Bug 214737 - rpm seems to have bogus multilib optimization
rpm seems to have bogus multilib optimization
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Depends On:
Blocks: FC7Target 220348 multilib
  Show dependency treegraph
Reported: 2006-11-08 22:38 EST by Ray Strode [halfline]
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1003029 (view as bug list)
Last Closed: 2007-08-28 07:02:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2006-11-08 22:38:32 EST
Recently a lost of packages that call programs in post have had to add 

[ -x /path/to/program ] && 

guards to get around some sort of optimization that rpm performs where it won't
install a 32-bit binary early in a transaction if a 64-bit binary would
overwrite it later in the transaction.

That optimization seems bogus because the binary may be needed during the
transaction and it breaks the contract that Requires(post): program will ensure
the program is fully installed before %post.

We should just always install the 32-bit binary even though it will get replaced
later in the transaction.
Comment 1 Jeff Johnson 2006-11-09 07:39:49 EST
What packages have the "[ -x /path/to/program ] && ,,," hackery?

What failure symptom is the hackery trying to solve?
Comment 2 Ray Strode [halfline] 2006-11-09 10:58:02 EST
So let me give an example:

some packages need to update the fontconfig global font cache on package
install.  So these packages would normally add Requires(post): fontconfig or
something similiar and then run fc-cache in %post.

The problem comes into play with multilib.  If both i386 and x86-64 fontconfig
end up in the same transaction as one of those packages then fontconfig.i386
will satisfy the Requires(post), but /usr/bin/fc-cache won't be installed at
%post time because rpm knows that fontconfig.x86-64 will provide
/usr/bin/fc-cache later in the transaction.  So you end up with %post failing
with file not found.
Comment 3 Jeff Johnson 2006-11-09 21:13:55 EST
Fundamental to the multilib implementaion in rpm, is that libraries are distingushed by being on
separate paths, but elf32/elf64 executables should behave identically.

That is true for, say, /bin/ls or bin/sh, the functionality is independent of elf32/elf64.

There are binaries whose bahvior can and does depend on elf32/elf64, say, valgrind.

Does the functionality of /usr/bin/fc-cache depend on whether the executable is
elf32 or elf64?

Otherwise, what *should* be happening in your example, is that the
   Requires(post): fontconfig
will order packages so that one of the fontconfig (elf32/elf64 executables assumed to be
interchangeable) will be installed first.

However, if there are dependency loops, then all the relations involved in the loop
will be ignored, and the ordering will perhaps be non-deterministic.

I cannot tell whether there are loops involved without seeing a more specific example.

Your explanantion makes no sense (to me) if /usr/bin/fc-cache is included in
both the i386 and x86_64 packages, and /usr/bin/fc-cache behavior is not
dependent on elf32/elf64 unless there are dependency loops involved. One or
the other of the two fontconfig packages should have been ordered before any
package that has
    Requires: fontconfig
Comment 4 Jeff Johnson 2006-11-09 21:15:58 EST
No matter what
    if [ -x /usr/bin/fc-cache ] ...
tests in scriptlets are a hacky and silly way to solve a more fundamental problem.

I suspect we can both agree on that ;-)
Comment 5 Matthias Clasen 2006-11-09 21:23:12 EST
Jeff, if you look at the install log linked in e.g. bug 214697 you will see
that scrollkeeper _is_ installed before zenity, and still the binary is missing
in the later zenity %post. Here is an excerpt:

Installing docbook-dtds - 1.0-30.1.noarch
Installing scrollkeeper - 0.3.14-8.fc6.s390
Installing docbook-style-xsl - 1.69.1-5.1.noarch
Installing zenity - 2.16.0-1.fc6.s390x
/var/tmp/rpm-tmp.84928: line 1: scrollkeeper-update: command not found
error: %post(zenity-2.16.0-1.fc6.s390x) scriptlet failed, exit status 127

As Ray said earlier, this has been explained by installer people as a
bogus optimization in rpm where it simply does not install the binaries
in the compat-arch package if it knows that they will be overwritten by
a later native-arch version of the same package in the same transaction.
Comment 6 Ray Strode [halfline] 2006-11-10 10:52:00 EST
Hi Jeff,

Yea in these cases both the 32-bit and 64-bit versions of the binaries should
behave identically.

In the cases where this doesn't hold true we usually version the binary with a
-32 or -64 suffix (see gdk-pixbuf-query-loaders-32 for instance).  I can't think
of any examples were we use one of these versioned programs in %post though. 
The post install programs just do things that, e.g., update architecture
independent caches (like the gtk icon cache or scrollkeeper catalog database)

Comment 7 Jeff Johnson 2006-11-10 11:55:19 EST
I am not authorized (nor do I wish to be authorized) to see #214697.
Mail privately if you wish me to be informed sufficiently that I might
be able to constyruct a reproducer.

OK, what I guess is happening is that the policy of
    Always prefer ELF64.
may be computing a don't install resolution at odds with
the way that dependencies are ordering packages. I'll
verify from looking at code this weekend.

If that's the case, the cheapest fix is to add an additional constraint
to order ELF64 packages before ELF32 for identically named packages,
not hard.

I suspect the better long term fix is to refactor all the GNOME goop out of
package scriptlets into a trigger based on "directory contents changed",
but that's entirely speculative and irrelevant to this bug atm.
Comment 9 Jeff Johnson 2006-12-20 22:02:22 EST
Heh, "bogus multilib optimizations" is not even close to the truth. Sure, let's
install every ELF file twice just in case it is needed!

FWIW, I have given Paul Nasrat the fix, we'll see if or when it is applied.
Comment 10 David Woodhouse 2007-05-01 07:06:04 EDT
Probably too late to fix for F7, and the real fix in the long term is to get rid
of the hack with conflicting files and file 'colours' anyway (the original part
of bug #235752; not the short-term hack to prefer elf32 on ppc64 for f7).
Comment 11 David Woodhouse 2007-05-01 07:07:38 EDT
Oops, I mean the original part of bug #235757, not the multilib tracker.
Comment 12 Jeff Johnson 2007-05-01 08:42:30 EDT
Fixed in rpm cvs, will be in rpm-4.4.9-0.5 when built.

Comment 13 Red Hat Bugzilla 2007-08-21 01:29:17 EDT
User pnasrat@redhat.com's account has been closed
Comment 14 Panu Matilainen 2007-08-22 02:35:07 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 15 Panu Matilainen 2007-08-28 07:02:46 EDT
rpm in next rawhide push reorders installs to install packages
with preferred color first which should fix this issue. Thanks for the patch Jeff...

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