Nächste Seite: Installation, Bootprozess, Shutdown Aufwärts: eisfair Entwickler-Dokumentation Vorherige Seite: Überblick über ein eisfair Inhalt Index
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 eis-list.txt aufzulisten.
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.
Die Info-Datei hat eine XML-Struktur, die folgendermassen 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 Gross- 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. Dieses Tag kann mehrmals vorhanden sein, wenn das Paket auf mehreren Zielsystemen installiert werden kann. |
| <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). |
| <sha1sum> | (optional) Checksumme zur automatischen Prüfung der Integrität 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. |
| <space> | (optional) Gesamter zur Installation benötigter 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össe 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) |
| <require-lib> | (optional) Verweist auf ein Library-Paket (siehe require-lib-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 Programmes, Hinweise, Tipps, Patches ... |
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>.
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.
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. Dieses Vorgehen wird vom Paket packagedevelopment konsequent
umgesetzt.
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 |
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äesst. Es ergibt sich bspw. folgender Ablauf:
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:
Hinweis
Das Paket ,,packagedevelopment`` erzeugt bis einschliesslich
Paketversion 0.5.5 Pakete mit Versionen 0.x.x mit dem Status
testing. Es gibt bereits einen
Feature-Request
im eisfair Bugtracker
um hier das
korrekte Verhalten zu implementieren.
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:
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:
Die Pakete dieser Sektionen sollen zum jeweils nächsten Release nach Möglichkeit in der nun gültigen Sektion erscheinen.
Mit der Bildung einer Prüfsumme über das Archiv und mit dem Eintrag dieser sha1sum kann die fehlerfreie Übertragung vor der Installation geprüft werden.
Ermittlung der Checksumme:
sha1sum -b test.tar.gz | cut -d' ' -f1
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.
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össe zuzüglich der Grösse 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össe das Archiv des Paketes bereits fertig ist.
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-2
eisxen-1
zugelassen.
<system>eisfair-1</system>
Dieses Tag darf auch mehrfach in einer Paket-Info-Datei vorkommen.
<system>eisfair-1</system>
<system>eisfair-2</system>
Dieser Wert definiert eine Abhängigkeit 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 über den Paketnamen referenziert werden (Beispiele 4 und 5). Damit diese Variante verwendet werden kann, muss über die eis-list.txt eine index-Datei bereitgestellt werden, in der das benötigte 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ängig, so kann das <require-package>-Tag mehrfach vorkommen. Gibt es keine Abhängigkeiten, so kann es entfallen.
Die (immer vorhandene) Abhängigkeit zum Paket base muss nicht explizit genannt werden, es sein denn, eine bestimmte Version wird vorausgesetzt.
Beispiele:
<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>
Beispiele:
<require-lib>libdb4-3 1.0.0</require-lib> <require-lib>http://www.domain.de/libldap2-2.tar.gz.info 1.0.0</require-lib>
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.
Wenn ein Paket aktualisiert wird, sind folgende Punkte zu beachten:
Wird für die Paketentwicklungs ''packagedevelopment'' verwendet, werden diese Punkte automatisch korrekt behandelt.
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>
<sha1sum>559df80365121fb576761f145011e2ebbcfc71cb</sha1sum>
<space>13</space>
<require-lib>libdb4-3 1.0.0</require-lib>
<require-lib>libgdbm1-8 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>