[Aptitude-svn-commit] r3261 - in branches/aptitude-0.3/aptitude: . src/generic/problemresolver
Daniel Burrows
dburrows@costa.debian.org
Thu, 05 May 2005 01:32:36 +0000
Author: dburrows
Date: Thu May 5 01:32:33 2005
New Revision: 3261
Modified:
branches/aptitude-0.3/aptitude/ChangeLog
branches/aptitude-0.3/aptitude/src/generic/problemresolver/model.tex
Log:
Finish off the dependency model document for now.
Modified: branches/aptitude-0.3/aptitude/ChangeLog
==============================================================================
--- branches/aptitude-0.3/aptitude/ChangeLog (original)
+++ branches/aptitude-0.3/aptitude/ChangeLog Thu May 5 01:32:33 2005
@@ -2,6 +2,11 @@
* src/generic/problemresolver/model.tex:
+ More Stuff[tm] -- wrote up some comments on Recommends, added a
+ Future Work section.
+
+ * src/generic/problemresolver/model.tex:
+
Edit a bunch of stuff in the document, and write up that second proof.
2005-05-01 Daniel Burrows <dburrows@debian.org>
Modified: branches/aptitude-0.3/aptitude/src/generic/problemresolver/model.tex
==============================================================================
--- branches/aptitude-0.3/aptitude/src/generic/problemresolver/model.tex (original)
+++ branches/aptitude-0.3/aptitude/src/generic/problemresolver/model.tex Thu May 5 01:32:33 2005
@@ -68,6 +68,16 @@
resolutions.
\end{abstract}
+\begin{note}
+ This is a work in progress; it sometimes lags behind or jumps ahead
+ of the current state of the software it documents, and some of the
+ details may be incomplete or unattended to. However, I hope that it
+ provides some more insight into the direction in which
+ \pkg{aptitude}'s problem resolver is headed -- and in which I
+ believe that other installation frontends should also consider
+ heading.
+\end{note}
+
\section{Introduction}
It is common nowadays for hundreds or thousands of software packages
@@ -774,10 +784,10 @@
\begin{figure}
\begin{gather*}
\inferrule{I \not \satisfies d \\ d = v -> S \\
- I(v)=I_0(v) \\ \pkgof{v'}=\pkgof{v} \\ v' \not \in F}
+ I(v)=I_0(v) \\ \pkgof{v'}=\pkgof{v} \\ v' \notin F}
{(I,F) \nsol{I_0}{d} (I;v',F \cup S)} \\
\inferrule{I \not \satisfies d \\ d = v -> S \\ v' \in S \\
- I(v')=I_0(v') \\ v' \not \in F}
+ I(v')=I_0(v') \\ v' \notin F}
{(I,F) \nsol{I_0}{d} (I;v', F)}
\end{gather*}
@@ -868,9 +878,131 @@
installations exist, they are accumulated and a successor formed by
adding these installations to $I$ is placed into the open queue.
+\section{Non-mandatory Dependencies}
+
+In addition to the standard Depends metadata, Debian also has a class
+of dependencies known as ``recommendations''. In the words of section
+7.2 of Debian's technical policy:
+
+\begin{quote}
+ Recommends: This declares a strong, but not absolute dependency.
+
+ The Recommends field should list packages that would be found
+ together with [the recommending package] in all but unusual
+ installations.
+\end{quote}
+
+Package management frontends adopt a variety of strategies to deal
+with recommendations, ranging from completely ignoring them to
+treating them nearly as strictly as dependencies. The current best
+practice seems to be the rule ``install recommendations when a package
+is first installed; ignore them otherwise''.
+
+In this section, I will propose one way in which the above theory and
+algorithm can be extended to accomodate these non-mandatory
+relationships.
+
+\subsection{``Hard'' and ``Soft''}
+
+The information content of a recommendation is equivalent to that of a
+dependency, and so it makes sense to represent a recommendation in our
+formal model as a special type of dependency. I will divide
+dependencies into two classes: ``hard'' dependencies and ``soft''
+dependencies. ``soft'' dependencies, of course, represent
+recommendations\footnote{Or, to be more precise, recommendations of
+ packages that are not presently installed, in accordance with the
+ abovementioned rule.}.
+
+Now, although ``soft'' dependencies need not be satisfied in an
+eventual solution, we would like the algorithm to at least \emph{try}
+to satisfy them, and in fact it should to make a reasonably
+significant effort to satisfy them. In order to ensure that this is
+done, I suggest the following techniques:
+
+\begin{figure}
+ \begin{gather*}
+ \inferrule{d \notin C \\
+ I \not \satisfies d \\ d = v -> S \\
+ I(v)=I_0(v) \\ \pkgof{v'}=\pkgof{v} \\ v' \not \in F}
+ {(I,F,C) \nsol{I_0}{d} (I;v',F \cup S,C)} \\
+ \inferrule{d \notin C \\
+ I \not \satisfies d \\ d = v -> S \\ v' \in S \\
+ I(v')=I_0(v') \\ v' \not \in F}
+ {(I,F,C) \nsol{I_0}{d} (I;v', F,C)} \\
+ \inferrule{I \not \satisfies d \\ d \text{ is soft}}
+ {(I,F,C) \nsol{I_0}{d} (I,F,C \cup \{d\})}
+ \end{gather*}
+
+ \caption{Successor generation with soft dependencies}
+ \label{fig:excludever}
+\end{figure}
+
+\begin{itemize}
+\item Extend the state of search nodes with an additional set $C$,
+ representing the dependencies that have been ``closed'' by being
+ examined at least once. As shown in Figure~\vref{fig:excludever},
+ extend successor generation to permit the algorithm to ``give up''
+ on any open soft dependency: in addition to generating successors
+ for the various way of solving that dependency, it will also
+ generate a successor in which no package states are changed, but the
+ dependency is closed anyway.
+\item Penalize broken soft dependencies, to reward solutions that
+ fulfill soft dependencies.
+\end{itemize}
+
+This has not yet been tested, but will likely require some rebalancing
+of the various weighting factors previously discussed in order to
+produce reasonable results.
+
\section{Implementation}
-A prototype implementation exists in the experimental branch of
-\pkg{aptitude}.
+A prototype implementation of this resolver algorithm exists in the
+experimental branch of \pkg{aptitude}. The implementation is composed
+of two pieces, which are assembled via C++ templates: a search
+algorithm for a generic dependency problem, and a runtime translation
+of APT dependencies to the generic form outlined above. It does not
+implement ``soft'' dependencies, although their future inclusion is
+planned.
+
+The current implementation seems to perform reasonably well: in the
+cases that I have tested, solutions are generated quickly enough for
+interactive use. However, the order in which solutions are offered is
+sometimes surprising: for instance, if the installation of a package
+causes problems, it is common for the first generated solution to be
+``cancel this installation''. While, as noted above, there is no
+perfect solution even in principle and any static weighting is likely
+to occasionally produce odd results, I expect that some of these
+problems can be fixed through adjustments of the score function.
+
+\section{Future Work}
+
+As noted above, the score function needs to be adjusted and soft
+dependencies need to be supported. In addition, some consideration of
+the following questions seems worthwhile to me:
+
+\begin{enumerate}
+\item Is it ever possible to ``divide and conquer'' a dependency
+ problem?
+
+ Rationale: as noted towards the beginning of this paper, informal
+ analyses of dependency problems often seem to adopt a ``divide and
+ conquer'' approach. Moreover, such an approach would have several
+ important user interface benefits: for instance, it would avoid the
+ tendency of the algorithm to produce the Cartesian product of all
+ the different ways to solve each isolated group of dependency
+ problems.
+
+ I do not, however, see an obvious simple way of performing such a
+ division.
+
+\item Can and should ``overly similar'' solutions be detected and
+ dropped?
+
+ When a solution implicates a large number of packages, the current
+ algorithm tends to produce many solutions which differ only slightly
+ from one another. From a user-interface perspective, it might be
+ desirable to drop some of these solutions. What metric, if any,
+ should be used to perform this dropping?
+\end{enumerate}
\end{document}