Re: Software Management call for RFEs
2013-05-23 00:30, Richard W.M. Jones skrev:
On Wed, May 22, 2013 at 03:52:22PM -0600, Orion Poplawski wrote:
> Something I'm just now running into - I have a package that can make
> use of one of two different backends, but it definitely needs one of
> them. I don't want to pick which one in the package. Also, it is
> explicitly referencing specific implementations, not a generic
> interface, so a generic Provides in the backend packages is not
> appropriate. But something like:
>
> Requires: ( pkgA || pkgB )
>
> might do the trick.
FWIW dpkg can express this kind of dependency, eg:
Depends: exim | mail-transport-agent
[from: http://www.debian.org/doc/debian-policy/ch-relationships.html]
If I remember this right, Debian's implementation uses the
short-circuiting OR operator. This makes it possible to express
dependencies with an order of preference. For instance, with the example
from above:
Depends: exim | mail-transport-agent
(note that exim has virtual 'mail-transport-agent' provides)
If no mail-transport-agent is installed, it drags in exim; otherwise it
is happy with any package that has virtual mail-transport-agent provides.
This is a case that is not possible to solely express with rpm's virtual
provides.
If implemented, this would have implications for Fedora. You could
have two people who have installed the same package, with a very
different set of dependent packages, leading to some sort of
combinatorial explosion of QA.
yum's depsolver already has some logic that resolves Provides
differently depending on what packages are already installed, which
makes it highly unpredictable. I don't think QA would get any harder if
we get the ability to explicitly express this in the spec files.
From http://yum.baseurl.org/wiki/CompareProviders :
1) Candidates from the same srpm as the requiring package are
preferred
2) Candidates with names that start the same as the requiring package
are favored
3a) Candidates with the same (or similar) arch as the requiring
package have more pull than those with a less similar arch
3b) Candidates with the same (or similar) arch as the system have
more pulls than those with a less similar arch
3c) Candidates with close relationships to the already installed
system (and transaction/requestor) have more pull than those that
would require more changes to the installed system
4) In the event of a tie, candidates with very long names will lose
the tie
5) In the event they are still tied, they are sorted alphabetically
and "highest" wins (zpkg is picked over apkg).
--
Kalev