
\chapter{Die Paket-Info-Datei}

\marklabel{infofile}{\section{Hintergrund der Paket-Info-Datei}}

   Diese Datei soll eine bessere "Ubersicht "uber die verf"ugbaren Pakete
   und notwendige Verwaltungsdaten bereitstellen.

   Sie wird auch dazu verwendet, um das Paket in einer eis-list.txt aufzulisten.

\section{Namen und Pfad}

   Die Info-Datei wird mit jedem Paket zweimal ausgeliefert: Sie ist
   erstens im Paket enthalten und liegt im Verzeichnis
   \texttt{/var/install/packages/} mit dem Paketnamen als Name und wird
   zus"atzlich parallel zum eigentlichen Paket ausgeliefert. Dabei erh"alt
   sie die Dateiendung \texttt{.info}.

\sloppy

   Beispiel:\\
   Wenn der Pfad zum Paket \texttt{mail.tar.gz} bspw. \texttt{http://www.meine-domain.de/eisfair/}
   lautet (also die URL das Paketes \texttt{http://www.domain.de/eisfair/mail.tar.gz}
   ist), dann heisst die zugeh"orige Info-Datei \texttt{mail.tar.gz.info}; deren URL
   lautet somit \texttt{http://www.domain.de/eisfair/mail.tar.gz.info}.

   Die Datei ist zudem als \texttt{/var/install/packages/mail}
   im tar-Archiv enthalten.

\section{Format}

   Die Info-Datei hat eine XML-Struktur, die folgendermassen aussieht:

   \begin{verbatim}
<package>
...
</package>
   \end{verbatim}

   Innerhalb des Paket-Tags sind die unten beschriebenen Tags erlaubt. Die Werte sind,
   soweit nicht anders gekennzeichnet, Freitext. Werte, die nicht
   Freitext sind, sind case-sensitiv (auf Gross- und Kleinschreibung
   achten!). Freitexte d"urfen folgende Zeichen nicht enthalten: "`<"',
   "`>"',"`\$"'.

   Jedes Tag (bis auf \tag{description}) muss mit Start-Tag, Wert und End-Tag
   in genau einer Zeile stehen.

   Im folgenden werden alle Tags einer Infodatei kurz erl"autert. Bis auf
   die mit (optional) gekennzeichneten Ausnahmen, darf keines dieser Tags
   leer bleiben oder fehlen!


%\tablehead{\hline Tag & Bedeutung \\ \hline}
%\begin{supertabular}{|l|p{10cm}|}
\begin{tabularx}{\textwidth}[t]{|X|p{10cm}|}
     \firsthline
     Tag & Bedeutung \\
     \hline
     \tag{name}              & Der Name des Paketes. \\
     \tag{short}             & Eine Kurzbeschreibung (max 60 Zeichen). Dieses Tag
                               sollte nicht nochmals den Namen des Paketes enthalten. \\
     \tag{version}           & Die Version des Paketes (siehe \jump{versiontag}{version-Tag}). \\
     \tag{date}              & Das Releasedatum dieser Version.  \\
     \tag{system}            & F"ur welches System dieses Paket zugelassen ist. Dieses Tag kann
                               mehrmals vorhanden sein, wenn das Paket auf mehreren Zielsystemen
                               installiert werden kann. \\
     \tag{author}            & Der Name des Autors inklusive Email-Adresse. \\
     \tag{status}            & Der Status des Paketes (siehe \jump{statustag}{status-Tag}). \\
     \tag{section}           & Der Bereich, dem dieses Paket angeh"ort (siehe \jump{sectiontag}{section-Tag}). \\
     \tag{sha1sum}           & (optional) Checksumme zur automatischen Pr"ufung der Integrit"at eines Pakets
                               (ab base 1.4.0). Hinweis: Dieses Tag kann im PackageInfoFile innerhalb des
                               Archives nicht enthalten sein, da zum Zeitpunkt der Erstellung des Archives
                               die Checksumme noch nicht bekannt ist. Das Tag ist somit nur in der externen
                               *.info-Datei vorhanden. \\
     \tag{space}             & (optional) Gesamter zur Installation ben"otigter Plattenplatz
                               (ab base 1.4.0). Hinweis: Dieses Tag kann im PackageInfoFile innerhalb des
                               Archives nicht enthalten sein, da zum Zeitpunkt der Erstellung des Archives
                               die Gr"osse noch nicht bekannt ist. Das Tag ist somit nur in der externen
                               *.info-Datei vorhanden. \\
     \tag{require-package}   & (optional) Weiteres Paket, welches zum Betrieb unbedingt
                               ben"otigt wird. (siehe \jump{requirepackagetag}{require-package-tag}) \\
     \tag{require-lib}       & (optional) Verweist auf ein Library-Paket (siehe
                               \jump{requirelibtag}{require-lib-tag}) \\
     \tag{sub-package}       & (optional) Ist ein Paket inkrementell aufgebaut,
                               werden hier alle weiteren Teilpakete angegeben. (siehe
                               \jump{subpackagetag}{sub-package-tag}) \\
     \tag{description}       & Eine ausf"uhrlichere Beschreibung des Programmes, Hinweise, Tipps, Patches \ldots \\
     \lasthline
%\end{supertabular}
\end{tabularx}
\\\\
   Die Reihenfolge der Tags ist beliebig. Die Tag-Namen m"ussen in
   Kleinbuchstaben gesetzt sein. Es folgen weitere Beschreibungen der Tags.

\marklabel{nametag}{\subsection{<name>-Tag}}

   Das \tag{name}-Tag darf nur die Zeichen a-z, 0-9, "`-"' und "`\_"' enthalten,
   wobei eine Angabe der Versionsnummer des in dem Paket enthaltenen Programms
   vermieden werden sollte. Es gibt allerdings Ausnahmen, wie z.B. \tag{name}apache2\tag{/name}
   und \tag{name}apache\tag{/name}.

\marklabel{versiontag}{\subsection{<version>-Tag}}

   Wie in der OpenSource-Welt "ublich, werden auch die eisfair-Pakete mit
   dreiteiligen Versionsnummern nach folgendem Schema versehen:
   \texttt{X.Y.Z},

   Diese drei Teile haben jeweils eine konkrete Bedeutung.

   \begin{description}
   \item[X - Major] Der erste Block gibt ein sog. \emph{Major-Release} an.
   Das heisst, das ist eine Art Hauptversion des Paketes. Diese Nummer "andert
   sich i. d. R. nur dann, wenn das Paket komplett neu aufgebaut wurde oder
   die internen Komponenten ebenfalls einen Sprung der Major-Version gemacht
   haben.

   \item[Y - Minor] Der zweite Block gibt ein \emph{Minor-Release} an.
   Das heisst, jede Weiterentwicklung eines Paketes in Verbindung mit neuen
   Features, wird an dieser Stelle einen Versionsschritt machen. Wenn also
   bei einem Paket ein neues Feature eingebaut wird, dann wird dieses bspw.
   einen Versionsschritt von \emph{1.2.5} zu \emph{1.3.0} machen.

   \item[Z - Bugfix bzw. Patchlevel] Wenn in einem Paket Fehler beseitigt
   werden, so schl"agt sich das auf die letzte Ziffer der Versionsbezeichnung
   nieder, also auf \emph{Z}. Das ist die Nummer des \emph{Bugfix-Release}.
   Um beim vorigen Beispiel zu bleiben: Es wird f"ur ein Paket in der Version
   1.2.5 ein Fehler gemeldet und behoben. Somit hat das neue Paket die Version
   1.2.6.
   \end{description}

   So entwickelt sich die Versionsnummer weiter. Nach einem weiteren Bugfix
   wird es die Version 1.2.7 und nach dem Einbau eines neuen Features wie
   bspw. einer neuen Konfigurationsvariablen wird es die 1.3.0. Die Verwendung
   dieses Versionierungsschemas erm"oglicht es zudem, die korrekte
   Versionsnummernvergabe vollst"andig zu automatisieren.

   Die Variablen haben den Wertebereich von 0-99 und die Version 0.0.0 ist
   verboten.

   \hinweis{"Ublicherweise ist es so, dass bei Developerversionen
   (Testing-Versionen) der Minor (Y) ungerade und bei den stabilen Versionen
   gerade ist. Dieses Vorgehen wird vom Paket packagedevelopment konsequent
   umgesetzt.}

\marklabel{datetag}{\subsection{<date>-Tag}}

   Das Release-Datum des Pakets im Format: \texttt{YYYY-MM-DD}, (nach ISO 8601)

   \begin{tabular}{ll}
   YYYY & 4-stellige Jahreszahl\\
   MM   & 2-stelliger Monat\\
   DD   & 2-stelliger Tag\\
   \end{tabular}

\marklabel{statustag}{\subsection{<status>-Tag}}

   Ein eisfair-Paket kennt drei verschiedene Status, welche sich aus folgender
   "Uberlegung ergeben: Ein v"ollig neues Paket beginnt sein Leben mit einer
   Versionsnummer 0.x.x, also kleiner als Major-Version 1.0.0. Alle Pakete mit
   einer solchen Version werden per Konvention als \emph{unstable}
   gekennzeichnet. Ein solches Paket wurde noch nicht getestet und die
   Installation ist nur Experten zu empfehlen, da dieses Paket noch erhebliche
   Fehler und Ungereimtheiten enthalten kann.

   Hat das Paket einen gewissen Reifegrad erlangt, dann wird es die Version
   1.0.0 erreichen. Ab hier gilt das bereits beim Version-Tag angesprochene
   Vorgehen, dass ein Paket mit geradem Minor als \emph{stable} und ein Paket
   mit ungeradem Minor als \emph{testing} gekennzeichnet wird.

   So ist die Version 1.0.0 eine Stable-Version und die Versionen 1.0.x sind
   die Bugfixes dieses Stable-Release. Die Version 1.1.0 w"are demgegen"uber
   jedoch eine Testing-Version. Die gesamte Frage nach dem Status eines Pakets
   wird damit wesentlich vereinfacht, da sich dieser unmittelbar aus der
   Versionsnummer herleiten l"aesst. Es ergibt sich bspw. folgender Ablauf:

   \begin{itemize}
     \item Release 1.0.0        <-- Stable
     \item Bugfix 1.0.1         <-- ebenfalls Stable
     \item Bugfix 1.0.2         <-- nochmal Stable
     \item Vorabversion 1.1.0   <-- Testing
     \item Bugfix 1.0.3         <-- wieder Stable
     \item Vorabversion 1.1.1   <-- Testing
     \item Release 1.2.0        <-- Stable
     \item Bugfix 1.2.1         <-- Bugfix der neuesten Stable-Version
     \item Bugfix 1.0.4         <-- Bugfix einer "alteren Version
   \end{itemize}

   Wie dieses Beispiel zeigt, werden hier problemlos drei verschiedene
   Versionen gepflegt: Das aktuelle Stable (1.2.0) durch Bugfixes (1.2.1),
   ein "alteres Stable (1.0.0) durch Bugfixes (1.0.1 bis 1.0.4) sowie die
   Entwicklerversion 1.1.0 bis 1.1.2. Da das Release 1.2.0 aus der Testing
   1.1.1 hervorgegangen ist, muss jedoch sichergestellt werden, dass die nun
   kommenden Testing-Versionen bei der n"achsten ungeraden Nummer nach dem
   Release weiterlaufen. Das w"aren hier die Versionen 1.3.0, 1.3.1 usw.

   Bzgl. der Version eines Paketes und dem damit einher gehenden Status sollen
   folgende Grunds"atze zur Anwendung kommen:

   \begin{description}
   \item[testing] Dieses Paket wurde schon getestet und alle bekannten Fehler
   wurden beseitigt. Wenn ein Paket diesen Status erreicht hat, sollte es einen
   Feature-Freeze erhalten, d. h. es werden keine neuen Features mehr eingebaut,
   sondern nur noch Bugfixes vorgenommen. Ein Paket soll diesen Status erst
   dann erhalten, wenn mindestens f"unf Benutzer das Paket installiert
   haben und alle gemeldeten Fehler vom Autor beseitigt wurden.

   \item[stable] Dieses Paket ist ausreichend getestet und arbeitet auch in
   vielen Kombinationen mit anderen Programmen und Treibern wie erwartet.
   Eine Dokumentation ist vorhanden. Ein Paket soll bzw. kann diesen Status
   erst dann erhalten, wenn es vorher den Status "`unstable"' bzw. "`testing"'
   besass.
   \end{description}

   \hinweis{Das Paket "`packagedevelopment"' erzeugt bis einschliesslich
            Paketversion 0.5.5 Pakete mit Versionen 0.x.x mit dem Status
            \emph{testing}. Es gibt bereits einen
            \link{http://bugs.eisfair.org/view.php?id=203}{Feature-Request}
            im \link{http://bugs.eisfair.org}{eisfair Bugtracker} um hier das
            korrekte Verhalten zu implementieren.}

\marklabel{sectiontag}{\subsection{<section>-Tag}}

   Dieser Wert ordnet das Paket in eine bestimmte Kategorie ein.
   Dar"uber l"asst sich eine Men"uauswahl o."a. realisieren. Es existieren
   folgende M"oglichkeiten f"ur diesen Wert:
   \begin{itemize}
     \item backup - In dieser Sektion sollen Pakete platziert werden, welche sich
                    mit dem Sichern und Wiederherstellen von Daten besch"aftigen.
     \item base - Diese Sektion enth"alt Basisbestandteile des eisfair-Systems und
                  wird haupts"achlich vom Team direkt betreut.
     \item 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.
     \item communication - Die Sektion 'communication' enth"alt Pakete, welche sich
                           unter dem Stichwort \texttt{B"urokommunikation} oder \texttt{Office
                           communication} zusammenfassen lassen. Das sind bspw. die
                           Pakete \texttt{asterisk}, \texttt{eisfax} oder \texttt{vbox}.
     \item contrib
     \item database - Hier werden alle Pakete zu Datenbanken abgelegt. Das betrifft
                      sowohl die jeweilige Datenbank direkt, als auch die Tools daf"ur.
                      Zwei Beispiele sind hier die Pakete \texttt{mysql} sowie \texttt{phpmyadmin}.
     \item 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,
                   also gcc \& Co.
     \item drivers - In dieser Sektion werden Treiber-Pakete abgelegt, wie sie f"ur spezielle
                     Hardware ben"otigt werden. Dies sind bspw. Pakete mit Treibern f"ur die
                     AVM-ISDN-Karten oder RAID-Controller.
     \item game - In der Sektion 'game' sollen Pakete platziert werden, welche Serverdienste
                  bzw. Spiele-Proxies f"ur (Online-)Spiele bieten.
     \item kernel - Diese Sektion enth"alt Basisbestandteile des eisfair-Systems und wird
                    haupts"achlich vom Team direkt betreut.
     \item lib - Diese Sektion beinhaltet die Bibliotheks-Pakete. Diese Pakete m"ussen immer
                 mit der Zeichenfolge \texttt{lib} beginnen, was jedoch von packagedevelopment beim
                 Anlegen eines solchen Paketes ggf. automatisch erg"anzt wird.
     \item libdev - In dieser Sektion werden die Dev-Pakete zur jeweiligen Bibliothek aufgef"uhrt.
     \item mail - Hier werden alle Pakete in Zusammenhang mit Emails platziert. Beispiele daf"ur
                  sind nat"urlich das \texttt{mail} Paket, sowie \texttt{antispam} oder auch \texttt{archimap}.
     \item misc - In der Sektion \texttt{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 \texttt{lcd} oder \texttt{motion}.
     \item multimedia - Die Sektion \texttt{multimedia} dient der Aufnahme von Paketen welche sich mit
                        jeglicher Form von Video- und/oder Audiodaten besch"aftigen. Dazu z"ahlen
                        bspw. die Pakete \texttt{vdr}, \texttt{mpg123} oder \texttt{cdrecord}.
     \item 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 \texttt{bonding}, \texttt{dns} oder \texttt{inet} bieten.
     \item 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. \texttt{addhost} oder auch \texttt{phpldapadmin}.
     \item news - In dieser Sektion werden Pakete abgelegt, welche sich mit dem News-System
                  besch"aftigen, also Newsreader.
     \item plang - Die Sektion \texttt{plang} beinhaltet Pakete zur Entwicklung bzw. Programmierung
                   in den verschiedensten Programmiersprachen. Dies sind bspw. die Pakete f"ur
                   Java, Python oder Perl.
     \item 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 \texttt{html2ps} oder \texttt{a2ps}.
     \item security - Pakete dieser Sektion besch"aftigen sich mit der Sicherheit des Servers bzw.
                      nicht nur des Servers. Dazu z"ahlen bspw. die Pakete \texttt{certs} oder \texttt{clamav}.
     \item system - Hier werden Pakete f"ur den allgemeinen Betrieb des Servers vorgehalten. Dazu
                    z"ahlen bspw. Pakete wie \texttt{quota} oder \texttt{smartmon}.
     \item utils - In der Sektion \texttt{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 \texttt{zip}, \texttt{sasl} oder \texttt{chroot}.
     \item web - Hier werden die Pakete f"ur den Webzugriff auf den Server vorgehalten. Dies
                 sind die Basispakete wie bspw. \texttt{apache2} sowie darauf aufbauend bspw.
                 \texttt{apache2\_webalizer} oder \texttt{trac}.
   \end{itemize}


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 - admin-tools zum Installieren und Konfigurieren
     \item dns-dhcp
     \item etc
     \item inet-mail-news
     \item interpreter - perl, ruby, python und co.
     \item net - alles rund ums Netzwerk
   \end{itemize}

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



\marklabel{sha1sumtag}{\subsection{<sha1sum>-Tag}}

    Mit der Bildung einer Pr"ufsumme "uber das Archiv und mit dem Eintrag dieser
    sha1sum kann die fehlerfreie "Ubertragung vor der Installation gepr"uft werden.

    \begin{example}
    Ermittlung der Checksumme:
    \begin{verbatim}

    sha1sum -b test.tar.gz | cut -d' ' -f1

    \end{verbatim}
    \end{example}

    Dieses Tag kann nur im separaten Info-File gesetzt werden, da zum Zeitpunkt
    der Berechnung der Pr"ufsumme das Archiv des Paketes bereits fertig ist.

\marklabel{spacetag}{\subsection{<space>-Tag}}

    Mit dem Eintrag des gesamten zur Installation ben"otigten
    Plattenplatzes kann gepr"uft werden, ob dieser zur Verf"ugung steht.

    Der ben"otigte Plattenplatz berechnet sich aus der Archivgr"osse
    zuz"uglich der Gr"osse der Einzeldateien.

    Die Angabe erfolgt in ganzen Megabyte.

    \begin{example}
    Beispiel (ben"otigt werden 13 Megabyte):
    \begin{verbatim}

    <space>13</space>

    \end{verbatim}
    \end{example}

    Dieses Tag kann nur im separaten Info-File gesetzt werden, da zum Zeitpunkt
    der Berechnung der Gesamtgr"osse das Archiv des Paketes bereits fertig ist.

\marklabel{systemtag}{\subsection{<system>-Tag}}

    Dieses Tag legt fest, f"ur welches System das Paket entwickelt wurde,
    zum Beispiel f"ur das System 'eisfair-1'.

    Im Moment sind die Tags

    \begin{verbatim}
    eisfair-1
    eisfair-2
    eisxen-1
    \end{verbatim}

    zugelassen.

    \begin{example}
    \begin{verbatim}

    <system>eisfair-1</system>

    \end{verbatim}
    \end{example}

    Dieses Tag darf auch mehrfach in einer Paket-Info-Datei vorkommen.

    \begin{example}
    \begin{verbatim}

    <system>eisfair-1</system>
    <system>eisfair-2</system>

    \end{verbatim}
    \end{example}

\marklabel{requirepackagetag}{\subsection{<require-package>-Tag}}

   Dieser Wert definiert eine Abh"angigkeit zwischen dem beschriebenen
   Paket und einem anderen Paket.

   Das notwendige Paket kann dabei auf mehrere Arten referenziert
   werden. Die einfachste Variante ist der direkte Verweis auf die jeweilige
   Paket-Info-Datei. Das kann entweder durch die Angabe des
   relativen Pfades (Beispiele 1 und 2) oder durch die Angabe der
   absoluten URL (Beispiel 3) geschehen.

   Alternativ kann ein Paket auch "uber den Paketnamen referenziert
   werden (Beispiele 4 und 5). Damit diese Variante verwendet werden kann,
   muss "uber die \jump{eislist}{eis-list.txt} eine \jump{indextxt}{index-Datei}
   bereitgestellt werden, in der das ben"otigte Paket enthalten ist.

   Sollte eine bestimmte Mindestversion gefordert werden, so kann diese bei
   allen Varianten optional durch ein Leerzeichen getrennt hinter dem
   Dateinamen bzw. Paketnamen angegeben werden.

   Ist das beschriebene Paket von mehreren Paketen abh"angig, so kann
   das \tag{require-package}-Tag mehrfach vorkommen. Gibt es keine
   Abh"angigkeiten, so kann es entfallen.

   Die (immer vorhandene) Abh"angigkeit zum Paket base muss nicht explizit genannt werden, es
   sein denn, eine bestimmte Version wird vorausgesetzt.

   Beispiele:
   \footnotesize
   \begin{verbatim}
<require-package>bar.tar.gz.info 1.3.1</require-package>
<require-package>../packages/foo.tar.gz.info 1.0.5</require-package>
<require-package>http://www.domain.de/foo.tar.gz.info 1.0.5</require-package>
<require-package>foo 1.0.5</require-package>
<require-package>bar</require-package>
   \end{verbatim}
   \normalsize


\marklabel{requirelibtag}{\subsection{<require-lib>-Tag}}
   Da Bibliotheken aus Paketen nicht nur von einer bestimmten Anwendung ben"otigt
   werden, erfolgt ihre Auslieferung in separaten Paketen. Diese werden so
   vor der Installation des eigentlichen Paketes auf den Rechner geladen.\\

   Beispiele:
   \footnotesize
   \begin{verbatim}
<require-lib>libdb4 1.0.0</require-lib>
<require-lib>http://www.domain.de/libldap2.tar.gz.info 1.0.0</require-lib>
   \end{verbatim}
   \normalsize

\marklabel{subpackagetag}{\subsection{<sub-package>-Tag}}

Das Tag \tag{sub-package} gibt an, welche Unterpakete vom Hauptpaket
selbst"andig geladen werden. Diese Angaben dienen lediglich der
Information, z.B. f"ur \eisfair\--Download-Mirror-Systeme.

Syntax:

  \tag{sub-package}LOCATION EXTRA\_DATA\tag{/sub-package}

  Die Form von LOCATION entspricht derselben wie f"ur \tag{require-package}.

  Als EXTRA\_DATA k"onnen zus"atzliche Informationen "ubermittelt werden.
  Beispielsweise wird beim base-Update der ben"otigte Platz auf der
  Festplatte in MB angegeben. Dieser Wert ist paketspezifisch und optional.


\section{Update eines Pakets}

   Wenn ein Paket aktualisiert wird, sind folgende Punkte zu beachten:
   \begin{itemize}
     \item Updaten des \tag{version}-tags
     \item Eventuell R"uckstufung des \tag{status}-Tags
   \end{itemize}

   Wird f"ur die Paketentwicklungs ''packagedevelopment'' verwendet,
   werden diese Punkte automatisch korrekt behandelt.

\section{Beispiel}

   Anbei ein kleines Beispiel, welches obige Definitionen illustrieren soll.

\footnotesize
\begin{verbatim}
<package>
<name>mail</name>
<short>Mail services</short>
<version>1.2.7</version>
<date>2004-06-25</date>
<system>eisfair-1</system>
<author>Juergen Edner, fli4l-eisfair(at)telejeck(dot)de</author>
<status>testing</status>
<section>mail</section>
<sha1sum>559df80365121fb576761f145011e2ebbcfc71cb</sha1sum>
<space>13</space>
<require-lib>libdb4 1.0.0</require-lib>
<require-lib>libgdbm 1.0.0</require-lib>
<require-lib>libssl 1.0.0</require-lib>
<require-package>base 1.0.5</require-package>
<require-package>inet 1.0.0</require-package>
<require-package>perl 1.0.0</require-package>
<description>
Mail Services

EXIM      Version: 4.34            EXISCAN   Version: 4.34-22
FETCHMAIL Version: 6.2.5           IPOP3D    Version: 2003.83
IMAPD     Version: 2003.338        VACATION  Version: 1.2.6.1

Attention: This package requires as minimum an installed update-1.0.5
           package!
Attention: Be careful, only mail usernames in lowercase are allowed in
           this package!

</description>
</package>
\end{verbatim}
\normalsize
