\chapter{Analysis of existing solutions}

The existing solutions have a few common shortcomings:

\begin{itemize}
\item Limited number of architectures
\item No way to handle multiple architectures with same pointer size
\item Little or no real support for multiarch, just hacked-on solutions
\end{itemize}

There are some existing solutions for handling multiarch and there has
been a consensus forming on how to solve it on the file system
hierarchy level, but nobody has so far been willing to take the first
step and make their system multiarch-compliant.  The implementations
which exist are limited and usually only supports two architectures,
not an unlimited number.

In most cases, support for two architectures will be enough.  A very
common case will be support for i386 binaries on an x86\_64 machine or
support for powerpc or sparc binaries on their equivalent 64 bit
systems.  This can be solved adequately with a solution which just
provides support for two architectures, for instance the file system
layout most Linux distributions have so far with \directory{/usr/lib}
and \directory{/usr/lib64} (or \directory{/usr/lib} and
\directory{/usr/lib32} where the ``native'' architecture is 64 bit).

The lib/lib64 solution doesn't work well once you want to support
multiple 64 or 32 bit architectures.  An example is
NetBSD\cite{netbsd-site} and FreeBSD's\cite{freebsd-site} support for
running Linux binaries.  Another example would be the moment
ia64\cite{itanium-site} get support for running x86\_64 binaries where
you'd get a collision between the architectures in what should go in
/usr/lib (since that is a 64 bit directory on ia64).

One can construct more contrived examples, such as running i386 and
amd64 binaries for Linux, FreeBSD and NetBSD, on a NetBSD system.
One would then need six different library directories.  Once you have such
large systems, a generalised solution is obviously needed.

The existing solutions have been more thoroughly described in
\cite{tfheen-scalable}.  This is recommended reading to understand
some of the scalability problems in the software distribution systems
of today.

\section{The ``File Hierarchy Standard''}
\label{existing;fhs}

The current FHS\cite{fhs-site} only includes support for the
\directory{/lib}{\em qual} form with {\em qual} being 32 or 64 depending
on the pointer size.  There are proposals for adding other structures
with the most common being \directory{/lib/}{\em architecture}
\cite{taggart-multiarch} \cite{tfheen-multiarch3}.  Another proposal
was using the already existing support for a
\directory{/usr/}{\em architecture} which is well-supported in the
toolchain, but usually used for cross-compilation, not for binaries of
a ``foreign'' architecture.

\section{Current multiarch support in packaging tools}

The support for multiarch in the current set of packaging tools is
mostly missing with a few exceptions.  One such exception is RPM,
which supports installing packages for multiple architectures.  

By inspection of Fedora Core 3 RPMs, it does not seems to special-case
cross-architecture dependencies.  Most dependencies on
binary files are file-based dependencies rather than dependencies on
packages.  The dependencies are just on ``64 bit'' without any further
specification, so it is prone to confusing ia64-linux and
x86\_64-linux, for instance.  File dependencies by themselves are hard
to get right since you need to make sure only one package in the
distribution provides the file depended on.