[Fedora-packaging] tricks for multilib proposal

[Patrice Dumas]

Hello, 

I propose the following with tricks for packaging multilibs. It tries to
be a summary of a thread about multilibs. There may be mistakes, or
statements everybody doesn't agree with, so please comment.
This is pseudo wiki and I don't know where it should be put in the 
wiki.





= Multi lib tricks =

== Architecture independent files ==

For architecture independent the conflicts should be avoided, so the
files should be identical among arches. It may involve some work with
upstream when header files include architecture specific files, for
example header files which contains autoconf conditionals like
HAVE_INT32.

Files should also have the same timestamps. For most of the files this
means taking care to keep the timestamps (which should be done in
every package). For autoconf based packages this is in general achieved
by doing something along:

make install DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p"

For the architecture independent files generated at build time it is
possible to use the timestamp of a reference file. For example:

touch -r ../cernlib.in src/scripts/cernlib

or

touch -r NEWS $RPM_BUILD_ROOT%{_includedir}/Xbae/patchlevel.h

== Multiarch, binaries and compilation scripts ==

In multilib environments there is a preferred architecture, 64
bit over 32 bit in x86_64, 32 bit over 64 bit in ppc64. When a conflict 
is found between two packages corresponding with different arches, the 
installed file is the one from the preferred arch. This is very common 
for executables in /usr/bin, for example. If the file /usr/bin/foo is 
found in an x86_64 package and in an i386 package, the executable 
from x86_64 will be installed. 

These implicit conflicts are accepted in Fedora, though they are
considered bad by some contributors. There may be some long-term 
solution for these issues, but before that there are some tricks 
that may allow to avoid those conflicts that are presented below. 
Once again they are optional.

* In compilation scripts (in general named along mylib-config) it should
  be advisable to remove -L$libdir when $libdir is the default library
  directory on this platform. Indeed this is automatically added when
  linking with the gcc compiler (it may be needed when linking with ld,
  but using ld is wrong in general, so a user linking with ld should add
  the flag by himself).

* binaries may be put outside of the packages selected to be included
  in multilib repositories. In general the devel subpackages and their
  dependencies are included in multilib repositories. A typical split
  of a package is:

foo for the binaries
foo-libs for the libraries
foo-devel for the development headers, and development symlinks

   foo-devel and foo both requires foo-libs, and foo isn't 
   present in multilib repository.

* wrapper scripts may be used to run a binaries based on which one is
  present. Here is a script example (adapted from firefox)

ARCH=$(uname -m)

case $ARCH in
        x86_64 | ia64 | s390 )
           LIB_DIR=/usr/lib64
           SECONDARY_LIB_DIR=/usr/lib
                ;;
        * )
            LIB_DIR=/usr/lib
            SECONDARY_LIB_DIR=/usr/lib64
                ;;
esac

if [ ! -x $LIB_DIR/package-0.0.1/foo ]; then
    if [ ! -x $SECONDARY_LIB_DIR/package-0.0.1/foo ]; then
        echo "Error: $LIB_DIR/package-0.0.1/foo not found"
        if [ -d $SECONDARY_LIB_DIR ]; then
            echo "       $SECONDARY_LIB_DIR/package-0.0.1/foo not found"
        fi
        exit 1
    fi
    LIB_DIR=$SECONDARY_LIB_DIR
fi


Another way to handle those conflicts could be to have a different
directory for each architecture, even for executables, enabling 
Fedora to be multiarch and not only multilib.




--
Pat