Chapter E. Configuration file handling (from old Packaging Manual)
their file, but the package maintainer doesn't ship a different version, the user's changes will
stay, silently, but if the maintainer ships a new version and the user hasn't edited it the new
version will be installed (with an informative message). If both have changed their version the
user is prompted about the problem and must resolve the differences themselves.
The comparisons are done by calculating the MD5 message digests of the files, and storing the
MD5 of the file as it was included in the most recent version of the package.
When a package is installed for the first time
will install the file that comes with it, unless
that would mean overwriting a file already on the file system.
However, note that
will not replace a conffile that was removed by the user (or by a
script). This is necessary because with some programs a missing file produces an effect hard
or impossible to achieve in another way, so that a missing file needs to be kept that way if the
user did it.
Note that a package should not modify a
handled conffile in its maintainer scripts. Doing
this will lead to
giving the user confusing and possibly dangerous options for conffile
update when the package is upgraded.
E.2 Fully featured maintainer script configuration handling
For files which contain site specific information such as the hostname and networking details
and so forth, it is better to create the file in the package's
This will typically involve examining the state of the rest of the system to determine values
and other information, and may involve prompting the user for some information which can't
be obtained some other way.
When using this method there are a couple of important issues which should be considered:
If you discover a bug in the program which generates the configuration file, or if the format of
the file changes from one version to the next, you will have to arrange for the postinst script to
do something sensible usually this will mean editing the installed configuration file to remove
the problem or change the syntax. You will have to do this very carefully, since the user may
have changed the file, perhaps to fix the very problem that your script is trying to deal with
you will have to detect these situations and deal with them correctly.
If you do go down this route it's probably a good idea to make the program that generates the
configuration file(s) a separate program in
, by convention called
and then run that if appropriate from the post installation script. The
gram should not unquestioningly overwrite an existing configuration if its mode of operation
is geared towards setting up a package for the first time (rather than any arbitrary reconfigu
ration later) you should have it check whether the configuration already exists, and require a
flag to overwrite it.