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: The example package used here is libfoo. The i386 version of the binary package is libfoo:i386; the amd64 version is libfoo:amd64. In order for packages to be considered coinstallable by dpkg, an Multi-Arch field will be added to the control file in the binary package. If the field is missing or set to "no", dpkg will see the packages as having an implicit conflict across architectures. When dpkg sees a multi-arch package, it automatically makes the architecture part of the package name. Matt Taggart has written a proposal on what the file system layout should look like, as documented in http://www.linuxbase.org/~taggart/multiarch.html#proposal . Today, if you just added "Multi-Arch: yes" to a random library package and tried to install it, you would have problems with file overlaps. Most of them are trivially solved by moving common, arch-independent files out into a -common package. Still, you have to have /usr/share/doc/libfoo (as per policy 2.3). The abovementioned conflict can be reduced to a single conflicting symlink by making /usr/share/doc/libfoo a symlink to libfoo-common. Said conflict will then be special-cased in dpkg: If two packages provide the same file and that file is a symlink with the same target, it will not be seen as a file conflict. Multi-arch libraries will therefore have to satitisfy the following requirements: - They must depend on the corresponding -common package, which will include the architecture-independent parts the library package needs. This includes the copyright file and all the contents of /usr/share/doc/$package. - The library package must provide /usr/share/doc/$package as a symlink to $package-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. This is not really true with Anthony Town's proposal (available at http://people.debian.org/~ajt/amd64-multiarch-3.txt), but that proposal requires implementing versioned provides in dpkg. He proposes to encode even more ABI information into the package name, while this proposal tries to separate ABI information (which is Architecture here) and package name. 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 is the same as today). 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, as well as any other tools that depend on the exact format of the Depends fields. Q: What about /usr/lib64 (and /lib64)? What about /usr/X11R6? A: lib64 is a wart on history and should never have been allowed to grow up. It will be removed at the earliest opportunity, provided no software needs it. X11R6 will also disappear by itself, so we won't 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