Pisilinux3/pisi
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

duzeltmeler...

Browse Source
This commit is contained in:
Eray Özkural
2005-07-22 15:17:35 +00:00
parent 0d5288fe6d
commit a093492de1
2 changed files with 60 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/dependency.pdf
BIN
View File
Binary file not shown.
doc/dependency.tex
+60 -54
View File
@@ -22,8 +22,6 @@
%\newrefformat{apx}{Appendix~\ref{#1}} %\newrefformat{apx}{Appendix~\ref{#1}}
%\newrefformat{tab}{Table~\ref{#1}} %\newrefformat{tab}{Table~\ref{#1}}
%\newrefformat{fig}{Figure~\ref{#1}} %\newrefformat{fig}{Figure~\ref{#1}}
%usepackage[active]{srcltx} %usepackage[active]{srcltx}
\title{ Dependency Resolution in PISI} \title{ Dependency Resolution in PISI}
@@ -68,26 +66,30 @@ system that are not modelled well with the SAT problem.
We use a graph theoretic approach instead. A directed graph (digraph) 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$ $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 where each edge $(u,v)$ represents an edge from a vertex to another.
another. Topological sort of a graph gives a total ordering of the Accessor functions $V(G)$ and $E(G)$ yield the vertex and edge set of
vertices in which there are only forward edges. the graph $G$. Topological sort of a graph gives a total ordering of
the vertices in which there are only forward edges. A vertex induced
subgraph of $G$ by vertex set $A$ contains only the vertex set $A$ and
edges incident to members of $A$.
\section{Package operation planning} \section{Package operation planning}
The dependency resolution problem may be viewed as a simple forward The dependency resolution problem may be viewed as a simple forward
chaining problem, where we would like to begin from an initial state chaining problem, where we would like to begin from an initial state
$S_0$ and by following allowable system transitions $t_i: S -> S$, $S_0$ and by following allowable system transitions $t_i: S \to S$,
arrive at a desired system state $S_f$ (where $S$ is the set of all states). arrive at a desired system state $S_f$ (where $S$ is the set of all states).
A system state $S_i$ is defined as the set of installed packages on the A system state $S_i$ is defined as the set of installed packages on
system together with their versions, i.e. $S_i = \{ (x,v) : x \text{ is the system together with their versions, i.e. $S_i = \{ (x,v) : x
installed}, v=version(x)\} $. An atomic system transition $t_i$ chains one \text{ is installed}, v=version(x)\} $. An atomic system transition
system state into another, making one ACID change on the system. The $t_i$ chains one system state into another, making one ACID change on
usual atomic transitions are the single package install and remove the system. The usual atomic transitions are the single package
operations found in low-level package management code of PISI. Note install, remove and reinstall (upgrade or downgrade) operations found
that in PISI, an upgrade operation is identical to a remove operation in low-level package management code of PISI. Note that in PISI, an
followed by an install operation (which sets it apart from some other upgrade operation is identical to a remove operation followed by an
packaging systems). install operation (which sets it apart from some other packaging
systems).
A package operation plan is thus naturally conceived of as a sequence A package operation plan is thus naturally conceived of as a sequence
of atomic system transitions. Given an initial state and a final of atomic system transitions. Given an initial state and a final
@@ -116,39 +118,39 @@ look at the dependency condition.
\subsection{Solving the simplest case with topological sorting} \subsection{Solving the simplest case with topological sorting}
We will now concentrate on a simple form of the problem which can We will now concentrate on a simple form of the problem which can be
be solved with topological sorting. This form is not concerned with solved with topological sorting. This form is not concerned with
versions. From initial set of packages $S_0$, we would like to versions. From an 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 install in addition a new set $A$ of packages obtaining $S_f = S_0 \cup
A$. A$.
The only relations considered are of the form: $a$ Depends on $b$, or more The only relations considered are of the form: $a$ Depends on $b$, or more
briefly $aDb$. briefly $aDb$.
The graph of all such simple dependency relations is a directed graph The graph of all such simple dependency relations is a digraph $G$.
(digraph) $G$. For each dependency relation $aDB$, there is an edge $a For each dependency relation $aDb$, there is an edge $a \to b$ in $G$.
\to b$ in $G$. Accessing graph $G$ usually requires a database operation and Accessing graph $G$ usually requires a database operation and is
is therefore expensive. therefore expensive.
We now consider the digraph $G_A$ of the minimal set of simple We now consider the digraph $G_A$ of the minimal set of simple
dependency relations which contains all information required to dependency relations which contains all information required to
construct a plan to install packages $A$. $G_A$ is a vertex induced graph construct a plan to install packages $A$. $G_A$ is a vertex induced
such that the fringe of $A$, e.g. vertices with out-degree $0$ are graph such that the fringe of $A$, e.g. vertices with out-degree $0$
already installed. Vertices of $G_A$ are taken from $S_f$. First, let us depend only on packages that are already installed (or none). Vertices
explain the labelling scheme. Already installed vertices are labelled of $G_A$ are taken from $S_f$. First, let us explain the labelling
with 'i'. Packages to be added are labelled with 'a', and packages to scheme. Already installed vertices are labelled with 'i'. Packages to
be installed due to dependencies are labelled with 'd'. We be added are labelled with 'a', and packages to be installed due to
construct the graph as follows dependencies are labelled with 'd'. We construct the graph as follows
\begin{algorithm} \begin{algorithm}
%\caption{$\textsc{Par-Freq}(T_i, \epsilon, \textsc{Mine-Freq} )$} \caption{$\textsc{Make-}G_A(G, A)$}
\label{alg:cons-graph} \label{alg:cons-graph}
\begin{algorithmic}[1] \begin{algorithmic}[1]
\STATE $G_A \gets$ isolated vertex set $A$ labelled with 'a' \STATE $G_A \gets$ vertex induced subgraph of $G$ by $A$ labelled with 'a'
\REPEAT \REPEAT
\STATE done $\gets$ true \STATE done $\gets$ true
\FOR{each $u \in V_A$ with out-degree $0$} \FOR{each $u \in V(G_A)$ with out-degree $0$}
\FOR{ $v \in adj(u) $ of $G$} \FOR{ $v \in adj(u) $ of $G$}
\IF{$v \notin V_A$} \IF{$v \notin V(G_A)$}
\STATE done $\gets$ false \STATE done $\gets$ false
\IF{$v$ is installed} \IF{$v$ is installed}
\STATE label $v$ with 'i' \STATE label $v$ with 'i'
@@ -281,24 +283,29 @@ multi-package upgrade, the exact details of the goal state depend on
the graph $G_f$ of the repository. Thus, we construct a graph the graph $G_f$ of the repository. Thus, we construct a graph
$G_{A,f}$ that is a vertex-induced subgraph of $G_f$ such that it $G_{A,f}$ that is a vertex-induced subgraph of $G_f$ such that it
contains all information relevant to upgrading packages $A$. We begin contains all information relevant to upgrading packages $A$. We begin
by a vertex induced graph by $A$. These are the packages that will be by a vertex induced subgraph of $G_f$ by $A$. These are the packages
upgraded in any case. Then, we make a pass on the vertices, and look that will be upgraded in any case. Then, we make a pass on the
at all the outgoing edges, we compare whether this edge has changed in vertices, and look at all the outgoing edges, we compare whether this
any substantial way from the previous version. In particular, we are edge has changed in any substantial way from the previous version. In
interested in whether the predicate of the edge is valid for the particular, we are interested in whether the predicate of the edge is
version of the same package in our current system. Every compared valid for the version of the same package in our current system. Every
vertex in this manner is marked done, and the edges not valid for the compared vertex in this manner is marked done, and the edges not valid
current system pull new unmarked vertices into $G_f$, this continues for the current system pull new unmarked vertices into $G_f$, this
until there are no unmarked vertices left. Hence, the vertices of continues until there are no unmarked vertices left. Hence, the
$G_f$ are the packages that must be upgraded. vertices of $G_f$ are the packages that must be upgraded.
To actually carry out the upgrade a strategy is to upgrade one by one To actually carry out the upgrade a strategy is to upgrade all the
all the packages in some order. A good order is again the reverse packages in $G_{A,f}$ in some order. A good order is again the reverse
topological order order, in fact, the operation is merely a special case of a topological order order, in fact, the upgrade operation is merely a
multi-package installation code that can install from a remote special case of a multi-package installation code that can install
repository. However, in case no package depends on the packages to be from a remote repository, since a multi-package installation can
upgraded, then we can carry out a completely consistency-preserving contain upgrades in addition to new packages. However, in case no
plan as discussed above. package depends on the packages to be upgraded, then we can carry out
a completely consistency-preserving plan as discussed above. The
conflicts are resolved in the usual fashion, by removing those
packages in conflict with new packages that are installed. This can be
accomplished by invoking a remove operation prior to the upgrade
operation.
\section{Examples} \section{Examples}
@@ -317,7 +324,6 @@ initial state:\\
In this case, we can find a consistency-preserving plan in terms of In this case, we can find a consistency-preserving plan in terms of
install and remove operations. install and remove operations.
\\ \\
plan:\\ plan:\\
remove $(a,1)$\\ remove $(a,1)$\\
@@ -339,10 +345,10 @@ chain. In fact, here there is no consistency-preserving plan in terms
of atomic single package transitions: install, remove, upgrade. In of atomic single package transitions: install, remove, upgrade. In
these cases, it seems best to resort to upgrade in place, and in the these cases, it seems best to resort to upgrade in place, and in the
reverse topological order of dependencies. reverse topological order of dependencies.
\\
plan:\\ plan:\\
upgrade $(c,1) \to (c,2)$ upgrade $(c,1) \to (c,2)$\\
upgrade $(b,1) \to (b,2)$ upgrade $(b,1) \to (b,2)$\\
\subsection{A multi package remove} \subsection{A multi package remove}