Chapter 10. Files

83

The scripts are not required to configure every possible option for the package, but only those

necessary to get the package running on a given system. Ideally the sysadmin should not have

to do any configuration other than that done (semi )automatically by the

postinst

script.

A common practice is to create a script called

package

 configure

and have the package's

postinst

call it if and only if the configuration file does not already exist. In certain cases

it is useful for there to be an example or template file which the maintainer scripts use. Such

files should be in

/usr/share/

package

or

/usr/lib/

package

(depending on whether

they are architecture independent or not). There should be symbolic links to them from

/usr

/share/doc/

package

/examples

if they are examples, and should be perfectly ordinary

dpkg

 handled files (not configuration files).

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.

10.7.4 Sharing configuration files

Packages which specify the same file as a

conffile

must be tagged as conflicting with each

other. (This is an instance of the general rule about not sharing files. Note that neither alter 

natives nor diversions are likely to be appropriate in this case; in particular,

dpkg

does not

handle diverted

conffile

s well.)

The maintainer scripts must not alter a

conffile

of any package, including the one the scripts

belong to.

If two or more packages use the same configuration file and it is reasonable for both to be in 

stalled at the same time, one of these packages must be defined as owner of the configuration

file, i.e., it will be the package which handles that file as a configuration file. Other packages

that use the configuration file must depend on the owning package if they require the con 

figuration file to operate. If the other package will use the configuration file if present, but is

capable of operating without it, no dependency need be declared.

If it is desirable for two or more related packages to share a configuration file and for all of

the related packages to be able to modify that configuration file, then the following should be

done:

1 One of the related packages (the  owning  package) will manage the configuration file

with maintainer scripts as described in the previous section.

2 The owning package should also provide a program that the other packages may use to

modify the configuration file.

3 The related packages must use the provided program to make any desired modifications

to the configuration file. They should either depend on the core package to guaran 

tee that the configuration modifier program is available or accept gracefully that they

cannot modify the configuration file if it is not. (This is in addition to the fact that the

configuration file may not even be present in the latter scenario.)

Sometimes it's appropriate to create a new package which provides the basic infrastructure

for the other packages and which manages the shared configuration files. (The

sgml base

package is a good example.)