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

Questionable conffile handling in connection with debconf



I have noticed that many packages are improperly modifying conffiles in
postinst, often using information from the debconf database.  As I understand
policy (see the excerpt at the end of this message), conffiles should never be
modified in maintainer scripts.  Configuration files should be distributed as
part of the package (either as conffiles or not), or else created and managed
by maintainer scripts, but not both.  The growing popularity of debconf seems
to have made this an important issue.

A few of the packages that happen to be present on my system are adduser
(modifies conffile adduser.conf), esound-common (modifies conffile
/etc/esound/esd.conf) and lynx (modifies conffile /etc/lynx.cfg).

This mixing of semantics (conffile changes should be preserved, but debconf
configuration choices should be honoured) can be very confusing.  adduser seems
to go to some trouble in order to check if the user has changed the setting in
the configuration file, and will ask again.  lynx seems to only use the debconf
setting for initial configuration, and ignore it thereafter.  esound-common
seems to unconditionally override the configuration file setting using the
answer from debconf.

For the three packages I looked at, there were three different sets of
semantics.  What do we do about this?

Quoth the Policy [section 4.7.3]:

The easy way to achieve this behavior is to make the configuration file a
conffile. This is appropriate only if it is possible to distribute a default
version that will work for most installations, although some system
administrators may choose to modify it. This implies that the default version
will be part of the package distribution, and must not be modified by the
maintainer scripts during installation (or at any other time).
[...]
The other way to do it is via the maintainer scripts. In this case, the
configuration file must not be listed as a conffile and must not be part of the
package distribution. If the existence of a file is required for the package to
be sensibly configured it is the responsibility of the package maintainer to
write scripts which correctly create, update, maintain and remove-on-purge the
file. 
[...]
These two styles of configuration file handling must not be mixed, for that way
lies madness: dpkg will ask about overwriting the file every time the package
is upgraded.

-- 
 - mdz

Attachment: pgp3XZE9gPelb.pgp
Description: PGP signature


Reply to: