3.9. Maintainer Scripts

The package installation scripts should avoid producing output which is unnecessary for the user to see and should rely on dpkg to stave off boredom on the part of a user installing many packages. This means, amongst other things, not passing the --verbose option to update-alternatives.

Errors which occur during the execution of an installation script must be checked and the installation must not continue after an error.

Note that in general Scripts applies to package maintainer scripts, too.

You should not use dpkg-divert on a file belonging to another package without consulting the maintainer of that package first. When adding or removing diversions, package maintainer scripts must provide the --package flag to dpkg-divert and must not use --local.

All packages which supply an instance of a common command name (or, in general, filename) should generally use update-alternatives, so that they may be installed together. If update-alternatives is not used, then each package must use Conflicts to ensure that other packages are removed. (In this case, it may be appropriate to specify a conflict against earlier versions of something that previously did not use update-alternatives; this is an exception to the usual rule that versioned conflicts should be avoided.)

3.9.1. Prompting in maintainer scripts

Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher.

Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed.

The Debian Configuration Management Specification is included in the debconf_specification files in the debian-policy package. It is also available from the Debian web mirrors at https://www.debian.org/doc/packaging-manuals/debconf_specification.html.

Packages which use the Debian Configuration Management Specification may contain the additional control information files config and templates. config is an additional maintainer script used for package configuration, and templates contains templates used for user prompting. The config script might be run before the preinst script and before the package is unpacked or any of its dependencies or pre-dependencies are satisfied. Therefore it must work using only the tools present in essential packages. 5

Packages which use the Debian Configuration Management Specification must allow for translation of their user-visible messages by using a gettext-based system such as the one provided by the po-debconf package.

Packages should try to minimize the amount of prompting they need to do, and they should ensure that the user will only ever be asked each question once. This means that packages should try to use appropriate shared configuration files (such as /etc/papersize and /etc/news/server), and shared debconf variables rather than each prompting for their own list of required pieces of information.

It also means that an upgrade should not ask the same questions again, unless the user has used dpkg --purge to remove the package’s configuration. The answers to configuration questions should be stored in an appropriate place in /etc so that the user can modify them, and how this has been done should be documented.

If a package has a vitally important piece of information to pass to the user (such as “don’t run me as I am, you must edit the following configuration files first or you risk your system emitting badly-formatted messages”), it should display this in the config or postinst script and prompt the user to hit return to acknowledge the message. Copyright messages do not count as vitally important (they belong in /usr/share/doc/package/copyright); neither do instructions on how to use a program (these should be in on-line documentation, where all the users can see them).

Any necessary prompting should almost always be confined to the config or postinst script. If it is done in the postinst, it should be protected with a conditional so that unnecessary prompting doesn’t happen if a package’s installation fails and the postinst is called with abort-upgrade, abort-remove or abort-deconfigure.

1

A sample implementation of such a whitelist written for the Mailman mailing list management software is used for mailing lists hosted by https://alioth-lists.debian.net/.

2

The detailed procedure for gracefully orphaning a package can be found in the Debian Developer’s Reference (see Related documents).

3

The blurb that comes with a program in its announcements and/or README files is rarely suitable for use in a description. It is usually aimed at people who are already in the community where the package is used.

4

Essential is needed in part to avoid unresolvable dependency loops on upgrade. If packages add unnecessary dependencies on packages in this set, the chances that there will be an unresolvable dependency loop caused by forcing these Essential packages to be configured first before they need to be is greatly increased. It also increases the chances that frontends will be unable to calculate an upgrade path, even if one exists.

Also, functionality is rarely ever removed from the Essential set, but packages have been removed from the Essential set when the functionality moved to a different package. So depending on these packages just in case they stop being essential does way more harm than good.

5

Debconf or another tool that implements the Debian Configuration Management Specification will also be installed, and any versioned dependencies on it will be satisfied before preconfiguration begins.