The filecolours hack was a cute trick for the first five minutes, but it's time we fixed the packaging so that we don't need it. It's complex and does the wrong thing in various places. (bug #235524, for example, and the fact that if you remove a 64-bit package leaving a 32-bit package behind, the 64-bit _files_ remain). We should make executables conflict again, and fix the packages so that if we have both executable and libraries, and we want the libraries to be available for both architures, the package in question is split into 'foo' and 'foo-libs'.
The trick is to split executables <-> libraries. The both persuasions of libraries, but one persuasuion of executables, can be installed by pkg selection. And FWIW, its not true that rpm is leaving 64bit files behind or around (see #235524)
(In reply to comment #1) > And FWIW, its not true that rpm is leaving 64bit files behind or around (see > #235524) That bug confirms the misbehaviour. Yes, you found that it's caused by a dependency loop -- but that doesn't mean it isn't a bug. I appreciate that with a compiler, "undefined behaviour" means it's allowed to beat you up and sleep with your mother -- but is that applicable to RPM too, when it sees dependency loops?
Created attachment 153582 [details] Honour %_prefer_color instead of always assuming elf64 is preferred. This isn't going to get fixed in our package set for F7, obviously. In the short term, we could at least make RPM select the _appropriate_ binaries on -- by preferring elf32 instead of elf64 where 32-bit is the "primary architecture". The attached patch allows this, and should be accompanied by a small modification to anaconda: --- iutil.py 25 Apr 2007 15:28:31 -0000 1.142 +++ iutil.py 27 Apr 2007 06:54:32 -0000 @@ -453,5 +453,7 @@ def writeRpmPlatform(root="/"): return f = open("%s/etc/rpm/macros" %(root,), 'w+') f.write("%_transaction_color 3\n") + if myarch.startswith("ppc64") or myarch == "sparc64": + f.write("%_prefer_color 1\n") f.close() Actually, it would be quite good to do that on upgrades, too.
Compilers resort to a "standard" to implicitly define unexpected behavior, rpm has only conflicting expectations with buggy data. Off to examine the patch ...
AFAICT tell (without coffee) prefer_color won't solve the "skipcolor" problem here, only choose which arch will exhibit the broken behavior. Disabling the "Always prefer ..." policy when a file is to be erased is what is needed. pref_color definitely needs to be added for other reasons. Thanks for the patch.
There is no skipcolor problem here. That was elsewhere (bug #235524). I only mentioned this patch in that context because if you set %_prefer_color to 1 you'll be able to reproduce that problem on x86_64.
Yep, my mistake.
I've performed upgrades from FC6->rawhide and installs of rawhide with this patch (and the fix for bug #233427), which is now applied to yum upstream). All seem to be working correctly, giving me binaries of the primary architecture as is right and proper. This fix should affect _only_ ppc64, and massively improves the multilib situation there (bringing it basically in line with the situation on x86_64 where the primary architecture is preferred by both yum and rpm). Marking FC7Blocker.
Bill, Paul, This seems like a sane solution for ppc64 to me. Can we get an rpm built with this patch and a request sent to rel-eng for it to get tagged for F7? Tom, Seems like sparc64 will want this too. Slightly less relevant for F7, but adding you on CC none the less
Changing summary to better describe what's being solved in this patch. I'm not against it. Bouncing back to the actual component the patch is for.
I see in CVS the anaconda change to write _prefer_color on installs; that bit of code doesn't do it on upgrades though, does it?
Reopening -- we need this for upgrades too, not just clean installs. Also, the 'prefer elf32' thing is just the short-term hack for F7; when that's done we can drop this bug from FC7Blocker but it should still remain open with its original title -- we should get rid of the colour stuff altogether, and stop asking RPM to second-guess what we wanted to install.
rpm-4.4.2-46.fc7 is tagged for f7-final, and includes: * Tue May 01 2007 Paul Nasrat <...> - 4.4.2-46 - Configurable policy for prefered ELF (#235757) David, does this mean we can move this bug from FC7Blocker to F8Blocker (and change the title) now?
No, we still need anaconda to set _prefer_color 1 in /etc/rpm/macros on upgrades.
Commited a fix for upgrades
Reopening and setting summary back to the original bug rather than the short-term workaround for F7.
User pnasrat's account has been closed
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Can somebody confirm or infirm that it is closed?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
If this is still a problem in F9, please refile as a different bug.