Better priority handling for x86_64 RPMs + option to turn off biarch support

Bug #244342 reported by Rehan Khan
2
Affects Status Importance Assigned to Milestone
Smart Package Manager
Fix Released
Undecided
Gustavo Niemeyer

Bug Description

Imported: http://tracker.labix.org/issue177

Reason for Import: Patch Review

further details: https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration

msg570 (view) Author: loki Date: 2006-06-18.22:35:59

I've written a patch that does the following things:
- use smart's own archscore() everywhere (defined in smart/backends/rpm/base.py)
instead of hard-coded rpm.archscore() calls
- add an option "rpm-enable-biarch" (on by default) that can be turned off and
which totally blocks 32bit packages on install+upgrade commands; it doesn't yet
block 32bit package completion suggestions nor results on search or query, so
this needs some more work
- a better candidate selection algorithm on x86_64 systems for RPM, explained below

The better candidate selection algorithm affects the RPMPackage.__lt__()
function (defined in smart/backends/rpm/base.py).
It gives a higher priority to x86_64 packages, as compared to 32bit ones.
The change is pretty simple: it first compares on architecture, before comparing
on versions.

The result is quite interesting though, as an install operation will only result
in installing a 32bit package (on an x86_64 system) if and only if there is
64bit package available _at all_.

For example, considering the following candidate packages that would be
available from channels:
- kdelibs3-3.5.3-7.3@x86_64
- kdelibs3-3.5.3-7.4@i586

Without the patch, "smart install kdelibs3" will pick the
"kdelibs3-3.5.3-7.4@i586" package, as it has a higher version as
"kdelibs3-3.5.3-7.3@x86_64".
In the real world, that's hardly what you'd want smart to do.
With the attached patch, smart will pick "kdelibs3-3.5.3-7.3@x86_64", even
though it has a lower version number, because it is an x86_64 package on an
x86_64 system.

By modifying the RPMPackage.__lt__() function, it will simply result in a
differont order of installation candidates when smart performs
    pkgs.sort()
    pkgs.reverse()
in sortUpgrades() (in smart/transaction.py).

Without the patch, pkgs would look like this:
[kdelibs3-3.5.3-7.4@i586, kdelibs3-3.5.3-7.3@x86_64]

With the patch, like this:
[kdelibs3-3.5.3-7.3@x86_64, kdelibs3-3.4.2-24@i586]

Would still need to double-check whether it has side-effects on other parts, but
as of now, it works for me.
Also, would need to check whether other parts of smart would need patching as
well, but the change to __lt__() seems sufficient from what I've seen up to now.

Note that the modified source currently has hard-coded references to "x86_64" at
2 or 3 places. Maybe a better implementation is possible, to also catch ppc64,
but basically that change is only needed for biarch systems.

Revision history for this message
Rehan Khan (rasker) wrote :
Revision history for this message
Rehan Khan (rasker) wrote :
Revision history for this message
Rehan Khan (rasker) wrote :

Issue 174 ( http://tracker.labix.org/issue174 ) is also related. Waiting feedback from user.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

This sounds pretty similar to bug #243972. If that's the case, the changes were already
made to Smart. Careful investigation would be good, even then.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

Yes, indeed that's addressing the same thing that was improved in
revision 797 of trunk.

Changed in smart:
assignee: nobody → niemeyer
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.