Bug 214737 - rpm seems to have bogus multilib optimization
Summary: rpm seems to have bogus multilib optimization
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact:
Depends On:
Blocks: FC7Target 220348 multilib
TreeView+ depends on / blocked
Reported: 2006-11-09 03:38 UTC by Ray Strode [halfline]
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1003029 (view as bug list)
Last Closed: 2007-08-28 11:02:46 UTC
Type: ---

Attachments (Terms of Use)

Description Ray Strode [halfline] 2006-11-09 03:38:32 UTC
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 12:39:49 UTC
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 15:58:02 UTC
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-10 02:13:55 UTC
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-10 02:15:58 UTC
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-10 02:23:12 UTC
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 15:52:00 UTC
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 16:55:19 UTC
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-21 03:02:22 UTC
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 11:06:04 UTC
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 11:07:38 UTC
Oops, I mean the original part of bug #235757, not the multilib tracker.

Comment 12 Jeff Johnson 2007-05-01 12:42:30 UTC
Fixed in rpm cvs, will be in rpm-4.4.9-0.5 when built.


Comment 13 Red Hat Bugzilla 2007-08-21 05:29:17 UTC
User pnasrat's account has been closed

Comment 14 Panu Matilainen 2007-08-22 06:35:07 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 15 Panu Matilainen 2007-08-28 11:02:46 UTC
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.