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:
> > 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?
I thought this was in the policy manual/packaging manual/developers
reference somewhere, but I can't find a reference right now.
> 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.
This is quite common. For example, a package providing an equivalent
replacement for some existing package might Provide that package, or when a
package's name changes but the old package remains, the new package might
Provide the old name in order to satisfy old dependencies.
> 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.
Is it certain that none of the rsh-like alternatives will work here? Why?
If you are absolutely certain that ssh (for example) will not work at all,
then you can guarantee that you will get the real package by specifying a
versioned dependency, though this is not terribly elegant and may break in
the future if versioned Provides are implemented.
--
- mdz
Reply to: