Bug 235757

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.