Re: virtual-package-depends-without-real-package-depends rsh-client
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
Reply to: