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-Depends-Arch, Build-Conflicts, Build-Conflicts-Indep and Build-Conflicts-Arch 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)

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

Package: foo
Depends: bar

and someone else releases an enhanced version of the bar package they can say:

Package: bar-plus
Provides: bar

and the bar-plus package will now also satisfy the dependency for the foo package.

A Provides field may contain version numbers, and such a version number will be considered when considering a dependency on or conflict with the virtual package name. For example, given the following packages:

Package: foo
Depends: bar (>= 1.0)
Package: bar
Version: 0.9
Package: bar-plus
Provides: bar (= 1.0)

the bar-plus package will satisfy the dependency for the foo package with the virtual package name, as above. If the Provides field does not specify a version number, it will not satisfy versioned dependencies or violate versioned Conflicts or Breaks. For example, given the following packages:

Package: foo
Depends: bar (>= 1.0)
Package: bar
Version: 0.9
Package: bar-plus
Provides: bar (= 1.0)
Package: bar-clone
Provides: bar

the bar-plus package will satisfy the dependency for the foo package, but the bar-clone package will not.

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), 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.