Virtual packages

Virtual packages

Next to the usual packages, DEB also has the notion of virtual packages. These packages do not physically exist, but they can be used in dependencies; a dependency on a virtual package can be fulfilled by any package that provides te virtual package.

For example, suppose that a package A needs a web server to run, but it doesn't matter which particular web server. In that case, one could declare package A to depend on a virtual package webserver.

Then, in order to specify which packages can fulfill the webserver dependency, all web server packages (apache, ...) can be declared to provide the webserver package.

Virtual packages do not have versions (though the packages providing them, of course, do); according to the Debian Policy Manual, though, the possibility may be added in future versions of the DEB format.

DEB package format

A DEB package is an ar(1) archive, which contains the following files:

• debian-binary
• control.tar.gz (the metadata)
• data.tar.gz (the package data)

The metadata is contained in the control.tar.gz file; this file contains all sorts of data on the package (MD5 sums of the files, pre- and postinstall scripts, ...), but most importantly it contains the file control (hereafter called the control file), which contains the package metadata.

Debian also knows pool files, which are concatenations of control files.

A control file is a text file, which contains fields (usually one per line, though multi-line fields are also possible).

Important fields are:

• Package: the package name
• Version: the package version
• Architecture: this package runs on a specific architecture
• Depends: run-time dependencies (dependencies that are needed to run the package)
• Pre-Depends: install-time dependencies (dependencies that are needed to install the package, for example an archiving tool)
• Conflicts: conflicting dependencies
• Provides: this package can fulfill a virtual dependency.
• Replaces: this package replaces another version.

There are other types of dependencies, such as Suggests or Recommends, but these dependencies are, as their names already suggest, optional (if there is a Suggests dependency, it does not have to be fulfilled for the package to be installed).

A run-time or an install-time dependency consists of a list of alternatives, where an alternative is a list of (virtual) package names, with versions. For example: Depends: A (>> 2.63), B (= 2.4) | C (>= 5.99a), D (<< 0.27-beta), E means that, in order for the dependency to be fulfilled, the following conditions must be met:

• Package A must be installed with a version strictly greater than 2.63
• Either package B (version 2.4) or package B (version greater than or equal to 5.99a) must be installed
• Package C (version strictly less than 0.27-beta) must be installed.
• Package E must be installed, in any version (or perhaps E is a virtual package)

So, for every alternatives, at least one of its options must be satisfied.

Example: ocaml

Here is the control file of the ocaml package (version 3.08.3-3 for i386):

Package: ocaml
Version: 3.08.3-3
Section: devel
Priority: optional
Architecture: i386
Depends: ocaml-base (= 3.08.3-3), ocaml-base-3.08.3, ocaml-nox-3.08.3
Suggests: xlibs-dev, tcl8.4-dev, tk8.4-dev
Provides: ocaml-3.08.3
Installed-Size: 6940
Maintainer: Sven Luther 
Description: ML language implementation with a class-based object system
 Objective Caml is an implementation of the ML language, based on
 the Caml Light dialect extended with a complete class-based object system
 and a powerful module system in the style of Standard ML.
 .
 Objective Caml comprises two compilers. One generates bytecode
 which is then interpreted by a C program. This compiler runs quickly,
 generates compact code with moderate memory requirements, and is
 portable to essentially any 32 or 64 bit Unix platform. Performance of
 generated programs is quite good for a bytecoded implementation:
 almost twice as fast as Caml Light 0.7. This compiler can be used
 either as a standalone, batch-oriented compiler that produces
 standalone programs, or as an interactive, toplevel-based system.
 .
 The other compiler generates high-performance native code for a number
 of processors. Compilation takes longer and generates bigger code, but
 the generated programs deliver excellent performance, while retaining
 the moderate memory requirements of the bytecode compiler. It is not
 available on all arches though.
 .
 This package contains everything needed to develop ocaml applications,
 including the graphics libraries.

We see that this package is named ocaml, it has version 3.08.3-3, it is meant for the i386 architecture, and it depends on three packages: ocaml-base (version 3.08.3-3), ocaml-base-3.08.3 and ocaml-nox-3.08.3.

Furthermore, it provides the virtual package ocaml-3.08.3.

The APT tool

The APT tool is written in C++ and uses an ad-hoc, backtracking algorithm for finding an installation recipe. This algorithm, altough it is fast, is incomplete and incorrect. Also, the maintainers assume APT works in a particular way and give hints in the dependency information, for helping APT solve the dependencies, and also for prioritizing packages.

• apt-get install abiword-gnome=2.2.7-3 fails, but abiword-gnome=2.2.7-3 is installable
• apt-get install abiword-gnome=2.2.7-3 abiword-common=2.2.7-3 succeeds, installing libaspell15c2
• apt-get install abiword-common=2.2.7-3 abiword-gnome=2.2.7-3 succeeds, but does not deem necessary to install libaspell15c2.