Bug 235757 - prevent multilib file conflicts, abandon RPM file colour hack.
Summary: prevent multilib file conflicts, abandon RPM file colour hack.
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
Whiteboard: bzcl34nup
Depends On: 171279
Blocks: F8Target multilib
TreeView+ depends on / blocked
Reported: 2007-04-09 22:56 UTC by David Woodhouse
Modified: 2013-01-10 04:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-08-06 21:36:11 UTC
Type: ---

Attachments (Terms of Use)
Honour %_prefer_color instead of always assuming elf64 is preferred. (3.50 KB, patch)
2007-04-27 07:01 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2007-04-09 22:56:43 UTC
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-25 00:30:15 UTC
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 06:56:30 UTC
(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

Comment 3 David Woodhouse 2007-04-27 07:01:00 UTC
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="/"):
     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")

Actually, it would be quite good to do that on upgrades, too.

Comment 4 Jeff Johnson 2007-04-27 10:51:23 UTC
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 10:56:45 UTC
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 11:06:13 UTC
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 11:13:30 UTC
Yep, my mistake.

Comment 11 David Woodhouse 2007-04-27 23:37:52 UTC
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 12:24:39 UTC
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?


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 04:45:02 UTC
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 06:13:53 UTC
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 08:44:31 UTC
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 21:06:07 UTC
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 05:04:52 UTC
No, we still need anaconda to set _prefer_color 1 in /etc/rpm/macros on upgrades.

Comment 18 Paul Nasrat 2007-05-14 09:58:13 UTC
Commited a fix for upgrades

Comment 19 David Woodhouse 2007-06-07 14:31:58 UTC
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 05:33:33 UTC
User pnasrat's account has been closed

Comment 21 Bug Zapper 2008-04-04 00:00:57 UTC
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:

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-07 01:27:22 UTC
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:

Comment 23 Patrice Dumas 2008-05-11 22:40:48 UTC
Can somebody confirm or infirm that it is closed?

Comment 24 Bug Zapper 2008-05-14 02:45:23 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 26 Andy Lindeberg 2008-08-06 21:36:11 UTC
If this is still a problem in F9, please refile as a different bug.

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