Re: Solution strategy: Re: use and abuse of debconf

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Matt" == Matt Zimmerman <mdz@debian.org> writes:

    Matt> In this age of debconf, we now have standard tools for
    Matt> asking the user questions (debconf) and reconfiguring a
    Matt> package (dpkg-reconfigure).  In order to use these
    Matt> mechanisms successfully, we need some way to peacefully
    Matt> coexist with the user's manual changes.  The key change is
    Matt> that package configuration via these tools is done _by
    Matt> maintainer scripts_, rather than by supplying a default
    Matt> conffile or running a script.  Policy specifically forbids
    Matt> the editing of conffiles by maintainer scripts ([1] (must
    Matt> not), [2] (should not)).  Now, maintainer scripts using
    Matt> debconf have these options:


    Matt> 2. Only generate an initial configuration, and leave it
    Matt> alone forever thereafter (the configuration file may be a
    Matt> conffile).  This is a waste of good infrastructure, and
    Matt> leaves the user feeling cheated.  If they want to use that
    Matt> same slick process to create a new configuration, they must
    Matt> remove and reinstall the package.

Uh such configuration must not be a conffile.  It will always differ
from the package, so the md5 checksum will be wrong.  Also, it is
against policy.



    Matt> 3. Always overwrite the configuration (the configuration
    Matt> file is NOT a conffile).  This may seem appropriate for some
    Matt> packages, for which there is a 1:1 mapping between debconf
    Matt> questions and configuration options, but does not allow the
    Matt> user to preserve their local changes (a bad thing).

This is often against policy 4.7.3.


    Matt> 4. Try to merge the user's changes into the configuration
    Matt> file (the configuration file is NOT a conffile).  This is,
    Matt> in my opinion, almost always a bad idea.  Regardless of how
    Matt> few lines such a hack adds to the maintainer scripts, this
    Matt> is not guaranteed to stay simple.  If a config file format
    Matt> changes, for example, the maintainer scripts may be required
    Matt> to be able to parse both config file formats and convert
    Matt> between them.  This means that the maintainer script's
    Matt> parser must be smarter than the program's own (which can
    Matt> only read one of the formats).  Some programs, which use an
    Matt> ancient config file format that is unlikely to ever change,
    Matt> can get away with this, as can programs with very simple

I really think that we should attempt to develop tools to support this
wherever possible.