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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
