Chapter E. Configuration file handling (from old Packaging Manual)

122

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

dpkg

will install the file that comes with it, unless

that would mean overwriting a file already on the file system.

However, note that

dpkg

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

dpkg

 handled conffile in its maintainer scripts. Doing

this will lead to

dpkg

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

postinst

script.

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

/usr/sbin

, by convention called

package

config

and then run that if appropriate from the post installation script. The

package

config

pro 

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

  force

flag to overwrite it.