\chapter{Design of an production-ready implementation}

A design along the lines as suggested in
\cite{dpkg-site-featuredepends} would require support for a number of
new features.  A feature is here loosely defined as ``something the
program should do with a certain amount of size and complexity''.
Features can be overlapping, but they should generally be orthogonal.
Dpkg needs some changes to support the FeatureDependencies (from
\cite{dpkg-site-featuredepends}) specification.

\section{Dpkg changes}

\begin{itemize}
\item dpkg-provided packages.
\item Ability to extract features ``smartly'' by tools such as
  dpkg-shlibdeps.
\item Extending the syntax of control files to be able to say ``this
  package with this feature''.  Examples would be ``Depends:
  \pkg{libfoo:i386}''
\item Continued support for sharing of symlinks with common targets
  between packages.
\end{itemize}

\subsection{dpkg-provided packages}

Impact: small

Current packages do not have an explicit dependency on the ABI they
need.  It works out well due to each system having one and only one
architecture and the ABI thereby being implicitly defined from the
packages depended on and the architecture of the package.  The
architecture is an implicit and second class citizen,
dependency-wise.

To solve this and make the architecture a first-class citizen, the ABI
should be specified in the Depends field.  Since providing the system
ABI doesn't belong naturally to any package, it should be a
non-existing, dpkg-provided package.  The ABIs should be determined at
run-time as they can change based on the installation and removal of
emulator packages.

\subsection{Smart extraction of features}

Impact: medium

As part of most packages's build process, dpkg-shlibdeps is run.  It
looks at the programs in the package and what libraries those link to.
Then it checks a file which says at what point those libraries last
changed their ABI and writes appropriate dependency information into a
``substvars'' file.  Dpkg-shlibdeps needs to be extended to include
the full ABI information in the substvars file.

In addition, it must be possible to specify a list of features by
hand in the regular ``debian/control'' file.

\subsection{Features in Depends fields}

Impact: big

Currently, the only information one can specify in a Depends field is
a package with an optional versioned relation (less than, less than or
equal, equal, equal than or bigger or bigger than).  This must be
changed to a syntax which allows specification of features.

It is here important to distinguish between the syntax of
debian/control in the source package and DEBIAN/control in the binary
package.  (See \cite{debian-policy/binarypackage/control} and
\cite{debian-policy/sourcepackage/control} for more information on the
difference between those two files.) The former must be easy to both
read and write for humans.  The latter must be parseable for computers
(but still be possible to read for humans).  The proposal here lists
two different syntaxes for specifying features depending on which file
is the relevant one

\subsubsection{Source package}

The syntax of the human-readable debian/control should be:
\begin{lstlisting}[frame=tRBl,columns=fullflexible]
Depends: package:<feature1 feature2>
\end{lstlisting}
Feature can (for instance) be ``gnome2'' or ``i386-linux''.

\subsubsection{Binary package}

The syntax in the binary package's DEBIAN/control should be:
\begin{lstlisting}[frame=tRBl,columns=fullflexible]
Depends: package:feature1, package:feature2
\end{lstlisting}
This is because generation of extra parts of the Depends line is a lot
easier when split up rather than inside a set of brackets.

\begin{example}
An example is the source debian/control file
\lstset{language=DebControl}
\begin{lstlisting}[columns=fullflexible]
Package: bazaar
Depends: libc6, diff:<any>, patch:<any>
\end{lstlisting}
which would become the binary DEBIAN/control file

\begin{lstlisting}[columns=fullflexible]
Package: bazaar
Depends: system:i386, libc6:i386, diff, patch
\end{lstlisting}
\end{example}

The parser in dpkg needs to be adjusted to interpret this syntax
correctly, both in the source and binary packages.

\subsection{Sharing of symlinks with common target}

Impact: small

At the moment, any overlap in files between two packages will cause
dpkg to error out on installation with an error message.  Debian
policy requires the copyright information for a package to be
available as \directory{/usr/share/doc/}\\{\em
  package}\directory{/copyright}.  This will, naturally, cause trouble
with multiarch and dpkg will therefore be changed so a symlink with a
common name and target is reference-counted and can be shared between
different packages.  This is similar to how directories are handled.

The code for this support can be copied off the prototype, but it
needs a bit more work.  It currently just removes the symlink on
remove, which is obviously wrong and it should rather have some
reference-counting code in there.  The already existing conflict
handling should kick in if a new package with a symlink pointing to
somewhere else is installed.

\section{Other affected systems}

Dpkg isn't the only tool which interprets and uses package
relationships.  As both the syntax and the semantics of the control
file fields change all of those tools might need updating.  No
exhaustive list exists, but the most prominent ones are:

\begin{itemize}
\item dak, also known as katie.  Those are the scripts used for
  managing the Debian archive.
\item linda, lintian.  Those packages are tools which are used to
  ``lint'' packages for common errors and mistakes.
\item apt, dselect, aptitude, synaptic.  All package managers handle
  dependencies between different packages.  They need to show the
  features provided by different packages and which of those causes
  conflicts.
\end{itemize}
