FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-20-2009, 05:04 PM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Fri, Feb 20 2009, Jrg Sommer wrote:

> I'm packaging etcgit [1], a system to manage configuration files in /etc
> with git, similar to etckeeper. Etcgit tracks the original version of all
> files and therefore, I have to wrap ucf to get the original version and
> stop ucf from doing anything. The script [2] is mainly this:

Shouldn't etcgit be tracking the current state as well as the
original versions?

Also, I am not sure that this is valid. ucf is merely a toll
for the administrator to select what the local configuration file
contains; and as such is logically similar to vi or emacs. If you are
nto planning on wrapping vi-and-variants, and various emacsen, why wrap
ucf?


> save_original
> merge_with_current
> export UCF_FORCE_CONFFOLD=1

NAK.

I think this is wrong. This essentially says that ucf should
never present the new config file to the user, even if keeping the old
configuration files breaks the system. If the user/maintainer decides
to shoot themselves in the foot it is onething, but ucf should never
set this as the default.

> run_real_ucf "$@"
> rm "$file".ucf-dist
>
> As the Debian policy requests, I write to you to tell you about my plan
> and ask for your approval.

I think this should be discussed on -devel, not just between us.

> [1] http://git.debian.org/?p=users/jo-guest/etcgit.git;a=summary
> [2] http://git.debian.org/?p=users/jo-guest/etcgit.git;a=blob;f=ucf-wrapper;hb=HEAD


manoj
--
I hate dying. Dave Johnson
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-21-2009, 09:41 AM
Jörg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Hi Manoj, Hi debian-devel,

Manoj Srivastava hat am Fri 20. Feb, 12:04 (-0600) geschrieben:
> On Fri, Feb 20 2009, Jörg Sommer wrote:
>
> > I'm packaging etcgit [1], a system to manage configuration files in /etc
> > with git, similar to etckeeper. Etcgit tracks the original version of all
> > files and therefore, I have to wrap ucf to get the original version and
> > stop ucf from doing anything. The script [2] is mainly this:
>
> Shouldn't etcgit be tracking the current state as well as the
> original versions?

Yes, it does so. In one branch it tracks the original configuration files
as given to ucf and as shipped with the packages. In a second branch the
configuration files modified by the administrator are stored. The former
branch is updated when ucf or apt-get is run. Then these changes are
merged into the branch with the local configurations. If a confict
happens, the user has to solve it manually.

> Also, I am not sure that this is valid. ucf is merely a toll
> for the administrator to select what the local configuration file
> contains; and as such is logically similar to vi or emacs. If you are
> nto planning on wrapping vi-and-variants, and various emacsen, why wrap
> ucf?

No, it's up to the administrator to make commits to etcgit after changes
to any file. Etcgit refuses to continue with apt-get if there are
uncommited changes.

> > save_original
> > merge_with_current
> > export UCF_FORCE_CONFFOLD=1
>
> NAK.
>
> I think this is wrong. This essentially says that ucf should
> never present the new config file to the user, even if keeping the old
> configuration files breaks the system.

Yes, ucf should not touch the configuration file, because the merge
was done by etcgit. When ucf sees the “old” configuration file it's
already updated by etcgit. The ucf call is only to let ucf update it's
internal database.

Regards, Jörg.
--
Was man mühelos erreichen kann, ist gewöhnlich nicht der Mühe wert,
erreicht zu werden.
 
Old 02-21-2009, 03:23 PM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sat, Feb 21 2009, Jörg Sommer wrote:

> Hi Manoj, Hi debian-devel,
>
> Manoj Srivastava hat am Fri 20. Feb, 12:04 (-0600) geschrieben:
>> On Fri, Feb 20 2009, Jörg Sommer wrote:
>>
>> > I'm packaging etcgit [1], a system to manage configuration files in /etc
>> > with git, similar to etckeeper. Etcgit tracks the original version of all
>> > files and therefore, I have to wrap ucf to get the original version and
>> > stop ucf from doing anything. The script [2] is mainly this:
>>
>> Shouldn't etcgit be tracking the current state as well as the
>> original versions?
>
> Yes, it does so. In one branch it tracks the original configuration files
> as given to ucf and as shipped with the packages. In a second branch

I don't see how you can get that. There is no "file shipped with
the package" when you use ucf. Indeed, if there were files shipped in
/etc in the package, you can't use ucf. The files given to ucf are
often generated at install time -- and you have no way of knowing where
they are located.

What you are doing is to keep a static record of the very first
file that etckeeper encounters -- and never, ever changing it, despite
what the package maintainer wants as the new version. This does not
seem like something anyone would actually want.


> the configuration files modified by the administrator are stored. The
> former branch is updated when ucf or apt-get is run. Then these

How is the former branch updated with the new version, since you
are using UCF_FORCE_CONFFOLD? The documented effect is to retain
whatever was on the file system, no matter what.

> changes are merged into the branch with the local configurations. If a
> confict happens, the user has to solve it manually.

>> Also, I am not sure that this is valid. ucf is merely a toll
>> for the administrator to select what the local configuration file
>> contains; and as such is logically similar to vi or emacs. If you are
>> nto planning on wrapping vi-and-variants, and various emacsen, why wrap
>> ucf?
>
> No, it's up to the administrator to make commits to etcgit after changes
> to any file. Etcgit refuses to continue with apt-get if there are
> uncommited changes.

In other words, totally remove whatever functionality ucf
offers -- which is to allow users to know there is a nerw version, and
optionally use it. ucf will record that the upstream files md5sum is
changed, but it will not actually record anything else about the
upstream version (unless the threeway option is used).

>> > save_original
>> > merge_with_current
>> > export UCF_FORCE_CONFFOLD=1
>>
>> NAK.
>>
>> I think this is wrong. This essentially says that ucf should
>> never present the new config file to the user, even if keeping the old
>> configuration files breaks the system.
>
> Yes, ucf should not touch the configuration file, because the merge
> was done by etcgit. When ucf sees the “old” configuration file it's
> already updated by etcgit. The ucf call is only to let ucf update it's
> internal database.

ucf only changes the configuration file if the user asks it
to. And the user, in your scheme, may never even know there is a file to
be updated -- since you have effectively removed ucf functionality.

This sounds more like etckeeper conflicts with ucf.

I suggest you look more into how to integrate ucf mandated
changes into etckeeper, rather than just gutting ucf. etckeeper needs
to find out what the upstream version is, record that in the proper
branch, and then ucf dot its stuff on the "local" branch, and record
that.

Anything else should be reflected in a conflicts relationship
between ucf and etckeeper, not a diversion, since the diversion does
not actually maintain the functionality of ucf.

manoj
--
Once harm has been done, even a fool understands it. Homer
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-21-2009, 08:08 PM
Frank Küster
 
Default ucf: Diversion of /u/b/ucf by etcgit

Manoj Srivastava <srivasta@debian.org> wrote:

>> Yes, ucf should not touch the configuration file, because the merge
>> was done by etcgit. When ucf sees the “old” configuration file it's
>> already updated by etcgit. The ucf call is only to let ucf update it's
>> internal database.
>
> ucf only changes the configuration file if the user asks it
> to. And the user, in your scheme, may never even know there is a file to
> be updated -- since you have effectively removed ucf functionality.
>
> This sounds more like etckeeper conflicts with ucf.
>
> I suggest you look more into how to integrate ucf mandated
> changes into etckeeper, rather than just gutting ucf.

>From the little information I have about etcgit and etckeeper, it seems
to me that Manoj is right. It may, however, actually make sense to
divert (or change) ucf to make etc{git,keeper} usable with it: It would
have to commit the file to the correct branch of the repository (and
then update it's own database by doing something similar to what was
proposed originally).

Regards, Frank
--
Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-21-2009, 10:09 PM
Jrg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Manoj Srivastava <srivasta@debian.org> wrote:
> On Sat, Feb 21 2009, Jrg Sommer wrote:
>> Manoj Srivastava hat am Fri 20. Feb, 12:04 (-0600) geschrieben:
>>> On Fri, Feb 20 2009, Jrg Sommer wrote:
>>>
>>> > I'm packaging etcgit [1], a system to manage configuration files in /etc
>>> > with git, similar to etckeeper. Etcgit tracks the original version of all
>>> > files and therefore, I have to wrap ucf to get the original version and
>>> > stop ucf from doing anything. The script [2] is mainly this:
>>>
>>> Shouldn't etcgit be tracking the current state as well as the
>>> original versions?
>>
>> Yes, it does so. In one branch it tracks the original configuration files
>> as given to ucf and as shipped with the packages. In a second branch
>
> I don't see how you can get that. There is no "file shipped with
> the package" when you use ucf.

Right, but when I hook into apt-get, I can get the configuration file
shipped with the packages. But that has nothing to do with ucf.

>> the configuration files modified by the administrator are stored. The
>> former branch is updated when ucf or apt-get is run. Then these
>
> How is the former branch updated with the new version, since you
> are using UCF_FORCE_CONFFOLD? The documented effect is to retain
> whatever was on the file system, no matter what.

Therefore, I use the wrapper around ucf. The postinst script calls

ucf <New File> <Destination>

So I've the new file and know where it should go. I can update the file
in the branch with the original files and then merge this branch with the
local configuration branch and install this result underneath /etc. Then
the real ucf can update it's database, but it should not touch the file
I've put underneath /etc. It's

save_original
merge_with_current
export UCF_FORCE_CONFFOLD=1
ucf.etcgit "$@"

>> changes are merged into the branch with the local configurations. If a
>> confict happens, the user has to solve it manually.
>
>>> Also, I am not sure that this is valid. ucf is merely a toll
>>> for the administrator to select what the local configuration file
>>> contains; and as such is logically similar to vi or emacs. If you are
>>> nto planning on wrapping vi-and-variants, and various emacsen, why wrap
>>> ucf?
>>
>> No, it's up to the administrator to make commits to etcgit after changes
>> to any file. Etcgit refuses to continue with apt-get if there are
>> uncommited changes.
>
> In other words, totally remove whatever functionality ucf
> offers

Not remove, but etcgit reimplements it.

> Anything else should be reflected in a conflicts relationship
> between ucf and etckeeper, not a diversion, since the diversion does
> not actually maintain the functionality of ucf.

Interesting idea. Etcgit could replace ucf. I'll think about it.

Bye, Jrg.
--
Man soll Denken lehren, nicht Gedachtes.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-21-2009, 11:38 PM
Steve Langasek
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sat, Feb 21, 2009 at 11:09:52PM +0000, Jrg Sommer wrote:

> >> the configuration files modified by the administrator are stored. The
> >> former branch is updated when ucf or apt-get is run. Then these

> > How is the former branch updated with the new version, since you
> > are using UCF_FORCE_CONFFOLD? The documented effect is to retain
> > whatever was on the file system, no matter what.

> Therefore, I use the wrapper around ucf. The postinst script calls

> ucf <New File> <Destination>

> So I've the new file and know where it should go. I can update the file
> in the branch with the original files and then merge this branch with the
> local configuration branch and install this result underneath /etc. Then
> the real ucf can update it's database, but it should not touch the file
> I've put underneath /etc. It's

> save_original
> merge_with_current
> export UCF_FORCE_CONFFOLD=1
> ucf.etcgit "$@"

So this will leave the ucf db with a horribly incorrect view of the current
state of the config file, and if the user ever removes etcgit, there'll be
a real mess.

> > Anything else should be reflected in a conflicts relationship
> > between ucf and etckeeper, not a diversion, since the diversion does
> > not actually maintain the functionality of ucf.

> Interesting idea. Etcgit could replace ucf. I'll think about it.

As a maintainer of packages that depend on ucf, I think that would be a
reason to conflict with etcgit in order to spare users the pain of the issue
above.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 12:15 AM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sat, Feb 21 2009, Jrg Sommer wrote:

> Manoj Srivastava <srivasta@debian.org> wrote:
>> On Sat, Feb 21 2009, Jrg Sommer wrote:
>>> Manoj Srivastava hat am Fri 20. Feb, 12:04 (-0600) geschrieben:
>>>> On Fri, Feb 20 2009, Jrg Sommer wrote:
>>>>
>>>> > I'm packaging etcgit [1], a system to manage configuration files in /etc
>>>> > with git, similar to etckeeper. Etcgit tracks the original version of all
>>>> > files and therefore, I have to wrap ucf to get the original version and
>>>> > stop ucf from doing anything. The script [2] is mainly this:
>>>>
>>>> Shouldn't etcgit be tracking the current state as well as the
>>>> original versions?
>>>
>>> Yes, it does so. In one branch it tracks the original configuration files
>>> as given to ucf and as shipped with the packages. In a second branch
>>
>> I don't see how you can get that. There is no "file shipped with
>> the package" when you use ucf.
>
> Right, but when I hook into apt-get, I can get the configuration file
> shipped with the packages. But that has nothing to do with ucf.

What does "hook into apt-get" mean?

What happens if I do a dpkg -i?

Also, there might be nothing shipped with the package. You can't
"hook into apt-get" to get the file generated in the postinst -- since
there might not _be_ a upstream version at all until the postinst is
run.


>>> the configuration files modified by the administrator are stored. The
>>> former branch is updated when ucf or apt-get is run. Then these
>>
>> How is the former branch updated with the new version, since you
>> are using UCF_FORCE_CONFFOLD? The documented effect is to retain
>> whatever was on the file system, no matter what.
>
> Therefore, I use the wrapper around ucf. The postinst script calls
>
> ucf <New File> <Destination>
>
> So I've the new file and know where it should go.

Fair enough, This will work.

> I can update the file in the branch with the original files and then
> merge this branch with the local configuration branch and install this
> result underneath /etc.

Hmm?

> save_original
> merge_with_current

$ git checkout <original file branch>
$ cp <New File> <Destination>
$ git add <Destination>
$ git commit
$ git checkout <local changes branch>
$ git merge <original file branch>

Which is pretty horrendous, since it merges changes from the
upstream branch into the local branch, which might break things,
without asking the human. You also do not ask the human if they want to
replace their local changes totally with the new upstream file -- which
might have implemented the changes the user made in a different way.


> Then the real ucf can update it's database,
> but it should not touch the file I've put underneath /etc. It's
> export UCF_FORCE_CONFFOLD=1
> ucf.etcgit "$@"

And the file has been changed udner the user, with the merge
above, without the user ever being informed before the changes were
committed.

>>> changes are merged into the branch with the local configurations. If a
>>> confict happens, the user has to solve it manually.
>>
>>>> Also, I am not sure that this is valid. ucf is merely a toll
>>>> for the administrator to select what the local configuration file
>>>> contains; and as such is logically similar to vi or emacs. If you are
>>>> nto planning on wrapping vi-and-variants, and various emacsen, why wrap
>>>> ucf?
>>>
>>> No, it's up to the administrator to make commits to etcgit after changes
>>> to any file. Etcgit refuses to continue with apt-get if there are
>>> uncommited changes.
>>
>> In other words, totally remove whatever functionality ucf
>> offers
>
> Not remove, but etcgit reimplements it.

Oh, you ask the use before you commit changes from the upstream
branch before you actually change the local file You handle deleted
files correctly?

Since asking the user is the basic thing ucf does, unless you
are asking the user, you are not re-implementing ucf.

>
>> Anything else should be reflected in a conflicts relationship
>> between ucf and etckeeper, not a diversion, since the diversion does
>> not actually maintain the functionality of ucf.
>
> Interesting idea. Etcgit could replace ucf. I'll think about it.

I will consider adding a conflicts to the ucf package as well.

manoj
--
Sex is like air. It's only a big deal if you can't get any.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 12:19 AM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sat, Feb 21 2009, Frank Küster wrote:

> Manoj Srivastava <srivasta@debian.org> wrote:
>
>>> Yes, ucf should not touch the configuration file, because the merge
>>> was done by etcgit. When ucf sees the “old” configuration file it's
>>> already updated by etcgit. The ucf call is only to let ucf update it's
>>> internal database.
>>
>> ucf only changes the configuration file if the user asks it
>> to. And the user, in your scheme, may never even know there is a file to
>> be updated -- since you have effectively removed ucf functionality.
>>
>> This sounds more like etckeeper conflicts with ucf.
>>
>> I suggest you look more into how to integrate ucf mandated
>> changes into etckeeper, rather than just gutting ucf.
>
>>From the little information I have about etcgit and etckeeper, it seems
> to me that Manoj is right. It may, however, actually make sense to
> divert (or change) ucf to make etc{git,keeper} usable with it: It would
> have to commit the file to the correct branch of the repository (and
> then update it's own database by doing something similar to what was
> proposed originally).

I think the correct thing for the wrapper to do is
a) change branch to the upstram_version_branch, and commit the new
upstream.
b) Change back to the local branch
c) run ucf and let the user do their thing (replace, not replace, edit,
whatever).
d) Commit the result to the local_changed_branch.


The basic idea is _not_ to interfere with the real ucf, so the
user is asked, and the local file what ucf thinks the local file is,
and what the user actually wants there.

Apart from the whole FORCE_CONFOLD thing, the rest is basically
sound.

manoj
--
"What I've done, of course, is total garbage." Willard, Pure Math 430a
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 10:00 AM
Vincent Danjean
 
Default ucf: Diversion of /u/b/ucf by etcgit

Manoj Srivastava wrote:
> I think the correct thing for the wrapper to do is
> a) change branch to the upstram_version_branch, and commit the new
> upstream.
> b) Change back to the local branch
> c) run ucf and let the user do their thing (replace, not replace, edit,
> whatever).
> d) Commit the result to the local_changed_branch.

I also think this would be a good think.

But perhaps, ucf can be improved to detect this situation (perhaps a new
option that etcgit add before calling the real ucf) and can propose a
new way to resolve the confict :
- use old conffile
- use new conffile
- see diff
- try experimental 3 way merge
- ...
- merge with etcgit <- new option for the user

If selected, the new option will run a callback provided by etcgit
that will merge the corresponding branches with git.


You will need to discuss between you to define properly the interfaces.
It is also possible to improve ucf to propose new generic ways of handling
merges (and perhaps storing the original file and the resulted file) just
by installing callback scripts.
Then etcgit or other similar packages will be able to install their hooks
without messing with provides/conflicts/diversions/... of ucf

Regards,
Vincent

--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 11:04 AM
Frank Kster
 
Default ucf: Diversion of /u/b/ucf by etcgit

Jrg Sommer <joerg@alea.gnuu.de> wrote:

> Right, but when I hook into apt-get, I can get the configuration file
> shipped with the packages.

You cannot, since the very purpose of ucf is to give dpkg-conffile-like
behavior for configuration files *not* shipped in the package.

Regards, Frank
--
Frank Kster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org