Solution strategy: Re: use and abuse of debconf
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.
Comments?
--
- mdz
Reply to: