Packages can declare in their control file that they have certain relationships to other packages - for example, that they may not be installed at the same time as certain other packages, and/or that they depend on the presence of others, or that they should overwrite files in certain other packages if present.
This is done using the Depends, Recommends, Suggests, Conflicts, Provides and Replaces control file fields.
Source packages may declare relationships to binary packages, saying that they require certain binary packages being installed or absent at the time of building the package.
This is done using the Build-Depends, Build-Depends-Indep, Build-Conflicts, and Build-Conflicts-Indep control file fields.
These fields all have a uniform syntax. They are a list of package names separated by commas.
In Depends, Recommends, Suggests, Pre-Depends, Build-Depends and Build-Depends-Indep(the fields which declare dependencies of the package in which they occur on other packages) these package names may also be lists of alternative package names, separated by vertical bar symbols | (pipe symbols).
All the fields except Provides may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual package name; the parentheses should contain a relation from the list below followed by a version number, in the format described in Version numbering, Chapter 5.
The relations allowed are <<, <=,
=, >= and >> for strictly
earlier, earlier or equal, exactly equal, later or equal and strictly later,
respectively. The forms < and > were used to
mean earlier/later or equal, rather than strictly earlier/later, so they should
not appear in new packages (though dpkg
still supports them).
Whitespace may appear at any point in the version specification, and must
appear where it's necessary to disambiguate; it is not otherwise significant.
For consistency and in case of future changes to dpkg
it is
recommended that a single space be used after a version relationship and before
a version number; it is usual also to put a single space after each comma, on
either side of each vertical bar, and before each open parenthesis.
For example:
Package: metamail Version: 2.7-3 Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
All fields that specify build-time relationships (Build-Depends, Build-Depends-Indep, Build-Conflicts and Build-Conflicts-Indep) may be restricted to a certain set of architectures. This is done in brackets after each individual package name and the optional version specification. The brackets enclose a list of Debian architecture names separated by whitespace. An exclamation mark may be prepended to each name. If the current Debian host architecture is not in this list and there are no exclamation marks in the list, or it is in the list with a prepended exclamation mark, the package name and the associated version specification are ignored completely for the purposes of defining the relationships.
For example:
Source: glibc Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
These four fields are used to declare a dependency by one package on another. They appear in the depending package's control file.
All but Pre-Depends (discussed below) take effect only when a package is to be configured. They do not prevent a package being on the system in an unconfigured state while its dependencies are unsatisfied, and it is possible to replace a package whose dependencies are satisfied and which is properly installed with a different version whose dependencies are not and cannot be satisfied; when this is done the depending package will be left unconfigured (since attempts to configure it will give errors) and will not function properly.
For this reason packages in an installation run are usually all unpacked first and all configured later; this gives later versions of packages with dependencies on later versions of other packages the opportunity to have their dependencies satisfied.
Thus Depends allows package maintainers to impose an order in which packages should be configured.
dpkg
will not configure packages whose dependencies aren't
satisfied. If it is asked to make an installation which would cause an
installed package's dependencies to become unsatisfied it will complain [21], unless
--auto-deconfigure is specified, in which case those packages will
be deconfigured before the installation proceeds.
dselect
makes it hard for the user to select packages for
installation, removal or upgrade in a way that would mean that packages'
Depends
fields would be unsatisfied. The user can override this
if they wish, for example if they know that dselect
has an
out-of-date view of the real package relationships.
The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.
Recommends is ignored by dpkg
, so that users using
the command-line (who are presumed to know what they're doing) will not be
impeded.
It is treated by dselect
exactly as Depends is; this
makes it hard for the user to select things so as to leave
Recommends fields unsatisfied, but they are able to do so by being
persistent.
The Recommends field should list packages that would be found together with this one in all but unusual installations.
dselect
will offer suggsted packages to the system administrator
when they select the suggesting package, but the default is not to install the
suggested package.
dpkg
to complete installation of the packages named before even
starting the installation of the package which declares the predependency.
dselect
checks for predependencies when it is doing an
installation run, and will attempt to find the packages which are required to
be installed first and do so in the right order.
However, this process is slow (because it requires repeated invocations of
dpkg
) and troublesome (because it requires guessing where to find
the appropriate files).
For these reasons, and because this field imposes restrictions on the order in which packages may be unpacked (which can be difficult for installations from multipart media, for example), Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.
When the package declaring it is being configured, a Pre-Dependency will be considered satisfied only if the depending package has been correctly configured, just as if an ordinary Depends had been used.
However, when a package declaring a predependency is being unpacked the predependency can be satisfied even if the depended-on package(s) are only unpacked or half-configured, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case both the previously-configured and currently unpacked or half-configured versions must satisfy any version clause in the Pre-Depends field.
When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency. Some packages are composed of components of varying degrees of importance. Such a package should list using Depends the package(s) which are required by the more important components. The other components' requirements may be mentioned as Suggestions or Recommendations, as appropriate to the components' relative importance.
The dependency fields listed above are used by packages which need shared libraries to declare dependencies on the appropriate packages.
These dependencies are usually determined automatically using
dpkg-shlibdeps
and inserted in the package control file using the
control file substitution variables mechanism; see debian/substvars and
variable substitutions, Section 3.2.4 and Tools for processing source packages,
Section 3.1.
If dpkg
would like to remove a package due to a conflict, as
described above, but this would violate a dependency of some other package on
the system, dpkg
will usually not remove the conflicting package
and halt with an error.
However, if the --auto-deconfigure (-B) option is
used dpkg
will automatically `deconfigure' the package with the
problematic dependency, so that the conflicting package can be removed and the
package we're trying to install can be installed. If dpkg
is
being asked to install packages (rather than just unpacking them) it will try
to reconfigure the package when it has unpacked all its arguments, in the hope
that one of the other packages it is installing will satisfy the problematic
dependency.
dselect
supplies this argument to dpkg
when it
invokes it, so that bulk installations proceed smoothly.
When one binary package declares a conflict with another dpkg
will
refuse to allow them to be installed on the system at the same time.
If one package is to be installed, the other must be removed first - if the
package being installed is marked as replacing (Replaces - overwriting
files and replacing packages, Section 8.5) the one on the system, or the
one on the system is marked as deselected, or both packages are marked
Essential, then dpkg
will automatically remove the
package which is causing the conflict, otherwise it will halt the installation
of the new package with an error.
dselect
makes it hard to select conflicting packages, though the
user can override this if they wish. If they do not override it then
dselect
will select one of the packages for removal, and the user
must make sure it is the right one. In the future dselect
will
look for the presence of a Replaces field to help decide which
package should be installed and which removed.
A package will not cause a conflict merely because its configuration files are still installed; it must be at least half-installed.
A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing something.
A Conflicts entry should almost never have an `earlier than'
version clause. This would prevent dpkg
from upgrading or
installing the package which declared such a conflict until the upgrade or
removal of the conflicted-with package had been completed. This aspect of
installation ordering is not handled by dselect
, so that the use
Conflicts in this way is likely to cause problems for `bulk run'
upgrades and installations.
As well as the names of actual (`concrete') packages, the package relationship fields Depends, Build-Depends, Build-Depends-Indep, Recommends, Suggests, Conflicts, Build-Conflicts and Build-Conflicts-Indep may mention virtual packages.
A virtual package is one which appears in the Provides control file field of another package. The effect is as if the package(s) which provide a particular virtual package name had been listed by name everywhere the virtual package name appears.
If there are both a real and a virtual package of the same name then the dependency may be satisfied (or the conflict caused) by either the real package or any of the virtual packages which provide it. This is so that, for example, supposing we have
Package: vm Depends: emacs
and someone else releases an xemacs package they can say
Package: xemacs Provides: emacs
and all will work in the interim (until a purely virtual package name is decided on and the emacs and vm packages are changed to use it).
If a dependency or a conflict has a version number attached then only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict) - it is assumed that a real package which provides virtual package is not of the `right' version. So, a Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be looked at when considering a dependency on or conflict with the virtual package name.
It is likely that the ability will be added in a future release of
dpkg
to specify a version number for each virtual package it
provides. This feature is not yet present, however, and is expected to be used
only infrequently.
If you want to specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, you should list the real package as an alternative before the virtual.
The Replaces control file field has two purposes, which come into play in different situations.
Virtual packages (Virtual packages - Provides, Section 8.4) are not considered when looking at a Replaces field - the packages declared as being replaced must be mentioned by their real names.
Firstly, as mentioned before, it is usually an error for a package to contains files which are on the system in another package, though currently the --force-overwrite flag is enabled by default, downgrading the error to a warning,
If the overwriting package declares that it replaces the one containing the
file being overwritten then dpkg
will proceed, and replace the
file from the old package with that from the new. The file will no longer be
listed as `owned' by the old package.
If a package is completely replaced in this way, so that dpkg
does
not know of any files it still contains, it is considered to have disappeared.
It will be marked as not wanted on the system (selected for removal) and not
installed. Any conffiles details noted in the package will be ignored, as they
will have been taken over by the replacing package(s). The package's
postrm
script will be run to allow the package to do any final
cleanup required. See Summary of ways maintainer
scripts are called, Section 6.2.
In the future dpkg
will discard files which overwrite those from
another package which declares that it replaces the one being installed (so
that you can install an older version of a package without problems).
This usage of Replaces only takes effect when both packages are at least partially on the system at once, so that it can only happen if they do not conflict or if the conflict has been overridden.
Secondly, Replaces allows dpkg
and
dselect
to resolve which package should be removed when there is a
conflict - see Alternative binary
packages - Conflicts and Replaces, Section 8.3.
This usage only takes effect when the two packages do conflict, so
that the two effects do not interfere with each other.
Ordering is significant in dependency fields.
Usually dselect will suggest to the user that they select the package with the most `fundamental' class (eg, it will prefer Base packages to Optional ones), or the one that they `most wanted' to select in some sense.
In the absence of other information dselect
will offer a default
selection of the first named package in a list of alternatives.
However, there is no way to specify the `order' of several packages which all provide the same thing, when that thing is listed as a dependency.
Therefore a dependency on a virtual package should contain a concrete package name as the first alternative, so that this is the default.
For example, consider the set of packages:
Package: glibcdoc Recommends: info-browser Package: info Provides: info-browser Package: emacs Provides: info-browser
If emacs
and info
both have the same priority then
dselect
's choice is essentially random. Better would be
Package: glibcdoc Recommends: info | info-browser
so that dselect
defaults to selecting the lightweight standalone
info browser.
A source package may declare a dependency or a conflict on a binary package. This is done with the control file fields Build-Depends, Build-Depends-Indep, Build-Conflicts, and Build-Conflicts-Indep. Their semantics is that the dependencies and conflicts they define must be satisfied (as defined earlier for binary packages), when one of the targets in debian/rules that the particular field applies to is invoked.
ijackson@gnu.ai.mit.edu
bweaver@debian.org
schwarz@debian.org
srivasta@debian.org
debian-policy@lists.debian.org