1 files changed, 105 insertions, 0 deletions
diff --git a/doc/virtual-dependencies.txt b/doc/virtual-dependencies.txt
new file mode 100644
index 000000000..1f45eb7a0
--- /dev/null
+++ b/doc/virtual-dependencies.txt
@@ -0,0 +1,105 @@
+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.