5.2.1.2. 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 containing the same name, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg will refuse to install a package if it triggers a conflict with an already installed package, except if the new package specifies that it will “replace” the installed packages, in which case dpkg will choose to replace the old package with the new one. apt-get always follows your instructions: if you choose to install a new package, it will automatically offer to uninstall the package that poses a problem.
5.2.1.3. 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.
dpkg will refuse to install a package that breaks an already installed package, and apt-get 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 prevents the user from running into these problems.
5.2.1.4. 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.
VOCABULARY Meta-package and virtual package
It is essential to clearly distinguish meta-packages from virtual packages. The former are real packages (including real .deb files), whose only purpose is to express dependencies.
Virtual packages, however, do not exist physically; they are only a means of identifying real packages based on common, logical criteria (service provided, compatibility with a standard program or a pre-existing package, etc.).
5.2.1.4.1. Providing a “Service”
Let us discuss the first case in greater detail with an example: all mail servers, such as postfix or sendmail are said to “provide” the mail-transport-agent virtual package. Thus, any package that needs this service to be functional (e.g. a mailing list manager, such as smartlist or sympa) simply states in its dependencies that it requires a mail-transport-agent instead of specifying a large yet incomplete list of possible solutions (e.g. postfix | sendmail | exim | …). Furthermore, it is useless to install two mail servers on the same machine, which is why each of these packages declares a conflict with the mail-transport-agent virtual package. The conflict with itself is ignored by the system, but this technique will prohibit the installation of two mail servers side by side.
DEBIAN POLICY List of virtual packages
For virtual packages to be useful, everyone must agree on their name. This is why they are standardized in the Debian Policy. The list includes among others mail-transport-agent for mail servers, c-compiler for C programming language compilers, www-browser for web browsers, httpd for web servers, ftp-server for FTP servers, x-terminal-emulator for terminal emulators in graphical mode (xterm ), and x-window-manager for window managers.
The full list can be found on the Web, at
→ http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
5.2.1.4.2. Interchangeability with Another Package
The Provides field is again interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.10 present in Squeeze). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 or 5.10. The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.
Figure 5.1. Use of a Provides field in order to not break dependencies
This feature is very useful, since it is never possible to anticipate the vagaries of development, and it is necessary to be able to adjust to renaming, and other automatic replacement, of obsolete software.
BACK TO BASICS Perl, a programming language
Perl (Practical Extraction and Report Language) is a very popular programming language. It has many ready-to-use modules that cover a vast spectrum of applications, and that are distributed by the CPAN (Comprehensive Perl Archive Network) servers, an exhaustive network of Perl packages.
→ http://www.perl.org/
→ http://www.cpan.org/
Since it is an interpreted language, a program written in Perl does not require compilation prior to execution. This is why they are called “Perl scripts”.
5.2.1.4.3. Current Limitations
Virtual packages suffer from some troubling limitations, the most significant of which being the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, will never be considered as satisfied by the packaging system — while in fact it most likely is satisfied. Unaware of this, the package system chooses the least risky option, assuming that the versions do not match.
GOING FURTHER Virtual package versions
Although today virtual packages can't have versions, this will not necessarily always be the case. Indeed, apt is already able to manage the versions of virtual packages and it is likely that dpkg eventually will too. We will then be able to write fields such as Provides: libstorable-perl (= 1.7) to indicate that a package provides the same functionality as libstorable-perl in its 1.7 version.
5.2.1.5. Replacing Files: The Replaces Field
The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails, stating that it can not overwrite the files of another package (in fact, it is possible to force it to do so with the --force-overwrite option). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.