Bug 460777 - RFE: make yum _bestPackageFRomList use compare_providers()
RFE: make yum _bestPackageFRomList use compare_providers()
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-31 14:37 EDT by Ville Skyttä
Modified: 2014-01-21 18:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-21 16:42:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Prefer arch over package name length in _bestPackageFromList() (4.01 KB, patch)
2008-08-31 14:37 EDT, Ville Skyttä
no flags Details | Diff
getBestArchFromList() micro-optimization (938 bytes, patch)
2008-08-31 14:39 EDT, Ville Skyttä
no flags Details | Diff
Use _compare_providers in _bestPackageFromList (2.28 KB, patch)
2008-09-20 07:13 EDT, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2008-08-31 14:37:24 EDT
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.
Comment 1 Ville Skyttä 2008-08-31 14:39:28 EDT
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 :)
Comment 2 seth vidal 2008-08-31 15:21:53 EDT
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
Comment 3 Ville Skyttä 2008-08-31 15:57:31 EDT
(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.
Comment 4 James Antill 2008-08-31 17:55:09 EDT
> 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?
Comment 5 Ville Skyttä 2008-09-01 12:48:56 EDT
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.
Comment 6 Ville Skyttä 2008-09-15 16:16:43 EDT
(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.
Comment 7 seth vidal 2008-09-18 11:13:45 EDT
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?
Comment 8 Ville Skyttä 2008-09-20 07:13:58 EDT
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.
Comment 9 Bug Zapper 2008-11-25 21:54:54 EST
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
Comment 10 seth vidal 2009-01-21 16:42:09 EST
applied upstream. Thank you.
Comment 11 Ville Skyttä 2009-02-06 18:00:20 EST
(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!

Note You need to log in before you can comment on or make changes to this bug.