Change to project/trunk,tags,branches style
This commit is contained in:
Faik Uygur
@@ -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}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,167 @@
|
||||
component'larla ilgili notlar
|
||||
|
||||
1. Temel feature'lar (Eray)
|
||||
--------------------
|
||||
|
||||
Iki yerde component tag'i tanimladik simdiye kadar, bir
|
||||
source'larda bir de binary'lerde. Binary'de tanimlanan component default
|
||||
olarak source'daki tanimi inherit ediyor ve tanimlanan component'i override
|
||||
edebiliyor.
|
||||
|
||||
Bir component temel olarak bir meta-package, icerisinde paketler olan
|
||||
bir paket. Bir component'in icerisinde bir takim source'lar ve bir takim
|
||||
binary'ler bulunuyor diye bakabiliriz. Sanirim query'leri bu sekilde yapmak
|
||||
mumkun olmali.
|
||||
|
||||
$ pisi list-components
|
||||
$ pisi info system.base
|
||||
Source packages in system.base:
|
||||
....
|
||||
....
|
||||
Binary packages in system.base:
|
||||
....
|
||||
....
|
||||
|
||||
gibi ozellikler eklemeyi umit ediyorum.
|
||||
|
||||
Source'larin component tag'leri de, gene sadece bir senaryo konusuyorum,
|
||||
direkt olarak directory structure'indan inherit alinacak. Ayni zamanda o pspec
|
||||
icin de bir tane component tanimlananack default olarak, ve bu component o
|
||||
scope'da tanimlanmis olan butun binary package'lari icerecek.
|
||||
|
||||
Ornegin diyelim ki a/b/c/pspec.xml var ve c1 c2 c3 seklinde uc tane paket
|
||||
tanimliyor. Hic bir component tanimi yapilmadigi zaman otomatik olarak bir
|
||||
a.b.c component'i olusturulacak, ve bu component'in icerisinde c1 c2 c3
|
||||
bulunacak.
|
||||
|
||||
$ pisi info a.b.c
|
||||
Source packages:
|
||||
c - oldur beni yarim sen olmazsan biterim
|
||||
Binary packages:
|
||||
c1 - bu aksam demlenmemek sonum olur benim
|
||||
c2 - sincaplarla konustum butun gece
|
||||
c3 - her gul gordugumde icim kan aglar
|
||||
|
||||
Bu varsayilan davranis, ama bunu degistirmek mumkun olacak. Burada yamuk
|
||||
gozukebilecek bir sey var, o da tek bir paket oldugunda sanki biraz
|
||||
redundancy olmasi, o takdirde bir optimizasyon olarak, diyelim ki
|
||||
a/b/c/pspec.xml'in icerisinde tek bir paket tanimli c1
|
||||
|
||||
$ pisi info a.b
|
||||
....
|
||||
c1 - dil dil dillerdeyim
|
||||
|
||||
olabilir bu durumda, bu genel agac mantiginda bir sorun yaratmayacaktir.
|
||||
|
||||
|
||||
2. Temel tanım (Barış)
|
||||
|
||||
fiziksel aitlik: kdebase'den çıkan kcontrol gibi; grup aitliği: pdf
|
||||
göstericileri gibi...
|
||||
|
||||
|
||||
3. Database XML ayrımı (Barış)
|
||||
|
||||
Component database'i ile component.xml ayrı olmalı. Component database,
|
||||
pisi'nin pisi-index.xml dosyasını okuyarak oluşturacağı bir veritabanı. Hangi
|
||||
paketler hangi componentlere dahil, vs. sorguları bu veritabanından
|
||||
yapılacak.
|
||||
|
||||
Pspec dosyasını hatırlayalım. İçerisinde bir <PartOf> diye bir tag var.
|
||||
Oluşturulacak paketin hangi component'e ait olduğunu belirtiyor. Bu bilgi
|
||||
pisi-index.xml dosyasına da koyulmalı.
|
||||
|
||||
4. PL modüllerine benzerlik (Eray)
|
||||
|
||||
component tag'leri Java ya da python'daki gibi
|
||||
directory yapisindan cikiyor. Yani pisi bir programlama dili olsaydi
|
||||
component'lar module'ler ya da package'larla es anlamli olacakti.
|
||||
|
||||
5. Mereology ve Eray'ın açıklama çabaları (Eray)
|
||||
|
||||
PartOf iliskisi hakkında su kadarini soylemek yeter: eger a b'nin bir parcasiysa,
|
||||
a'nin fonksiyonu b'nin fonksiyonunun bir parcasidir. Bu da fiziksel sistemler
|
||||
icin bir principle of compositionality'nin varligindan hareket eder [*]
|
||||
|
||||
Genel olarak da software engineering ve AI camiasinda module'un tanimi gayet
|
||||
iyi bilinir. Bir modul icerisindeki bagimliliklar yogundur. Moduller arasindaki
|
||||
bagimliliklar zayiftir.
|
||||
|
||||
Bu tanim sadece software engineering'de degil, nesneler arasindaki
|
||||
benzerliklerin incelendigi bir cok disiplinde kullanilan informal bir tanim,
|
||||
ama tabii ki formule dokulmus bir ton hali var.Sırf bu tanımı taban alarak
|
||||
yazılmış başarılı kümeleme (clustering) algoritmaları var.
|
||||
|
||||
Modulerlik tanimi verilen *fiziksel* modul ve parcasi olma iliskisiyle
|
||||
birlesince birlikte install edilip remove edilme yahut ortak bağımlılıklara
|
||||
sahip olma tanımlarına götürür.
|
||||
|
||||
Bu tanımı analiz edebilmek için parcasi olma iliskisininin anlamini
|
||||
korumamiz yeterli. Temel olarak
|
||||
|
||||
kol insanin parcasidir
|
||||
|
||||
iliskisi burada yer aliyor. Eger
|
||||
|
||||
a partof b
|
||||
|
||||
turu iliskilerde a paket ya da component, ve b component ise, a ve b'nin
|
||||
iliskisinin kol ve insan iliskisi gibi olmasini bekleriz. Eger bu parca-butun
|
||||
iliskisini ihlal ediyorsa o zaman muhtemelen yanlis bir iliski bulunmus
|
||||
demektir.
|
||||
|
||||
Bunun turlu sonuclari da onem sirasina gore soyle dizilebilir:
|
||||
|
||||
1. Fonksiyonlarin bolunebilmesi prensibinden: (basit bir sonuç)
|
||||
a's function is part-of b's function
|
||||
|
||||
orneğin kolun fonksiyonu insanın total fonksiyonunun bir parçasıdır.
|
||||
|
||||
paket ornegi: pisi'nin fonksiyonu olan paket yükleme/çıkarma system.base'in fonksiyonunun, yani temel pardus sisteminin fonksiyonunun bir parçasıdır.
|
||||
|
||||
2. Karmasik sistemlerde birbirine dayanan ufak parcalarin kararli yapilar
|
||||
meydana getirmesi prensibinden: (evrimsel sonuç)
|
||||
|
||||
if a is a part-of c, and b is a part-of c, then it follows that a and b
|
||||
may:
|
||||
a. have many interdependencies
|
||||
b. share in their origins
|
||||
(which are about the same thing)
|
||||
|
||||
2b. sonucunun bizim durumumuza uygulanması, source code'un aynı kaynaktan
|
||||
çıkması, birlikte inşa edilmeleri gibi şartları getirir. Bunun oldukça
|
||||
olasi, en azindan insa metodlarinin ve kaynaklarının birbirine benzemesini
|
||||
bekleriz. Yalniz, 2.a'daki bagimliliklar sadece insa ile degil ayni zamanda
|
||||
calisma ile de alakalidir. Kaynakları farklı parçaların birbirine bağımlı
|
||||
hale gelebilecegini unutmamak gerekir.
|
||||
|
||||
Fedora'nin yaklasiminin hos tarafi, boyle teknik ayrintilara girmeden "package
|
||||
group" mantigini kullanmasiydi, ama bizim belli bir anlami olan parca-butun
|
||||
iliskisini korumamiz daha mantikli bir yazilim ontology'si ortaya
|
||||
cikaracaktir. Onlarin yaklasimi ise "anything goes", grup ile kategori'nin
|
||||
temel bir farki yok cunku, herhangi bir bakis acisi olabilir "grup".
|
||||
|
||||
|
||||
6. Modulleri test etmek (!!) (Eray)
|
||||
------------------------------------
|
||||
|
||||
PISI'deki seçilen implementation detaylari bir tanima cok fazla commitment
|
||||
yapmiyor, implementation'ın getirdiği tek şey paketleri bir ağaca koymak.
|
||||
Component'ların seçiminin ne kadar kaliteli olduğunu belirleyemiyor.
|
||||
Paketlerin ve componentlarin secimi yapiyor, ki kritik olan o.
|
||||
Yalnız modulerlik tanimindan ve part-of iliskisinin
|
||||
if a is part of b, and b is part of c, then a is part of c.
|
||||
if a is part of b, and b is not part of c, then a is not part of c.
|
||||
gibi sonuclari getirmesinden hareketle (ki bunlar klasik computational
|
||||
ontology) kismen test edebilecegimiz bir sekil aliyor ornegin bagimlilik
|
||||
graph'ini cluster ederek, ya da her modul icin bir modulerlik sayisi
|
||||
hesaplayarak. Daha az formal olarak da bu sonuçları kafamızda yürüterek
|
||||
yaptığımız componentların ne kadar akla yatkın olduğunu bulabiliriz.
|
||||
|
||||
|
||||
7. Cagların frugalware önerisi
|
||||
------------------------------
|
||||
|
||||
http://ftp.frugalware.org/pub/frugalware/frugalware-current/source/
|
||||
adresindeki yerleşimin hem source hem de binary depo için uygulanmasını ve
|
||||
kategori, componentların da bundan çıkartılmasını öneriyorum.
|
||||
Binary file not shown.
@@ -0,0 +1,381 @@
|
||||
%%% 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.
|
||||
Accessor functions $V(G)$ and $E(G)$ yield the vertex and edge set of
|
||||
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}
|
||||
|
||||
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 \to S$,
|
||||
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 system together with their versions, i.e. $S_i = \{ (x,v) : x
|
||||
\text{ 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 reinstall (upgrade or downgrade) operations found
|
||||
in low-level package management code of PISI. Note that in PISI, an
|
||||
upgrade operation is identical to a remove operation followed by an
|
||||
install operation (which sets it apart from some other packaging
|
||||
systems).
|
||||
|
||||
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$ in the definitions for simplicity.
|
||||
|
||||
\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. We will explain the conflicts later, for the present let us
|
||||
look at the dependency condition.
|
||||
|
||||
\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. Neither do we consider remote repositories. 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 A$, for a static set of package
|
||||
relations.
|
||||
|
||||
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 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$
|
||||
depend only on packages that are already installed (or none). 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{Make-}G_A(G, A)$}
|
||||
\label{alg:cons-graph}
|
||||
\begin{algorithmic}[1]
|
||||
\STATE $G_A \gets$ vertex induced subgraph of $G$ by $A$ labelled with 'a'
|
||||
\REPEAT
|
||||
\STATE done $\gets$ true
|
||||
\FOR{each $u \in V(G_A)$ with out-degree $0$}
|
||||
\FOR{ $v \in adj(u) $ of $G$}
|
||||
\IF{$v \notin V(G_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'. Observe that, by definition of a topological sort,
|
||||
installing packages in the reverse order of a topological sort
|
||||
guarantees that no package is installed before all of its dependencies
|
||||
are installed. Thus, this yields a consistency-preserving plan.
|
||||
|
||||
\subsection{Dependency conditions}
|
||||
|
||||
In the PISI specification, we allow a dependency to specify a local
|
||||
condition, for instance a program may require a dependency on
|
||||
\texttt{libx} with pardus source release $3$ or greater. Another
|
||||
program may require a dependency on a particular source release. These
|
||||
conditions are local because they can be computed over the elements of
|
||||
system state $S_i$, e.g. package (name, version) pairs. Let us denote this
|
||||
condition by a predicate $P(b)$ such that $aDb$ iff $P(b)$. The
|
||||
predicate $P$ for the dependency $aDb$ can be stored as edge data for
|
||||
$(u,v)$ on the graph.
|
||||
% thus when we say $P(u,v)$, this means the predicate stored on
|
||||
%$(u,v)$ edge for vertex $v$.
|
||||
|
||||
In this case, the vertices of the package dependency graph $G$ and the
|
||||
planning graph $G_A$ retain the version information along with the
|
||||
package name. The dependency relation thus holds between two pairs
|
||||
$(p_1,v_1)$ and $(p_2,v_2)$, satisfying a given predicate
|
||||
$P(p_2,v_2)$. When constructing the graph, we therefore take this
|
||||
predicate into account and admit a new edge $(u,v)$, and thus a new
|
||||
vertex $v$ into $G_A$ if and only if the target vertex satisfies
|
||||
$P(v)$.
|
||||
|
||||
\subsection{Conflicts and COMAR dependencies}
|
||||
|
||||
The tags \texttt{Conflicts} and \texttt{Provides} in PISI are
|
||||
inherited from Debian distribution. A conflict between two packages
|
||||
($a$ conflicts with $b$) is a symmetric relation that prevents the
|
||||
packages $a,b$ from being installed simultaneously (It is
|
||||
sufficient that only one direction of the relation is declared, the
|
||||
other direction is inferred). Provision in the form of $a$ provides $A$
|
||||
denotes that $a$ implements a virtual package abstraction $A$.
|
||||
|
||||
In PISI, a package can provide an object of a COMAR Object Model (OM),
|
||||
and is currently the only model of a ``virtual package''. In the
|
||||
following example, let $a_1,a_2,\ldots,a_n$ provide the OM $A$. A package
|
||||
can depend on another package's OM, for instance $b$ comar-depends on
|
||||
$A$ (or in short form $bDA$) (Currently, conditions on virtual
|
||||
dependencies are not supported). In this case, it is sufficient that
|
||||
only one of the $a_i$ are installed. To resolve this, the user is
|
||||
asked to choose from a list of alternatives immediately, since
|
||||
otherwise there is unavoidable combinatorial explosion (in the form of
|
||||
having to consider $\Pi_{bDA}num(A)$ graphs in the worst case where
|
||||
$num(A)$ is the number of alternatives for comar OM $A$; the problem
|
||||
is that there seems to be no simple solution to solve satisfiability
|
||||
with arbitrary disjunctions in package dependency, short of a $SAT$
|
||||
solver).
|
||||
|
||||
The resolution of conflicts to maintain system consistency condition
|
||||
$2$ is easier to achieve. This can be satisfied by disallowing
|
||||
installation of a package that would violate the condition, or
|
||||
removing currently installed packages which conflict with the newly
|
||||
installed package and its dependencies. In most package managers, the
|
||||
second option is confirmed by the user for making it easier. In the
|
||||
install operation, after constructing the partial dependency graph
|
||||
$G_A$, we merely have to check whether any conflict appears among the
|
||||
vertices of $G_A$. If so, then the operation is untenable, since $G_A$
|
||||
shows the future state of the installed system. Since a conflict is
|
||||
symmetric, it is represented as a bidirectional edge $a \leftrightarrow b$. To
|
||||
distinguish dependencies from conflicts, the edges would have to be
|
||||
labelled in this case, for instance with 'd' and 'c'. The removal
|
||||
option can be implemented by invoking a multi-package remove operation
|
||||
on the packages in conflict.
|
||||
|
||||
\subsection{Remove operation}
|
||||
|
||||
Dependency resolution for remove operation is similar to install. The
|
||||
only significant difference is that we remove the packages in the
|
||||
topological order rather than installing packages in the reverse
|
||||
topological order.
|
||||
|
||||
\section{Remote repositories and upgrade operation}
|
||||
|
||||
|
||||
The upgrade operation is more complicated. First of all, the system
|
||||
has to distinguish between the current relation graph (e.g.
|
||||
dependencies and conflicts), and the future relation graph which may
|
||||
be different in rather important aspects. In theory, we allow any
|
||||
dependency and conflict to change. Therefore, we have a $G_0$ which
|
||||
represents the current relations (among installed packages) in the
|
||||
system, and a $G_f$ which is probably taken from a remote package
|
||||
repository. We begin by noting that $G_0$ and $G_f$ have to be
|
||||
compatible. That is, to say, if a package $(p_1,v_1)$ is shared across
|
||||
two graphs, then the declarations made by the package are one and the
|
||||
same.
|
||||
|
||||
$G_0$ can be calculated from the package information (e.g. metadata)
|
||||
of the installed packages and is stored by PISI in a dedicated
|
||||
database. $G_f$ is most likely constructed from a PISI Index file
|
||||
corresponding to a particular package repository. Accessing both of
|
||||
these entities is expensive and we should take care to minimize access
|
||||
as in the previous section.
|
||||
|
||||
To preserve consistency during individual transitions, the planner can
|
||||
choose to remove a minimum number of packages from the system to bring
|
||||
it to a clean state, and then install the new versions of these
|
||||
packages in the correct order. Let us assume that it is indeed
|
||||
possible to achieve this ``clean state''. Apparently, this is not
|
||||
always possible because other packages may depend on the package(s) to
|
||||
upgrade. At any rate, to achieve this, first we need to
|
||||
calculate subgraphs of $G_0$ and $G_f$. We can calculate alternative
|
||||
plans from these subgraphs if need be.
|
||||
|
||||
Let $A$ be the set of packages to be upgraded from a given repository.
|
||||
$G_{A,0}$ is the subgraph of $G_{0}$ induced by the ``upgrade
|
||||
closure'' of $A$. The ``upgrade closure'' of a set $A$ of packages is
|
||||
defined as a minimal set of packages $B \supseteq A$ such that there is no
|
||||
package in $B$ that requires an upgrade for $A$ to be upgraded. This
|
||||
is found by assuming that the current system state $S_0$ is
|
||||
consistent, and by constructing a relation graph of the future state
|
||||
of the system to detect the dependencies that have changed.
|
||||
|
||||
Obviously, to make a plan, we must first know the goal state. In a
|
||||
multi-package upgrade, the exact details of the goal state depend on
|
||||
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
|
||||
contains all information relevant to upgrading packages $A$. We begin
|
||||
by a vertex induced subgraph of $G_f$ by $A$. These are the packages
|
||||
that will be upgraded in any case. Then, we make a pass on the
|
||||
vertices, and look at all the outgoing edges, we compare whether this
|
||||
edge has changed in any substantial way from the previous version. In
|
||||
particular, we are interested in whether the predicate of the edge is
|
||||
valid for the version of the same package in our current system. Every
|
||||
compared vertex in this manner is marked done, and the edges not valid
|
||||
for the current system pull new unmarked vertices into $G_f$, this
|
||||
continues until there are no unmarked vertices left. Hence, the
|
||||
vertices of $G_f$ are the packages that must be upgraded.
|
||||
|
||||
To actually carry out the upgrade a strategy is to upgrade all the
|
||||
packages in $G_{A,f}$ in some order. A good order is again the reverse
|
||||
topological order order, in fact, the upgrade operation is merely a
|
||||
special case of a multi-package installation code that can install
|
||||
from a remote repository, since a multi-package installation can
|
||||
contain upgrades in addition to new packages. However, in case no
|
||||
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}
|
||||
|
||||
\subsection{A single package upgrade}
|
||||
|
||||
goal: 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 \\
|
||||
|
||||
In this case, we can find a consistency-preserving plan in terms of
|
||||
install and remove operations.
|
||||
\\
|
||||
plan:\\
|
||||
remove $(a,1)$\\
|
||||
remove $(b,1)$\\
|
||||
remove $(c,1)$\\
|
||||
install $(c,3)$\\
|
||||
install $(d,2)$\\
|
||||
install $(a,2)$\\
|
||||
|
||||
\subsection{Another upgrade}
|
||||
|
||||
goal: upgrade $(b,1) \to (b,2)$\\
|
||||
\\
|
||||
current dep: $(a,1) \to[=1] (b,1) \to[=1] (c,1) \to[=1] (d,1)$\\
|
||||
repo dep: \nobreakspace{} \nobreakspace$(a,1) \to[=2] (b,2) \to[=2] (c,2) \to[=1] (d,1)$\\
|
||||
|
||||
In this case, we cannot remove $(b,1)$ because it's locked in the
|
||||
chain. In fact, here there is no consistency-preserving plan in terms
|
||||
of atomic single package transitions: install, remove, upgrade. In
|
||||
these cases, it seems best to resort to upgrade in place, and in the
|
||||
reverse topological order of dependencies.
|
||||
\\
|
||||
plan:\\
|
||||
upgrade $(c,1) \to (c,2)$\\
|
||||
upgrade $(b,1) \to (b,2)$\\
|
||||
|
||||
|
||||
\subsection{A multi package remove}
|
||||
|
||||
goal: remove $(a,2), (b,3), (c,2)$\\
|
||||
\\
|
||||
rules:\\
|
||||
$(c,2)$ depends $(a,2)$\\
|
||||
$(d,2)$ depends on $(b,3), (c,2)$\\
|
||||
$(e,1)$ depends on $(a,2)$\\
|
||||
$(f,2)$ depends on $(e,1)$\\
|
||||
$(g,2)$ depends on $(e,1)$\\\\
|
||||
plan:\\
|
||||
remove $(f,2)$\\
|
||||
remove $(g,2)$\\
|
||||
remove $(e,1)$\\
|
||||
remove $(d,2)$\\
|
||||
remove $(b,3)$\\
|
||||
remove $(c,2)$\\
|
||||
remove $(a,2)$\\
|
||||
\end{document}
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,187 @@
|
||||
\documentclass[a4paper,11pt]{article}
|
||||
|
||||
\title{P\.IS\.I Packages: Version Policy v0.2}
|
||||
\date{\today}
|
||||
\author{Eray \"Ozkural and T. Bar\i{}\c s Metin}
|
||||
|
||||
|
||||
\begin{document}
|
||||
\maketitle
|
||||
|
||||
\section*{Revision History}
|
||||
\begin{itemize}
|
||||
\item v0.1: Bar\i\c s Metin wrote the first version preparing the outline,
|
||||
detailed Source Version Section, and started the Section on Release Number.
|
||||
\item v0.2: Eray \"Ozkural wrote a detailed introduction, added
|
||||
explanations of release and build numbers, reorganized a bit.
|
||||
\end{itemize}
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
This document explains the \emph{version policy} that applies to
|
||||
P\.IS\.I packages. Classically, the issue of distinguishing source and
|
||||
binary distributions unambiguously has not received a rigorous
|
||||
treatment in the context of LINUX distributions. We have identified
|
||||
several shortcomings of the usual practices of extending the original
|
||||
version with suffixes and prefixes, colorfully illustrated in the
|
||||
following common problems.
|
||||
|
||||
\begin{description}
|
||||
|
||||
\item[The problem of future downgrades]
|
||||
The distribution chooses to use a previous version of the package in
|
||||
the next release. There is no way to indicate this, so ad-hoc
|
||||
solutions such as version prefixes are used. It is
|
||||
impossible to denote a future dependency that requires at least this
|
||||
distribution source release in this case, either.
|
||||
|
||||
\item[The problem of redundant distributions]
|
||||
A trivial patch has been applied to the source. While few binary
|
||||
packages have been affected by this change, all binary packages
|
||||
built from the source are redistributed.
|
||||
|
||||
\item[The problem of underdetermined rebuilds]
|
||||
There have been rapid changes in the system, and although no
|
||||
changes have been made to the package source, a new binary
|
||||
distribution must be prepared.
|
||||
|
||||
\end{description}
|
||||
|
||||
We have devised a slightly new approach in order to alleviate these
|
||||
problems. Our solution consists of encoding the history of source and
|
||||
binary package developments in separate version strings we call release and
|
||||
build numbers.
|
||||
|
||||
Since the source version is usually used by the users and developers
|
||||
to identify software, we retain the notion of a source version in
|
||||
P\.IS\.I as a convenience.
|
||||
|
||||
In the following sections, we explain the components of our
|
||||
versioning scheme.
|
||||
|
||||
\subsection{Source Version}
|
||||
|
||||
Source version is the version number provided by the
|
||||
upstream maintainer of the source archive used in package. It must
|
||||
always be the same as the upstream version used.
|
||||
|
||||
\textbf{Example}: If the upstream archive name is
|
||||
\emph{bash-3.0.tar.gz} the version number of the package is \emph{3.0}
|
||||
|
||||
\subsubsection{Version Suffixes}
|
||||
|
||||
There is a pre-defined list of suffixes a package version can
|
||||
take.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{alpha} Source/Package is in alpha state
|
||||
\item \textbf{beta} Source/Package is in beta state
|
||||
\item \textbf{pre} Source/Pacgage passed the beta state but stable
|
||||
version is not relased yet.
|
||||
\item \textbf{rc} Source/Package is a release-candidate.
|
||||
\item \textbf{m} Source/Package is a milestone before stable version.
|
||||
\item \textbf{p} Source/Package is released and some patches are
|
||||
applied after the release. This is the patch level.
|
||||
\end{itemize}
|
||||
|
||||
The suffix should be written after the special separator
|
||||
character \textbf{\_}. And there must allways be a number after a
|
||||
suffix. \textbf{Example}: packagename-1.0\_beta1
|
||||
|
||||
The basic order of the priorities for suffixes is:\newline
|
||||
\emph{p $>$ (no suffix) $>$ m $>$ rc $>$ pre $>$ beta $>$ alpha}.
|
||||
|
||||
The scope of a source version string is global in the literal
|
||||
sense. It shall not vary from repository to repository.
|
||||
|
||||
The support for these special suffixes as well as usual alphanumeric
|
||||
version string ordering has been implemented in P\.IS\.I.
|
||||
|
||||
\section{Identifying Package Sources}
|
||||
|
||||
A P\.IS\.I source has three identity elements written under
|
||||
\texttt{SOURCE} tag: name, source version, and source release number.
|
||||
We usually say just version and release number/release instead of
|
||||
source version and source release number, respectively. Name is available in
|
||||
the \texttt{<Name>} tag. Version and release are available in the last
|
||||
\texttt{<Update>} element of \texttt{<History>} tag of a \texttt{PSPEC}.
|
||||
|
||||
The name of a source package is constant throughout its revision
|
||||
history. The version is the original version, given by its
|
||||
programmers. Release is a positive integer. Name and release
|
||||
is sufficient to uniquely identify a particular PISI source revision.
|
||||
That is, version and release are independent.
|
||||
|
||||
\subsection{Release Number}
|
||||
|
||||
Release number is the number of the changes that are made to the
|
||||
package source since the initial version in the distribution source. A
|
||||
change can be a patch applied to the source archive, modification in
|
||||
the actions.py, pspec.xml or any file in the source package
|
||||
directory. This change is indicated in \texttt{<Update>} tags manually
|
||||
by the package maintainer.
|
||||
|
||||
The initial release of a package is by default \texttt{1}. The release
|
||||
number always increments by $1$ in each revision in the
|
||||
\texttt{History}, even the slightest ones, but it never decrements.
|
||||
|
||||
The scope of the release number is a given distribution, regardless of
|
||||
its version, e.g. Pardus.
|
||||
|
||||
In the future, PISI will have strict checks for release numbers.
|
||||
|
||||
\subsection{Dependency Specifications}
|
||||
|
||||
We allow a package to use both source version and release to identify
|
||||
a particular version or a range of package versions.
|
||||
|
||||
\section{Identifying Binary packages}
|
||||
|
||||
A PISI binary package is produced from a PISI source package. It has a
|
||||
name that is constant throughout the history of the source package,
|
||||
and it inherits the source version and release number from the source
|
||||
package. However, a binary package has in addition a binary build
|
||||
number. Shortly, build number or just build. For each of the
|
||||
architecture targets, e.g. particular binaries, it also has an
|
||||
architecture tag.
|
||||
|
||||
A binary package is uniquely identified by its name, build number, and
|
||||
architecture regardless of the source version.
|
||||
|
||||
\section{Build Number}
|
||||
|
||||
Similarly to source release number, binary build number is the number
|
||||
of changes that are made to a binary package. By change, we mean any
|
||||
bit change. The existence of a change is tested by comparing the
|
||||
cryptographic checksums in files.xml with those of the previous build, and the
|
||||
build number is automatically determined by the P\.IS\.I build system.
|
||||
The build number starts from $1$ as in release number, and increments
|
||||
by one with each binary change.
|
||||
|
||||
The user never interferes with the build number himself. However, if
|
||||
the user fails to provide the previous build, then a package without
|
||||
a build number is built. A package without a build number is evaluated
|
||||
on the basis of release number, which is guaranteed to exist.
|
||||
|
||||
The scope of a build number is a given distribution build environment
|
||||
for a particular architecture, which may vary from repository to
|
||||
repository. Therefore, it is not used in dependency
|
||||
specifications. However, the system does assume that a build of a
|
||||
given package and architecture is unique in a given repository.
|
||||
|
||||
\section{Package File Names}
|
||||
|
||||
A P\.IS\.I binary package file name contains all the components relevant
|
||||
to its identification, separated by dashes:
|
||||
\begin{verbatim}
|
||||
<binary name>-<source version>-<source release>-<binary build>.pisi
|
||||
\end{verbatim}
|
||||
|
||||
\section{Future Work}
|
||||
|
||||
In the future, it may be necessary to extend the notion of release
|
||||
number and build number to support branches and forks of a
|
||||
distribution. A proposal was to have CVS-like branching, but it
|
||||
was dismissed as unnecessary.
|
||||
|
||||
\end{document}
|
||||
+532
@@ -0,0 +1,532 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<XMI xmlns:UML="http://schema.omg.org/spec/UML/1.3" verified="false" timestamp="2006-09-29T21:06:38" xmi.version="1.2" >
|
||||
<XMI.header>
|
||||
<XMI.documentation>
|
||||
<XMI.exporter>umbrello uml modeller http://uml.sf.net</XMI.exporter>
|
||||
<XMI.exporterVersion>1.5.4</XMI.exporterVersion>
|
||||
<XMI.exporterEncoding>UnicodeUTF8</XMI.exporterEncoding>
|
||||
</XMI.documentation>
|
||||
<XMI.metamodel xmi.name="UML" href="UML.xml" xmi.version="1.3" />
|
||||
</XMI.header>
|
||||
<XMI.content>
|
||||
<UML:Model isSpecification="false" isLeaf="false" isRoot="false" xmi.id="m1" isAbstract="false" name="UML Model" >
|
||||
<UML:Namespace.ownedElement>
|
||||
<UML:Stereotype isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="3" isRoot="false" isAbstract="false" name="datatype" />
|
||||
<UML:Stereotype isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="108" isRoot="false" isAbstract="false" name="enum" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="2" isRoot="false" isAbstract="false" name="int" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="4" isRoot="false" isAbstract="false" name="char" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="5" isRoot="false" isAbstract="false" name="bool" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="6" isRoot="false" isAbstract="false" name="float" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="7" isRoot="false" isAbstract="false" name="double" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="8" isRoot="false" isAbstract="false" name="short" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="9" isRoot="false" isAbstract="false" name="long" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="10" isRoot="false" isAbstract="false" name="unsigned int" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="11" isRoot="false" isAbstract="false" name="unsigned short" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="12" isRoot="false" isAbstract="false" name="unsigned long" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="13" isRoot="false" isAbstract="false" name="string" />
|
||||
<UML:DataType stereotype="3" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="89" isRoot="false" isAbstract="false" name="data" />
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="24" isRoot="false" isAbstract="false" name="InstallDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="25" type="76" name="d" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="77" type="76" name="db" />
|
||||
</UML:Classifier.feature>
|
||||
<UML:Namespace.ownedElement>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="24" xmi.id="14" isRoot="false" isAbstract="false" name="InstallInfo" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="79" type="13" name="state" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="80" type="13" name="version" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="81" type="13" name="release" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="82" type="13" name="build" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="83" type="13" name="distribution" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="84" type="13" name="time" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
</UML:Namespace.ownedElement>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="76" isRoot="false" isAbstract="false" name="LockedDBShelf" />
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="86" isRoot="false" isAbstract="false" name="RepoDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="87" type="76" name="d" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="98" isRoot="false" isAbstract="false" name="Repo" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="99" type="13" name="indexuri" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="111" isRoot="false" isAbstract="false" name="FilesDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="112" type="76" name="d" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="114" isRoot="false" isAbstract="false" name="FileInfo" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="115" type="13" name="path" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="116" type="13" name="type" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="117" type="9" name="size" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="118" type="13" name="hash" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="119" type="5" name="permanent" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Enumeration stereotype="108" isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="141" isRoot="false" isAbstract="false" name="repo" >
|
||||
<UML:EnumerationLiteral isSpecification="false" isLeaf="false" visibility="public" namespace="141" xmi.id="142" isRoot="false" isAbstract="false" name="installed" />
|
||||
<UML:EnumerationLiteral isSpecification="false" isLeaf="false" visibility="public" namespace="141" xmi.id="143" isRoot="false" isAbstract="false" name="thirdparty" />
|
||||
<UML:EnumerationLiteral isSpecification="false" isLeaf="false" visibility="public" namespace="141" xmi.id="144" isRoot="false" isAbstract="false" name="repos" />
|
||||
<UML:EnumerationLiteral isSpecification="false" isLeaf="false" visibility="public" namespace="141" xmi.id="145" isRoot="false" isAbstract="false" name="all" />
|
||||
</UML:Enumeration>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="146" isRoot="false" isAbstract="false" name="ItemByRepo" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="147" type="76" name="d" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="155" isRoot="false" isAbstract="false" name="ComponentDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="156" type="146" name="d" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="163" isRoot="false" isAbstract="false" name="Component" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="164" type="13" name="name" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="165" type="13" name="localname" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="166" type="13" name="summary" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="167" type="13" name="description" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="168" type="177" name="dependencies" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="169" type="177" name="packages" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="170" type="177" name="sources" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="177" isRoot="false" isAbstract="false" name="list" />
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="186" isRoot="false" isAbstract="false" name="PackageDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="187" type="146" name="d" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="188" type="146" name="dr" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="190" isRoot="false" isAbstract="false" name="Package" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="191" type="13" name="name" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="192" type="13" name="summary" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="193" type="13" name="description" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="194" type="13" name="partof" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="195" type="13" name="license" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="196" type="177" name="packageDependencies" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="197" type="177" name="componentDependencies" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="198" type="177" name="files" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="199" type="177" name="conflicts" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="200" type="177" name="providesComar" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="201" type="177" name="additionalFiles" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="202" type="177" name="history" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="211" isRoot="false" isAbstract="false" name="SourceDB" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="212" type="146" name="d" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="213" type="146" name="dpkgtosrc" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="215" isRoot="false" isAbstract="false" name="SpecFile" >
|
||||
<UML:Classifier.feature>
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="216" type="217" name="source" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="218" type="177" name="packages" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="219" type="177" name="history" />
|
||||
<UML:Attribute isSpecification="false" visibility="private" xmi.id="221" type="177" name="components" />
|
||||
</UML:Classifier.feature>
|
||||
</UML:Class>
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="217" isRoot="false" isAbstract="false" name="Source" />
|
||||
<UML:Class isSpecification="false" isLeaf="false" visibility="public" namespace="m1" xmi.id="220" isRoot="false" isAbstract="false" name="History" />
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="26" name="" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="false" xmi.id="27" aggregation="none" type="24" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="28" aggregation="none" type="14" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="35" name="" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="false" xmi.id="36" aggregation="none" type="24" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="37" aggregation="none" type="14" name="" multiplicity="n" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="40" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="false" xmi.id="41" aggregation="none" type="24" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="42" aggregation="none" type="14" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="64" name="" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="65" aggregation="none" type="24" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="66" aggregation="none" type="14" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="73" name="" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="false" xmi.id="74" aggregation="none" type="24" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="75" aggregation="none" type="14" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="90" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="91" aggregation="composite" type="24" name="name" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="92" aggregation="none" type="14" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="100" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="101" aggregation="composite" type="86" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="102" aggregation="none" type="98" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="120" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="121" aggregation="composite" type="111" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="122" aggregation="none" type="114" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Dependency isSpecification="false" visibility="public" namespace="m1" xmi.id="149" client="146" name="" supplier="141" />
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="171" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="172" aggregation="composite" type="155" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="173" aggregation="none" type="163" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="203" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="204" aggregation="composite" type="186" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="205" aggregation="none" type="190" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
<UML:Association isSpecification="false" visibility="public" namespace="m1" xmi.id="222" name="1..*" >
|
||||
<UML:Association.connection>
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="223" aggregation="composite" type="211" name="" />
|
||||
<UML:AssociationEnd isSpecification="false" visibility="public" changeability="changeable" isNavigable="true" xmi.id="224" aggregation="none" type="215" name="" />
|
||||
</UML:Association.connection>
|
||||
</UML:Association>
|
||||
</UML:Namespace.ownedElement>
|
||||
</UML:Model>
|
||||
</XMI.content>
|
||||
<XMI.extensions xmi.extender="umbrello" >
|
||||
<docsettings viewid="209" documentation="" uniqueid="234" />
|
||||
<diagrams>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="1" documentation="" type="402" showops="1" showpackage="0" name="InstallDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<classwidget usesdiagramfillcolour="0" width="142" showattsigs="601" usesdiagramusefillcolour="0" x="543" y="273" showopsigs="601" linewidth="none" fillcolour="#ffffc0" height="135" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="14" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="#ff0000" />
|
||||
<classwidget usesdiagramfillcolour="0" width="204" showattsigs="601" usesdiagramusefillcolour="0" x="35" y="355" showopsigs="601" linewidth="none" fillcolour="#ffffc0" height="63" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="24" showoperations="1" showpackage="1" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="#ff0000" />
|
||||
<notewidget usesdiagramfillcolour="1" width="413" usesdiagramusefillcolour="1" x="27" y="149" linewidth="none" fillcolour="none" height="185" usefillcolor="1" isinstance="0" xmi.id="46" showstereotype="1" text="@d: is a bsddb dict which holds package related data.
|
||||
key:"package name" value:InstallInfo
|
||||
|
||||
"/var/db/pisi/install.bdb"
|
||||
|
||||
@dp: is a bsddb dict which holds pending packages data.
|
||||
key:"package name" value:bool
|
||||
|
||||
"/var/db/pisi/configpending.bdb"
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="411" usesdiagramusefillcolour="1" x="15" y="14" linewidth="none" fillcolour="none" height="113" usefillcolor="1" isinstance="0" xmi.id="47" text="installdb.py
|
||||
|
||||
The main purpose of the installdb is to hold the packages' version and status infos. " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="313" usesdiagramusefillcolour="1" x="678" y="50" linewidth="none" fillcolour="none" height="245" usefillcolor="1" isinstance="0" xmi.id="49" showstereotype="1" text="@state: holds the status of the package
|
||||
'i' : 'installed'
|
||||
'ip' : 'installed-pending'
|
||||
'r' : 'removed'
|
||||
'p' : 'purged'
|
||||
@version: version of the package
|
||||
@release: release number of the package
|
||||
@build: build number of the package
|
||||
@distribution: distribution of the package. (exp: "Pardus")
|
||||
@time: the time when the package is installed
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="14" widgetaid="24" xmi.id="90" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="239" starty="386" />
|
||||
<endpoint endx="543" endy="340" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="391" y="363" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="227" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<floatingtext usesdiagramfillcolour="1" width="56" usesdiagramusefillcolour="1" x="241" y="362" linewidth="none" posttext="" role="709" fillcolour="none" height="22" usefillcolor="1" pretext="+" isinstance="0" xmi.id="228" text="name" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="52" documentation="" type="402" showops="1" showpackage="0" name="RepoDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<notewidget usesdiagramfillcolour="1" width="453" usesdiagramusefillcolour="1" x="16" y="13" linewidth="none" fillcolour="none" height="108" usefillcolor="1" isinstance="0" xmi.id="54" text="repodb.py
|
||||
|
||||
The main purpose of the repodb is to hold the repositories' infos (currently we only have the repository's url).
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="139" showattsigs="601" usesdiagramusefillcolour="1" x="35" y="299" showopsigs="601" linewidth="none" fillcolour="none" height="45" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="86" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="403" usesdiagramusefillcolour="1" x="22" y="165" linewidth="none" fillcolour="none" height="101" usefillcolor="1" isinstance="0" xmi.id="88" showstereotype="1" text="@d: is a bsddb dict which holds repositories' infos
|
||||
key:"repository name" value:Repo
|
||||
|
||||
"/var/db/pisi/repodb.bdb"
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="121" showattsigs="601" usesdiagramusefillcolour="1" x="538" y="259" showopsigs="601" linewidth="none" fillcolour="none" height="45" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="98" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="243" usesdiagramusefillcolour="1" x="615" y="211" linewidth="none" fillcolour="none" height="58" usefillcolor="1" isinstance="0" xmi.id="106" showstereotype="1" text="@indexuri: url of the repository. " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="98" widgetaid="86" xmi.id="100" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="174" starty="321" />
|
||||
<endpoint endx="538" endy="281" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="356" y="301" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="229" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="109" documentation="" type="402" showops="1" showpackage="0" name="FilesDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<notewidget usesdiagramfillcolour="1" width="404" usesdiagramusefillcolour="1" x="14" y="14" linewidth="none" fillcolour="none" height="113" usefillcolor="1" isinstance="0" xmi.id="110" text="filesdb.py
|
||||
|
||||
The main purpose of the filesdb is to hold all the packages' files' information.
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="139" showattsigs="601" usesdiagramusefillcolour="1" x="43" y="338" showopsigs="601" linewidth="none" fillcolour="none" height="45" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="111" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="420" usesdiagramusefillcolour="1" x="15" y="188" linewidth="none" fillcolour="none" height="115" usefillcolor="1" isinstance="0" xmi.id="113" showstereotype="1" text="@d: is a bsddb dict which holds file infos that all the installed packages have.
|
||||
|
||||
key:"file path" value: (packagename, FileInfo) tuple
|
||||
"/var/db/pisi/filesdb.bdb"
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="140" showattsigs="601" usesdiagramusefillcolour="1" x="538" y="244" showopsigs="601" linewidth="none" fillcolour="none" height="122" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="114" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="335" usesdiagramusefillcolour="1" x="640" y="81" linewidth="none" fillcolour="none" height="223" usefillcolor="1" isinstance="0" xmi.id="133" showstereotype="1" text="@path: path of the file
|
||||
@type: type of the file. ("doc", "man", "info", "config", "header", "library", "executable", "data", "localedata")
|
||||
@size: size of the file
|
||||
@hash: sha1sum of the file
|
||||
@permanent: If true, file is not removed when the package is removed. " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="114" widgetaid="111" xmi.id="120" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="182" starty="360" />
|
||||
<endpoint endx="538" endy="305" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="360" y="332" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="230" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="136" documentation="" type="402" showops="1" showpackage="0" name="ItemByRepo" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<enumwidget usesdiagramfillcolour="0" width="85" usesdiagramusefillcolour="0" x="507" y="249" linewidth="none" fillcolour="#ffffc0" height="126" usefillcolor="1" isinstance="0" xmi.id="141" showpackage="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" />
|
||||
<classwidget usesdiagramfillcolour="1" width="139" showattsigs="601" usesdiagramusefillcolour="1" x="52" y="262" showopsigs="601" linewidth="none" fillcolour="none" height="45" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="146" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="394" usesdiagramusefillcolour="1" x="38" y="178" linewidth="none" fillcolour="none" height="69" usefillcolor="1" isinstance="0" xmi.id="148" showstereotype="1" text="@d: is a bsddb dict which holds another key,value dict
|
||||
key: objkey value:dict("repo name", objvalue)
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="453" usesdiagramusefillcolour="1" x="16" y="20" linewidth="none" fillcolour="none" height="108" usefillcolor="1" isinstance="0" xmi.id="152" text="itembydb.py
|
||||
|
||||
The main purpose of the itembyrepo class is make it easier for holding datas by repository." font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="141" widgetaid="146" xmi.id="149" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="191" starty="284" />
|
||||
<endpoint endx="507" endy="312" />
|
||||
</linepath>
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="153" documentation="" type="402" showops="1" showpackage="0" name="ComponentDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<notewidget usesdiagramfillcolour="1" width="453" usesdiagramusefillcolour="1" x="16" y="20" linewidth="none" fillcolour="none" height="108" usefillcolor="1" isinstance="0" xmi.id="154" text="component.py
|
||||
|
||||
The main purpose of the componentdb is to hold the repositories component infos. " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="130" showattsigs="601" usesdiagramusefillcolour="1" x="31" y="332" showopsigs="601" linewidth="none" fillcolour="none" height="47" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="155" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="401" usesdiagramusefillcolour="1" x="30" y="203" linewidth="none" fillcolour="none" height="112" usefillcolor="1" isinstance="0" xmi.id="157" showstereotype="1" text="@d: is a ItemByRepo object which contains component infos by repos.
|
||||
|
||||
key: "component name" value: Component
|
||||
"/var/db/pisi/component.bdb"
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="160" showattsigs="601" usesdiagramusefillcolour="1" x="549" y="317" showopsigs="601" linewidth="none" fillcolour="none" height="153" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="163" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="335" usesdiagramusefillcolour="1" x="673" y="106" linewidth="none" fillcolour="none" height="223" usefillcolor="1" isinstance="0" xmi.id="176" showstereotype="1" text="@name: component name
|
||||
@localname: components local name (system.base) -> (sistem.taban)
|
||||
@summary: component information
|
||||
@component: component description
|
||||
@dependencies: string list of other components this component depends on.
|
||||
@packages: string list of packages under this component
|
||||
@sources: string list of source packages under this component" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="163" widgetaid="155" xmi.id="171" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="161" starty="355" />
|
||||
<endpoint endx="549" endy="393" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="355" y="374" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="231" showstereotype="1" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1021" snapy="10" showatts="1" xmi.id="184" documentation="" type="402" showops="1" showpackage="0" name="PackageDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="579" >
|
||||
<widgets>
|
||||
<notewidget usesdiagramfillcolour="1" width="453" usesdiagramusefillcolour="1" x="16" y="20" linewidth="none" fillcolour="none" height="108" usefillcolor="1" isinstance="0" xmi.id="185" text="packagedb.py
|
||||
|
||||
The main purpose of the packagedb is to hold package infos of the repositories and reverse dependency informations." font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="125" showattsigs="601" usesdiagramusefillcolour="1" x="36" y="428" showopsigs="601" linewidth="none" fillcolour="none" height="63" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="186" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="418" usesdiagramusefillcolour="1" x="32" y="177" linewidth="none" fillcolour="none" height="235" usefillcolor="1" isinstance="0" xmi.id="189" showstereotype="1" text="@d: is a ItemByRepo object which holds the package informations of repos.
|
||||
key:"package name" value:Package
|
||||
|
||||
"/var/db/pisi/package.bdb"
|
||||
|
||||
@d: is a ItemByRepo object which holds reverse dependency information of packages.
|
||||
key:"dependency name" value: [dependent package names list]
|
||||
|
||||
"/var/db/pisi/revdep.bdb" " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="217" showattsigs="601" usesdiagramusefillcolour="1" x="557" y="296" showopsigs="601" linewidth="none" fillcolour="none" height="243" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="190" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="317" usesdiagramusefillcolour="1" x="700" y="187" linewidth="none" fillcolour="none" height="120" usefillcolor="1" isinstance="0" xmi.id="206" showstereotype="1" text="@name: package name
|
||||
@summary: package's summary
|
||||
@description: description of the package
|
||||
@partof: package's component
|
||||
@license: license of the package
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="190" widgetaid="186" xmi.id="203" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="161" starty="459" />
|
||||
<endpoint endx="557" endy="417" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="359" y="438" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="232" showstereotype="1" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
<diagram snapgrid="0" showattsig="1" fillcolor="#ffffc0" linewidth="0" zoom="100" showgrid="0" showopsig="1" usefillcolor="1" snapx="10" canvaswidth="1012" snapy="10" showatts="1" xmi.id="209" documentation="" type="402" showops="1" showpackage="0" name="SourceDB" localid="900000" showstereotype="0" showscope="1" snapcsgrid="0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="#ff0000" canvasheight="593" >
|
||||
<widgets>
|
||||
<notewidget usesdiagramfillcolour="1" width="453" usesdiagramusefillcolour="1" x="27" y="22" linewidth="none" fillcolour="none" height="108" usefillcolor="1" isinstance="0" xmi.id="210" text="sourcedb.py
|
||||
|
||||
The main purpose of the sourcedb is for emerge operation. " font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="175" showattsigs="601" usesdiagramusefillcolour="1" x="33" y="433" showopsigs="601" linewidth="none" fillcolour="none" height="63" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="211" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
<notewidget usesdiagramfillcolour="1" width="414" usesdiagramusefillcolour="1" x="31" y="174" linewidth="none" fillcolour="none" height="242" usefillcolor="1" isinstance="0" xmi.id="214" showstereotype="1" text="@d: is a ItemByRepo object which contains source packages building information of the package for emerge.
|
||||
key: "source package name" value: SpecFile
|
||||
|
||||
"/var/db/pisi/source.bdb"
|
||||
|
||||
@d: is a ItemByRepo object which contains package name information and that package's source package name information
|
||||
key: "package name" value:"source package name"
|
||||
|
||||
"/var/db/pisi/pkgtosrc.bdb"
|
||||
" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
<classwidget usesdiagramfillcolour="1" width="133" showattsigs="601" usesdiagramusefillcolour="1" x="666" y="365" showopsigs="601" linewidth="none" fillcolour="none" height="99" usefillcolor="1" showpubliconly="0" showattributes="1" isinstance="0" xmi.id="215" showoperations="1" showpackage="0" showscope="1" font="DejaVu Sans,9,-1,5,75,0,0,0,0,0" linecolor="none" />
|
||||
</widgets>
|
||||
<messages/>
|
||||
<associations>
|
||||
<assocwidget totalcounta="2" indexa="1" totalcountb="2" indexb="1" linewidth="none" widgetbid="215" widgetaid="211" xmi.id="222" linecolor="none" >
|
||||
<linepath>
|
||||
<startpoint startx="208" starty="464" />
|
||||
<endpoint endx="666" endy="414" />
|
||||
</linepath>
|
||||
<floatingtext usesdiagramfillcolour="1" width="32" usesdiagramusefillcolour="1" x="437" y="439" linewidth="none" posttext="" role="703" fillcolour="none" height="32" usefillcolor="1" pretext="" isinstance="0" xmi.id="233" showstereotype="1" text="1..*" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0" linecolor="none" />
|
||||
</assocwidget>
|
||||
</associations>
|
||||
</diagram>
|
||||
</diagrams>
|
||||
<listview>
|
||||
<listitem open="1" type="800" label="Görünümler" >
|
||||
<listitem open="1" type="801" label="Mantıksal Görünüm" >
|
||||
<listitem open="1" type="813" id="163" >
|
||||
<listitem open="0" type="814" id="164" />
|
||||
<listitem open="0" type="814" id="165" />
|
||||
<listitem open="0" type="814" id="166" />
|
||||
<listitem open="0" type="814" id="167" />
|
||||
<listitem open="0" type="814" id="168" />
|
||||
<listitem open="0" type="814" id="169" />
|
||||
<listitem open="0" type="814" id="170" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="155" >
|
||||
<listitem open="0" type="814" id="156" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="114" >
|
||||
<listitem open="0" type="814" id="115" />
|
||||
<listitem open="0" type="814" id="116" />
|
||||
<listitem open="0" type="814" id="117" />
|
||||
<listitem open="0" type="814" id="118" />
|
||||
<listitem open="0" type="814" id="119" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="111" >
|
||||
<listitem open="0" type="814" id="112" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="220" />
|
||||
<listitem open="1" type="813" id="24" >
|
||||
<listitem open="1" type="813" id="14" >
|
||||
<listitem open="0" type="814" id="79" />
|
||||
<listitem open="0" type="814" id="80" />
|
||||
<listitem open="0" type="814" id="81" />
|
||||
<listitem open="0" type="814" id="82" />
|
||||
<listitem open="0" type="814" id="83" />
|
||||
<listitem open="0" type="814" id="84" />
|
||||
</listitem>
|
||||
<listitem open="0" type="814" id="25" />
|
||||
<listitem open="0" type="814" id="77" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="146" >
|
||||
<listitem open="0" type="814" id="147" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="76" />
|
||||
<listitem open="1" type="813" id="190" >
|
||||
<listitem open="0" type="814" id="191" />
|
||||
<listitem open="0" type="814" id="192" />
|
||||
<listitem open="0" type="814" id="193" />
|
||||
<listitem open="0" type="814" id="194" />
|
||||
<listitem open="0" type="814" id="195" />
|
||||
<listitem open="0" type="814" id="196" />
|
||||
<listitem open="0" type="814" id="197" />
|
||||
<listitem open="0" type="814" id="198" />
|
||||
<listitem open="0" type="814" id="199" />
|
||||
<listitem open="0" type="814" id="200" />
|
||||
<listitem open="0" type="814" id="201" />
|
||||
<listitem open="0" type="814" id="202" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="186" >
|
||||
<listitem open="0" type="814" id="187" />
|
||||
<listitem open="0" type="814" id="188" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="98" >
|
||||
<listitem open="0" type="814" id="99" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="86" >
|
||||
<listitem open="0" type="814" id="87" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="217" />
|
||||
<listitem open="1" type="813" id="211" >
|
||||
<listitem open="0" type="814" id="212" />
|
||||
<listitem open="0" type="814" id="213" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="215" >
|
||||
<listitem open="0" type="814" id="216" />
|
||||
<listitem open="0" type="814" id="218" />
|
||||
<listitem open="0" type="814" id="219" />
|
||||
<listitem open="0" type="814" id="221" />
|
||||
</listitem>
|
||||
<listitem open="1" type="813" id="177" />
|
||||
<listitem open="1" type="830" label="Veri türleri" >
|
||||
<listitem open="1" type="829" id="5" />
|
||||
<listitem open="1" type="829" id="4" />
|
||||
<listitem open="1" type="829" id="89" />
|
||||
<listitem open="1" type="829" id="7" />
|
||||
<listitem open="1" type="829" id="6" />
|
||||
<listitem open="1" type="829" id="2" />
|
||||
<listitem open="1" type="829" id="9" />
|
||||
<listitem open="1" type="829" id="8" />
|
||||
<listitem open="1" type="829" id="13" />
|
||||
<listitem open="1" type="829" id="10" />
|
||||
<listitem open="1" type="829" id="12" />
|
||||
<listitem open="1" type="829" id="11" />
|
||||
</listitem>
|
||||
<listitem open="1" type="831" id="141" >
|
||||
<listitem open="0" type="839" id="142" />
|
||||
<listitem open="0" type="839" id="143" />
|
||||
<listitem open="0" type="839" id="144" />
|
||||
<listitem open="0" type="839" id="145" />
|
||||
</listitem>
|
||||
</listitem>
|
||||
<listitem open="1" type="802" label="Use Case Görünümü" />
|
||||
<listitem open="1" type="821" label="Bileşen Görünümü" />
|
||||
<listitem open="1" type="827" label="Deployment View" />
|
||||
<listitem open="1" type="836" label="Entity Relationship Model" />
|
||||
</listitem>
|
||||
</listview>
|
||||
<codegeneration>
|
||||
<codegenerator language="C++" />
|
||||
</codegeneration>
|
||||
</XMI.extensions>
|
||||
</XMI>
|
||||
@@ -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