Created attachment 315449 [details] Prefer arch over package name length in _bestPackageFromList() Scenario: x86_64 host, yum 3.2.19, repository with packages foo-1.0.i386 and foobar-1.0.x86_64 in it, both packages provide bar. "yum install bar" results in foo-1.0.i386 installed because package name length takes precedence over arch goodness. I think this is backwards; fix against yum-3_2_X branch along with some more or less useful, quick and dirty test cases is attached.
Created attachment 315450 [details] getBestArchFromList() micro-optimization This one's semi-unrelated, but I thought I'd post it here as I came across it when looking into the real reported issue. Sorry :)
Implementing the first patch changes existing behavior, imo, negatively. If you want to implement that patch correctly you can make bestPackageFromList() talk to YumBase._compare_providers() from depsolve.py
(In reply to comment #2) > Implementing the first patch changes existing behavior, imo, negatively. Could you elaborate? I tried to construct it so that it only fixes the thing I think is a bug and would have no other side effects. If the existing behavior must not change so that arch takes precedence over package name length, would it matter at all how the patch was internally implemented (see your note below)? > If you want to implement that patch correctly you can make > bestPackageFromList() talk to YumBase._compare_providers() from depsolve.py I thought about that, but also apparently incorrectly thought that _compare_providers() always needs a reqpo and as I'm not aware of any fake package functionality in yum itself (there's some in the test suite), didn't explore that further. I'll look into revising the patch if I get an ack that having arch take precedence over package name length is indeed desirable and a better patch to do that would be accepted.
> Scenario: x86_64 host, yum 3.2.19, repository with packages > foo-1.0.i386 and foobar-1.0.x86_64 Can you give a real example where foo would _only_ have a .i386 package in an .x86_64 repo?
Some examples I've encountered, off the top of my head: The package might not be available as anything else but i386 for many reasons (proprietary only built for i386, does not build on x86_64, noarch-like subpackage of an i386 build where x86_64 might add no real value, etc). And it does not have to be an x86_64 repo or a single repo in the first place, one may very well want to use an i386 repo where foo is (which may be available as i386 only) on x86_64 among other x86_64 ones. Or a small combined repo for i386 and x86_64 where it adds no value to setup one for each.
(In reply to comment #3) > (In reply to comment #2) > > Implementing the first patch changes existing behavior, imo, negatively. > > Could you elaborate? I tried to construct it so that it only fixes the thing I > think is a bug and would have no other side effects. [...] > I'll look into revising the patch if I get an ack that having arch take > precedence over package name length is indeed desirable and a better patch to > do that would be accepted. Seth, James, could you reply to the questions above? I still can't come up with a reason or a scenario where it would be good to prefer shorter package name over a better arch.
Ville, If you can provide some pkgs/examples which test this here's what I'd like to do: 1. test it with compare_providers b/c even w/o a reqpo it should be doing roughly the right thing. 2. patch bestPackagesFromList() to use compare_providers instead of doing its own thing. Does that make sense to everyone?
Created attachment 317285 [details] Use _compare_providers in _bestPackageFromList Sure, works for me. Test repo @ http://scop.fedorapeople.org/tmp/, test case: "yum resolvedep bar" on x86_64 -> should return 0:quux-1.0-1.x86_64, but returns 0:foo-1.0-1.i386. The attached patch makes _bestPackageFromList use _compare_providers but it does not help (applied on top of yum-3.2.19-3.fc9.noarch) so perhaps _compare_providers() needs some work as well. Note that the attached patch does not update the _bestPackageFromList docstring, I suppose the multilib comment in it is no longer accurate, but I'll leave updating it to someone else who knows the specifics.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
applied upstream. Thank you.
(In reply to comment #8) > Test repo @ http://scop.fedorapeople.org/tmp/, test case: > "yum resolvedep bar" on x86_64 -> should return 0:quux-1.0-1.x86_64, but > returns 0:foo-1.0-1.i386. Ahh, http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=05b3273e5910a19692fc39edff71780431471f94 fixes this one. Thanks!