3.6 Virtual packages
Sometimes, there are several packages which offer more-or-less the same functionality. In this case, it's useful to define a virtual package whose name describes that common functionality. (The virtual packages only exist logically, not physically; that's why they are called virtual.) The packages with this particular function will then provide the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually.
All packages should use virtual package names where appropriate, and arrange to create new ones if necessary. They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. (See also Virtual packages - Provides, Section 7.5)
The latest version of the authoritative list of virtual package names can be found in the debian-policy package. It is also available from the Debian web mirrors at /doc/packaging-manuals/virtual-package-names-list.txt.
The procedure for updating the list is described in the preface to the list.
7.5 Virtual packages - Provides
As well as the names of actual ("concrete") packages, the package relationship fields Depends, Recommends, Suggests, Enhances, Pre-Depends, Breaks, Conflicts, Build-Depends, Build-Depends-Indep, Build-Conflicts and Build-Conflicts-Indep may mention "virtual packages".
A virtual package is one which appears in the Provides control 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. (See also Virtual packages, Section 3.6)
If there are both concrete and virtual packages of the same name, then the dependency may be satisfied (or the conflict caused) by either the concrete package with the name in question or any other concrete package which provides the virtual package with the name in question. This is so that, for example, supposing we have
and someone else releases an enhanced version of the bar package they can say:
and the bar-plus package will now also satisfy the dependency for the foo package.
If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. The package manager will assume that a package providing that virtual package is not of the "right" version. 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 considered when considering a dependency on or conflict with the virtual package name.
To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one.
If the virtual package represents a facility that can only be provided by one real package at a time, such as the mail-transport-agent virtual package that requires installation of a binary that would conflict with all other providers of that virtual package (see Mail transport, delivery and user agents, Section 11.6), all packages providing that virtual package should also declare a conflict with it using Conflicts. This will ensure that at most one provider of that virtual package is unpacked or installed at a time.
http://www.debian.org/doc/debian-policy ... ships.html