how to have yum prefer one dependency over others

[seth vidal]

On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote:
> On 16 September 2011 17:36, seth vidal <skvidal at fedoraproject.org> wrote:
> > Here is how yum does comparison between multiple package providing the
> > same thing:
> > http://yum.baseurl.org/wiki/CompareProviders
> 
> I don't think that works for all cases; surely "grid-certificates = 2"
> wins over "grid-certificates = 1" in all cases? It's certainly better
> than relying on the length of the package name or alphabetical
> ordering...

Which, if you read, yum doesn't do exclusively.

Here's what yum does.
0. each pkg starts out with a score of 0.

1. if any of the providers is a newer version of something we have
installed then increase their score by 5

2. if any of the providers are not the newest version of themselves then
decrease their score by 1024.

3. if any of the providers are obsoleted by another provider, decrease
that provider by 1024.

4. check the arch distance between the requiring pkg and each of the
providers. The pkg with the smallest arch distance gets a 5 added to
their score. Do the same check but comparing the pkg arch distance to
the system arch, not the requiring pkg arch

5. compare the sourcerpm on each provider to the requiring pkg's source
rpm. If they share a sourcerpm add 20 to the score

6. check the base pkg for each subpkg. If the base pkg is installed on
the system add 5 to the provider's score.

7. check the prefix of the pkg to the requiring pkg prefix (perl-foo and
perl-lib) for each common character in the prefix add 2 points to the
provider's score.

8. if, at this point, we have pkgs with an equal score - look at the
deplist (one layer deep) and see what they would pull in that is NOT
already installed. Add 1 to the score of the pkg with the least new deps
to be pulled in.

9. if all else fails and we STILL have two pkgs with the same score -
take the leaders from the list and compare their name length. We add
1,000 and then subtract the length of the number of character's in the
pkgs name from its score (the addition of 1000 is to ensure that one of
the leaders will be picked).

10. return the list of providers, sorted best to worst.

11. if the packages are the same length, then the packages are compared
as shown in "yum list". The one lower in the list will win.

> 
> In Zif, I'm doing something like:
> 
> * Filter by best arch
> * Filter by depend version
> * Filter by native arch
> * Filter by smallest name
> * Filter by newest

So you fail to take shortest number of deps and you're going to
generally fail for a any number of pkgs which really need a
closely-related sibling package but something else outside of their srpm
also provides what they need.

That happens a lot in the kde/gnome world and with many of the languages
with a large number of modules. (python, perl, etc)

Yum's depsolving and provider comparison is significantly more mature
and works in actual uses not just theoretically. 

That you've implemented a depsolver for use with PK that does not match
yum nor anaconda is pretty bad. You've chosen intentional
incompatibility. That's neither helpful nor really embodying the goals I
like to think of in fedora.


> non-native architecture packages onto their system for an update and
> want to follow the latest provide version (even if that means
> installing additional deps). The current logic where yum wants to
> install a hundred i686 packages on my x86_64 box when the repos get a
> bit screwy doesn't seem to work very well in my opinion.

There are still a largish number of packages out there that have things
like:

Requires: foo

where they really want:
Requires: foo(64bit)

Which causes the other path you're describing.

It's sad that you've chosen to implement something else entirely on your
own rather than working with the growing number of people working on
yum.

-sv