To: Debian users list 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.