\chapter{Evaluation}

This chapter describes how to solve the problems as described in the
problem definition.  There are two ``extreme'' alternatives: write
something from scratch or build on one of the existing solutions.
Starting from scratch gives a lot of possibilities, but it also means
more work and a higher risk of errors.  Starting from a known code base
means one can start working on the needed features right away, but doing
so means one is tied to the current design, which might get in the way
of the wanted result.

Dpkg has been in development for over ten years, \rpm a bit shorter,
but it's also fairly old.  If one were to develop a new tool, it would
not be feasible to have equivalent functionality in significantly (one
magnitude or more) less time.  In addition, the existing tools have
been used and thereby proven by a lot of users over time.  A new tool
would need time to be proven in the same way.  Because of this,
investigating the existing solutions rather than developing something
from scratch is the most interesting approach.

\section{Evaluation}

Following is an evaluation of the different tools with regard to the
requirements pointed out in the problem specification.

\subsection{dpkg}

Dpkg is well-integrated with existing tools such as \apt.  \apt handles
different releases and mixing of those easily.  Dpkg also has rich
semantics when it comes to dependencies and conflicts.  This makes it a
good candidate for extending, even though it is lacking in the
programming interfaces department.

\subsection{RPM}

\rpm doesn't support any repositories by itself, but it is
well-supported by way of \apt, yum or a number of similar tools.  None
of those support recursive repositories, but as described, that can be
emulated.  The repository tool would also be responsible for handling
different release levels.

\subsection{BSD Ports}

\bsd Ports lacks several important features, and while it could be a
good basis to build on, one would use a fair amount of resources to
build an infrastructure which matches \rpm's or dpkg's.  It has a
strength that it is cross-platform due to only depending on standardised
tools like make.

\section{Ranking}

None of the systems support repositories by themselves, but both \rpm
and dpkg does it through \apt (or similar tools).  \rpm is already
librarified and supports a fair amount of extra functionality
internally, which need external tools for dpkg.  Dpkg is more
\unix-like with small tools and interfaces with them.  This means
further development on dpkg is more likely to succeed, and there is
developer support already for some of the needed changes.


 The following changes, to dpkg itself, or related
components, need to be implemented.  Note that not all the
requirements in the problem definition are touched, as dpkg is already
a working software distribution system and therefore has several of
the requirements fulfilled already.

\begin{itemize}
\item {\em Keep system consistent across system boundaries such as hosts
    or architectures.}  Currently, dpkg has no support for this at all.
  It is realized through combinations of tools such as
  pkgsync\cite{package-pkgsync} with rdist\cite{rdist-site} or
  cfengine\cite{cfengine-site}.  Those tools would need to be extended,
  or procedures such as putting the pkgsync configuration in a file
  which is installed by pkgsync itself would have to be developed.  This
  fulfills the ``keep system consistent'' requirement in section
  \ref{pd_packaging_systems}.
    
\item {\em Recursive repository support} will make managing autonomous
  sites, regional differences a lot easier.  This would be handled by
  \apt, not dpkg itself.  A way to do it would be to have
  ``meta-repositories'' which just pointed to other repositories for
  most of the files (in order to save disk space on the repository).
  This solves the problems surrounding ``autonomous sites'' and
  ``regional differences'' in section \ref{pd_packaging_systems}.

\item {\em Support for multiple architectures.} Dpkg would have to be
  extended to know about what architectures the installation supports,
  either natively or through emulation.  The syntax of the control file
  fields in dpkg would also have to be extended, as they are currently
  unable to differ between architecture-dependent and
  architecture-independent dependencies.  Some proposals on how to solve
  this has already been made, see \cite{taggart-multiarch}
  \cite{tfheen-multiarch3}.

  While this isn't part of the problem definition, it is supported by
  other other packaging systems.  It also solves some problems related
  to moving from one architecture to another.

\item {\em Plugin and hooks support}.  The dpkg maintainer has already
  talked about where he sees dpkg moving\cite{sjr-dpkg-next}, including
  triggers and libdpkg, mostly in terms of what features are desirable
  rather than how they should be implemented.  This solves scalability
  problems related to dependencies in ``Package choices'' in
  section \ref{pd_packaging_systems}.

\end{itemize}

