Multilib help?

[Bill Nottingham]

Richard W.M. Jones (rjones at redhat.com) said: 
> Is there better documentation on how multilib works and how to resolve
> multilib problems than
> http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks ?  I
> understand that it uses various heuristics before it corrupts files,
> but those don't seem to be documented.
> 
> I just spent half a day tracking down a problem which turned out to be
> because multilib had corrupted a file, and I wish to solve this now
> once and for all.

'corrupted a file'? I'm really not sure what you mean here.

In any case, excessive verbiage follows:

...

Fedora, on certain architectures, supports multible binary ABIs.
This includes support for i386 on x86_64, and ppc64 on ppc.

Fedora supports these ABIs through a process called 'multi-arch'
or 'multilib', wherein the corresponding RPM packages for the secondary
arch are included along with their primary arch counterparts. These
packages are built via the same process as the primary arch packages,
and are identical to the packages that would be shipped in a 
release where that arch would be the primary arch.
 
The primary function of multilib support in Fedora is to provide a
runtime environment for applications to use. To satisfy this, packages
that provide runtime libraries are included for the secondary arch.

The secondary function of multilib support in Fedora is to provide
a development environment. To satisfy this, packages that provide
development headers are included for the secondary arch. However,
it should be noted that it is preferred to use a full system of
the appropriate architecture to do development where possible; this
can be done by using the 'mock' package to create an appropriate
chroot.

Multilib packages are intentionally not provided for system daemons
(for example, to run alternate-wordsize versions of Apache or
PostgreSQL.) If you need to run a non-default wordsize of a system
daemon, it is recommended that you install the system with a release
that supports that architecture as the primary architecture.

Not all packages produced by a particular source RPM are included as
multilib packages; only subpackages that implement runtime libraries
or development environments are included.

Whether or not multilib packages are installed by default is controlled by
the 'multilib_policy' configuration file parameter for yum. The default
value for Fedora of 'best' installs only packages for the primary
architecture. If this is changed to 'all' packages for all compatible
architectures will be installed by default. Note that this can only be
changed post-install; anaconda uses the default of only installing packages
for the primary arch.

You can still at any time install packages for a particular arch by passing
the architecture directly to yum. For example, running 'yum install
glibc.i686', or putting 'glibc.i686' in a kickstart %packages stanza, will
install the 32-bit x86 version of glibc.

When installed in parallel, multilib RPM packages may contain files that
live in common paths. When this happens, RPM uses the following algorithm:

- If the file in both packages is identical, installation is allowed
  and the file is written
- If the file in both packages is an ELF binary, the file used is the
  file in the package for the primary architecture
- If the file in both packages is not an ELF binary a RPM conflict is
  raised

If such conflicts are raised with packages in the Fedora tree, it can
be considered a packaging bug that needs to be fixed.

...

Bill