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

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. :-)


>>  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 Kirkland
Ubuntu Core Developer

Reply to: