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