Re: 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
Reply to: