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