* latex'e cevir, guzellestir ortami
* review'a graph theory'le ilgili bir paragraf yaz.
This commit is contained in:
Eray Özkural
@@ -0,0 +1,79 @@
|
|||||||
|
% ALGORITHM STYLE -- Released 8 April 1996
|
||||||
|
% for LaTeX-2e
|
||||||
|
% Copyright -- 1994 Peter Williams
|
||||||
|
% E-mail Peter.Williams@dsto.defence.gov.au
|
||||||
|
\NeedsTeXFormat{LaTeX2e}
|
||||||
|
\ProvidesPackage{algorithm}
|
||||||
|
\typeout{Document Style `algorithm' - floating environment}
|
||||||
|
|
||||||
|
\RequirePackage{float}
|
||||||
|
\RequirePackage{ifthen}
|
||||||
|
\newcommand{\ALG@within}{nothing}
|
||||||
|
\newboolean{ALG@within}
|
||||||
|
\setboolean{ALG@within}{false}
|
||||||
|
\newcommand{\ALG@floatstyle}{ruled}
|
||||||
|
\newcommand{\ALG@name}{Algorithm}
|
||||||
|
\newcommand{\listalgorithmname}{List of \ALG@name s}
|
||||||
|
|
||||||
|
% Declare Options
|
||||||
|
% first appearance
|
||||||
|
\DeclareOption{plain}{
|
||||||
|
\renewcommand{\ALG@floatstyle}{plain}
|
||||||
|
}
|
||||||
|
\DeclareOption{ruled}{
|
||||||
|
\renewcommand{\ALG@floatstyle}{ruled}
|
||||||
|
}
|
||||||
|
\DeclareOption{boxed}{
|
||||||
|
\renewcommand{\ALG@floatstyle}{boxed}
|
||||||
|
}
|
||||||
|
% then numbering convention
|
||||||
|
\DeclareOption{part}{
|
||||||
|
\renewcommand{\ALG@within}{part}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption{chapter}{
|
||||||
|
\renewcommand{\ALG@within}{chapter}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption{section}{
|
||||||
|
\renewcommand{\ALG@within}{section}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption{subsection}{
|
||||||
|
\renewcommand{\ALG@within}{subsection}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption{subsubsection}{
|
||||||
|
\renewcommand{\ALG@within}{subsubsection}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption{nothing}{
|
||||||
|
\renewcommand{\ALG@within}{nothing}
|
||||||
|
\setboolean{ALG@within}{true}
|
||||||
|
}
|
||||||
|
\DeclareOption*{\edef\ALG@name{\CurrentOption}}
|
||||||
|
|
||||||
|
% ALGORITHM
|
||||||
|
%
|
||||||
|
\ProcessOptions
|
||||||
|
\floatstyle{\ALG@floatstyle}
|
||||||
|
\ifthenelse{\boolean{ALG@within}}{
|
||||||
|
\ifthenelse{\equal{\ALG@within}{part}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}[part]}{}
|
||||||
|
\ifthenelse{\equal{\ALG@within}{chapter}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}[chapter]}{}
|
||||||
|
\ifthenelse{\equal{\ALG@within}{section}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}[section]}{}
|
||||||
|
\ifthenelse{\equal{\ALG@within}{subsection}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}[subsection]}{}
|
||||||
|
\ifthenelse{\equal{\ALG@within}{subsubsection}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}[subsubsection]}{}
|
||||||
|
\ifthenelse{\equal{\ALG@within}{nothing}}
|
||||||
|
{\newfloat{algorithm}{htbp}{loa}}{}
|
||||||
|
}{
|
||||||
|
\newfloat{algorithm}{htbp}{loa}
|
||||||
|
}
|
||||||
|
\floatname{algorithm}{\ALG@name}
|
||||||
|
|
||||||
|
\newcommand{\listofalgorithms}{\listof{algorithm}{\listalgorithmname}}
|
||||||
|
|
||||||
@@ -0,0 +1,158 @@
|
|||||||
|
% ALGORITHMIC STYLE -- Released 8 APRIL 1996
|
||||||
|
% for LaTeX version 2e
|
||||||
|
% Copyright -- 1994 Peter Williams
|
||||||
|
% E-mail PeterWilliams@dsto.defence.gov.au
|
||||||
|
\NeedsTeXFormat{LaTeX2e}
|
||||||
|
\ProvidesPackage{algorithmic}
|
||||||
|
\typeout{Document Style `algorithmic' - environment}
|
||||||
|
%
|
||||||
|
\RequirePackage{ifthen}
|
||||||
|
\RequirePackage{calc}
|
||||||
|
\newboolean{ALC@noend}
|
||||||
|
\setboolean{ALC@noend}{false}
|
||||||
|
\newcounter{ALC@line}
|
||||||
|
\newcounter{ALC@rem}
|
||||||
|
\newlength{\ALC@tlm}
|
||||||
|
%
|
||||||
|
\DeclareOption{noend}{\setboolean{ALC@noend}{true}}
|
||||||
|
%
|
||||||
|
\ProcessOptions
|
||||||
|
%
|
||||||
|
% ALGORITHMIC
|
||||||
|
\newcommand{\algorithmicrequire}{\textbf{Require:}}
|
||||||
|
\newcommand{\algorithmicensure}{\textbf{Ensure:}}
|
||||||
|
\newcommand{\algorithmiccomment}[1]{\{#1\}}
|
||||||
|
\newcommand{\algorithmicend}{\textbf{end}}
|
||||||
|
\newcommand{\algorithmicif}{\textbf{if}}
|
||||||
|
\newcommand{\algorithmicthen}{\textbf{then}}
|
||||||
|
\newcommand{\algorithmicelse}{\textbf{else}}
|
||||||
|
\newcommand{\algorithmicelsif}{\algorithmicelse\ \algorithmicif}
|
||||||
|
\newcommand{\algorithmicendif}{\algorithmicend\ \algorithmicif}
|
||||||
|
\newcommand{\algorithmicfor}{\textbf{for}}
|
||||||
|
\newcommand{\algorithmicforall}{\textbf{for all}}
|
||||||
|
\newcommand{\algorithmicdo}{\textbf{do}}
|
||||||
|
\newcommand{\algorithmicendfor}{\algorithmicend\ \algorithmicfor}
|
||||||
|
\newcommand{\algorithmicwhile}{\textbf{while}}
|
||||||
|
\newcommand{\algorithmicendwhile}{\algorithmicend\ \algorithmicwhile}
|
||||||
|
\newcommand{\algorithmicloop}{\textbf{loop}}
|
||||||
|
\newcommand{\algorithmicendloop}{\algorithmicend\ \algorithmicloop}
|
||||||
|
\newcommand{\algorithmicrepeat}{\textbf{repeat}}
|
||||||
|
\newcommand{\algorithmicuntil}{\textbf{until}}
|
||||||
|
\def\ALC@item[#1]{%
|
||||||
|
\if@noparitem \@donoparitem
|
||||||
|
\else \if@inlabel \indent \par \fi
|
||||||
|
\ifhmode \unskip\unskip \par \fi
|
||||||
|
\if@newlist \if@nobreak \@nbitem \else
|
||||||
|
\addpenalty\@beginparpenalty
|
||||||
|
\addvspace\@topsep \addvspace{-\parskip}\fi
|
||||||
|
\else \addpenalty\@itempenalty \addvspace\itemsep
|
||||||
|
\fi
|
||||||
|
\global\@inlabeltrue
|
||||||
|
\fi
|
||||||
|
\everypar{\global\@minipagefalse\global\@newlistfalse
|
||||||
|
\if@inlabel\global\@inlabelfalse \hskip -\parindent \box\@labels
|
||||||
|
\penalty\z@ \fi
|
||||||
|
\everypar{}}\global\@nobreakfalse
|
||||||
|
\if@noitemarg \@noitemargfalse \if@nmbrlist \refstepcounter{\@listctr}\fi \fi
|
||||||
|
\sbox\@tempboxa{\makelabel{#1}}%
|
||||||
|
\global\setbox\@labels
|
||||||
|
\hbox{\unhbox\@labels \hskip \itemindent
|
||||||
|
\hskip -\labelwidth \hskip -\ALC@tlm
|
||||||
|
\ifdim \wd\@tempboxa >\labelwidth
|
||||||
|
\box\@tempboxa
|
||||||
|
\else \hbox to\labelwidth {\unhbox\@tempboxa}\fi
|
||||||
|
\hskip \ALC@tlm}\ignorespaces}
|
||||||
|
%
|
||||||
|
\newenvironment{algorithmic}[1][0]{
|
||||||
|
\let\@item\ALC@item
|
||||||
|
\newcommand{\ALC@lno}{%
|
||||||
|
\ifthenelse{\equal{\arabic{ALC@rem}}{0}}
|
||||||
|
{{\footnotesize \arabic{ALC@line}:}}{}%
|
||||||
|
}
|
||||||
|
\let\@listii\@listi
|
||||||
|
\let\@listiii\@listi
|
||||||
|
\let\@listiv\@listi
|
||||||
|
\let\@listv\@listi
|
||||||
|
\let\@listvi\@listi
|
||||||
|
\let\@listvii\@listi
|
||||||
|
\newenvironment{ALC@g}{
|
||||||
|
\begin{list}{\ALC@lno}{ \itemsep\z@ \itemindent\z@
|
||||||
|
\listparindent\z@ \rightmargin\z@
|
||||||
|
\topsep\z@ \partopsep\z@ \parskip\z@\parsep\z@
|
||||||
|
\leftmargin 1em
|
||||||
|
\addtolength{\ALC@tlm}{\leftmargin}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
{\end{list}}
|
||||||
|
\newcommand{\ALC@it}{\addtocounter{ALC@line}{1}\addtocounter{ALC@rem}{1}\ifthenelse{\equal{\arabic{ALC@rem}}{#1}}{\setcounter{ALC@rem}{0}}{}\item}
|
||||||
|
\newcommand{\ALC@com}[1]{\ifthenelse{\equal{##1}{default}}%
|
||||||
|
{}{\ \algorithmiccomment{##1}}}
|
||||||
|
\newcommand{\REQUIRE}{\item[\algorithmicrequire]}
|
||||||
|
\newcommand{\ENSURE}{\item[\algorithmicensure]}
|
||||||
|
\newcommand{\STATE}{\ALC@it}
|
||||||
|
\newcommand{\COMMENT}[1]{\algorithmiccomment{##1}}
|
||||||
|
\newenvironment{ALC@if}{\begin{ALC@g}}{\end{ALC@g}}
|
||||||
|
\newenvironment{ALC@for}{\begin{ALC@g}}{\end{ALC@g}}
|
||||||
|
\newenvironment{ALC@whl}{\begin{ALC@g}}{\end{ALC@g}}
|
||||||
|
\newenvironment{ALC@loop}{\begin{ALC@g}}{\end{ALC@g}}
|
||||||
|
\newenvironment{ALC@rpt}{\begin{ALC@g}}{\end{ALC@g}}
|
||||||
|
\renewcommand{\\}{\@centercr}
|
||||||
|
\newcommand{\IF}[2][default]{\ALC@it\algorithmicif\ ##2\ \algorithmicthen%
|
||||||
|
\ALC@com{##1}\begin{ALC@if}}
|
||||||
|
\newcommand{\ELSE}[1][default]{\end{ALC@if}\ALC@it\algorithmicelse%
|
||||||
|
\ALC@com{##1}\begin{ALC@if}}
|
||||||
|
\newcommand{\ELSIF}[2][default]%
|
||||||
|
{\end{ALC@if}\ALC@it\algorithmicelsif\ ##2\ \algorithmicthen%
|
||||||
|
\ALC@com{##1}\begin{ALC@if}}
|
||||||
|
\newcommand{\FOR}[2][default]{\ALC@it\algorithmicfor\ ##2\ \algorithmicdo%
|
||||||
|
\ALC@com{##1}\begin{ALC@for}}
|
||||||
|
\newcommand{\FORALL}[2][default]{\ALC@it\algorithmicforall\ ##2\ %
|
||||||
|
\algorithmicdo%
|
||||||
|
\ALC@com{##1}\begin{ALC@for}}
|
||||||
|
\newcommand{\WHILE}[2][default]{\ALC@it\algorithmicwhile\ ##2\ %
|
||||||
|
\algorithmicdo%
|
||||||
|
\ALC@com{##1}\begin{ALC@whl}}
|
||||||
|
\newcommand{\LOOP}[1][default]{\ALC@it\algorithmicloop%
|
||||||
|
\ALC@com{##1}\begin{ALC@loop}}
|
||||||
|
\newcommand{\REPEAT}[1][default]{\ALC@it\algorithmicrepeat%
|
||||||
|
\ALC@com{##1}\begin{ALC@rpt}}
|
||||||
|
\newcommand{\UNTIL}[1]{\end{ALC@rpt}\ALC@it\algorithmicuntil\ ##1}
|
||||||
|
\ifthenelse{\boolean{ALC@noend}}{
|
||||||
|
\newcommand{\ENDIF}{\end{ALC@if}}
|
||||||
|
\newcommand{\ENDFOR}{\end{ALC@for}}
|
||||||
|
\newcommand{\ENDWHILE}{\end{ALC@whl}}
|
||||||
|
\newcommand{\ENDLOOP}{\end{ALC@loop}}
|
||||||
|
}{
|
||||||
|
\newcommand{\ENDIF}{\end{ALC@if}\ALC@it\algorithmicendif}
|
||||||
|
\newcommand{\ENDFOR}{\end{ALC@for}\ALC@it\algorithmicendfor}
|
||||||
|
\newcommand{\ENDWHILE}{\end{ALC@whl}\ALC@it\algorithmicendwhile}
|
||||||
|
\newcommand{\ENDLOOP}{\end{ALC@loop}\ALC@it\algorithmicendloop}
|
||||||
|
}
|
||||||
|
\renewcommand{\@toodeep}{}
|
||||||
|
\begin{list}{\ALC@lno}{\setcounter{ALC@line}{0}\setcounter{ALC@rem}{0}%
|
||||||
|
\itemsep\z@ \itemindent\z@ \listparindent\z@%
|
||||||
|
\partopsep\z@ \parskip\z@ \parsep\z@%
|
||||||
|
\labelsep 0.5em \topsep 0.2em%
|
||||||
|
\ifthenelse{\equal{#1}{0}}
|
||||||
|
{\labelwidth 0.5em }
|
||||||
|
{\labelwidth 1.2em }
|
||||||
|
\leftmargin\labelwidth \addtolength{\leftmargin}{\labelsep}
|
||||||
|
\ALC@tlm\labelsep
|
||||||
|
}
|
||||||
|
}
|
||||||
|
{\end{list}}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Binary file not shown.
@@ -0,0 +1,197 @@
|
|||||||
|
|
||||||
|
%%% Local Variables:
|
||||||
|
%%% mode: latex
|
||||||
|
%%% TeX-master: t
|
||||||
|
%%% End:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\documentclass[a4paper,11pt]{article}
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\usepackage{algorithm}
|
||||||
|
\usepackage{algorithmic}
|
||||||
|
\usepackage{amsmath}
|
||||||
|
\usepackage{amstext}
|
||||||
|
\usepackage{amsfonts}
|
||||||
|
\usepackage{amsbsy}
|
||||||
|
\usepackage{amsthm}
|
||||||
|
\usepackage{prettyref}
|
||||||
|
%\newrefformat{alg}{Algorithm~\ref{#1}}
|
||||||
|
%\newrefformat{eq}{Equation~\ref{#1}}
|
||||||
|
%\newrefformat{lem}{Lemma~\ref{#1}}
|
||||||
|
%\newrefformat{thm}{Theorem~\ref{#1}}
|
||||||
|
%\newrefformat{chp}{Chapter~\ref{#1}}
|
||||||
|
%\newrefformat{sec}{Section~\ref{#1}}
|
||||||
|
%\newrefformat{apx}{Appendix~\ref{#1}}
|
||||||
|
%\newrefformat{tab}{Table~\ref{#1}}
|
||||||
|
%\newrefformat{fig}{Figure~\ref{#1}}
|
||||||
|
|
||||||
|
|
||||||
|
%usepackage[active]{srcltx}
|
||||||
|
\title{ Dependency Resolution in PISI}
|
||||||
|
|
||||||
|
\author{Eray \"{O}zkural}
|
||||||
|
|
||||||
|
\date{\today}
|
||||||
|
|
||||||
|
\begin{document}
|
||||||
|
|
||||||
|
\maketitle
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\section{Introduction}
|
||||||
|
|
||||||
|
Dependency resolution in package management systems have a
|
||||||
|
significance in that they are the key to providing system stability
|
||||||
|
and internet upgrades. The scale of package databases requires the
|
||||||
|
dependency resolution mechanism to be efficient and correct,
|
||||||
|
motivating a closer look at the theory.
|
||||||
|
|
||||||
|
|
||||||
|
\section{Review}
|
||||||
|
|
||||||
|
Dependency resolution has been taken in the most general setting as
|
||||||
|
the famous SAT problem of propositional logic. If we consider a system
|
||||||
|
$D$ of dependency statements $D_i$, each statement can be taken as a
|
||||||
|
proposition in propositional logic which states, for instance:
|
||||||
|
|
||||||
|
$D_i$: if package $a$ is installed or package $b$ is installed, then
|
||||||
|
package $i$ is installable.\\
|
||||||
|
...
|
||||||
|
|
||||||
|
The system is thus understood as the conjunction of such facts, giving
|
||||||
|
us a logical programming formulation to determine installation conditions.
|
||||||
|
|
||||||
|
Note that for simplicity we do not consider the nuances in upgrade and
|
||||||
|
remove operations at the moment.
|
||||||
|
|
||||||
|
However, using a SAT solver for this operation may be shooting a fly
|
||||||
|
with a bazooka. We observe that only certain forms of propositions
|
||||||
|
will be necessary for a dependency system. Furthermore, as we shall
|
||||||
|
see further constraints and optimizations may be required of the
|
||||||
|
system that are not modelled well with the SAT problem.
|
||||||
|
|
||||||
|
We use a graph theoretic approach instead. A directed graph (digraph)
|
||||||
|
$G=(V,E)$ is formally a set of vertices $V$ and a set of edges $E$
|
||||||
|
where each edge $(u,v)$ represents an edge from a vertex to
|
||||||
|
another. Topological sort of a graph gives a total ordering of the
|
||||||
|
vertices in which there are only forward edges.
|
||||||
|
|
||||||
|
\section{Package operation planning}
|
||||||
|
|
||||||
|
The dependency resolution problem may be viewed as a simple forward
|
||||||
|
chaining problem, where we would like to begin from an initial state
|
||||||
|
$S_0$ and by following allowable system transitions $t_i: S -> S$,
|
||||||
|
arrive at a desired system state $S_f$.
|
||||||
|
|
||||||
|
A system state $S_i$ is defined as the set of installed packages on the
|
||||||
|
system together with their versions, i.e. $S_i = \{ (x,v) : x is
|
||||||
|
installed, v=version(x)\} $. An atomic system transition $t_i$ chains one
|
||||||
|
system state into another, making one ACID change on the system. The
|
||||||
|
usual atomic transitions are the single package install, remove and
|
||||||
|
upgrade operations found in low-level package management code.
|
||||||
|
|
||||||
|
A package operation plan is thus naturally conceived of as a sequence
|
||||||
|
of atomic system transitions. Given an initial state and a final
|
||||||
|
state, the job of the package operation planner is to determine
|
||||||
|
whether there is a plan, and if so find the "best" one.
|
||||||
|
|
||||||
|
Where there are no versions involved (e.g. upgrade/downgrade), we will
|
||||||
|
replace the pair $(x,v)$ with $x$.
|
||||||
|
|
||||||
|
\subsection{System consistency}
|
||||||
|
|
||||||
|
It is worth mentioning here the concept of system consistency. As in a
|
||||||
|
database transaction, it is not acceptable that the system violates an
|
||||||
|
invariant afterwards. In the context of PISI, system consistency is
|
||||||
|
composed of two conditions for the current set of installed packages.
|
||||||
|
\begin{enumerate}
|
||||||
|
\item All package dependencies are satisfied (we may call this a
|
||||||
|
closed system)
|
||||||
|
\item No package conflicts are present.
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Therefore, by atomic transition we also mean one that does not corrupt
|
||||||
|
system consistency. The system is thus never in an inconsistent state.
|
||||||
|
|
||||||
|
|
||||||
|
\subsection{Solving the simplest case with topological sorting}
|
||||||
|
|
||||||
|
We will now concentrate on a simple form of the problem which can
|
||||||
|
be solved with topological sorting. This form is not concerned with
|
||||||
|
versions. From initial set of packages $S_0$, we would like to
|
||||||
|
install in addition a new set $A$ of packages obtaining $S_f = S_0 \cup
|
||||||
|
A$.
|
||||||
|
|
||||||
|
The only relations considered are of the form: $a$ Depends on $b$, or more
|
||||||
|
briefly $aDb$.
|
||||||
|
|
||||||
|
The graph of all such simple dependency relations is a directed graph
|
||||||
|
(digraph) $G$. For each dependency relation $aDB$, there is an edge $a
|
||||||
|
\to b$ in $G$. Accessing graph $G$ usually requires a database operation and
|
||||||
|
is therefore expensive.
|
||||||
|
|
||||||
|
We now consider the digraph $G_A$ of the minimal set of simple
|
||||||
|
dependency relations which contains all information required to
|
||||||
|
construct a plan to install packages $A$. $G_A$ is a vertex induced graph
|
||||||
|
such that the fringe of $A$, e.g. vertices with out-degree $0$ are
|
||||||
|
already installed. Vertices of $G_A$ are taken from $S_f$. First, let us
|
||||||
|
explain the labelling scheme. Already installed vertices are labelled
|
||||||
|
with 'i'. Packages to be added are labelled with 'a', and packages to
|
||||||
|
be installed due to dependencies are labelled with 'd'. We
|
||||||
|
construct the graph as follows
|
||||||
|
\begin{algorithm}
|
||||||
|
%\caption{$\textsc{Par-Freq}(T_i, \epsilon, \textsc{Mine-Freq} )$}
|
||||||
|
\label{alg:cons-graph}
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
\STATE $G_A \gets$ isolated vertex set $A$ labelled with 'a'
|
||||||
|
\REPEAT
|
||||||
|
\STATE done $\gets$ true
|
||||||
|
\FOR{each $u \in V_A$ with out-degree $0$}
|
||||||
|
\FOR{ $v \in adj(u) $ of $G$}
|
||||||
|
\IF{$v is \notin V_A$}
|
||||||
|
\STATE done $\gets$ false
|
||||||
|
\IF{$v$ is installed}
|
||||||
|
\STATE label $v$ with 'i'
|
||||||
|
\ELSE
|
||||||
|
\STATE label $v$ with 'd'
|
||||||
|
\ENDIF
|
||||||
|
\STATE add $(u,v)$ to $G_A$
|
||||||
|
\ENDIF
|
||||||
|
\ENDFOR
|
||||||
|
\ENDFOR
|
||||||
|
\UNTIL{done}
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
By this iterative expansion, we do a minimum number of database
|
||||||
|
accesses to $G$ and construct a dependency graph in memory. If the
|
||||||
|
$G_A$'s fringe has vertices with non 'i'-labels, then $A$ cannot be
|
||||||
|
installed. Otherwise, we find a topological sort $L$ of $G_A$, and in
|
||||||
|
the reverse order, install packages for vertices labelled with
|
||||||
|
'a' or 'd'.
|
||||||
|
|
||||||
|
\section{Complex cases}
|
||||||
|
|
||||||
|
\subsection{A complex upgrade}
|
||||||
|
|
||||||
|
plan: upgrade $(a,1)$ to $(a,2)$\\
|
||||||
|
\\
|
||||||
|
rules:
|
||||||
|
$(a,1)$ depends on $(b,1), (c,1)$ \\
|
||||||
|
$(a,1)$ conflicts with $(d,1)$\\
|
||||||
|
$(a,2)$ depends on $(c,3), (d,2)$\\
|
||||||
|
$(a,2)$ conflicts with $(b,1)$\\
|
||||||
|
\\
|
||||||
|
initial state:\\
|
||||||
|
$(a,1), (b,1), (c,1)$ installed \\
|
||||||
|
\\
|
||||||
|
plan:\\
|
||||||
|
remove $(b,1)$\\
|
||||||
|
upgrade $(c,1) -> (c,3)$\\
|
||||||
|
install $(d,2)$\\
|
||||||
|
upgrade $(a,1) -> (a,2)$\\
|
||||||
|
|
||||||
|
|
||||||
|
\end{document}
|
||||||
@@ -1,141 +0,0 @@
|
|||||||
Dependency Resolution in PISI
|
|
||||||
|
|
||||||
Eray Ozkural
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
|
|
||||||
Dependency resolution in package management systems have a
|
|
||||||
significance in that they are the key to providing system stability
|
|
||||||
and internet upgrades. The scale of package databases requires the
|
|
||||||
dependency resolution mechanism to be efficient and correct,
|
|
||||||
motivating a closer look at the theory.
|
|
||||||
|
|
||||||
|
|
||||||
2. Review
|
|
||||||
|
|
||||||
Dependency resolution has been taken in the most general setting as
|
|
||||||
the famous SAT problem of propositional logic. If we consider a system
|
|
||||||
D of dependency statements D_i, each statement can be taken as a
|
|
||||||
proposition in propositional logic which states, for
|
|
||||||
instance:
|
|
||||||
|
|
||||||
D_i: if package a is installed or package b is installed, then package i
|
|
||||||
is installable.
|
|
||||||
...
|
|
||||||
|
|
||||||
The system is thus understood as the conjunction of such facts, giving
|
|
||||||
us a logical programming system for determining installation conditions.
|
|
||||||
|
|
||||||
Note that for simplicity we do not consider the nuances in upgrade and
|
|
||||||
remove operations at the moment.
|
|
||||||
|
|
||||||
However, using a SAT solver for this operation may be shooting a fly
|
|
||||||
with a bazooka. We observe that only certain forms of propositions
|
|
||||||
will be necessary for a dependency system. Furthermore, as we shall
|
|
||||||
see further constraints and optimizations may be required of the
|
|
||||||
system that are not modelled well with SAT problem.
|
|
||||||
|
|
||||||
|
|
||||||
3. Package operation planning
|
|
||||||
|
|
||||||
The dependency resolution problem may be viewed as a simple forward
|
|
||||||
chaining problem, where we would like to begin from an initial state
|
|
||||||
S_0 and by following allowable system transitions t_i: S -> S,
|
|
||||||
arrive at a desired system state S_f.
|
|
||||||
|
|
||||||
A system state S_i is defined as the set of installed packages on the
|
|
||||||
system together with their versions, i.e. S_i = { (x,v) : x is
|
|
||||||
installed, v=version(x)}. An atomic system transition t_i chains one
|
|
||||||
system state into another, making one ACID change on the system. The
|
|
||||||
usual atomic transitions are the single package install, remove and
|
|
||||||
upgrade operations found in low-level package management code.
|
|
||||||
|
|
||||||
A package operation plan is thus naturally conceived of as a sequence
|
|
||||||
of atomic system transitions. Given an initial state and a final
|
|
||||||
state, the job of the package operation planner is to determine
|
|
||||||
whether there is a plan, and if so find the "best" one.
|
|
||||||
|
|
||||||
Where there are no versions involved (e.g. upgrade/downgrade), we will
|
|
||||||
replace the pair (x,v) with x.
|
|
||||||
|
|
||||||
3.1 System consistency
|
|
||||||
|
|
||||||
It is worth mentioning here the concept of system consistency. As in a
|
|
||||||
database transaction, it is not acceptable that the system violates an
|
|
||||||
invariant afterwards. In the context of PISI, system consistency is
|
|
||||||
composed of two conditions for the current set of installed packages.
|
|
||||||
1. All package dependencies are satisfied (we may call this a closed system)
|
|
||||||
2. No package conflicts are present.
|
|
||||||
|
|
||||||
Therefore, by atomic transition we also mean one that does not corrupt
|
|
||||||
system consistency. The system is thus never in an inconsistent state.
|
|
||||||
|
|
||||||
|
|
||||||
3.2 Solving the simplest case with topological sorting
|
|
||||||
|
|
||||||
We will now concentrate on a simple form of the problem which can
|
|
||||||
be solved with topological sorting. This form is not concerned with
|
|
||||||
versions. From initial set of packages S_0, we would like to
|
|
||||||
install in addition a new set A of packages obtaining S_f = S_0 \cup A.
|
|
||||||
|
|
||||||
The only relations considered are of the form: a Depends on b, or more
|
|
||||||
shortly aDb.
|
|
||||||
|
|
||||||
The graph of all such simple dependency relations is a directed graph
|
|
||||||
(digraph) G. For each dependency relation aDB, there is an edge a ->
|
|
||||||
b in G. Accessing graph G usually requires a database operation and
|
|
||||||
is therefore expensive.
|
|
||||||
|
|
||||||
We now consider the digraph G_A of the minimal set of simple
|
|
||||||
dependency relations which contains all information required to
|
|
||||||
construct a plan to install packages A. G_A is a vertex induced graph
|
|
||||||
such that the fringe of $A$, e.g. vertices with out-degree $0$ are
|
|
||||||
already installed. Vertices of G_A are taken from S_f. First, let us
|
|
||||||
explain the labelling scheme. Already installed vertices are labelled
|
|
||||||
with 'i'. Packages to be added are labelled with 'a', and packages to
|
|
||||||
be installed due to dependencies are labelled with 'd'. We
|
|
||||||
construct the graph as follows
|
|
||||||
|
|
||||||
G_A <- isolated vertex set A labelled with 'a'
|
|
||||||
repeat
|
|
||||||
done <- true
|
|
||||||
for each u in V_A with out-degree 0
|
|
||||||
for v in adj(u) in G
|
|
||||||
if v is not in V_A
|
|
||||||
done <- false
|
|
||||||
if v is installed
|
|
||||||
label v with 'i'
|
|
||||||
else
|
|
||||||
label v with 'd'
|
|
||||||
add (u,v) to G_A
|
|
||||||
until done
|
|
||||||
|
|
||||||
By this iterative expansion, we do a minimum number of database
|
|
||||||
accesses to G and construct a dependency graph in memory. If the
|
|
||||||
G_A's fringe has vertices with non 'i'-labels, then A cannot be
|
|
||||||
installed. Otherwise, we find a topological sort L of G_A, and in
|
|
||||||
the reverse order, install packages for vertices labelled with
|
|
||||||
'a' or 'd'.
|
|
||||||
|
|
||||||
4. Complex cases
|
|
||||||
|
|
||||||
4.1 A complex upgrade
|
|
||||||
|
|
||||||
plan: upgrade (a,1) to (a,2)
|
|
||||||
|
|
||||||
rules:
|
|
||||||
(a,1) depends on (b,1), (c,1)
|
|
||||||
(a,1) conflicts with (d,1)
|
|
||||||
(a,2) depends on (c,3), (d,2)
|
|
||||||
(a,2) conflicts with (b,1)
|
|
||||||
|
|
||||||
initial state:
|
|
||||||
(a,1), (b,1), (c,1) installed
|
|
||||||
|
|
||||||
plan:
|
|
||||||
remove (b,1)
|
|
||||||
upgrade (c,1) -> (c,3)
|
|
||||||
install (d,2)
|
|
||||||
upgrade (a,1) -> (a,2)
|
|
||||||
@@ -0,0 +1,37 @@
|
|||||||
|
%%
|
||||||
|
%% This is file `prettyref.sty',
|
||||||
|
%% generated with the docstrip utility.
|
||||||
|
%%
|
||||||
|
%% The original source files were:
|
||||||
|
%%
|
||||||
|
%% prettyref.dtx (with options: `style')
|
||||||
|
%%
|
||||||
|
%% Copyright (c) 1995 Kevin Ruland
|
||||||
|
%%
|
||||||
|
%%
|
||||||
|
%% prettyref v3.0
|
||||||
|
%%
|
||||||
|
%% Copyright 1995,1998. by Kevin Ruland kevin@rodin.wustl.edu
|
||||||
|
%%
|
||||||
|
\ProvidesPackage{prettyref}[1998/07/09 v3.0]
|
||||||
|
\def\newrefformat#1#2{%
|
||||||
|
\@namedef{pr@#1}##1{#2}}
|
||||||
|
\newrefformat{eq}{\textup{(\ref{#1})}}
|
||||||
|
\newrefformat{lem}{Lemma \ref{#1}}
|
||||||
|
\newrefformat{thm}{Theorem \ref{#1}}
|
||||||
|
\newrefformat{cha}{Chapter \ref{#1}}
|
||||||
|
\newrefformat{sec}{Section \ref{#1}}
|
||||||
|
\newrefformat{tab}{Table \ref{#1} on page \pageref{#1}}
|
||||||
|
\newrefformat{fig}{Figure \ref{#1} on page \pageref{#1}}
|
||||||
|
\def\prettyref#1{\@prettyref#1:}
|
||||||
|
\def\@prettyref#1:#2:{%
|
||||||
|
\expandafter\ifx\csname pr@#1\endcsname\relax%
|
||||||
|
\PackageWarning{prettyref}{Reference format #1\space undefined}%
|
||||||
|
\ref{#1:#2}%
|
||||||
|
\else%
|
||||||
|
\csname pr@#1\endcsname{#1:#2}%
|
||||||
|
\fi%
|
||||||
|
}
|
||||||
|
\endinput
|
||||||
|
%%
|
||||||
|
%% End of file `prettyref.sty'.
|
||||||
Reference in New Issue
Block a user