Marc Haber writes ("Re: Ideas to improve dpkg/ucf with hooks"):
> On Sun, 15 Nov 2015 23:10:11 +0100, Wouter Verhelst
> <wou...@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.
