Since the debian-amd64 port started, there has been rumors and
half-way implementations of a hybrid system which supports both i386
and amd64 packages. This was first known as biarch then multiarch.
Multiarch is an implementation of a Debian system which exploits the
possibilities inherent to architectures (used in the Debian sense)
such as amd64, sparc and Nienna, better known as "Debian NetBSD". It
allows the system to have .debs for multiple architectures installed
in a sensible way (meaning not separate chroots, for instance) and a
way to express trans-architectural dependencies.
The multiarch proposals have been floating around for a long time now
and they were discussed fairly heavily at the last Debconf. As part
of my master's thesis, I am doing an implementation of a
partly-multiarched system. It shows that it is both possible to do a
multiarched system as well as outlining some of the issues that will
crop up.
As such, the proposal has two parts. One is mostly-agreed on, the
other is more contested. The parts are the file system implementation
and how to implement this in dpkg and Debian packages.
The file system implementation only speaks of libraries and library
packages as those are the most interesting to make multiarch capable.
Other packages which might be multiarched is the toolchain, since it
has good support for coinstallations already, but having multiple
installations of coreutils or sed does not really make any sort of
sense.
For libraries, they will install their files in /lib/$(gcc
-dumpmachine) or /usr/lib/$(gcc -dumpmachine) as appropriate. gcc
-dumpmachine outputs a string similar to i486-linux, x86_64-linux.
For programs wanting to be multiarched, applying a transformation
similar to what gcc use would probably be the right way. (gcc becomes
x86_64-linux-gcc and so on.)
On the packaging side of things, there are currently two proposals.
One by Tollef Fog Heen (with input from different people on Debian
mailing lists) and one by Anthony Towns.
Both proposals means splitting packages is necessary, as files common
to multiple architectures would cause overlap (think /usr/share).
The proposal which is implemented here is Tollef's. It implies
extending the semantics of a Depends field from what it is today where
on the other hand means "I just need a banana package installed, I
do not care about the architecture".
The talk will concentrate around the issues which pops up when such
changes are made, the needed change to infrastructure and core
utilities such as dpkg.
About the author:
Tollef Fog Heen is a Debian Developer and has been since early 2001.
He has been involved in a lot of different Debian projects from
rejuvenating the debian-installer project to general package
maintainance and porting work on the AMD64 port. He has been working on
multiarch since early 2004.
