Dependencies: the Depends Field
The package dependencies are defined in the Depends field in the package header. This is a list of
conditions to be met for the package to work correctly—this information is used by tools such as
apt
in order to install the required libraries, in appropriate versions fulfilling the dependencies of
the package to be installed. For each dependency, you can restrict the range of versions that meet
that condition. In other words, it is possible to express the fact that you need the package libc6
212
Kali Linux Revealed
in a version equal to or greater than “2.15” (written “
libc6 (>= 2.15)
”). Version comparison
operators are as follows:
•
<<
: less than;
•
<=
: less than or equal to;
•
=
: equal to (note that “2.6.1” is not equal to “2.6.1-1”);
•
>=
: greater than or equal to;
•
>>
: greater than.
In a list of conditions to be met, the comma serves as a separator, interpreted as a logical “AND.”
In conditions, the vertical bar (“|”) expresses a logical “OR” (it is an inclusive “OR,” not an exclu-
sive “either/or”). Carrying greater priority than “AND,” you can use it as many times as necessary.
Thus, the dependency “(A OR B) AND C” is written
A | B, C
. In contrast, the expression “A OR (B
AND C)” should be written as “(A OR B) AND (A OR C)”, since the Depends field does not tolerate
parentheses that change the order of priorities between the logical operators “OR” and “AND”.
It would thus be written
A | B, A | C
. See
https://www.debian.org/doc/debian-policy/
ch-relationships.html
for more information.
The dependencies system is a good mechanism for guaranteeing the operation of a program but it
has another use with metapackages. These are empty packages that only describe dependencies.
They facilitate the installation of a consistent group of programs preselected by the metapackage
maintainer; as such,
apt install metapackage
will automatically install all of these programs
using the metapackage’s dependencies. The gnome, kali-tools-wireless, and kali-linux-large packages
are examples of metapackages. For more information on Kali’s metapackages, see
https://tools.
kali.org/kali-metapackages
Pre-Depends, a More Demanding Depends
Pre-dependencies, which are listed in the Pre-Depends field in the package headers, complete the
normal dependencies; their syntax is identical. A normal dependency indicates that the pack-
age in question must be unpacked and configured before configuration of the package declaring
the dependency. A pre-dependency stipulates that the package in question must be unpacked
and configured before execution of the pre-installation script of the package declaring the pre-
dependency, that is before its installation.
A pre-dependency is very demanding for
apt
because it adds a strict constraint on the ordering of
the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It
is even recommended to consult other developers on
debian-devel@lists.debian.org
before adding
a pre-dependency as it is generally possible to find another solution as a work-around.
213
Chapter 8 — Debian Package Management
Recommends, Suggests, and Enhances Fields
The Recommends and Suggests fields describe dependencies that are not compulsory. The rec-
ommended dependencies, the most important, considerably improve the functionality offered by
the package but are not indispensable to its operation. The suggested dependencies, of secondary
importance, indicate that certain packages may complement and increase their respective utility,
but it is perfectly reasonable to install one without the others.
You should always install the recommended packages unless you know exactly why you do not
need them. Conversely, it is not necessary to install suggested packages unless you know why you
need them.
The Enhances field also describes a suggestion, but in a different context. It is indeed located in
the suggested package, and not in the package that benefits from the suggestion. Its interest lies
in that it is possible to add a suggestion without having to modify the package that is concerned.
Thus, all add-ons, plug-ins, and other extensions of a program can then appear in the list of sug-
gestions related to the software. Although it has existed for several years, this last field is still
largely ignored by programs such as
apt
or
synaptic
. The original goal was to let a package like
xul-ext-adblock-plus (a Firefox extension) declare Enhances: firefox, firefox-esr and thus appear in
the list of suggested packages associated to firefox and firefox-esr.
Conflicts: the Conflicts Field
The Conflicts field indicates when a package cannot be installed simultaneously with another. The
most common reasons for this are that both packages include a file of the same name, provide the
same service on the same transmission control protocol (TCP) port, or would hinder each other’s
operation.
If it triggers a conflict with an already installed package,
dpkg
will refuse to install a package,
except if the new package specifies that it will replace the installed package, in which case
dpkg
will choose to replace the old package with the new one. APT always follows your instructions: if
you choose to install a new package, it will automatically offer to uninstall the package that poses
a problem.
Incompatibilities: the Breaks Field
The Breaks field has an effect similar to that of the Conflicts field, but with a special meaning. It
signals that the installation of a package will break another package (or particular versions of it).
In general, this incompatibility between two packages is transitory and the Breaks relationship
specifically refers to the incompatible versions.
214
Kali Linux Revealed
When a package breaks an already installed package,
dpkg
will refuse to install it, and
apt
will try
to resolve the problem by updating the package that would be broken to a newer version (which
is assumed to be fixed and, thus, compatible again).
This type of situation may occur in the case of updates without backwards compatibility: this is
the case if the new version no longer functions with the older version and causes a malfunction in
another program without making special provisions. The Breaks field helps prevent these types
of problems.
Provided Items: the Provides Field
This field introduces the very interesting concept of a virtual package. It has many roles, but two are
of particular importance. The first role consists in using a virtual package to associate a generic
service with it (the package provides the service). The second indicates that a package completely
replaces another and that for this purpose, it can also satisfy the dependencies that the other
would satisfy. It is thus possible to create a substitution package without having to use the same
package name.
|
