Re: ucf: Diversion of /u/b/ucf by etcgit
On Sat, Feb 21 2009, Jörg Sommer wrote:
> 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.
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
Reply to: