Re: Ideas to improve dpkg/ucf with hooks
Marc Haber writes ("Re: Ideas to improve dpkg/ucf with hooks"):
> On Sun, 15 Nov 2015 23:10:11 +0100, Wouter Verhelst
> <wouter@debian.org> wrote:
> >On Fri, Nov 13, 2015 at 05:47:41PM +0100, Marc Haber wrote:
> >> Regarding dpkg, its conffile handling is IMO beyond repair, it should
> >> be deprecated and later removed.
> >
> >Could you explain why?
I thought that as the original author of dpkg's conffile mechanism,
I'd say that I agree with Marc's criticisms.
> - It does not give maintainers the level of control that she has with
> ucf
> - It is still (after over 15 years) a program (if not the only one)
> that directly prompts the user with a keyboard-needing question
> instead of doing it debconf- and ucf-style with selectable
> frontends, defaulting to a dialog-style frontend
These are important bugs to fix. I don't have an opinion about /how/
they should be fixed (eg, whether by deprecating the dpkg conffile
system, or improving it, or whatever). There are several reasonable
approaches. I'm glad that people are looking at this.
> - It is documented to fail miserably when a conffile belonging to
> package A gets modified by package B. This is not relevant for
> Debian proper (since we forbid this constellation in Policy to cater
> for this shortcoming of our central package management tool), but
> making this possible would make package maintenance (e.g. sharing of
> a single conffile between packages) muche easier, and it would allow
> local administrators to have local "configuration" packages to roll
> out for basic site configuration without a full-fledged
> configuration management system.
I think ideally we would have some system whereby different packages
can meddle with each others' conffiles, _before_ dpkg/ucf-style
diff-based config prompting.
Ie, something which would allow packages to modify (in some controlled
and reproducible way) (or even generate) the notional `as shipped'
version.
That would make it much easier to make overlay and configuration
management packages. (Those are less important in Debian proper but
would be very useful for special-purpose downstreams, users, etc.)
Ian.
Reply to: