4. Die Paket-Info-Datei

4.1. Hintergrund der Paket-Info-Datei

Diese Datei soll eine bessere Übersicht über die verfügbaren Pakete und notwendige Verwaltungsdaten bereitstellen.

Sie wird auch dazu verwendet, um das Paket in einer index.txt aufzulisten.

4.2. Namen und Pfad

Die Info-Datei wird mit jedem Paket zweimal ausgeliefert: Sie ist erstens im Paket enthalten und liegt im Verzeichnis /var/install/packages/ mit dem Paketnamen als Name und wird zusätzlich parallel zum eigentlichen Paket ausgeliefert. Dabei erhält sie die Dateiendung .info.

Beispiel:

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

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

4.3. Format

Die Info-Datei hat eine XML-Struktur, die folgendermaßen aussieht:

<package>
...
</package>

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 Groß- und Kleinschreibung achten!). Freitexte dürfen folgende Zeichen nicht enthalten: „<“, „>“, „$“.

Jedes Tag (bis auf <description> ) muss mit Start-Tag, Wert und End- Tag in genau einer Zeile stehen.

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

Tag	Bedeutung
<name>	Der Name des Paketes.
<short>	Eine Kurzbeschreibung (max 60 Zeichen). Dieses Tag sollte nicht nochmals den Namen des Paketes enthalten.
<version>	Die Version des Paketes (siehe <version>-Tag).
<date>	Das Releasedatum dieser Version.
<system>	Für welches System dieses Paket zugelassen ist.
<author>	Der Name des Autors inklusive Email-Adresse.
<status>	Der Status des Paketes (siehe <status>-Tag).
<section>	Der Bereich, dem dieses Paket angehört (siehe <section>-Tag).
<sha256sum>	Checksumme zur automatischen Prüfung der Integrität eines Pakets. 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.
<space>	(optional) Gesamter zur Installation benötigter Plattenplatz Hinweis: Dieses Tag kann im PackageInfoFile innerhalb des Archives nicht enthalten sein, da zum Zeitpunkt der Erstellung des Archives die Größe noch nicht bekannt ist. Das Tag ist somit nur in der externen *.info-Datei vorhanden.
<require-package>	(optional) Weiteres Paket, welches zum Betrieb unbedingt benötigt wird. (siehe <require-package>-Tag)
<linked-package>	(optional) Verweist auf ein Paket welches bei einem update mit aktualisiert werden muss, wenn es installiert ist. <linked-package>-Tag)
<replaces>	(optional) Verweist auf ein Paket, welches durch dieses Paket ersetzt wird. (siehe <replaces>-Tag)
<sub-package>	(optional) Ist ein Paket inkrementell aufgebaut, werden hier alle weiteren Teilpakete angegeben. (siehe <sub-package>-Tag)
<description>	Eine ausführlichere Beschreibung des Programms, Hinweise, Tipps, Patches …

Die Reihenfolge der Tags ist beliebig. Die Tag-Namen müssen in Kleinbuchstaben gesetzt sein. Es folgen weitere Beschreibungen der Tags.

4.3.1. <name>-Tag

Das <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. <name>apache2</name> und <name>apache</name>.

4.3.2. <version>-Tag

Wie in der OpenSource-Welt üblich, werden auch die eisfair-Pakete mit dreiteiligen Versionsnummern nach folgendem Schema versehen: X.Y.Z , Diese drei Teile haben jeweils eine konkrete Bedeutung.

• X - Major

  Der erste Block gibt ein sog. Major-Release an. Das heißt, das ist eine Art Hauptversion des Paketes. Diese Nummer ändert 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.

• Y - Minor

  Der zweite Block gibt ein Minor-Release an. Das heißt, 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 1.2.5 zu 1.3.0 machen.

• Z - Bugfix bzw. Patchlevel

  Wenn in einem Paket Fehler beseitigt werden, so schlägt sich das auf die letzte Ziffer der Versionsbezeichnung nieder, also auf Z. Das ist die Nummer des Bugfix- Release. Um beim vorigen Beispiel zu bleiben: Es wird für ein Paket in der Version 1.2.5 ein Fehler gemeldet und behoben. Somit hat das neue Paket die Version 1.2.6.

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öglicht es zudem, die korrekte Versionsnummernvergabe vollständig zu automatisieren.

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

Hinweis

Üblicherweise ist es so, dass bei Developerversionen (Testing- Versionen) der Minor (Y) ungerade und bei den stabilen Versionen gerade ist.

4.3.3. <date>-Tag

Das Release-Datum des Pakets im Format: „YYYY-MM-DD“ , (nach ISO 8601)

YYYY	4-stellige Jahreszahl
MM	2-stelliger Monat
DD	2-stelliger Tag

4.3.4. <status>-Tag

Ein eisfair-Paket kennt drei verschiedene Status, welche sich aus folgender Überlegung ergeben: Ein völlig 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 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 stable und ein Paket mit ungeradem Minor als 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äre demgegenüber 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ässt. Es ergibt sich bspw. folgender Ablauf:

• Release 1.0.0 <- Stable

• Bugfix 1.0.1 <- ebenfalls Stable

• Bugfix 1.0.2 <- nochmal Stable

• Vorabversion 1.1.0 <- Testing

• Bugfix 1.0.3 <- wieder Stable

• Vorabversion 1.1.1 <- Testing

• Release 1.2.0 <- Stable

• Bugfix 1.2.1 <- Bugfix der neuesten Stable-Version

• Bugfix 1.0.4 <- Bugfix einer älteren Version

Wie dieses Beispiel zeigt, werden hier problemlos drei verschiedene Versionen gepflegt: Das aktuelle Stable (1.2.0) durch Bugfixes (1.2.1), ein älteres 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ächsten ungeraden Nummer nach dem Release weiterlaufen. Das wären hier die Versionen 1.3.0, 1.3.1 usw. Bzgl. der Version eines Paketes und dem damit einher gehenden Status sollen folgende Grundsätze zur Anwendung kommen:

• 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ünf Benutzer das Paket installiert haben und alle gemeldeten Fehler vom Autor beseitigt wurden.

• 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 besaß.

4.3.5. <section>-Tag

Dieser Wert ordnet das Paket in eine bestimmte Kategorie ein. Darüber lässt sich eine Menüauswahl o.ä. realisieren. Es existieren folgende Möglichkeiten für diesen Wert:

• backup

  In dieser Sektion sollen Pakete platziert werden, welche sich mit dem Sichern und Wiederherstellen von Daten beschäftigen.

• base

  Diese Sektion enthält Basisbestandteile des eisfair-Systems und wird hauptsächlich vom Team direkt betreut.

• chat

  Hier können Pakete platziert werden, welche sich mit den verschiedensten Formen des Chats beschäftigen. Beispiele hierfür sind IRC, Jabber oder auch TeamSpeak.

• communication

  Die Sektion ‚communication‘ enthält Pakete, welche sich unter dem Stichwort Bürokommunikation oder Office communication zusammenfassen lassen. Das sind bspw. die Pakete asterisk , eisfax oder vbox.

• contrib

  
  

• database

  Hier werden alle Pakete zu Datenbanken abgelegt. Das betrifft sowohl die jeweilige Datenbank direkt, als auch die Tools dafür. Zwei Beispiele sind hier die Pakete mysql sowie phpmyadmin .

• devel

  Unter dieser Sektion werden all die Pakete geführt, welche sich mit der Entwicklung beschäftigen. Das sind also all die Pakete, welche für die Entwicklung von weiteren eisfair-Paketen benötigt werden, also gcc & Co.

• drivers

  In dieser Sektion werden Treiber-Pakete abgelegt, wie sie für spezielle Hardware benötigt werden. Dies sind bspw. Pakete mit Treibern für die AVM-ISDN-Karten oder RAID-Controller.

• game

  In der Sektion ‚game‘ sollen Pakete platziert werden, welche Serverdienste bzw. Spiele-Proxies für (Online-)Spiele bieten.

• kernel

  Diese Sektion enthält Basisbestandteile des eisfair-Systems und wird hauptsächlich vom Team direkt betreut.

• lib

  Diese Sektion beinhaltet die Bibliotheks-Pakete. Diese Pakete müssen immer mit der Zeichenfolge lib beginnen.

• libdev

  In dieser Sektion werden die Dev-Pakete zur jeweiligen Bibliothek aufgeführt.

• mail

  Hier werden alle Pakete in Zusammenhang mit Emails platziert. Beispiele dafür sind natürlich das mail Paket, sowie antispam oder auch archimap.

• misc

  In der Sektion misc können Pakete platziert werden, welche eine Funktionalität bieten, welche sich nicht einer der anderen Sektion zuordnen lässt. Beispiele sind hier die Pakete lcd oder motion.

• multimedia

  Die Sektion multimedia dient der Aufnahme von Paketen welche sich mit jeglicher Form von Video- und/oder Audiodaten beschäftigen. Dazu zählen bspw. die Pakete vdr, mpg123 oder cdrecord.

• 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.

• netutils

  Im Gegensatz zur vorherigen Sektion werden hier die Pakete geführt, welche den Admin bei seiner Arbeit unterstützen sollen. Also finden sich hier verschiedene Utilities wie bspw. addhost oder auch phpldapadmin .

• news

  In dieser Sektion werden Pakete abgelegt, welche sich mit dem News-System beschäftigen, also Newsreader.

• perl

  In dieser Sektion werden die Perl Pakete abgelegt.

• plang

  Die Sektion plang beinhaltet Pakete zur Entwicklung bzw. Programmierung in den verschiedensten Programmiersprachen. Dies sind bspw. die Pakete für Java, lua, tcl.

• printer-file

  In dieser Sektion werden die Pakete für Druck- und Dateidienste abgelegt. Dies sind bspw. die Pakete für NFS-Freigaben sowie Samba oder auch verschiedene Konverter wie html2ps oder a2ps.

• python2

  In dieser Sektion werden die Pakete abgelegt, die Module für die Python Version 2.x mitbringen.

• python3

  In dieser Sektion werden die Pakete abgelegt, die Module für die Python Version 3.x mitbringen.

• security

  Pakete dieser Sektion beschäftigen sich mit der Sicherheit des Servers bzw. nicht nur des Servers. Dazu zählen bspw. die Pakete certs oder clamav.

• system

  Hier werden Pakete für den allgemeinen Betrieb des Servers vorgehalten. Dazu zählen bspw. Pakete wie quota oder smartmon.

• utils

  In der Sektion utils werden Tools und Werkzeuge untergebracht, welche für die ganz normale Benutzung oder auch Administration des Servers benötigt werden. Beispiele sind die Pakete zip , sasl oder chroot.

• web

  Hier werden die Pakete für den Webzugriff auf den Server vorgehalten. Dies sind die Basispakete wie bspw. apache2 sowie darauf aufbauend bspw. apache2_webalizer oder trac.

4.3.6. <sha256sum>-Tag

Mit der Bildung einer Prüfsumme über das Archiv und mit dem Eintrag dieser sha256sum kann die fehlerfreie Übertragung vor der Installation geprüft werden.

Ermittlung der Checksumme:

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

<sha256sum>be77c6ae535380aa4144a9950b2fbb40662dade9904351efaea2d8114dbd9b01</sha256sum>

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

4.3.7. <space>-Tag

Mit dem Eintrag des gesamten zur Installation benötigten Plattenplatzes kann geprüft werden, ob dieser zur Verfügung steht. Der benötigte Plattenplatz berechnet sich aus der Archivgröße zuzüglich der Größe der Einzeldateien. Die Angabe erfolgt in ganzen Megabyte.

Beispiel (benötigt werden 13 Megabyte):

<space>13</space>

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

4.3.8. <system>-Tag

Dieses Tag legt fest, für welches System das Paket entwickelt wurde, zum Beispiel für das System ‚eisfair-1‘. Im Moment sind die Tags

eisfair-1
eisfair-64
eisfair-noarch
eisxen-1

zugelassen.

<system>eisfair-1</system>

4.3.9. <require-package>-Tag

Dieser Wert definiert eine Abhängigkeit zwischen dem beschriebenen Paket und einem oder mehreren anderen Paket(en).

Ein Paket wird über den Paketnamen referenziert. Sollte eine bestimmte Mindestversion gefordert werden, so kann diese bei allen Varianten optional durch ein Leerzeichen getrennt hinter dem Dateinamen bzw. Paketnamen angegeben werden.

Damit ein referenziertes Paket aufgefunden werden kann, muss es in der index-Datei aufgelistet werden. Wird das Paket über pack-eis bereitgestellt, dann erfolgt diese Auflistung automatisch.

Ist das beschriebene Paket von mehreren Paketen abhängig, so kann das <require-package>-Tag mehrfach vorkommen. Gibt es keine Abhängigkeiten, so kann es entfallen.

Falls es mehrere Alternativen für eine einzelen Paketabhängigkeit gibt, können mehrere Pakete mit und ohne Versionsangabe, durch den ‚|‘ Operator getrennt, angegeben werden (siehe Beispiel 3). Ein Beispiel dafür wäre beispielsweise die Anforderung an ein Mail-Paket, die durch mehrere mögliche Alternativen erfüllt werden kann.

Der Paketmanager verhält sich in dieser Situation wie folgt:

1. Falls keines der angegebenen Pakete bereits installiert ist, wird das erste Paket der Liste als Paketabhängigkeit verwendet. Die Alternativen finden dagegen keine Berücksichtigung.

2. Falls eines der angegebenen Pakete bereits installiert ist, wird dieses im Bedarfsfall aktualisiert. Nicht installierte Pakete werden dagegen bei der Installation nicht angefordert.

3. Falls mehrere (oder alle) der angegebenen Pakete installiert sind, werden alle bereits installierten Pakete der Liste im Bedarfsfall aktualisiert.

Die (immer vorhandene) Abhängigkeit zum Paket base muss nicht explizit genannt werden, es sei denn, eine bestimmte Version wird zwingend vorausgesetzt.

Beispiele:

<require-package>foo 1.0.5</require-package>
<require-package>bar</require-package>
<require-package>bar 1.8.7 | foo 1.5.6 | foba 1.2.3</require-package>

4.3.10. <linked-package>-Tag

Der Wert beschreibt Pakete die optional installiert sein köennen und bei dem update des Pakets mit aktualisiert werden sollen.

Beispiele:

<linked-package>libdb-dev 2.8.0</linked-package>

4.3.11. <replaces>-Tag

Der Wert beschreibt ein Paket, daß durch dieses ersetzt wird.

Beispiele:

<replaces>libdb</replaces>

4.3.12. <sub-package>-Tag

Das Tag <sub-package> gibt an, welche Unterpakete vom Hauptpaket selbständig geladen werden. Diese Angaben dienen lediglich der Information, z.B. für eisfair-Download-Mirror-Systeme.

Syntax:

<sub-package>LOCATION EXTRA_DATA</sub-package>

Die Form von LOCATION entspricht derselben wie für <require-package>.

Als EXTRA_DATA können zusätzliche Informationen übermittelt werden. Beispielsweise wird beim base-Update der benötigte Platz auf der Festplatte in MB angegeben. Dieser Wert ist Paketspezifisch und optional.

4.4. Update eines Pakets

Wenn ein Paket aktualisiert wird, sind folgende Punkte zu beachten:

• Updaten des <version>-Tags

• Eventuell Rückstufung des <status>-Tags

Beispiel:

Anbei ein kleines Beispiel, welches obige Definitionen illustrieren soll.

<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>
<sha256sum>be77c6ae535380aa4144a9950b2fbb40662dade9904351efaea2d8114dbd9b01</sha256sum>
<space>13</space>
<require-package>libdb 1.0.0</require-package>
<require-package>libgdbm 1.0.0</require-package>
<require-package>libssl 1.0.0</require-package>
<require-package>base 1.0.5</require-package>
<require-package>perl 1.0.0</require-package>
<description>
Mail Services

Reminder:
By default the included program components are licensed
under GPLv2 or later, except for the following components:

alterMIME  - Copyright (c) 2000-2019 P.L.Daniels, All rights reserved.
Panda-IMAP - Licensed under the Apache v2.0 license.

EXIM           Version: 4.90.1     ALTERMIME Version: 0.3.10
PANDA-IMAPD    Version: 2010.417   FETCHMAIL Version: 6.3.26
PANDA-IPOP3D   Version: 2010.104   VACATION  Version: 1.2.7.1
PANDA-MAILUTIL Version: 2010

</description>
</package>