Understanding multi-lib conflicts in packages

[Matthias Clasen]

Michael Schwendt wrote:
> I have a *long* list of i386+x86_64 multi-lib package conflicts in
> Extras 7 here.
>
> If two packages (one i386, the other x86_64) of the same name
> are installed, which files can cause conflicts because no magic
> inside RPM takes care of overriding files like executables?
>
> Can %doc files cause a conflict?
>   
Yes, this is a common form of multilib conflict,  which often arises when
documentation is generated at build time and the doc generator (e.g. gtk-doc
or doxygen) embeds timestamps or some other random data in the generated
docs.

The easiest fix here is often to use pregenerated docs as separate source
instead of generating the docs at build time.
> I assume include files can cause a conflict.
>   
Yes, quite a few libraries install config.h-alike headers which naturally
cause conflicts.

> I assume arch-independent data files can cause a conflict.
>   
Only if they are generated at build time and include timestamps or other
variable data. Identical files will not cause conflicts if they installed by
arch-variants of the same package, AFAIK.
> I assume executables in bindir/sbindir'n'friends don't cause
> a conflict, because RPM lets the best arch win (or something like
> that, right?)
>   
Yes. But unfortunately, rpm has some mis-optimization in this area: if it
sees that a binary will later be overwritten by an arch-variant of the 
same package,
it does not bother to install the "wrong arch" binary in the first 
place. Unfortunately,
that wreaks havoc with other packages that Requires(post) the package in 
order to
use that very binary. We have seen cases like this with e.g. fc-cache and
gtk-update-icon-cache in RHEL.

Matthias