Using multiarch

To enable the installation of multiarch binaries, apt and dpkg need configuration changes. For example, if you have an amd64 system that you want to install i386 libraries onto, do the following:

Converting your package for multiarch

This section is intended to be a one-stop guide for converting library packages to Multiarch. If you find there are issues not documented here, please update this wiki page, or contact debian-devel@lists.debian.org for help.

Why update your library package for multiarch support?

Now that multiarch support is available in the package manager (dpkg 1.16.0 and above; apt 0.8.12 and above), converting your runtime library package to Multi-Arch: same makes it possible for users to install your package for more than one architecture at the same time. This has several benefits:

Issues to be aware of when converting

You might wonder why, if multiarch is so great, the conversion isn't handled automatically by the package helper tools like debhelper and cdbs. The answer is that there is no reliable way to automatically convert a package to multiarch. Careful attention is required on the part of the maintainer to ensure the conversion is done correctly. In particular, you must pay attention to the following issues:

What does the end result look like?

Currently, Debian Policy (9.1.1) provides for multiarch paths only for shared libraries. However, most upstream build systems (such as autoconf, with --libdir) will install shared libraries, support files, and various development files (such as static libraries and .so symlinks) together to the same target directory. It is intended that Debian Policy be amended to permit all of these files to be installed to the multiarch /usr/lib/<triplet> subdirectory.

With that fixed, the changes to packages for multiarch can be summarized as follows:

/usr/lib -> /usr/lib/<triplet>
/usr/lib/<pkgdir> -> /usr/lib/<triplet>/<pkgdir>
/usr/include: no change
/usr/bin: no change
/usr/share: no change
/usr/sbin: no change

Packages that are Multi-Arch: same must adhere quite closely to Debian Policy section 8. In particular, since multiarch doesn't make any changes to the executable paths, a multiarch library package must not include binary executables in /usr/bin or /usr/sbin, since this will cause a conflict among the different architecture versions of a package. See Debian Policy: Shared library support files for advice on dealing with any such executables currently included in your runtime library package.

The end result, then, is a runtime library package that contains only files in the directories /lib/<triplet>, /usr/lib/<triplet>, /usr/share, and possibly /etc (though including configuration files in runtime library packages is generally discouraged). When these are all the files present in your runtime library package, your package can be marked Multi-Arch: same.

/!\ Note that any files in /usr/share or /etc must be byte-for-byte identical across architectures, otherwise file conflicts will result! This means, in particular, that any gzip-compressed files must be compressed with -n to avoid embedded timestamps.

Multi-Arch: foreign support packages

If your runtime library package follows Debian Policy section 8, there's a good chance that your library will have a dependency on some runtime support package such as libfoo-data. Since by definition the contents of this package are moved out of the runtime library package because they cannot be shared, you cannot install a copy of this package for each architecture and so it cannot be marked Multi-Arch: same. Instead, assuming that the interfaces the library uses to access these support files are architecture-independent, we instead mark this support package Multi-Arch: foreign to indicate that one copy of this package, of any architecture, is sufficient to satisfy the needs of the runtime library package of every architecture. No special dependencies or build-dependencies are needed in order to use Multi-Arch: foreign since this does not require multiarch-specific changes to the package's contents.

The Multi-Arch: foreign field must be set on such support packages regardless of whether they are Architecture: any, or Architecture: all. See the multiarch package manager spec for an explanation of this.

udeb handling

Although the runtime linker in the Debian installer environment is perfectly capable of finding libraries installed to the multiarch /usr/lib/arch path, it is unlikely that an installer will ever need to include binaries for more than one architecture; it is therefore recommended to install libraries directly to /usr/lib in udebs instead. Of course, plugins will need to be installed within a udeb to the directory where the binary will look for them; so if only the multiarch directory is on the search path, plugins will need to install to the multiarch directory even though the shared library may still be in /usr/lib.

Recipes for converting packages

dh(1) and autotools

By far the simplest package to convert is one that uses autoconf upstream and dh(1) in the Debian packaging.

  1. Build-depend on debhelper (>= 8.1.3).

  2. Add Pre-Depends: ${misc:Pre-Depends}  to any package listed in debian/control that provides a shared library.

  3. Update debian/compat to '9'. Note: debhelper compat level 9 is still under development; please pay attention to the section on Debhelper compatibility levels in the debhelper(7) manpage for information on other changes that may affect your package.

  4. Replace occurrences of /usr/lib/ in debian/*.install with /usr/lib/*/.

  5. If /usr/lib (or a subdirectory) is listed as an installation target in debian/*.install, or the target of a link in debian/*.link, you will need to autogenerate this file in debian/rules with an override target (and add the generated files to debian/clean so they're removed again in the clean target), to substitute in the value of $(DEB_HOST_MULTIARCH).

  6. Any occurrences of /usr/lib in debian/rules should be replaced with /usr/lib/$(DEB_HOST_MULTIARCH).

  7. If you needed to use $(DEB_HOST_MULTIARCH) in debian/rules in either of the two preceding steps, set DEB_HOST_MULTIARCH in debian/rules by calling: DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

  8. Once you have built the package and verified that the shared library package contains only the expected files, and that your -dev package still works, mark this shared library package Multi-Arch: same in debian/control.

If you have overridden debhelper commands in debian/rules, despite using dh(1) for the rest of the build, you may need to follow the instructions below for classic debhelper to modify mv, cp or rm commands used by your override rules.

cdbs and autotools

CDBS doesn't have the equivalent of debian/compat to control its behavior, so a little more effort is needed if you use CDBS rather than dh(1).

  1. Build-depend on debhelper (>= 8.1.3) and cdbs (>= 0.4.93)

  2. Add Pre-Depends: ${misc:Pre-Depends}  to any package listed in debian/control that provides a shared library.

  3. Add DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) to debian/rules.

  4. Any occurrences of /usr/lib in debian/rules should be replaced with /usr/lib/$(DEB_HOST_MULTIARCH).

  5. Replace occurrences of /usr/lib/ in debian/*.install with /usr/lib/*/.

  6. If /usr/lib (or a subdirectory) is listed as an installation target in debian/*.install, or the target of a link in debian/*.link, you will need to autogenerate this file in debian/rules with a common-install-arch:: target (and clean up the generated file in the clean target), to substitute in the value of $(DEB_HOST_MULTIARCH).

  7. Once you have built the package and verified that the shared library package contains only the expected files, and that your -dev package still works, mark this shared library package Multi-Arch: same in debian/control.

classic debhelper and autotools

If you call dh_* commands directly in debian/rules rather than using dh(1) or cdbs, these are the steps to follow when converting a library package for multiarch.

  1. Build-depend on debhelper (>= 8.1.3).

  2. Add Pre-Depends: ${misc:Pre-Depends}  to any package listed in debian/control that provides a shared library.

  3. Set DEB_HOST_MULTIARCH in debian/rules by calling: DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

  4. Add --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) to each invocation of configure in debian/rules.

  5. Any occurrences of /usr/lib in debian/rules should be replaced with /usr/lib/$(DEB_HOST_MULTIARCH).

  6. Replace occurrences of /usr/lib/ in debian/*.install with /usr/lib/*/.

  7. If /usr/lib (or a subdirectory) is listed as an installation target in debian/*.install, or the target of a link in debian/*.link, you will need to autogenerate this file in debian/rules at the beginning of any install target, to substitute in the value of $(DEB_HOST_MULTIARCH). (If you do not have an install: target, you will need to do this at the beginning of your binary/binary-indep/binary-arch target.) You should then also clean up the generated file in the clean target.

  8. Once you have built the package and verified that the shared library package contains only the expected files, and that your -dev package still works, mark this shared library package Multi-Arch: same in debian/control.

autotools with no helper

  1. Build-depend on dpkg-dev (>= 1.16.0).

  2. Add Pre-Depends: multiarch-support to any package listed in debian/control that provides a shared library.

  3. Set DEB_HOST_MULTIARCH in debian/rules by calling: DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

  4. Add --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) to each invocation of configure in debian/rules.

  5. Any occurrences of /usr/lib in debian/rules should be replaced with /usr/lib/$(DEB_HOST_MULTIARCH).

  6. Once you have built the package and verified that the shared library package contains only the expected files, and that your -dev package still works, mark this shared library package Multi-Arch: same in debian/control.

Other build systems

If you can provide a recipe for converting a package to multiarch when it uses something other than autotools as its build system, please add it here. If this build system is supported by dh(1), please also consider providing a patch to debhelper to automatically build for multiarch in compat level 9.