Bug 214737

What packages have the "[ -x /path/to/program ] && ,,," hackery?

What failure symptom is the hackery trying to solve?

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.

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

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 ;-)

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.

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)

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.

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.

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).

Oops, I mean the original part of bug #235757, not the multilib tracker.

Fixed in rpm cvs, will be in rpm-4.4.9-0.5 when built.

UPSTREAM

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

rpm 4.4.2.2(-rc1) in next rawhide push reorders installs to install packages
with preferred color first which should fix this issue. Thanks for the patch Jeff...