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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
