The use of this field is justified when package names change or when a package is included in another. This also happens when the maintainer decides to distribute files differently among various binary packages produced from the same source package: a replaced file no longer belongs to the old package, but only to the new one.
If all of the files in an installed package have been replaced, the package is considered to be removed. Finally, this field also encourages dpkg to remove the replaced package where there is a conflict.
GOING FURTHER The Tag field
In the apt example above, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) is a recent development in Debian. For this purpose, it is not yet integrated in all of its tools; aptitude displays these tags, and allows them to be used as search criteria. For those who are repelled by aptitude's search criteria, the following site allows navigation of the tag database:
→ http://debtags.alioth.debian.org/
5.2.2. Configuration Scripts
In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).
GOING FURTHER dpkg data directory
All of the configuration scripts for installed packages are stored in the /var/lib/dpkg/info/ directory, in the form of a file prefixed with the package's name. This directory also includes a file with the .list extension for each package, containing the list of files that belong to that package.
The /var/lib/dpkg/status file contains a series of data blocks (in the format of the famous mail headers, RFC 2822) describing the status of each package. The information from the control file of the installed packages is also replicated there.
In general, the preinst script is executed prior to installation of the package, while the postinst follows it. Likewise, prerm is invoked before removal of a package and postrm aftwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.
CAUTION Symbolic names of the scripts
The sequences described in this section call configuration scripts by specific names, such as old-prerm or new-postinst. They are, respectively, the prerm script contained in the old version of the package (installed before the update) and the postinst script contained in the new version (installed by the update).
TIP State diagrams
Manoj Srivastava made these diagrams explaining how the configuration scripts are called by dpkg. Similar diagrams have also been developed by the Debian Women project; they are a bit simpler to understand, but less complete.
→ http://people.debian.org/~srivasta/MaintainerScripts.html
→ http://wiki.debian.org/MaintainerScripts
5.2.2.1. Installation and Upgrade
Here is what happens during an installation (or an update):
For an update, dpkg calls the old-prerm upgrade new-version.
Still for an update, dpkg then executes new-preinst upgradeold-version; for a first installation, it executes new-preinst install. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, the configuration files having been retained).
The new package files are then unpacked. If a file already exists, it is replaced, but a backup copy is temporarily made.
For an update, dpkg executes old-postrm upgrade new-version.
dpkg updates all of the internal data (file list, configuration scripts, etc.) and removes the backups of the replaced files. This is the point of no return: dpkg no longer has access to all of the elements necessary to return to the previous state.
dpkg will update the configuration files, asking the user to decide if it is unable to automatically manage this task. The details of this procedure are discussed in Section 5.2.3, “Checksums, List of Configuration Files”.
Finally, dpkg configures the package by executing new-postinst configure last-version-configured.
5.2.2.2. Package Removal
Here is what happens during a package removaclass="underline"
dpkg calls prerm remove.
dpkg removes all of the package's files, with the exception of the configuration files and configuration scripts.
dpkg executes postrm remove. All of the configuration scripts, except postrm, are removed. If the user has not used the “purge” option, the operations are completed there.
For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes postrm purge.
VOCABULARY Purge, complete removal
When a Debian package is removed, the configuration files are retained in order to facilitate possible re-installation. Likewise, the data generated by a daemon (such as the content of an LDAP server directory, or the content of a database for an SQL server) are usually retained.
To remove all data associated with a package, it is necessary to “purge” the package with the command, dpkg -P package, apt-get remove --purge package or aptitude purge package.
Given the definitive nature of such data removal, purge should not be taken lightly.
The four scripts detailed below are complemented by a config script, provided by packages using debconf to acquire information from the user for configuration. During installation, this script defines in detail the questions asked by debconf. The responses are recorded in the debconf database for future reference. The script is generally executed by apt prior to installing packages one by one in order to group all the questions and ask them all to the user at the beginning of the process. The pre- and post-installation scripts can then use this information to operate according to the user's wishes.