Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava <srivasta@debian.org> wrote:
> On Sat, Feb 21 2009, Jörg Sommer wrote:
>> 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.
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, Jörg.
--
Man soll Denken lehren, nicht Gedachtes.
Reply to: