How to handle multiarch on x86-64 (and other platforms). Problem and delimitations: We want to be able to install libfoo built for i386 and libfoo built for amd64 at the same time. The reason we want this is that we want to be able to install applications linking against both the 32 bit and 64 bit libraries. This is only one case: We might want to install O32, N32 and N64 libraries on mips, or install i386, hppa and ia64 libraries on ia64. We are not trying to solve the issue of having multiple applications with different ABIs installed at the same time, so having both a i386 and an amd64 perl installed at the same time is out of scope for this document. Solution: In order for packages to be considered coinstallable by dpkg, an Multi-Arch field has to be added to the control file in the .deb. If the field is missing or set to "no", dpkg will se the packages as having an implicit conflict across architectures. For multi-arch packages we make the architecture part of the package name as far as dpkg is concerned. The exact syntax is yet to be decided, but something like libfoo:i386 to refer to libfoo on i386, libfoo:amd64 to refer to libfoo on amd64. Since we want to support more than just two architectures per platform, using /usr/lib64 as proposed by others is too limiting. We will instead use /usr/$(gcc -dumpmachine)/{lib,include} (gcc -dumpmachine outputs i486-linux, x86_64-linux or equivalent). This means that we will not have conflicts between development packages, nor will we have to try to make include files architecture independent. The support for /usr/$(gcc -dumpmachine) is already in gcc, so few changes should be needed there, and switching from compiling for, say amd64 to i386 would be accomplished through Linux personalities. The problem with having two packages named the same is file overlap, especially /usr/share/doc/libfoo, which has to exist in both packages (per policy 2.3). Any other arch-indep files (that is, files in /usr/share) should be moved to an Architecture: all -common package. The case of file conflicts with /usr/share/doc/libfoo will be solved as a special case in dpkg where if two multi-arch packages provide the same file and that file is a symlink pointing to the same place, it will not be seen as a conflict. Libraries wishing to be multi-arch will therefore have to provide a libfoo-common, which will include what would go into /usr/share and the libfoo:amd64 and libfoo:i386 packages would have to provide said symlink and depend on libfoo-common. Questions: Q: Why not lib64foo? A: Renaming packages is a lot of work, and will not scale once you want to have three or more architectures being coinstallable. Q: How will dependencies be handled? A: Having a Depends field saying Depends: libfoo in an i386 package means: Depends: libfoo:i386 | libfoo:all . This will take care of getting you the right libraries. If you don't care what architecture the dependee is, you can use Depends: bash:any Q: Is the libfoo:$arch syntax handled for Depends fields today? A: No, not today, but patches for handling it have been written. The archive tools (katie) will most likely also have to be changed. Q: What about /usr/lib64, /usr/lib and /usr/include? A: They are kept around for historical reasons, but will go away once they are empty at some undefined point in the future. Q: What about /usr/X11R6? A: It is going away by itself, so we will not have to worry about it. Q: Will this mean libfoo won't include a copyright file or changelog? A: /usr/share/doc/libfoo-dev is already often a symlink, so this is already true for many packages in the archive. These will be provided by the libfoo-common package which libfoo shares the source with and which libfoo depends on. Comments/suggestions should be sent to Tollef Fog Heen