On Thu, May 5, 2011 at 1:14 AM, Raphael Hertzog <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
