This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 235757

Summary: prevent multilib file conflicts, abandon RPM file colour hack.
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: anacondaAssignee: Peter Jones <pjones>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: braden, dcantrell, hdegoede, herrold, jwboyer, pertusus, pnasrat, tcallawa, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-06 17:36:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 171279    
Bug Blocks: 235704, 235752    
Attachments:
Description Flags
Honour %_prefer_color instead of always assuming elf64 is preferred. none

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 rel-eng@fedoraproject.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 pnasrat@redhat.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.