1 To: Debian users list <debian-user@pixar.com>
2 Subject: dpkg 0.93.36: dselect does virtual packages
4 This release contains virtual package support in the C parts of the
5 system, which at the moment includes dselect and dpkg-deb.
7 It works as I outlined in a mail to debian-devel a little while ago.
9 Package maintainers: please start adding `Provides:' fields to your
10 packages. dselect will use and understand them; dpkg-deb will check
11 the syntax of the Provides field instead of warning you about it.
12 dpkg will not understand the new field and will ignore it.
14 When almost all the packages have Provides: fields in place we can
15 start replacing old-style Recommended: fields.
17 Note that we can't change Depends: fields since they're also
18 interpreted by dpkg, which doesn't know about Provides (yet).
23 From: iwj10@cus.cam.ac.uk (Ian Jackson)
24 To: debian-devel@pixar.com
25 Subject: `virtual' packages in Depends, Conflicts &c
26 Date: Fri, 31 Mar 95 15:44 BST
28 We're starting to have a problem with package name changes and
29 multiple packages providing the same service.
31 I liked the idea (put forward by [Bruce Perens]) of having `virtual'
32 packages; it seems that it would solve many of these problems straight
35 What I'm proposing to do is as follows:
37 Depends, Conflicts, Recommended and Optional lines will now be able to
38 contain `virtual' package names as well as real package names.
40 Virtual packages are in the same namespace as real packages, and may
41 have the same name. The meaning of a virtual package in a
42 dependency/conflicts list is exactly that of listing all the real
43 packages which state that they are an instantiation of that virtual
46 This is done with a new Provides field in the control file, with a
47 syntax much like the Conflicts field.
49 The idea is that we can have something like:
60 &c. The result is equivalent to elm having said
61 Depends: smail | sendmail
63 (There'll be a special case to say that a package may conflict with a
64 virtual package which it provides - clearly ...)
66 If there are both a real and a virtual package of the same name then
67 the dependency may be satisfied (or the conflict caused) by either the
68 real package or any of the virtual packages which provide it. This is
69 so that, for example, supposing we have
72 (this is a fictional example - the Lout package shouldn't mention
73 ghostview), and someone else comes up with a nice PostScript
74 previewer, then they can just say
75 Package: marvelpostview
77 and all will work in the interim (until, say, the Lout maintainer
80 If a dependency or a conflict has a version number attached then only
81 real packages will be considered to see whether the relationship is
82 satisfied (or prohibited, for a conflict) - it is assumed that a real
83 package which provides virtual package is not of the `right' version.
84 If there is demand I could arrange that a package which provides a
85 virtual package may mention a version number, eg.
87 though I tbink this is unlikely to be helpful.
89 If you want to specify which of a set of real packages should be the
90 default to satisfy a particular dependency on a virtual package, you
91 can simply list the real package as alternative before the virtual
94 Recommended: xsvga | x-server
95 Provides: x-base, xr6shlib