Debian-news is about one simple thing - news about Debian GNU/Linux and the top free distributions based on Debian GNU/Linux.


Multiarch in Debian unstable

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 or left
behind on your filesystem on upgrade from potato[1], 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.[2]

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
in unstable!


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

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
before uploading.

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
of .

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.

Happy hacking,

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

No Response to “Multiarch in Debian unstable” »

No comments yet.

RSS feed for comments on this post.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


Debian-News is not related to the Debian Project.
All logos and trademarks on this site are property of their respective owners.