>>>>> "Michael" == Michael Meskes <[EMAIL PROTECTED]> writes:
Michael> On Wed, Oct 07, 1998 at 12:32:32PM -0700, Ben Gertzfield Michael> wrote: Ben> I'm pretty sure policy states that a package cannot depend Ben> wholly on a virtual package; it has to depend on a real, Ben> preferred package, *or* the virtual package, like so:; Ben> Ben> Depends: jds1.1 | jdk1.1-runtime (that should be jdk1.1, not jds of course.) Michael> So should I submit bug reports against these packages? Yes. Here's the relevant part of policy you should cite: 8.6 Defaults for satisfying dependencies - ordering Ordering is significant in dependency fields. 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. In the absence of other information dselect will offer a default selection of the first named package in a list of alternatives. 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. Therefore a dependency on a virtual package should contain a concrete package name as the first alternative, so that this is the default. For example, consider the set of packages: Package: glibcdoc Recommends: info-browser Package: info Provides: info-browser Package: emacs Provides: info-browser If emacs and info both have the same priority then dselect's choice is essentially random. Better would be Package: glibcdoc Recommends: info | info-browser so that dselect defaults to selecting the lightweight standalone info browser. Ben -- Brought to you by the letters F and T and the number 4. "If it wasn't for disappointment, I wouldn't have any appointment." -- TMBG Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.