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 debian-devel@lists.debian.org. 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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature