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

* latex'e cevir, guzellestir ortami

Browse Source 
* review'a graph theory'le ilgili bir paragraf yaz.
This commit is contained in:
Eray Özkural
2005-07-21 00:28:17 +00:00
parent 48901ce09b
commit 80cd6f57d8
6 changed files with 471 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/algorithm.sty
+79
View File
@@ -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}}
doc/algorithmic.sty
+158
View File
@@ -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}}
doc/dependency.pdf
BIN
View File
Binary file not shown.
doc/dependency.tex
+197
View File
@@ -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}
doc/dependency.txt
-141
View File
@@ -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)
doc/prettyref.sty
+37
View File
@@ -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'.