To: Debian users list <debian-user@pixar.com>
Subject: dpkg 0.93.36: dselect does virtual packages

This release contains virtual package support in the C parts of the
system, which at the moment includes dselect and dpkg-deb.

It works as I outlined in a mail to debian-devel a little while ago.

Package maintainers: please start adding `Provides:' fields to your
packages.  dselect will use and understand them; dpkg-deb will check
the syntax of the Provides field instead of warning you about it.
dpkg will not understand the new field and will ignore it.

When almost all the packages have Provides: fields in place we can
start replacing old-style Recommended: fields.

Note that we can't change Depends: fields since they're also
interpreted by dpkg, which doesn't know about Provides (yet).

[...]
--------------------

From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: `virtual' packages in Depends, Conflicts &c
Date: Fri, 31 Mar 95 15:44 BST

We're starting to have a problem with package name changes and
multiple packages providing the same service.

I liked the idea (put forward by [Bruce Perens]) of having `virtual'
packages; it seems that it would solve many of these problems straight
away.

What I'm proposing to do is as follows:

Depends, Conflicts, Recommended and Optional lines will now be able to
contain `virtual' package names as well as real package names.

Virtual packages are in the same namespace as real packages, and may
have the same name.  The meaning of a virtual package in a
dependency/conflicts list is exactly that of listing all the real
packages which state that they are an instantiation of that virtual
package.

This is done with a new Provides field in the control file, with a
syntax much like the Conflicts field.

The idea is that we can have something like:
 Package: elm
 Depends: mta

 Package: smail
 Provides: mta
 Conflicts: mta

 Package: sendmail
 Provides: mta
 Conflicts: mta
&c.  The result is equivalent to elm having said
 Depends: smail | sendmail

(There'll be a special case to say that a package may conflict with a
virtual package which it provides - clearly ...)

If there are both a real and a virtual package of the same name then
the dependency may be satisfied (or the conflict caused) by either the
real package or any of the virtual packages which provide it.  This is
so that, for example, supposing we have
 Package: lout
 Optional: ghostview
(this is a fictional example - the Lout package shouldn't mention
ghostview), and someone else comes up with a nice PostScript
previewer, then they can just say
 Package: marvelpostview
 Provides: ghostview
and all will work in the interim (until, say, the Lout maintainer
changes things).

If a dependency or a conflict has a version number attached then only
real packages will be considered to see whether the relationship is
satisfied (or prohibited, for a conflict) - it is assumed that a real
package which provides virtual package is not of the `right' version.
If there is demand I could arrange that a package which provides a
virtual package may mention a version number, eg.
  Provides: mta (2.0)
though I tbink this is unlikely to be helpful.

If you want to specify which of a set of real packages should be the
default to satisfy a particular dependency on a virtual package, you
can simply list the real package as alternative before the virtual
one.  E.g.:
 Package: xbaseR6
 Recommended: xsvga | x-server
 Provides: x-base, xr6shlib

 Package: xsvga
 Recommended: x-base
 Provides: x-server

 Package: x8514
 Recommended: x-base
 Provides: x-server

Ian.
