dpkg/doc/dependency-ordering.txt

To: Debian developers list <debian-devel@pixar.com>
Subject: Note about the default for virtal package dependencies

As I wrote some time ago (see below), ordering is significant in the
Depends and Recommended fields - in the absence of other information
dselect will suggest to the user that they select the first named
package in a list of options.

However, there is no way to specify the `order' of several packages
which all Provide the same thing, when that thing is listed as a
Dependency.

Eg, if we have:
 Package: glibcdoc
 Recommended: info-browser

 Package: info
 Provides: info-browser

 Package: emacs
 Provides: info-browser

then (if emacs and info are both in the same Class) dselect's choice
will be essentially random.

It is important to think about this problem, and to consider whether
to list one the the packages explicitly.

For example,
 Package: glibcdoc
 Recommended: info | info-browser

will do the same as the above, except that it will ensure that `info'
is the package which dselect will suggest to the user they also select
if the user has neither it nor Emacs and asks to select glibcdoc.

This is not necessary if one of the packages has a more fundamental
Class - see the details below.

Ian.

------- Start of forwarded message -------
To: Debian developers list <debian-devel@pixar.com>
Subject: Ordering is significant in Depends: and Recommends:

For dselect, the ordering of alternative packages in a Depends: or
Recommended: line is significant.

When an unsatisfied dependency (Depends or Recommended) or a conflict
is detected dselect will go into a `recursive package list', where the
user gets to choose how to resolve the problem.

Usually dselect will suggest to the user that they select the package
with the most `fundamental' class (eg, it will prefer Base packages to
Optional ones), or the one that they `most wanted' to select in some
sense.

However, in the absence of other information dselect will prefer
packages listed earlier in the unsatisfied entry in the Depends or
Recommended field.

NB: this doesn't apply to constructions of the form:
 Package: auctex
 Depends: emacs, tex
which specifies that auctex depends on *both* emacs and tex.  In this
case dselect will suggest to the user that they select both packages.

It applies to constructions of the form:
 Package: a2gs
 Recommended: gs_x | gs_both | gs_svga
Here, dselect will prefer gs_x because it is listed earlier.  (In the
future I may make it more clever - it may be able to notice, to
continue the example, that the dependencies of gs_x are not yet
satisfied while those of gs_svga, are, and thus prefer the latter, or
in a different situation to notice that gs_both has extra dependencies
which are satisfied, and thus prefer it to gs_x and gs_svga.  More
thought is needed in this area.)

One final example.  In the more complicated construction:
 Package: trn
 Depends: smail | sendmail, inn | inewsinn
dselect will prefer smail because it is a Standard package, and
Sendmail is only Optional, and will prefer inewsinn because it is
Recommended and inn is only Optional.  So, the default (if none of the
other packages were selected) would be to select smail and inewsinn.

However, if inewsinn were moved to Optional this would change, and inn
would be preferred whenever the issue arose after the change.

Optional fields have the same structure as Depends and Recommended
fields, but they will not arrange for the packages they list to be
suggested for selection, though they will be offered to the user.

Ian M: can this go in an appendix to the Guidelines ?

Ian.
------- End of forwarded message -------