
\chapter{packagedevelopment -- Paketentwicklung mit und f"ur eisfair}

\begin{verbatim}
    Last Update:
    $Id$
\end{verbatim}



Inhalt:
\begin{itemize}
    \item Was ist packagedevelopment?
    \item Konventionen der Dokumentation
    \item Voraussetzungen
        \begin{itemize}
            \item SSH-Konfiguration, Repository-Zugriff mit svn+ssh://
        \end{itemize}
    \item Beschreibung des erstellten Repositories
        \begin{itemize}
            \item Die Sektion 'backup'
            \item Die Sektion 'base'
            \item Die Sektion 'chat'
            \item Die Sektion 'communication'
            \item Die Sektion 'contrib'
            \item Die Sektion 'database'
            \item Die Sektion 'devel'
            \item Die Sektion 'drivers'
            \item Die Sektion 'game'
            \item Die Sektion 'kernel'
            \item Die Sektion 'lib'
            \item Die Sektion 'libdev'
            \item Die Sektion 'mail'
            \item Die Sektion 'misc'
            \item Die Sektion 'multimedia'
            \item Die Sektion 'netservices'
            \item Die Sektion 'netutils'
            \item Die Sektion 'news'
            \item Die Sektion 'plang'
            \item Die Sektion 'printer-file'
            \item Die Sektion 'security'
            \item Die Sektion 'system'
            \item Die Sektion 'utils'
            \item Die Sektion 'web'
            \item Entfallene Sektionen
        \end{itemize}
    \item Ablage und Strukturierung des Inhaltes eines zuk"unftigen
          Paketes
    \item Struktur eines Paketes im Repository
        \begin{itemize}
            \item Konfigurationsdateien eines Paketes
            \item Vorgehensweise beim Package-Build
            \item Aktualisierung des Package Info File
            \item Berechnung der Versionsnummer und des Paket-Status
            \item Erzeugung von Tags und Branches
        \end{itemize}
    \item Verwendung des Text-GUI
        \begin{itemize}
            \item List known packages out of folder list
            \item Create empty structure for a new package
            \item Check out existing package or update a existing working
                  copy
            \item (Re)Create file list for a folder on a package
            \item Create a release of a package
            \item Create a tag of the actual state of the trunk or a
                  bugfix branch
            \item Show released versions of a package
            \item Eislist administration
                  (show/search/add/remove/re-create)
            \item Choose package
            \item Command history
        \end{itemize}
    \item Der Paketbau
        \begin{itemize}
            \item Der Bau normaler Pakete (keine lib- oder libdev-Pakete)
            \item Der Bau von lib- und libdev-Paketen
            \item Tags von lib- und libdev-Paketen
        \end{itemize}
    \item Ausf"uhrung von speziellen Aufgaben vor bzw. nach dem Paketbau
    \item Automatisierter Paketbau -- Nightly-Builds
    \item Settings von 'packagedevelopment'
    \item Verweise
\end{itemize}




\section{Was ist packagedevelopment?}
Bei diesem Paket handelt es sich um eine Art Framework f"ur
Paketentwickler, welches die immer wieder notwendigen, wiederkehrenden
Schritte beim Paketbau "ubernimmt und somit den Entwickler von diesen
T"atigkeiten weitestgehend befreit. Weiterhin werden damit der
einheitliche Aufbau der eisfair-Pakete vereinfacht und Komplikationen
durch fehlende oder auch falsche Paketkomponenten verringert bzw. sogar
ganz ausgeschlossen. Der Paket-Autor wird damit weder von seiner Pflicht
entbunden, seine Pakete sauber zu entwickeln, noch wird er von den
M"oglichkeiten abgeschnitten, selbst an den relevanten Stellen
einzugreifen. Ihm wird lediglich 'geholfen'. :-)




\section{Konventionen der Dokumentation}
\begin{itemize}
    \item Die im weiteren Verlauf dieser Dokumentation genannten Dateien
          liegen, wenn nicht gesondert erw"ahnt, im Ordner
          'trunk/\_ADMIN/'.
    \item Bei den dargestellten Verzeichnis-Strukturen werden Ordner
          durch ein vorangestelltes '+' und Dateien durch '-'
          gekennzeichnet. Ein '|' symbolisiert die Zusammengeh"origkeit
          innerhalb einer Verzeichnis-Ebene.
    \item Es wird (zun"achst) nicht jedes Script einzeln beschrieben,
          sondern der Aufbau und die Organisation der Paketdaten und
          warum das so ist. Damit werden die M"oglichkeiten der Scripte
          verst"andlich und es wird ein mglw. "uberst"urztes Vorgehen
          vermieden.
    \item Die Namen der Scripte enden immer auf '*-new.sh'. Das r"uhrt
          daher, dass diese Scripte parallel zu den bisherigen
          Build-Scripten auf dem Server des eisfair-Teams entwickelt
          wurden und dort ebenfalls verwendet werden.
\end{itemize}




\section{Voraussetzungen}
Die Scripte in diesem Paket ben"otigen ein Subversion-Repository, in
welchem s"amtliche Daten vorgehalten werden. Dies betrifft die Scripte
selbst, sowieauch die Daten der damit entwickelten Pakete. Demzufolge
werden neben dem Zugriff auf ein solches Repository auch die
entsprechenden Befehle ben"otigt welche durch das Paket 'subversion' zur
Verf"ugung gestellt werden.

Es wird \_nicht\_ explizit eine Build-Umgebung vorausgesetzt. Das
Kompilieren hat mit dem eigentlichen Paketbau nichts zu tun. Nat"urlich
ist es sehr wahrscheinlich, dass auf der Entwickler-Maschine auch
Kompiler etc. vorhanden sind, zwingend notwendig ist das jedoch nicht.
Bspw. wird f"ur die Entwicklung von php-Paketen wie 'phpmyadmin' kein
Kompiler ben"otigt.

F"ur die Anwendung der Scripte werden \_nicht\_ zwingend root-Rechte
ben"otigt! Somit kann man die Paketentwicklung als normaler User
durchf"uhren. Es ist jedoch darauf zu achten, dass dieser User die
notwendigen Rechte hat, um die Pakete in die entsprechenden
Deployment-Folder zu kopieren. Dazu sp"ater mehr.



\subsection{SSH-Konfiguration, Repository-Zugriff mit svn+ssh://}
Soll auf das Repository mit der Protokoll-Kombination 'svn+ssh://'
zugegriffen werden, so wird die ssh-Konfigurationsdatei ~/.ssh/config im
Home-Ordner des entsprechenden Users ben"otigt. Darin muss der zu
verwendende ssh-User f"ur den Repository-Server, das zu verwendende
ssh-Keyfile, der Host sowie der vollst"andige Hostname des
Repository-Servers angegeben werden.

Im Vorfeld muss also sichergestellt werden, dass der ssh-Zugriff auf den
Repository-Server mit Keyfile-Authentifizierung funktioniert.

\begin{example}
Das ssh-Konfigurationsfile kann dann bspw. so aussehen:
\begin{verbatim}
eis # cat /home/starwarsfan/.ssh/config
Host             repoeis
    Hostname     repoeis.foobar.org
    User         starwarsfan
    IdentityFile /home/starwarsfan/.ssh/id_rsa_repoeis
\end{verbatim}
\end{example}

Der beim Schl"usselwort 'User' angegebene User muss also dem Usernamen
auf dem Repository-Server entsprechen und beim Schl"usselwort
'IdentityFile' wird der zu verwendende Private-Key angegeben.

Wichtig ist ausserdem, dass dieses File nur der entsprechende User lesen
bzw. schreiben darf!

\begin{verbatim}
eis # ls -l /home/alice/.ssh/config
-rw-------  1 alice users 164 Nov  4 22:15 /home/starwarsfan/.ssh/config
\end{verbatim}




\section{Beschreibung des erstellten Repositories}
Bei der Verwendung eines leeren Repositories wird darin die bei eisfair
verwendete Sektion-Struktur angelegt. Diese Struktur befindet sich
jeweils unterhalb der drei Basis-Ordner 'trunk', 'branches' und 'tags'.
Konkret sieht das dann so aus:

\begin{verbatim}
Repository
 + trunk
 |   + _ADMIN
 |   + backup
 |   + base
 |   + chat
 |   + communication
 |   + contrib
 |   + database
 |   + devel
 |   + driver
 |   + game
 |   + kernel
 |   + lib
 |   + libdev
 |   + mail
 |   + misc
 |   + multimedia
 |   + netservices
 |   + netutils
 |   + news
 |   + plang
 |   + printer-file
 |   + security
 |   + system
 |   + utils
 |   + web
 |
 + branches
 |   + backup
 |   + base
...
 |   + utils
 |   + web
 |
 + tags
 |   + backup
 |   + base
...
     + utils
     + web
\end{verbatim}


Der Ordner '\_ADMIN' ist nur im Trunk vorhanden. Dort liegen die mit
diesem Paket gelieferten Build-Scripte. Die restlichen Ordner sind in
allen drei Basis-Ordnern identisch.

Die Sektion-Ordner werden anhand der Eintr"age aus dem File
'sections-new.txt' erzeugt. Darauf bauen im weiteren Verlauf auch die
Build-Scripte auf. Je nachdem in welcher Sektion sp"ater Pakete
entwickelt werden, werden sich die entsprechenden Ordner nach und nach
mit Inhalt f"ullen.

In den folgenden Abschnitten eine kurze Erl"auterung, wof"ur die
Sektionen zu verwenden sind.



\subsection{Die Sektion 'backup'}
In dieser Sektion sollen Pakete platziert werden, welche sich mit dem
Sichern und Wiederherstellen von Daten besch"aftigen.



\subsection{Die Sektion 'base'}
Diese Sektion enth"alt Basisbestandteile des eisfair-Systems und wird
haupts"achlich vom Team direkt betreut.



\subsection{Die Sektion 'chat'}
Hier k"onnen Pakete platziert werden, welche sich mit den verschiedensten
Formen des Chats besch"aftigen. Beispiele hierf"ur sind IRC, Jabber oder
auch TeamSpeak.



\subsection{Die Sektion 'communication'}
Die Sektion 'communication' enth"alt Pakete, welche sich unter dem
Stichwort 'B"urokommunikation' oder 'Office communication' zusammenfassen
lassen. Das sind bspw. die Pakete 'asterisk', 'eisfax' oder 'vbox'.



\subsection{Die Sektion 'contrib'}



\subsection{Die Sektion 'database'}
Hier werden alle Pakete zu Datenbanken abgelegt. Das betrifft sowohl die
jeweilige Datenbank direkt, als auch die Tools daf"ar. Zwei Beispiele
sind hier die Pakete 'mysql' sowie 'phpmyadmin'.



\subsection{Die Sektion 'devel'}
Unter dieser Sektion werden all die Pakete gef"uhrt, welche sich mit der
Entwicklung besch"aftigen. Das sind also all die Pakete, welche f"ur die
Entwicklung von weiteren eisfair-Paketen ben"otigt werden.



\subsection{Die Sektion 'drivers'}
In dieser Sektion werden Treiber-Pakete abgelegt, wie sie f"ur spezielle
Hardware ben"utigt werden. Dies sind bspw. Pakete mit Treibern f"ur die
AVM-ISDN-Karten oder RAID-Controller.



\subsection{Die Sektion 'game'}
In der Sektion 'game' sollen Pakete platziert werden, welche
Serverdienste f"ur (Online-)Spiele bieten.



\subsection{Die Sektion 'kernel'}
Diese Sektion enth"alt Basisbestandteile des eisfair-Systems und wird
haupts"achlich vom Team direkt betreut.



\subsection{Die Sektion 'lib'}
Diese Sektion beinhaltet die Bibliotheks-Pakete. Diese Pakete m"ussen
immer mit der Zeichenfolge 'lib' beginnen, was jedoch von
packagedevelopment beim Anlegen eines solchen Paketes ggf. automatisch
erg"anzt wird.



\subsection{Die Sektion 'libdev'}
Die Sektion 'libdev' stellt eine besondere Sektion dar. Als Ordner ist
sie noch ein "Uberbleibsel aus fr"uheren Zeiten, sie enth"alt nun
physikalisch keine Pakete mehr. In der Liste der Pakete werden in dieser
Sektion die Dev-Pakete zur jeweiligen Bibliothek aufgef"uhrt, welche
jedoch effektiv zusammen mit der Bibliothek in der Sektion 'lib'
entwickelt werden.

Einfach gesagt: In der Sektion 'lib' werden sowohl die 'lib-' als auch
die 'libdev-'Pakete entwickelt. Damit liegt alles was zusammen geh"ort in
einem Basisordner.



\subsection{Die Sektion 'mail'}
Hier werden alle Pakete in Zusammenhang mit Emails platziert. Beispiele
daf"ur sind nat"urlich das 'mail' Paket, sowie 'antispam' oder auch
'archimap'.



\subsection{Die Sektion 'misc'}
In der Sektion 'misc' k"onnen Pakete platziert werden, welche eine
Funktionalit"at bieten, welche sich nicht einer der anderen Sektion
zuordnen l"asst. Beispiele sind hier die Pakete 'lcd' oder 'motion'.



\subsection{Die Sektion 'multimedia'}
Die Sektion 'multimedia' dient der Aufnahme von Paketen welche sich mit
jeglicher Form von Video- und/oder Audiodaten besch"aftigen. Dazu z"ahlen
bspw. die Pakete 'vdr', 'mpg123' oder 'cdrecord'.



\subsection{Die Sektion 'netservices'}
Die Pakete dieser Sektion bieten Dienste in Zusammenhang mit dem Netzwerk
an. Dabei handelt es sich um die verschiedensten Arten von Services und
Daemons wie sie bspw. die Pakete 'bonding', 'dns' oder 'inet' bieten.



\subsection{Die Sektion 'netutils'}
Im Gegensatz zur vorherigen Sektion werden hier die Pakete gef"uhrt,
welche den Admin bei seiner Arbeit unterst"utzen sollen. Also finden sich
hier verschiedene Utilities wie bspw. 'addhost' oder auch 'phpldapadmin'.



\subsection{Die Sektion 'news'}
In dieser Sektion werden Pakete abgelegt, welche sich mit dem News-System
besch"aftigen, also Newsreader.



\subsection{Die Sektion 'plang'}
Die Sektion 'plang' beinhaltet Pakete zur Entwicklung bzw. Programmierung
in den verschiedensten Programmiersprachen. Dies sind bspw. die Pakete
f"ur Java, Python oder Perl.



\subsection{Die Sektion 'printer-file'}
In dieser Sektion werden die Pakete f"ur Druck- und Dateidienste
abgelegt. Dies sind bspw. die Pakete f"ur NFS-Freigaben sowie Samba oder
auch verschiedene Konverter wie 'html2ps' oder 'a2ps'.



\subsection{Die Sektion 'security'}
Pakete dieser Sektion besch"aftigen sich mit der Sicherheit des Servers
bzw. nicht nur des Servers. Dazu z"ahlen bspw. die Pakete 'certs' oder
'clamav'.



\subsection{Die Sektion 'system'}
Hier werden Pakete f"ur den allgemeinen Betrieb des Servers vorgehalten.
Dazu z"ahlen bspw. Pakete wie 'quota' oder 'smartmon'.



\subsection{Die Sektion 'utils'}
In der Sektion 'utils' werden Tools und Werkzeuge untergebracht, welche
f"ur die ganz normale Benutzung oder auch Administration des Servers
ben"otigt werden. Beispiele sind die Pakete 'zip', 'sasl' oder 'chroot'.



\subsection{Die Sektion 'web'}
Hier werden die Pakete f"ur den Webzugriff auf den Server vorgehalten.
Dies sind die Basispakete wie bspw. 'apache2' sowie darauf aufbauend
bspw. 'apache2\_webalizer' oder 'trac'.



\subsection{Entfallene Sektionen}
Im Zuge der Bereinigung der Sektion-Struktur sind die folgenden Sektionen
entfallen bzw. aufgesplittet oder umbenannt worden. Dem einen oder
anderen Entwickler sind diese mglw. noch bekannt:

\begin{itemize}
  \item admin
  \item dns-dhcp
  \item etc
  \item inet-mail-news
  \item interpreter
  \item net
\end{itemize}

Die Pakete dieser Sektionen sollen zum jeweils n"achsten Release nach
M"oglichkeit in der nun g"ultigen Sektion erscheinen.




\section{Ablage und Strukturierung des Inhaltes eines zuk"unftigen
         Paketes}
Im Folgenden wird der prinzipielle Aufbau der Ordnerstruktur beschrieben,
mit welcher die Pakete verwaltet/gepflegt/gebaut werden.

Jedes den Build-Scripten bekannte Paket wird einmalig in der Datei
'folder-list-new.txt' eingetragen. In dieser Datei wird die
Sektion-Struktur erneut abgebildet und durch den Eintrag eines Paketes an
entsprechender Stelle dessen Platzierung im Repository definiert. F"ur
die beiden Pakete 'phpmyadmin' und 'phpldapadmin' w"urde das wie folgt
aussehen:

\begin{verbatim}
backup:#---------------BACKUP---------------------
base:#---------------BASE-----------------------
chat:#---------------CHAT-----------------------
communication:#---------------COMMUNICATION--------------
contrib:#---------------CONTRIB--------------------
database:#---------------DATABASE-------------------
database:phpmyadmin                                          <--
devel:#---------------DEVEL----------------------
drivers:#---------------DRIVERS--------------------
game:#---------------GAME-----------------------
kernel:#---------------KERNEL---------------------
lib:#---------------LIB------------------------
libdev:#---------------LIBDEV---------------------
mail:#---------------MAIL-----------------------
misc:#---------------MISC-----------------------
multimedia:#---------------MULTIMEDIA-----------------
netservices:#---------------NETSERVICES----------------
netutils:#---------------NETUTILS-------------------
netutils:phpldapadmin                                        <--
news:#---------------NEWS-----------------------
plang:#---------------PLANG----------------------
printer-file:#---------------PRINTER-FILE---------------
security:#---------------SECURITY-------------------
system:#---------------SYSTEM---------------------
utils:#---------------UTILS----------------------
web:#---------------WEB------------------------
\end{verbatim}

(Die beiden Pfeile am Zeilenende dienen nur der Illustration!)

Es gibt f"ur jede Sektion eine Zeile als Separator-Eintrag nach obigem
Schema. Nach der Sektion folgt getrennt durch ':\#' ein einfacher
Kommentar, welcher im TextGUI der Scripte zur optischen Trennung der
Sektionen verwendet wird.

Nach diesem Eintrag werden die Pakete der jeweiligen Sektion aufgelistet.
Ein Eintrag f"ur ein Paket hat zwingend den folgenden Aufbau:

\begin{verbatim}
   <section>:<package>
\end{verbatim}

Die Sektion muss dabei einem Eintrag aus 'sections-new.txt' entsprechen.

Hinweis:
   Eine Sonderstellung bei der Einordnung nehmen libdev-Pakete ein. Diese
   Pakete haben zwar eine eigene Sektion, werden jedoch physikalisch
   zusammen mit der zugeh"origen Library in der Sektion 'lib'
   vorgehalten. Damit wird eine einfache Wartung und Entwicklung
   der entsprechenden Pakete gew"ahrleistet, da somit s"amtliche
   Bestandteile beeinander sind und nicht zwei Ordner aus
   verschiedenen Sektionen ausgecheckt werden m"ussen. F"ur das
   Handling von Library-Paketen folgt sp"ater noch ein eigenes Kapitel.

Entsprechend dem Eintrag in 'folder-list-new.txt' existiert f"ur das
Paket im tats"achlichen Sektion-Ordner unterhalb von 'trunk' der
eigentliche Paket-Ordner, in welchem das Paket entwickelt und gepflegt
wird:

\begin{verbatim}
Repository
 + trunk
...
 |   + contrib
 |   + database
 |   |   + phpmyadmin
 |   |
 |   + devel
 |   + dns-dhcp
...
\end{verbatim}




\section{Struktur eines Paketes im Repository}
Wird ein leeres, also ein neues Paket erzeugt, dann entsteht im
entsprechenden Ordner eine weitere definierte Struktur. F"ur die
Erzeugung eines neuen Paketes gibt es selbstverst"andlich ein Script.
Genaueres dazu folgt sp"ater, hier zun"achst die entstehende Struktur:

\begin{example}
Repository
\begin{verbatim}
 + trunk
...
 |   + contrib
 |   + database
 |   |   + phpmyadmin
 |   |       + _ADMIN
 |   |       |   - phpmyadmin-global-settings.txt
 |   |       |
 |   |       + common
 |   |       |   + _ADMIN
 |   |       |   |   - phpmyadmin-files.txt
 |   |       |   |   - phpmyadmin-settings.txt
 |   |       |   |   - phpmyadmin-state.txt
 |   |       |   |   - phpmyadmin-version.txt
 |   |       |   |
 |   |       |   + tmp
 |   |       |   + usr
 |   |       |   + var
 |   |       |
 |   |       + eisfair-1
 |   |       |   + _ADMIN
 |   |       |   + var
 |   |       |
 |   |       + eisfair-2
 |   |           + _ADMIN
 |   |           + var
 |   |
 |   |
 |   + devel
 |   + dns-dhcp
...
\end{verbatim}
\end{example}



\subsection{Konfigurationsdateien eines Paketes}
Im Paket-Hauptordner wird der Ordner '\_ADMIN' angelegt, in welchem sich
ein einziges File befindet: '<package>-global-settings.txt'. Wie der Name
schon erkennen l"asst, werden in dieser Datei globale Einstellungen f"ur
den Build dieses Paketes definiert. Welche Einstellungen das sind wird
sp"ater erkl"art, da f"ur deren Verst"andnis der restliche Aufbau des
Paketes im Repository bekannt sein muss.


Hier die Kurzform:
   In den Ordnern \_unterhalb\_ eines Paket-Ordners gibt es immer
   g"ultige Bestandteile eines Paketes mit allem was dazu geh"ort. Also
   auch eine FileList f"ur den Inhalt \_dieses\_ Ordners. Im globalen
   Settingsfile wird angegeben, welche dieser Ordner zusammengepackt
   werden, um ein komplettes eisfair-Paket zu erzeugen. So lassen sich
   die Bestandteile eines Paketes aufteilen: Unterhalb von common liegt
   das, was bei allen Paketen gleich ist. In den anderen Ordnern dann der
   'Rest', welcher f"ur ein komplettes Paket fehlt, jedoch von Zielsystem
   zu Zielsystem unterschiedlich ist.


Neben dem Ordner '\_ADMIN' wird noch 'common' sowie bei Bedarf
'eisfair-1' und 'eisfair-2' angelegt. Das ist davon abh"angig, f"ur
welches Zielsystem das Paket entwickelt werden soll.

   Ein Vorgriff auf das Script zum Anlegen eines neuen Paketes:
   Soll das Paket f"ur nur ein Zielsystem entwickelt werden (bspw.
   nur f"ur eisfair-2), dann werden nur die Ordner '\_ADMIN' und
   'common' angelegt. Werden jedoch mehrere Zielsysteme gew"unscht,
   dann werden f"ur jedes dieser Zielsysteme separate Ordner
   erzeugt. Der Sinn und Zweck dieser "Ubung wird in den folgenden
   Abschnitten erkl"art.

Im Ordner '<package>/common/' sowie jedem weiteren Ordner parallel dazu
gibt es ebenfalls einen Ordner '\_ADMIN/', welcher die folgenden vier
Dateien enth"alt:

\begin{itemize}
  \item <package>-files.txt -
        Die "ubliche Datei-Liste f"ur alle Dateien, welche unterhalb des
        aktuellen Basis-Ordners vorhanden sind.
  \item <package>-settings.txt -
        Settings das aktuelle Paket betreffend
  \item <package>-state.txt -
        Der interne (!) Status des Paketes. Das hat nichts mit 'testing'
        oder 'stable' zu tun, sondern ist eine Vorbereitung f"ur das
        Lifecycle-Management der Pakete. Dazu gibt es momentan noch keine
        weitere Verwendung, es ist eine rein perspektifische
        Vorbereitung.
  \item <package>-version.txt -
        Die aktuelle Version des Paketes.
\end{itemize}


Weiterhin befindet sich unterhalb von '<package>/common/' die minimal
notwendige Verzeichnis-Struktur, welche f"ur ein eisfair-Paket ben"otigt
wird. Es ist kein Problem, hier bei Bedarf weitere Verzeichnisse
anzulegen.

Sind neben '<package>/\_ADMIN/' und '<package>/common/' weitere Ordner
vorhanden (wie bspw. '<package>/eisfair-1' und '<package>/eisfair-2'),
so enthalten diese jeweils mindestens wieder einen Ordner '\_ADMIN' sowie
'var/install/packages/' mit einem minimalen Package-Info-File.

Die Idee hinter dieser Strukturierung ist die:
Wird ein Paket nur f"ur ein Zielsystem gebaut (bspw. eisfair-1) oder es
ist f"ur mehrere Zielsysteme identisch (wie bspw. phpmyadmin), dann wird
nur der Ordner 'common' ben"otigt und darin das gesamte Paket entwickelt.

Unterscheiden sich jedoch Teile des Paketes wie bspw. unterschiedliche
Binaries f"ur eisfair-1 und eisfair-2, so werden diese Teile unterhalb
von '<package>/eisfair-1/...' bzw. '<package>/eisfair-2/...' gepflegt.
Damit ist es m"oglich, die identischen Teile wie bspw. die Doku oder
Install-Scripte in '<package>/common/...' einmalig f"ur beide Pakete zu
pflegen, w"ahrend die unterschiedlichen Bestandteile separat abgelegt
werden.

An dieser Stelle kommt die Datei '<package>-global-settings.txt' ins
Spiel. Darin werden die Bestandteile der verschiedenen Build-Targets
definiert. Das sieht f"ur das eben beschriebene Beispiel so aus:

\begin{verbatim}
packageComment[0]='Package for eisfair-1'
packageToBuild[0]='common
                   eisfair-1'
packageComment[1]='Package for eisfair-2'
packageToBuild[1]='common
                   eisfair-2'
\end{verbatim}


Wenn nun das Paket f"ur eisfair-1 gebaut werden soll, so wird dem
Build-Script mitgeteilt, dass es das Build-Target '0' bauen soll, welches
sich aus den Ordnern 'common' und 'eisfair-1' zusammensetzt. F"ur
eisfair-2 ist das demzufolge Build-Target '1', welches die Ordner
'common' und 'eisfair-2' verwendet.

In diesem Settings-File sind vorbereitete Eintr"age f"ur zehn
Build-Targets vorhanden, welche ihrerseits beliebig viele Ordner
enthalten k"onnen. Somit ist Folgendes kein Problem:

\begin{verbatim}
...
packageComment[1]='Package for eisfair-2'
packageToBuild[1]='common
                   eisfair-2
                   special-content
                   more-content'
...
\end{verbatim}

Damit werden die vier aufgelisteten Ordner in das Paket verpackt.



\subsection{Vorgehensweise beim Package-Build}
Beim Paketbau werden die Konfigurationsfiles '<package>-settings.txt',
'<package>-state.txt', '<package>-version.txt' sowie das
Package-Info-File im ersten aufgelisteten Ordner gesucht. Das ist
i. d. R. immer 'common'. Gibt es einen weiteren Ordner, dann werden die
Konfigurationsfiles nach der Suche im ersten Ordner im zweiten Ordner
gesucht. Falls sie im ersten Ordner vorhanden, im zweiten jedoch nicht
vorhanden waren, dann werden die Files aus dem ersten Ordner verwendet;
ansonsten die Files aus dem zweiten Ordner.

Wurden in den ersten beiden Ordnern keine Konfig-Files gefunden, dann
werden alle weiteren Ordner durchsucht. Werden keine Konfigurationen
gefunden, wird der Build abgebrochen.

Wenn sich ein Paket f"ur verschiedene Zielsysteme unterscheidet, gibt es
immer separate Ordner je Zielsystem. Somit sollte die Reihenfolge der
Ordner in den Build-Targets in '<package>-global-settings.txt' immer so
gew"ahlt werden, dass an zweiter Stelle der Ordner steht, in welchem sich
die jeweiligen Paket-Settings sowie das zu verwendende Package-Info-File
befindet. Damit wird erm"oglicht, dass die Pakete je nach Zielsystem
eigenst"andig gepflegt werden k"onnen, was sich durch separate
Versionsnummern je nach Zielsystem wiederspiegelt.

Es werden also die im Build-Target angegebenen Ordner von oben nach unten
nach den Konfigurationsfiles durchsucht. Im Anschluss daran werden die
enthaltenen Dateien in umgekehrter Reihenfolge, also von unten nach oben,
zum Paket-Archiv hinzugef"ugt. Wird dabei eine Datei gefunden, welche
bereits zum Archiv hinzugef"ugt wurde, wird der Build mit der Meldung auf
eine doppelt vorhandene Datei abgebrochen. Dies kann explizit vermieden
werden, indem eine (aus welchen Gr"unden auch immer) doppelt vorhandene
Datei in der entsprechenden Filelist mit dem Flag 'i' (ignore) versehen
wird.



\begin{example}
Um dies nochmals zu verdeutlichen hier die Ordnerstruktur des fiktiven
Paketes 'dbtool':
\begin{verbatim}
Repository
 + trunk
...
 |   + database
 |   |   + dbtool
 |   |       + _ADMIN
 |   |       |   - dbtool-global-settings.txt
 |   |       |
 |   |       + common
 |   |       |   + _ADMIN
 |   |       |   |   - dbtool-files.txt
 |   |       |   |   - dbtool-settings.txt
 |   |       |   |   - dbtool-state.txt
 |   |       |   |   - dbtool-version.txt
 |   |       |   |
 |   |       |   + tmp
 |   |       |   + usr
 |   |       |   + var
 |   |       |
 |   |       + binaries-eisfair-1
 |   |       |   + _ADMIN
 |   |       |   + usr
 |   |       |       + sbin
 |   |       |
 |   |       + binaries-eisfair-2
 |   |       |   + _ADMIN
 |   |       |   + usr
 |   |       |       + sbin
 |   |       |
 |   |       + eisfair-1
 |   |       |   + _ADMIN
 |   |       |   + var
 |   |       |
 |   |       + eisfair-2
 |   |           + _ADMIN
 |   |           + var
 |   |
...
\end{verbatim}
\end{example}



\begin{example}
F"ur diese Ordnerstruktur seien die folgenden Build-Targets definiert:
\begin{verbatim}
packageComment[0]='Package for eisfair-1'
packageToBuild[0]='common
                   eisfair-1
                   binaries-eisfair-1'
packageComment[1]='Package for eisfair-2'
packageToBuild[1]='common
                   eisfair-2
                   binaries-eisfair-2'
\end{verbatim}
\end{example}


Wird nun das Paket f"ur eisfair-1 gebaut, dann werden die Konfig-Dateien
aus 'trunk/database/dbtool/eisfair-1/\_ADMIN/' verwendet. Im weiteren
Verlauf werden zun"achst die Binaries aus
'trunk/database/dbtool/binaries-eisfair-1/' in das Archiv gepackt, dann
die Dateien aus 'trunk/database/dbtool/eisfair-1/' und zuletzt die
Dateien aus 'trunk/database/dbtool/common/'.



\subsection{Aktualisierung des Package Info File}
Im Package Info File gibt es eigentlich nur noch vier Tags, welche vom
Entwickler explizit von Hand gepflegt werden m"ussen und selbst das
mitunter auch nur einmal nach der initialen Erstellung des Paketes:

\begin{itemize}
  \item <short/> -
        Die Kurzbeschreibung des Paketes als Einzeiler
  \item <require-package/> bzw. <require-lib/> -
        Ben"otigte Pakete und Libraries
  \item <description/> -
        Die Paket-Kurzbeschreibung als Absatz f"ur einen groben
        "Uberblick.
  \item <author/> -
        Der Paketautor incl. Email-Adresse.
\end{itemize}

Alle weiteren Tags werden automatisch beim Build des Paketes
aktualisiert.

Das folgende Kapitel widmet sich einer ausf"uhrlichere Betrachtung der
Versionsnummer eines Paketes und deren Berechnung sowie dem daraus
resultierenden Paket-Status.



\subsection{Berechnung der Versionsnummer und des Paket-Status}
Basis der Versionierung von eisfair-Paketen ist eine aus drei Bl"ocken
bestehende Versionsnummer. Diese Bl"ocke werden durch Punkte voneinander
getrennt, womit sich das folgende Schema ergibt:

\begin{verbatim}
    <major>.<minor>.<bugfix>
\end{verbatim}

Die drei Bl"ocke repr"asentieren somit die Major-, Minor- und
Bugfix-Version des Paketes. Ausserdem wird an Hand des Typs der
Minor-Nummer der Status des Paketes bestimmt:

\begin{itemize}
  \item Ist der Minor eine gerade Ziffer, dann ist das Paket 'stable'
  \item Ist der Minor eine ungerade Ziffer, dann ist das Paket im Status
        'testing'
\end{itemize}

Damit lassen sich alle m"oglichen Varianten abbilden und zudem ist allein
aus der Versionsnummer heraus der Paket-Status einheitlich definiert.

Ein Paket w"urde sein Dasein also mit der Version 0.1.0 beginnen, einem
'testing'-Release. Auf den Status 'unstable' wurde ganz verzichtet, da
damit eine genaue Definition dessen, wann denn nun ein Paket 'unstabil'
und wann 'zum testen geeignet' ist, auch nicht vereinfacht wird. Es ist
lediglich so, dass ein Paket mit der Version 0.x.x immer 'testing' ist,
die anderen Status kommen erst ab Version 1.0.0 zum tragen.


\begin{example}
Somit ergibt sich bspw. folgender Ablauf:
\begin{verbatim}
1. Release      1.0.0   <-- Stable
2. Bugfix       1.0.1   <-- ebenfalls Stable
3. Bugfix       1.0.2   <-- nochmal Stable
4. Vorabversion 1.1.0   <-- Testing
5. Bugfix       1.0.3   <-- wieder Stable
6. Vorabversion 1.1.1   <-- Testing
7. Release      1.2.0   <-- Stable
8. Bugfix       1.2.1   <-- Bugfix der neuesten Stable-Version
9. Bugfix       1.0.4   <-- Bugfix einer "Alteren Version
\end{verbatim}
\end{example}

Nun stellt sich h"ochstwahrscheinlich die Frage, wie die Version 1.0.3 an
Position f"unf dort hineinpasst und wie die Version 1.0.4 in der letzten
Zeile 'gemacht' werden soll.

Die Scripte in diesem Paket unterst"utzen konsequent das bew"ahrte
Subversion-Konzept von 'Trunk', 'Tags' und 'Branches'. Damit wird eine
solch flexible Paketpflege erst erm"oglicht. Konkret lauft das wie folgt
ab:

Das Paket wird im Trunk entwickelt. Das von dort ver"offentlichte Paket
erh"alt die Version 1.0.0. Aus dieser Version wird ein Bugfix-Branch
angelegt, auf welchem die Bugfixes (und nur die Bugfixes!) zu dieser
stabilen Version implementiert werden. Da hier nur Bugfixes und keine
Features implementiert werden, sind die aus dem Bugfix-Branch generierten
Pakete ebenfalls 'stable'.

Da bei dieser Vorgehensweise die weitere Entwicklung eines Paketes von
den Bugfixes losgel"ost ist, k"onnen also die einzelnen stabilen Releases
unabh"angig voneinander gepflegt werden. Damit werden die Features des
Pakets im Trunk weiterentwickelt und k"onnen als 'testing' herausgegeben
werden, w"ahrend im Bugfix-Branch bzw. in den Bugfix-Branches die
stabilen Versionen 'stabil bleiben'. Je nach Umfang der "Anderungen
werden die relevanten Teile aus dem Bugfix-Branch in den Trunk gemerged,
so dass diese dort ebenfalls enthalten sind.

   Hier sei auf die Dokumentation von Subversion [1] verwiesen,
   insbesondere auf die Kapitel zum mergen von Bugfixes in den
   Release-Branch.

Damit sollte klar sein, dass in obigem Beispiel die Eintr"age 1., 4., 6.
und 7. aus dem 'trunk' kommen, 2., 3., 5., 8. und 9. jedoch aus
'branches'.

  Wichtig:
  Die Scripte des Paketes 'packagedevelopment' k"ummern sich um
  alle notwendigen Schritte bei der Erzeugung und dem Checkout
  sowohl des Bugfix-Branches als auch der entsprechenden Tags!
  Der Entwickler muss also lediglich an den 'richtigen' Stellen
  arbeiten, der Rest wird ihm abgenommen.



\subsection{Erzeugung von Tags und Branches}
Wird ein Paket gebaut, dann kann f"r diesen Entwicklungsstand ein Tag
angelegt werden. Aus diesem Tag kann dann ein Bugfix-Branch erzeugt
werden. Allerdings k"onnen Bugfix-Branches nur aus Stable-Tags erzeugt
werden. Damit wird sichergestellt, das keine 'krummen' Versionen (also
Testing's) zu Bugfixes mutieren. Das bedeutet, dass Bugfixes f"ur den
Testing-Zweig direkt im Trunk eingepflegt werden m"ussen. F"ur Tags bzw.
Branches wird in die zu Begin geschilderte Verzeichnisstruktur eine
weitere Ebene eingef"ugt, welche die einfache Identifikation der
Paketversion erm"oglicht. Dabei sind Tag's nach dem folgenden Schema
aufgebaut:

\begin{verbatim}
       <major>.<minor>.<bugfix>\_<target-no>[\_<destination-system>]*
\end{verbatim}

Bugfix-Branches sehen prinzipiell genauso aus, nur werden diese bei
'<bugfix>' durch ein 'x' kenntlich gemacht.


\begin{example}
Bsp.:
\begin{verbatim}
 - 1.0.0\_0\_eisfair-1   Release 1.0.0 f"ur eisfair-1, hieraus entsteht
                         der Bugfix-Branch 1.0.x\_0\_eisfair-1
 - 1.0.0\_1\_eisfair-2   Release 1.0.0 f"ur eisfair-2, hieraus entsteht
                         der Bugfix-Branch 1.0.x\_1\_eisfair-2
 - 1.2.3\_0\_eisfair-1   Dritter Bugfix f"ur Release 1.2.0 f"ur eisfair-1
 - 2.0.2\_1\_eisfair-2   Zweiter Bugfix f"ur Release 2.0.0 f"ur eisfair-2
\end{verbatim}
\end{example}

Diese Ordner sowie die dazugeh"orenden Bugfix-Branches gliedern sich wie
folgt in die Repository-Struktur ein:

\begin{example}
Repository
\begin{verbatim}
 + trunk
...
 |
 + tags
 |   + database
 |   |   + dbtool
 |   |       + 1.0.0\_0\_eisfair-1
 |   |       + 1.0.0\_1\_eisfair-2
 |   |       + 1.2.3\_0\_eisfair-1
 |   |       + 2.0.2\_1\_eisfair-2
...
 + branches
...
     + database
     |   + dbtool
     |       + 1.0.x\_0\_eisfair-1
     |       + 1.0.x\_1\_eisfair-2
     |       + 1.2.x\_0\_eisfair-1
     |       + 2.0.x\_1\_eisfair-2
    ...
\end{verbatim}
\end{example}

An dieser Stelle ein sehr wichtiger Hinweis: Unterhalb dieser Ordner
befindet sich zwar jeweils der gesamte Paket-Inhalt, dieser ist aber
\_nur\_ f"ur das im Ordnernamen aufgef"uhrte Build-Target wirklich valid!
Das hat seinen Grund unter anderem darin, dass die Pakete f"ur die
verschiedenen Zielsysteme eigenst"undige Versionsnummern haben, welche
sich sonst nicht sauber in Tags bzw. Branches aufl"osen lassen w"urden.
Da in diesen Ordnern aber keinerlei Weiterentwicklung der Pakete erfolgt
sondern lediglich die Bugfixes bearbeitet werden, stellt diese
Einschr"ankung keine allzu grosse H"urde dar. Zudem hat der Entwickler
dank Subversion jederzeit die M"oglichkeit, die Inhalte der Ordner zu
mergen.



\section{Verwendung des Text-GUI}
F"ur eine einheitliche Verwendung der Scripte gibt es ein zentrales,
textbasiertes GUI: 'admin-packages-new.sh'. "Uber die Men"upunkte dieses
Scriptes werden die Parameter f"ur alle anderen Scripte ermittelt und
diesen dann "Ubergeben.

Bei allen Operationen bietet das GUI die M"oglichkeit an, die aktuelle
Operation abzubrechen und wieder ins Hauptmen"u zur"uck zu gelangen.


\begin{example}
Die folgenden Men"upunkte stehen zur Verf"ugung:
\begin{verbatim}
#========================================================================
# eisfair - the easy internet server                  No package selected
#========================================================================
#
#  Please choose your next step by entering one of the following numbers:
#         (You will be asked for additional information if necessary)
#  1 - List known packages out of folder list
#  2 - Create empty structure for a new package
#  3 - Check out existing package or update a existing working copy (tag'
#      version, bugfix branch by base version number or main development)
#  4 - (Re)Create file list for a folder on a package
#  5 - Create a release of a package (testing (odd minor number), stable
#      (even minor) or bugfix (even minor and upcounting bugfix number))
#  6 - Create a tag of the actual state of the trunk (for a stable or
#      testing release) or the actual state of a bugfix branch
#  7 - Show released versions of a package
#  8 - Eislist administration (show/search/add/remove/re-create)
#
# C - Choose package
# H - Command history               Any other key will end up this script
#========================================================================
\end{verbatim}
\end{example}



Bei allen Operationen welche sich auf ein vorhandenes Paket beziehen,
wird zun"uchst das zu bearbeitenden Paket ausgew"ahlt. Das selektierte
Paket wird daraufhin in der Titelleiste eingeblendet:

\begin{verbatim}
#========================================================================
# eisfair - the easy internet server                    Working on foobar
#========================================================================
\end{verbatim}

Solange das GUI nicht beendet wird, bleibt diese Auswahl erhalten. Um sie
zu "andern kann der Men"upunkt 'C - Choose package' verwendet werden.
Siehe dazu den Abschnitt 'Choose package'.



\subsection{List known packages out of folder list}
Mit diesem Men"upunkt werden alle bekannten Pakete aufgelistet. Dabei
handelt es sich effektiv um den Inhalt des Files 'folder-list-new.txt',
welcher entweder komplett oder nur f"ur eine bestimmte Sektion
aufgelistet wird.



\subsection{Create empty structure for a new package}
Hier kann die minimale Struktur f"ur ein neues, leeres eisfair-Paket
erzeugt werden. Dazu folgen eine ganze Reihe weiterer Fragen, welche die
notwendigen Parameter zur Paketerzeugung ermitteln. Diese Parameter
werden im Anschluss an das Script 'create-package-new.sh' "ubergeben,
welches die notwendigen Schritte zur Paketerstellung ausf"uhrt.

Die folgenden Dinge werden abgefragt:
\begin{itemize}
  \item Welcher Sektion das neue Paket angeh"oren soll.
  \item Ob die neue Struktur in das Repository eingecheckt werden soll.
        Default-Antwort: yes
  \item Ob das Paket in die folder-list eingetragen werden soll.
        Default-Antwort: yes
  \item F"ur welche Zielsysteme das Paket entwickelt werden soll. Die
        hier angebotene Auswahlliste entspricht den Eintr"agen aus
        'system-tags.txt'.
  \item Der Name des Paketes
\end{itemize}

Nachdem diese Angaben erfolgt sind, werden einige Checks ausgef"uhrt und
wenn keine Probleme aufgetreten sind, wird das Paket angelegt.



\subsection{Check out existing package or update a existing working copy
            (tag'ed version, bugfix branch by base version number or main
             development)}
Um ein Paket aus dem Repository auszuchecken bzw. um eine vorhandene
Working-Copy zu aktualisieren, wird dieser Men"upunkt verwendet.

Dabei kann das Paket aus der Liste aller Pakete oder aus der Liste der
Pakete einer Sektion ausgew"ahlt bzw. Sektion und Paketname von Hand
eingegeben werden.

Danach wird erfragt, von wo ausgecheckt bzw. updated werden soll. Bedingt
durch die Subversion Repository Struktur stehen hier drei M"oglichkeiten
zur Wahl:
\begin{itemize}
  \item Die Entwicklungslinie des Paketes, also aus dem Trunk
  \item Ein Bugfix-Branch
  \item Ein Tag
\end{itemize}

Bei Auswahl von Branch oder Tag wird eine weitere Angabe ben"otigt und
zwar die gew"unschte Version in der Form <major.minor> f"ur
Bugfix-Branches bzw. <major.minor.bugfix> f"ur Tags. Wird hier keine
Angabe gemacht, so wird die aktuellste Version (also die Version mit der
h"ochsten Versionsnummer) ermittelt und diese ausgecheckt bzw.
aktualisiert.



\subsection{(Re)Create file list for a folder on a package}
Im Zuge der Paketentwicklung wandern nat"urlich Dateien in das Paket bzw.
werden daraus entfernt. Um nun die jeweiligen FileLists nicht von Hand
pflegen zu m"ussen, wurde dieser Men"upunkt implementiert. Nat"urlich
ist eine Pflege 'von Hand' auch weiterhin m"oglich und teilweise
erforderlich.

Es wird das Paket erfragt und f"ur welchen Ordner unterhalb des Paketes
die FileList erzeugt werden soll. Damit ist es m"oglich, die FileList
f"ur jeden der Ordner unterhalb von .../<section>/<package>/ separat zu
erzeugen. Eine bereits vorhandene FileList wird vorher im gleichen Ordner
als '<package>-files.txt.bak' gesichert und zu svn:ignore hinzugef"ugt.
Somit k"onnen von dieser 'alten' FileList die Dateirechte der einzelnen
Files "ubernommen werden, falls diese nicht den bei der Erstellung der
FileList vorgefundenen Rechten entsprechen.

Der Aufbau der FileList wird in der Entwickler-Dokumentation beschrieben
und aus diesem Grund hier nicht nochmals dargelegt.



\subsection{Create a release of a package (testing (odd minor number),
            stable (even minor) or bugfix (even minor and upcounting
            bugfix number))}
Dieser Men"upunkt ist wohl der wichtigste Punkt im gesamten Paket, mit
diesem Punkt werden die Pakete gebaut. Aus diesem Grund gibt es daf"ur
einen separaten Abschnitt, welcher auf die sich hier er"offnenden
M"oglichkeiten eingeht: 'Der Paketbau'



\subsection{Create a tag of the actual state of the trunk (for a stable
            or testing release) or the actual state of a bugfix branch}
Mit diesem Men"upunkt kann f"ur den aktuellen Entwicklungsstand eines
Paketes im Trunk oder f"ur einen Bugfix-Branch ein Tag angelegt werden.
Dabei wird aus der vorgefundenen Version automatisch der entsprechende
Verzeichnisname wie unter 'Erzeugung von Tags und Branches' beschrieben
erzeugt.

Dabei kann das Paket aus der Liste aller Pakete oder aus der Liste der
Pakete einer Sektion ausgew"ahlt bzw. Sektion und Paketname von Hand
eingegeben werden.

Danach wird erfragt, von wo aus ein Tag erzeugt werden soll. Bedingt
durch die Subversion Repository Struktur stehen hier zwei M"oglichkeiten
zur Wahl:
\begin{itemize}
  \item Die Entwicklungslinie des Paketes, also der Trunk oder
  \item Ein Bugfix-Branch
\end{itemize}

Bei der Auswahl von Trunk wird daraufhin erfragt, f"ur welches
Build-Target ein Tag angelegt werden soll.

Bei der Auswahl von Branch wird erfragt, f"ur welchen der gefundenen
Bugfix-Branches ein Tag erzeugt werden soll. Hier entf"allt die Frage
nach dem Build-Target, das dieses durch den Branch selbst bereits
vorgegeben ist.


\subsection{Show released versions of a package}
Bei Aufruf dieser Funktion wird das gew"unschte Paket erfragt und dann
die ver"offentlichten Versionen des Paketes aufgelistet. Diese Liste
entspricht den Tags f"ur dieses Paket, da f"ur jedes Release ein Tag
angelegt werden sollte und es keine andere M"oglichkeit gibt, die
bisherigen Releases zu erfassen.



\subsection{Eislist administration (show/search/add/remove/re-create)}
Es k"onnen drei separate EisLists verwaltet werden. Damit wird
erm"oglicht, die Pakete je nach Entwicklungsstand unterschiedlichen
Personen zug"anglich zu machen. Diese EisLists gliedern sich nach ihrem
internen Namen wie folgt:

\begin{itemize}
  \item Developer  - Entwicklerpakete
  \item TestTeam   - Pakete, welche zum Testen zur Verf"ugung stehen
  \item Release    - Ver"offentlichte Pakete, welche dann auch via
                     PackEis gefunden werden. Diese Liste sollte also der
                     auf PackEis angegebenen EisList entsprechen.
\end{itemize}

Hier k"onnen nun die Eislists administriert werden. Dabei wird zun"achst
die gew"unschte Eislist erfragt und daraufhin ein Men"u mit den
m"oglichen Operationen angezeigt. Die Operationen im Einzelnen:

\begin{itemize}
  \item Show packages on eislist
        Listet die Pakete der gew"ahlten Eislist auf.
  \item Search a package
        Sucht ein Paket in der gew"ahlten Eislist und gibt daraufhin
        Versionen  und Ordner aus, in denen das gew"unschte Paket
        gefunden wurde.
  \item Add a package
        Hier kann ein Paket zur Eislist hinzugef"ugt werden. Dazu wird
        der volle Pfad (ohne Extension) zum Paket erfragt und das Paket
        daraufhin in die gew"ahlte Eislist kopiert und einsortiert.
  \item Remove a package
        Alle Pakete der gew"ahlten Eislist werden aufgelistet und das
        gew"unschte Paket wird aus der Eislist entfernt.
  \item Re-Create eislist
        Mit diesem Men"upunkt kann die zu Beginn ausgew"ahlte Eislist neu
        erzeugt werden. Dabei besteht die Auswahlm"oglichkeit, eine
        einfache oder eine strukturierte Eislist erzeugen zu lassen.
\end{itemize}

  Bei einer einfachen Eislist werden alle Pakete in einer Liste
  aufgef"uhrt. Bei einer strukturierten Eislist hingegen werden zun"achst
  die Sektionen der gefundenen Pakete aufgef"uhrt und erst nach Auswahl
  einer dieser Sektionen die dort befindlichen Pakete. Das entspricht dem
  Aufbau der Eislist, welche bei der normalen Paketinstallation via
  PackEis zu sehen ist.



\subsection{Choose package}
Mit diesem Men"upunkt kann das zu bearbeitende Paket ausgew"ahlt werden.
Solange das TextGUI nicht beendet wird, bleibt das gew"ahlte Paket f"ur
die weiteren Bearbeitungsschritte selektiert. Wurde kein Paket
selektiert, so wird bei allen relevanten Schritten zun"achst nach dem zu
bearbeitenden Paket gefragt. Das gew"ahlte Paket wird in der Titelzeile
des TextGUI angezeigt.



\subsection{Command history}
Hier werden die letzten durchgef"uhrten Befehle aufgelistet und k"onnen
erneut aufgerufen werden. Damit wird das wiederholte Ausf"uhren von
bestimmten Aktionen wesentlich erleichtert. Die Anzahl der hier
aufgelisteten Eintr"age wurde im Setup von packagedevelopment festgelegt.




\section{Der Paketbau}

\subsection{Der Bau normaler Pakete (keine lib- oder libdev-Pakete)}
Der zentrale und wichtigste Bestandteil von 'packagedevelopment' ist das
Script zum Erzeugen der Archive, also der installierbaren eisfair Pakete.
Im Folgenden zun"achst die Anwendung mit dem Text-GUI.

Auch hier muss zun"achst das gew"unschte Paket ausgew"ahlt werden. Danach
wird erfragt, welchen Release-Typ man erzeugen m"ochte. Damit wird
automatisch festgelegt, woher die zu verpackenden Daten kommen. Die
folgenden M"oglichkeiten stehen zur Wahl:

\begin{verbatim}
1) Abort operation                 4) A bugfix release
2) A testing release               5) A package from an existing tag
3) A stable release
\end{verbatim}


Auswahl 1) bricht die Operation ab, 2) und 3) legen 'trunk' als Quelle
fest. Bei Auswahl von 4) wird 'branches' bzw. bei 5) 'tags' verwendet.
Bei 4) und 5) folgt darauf noch eine zus"atzliche Frage nach dem zu
verwendenden Branch bzw. dem zu verwendenden Tag, da bei Branches bzw.
Tags jeweils ein zus"atzlicher Ordner vorhanden ist (siehe '6.5 Erzeugung
von Tags und Branches').

Im n"achsten Schritt wird erfragt, ob das Paket erneut mit der aktuellen
Versionsnummer gebaut werden soll. Per default wird die Versionsnummer
\_nicht\_ modifiziert. Aus diesem Grund wird die folgende Vorgehensweise
empfohlen: Wurde eine Version released und die Entwicklung geht weiter,
dann sollte der erste Paketbau als 'testing' \_mit\_ Modifizierung der
Versionsnummer erfolgen. Damit wird die g"ultige Versionsnummer nach dem
bereits erfolgten Release in <package>-version.txt eingetragen und
solange an dem Paket entwickelt wird, kann es beliebig oft mit dieser
Versionsnummer gebaut werden. Nachdem es released wurde, wird ein
entsprechendes Tag erzeugt und der Zyklus beginnt von vorn.

Wichtiger Hinweise:
   Es ist \_nicht\_ m"oglich ein 'trunk'- bzw. ein 'bugfix'-Paket ohne
   Ver"anderung der Versionsnummer zu bauen, wenn f"ur diese Version
   bereits ein Tag existiert! Genau f"ur diesen Fall existiert ein Tag
   und kann bzw. muss f"ur den Bau exakt dieser Version verwendet werden.
   Somit ist es im Fall der Paketweiterentwicklung bei ge'tag'ten
   Versionen zwingend erforderlich, dass der erste Build \_mit\_
   Modifizierung der Versionsnummer erfolgt.

Im n"achsten Schritt wird das gew"unschte Build-Target erfragt. Hier
werden die in der Datei '<package>-global-settings.txt' angegebenen
Kommentare zu den einzelnen Build-Targets zur Auswahl aufgelistet. Wurden
keine Kommentare eingetragen, so werden die Ordnernamen aufgelistet.

Nun folgt die Frage nach dem im <date>-Tag zu setzenden Datum. Dabei
stehen die folgenden Auswahlm"oglichkeiten zur Verf"ugung:

\begin{verbatim}
1) Abort operation
2) Now (with extension 'svn2008-07-11' right after the version number)
3) Now
4) Keep
5) Enter by hand
\end{verbatim}

zu 1) Abbruch der aktuellen Operation.
zu 2) Diese Variante baut sog. 'svn-Versionen' eines Paketes. Dabei wird
      die Versionsangabe im <version>-Tag um die Angabe 'svn<datum>'
      erweitert, was bspw. so aussehen kann:
                  '<version>1.2.3svn2008-05-02<version>'.
      Auf diese Art und Weise k"onnen Pakete gleicher Versionsnummer aber
      unterschiedlicher Entwicklungsst"ande bspw. auf der Tester-Eislist
      f"ur Tests zur Verf"ugung gestellt werden, ohne f"ur kleinere
      "Anderungen immer neue Versionsnummern generieren zu m"ussen. Somit
      dient diese Variante lediglich der Entwicklung und ist f"ur echte
      Releases nicht anwendbar. Pakete mit einem solchen Tag k"onnen auch
      nicht auf PackEis ver"offentlicht werden.
zu 3) Es wird das aktuelle Datum verwendet.
zu 4) Das Datum wird nicht ver"andert.
zu 5) Das einzutragende Datum kann in der Form YYYY-MM-DD vorgegeben
      werden.

Nun folgen drei Fragen zur Ver"offentlichung des Paketes, sprich dem
Eintragen des Paketes in die drei m"oglichen Eislists. Per default wird
das Paket in die Entwickler-Eislist eingetragen, in die TestTeam- und die
Release-Eislist jedoch nicht.

Die letzte Frage vor dem Bau des Paketes ist die Frage, ob die
modifizierten Dateien ins Repository commited werden sollen. Per default
werden \_keine\_ Dateien commited, so dass das Paket beliebig oft gebaut
werden kann.

An dieser Stelle ist die 'Fragerunde' beendet und der Bau des Paketes
beginnt. Dabei werden zun"achst eine Reihe Checks durchgef"uhrt und der
Paketbau ggf. abgebrochen. So ist es bspw. nicht m"oglich, eine
testing-Version ohne Modifikation der Versionsnummer zu bauen, wenn die
aktuelle Versionsnummer einer stable-Version entspricht. Weiterhin wird
der Build abgebrochen, wenn die FileLists nicht korrekt sind. Dabei gibt
es prinzipiell zwei F"alle zu unterscheiden: Einerseits k"onnen Dateien
vorhanden sein, welche nicht in der jeweiligen FileList eingetragen sind
und andererseits k"onnen Dateien in der FileList eingetragen sein, welche
es aber im Dateisystem nicht (mehr) gibt.

Sollte der Build mit einer entsprechenden Fehlermeldung abgebrochen
worden sein bzw. man weiss, dass Dateien hinzugef"ugt oder entfernt
worden sind, dann muss die FileList des entsprechenden Ordners
aktualisiert werden. Siehe dazu das Kapitel
'(Re)Create file list for a folder on a package'.



\subsection{Der Bau von lib- und libdev-Paketen}
Eine Besonderheit beim Paketbau stellen die lib- und libdev-Pakete dar.
In der EisList werden diese Pakete in zwei Sektionen gef"uhrt, eben den
Sektionen 'lib' und 'libdev'. Hier gibt es die erste Besonderheit: Die
libdev-Pakete liegen physikalisch ebenfalls unter der lib-Sektion im
Repository bzw. in der WorkingCopy. Das hat seinen Grund darin, dass ein
lib- und ein libdev-Paket immer zusammen geh"ort und somit der Checkout
bzw. Commit von zwei unterschiedlichen Locations nicht notwendig ist.
Diese Besonderheit wird durch die Art und Weise der Eintragung der
Build-Targets im globalen Settings-File des Paketes geregelt. Jeder
Eintrag f"ur ein lib-Paket hat dort eine spezielle Angabe f"ur die
Target-Nummer des zugeh"origen libdev-Paketes. Damit ist es m"oglich,
beim Bau des lib-Paketes das libdev-Paket gleich mit zu bauen.

Das File 'lib<package>-globel-settings.txt' hat damit beispielhaft den
folgenden Aufbau:

\begin{verbatim}
# Package out of the content of common and eisfair-1
packageComment[0]='Content of common and eisfair-1_bin_4.2.2'
packageToBuild[0]='common
                   eisfair-1_bin_4.2.2'
devPackage[0]=1

# Dev-package out of the content of common-dev and eisfair-1-dev
packageComment[1]='Content of common-dev and eisfair-1-dev_bin_4.2.2'
packageToBuild[1]='common-dev
                   eisfair-1-dev_bin_4.2.2'
devPackage[1]=''

# Package out of the content of common and eisfair-2
packageComment[2]='Content of common and eisfair-2_bin_4.2.2'
packageToBuild[2]='common
                   eisfair-2_bin_4.2.2'
devPackage[2]=3

# Dev-package out of the content of common-dev and eisfair-2-dev
packageComment[3]='Content of common-dev and eisfair-2-dev_bin_4.2.2'
packageToBuild[3]='common-dev
                   eisfair-2-dev_bin_4.2.2'
devPackage[3]=''
\end{verbatim}


Durch die Angabe von 'devPackage[0]=1' wird festgelegt, dass das
libdev-Paket zum BuildTarget 0 das BuildTarget 1 ist. Entsprechend ist
BuildTarget 3 das libdev-Paket f"ur BuildTarget 2.

Beim Bau eines lib-Paketes "uber das Text-GUI wird erfragt, ob das
libdev-Paket gleich mit gebaut werden soll. Dementsprechend wird beim Bau
eines libdev-Paketes via Text-GUI erfragt, ob der Build an dieser Stelle
abgebrochen werden soll, wenn man f"ur das libdev-Paket auch das
lib-Paket bauen m"ochte.

Eine weitere Besonderheit stellt die automatisierte Aktualisierung des
Installationsscriptes 'tmp/install.sh' dar. Endet der letzte der im
Build-Target angegebenen Ordner auf eine dreistellige, durch '.'
separierte und mit '\_' angeh"angte Versionsnummer, so wird install.sh
mit dieser Versionsnummer aktualisiert. Damit wird eine automatisierte
Erzeugung der ben"otigten Symlinks f"ur Libraries erm"oglicht. Die
ermittelte Versionsnummer wird ebenfalls verwendet, um das
PackageInfoFile zu aktualisieren.

Um diese Aktualisierungen vorzunehmen, wird in install.sh nach der
Zeichenkette 'libVersion=' gesucht und diese mit der ermittelten
Lib-Version aktualisiert. Aus diesem Grund gibt es in install.sh den
folgenden Abschnitt:

\begin{verbatim}
# Don't change the name of the following variable! It is automatically
# updated during the package build with mktarball
libVersion=<version>
\end{verbatim}


Im PackageInfoFile wird nach 'Internal Program Version:' gesucht
und diese Zeile mit dem Namen der Bibliothek sowie deren Version
aktualisiert.

Wird diese Funktionalit"at nicht gew"unscht, so gibt es zwei Varianten:
\begin{itemize}
  \item Entweder die genannten Zeichenketten werden ver"andert oder
  \item In den Ordnernamen gibt es keine Versionsangabe
\end{itemize}



\subsection{Tags von lib- und libdev-Paketen}
Das Tag'ing von lib- und libdev-Paketen erfolgt prinzipiell genauso wie
auch bei normalen Paketen. Die einzige Besonderheit besteht hier darin,
dass in einem Tag hier sowohl die lib- als auch die libdev-Version
vermerkt wird. Das zeigt sich in einer weiteren Angabe im Tag-Namen,
der Target-Nummer des libdev-Paketes:

\begin{verbatim}
<major>.<minor>.<bugfix>\_<lib-target>\_<libdev-target>[\_<dest-system>]*
\end{verbatim}

Somit sieht das beispielhaft wie folgt aus:

\begin{verbatim}
    1.2.0\_0\_1\_eisfair-1
\end{verbatim}



\section{Ausf"uhrung von speziellen Aufgaben vor bzw. nach dem Paketbau}
Je nach Paket kann es durchaus erforderlich sein, dass vor oder nach dem
Paketbau spezielle Aufgaben ausgef"uhrt werden m"ussen. Um solche
Operationen zu erm"oglichen, gibt es jeweils ein sog.
'\_do\_<package>.sh'-Script, welches im jeweiligen \_ADMIN-Ordner
platziert werden kann.

Um ein solches Script bei Bedarf zu erzeugen, steht das Script
'create-do-script-new.sh' zur Verf"ugung. Dazu muss dieses Script
lediglich aus dem \_ADMIN-Ordner heraus aufgerufen werden, in welchem ein
\_do\_<package>.sh-Script erzeugt werden soll. Als einziger Parameter ist
der Paketname erforderlich, da der Ordnername nicht zwingend dem
Paketnamen entspricht. Das erzeugte Script enth"alt Funktionsr"umpfe,
welche vom Entwickler mit der gew"unschten Funktionalit"at gef"allt
werden m"ussen.

W"urde ein solches Script f"ur das weiter oben bereits verwendete fiktive
Paket 'dbtool' f"ur spezielle Aufgaben unterhalb des Ordners 'eisfair-1'
ben"otigt werden, s"ahe die Ordnerstruktur wie folgt aus:

\begin{verbatim}
 + trunk
...
 |   + database
 |   |   + dbtool
 |   |       + _ADMIN
 |   |       + common
 |   |       + binaries-eisfair-1
 |   |       + binaries-eisfair-2
 |   |       + eisfair-1
 |   |       |   + _ADMIN
 |   |       |   |   - _do_dbtool.sh
 |   |       |   |   - dbtool-files.txt
 |   |       |   |   - dbtool-settings.txt
 |   |       |   |   - dbtool-state.txt
 |   |       |   |   - dbtool-version.txt
 |   |       |   + var
 |   |       |
 |   |       + eisfair-2
...
\end{verbatim}

Wird ein solches Script w"ahrend dem Paketbau gefunden, so wird es
zweimal aufgerufen: Einmal vor dem Verpacken der Dateien in das
Paketarchiv und einmal danach. Die Unterscheidung dieser Aufrufe erfolgt
durch entsprechende Parameter. Innerhalb des Scriptes steht der volle
Pfad zum trunk-Ordner f"ur die weitere Verwendung zur Verf"ugung.

Ein einfaches Beispiel zur Anwendung:
   Der preBuild-Teil des do-Scriptes holt sich die Sourcen eines Tools
   von einem "Offentlichen Server, entpackt und kompiliert diese und
   erzeugt mit dem Script 'create-list-new.sh' die FileList. Damit ist
   der preBuild-Teil beendet und der normale Paketbau l"auft ab.

   Der postBuild-Teil r"aumt wieder auf, indem er die Sourcen sowie die
   erzeugten Binaries l"oscht.

   Mit dieser Vorgehensweise ist es m"oglich, den eigentlichen Inhalt
   eines Paketes mit relativ wenig Aufwand aktualisieren zu k"onnen.



\section{Automatisierter Paketbau -- Nightly-Builds}
Es besteht die M"oglichkeit, die Pakete automatisiert bauen zu lassen.
Das ist insbesondere dann von Vorteil, wenn bspw. mehrere Leute Pakete
entwickeln oder bei intensiver Anwendung der do-Scripte spezielle
Aktualisierungen realisiert werden sollen.

Dabei ist konfigurierbar, welche Build-Targets der Pakete gebaut werden
sollen und welche nicht. Realisiert wird das durch die Variable
'nightlyBuilds' in '<package>-global-settings.txt'. Diese enth"alt eine
durch Spaces separierte Liste der Build-Targets, welche beim
Nightly-Build gebaut werden sollen. Sollen also bspw. die Build-Targets
0, 2 und 3 eines Paketes innerhalb des Nightly-Build gebaut werden, so
muss folgendes im globalen Settingsfile des Paketes eingetragen werden:

\begin{verbatim}
    nightlyBuilds='0 2 3'
\end{verbatim}


F"ur die Nightly-Builds gibt es ein separates Konfigurationsfile, welches
vom Aufbau her identisch mit dem normalen Konfigurationsfile ist. Damit
besteht die M"oglichkeit, im Konfigfile 'settings-nightly-builds.txt'
einen anderen Pfad zum Ablegen der erzeugten Pakete zu verwenden.

Die Nightly-Builds werden durch den periodischen Aufruf des Scriptes
'mk-all-tarballs-new.sh' realisiert, welcher in einem Cron-Job
untergebracht werden kann. Innerhalb dieses Scriptes wird "uber die in
'folder-list-new.txt' gefundenen Pakete iteriert und je nach den in
'nightlyBuilds' vorgefundenen Werte der Build des Paketes angestossen.
Dabei erfolgt selbstverst"andlich keine Modifikation der Versionsnummer
und auch kein svn-Commit.

Achtung! Besondere Vorsicht muss bei den Schritten innerhalb der
\_do\_-Scripte geboten sein! F"uhrt ein \_do\_-Script selbst"andig
commit's durch, so wird das auch bei den Nightly-Builds der Fall sein.




\section{Settings von 'packagedevelopment'}

\begin{description}

\config{START\_PACKAGEDEVELOPMENT}{START\_PACKAGEDEVELOPMENT}{STARTPACKAGEDEVELOPMENT}
    F"ur die Aktivierung von PACKAGEDEVELOPMENT muss diese Variable
    lediglich auf den Wert 'yes' gestellt werden. Das Paket kann nicht
    direkt deaktiviert werden, da die \_ADMIN-Scripte noch immer im
    Repository vorhanden sind.

    G"ultige Werte: yes, no

    Standard-Einstellung: START\_PACKAGEDEVELOPMENT='yes'




\config{PKGDEV\_SETUP\_FOR\_NEW\_REPO}{PKGDEV\_SETUP\_FOR\_NEW\_REPO}{PKGDEVSETUPFORNEWREPO}
    Hier wird eingestellt, ob es sich bei dem zu verwendenden Repository
    um ein neues, also leeres Repository handelt oder ob der Folder
    'trunk/\_ADMIN/' im Repository bereits vorhanden ist.
    Wird 'yes' ausgew"ahlt, wird das enthaltene Archiv vollst"andig
    entpackt, die Konfiguration entsprechend den weiteren Vorgaben
    angepasst und das gesamte Setup durchlaufen.
    Wird 'no' ausgew"ahlt, so wird die Basis-Struktur des angegebenen
    Repositories (also die Ordner 'trunk', 'branches' und 'tags') sowie
    die darunter befindlichen Section-Folder ohne Inhalt (!) ausgecheckt.
    Im Anschluss daran wird das File '\_ADMIN/settings.txt' entsprechend
    den Vorgaben von hier erzeugt.

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_SETUP\_FOR\_NEW\_REPO='yes'




\config{PKGDEV\_REPO\_PROTOCOL}{PKGDEV\_REPO\_PROTOCOL}{PKGDEVREPOPROTOCOL}
    Hier wird das f"ur die Verbindung zum Repository zu verwendende
    Protokoll konfiguriert.

    Wird 'svn+ssh://' verwendet, so muss im Home-Verzeichnis des in
    PKGDEV\_WORKING\_COPY\_USER angegebenen Users das File '.ssh/config'
    vorhanden sein. Darin muss die SSH-Verbindung zum Repository-Server
    konfiguriert werden. Weitere Informationen siehe Doku im Abschnitt
    3.1 SSH-Konfiguration, Repository-Zugriff mit svn+ssh://

    G"ultige Werte: 'file://', 'http://', 'https://', 'svn://', 'svn+ssh://'

    Standard-Einstellung: PKGDEV\_REPO\_PROTOCOL='file://'



\config{PKGDEV\_REPO\_PATH}{PKGDEV\_REPO\_PATH}{PKGDEVREPOPATH}
    Hier wird der Pfad bzw. URL zur Wurzel des Repositories angegeben.
    Wenn sich das Repo auf der gleichen Maschine befindet, der Zugriff
    also via PKGDEV\_REPO\_PROTOCOL='file://' erfolgt, so ist die Angabe
    in der folgenden Form m"oglich: '/pfad/zum/repo/'. Wenn also mit dem
    Paket subversion bspw. ein Repo unter '/data/repo/eisfair'
    eingerichtet wurde, dann muss hier '/data/repo/eisfair' eingetragen
    werden.
    Wird via http auf das Repository zugegriffen, folgt der Eintrag dem
    gleichen Schema. Angenommen der Server ist via dem URL 'mein.eis.de'
    zu erreichen. Wenn der Repo-Server ebenfalls ein eisfair ist, welcher
    mit dem Paket 'subversion' das Repository unter dem gleichen Namen
    zur Verf"ugung stellt, dann muss hier Folgendes eingetragen werden:
    'mein.eis.de/svn/eisfair'. F"ur weitere Angaben dazu kann auch die
    Subversion Dokumentation herangezogen werden.

    G"ultige Werte:
    \begin{itemize}
      \item g"ultiger absoluter Pfad zum Repository wenn
            PKGDEV\_REPO\_PROTOCOL='file://'
      \item URL zum Repository bei allen anderen Einstellungen in
            PKGDEV\_REPO\_PROTOCOL
    \end{itemize}

    Standard-Einstellung: PKGDEV\_REPO\_PATH='/data/repo/eisfair'



\config{PKGDEV\_REPO\_USERNAME}{PKGDEV\_REPO\_USERNAME}{PKGDEVREPOUSERNAME}
    G"ultige Werte: g"ultiger Benutzername f"ur das zu verwendende Repo

    Dieser Eintrag findet nur bei PKGDEV\_REPO\_PROTOCOL='http://' oder
    bei PKGDEV\_REPO\_PROTOCOL='https://' Anwendung.

    Standard-Einstellung: PKGDEV\_REPO\_USERNAME=''



\config{PKGDEV\_REPO\_PASSWORD}{PKGDEV\_REPO\_PASSWORD}{PKGDEVREPOPASSWORD}
    G"ultige Werte: g"ultiges Passwort f"ur den unter
    PKGDEV\_REPO\_USERNAME angegebenen Benutzer

    Dieser Eintrag findet nur bei PKGDEV\_REPO\_PROTOCOL='http://' oder
    bei PKGDEV\_REPO\_PROTOCOL='https://' Anwendung.

    Standard-Einstellung: PKGDEV\_REPO\_PASSWORD=''



\config{PKGDEV\_WORKING\_COPY\_PATH}{PKGDEV\_WORKING\_COPY\_PATH}{PKGDEVWORKINGCOPYPATH}
    Hier wird der Pfad zum Verzeichnis angegeben, in welchem die
    Working-Copy des Repositories angelegt werden soll. In diesem
    Verzeichnis entstehen daraufhin die Ordner welche unter
    'PKGDEV\_FOLDER\_NAME\_TRUNK', 'PKGDEV\_FOLDER\_NAME\_BRANCHES' und
    'PKGDEV\_FOLDER\_NAME\_TAGS' angegeben werden. Diese sind unter den
    erweiterten Einstellungen zu finden.

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
        PKGDEV\_WORKING\_COPY\_PATH='/data/development/eisfair'




\config{PKGDEV\_WORKING\_COPY\_USER}{PKGDEV\_WORKING\_COPY\_USER}{PKGDEVWORKINGCOPYUSER}
    Hier wird der User angegeben, welchem der Ordner
    'PKGDEV\_WORKING\_COPY\_PATH' nebst Inhalt geh"oren soll.

    G"ultige Werte: g"ultiger Username

    Standard-Einstellung:
        PKGDEV\_WORKING\_COPY\_USER='root'




\config{PKGDEV\_WORKING\_COPY\_GROUP}{PKGDEV\_WORKING\_COPY\_GROUP}{PKGDEVWORKINGCOPYGROUP}
    Hier wird die Gruppe angegeben, welcher der Ordner
    'PKGDEV\_WORKING\_COPY\_PATH' nebst Inhalt geh"oren soll.

    G"ultige Werte: vorhandene Gruppe

    Standard-Einstellung:
        PKGDEV\_WORKING\_COPY\_GROUP='root'




\config{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER}{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER}{PKGDEVDEVELOPMENTPACKAGEBASEFOLDER}
    Hier wird angegeben, wo die erzeugten Pakete abgelegt werden sollen.
    In diesem Folder werden die Pakete dann in aufsteigend nummerierte
    Verzeichnisse kopiert und eine entsprechende Eislist sowie
    Index-Datei generiert.
    Es k"onnen drei verschiedene Eislists verwaltet werden:
    \begin{itemize}
      \item PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER
    \end{itemize}
    Damit wird die M"oglichkeit gegeben, ein Paket je nach Status
    unterschiedlichen Zielgruppen zur Verf"ugung zu stellen. Die
    vorgegebene Struktur erm"oglicht somit eine Eislist f"ur Phase der
    Entwicklung, f"ur  die Testl"aufe und f"ur den Release.

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
         PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER=
              '/var/www/htdocs/eisfair/development'




\config{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER}{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER}{PKGDEVTESTTEAMPACKAGEBASEFOLDER}
    Hier wird angegeben, wo die erzeugten Pakete abgelegt werden sollen.
    In diesem Folder werden die Pakete dann in aufsteigend nummerierte
    Verzeichnisse kopiert und eine entsprechende Eislist sowie
    Index-Datei generiert.
    Es k"onnen drei verschiedene Eislists verwaltet werden:
    \begin{itemize}
      \item PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER
    \end{itemize}
    Damit wird die M"oglichkeit gegeben, ein Paket je nach Status
    unterschiedlichen Zielgruppen zur Verf"ugung zu stellen. Die
    vorgegebene Struktur erm"oglicht somit eine Eislist f"ur Phase der
    Entwicklung, f"ur  die Testl"aufe und f"ur den Release.

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
         PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER=
              '/var/www/htdocs/eisfair/testteam'




\config{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER}{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER}{PKGDEVRELEASEPACKAGEBASEFOLDER}
    Hier wird angegeben, wo die erzeugten Pakete abgelegt werden sollen.
    In diesem Folder werden die Pakete dann in aufsteigend nummerierte
    Verzeichnisse kopiert und eine entsprechende Eislist sowie
    Index-Datei generiert.
    Es k"onnen drei verschiedene Eislists verwaltet werden:
    \begin{itemize}
      \item PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER
      \item PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER
    \end{itemize}
    Damit wird die M"oglichkeit gegeben, ein Paket je nach Status
    unterschiedlichen Zielgruppen zur Verf"ugung zu stellen. Die
    vorgegebene Struktur erm"oglicht somit eine Eislist f"ur Phase der
    Entwicklung, f"ur die Testl"aufe und f"ur den Release.

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
         PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER=
              '/var/www/htdocs/eisfair/release'




\config{PKGDEV\_ADVANCED\_SETTINGS}{PKGDEV\_ADVANCED\_SETTINGS}{PKGDEVADVANCEDSETTINGS}
    Hier k"onnen die erweiterten Settings aktiviert werden.

     G"ultige Werte: yes, no

     Standard-Einstellung: PKGDEV\_ADVANCED\_SETTINGS='no'




\config{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEVDEVELOPMENTPACKAGEBASEFOLDERPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die
    Paket-Subfolder unterhalb von
    'PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER' versehen.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_PERMISSION='2775'




\config{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEVTESTTEAMPACKAGEBASEFOLDERPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die
    Paket-Subfolder unterhalb von
    'PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER' versehen.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_PERMISSION='2775'




\config{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEVRELEASEPACKAGEBASEFOLDERPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die
    Paket-Subfolder unterhalb von
    'PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER' versehen.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_PERMISSION='2775'




\config{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEVDEVELOPMENTPACKAGEBASEFILEPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die Dateien
    versehen, welche unterhalb von
    'PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER' erzeugt werden. Das sind
    die jeweiligen Eislists, der Index sowie die Package-Files selbst.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FILE\_PERMISSION='664'




\config{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEVTESTTEAMPACKAGEBASEFILEPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die Dateien
    versehen, welche unterhalb von
    'PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER' erzeugt werden. Das sind
    die jeweiligen Eislists, der Index sowie die Package-Files selbst.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FILE\_PERMISSION='664'




\config{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEVRELEASEPACKAGEBASEFILEPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die Dateien
    versehen, welche unterhalb von
    'PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER' erzeugt werden. Das sind die
    jeweiligen Eislists, der Index sowie die Package-Files selbst.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_RELEASE\_PACKAGE\_BASE\_FILE\_PERMISSION='664'




\config{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEVDEVELOPMENTPACKAGEBASEFOLDERUSER}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER' werden dem hier
    angegebenen User zugeordnet.

    G"ultige Werte: g"ultiger User

    Standard-Einstellung:
        PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_USER='wwwrun'




\config{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEVTESTTEAMPACKAGEBASEFOLDERUSER}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER' werden dem hier
    angegebenen User zugeordnet.

    G"ultige Werte: g"ultiger User

    Standard-Einstellung:
        PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_USER='wwwrun'




\config{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEVRELEASEPACKAGEBASEFOLDERUSER}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER' werden dem hier
    angegebenen User zugeordnet.

    G"ultige Werte: g"ultiger User

    Standard-Einstellung:
        PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_USER='wwwrun'




\config{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEVDEVELOPMENTPACKAGEBASEFOLDERGROUP}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER' werden der hier
    angegebenen Gruppe zugeordnet.

    G"ultige Werte: g"ultige Gruppe

    Standard-Einstellung:
        PKGDEV\_DEVELOPMENT\_PACKAGE\_BASE\_FOLDER='nogroup'




\config{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEVTESTTEAMPACKAGEBASEFOLDERGROUP}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER' werden der hier
    angegebenen Gruppe zugeordnet.

    G"ultige Werte: g"ultige Gruppe

    Standard-Einstellung:
        PKGDEV\_TESTTEAM\_PACKAGE\_BASE\_FOLDER\_GROUP='nogroup'




\config{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEVRELEASEPACKAGEBASEFOLDERGROUP}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER' werden der hier
    angegebenen Gruppe zugeordnet.

    G"ultige Werte: g"ultige Gruppe

    Standard-Einstellung:
        PKGDEV\_RELEASE\_PACKAGE\_BASE\_FOLDER\_GROUP='nogroup'




\config{PKGDEV\_FOLDER\_NAME\_TRUNK}{PKGDEV\_FOLDER\_NAME\_TRUNK}{PKGDEVFOLDERNAMETRUNK}
    Hier wird der Name des Ordners angegeben, welcher sp"ater den Trunk
    aus dem Repository enthalten soll. Damit k"onnen also die Hauptordner
    aus verschiedenen Repo's innerhalb PKGDEV\_WORKING\_COPY\_PATH
    verwendet werden, wenn hier entsprechend unterschiedliche Eintr"age
    vorgenommen werden.

    G"ultige Werte: g"ultiger Ordnername

    Standard-Einstellung:
        PKGDEV\_FOLDER\_NAME\_TRUNK='trunk'




\config{PKGDEV\_FOLDER\_NAME\_BRANCHES}{PKGDEV\_FOLDER\_NAME\_BRANCHES}{PKGDEVFOLDERNAMEBRANCHES}
    Hier wird der Name des Ordners angegeben, welcher sp"ater die
    Branches aus dem Repository enthalten soll. Damit k"onnen also die
    Hauptordner aus verschiedenen Repo's innerhalb
    PKGDEV\_WORKING\_COPY\_PATH verwendet werden, wenn hier entsprechend
    unterschiedliche Eintr"age vorgenommen werden.

    G"ultige Werte: g"ultiger Ordnername

    Standard-Einstellung:
        PKGDEV\_FOLDER\_NAME\_TRUNK='branches'




\config{PKGDEV\_FOLDER\_NAME\_TAGS}{PKGDEV\_FOLDER\_NAME\_TAGS}{PKGDEVFOLDERNAMETAGS}
    Hier wird der Name des Ordners angegeben, welcher sp"ater die Tags
    aus dem Repository enthalten soll. Damit k"onnen also die Hauptordner
    aus verschiedenen Repo's innerhalb PKGDEV\_WORKING\_COPY\_PATH
    verwendet werden, wenn hier entsprechend unterschiedliche Eintr"age
    vorgenommen werden.

    G"ultige Werte: g"ultiger Ordnername

    Standard-Einstellung:
        PKGDEV\_FOLDER\_NAME\_TRUNK='tags'




\config{PKGDEV\_ARCHPROG}{PKGDEV\_ARCHPROG}{PKGDEVARCHPROG}
    Hier wird konfiguriert, welcher Packer zum Komprimieren der Pakete
    verwendet werden soll.

    G"ultige Werte: 'gzip', 'bzip2'

    Standard-Einstellung: PKGDEV\_ARCHPROG='gzip'




\config{PKGDEV\_SECTION\_FILE}{PKGDEV\_SECTION\_FILE}{PKGDEVSECTIONFILE}
    Hier wird die Datei angegeben, in welcher die bekannten Sectionen des
    eisfair Repositories aufgelistet sind. Die Datei wird im Ordner
    'trunk/\_ADMIN' im Repository gesucht und enth"alt Zeilenweise
    jeweils eine Section, Zeilen welche mit '\#' beginnen werden
    ignoriert:
    \begin{itemize}
      \item admin
      \item base
      \item contrib
      \item db
      \item ...
    \end{itemize}

    G"ultige Werte: String

    Standard-Einstellung: PKGDEV\_SECTION\_FILE='sections-new.txt'




\config{PKGDEV\_FOLDER\_LIST\_FILE}{PKGDEV\_FOLDER\_LIST\_FILE}{PKGDEVFOLDERLISTFILE}
    Im Folder-List-File werden alle bekannten Pakete verzeichnet. Diese
    Datei kennt somit alle Pakete dieses Repositories. Ausserdem wird
    hier die Zugeh"origkeit des Paketes zur entsprechenden Section
    festgehalten. Zeilen welche mit '\#' beginnen werden ignoriert. Es
    steht jeweils die Section eines Paketes gefolgt von ':' und dem
    Paketnamen in einer Zeile. Der Name einer Section kann zur besseren
    Unterscheidung nach dem ':' mit einem '\#' eingeleitet werden:
    \begin{itemize}
      \item ...
      \item drivers:\#---------------DRIVERS--------------------
      \item drivers:avm\_b1\_2.4.26-1
      \item drivers:avm\_b1\_2.6.16.29-xen
      \item drivers:avm\_b1\_2.6.16.33-xen
      \item ...
    \end{itemize}

    Die Datei wird wie auch das Section-File im Ordner 'trunk/\_ADMIN' im
    Repository gesucht.

    G"ultige Werte: yes, no

    Standard-Einstellung:
         PKGDEV\_FOLDER\_LIST\_FILE='folder-list-new.txt'




\config{PKGDEV\_INDEX\_SOURCE}{PKGDEV\_INDEX\_SOURCE}{PKGDEVINDEXSOURCE}
    Mit dieser Angabe wird eingestellt, woher die zu verwendende index.txt
    geholt werden soll. Falls das Default-Ziel nicht erreichbar ist, kann hier
    eine andere Quelle angegeben werden. Dabei ist auch ein Eintrag mit file://
    m"oglich.

    G"ultige Werte: http://<pfad> oder file://<pfad>

    Standard-Einstellung: PKGDEV\_INDEX\_SOURCE=https://www.pack-eis.de/index.txt




\config{PKGDEV\_COMMAND\_HISTORY}{PKGDEV\_COMMAND\_HISTORY}{PKGDEVCOMMANDHISTORY}
    Diese Einstellung gibt an, wieviele mit 'admin-packages-new.sh'
    abgesetzte Kommandos in der 'Command history' vorgehalten werden
    sollen. Damit steht die hier eingestellte Anzahl der generierten
    Kommandos der Men"upunkte 4 und 5 von 'admin-packages-new.sh' f"ur
    die erneute Verwendung zur Verf"ugung.

    G"ultige Werte: Ziffer

    Standard-Einstellung: PKGDEV\_COMMAND\_HISTORY=5




\config{PKGDEV\_DEBUG\_OUTPUT}{PKGDEV\_DEBUG\_OUTPUT}{PKGDEVDEBUGOUTPUT}
    Wird dieses Settings aktiviert, so wird w"ahrend dem Ablauf der
    Scripte zur Paketerstellung etc. wesentlich mehr Output produziert.

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_DEBUG\_OUTPUT='no'



\config{PKGDEV\_SETUP\_NIGHTLY\_BUILDS}{PKGDEV\_SETUP\_NIGHTLY\_BUILDS}{PKGDEVSETUPNIGHTLYBUILDS}
    Sollen die Pakete automatisch durch einen Cron-Job gebaut werden, so
    k"onnen im Folgenden die notwendigen Einstellungen vorgenommen
    werden.  Es wird ein Mail-Paket ben"otigt, wenn die Nightly-Builds
    aktiviert werden!

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_SETUP\_NIGHTLY\_BUILDS='no'



\config{PKGDEV\_NIGHTLY\_SCHEDULE}{PKGDEV\_NIGHTLY\_SCHEDULE}{PKGDEVNIGHTLYSCHEDULE}
    Hier wird nach "ublicher Cron-Syntax konfiguriert, wann der Cron-Job
    f"ur die Nightly-Builds ausgef"uhrt werden soll.

\begin{verbatim}
    Allowed values and meaning
    --------------------------
    0-59 .. minute
    0-23 .. hour
    1-31 .. day of month
    1-12 .. month (or names)
    0-7  .. day of week (0 or 7 is Sun, or use names)
\end{verbatim}

    G"ultige Werte: * * * * *

    Standard-Einstellung: PKGDEV\_NIGHTLY\_SCHEDULE='2 3 * * *'



\config{PKGDEV\_NIGHTLY\_MAIL\_TO}{PKGDEV\_NIGHTLY\_MAIL\_TO}{PKGDEVNIGHTLYMAILTO}
    Mailadresse, an welche der Build-Report bzw. im Fehlerfall der
    Fehler-Report geschickt werden soll.

    G"ultige Werte: G"ultige Email-Adresse

    Standard-Einstellung: PKGDEV\_NIGHTLY\_MAIL\_TO='root@localhost'



\config{PKGDEV\_NIGHTLY\_WORKING\_COPY\_PATH}{PKGDEV\_NIGHTLY\_WORKING\_COPY\_PATH}{PKGDEVNIGHTLYWORKINGCOPYPATH}
    Hier wird der Pfad zum Verzeichnis angegeben, in welchem die
    Working-Copy des Repositories abgelegt werden soll. In diesem
    Verzeichnis entstehen daraufhin die Ordner welche unter
    'PKGDEV\_FOLDER\_NAME\_TRUNK', 'PKGDEV\_FOLDER\_NAME\_BRANCHES' und
    'PKGDEV\_FOLDER\_NAME\_TAGS' angegeben werden (siehe dazu die
    erweiterten Einstellungen).

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_WORKING\_COPY\_PATH='/data/development/eisfair'



\config{PKGDEV\_NIGHTLY\_WORKING\_COPY\_USER}{PKGDEV\_NIGHTLY\_WORKING\_COPY\_USER}{PKGDEVNIGHTLYWORKINGCOPYUSER}
    Hier wird der User angegeben, welchem der Ordner
    'PKGDEV\_NIGHTLY\_WORKING\_COPY\_PATH' nebst Inhalt geh"oren soll.

    G"ultige Werte: g"ultiger Username

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_WORKING\_COPY\_USER='root'



\config{PKGDEV\_NIGHTLY\_WORKING\_COPY\_GROUP}{PKGDEV\_NIGHTLY\_WORKING\_COPY\_GROUP}{PKGDEVNIGHTLYWORKINGCOPYGROUP}
    Hier wird die Gruppe angegeben, welcher der Ordner
    'PKGDEV\_NIGHTLY\_WORKING\_COPY\_PATH' nebst Inhalt geh"oren soll.

    G"ultige Werte: vorhandene Gruppe

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_WORKING\_COPY\_GROUP='root'



\config{PKGDEV\_NIGHTLY\_WORKING\_COPY\_DO\_UPDATE}{PKGDEV\_NIGHTLY\_WORKING\_COPY\_DO\_UPDATE}{PKGDEVNIGHTLYWORKINGCOPYDOUPDATE}
    Hier kann eingestellt werden, ob die Working-Copy der Nightly-Builds
    vor dem eigentlichen Build-Loop aktualisiert werden soll. Diese
    Einstellung sollte insbesondere dann aktiviert werden, wenn die
    Working-Copy der Nightly-Builds nicht die gleiche ist, welche f"ur
    die  Entwicklung verwendet wird.

    Achtung: Bei Verwendung von Subversion 1.5.x sollte f"ur die
    Nightly-Builds eine separate Working-Copy verwendet werden, damit ein
    vollst"andiges Update durchgef"uhrt werden kann. Anderenfalls kann es
    zu Schwierigkeiten kommen, da ab Subversion 1.5.x Sparse-Checkouts
    m"oglich sind.

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_NIGHTLY\_WORKING\_COPY\_DO\_UPDATE='yes'



\config{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER}{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER}{PKGDEVNIGHTLYPACKAGEBASEFOLDER}
    Hier wird angegeben, wo die erzeugten Pakete abgelegt werden sollen. In
    diesem Folder werden die Pakete dann in aufsteigend nummerierte
    Verzeichnisse kopiert und eine entsprechende Eislist sowie Index-Datei
    generiert.

    G"ultige Werte: g"ultiger absoluter Pfad

    Standard-Einstellung:
      PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER='/var/www/htdocs/eisfair/development'



\config{PKGDEV\_NIGHTLY\_FOLDER\_NAME\_TRUNK}{PKGDEV\_NIGHTLY\_FOLDER\_NAME\_TRUNK}{PKGDEVNIGHTLYFOLDERNAMETRUNK}
    Hier wird der Name des Ordners angegeben, welcher den Trunk aus
    dem Repository enth"alt.

    G"ultige Werte: g"ultiger Ordnername

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_FOLDER\_NAME\_TRUNK='trunk'



\config{PKGDEV\_NIGHTLY\_BUILD\_BUGFIXES}{PKGDEV\_NIGHTLY\_BUILD\_BUGFIXES}{PKGDEVNIGHTLYBUILDBUGFIXES}
    Hier wird konfiguriert, ob beim Nightly-Build auch die
    Bugfix-Versionen erzeugt werden sollen.

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_NIGHTLY\_BUILD\_BUGFIXES='no'



\config{PKGDEV\_NIGHTLY\_FOLDER\_NAME\_BRANCHES}{PKGDEV\_NIGHTLY\_FOLDER\_NAME\_BRANCHES}{PKGDEVNIGHTLYFOLDERNAMEBRANCHES}
    Hier wird der Name des Ordners angegeben, welcher die Branches aus
    dem Repository enth"alt.

    G"ultige Werte: g"ultiger Ordnername

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_FOLDER\_NAME\_BRANCHES='branches'



\config{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_PERMISSION}{PKGDEVNIGHTLYPACKAGEBASEFOLDERPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die
    Paket-Subfolder unterhalb von
    'PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER' versehen.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_PERMISSION=775



\config{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FILE\_PERMISSION}{PKGDEVNIGHTLYPACKAGEBASEFILEPERMISSION}
    Mit den hier angegebenen Schreib-/Leserechten werden die Dateien
    versehen, welche unterhalb von
    'PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER' erzeugt werden. Das sind die
    jeweiligen Eislists, der Index sowie die Package-Files selbst.

    G"ultige Werte: oktaler Zahlenwert, siehe Parameter f"ur Befehl 'chmod'

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FILE\_PERMISSION=664



\config{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_USER}{PKGDEVNIGHTLYPACKAGEBASEFOLDERUSER}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER' werden dem hier
    angegebenen User zugeordnet.

    G"ultige Werte: g"ultiger User

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_USER='wwwrun'



\config{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_GROUP}{PKGDEVNIGHTLYPACKAGEBASEFOLDERGROUP}
    Die Paket-Subfolder unterhalb von
    'PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER' werden der hier
    angegebenen Gruppe zugeordnet.

    G"ultige Werte: g"ultige Gruppe

    Standard-Einstellung:
        PKGDEV\_NIGHTLY\_PACKAGE\_BASE\_FOLDER\_GROUP='nogroup'



\config{PKGDEV\_NIGHTLY\_ARCHPROG}{PKGDEV\_NIGHTLY\_ARCHPROG}{PKGDEVNIGHTLYARCHPROG}
    Hier wird konfiguriert, welcher Packer zum Komprimieren der Pakete
    verwendet werden soll.

    G"ultige Werte: 'gzip', 'bzip2'

    Standard-Einstellung: PKGDEV\_NIGHTLY\_ARCHPROG='gzip'



\config{PKGDEV\_NIGHTLY\_SECTION\_FILE}{PKGDEV\_NIGHTLY\_SECTION\_FILE}{PKGDEVNIGHTLYSECTIONFILE}
    Hier wird die Datei angegeben, in welcher die bekannten Sektionen des
    eisfair Repositories aufgelistet sind. Die Datei wird im Ordner
    'trunk/\_ADMIN/' im Repository gesucht und enth"alt Zeilenweise
    jeweils eine Section, Zeilen welche mit '\#' beginnen werden
    ignoriert:
    \begin{itemize}
      \item admin
      \item base
      \item contrib
      \item db
      \item ...
    \end{itemize}

    G"ultige Werte: String

    Standard-Einstellung: PKGDEV\_NIGHTLY\_SECTION\_FILE='sections-new.txt'



\config{PKGDEV\_NIGHTLY\_FOLDER\_LIST\_FILE}{PKGDEV\_NIGHTLY\_FOLDER\_LIST\_FILE}{PKGDEVNIGHTLYFOLDERLISTFILE}
    Im Folder-List-File werden alle bekannten Pakete verzeichnet. Diese
    Datei kennt somit alle Pakete dieses Repositories. Ausserdem wird
    hier die Zugeh"origkeit des Paketes zur entsprechenden Section
    festgehalten. Zeilen welche mit '\#' beginnen werden ignoriert. Es
    steht jeweils die Section eines Paketes gefolgt von ':' und dem
    Paketnamen in einer Zeile. Der Name einer Section kann zur besseren
    Unterscheidung nach dem ':' mit einem '\#' eingeleitet werden:
    \begin{itemize}
      \item ...
      \item drivers:\#---------------DRIVERS--------------------
      \item drivers:avm\_b1\_2.4.26-1
      \item drivers:avm\_b1\_2.6.16.29-xen
      \item drivers:avm\_b1\_2.6.16.33-xen
      \item ...
    \end{itemize}

    Die Datei wird wie auch das Section-File im Ordner 'trunk/\_ADMIN/'
    im Repository gesucht.

    G"ultige Werte: yes, no

    Standard-Einstellung:
         PKGDEV\_NIGHTLY\_FOLDER\_LIST\_FILE='folder-list-new.txt'



\config{PKGDEV\_NIGHTLY\_DEBUG\_OUTPUT}{PKGDEV\_NIGHTLY\_DEBUG\_OUTPUT}{PKGDEVNIGHTLYDEBUGOUTPUT}
    Wird dieses Settings aktiviert, so wird w"ahrend dem Ablauf der
    Scripte zur Paketerstellung etc. wesentlich mehr Output produziert.

    G"ultige Werte: yes, no

    Standard-Einstellung: PKGDEV\_NIGHTLY\_DEBUG\_OUTPUT='no'


\end{description}


\section{Verweise}
[1] http://svnbook.red-bean.com/
