--- Begin Message ---
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:
http://wiki.debian.org/Multiarch
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[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!
[1] http://bugs.debian.org/629534
[2] http://wiki.debian.org/Multiarch/Bootstrapping
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:
http://wiki.debian.org/Multiarch/Implementation
If you have any questions about the multiarchification of libraries, please
don't hesitate to ask on [email protected].
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 <git://git.debian.org/users/hertzog/dpkg.git>.
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:
http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact
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 http://www.debian.org/
[email protected] [email protected]
signature.asc
Description: Digital signature
--- End Message ---
_______________________________________________
Espiral mailing list
[email protected]
http://debian.ec/cgi-bin/mailman/listinfo/espiral
