On Sun, Feb 09, 2003 at 10:36:03AM -0700, Bob Proulx wrote: > Matt Zimmerman wrote: > > > Why does it think rsh-client is a virtual package? > > > > It is a mixed virtual package. There is a real package rsh-client, but also > > several other packages provide rsh-client (apt-cache showpkg rsh-client). > > Aha! Interesting. Since I *knew* that rsh-client was a real package > I never even considered that other packages would provide it as a > virtual package. I never even looked. > > > This may be a false positive, since you should not need an alternative for > > mixed virtual packages. > > Policy Manual section "2.3.5 Virtual packages" says nothing about > mixed virtual packages. Googling around I find reference to the > Debian Packaging Manual http://www.debian.org/doc/devel-manuals#devref > which is no longer available as such. Is there any place in > particular I could learn more about the details of mixed virtual > packages? > > Having both real and virtual packages seems to create a dilemma for > the tools. How common is this? How accepted are mixed virtual > packages? They appear to be an alternative with an infinitely high > priority. > > In this case I want the "real" rsh-client package and not one of the > virtuals such as ssh. I also have ssh installed. Therefore I do not > want to list this as "ssh | rsh-client" because that would not be the > right thing. Therefore I will declare this to be a false positive > since there is a real package rsh-client it should not create a > warning.
Well, after asking around and experimenting for myself, it seems apt and friends will select the real package over a virtual package. It would be nice if this makes it into policy though. Notice, there was thread on this some time ago here, and i even got input from the dpkg/apt folks. I use this 'feature' for my ocaml based packages, where i can generate a native code compiled package foo on the arches that support the native code compiler, and build an arch indep package foo-byte using the bytecode compiler, which provide foo. The user only need to apt-get install foo, and apt will install the native code version when it exists and fall back on the bytecode one when there is none. Maybe a more correct way to handle this, would be to associate a priority or something such to each provide ? having the real package be priority 50 for example, and other package able to provide virtual packages with other priorities, be them higher or lower. Friendly, Sven Luther
