Re: dotdee: a proposal for improving conffile management in Debian
On Thu, May 5, 2011 at 1:14 AM, Raphael Hertzog <hertzog@debian.org> wrote:
> On Wed, 04 May 2011, Jonathan Nieder wrote:
>> Raphael Hertzog wrote:
>>
>> > There's quite some work left to define the interface that the
>> > dpkg-conffile-handler programs must implement, and to the way the override
>> > would work
>>
>> Well, yeah. :)
>
> Heh, I'm happy to try to go into more details but I wanted first to
> explain the general principle and see how people would react to it.
Sorry for the delayed response (been travelling for the last few weeks).
>> FWIW I don't think this is inconsistent with what Dustin was
>> suggesting --- dotdee would just be one example of a
>> dpkg-conffile-handler program.
>
> Yes, I even mentioned this case as an example. :-)
Ack.
>> So the question becomes, where do the pristine conffiles get written,
>> and when does the conffile handler program get called to deal with
>> them.
>
> The closest compared to now is that have the pristine conffiles
> extracted where they are expected with the usual .dpkg-new suffix
> but to give the explicit path to the dpkg-conffile-handler so that
> dpkg is free to use something else later on.
>
> In theory the conffile handler would be called exactly at the time
> where dpkg renames .dpkg-new files during the --configure (i.e. before the
> postinst is run).
Agreed. That could really be an improvement over *.dpkg-new!
>> I confess that I'd prefer a hook specified on the commandline over
>> alternatives, since it would make experimenting with e.g. debugging
>> options a little easier. Defaults for commandline options can be
>> specified in dpkg.conf so I don't think this means any loss of
>> convenience.
>
> One does not forbid the other. The alternative system is cleaner to
> predict the behaviour of which package is going to have precedence should
> several conffile-handler be registered.
Right. I didn't _have_ to use update-alternatives in dotdee, but I
liked that it:
a) did a good, well-documented job of handling the creation/removal
of the necessary symlinks
b) supported a "priority" system, whereby those priorities are easily
over or under ridden
c) makes all of the available alternatives easily discoverable by a
curious admin or programmatic utility
> But we can certainly have a command-line option too for experimenting (or
> even just to be able to write non-regression tests).
>
>> I'd also prefer if, at least to start, there is only one conffile
>> handling program so people can experiment with what a good stackable
>> interface looks like (those are hard) outside of dpkg.
>
> Trust us to accept only good stuff in dpkg. :-)
Hehe :-)
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
Reply to: