Red Hat Bugzilla – Full Text Bug Listing
|Summary:||prevent multilib file conflicts, abandon RPM file colour hack.|
|Product:||[Fedora] Fedora||Reporter:||David Woodhouse <dwmw2>|
|Component:||anaconda||Assignee:||Peter Jones <pjones>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Version:||9||CC:||braden, dcantrell, hdegoede, herrold, jwboyer, pertusus, pnasrat, tcallawa, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-08-06 17:36:11 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||171279|
|Bug Blocks:||235704, 235752|
Description David Woodhouse 2007-04-09 18:56:43 EDT
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'.
Comment 1 Jeff Johnson 2007-04-24 20:30:15 EDT
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)
Comment 2 David Woodhouse 2007-04-27 02:56:30 EDT
(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?
Comment 3 David Woodhouse 2007-04-27 03:01:00 EDT
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.
Comment 4 Jeff Johnson 2007-04-27 06:51:23 EDT
Compilers resort to a "standard" to implicitly define unexpected behavior, rpm has only conflicting expectations with buggy data. Off to examine the patch ...
Comment 5 Jeff Johnson 2007-04-27 06:56:45 EDT
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.
Comment 6 David Woodhouse 2007-04-27 07:06:13 EDT
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.
Comment 7 Jeff Johnson 2007-04-27 07:13:30 EDT
Yep, my mistake.
Comment 11 David Woodhouse 2007-04-27 19:37:52 EDT
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.
Comment 12 Josh Boyer 2007-04-30 08:24:39 EDT
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 firstname.lastname@example.org 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
Comment 13 Bill Nottingham 2007-05-01 00:45:02 EDT
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.
Comment 14 David Woodhouse 2007-05-01 02:13:53 EDT
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?
Comment 15 David Woodhouse 2007-05-03 04:44:31 EDT
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.
Comment 16 Will Woods 2007-05-11 17:06:07 EDT
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?
Comment 17 David Woodhouse 2007-05-12 01:04:52 EDT
No, we still need anaconda to set _prefer_color 1 in /etc/rpm/macros on upgrades.
Comment 18 Paul Nasrat 2007-05-14 05:58:13 EDT
Commited a fix for upgrades
Comment 19 David Woodhouse 2007-06-07 10:31:58 EDT
Reopening and setting summary back to the original bug rather than the short-term workaround for F7.
Comment 20 Red Hat Bugzilla 2007-08-21 01:33:33 EDT
User email@example.com's account has been closed
Comment 21 Bug Zapper 2008-04-03 20:00:57 EDT
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.
Comment 22 Bug Zapper 2008-05-06 21:27:22 EDT
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
Comment 23 Patrice Dumas 2008-05-11 18:40:48 EDT
Can somebody confirm or infirm that it is closed?
Comment 24 Bug Zapper 2008-05-13 22:45:23 EDT
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
Comment 26 Andy Lindeberg 2008-08-06 17:36:11 EDT
If this is still a problem in F9, please refile as a different bug.