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