[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Sven Luther

Reply to: