\chapter{Further work}

Further work in this case constists of two parts:  Going deeper into
the work and finding bugs and fixing applications to work and
understand multiarch correctly.  The other part is alternative
approaches.

\section{Fixing bugs and applications}

Some of the applications which need to be fixed are

\begin{itemize}
\item libtool.  Needs to know about the new paths and in many cases it
  would be useful if it searched for libraries properly instead of
  relying on hard-coded paths.  Without this fix, moving a library
  another library needs to link means applications using the latter
  library will fail to build.
\item pango (and other libraries using configuration files).  Pango is
  a library implementing Unicode support for GTK+ applications.  It
  has support for plugins implemented as shared objects and loaded at
  run-time.  Those are found using a configuration file which lists
  all the plugins and their properties.  The problem is that the
  configuration file actually lists the full path to the plugins.  As
  the configuration file has no architecture component, this will have
  to be solved by not having the full path in the configuration file
  and using a search path, or through some other mean.
\end{itemize}

Pango is included here not because it is unique, but rather because it
shows an example of behaviour which is problematic when going from a
single architecture to multiple architectures.

\section{Alternative implementations}

Changing the file system layout is only one way to solve the multiarch
problem.  One other possibility is handling it all in kernel-space so
Linux/x86\_64 applications accessing \directory{/usr/lib} will see a
different directory from Linux/i386 applications.  This is certainly
possible, but requires changes in the kernel code and can be confusing
for the system administrator.  An interesting challenge would be to
decide how the packaging system would make sure to access the correct
library directory.
