[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ucf: Diversion of /u/b/ucf by etcgit



Manoj Srivastava <srivasta@debian.org> wrote:
> On Sun, Feb 22 2009, Jörg Sommer wrote:
>> Manoj Srivastava <srivasta@debian.org> wrote:
>>> On Sat, Feb 21 2009, Jörg Sommer wrote:
>>>>
>>>> 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?
>>
>> I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get.
>
>>>         What happens if I do a dpkg -i?
>>
>> Nothing. You have to update the branches by hand.
>
>         And yet you are proposing to divert ucf?

What do you suggest should happen when you run dpkg -i? What
should etcgit do?

>>>         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.
>
>> You can with the Post-Invoke hook.
>
>         What will you get about the newly created file in the
>  post-invoke hook?

The newly created file. I add it to the local branch to track the
changes. I can't tell the user where it comes from nor in which way his
file differs from the original, but it's in the tree. Nothing more.
That's the same etckeeper does for many versions. And did you get any
complains about your ucf acting wrong?

>  By the time the post-invoke hook is called, the file might be long
>  gone

Why should it be gone? If someone (dpkg, ucf, a update-somthing tool or a
maintainer script) puts a file underneath /etc, who should remove it?

>  -- and since ucf is being told to ignore the new file, you have lost
>  it.

I only tell ucf to not touch the file if I can get it in the wrapper. If
not the wrapper is invoked (or disabled), but the real ucf, I can't tell
it to not touch the new file.

>>>         I will consider adding a conflicts to the ucf package as well.
>>
>> Are you contented, when I disable the wrapper and add an option so the
>> user can enable the wrapper if he likes or leave it if he dislikes?
>
>         If you are going to divert ucf, I'll add a conflicts.

But then you force me to replace ucf what I don't want to do. I offered
the option to disable the wrapper by default and make everything works as
if the wrapper isn't there. What's the problem?

Bye, Jörg.
-- 
Damit das Mögliche entsteht, muß immer wieder das Unmögliche versucht
werden.                                       (Hermann Hesse)


Reply to: