Dear developers, It is with excitement and trepidation that I write to you today about the status of multiarch support in Debian.
What is multiarch?
People familiar with the FHS and with other Linux distributions probably
know that they require amd64 libraries to be shipped in /lib64 instead of in
/lib – a so-called “biarch” solution because it only scales to two
architectures. Debian has never implemented this provision of the FHS for
two reasons: first, because the package manager up to now has not had
support for installing copies of a package for more than one architecture
side by side, and second because accomodating /lib64 in Debian packaging is
sufficiently intrusive that we’ve held out for a solution that would address
more than just the 32+64-bit library case.
Multiarch is the solution to the second problem, providing a policy for
combining library packages from an arbitrary number of architectures on a
single filesystem. You can read more about multiarch here:
Status in unstable
If you’ve been paying very close attention to your filesystem, or if you
were one of the unlucky few who had a stray copy of libc.so or ld.so left
behind on your filesystem on upgrade from potato, you may have noticed
that libc is no longer located in /lib. It, along with several other
libraries, is now shipped in the multiarch directory (/lib/$arch) as part of
a mostly-painless bootstrap of multiarch into unstable.
This means that the door is open for converting other library packages as
well. Indeed, at last count, 63 source packages have already been converted
Next steps for maintainers
If you are a maintainer of a shared library package, you can convert it to
multiarch today following the instructions in the Debian wiki:
If you have any questions about the multiarchification of libraries, please
don’t hesitate to ask on email@example.com.
Note that the currently documented process only addresses the conversion for
/usr/lib. Multiarch handling of header files (/usr/include) will require
more per-package attention, because architecture-dependent and
architecture-independent header files are currently mixed together in a
single directory and we probably don’t want to move these all to
/usr/include/$arch. As a result, you may prefer to wait for a complete
patch that addresses multiarch for both runtime and development use cases
Otherwise, please help us realize the release goal of multiarch in wheezy!
But when can I use it?
As noted above, support for the multiarch filesystem layout solves only one
of the two problems preventing side-by-side installation of packages from
multiple architectures. The other problem, package manager support, is also
being worked on. apt in unstable includes full support for installing
packages in a multiarch configuration, and a preliminary implementation of
multiarch support for dpkg is available from the ‘pu/multiarch/full’ branch
Daring users can build this version of dpkg from source and configure it for
use with multiarch by creating a file /etc/dpkg/dpkg.cfg.d/multiarch with
“foreign-architecture $arch” lines.
Next steps for upstreams
Multiarch is a significant departure from the historical directory layout,
and while there is a fair consensus that this is the right way to go, this
transition will not be without its bumps. A number of upstream build
systems rely on being able to locate libraries and headers on the filesystem
at build time, not just using the system compiler’s built-in search path.
Patches have been prepared already for a number of these systems, but
currently the only authoritative way to get the multiarch path for a system
is by calling dpkg-architecture, so many of these patches are not yet
upstreamable; with the result that some upstream projects now have a hard
time building on Debian without the addition of Debian patches.
Work is ongoing to formulate a proper, distribution-neutral interface for
querying the correct multiarch path for a system. In the meantime, if you
are an upstream affected by this issue, or a maintainer of a package whose
upstream is affected, you are welcome to join us in discussing these matters
on debian-devel as well.
A summary of currently known upstream compatibility issues, and the status
of prospective patches for them, can also be found in the Debian wiki here:
And it’s a wiki, so feel free to document other known issues here.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/