\chapter{Implementation of a prototype}

Appendix \ref{appendix;patches} contains a set of patches used for
implemention of a prototype of the suggested solution.  It is both an
implementation of the file system layout as suggested by the proposals
referenced in section \ref{existing;fhs} as well as a the needed
changes to dpkg.

\section{Toolchain changes}

For packages to build correctly, the C library and the toolchain need
to become aware of the new directory structure.  The following changes
were implemented:

\begin{flushleft}
\begin{itemize}
\item common
  \begin{itemize}
  \item Move files into trees with the architecture name in the path.
  \item Split out any arch-independent files into its own package.
  \end{itemize}

\item glibc
  \begin{itemize}
  \item Add support for looking in \directory{/lib/}{\em architecture} and
    \directory{/usr/lib/}{\em architecture} to the run-time linker.
  \end{itemize}

  The patches for glibc are available in Appendix
  \ref{appendix;patches;glibc}.

\item binutils
  \begin{itemize}
  \item Add support to look in \directory{/lib/}{\em architecture} and
    \directory{/usr/lib/}{\em architecture} by default to the linker.
  \end{itemize}

  The patches for binutils are available in Appendix
  \ref{appendix;patches;binutils}.

\item gcc
  \begin{itemize}
  \item Add support to look in \directory{/lib/}{\em architecture} and
    \directory{/usr/lib/}{\em architecture} to the default set of linker
    options.
    \item Add support to look in
      \directory{/usr/include/}{\em architecture} for the C preprocessor.
  \end{itemize}

  The patches for gcc (version 3.4) are available in Appendix
  \ref{appendix;patches;gcc3.4}.

\item pkg-config
  \begin{itemize}
  \item Add \directory{/usr/lib/}{\em
      architecture}\directory{/pkgconfig} to the default search path
    for .pc files.
  \end{itemize}

  The patches for pkg-config are available in Appendix
  \ref{appendix;patches;pkg-config}.
\end{itemize}
\end{flushleft}

\section{Per-package changes}

The last package, pkg-config, does not strictly need to be changed in
a minimal implementation.  However, it is increasingly used as part of
the build chain and therefore included as an example of an auxiliary
tool which will need changes.  Other such tools are autoconf, automake
and libtool.  We can avoid changing those for the purpose of this
minimal implementation by taking care when passing parameters to the
configure script.

Once the changes to the toolchain are in place, the following changes
to a few packages are needed:

\begin{itemize}
\item Split the packages into architecture-independent and
  arch-dependent parts to avoid file overlap between packages.  Any
  overlaps will cause the packages not to be coinstallable as the
  package manager has no way to know which file is the correct one.
\item Making sure any architecture-dependent files either are in
  directories with the architecture as part of their name or that they
  include the architecture name themselves.  Most notably are proper
  libraries, but other examples are plugins or auxiliary data.
\item Packages using autoconf, automake and libtool should set the
  libdir variable to point to the right directory so any .la files
  installed have the correct contents.  The .la files are used by
  libtool as part of the link process to ensure the correct set of
  libraries are linked with.
\end{itemize}

\subsection{Example}

As an example, the \pkg{libogg} source package will be changed
from a regular, non-multiarched package to a multiarched one.  The
``common'' package will be called libogg-common.   The ``common''
development package will be called libogg-dev-common.  The actual
naming here is just a convention, there is nothing in the packaging
system which requires it to be named something in particular.

The \pkg{libogg0} package needs to depend on
\pkg{libogg0-common} due to Debian policy constraints with regards
to the shipping of a copyright.

Then all the architecture-independent files have to move to the
``-common'' package.  Since the package uses debhelper, simply
adjusting the .install file suffices.

The build system needs some minor changes too.  As the package uses
autoconf and automake the change needed is limited to the call to
configure which has ``\verb|--libdir|'' and
``\verb|--includedir|'' parameters added.

The patches for this are in Appendix \ref{appendix;patches;libogg}.


\section{Package manager changes}

Dpkg itself needs fairly minimal fixes:

\begin{itemize}
\item Handle the ``Multi-Arch'' field so a package can be installed
  multiple times for different architectures.  This requires changes
  to dpkg itself as well as dpkg-gencontrol to not strip out the field
  when building a package.
\item Support installing packages for ``foreign'' architectures.
\item Handle the case of a symlink pointing to a directory and being
  owned by different packages as a special case.  Dpkg should allow it
  an reference-count the link rather than the default behaviour which
  is to exit with an error because of the overlapping file.
  (This is required by Debian's policy of all packages being required
  to have a \directory{/usr/share/doc/}{\em packagename} which shall be a
  directory or a symlink to a package built by the same source
  package.  This is because the package has to ship a license, which
  is usually contained in \directory{/usr/share/doc/}{\em packagename}\directory{/copyright})
\end{itemize}

This is a preliminary prototype and in no way intended for general
usage.  It shows the point and demonstrates that multiarch this way is
possible and works.  

A filtered set of patches are in Appendix \ref{appendix;patches;dpkg}.  All
auto-generated files such as those made by automake, autoconf and
libtool are removed from the set of patches due to space and
readability reasons.  The dpkg patches in that set build upon work
done previously by Hugo Mills as part of an earlier push for
multiarch.  His work in turn was based up specifications and ideas as
published in \cite{tfheen-multiarch3} and \cite{tfheen-multiarch2} by
this author.

While the implementation was written, the upstream author of dpkg has
continued development and provided further changes and some extensions
on the idea into ``Feature
dependencies''\cite{dpkg-site-featuredepends}.  This will supersede
the prototype implementation.

