On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote: > On 16 September 2011 17:36, seth vidal <skvidal@xxxxxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
