Software Management call for RFEs

[Kalev Lember]

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