\chapter{Introduction}

Multiarch will be used as a term describing a system which has support
for running binaries with different architectures, simultaneously and
in the same file system hierarchy.  Architecture is here the GNU
system type.  Typical values are ``i386-linux'', ``x86\_64-linux'' and
``i386-freebsd4.8''.  This is because both the software (and in some
cases, the version of the software) as well as the hardware is
defining the ABI which software on the system has to conform to.

Being able to do this is a goal because not all software exists or
works correctly on all the architectures.  Current examples are
OpenOffice.org not working correctly on 64 bit architectures and the
limited availability of proprietary software.  A nice feature you get
``for free'' with multiarch is the ability to migrate from one
platform to another without having a single day on which the whole
system is switched.

This has, in one form or another, been supported in many operating
systems for a long time.  NetBSD/i386 has been able to run Linux/i386
binaries, FreeBSD likewise.  This is usually accomplished through
having a complete system installation in a chroot and the kernel doing
more or less dirty tricks to make the programs work. A problem with
most of those solutions is they force the administrator to maintain
two different operating system installations, often very different in
how they are maintained.  The integration between them is poor and
some software is installed twice.  Examples of the latter are
text-processing tools such as sed and awk.

This multiarch implementation will hopefully solve this problem.  It
will provide smooth integration and administer the system as a
single system rather than multiple separate installations.

\section{History}

Multiarch systems have a long history, spanning back to at least the
IBM S/360 model 30 which included support for emulating the IBM 1401 and
the IBM 7000 series\cite{365931} where emulation was used not only as
an intermediate stage when moving from one architecture, but used as a
permanent solution\cite{microprogramming.history}.

Later, emulation has been used in numerous research systems and
production systems ranging from the PDP-11 emulation in Nanodata
QM1\cite{804781} to more modern examples such as Apple's emulation of
the m68k family of CPUs when they introduced the Power Macintosh and
Transmeta's\cite{transmeta-site} Crusoe familiy of CPUs.

Even though multiarch has been used for a long time, it has not caught
on except for some lone efforts.  It is only lately that computers
have begun having enough CPU power that one is able to afford the
extra cost of supporting non-native architectures symmetrically.  In
this context, symmetrically means that any emulated architectures are
first-class citizens and run at decent speed and with good integration
into the rest of the system.  This as opposed to an emulator where the
emulated system runs inside a virtual machine and is only accessible
through the host system.  Earlier efforts have been on supporting a
single legacy architecture to ease the transition cost.  Multiarch is
an effort where the term ``native architecture'' is no longer as
meaningful since it uses the strength of the different ABIs provided
rather than a ``one size fits all'' approach.

Another reason why this is happening now and not ten or twenty years
ago is the growth of free software which runs on different hardware
architectures.  Multiarch unifies this.  Proprietary vendors have
usually had a bundle of hardware and software they wanted to sell and
therefore had little incentive to investigate cross-architecture
compatibility.  Their efforts was at most limited to a biarch
approach, usually with a 32 bit and a 64 bit set of libraries but
without any support for alternative kernels (such as Linux).  Those
solutions also tend to have a much bigger focus on one of the
architectures than the other.  An example is the 64 bit support in
Solaris which is ``for selected application only'' rather than a full
and generic 64 bit development and runtime environment.

This also means the number of references in this thesis is fairly low
and mostly limited to URLs to proposals and mailing list postings.
Those are the media which the free software world uses for
development, rather than the academic papers and publications.

\section{Delimitations}

The implementation here is done around dpkg, the package manager used
in Debian and derived distributions such as Ubuntu.  Due to time
constraints, only the dpkg implementation is done, but a similar
implementation could be done for other package managers such as RPM.

The file system implementation is an extension of the
FHS\cite{fhs-site} and could therefore easily be reused for other
Linux distributions.  The BSDs, Sun Solaris and so on would possibly
want to customise it a bit, but it could at least provide inspiration
for a similar solution.

The implementation is done with UNIX and UNIX-like operating systems
in mind.  It might be possible to do something similar for VMS or
Microsoft Windows, but that would most likely require heavy changes in
both the design and implementation so they are not discussed further.

Building binaries for other architectures is not covered in this
thesis.  It is interesting to do that, but getting support for just
running binaries from other architectures is needed first.

\section{Intentended audience}

This thesis is intended as a part of the debate surrounding how to do
multiarch in Debian.  The intended audience is Debian Developers and
other interested people.  An understanding of package relationships
and the Debian policy\cite{debian-policy} is recommended.
