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

Re: stop the "manage with debconf" madness

Personally I use the ask-about-overwrite question in debconf because the
last time this thread came up the only sensible solution was put forward in
the attached email. Now, I'm all for a better solution when it is determined
what that is, *but* I'm not for a witch hunt based on what was seen to be
previous best practice.

--- Begin Message ---
On Mon, Jan 15, 2001 at 07:40:00PM +1000, Jason Henry Parker wrote:

> [1] : Actually the file in question was a conffile as well as being
>       edited by debconf, but whatever.

Herein lies the problem, as I see it.  This is a common policy violation
because maintainers often want this functionality, but it clashes with policy,
or is not addressed.  With old-style use of conffiles, package maintainers
simply provided a default conffile, which they could update from time to time,
and the USER was responsible for merging in their local changes.  This was easy
on package maintainers, but hard on users.

Some packages cannot supply a reasonable default configuration for all users,
and/or would like to make the user's life easier by asking a few questions and
generating a configuration file.  In the pre-debconf era, this would be done by
a <package>config script, a la exim or magicfilter.  Once the config file was
generated, it would be left alone forever.  The user could reconfigure at any
time by running the script.  If the config file format changed or some such,
the user is responsible for re-running the config script and generating a new
config file.

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

1. Hide in a hole, and do things the old way.

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

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

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

5. Ask the user whether or not to overwrite their configuration file (the
   configuration file is NOT a conffile).  This is the approach taken by
   xserver-xfree86.  One of the questions asked of the user is (in effect)
   whether their configuration file should be under their control, or that of
   the maintainer scripts.  If the user opts to have their config file
   generated for them, manual changes are not preserved and their configuration
   is freshly generated (in the correct format) based on their answers.  If the
   user opts to write their own config file, the maintainer scripts will leave
   it alone until the user changes their mind.

Option #5 best meets the goals of both users and package maintainers.  Its only
problem is one of elegance.  First, the code and templates to ask the user
about each config file and how it should be handled must be duplicated in every
package that takes this approach.  Second, the packaging system does not know
about these configuration files, so the user might have some difficulty
determining which package owns it, or how it is managed.

This functionality should, I think, be integrated into the packaging system,
like the current conffile mechanism.  A configuration file should be able to be
tagged as either user-managed (behaving exactly as a current conffile) or
script-managed.  The user should be able to, at any time, switch between these
two states for a given configuration file, and maintainer scripts should be
able to query their status easily.  There has already been some talk about
enabling dpkg to track script-managed files.


 - mdz

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

--- End Message ---

Reply to: