dpkg (1.2.8); priority=LOW
[dpkg.git] / doc / virtual-dependencies.txt
blob1f45eb7a0c742538021f2c6e7bc2521b5f8dc704
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).
20 [...]
21 --------------------
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
33 away.
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
44 package.
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:
50  Package: elm
51  Depends: mta
53  Package: smail
54  Provides: mta
55  Conflicts: mta
57  Package: sendmail
58  Provides: mta
59  Conflicts: mta
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
70  Package: lout
71  Optional: ghostview
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
76  Provides: ghostview
77 and all will work in the interim (until, say, the Lout maintainer
78 changes things).
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.
86   Provides: mta (2.0)
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
92 one.  E.g.:
93  Package: xbaseR6
94  Recommended: xsvga | x-server
95  Provides: x-base, xr6shlib
97  Package: xsvga
98  Recommended: x-base
99  Provides: x-server
101  Package: x8514
102  Recommended: x-base
103  Provides: x-server
105 Ian.