Private Paketzentrale

Die Präambel

Ein Specfile besteht aus drei Teilen. Im ersten Abschnitt, der Präambel, stehen allgemeine Informationen, aus denen z. B. später der Name des Pakets gebildet wird. Für xpuyopuyo könnte die Präambel aussehen wie in Listing 1.

#Specfile fuer xpuyopuyo
Summary: netzwerkfaehiges Tetris-artiges Spiel
Name: xpuyopuyo
Version: 0.9.7
Release: apocalypse
Copyright: GPL
Group: Games/Arcade
Source: xpuyopuyo-0.9.7.tar.gz
URL: http://chaos2.org/
Distribution: Mandrake 9.0
Packager: Andrea Mueller <amueller@linux-user.de>

Ihr Aufbau ist denkbar einfach und bei jedem Paket gleich, so dass man hier mit Vorlagen arbeiten kann. Einem RPM-spezifischen Tag folgt ein Doppelpunkt und dahinter der zugehörige Wert. Aus den Werten hinter Name, Version und Release setzt sich später der Paketname zusammen. Das Version-Tag darf nur Zahlen und Punkte enthalten, ansonsten bricht RPM die Paketerstellung ab.

Im Release-Tag steht bei den Distributoren normalerweise, um die wievielte Paket-Version es sich handelt. Oft bauen Distributoren mehrere Pakete zu ein und derselben Programmversion, etwa weil es Patches dafür gibt oder weil der Distributor nachträglich andere Verbesserungen einbaut. Dieses Feld sollte auch zum Einfügen einer distributionsspezifischen Kennung genutzt werden, was jedoch nur Mandrake konsequent umsetzt. Bei Paketen dieses Distributors finden Sie immer die Buchstabenfolge mdk im Namen. Sie selbst können dorthin schreiben, was Sie mögen: Für das Beispiel muss der Rechnername herhalten. Achten Sie jedoch darauf, dass Sie bestimmte Zeichen wie z. B. das Minus nicht verwenden dürfen. Im Feld Summary ist Platz für die Kurzbeschreibung, das Source-Tag nimmt den Namen des Quellcode-Archivs auf, und das Feld URL enthält Service-Informationen für den Benutzer Ihres Pakets. Er weiß sofort, woher die Software im RPM stammt. Die Distribution-Zeile ist optional, Sie können sie also weglassen. Hinter dem Schlagwort Packager sollte jedoch Ihr Name oder Spitzname und eine gültige E-Mail-Adresse stehen, zumindest dann, wenn Sie das selbstgebaute Paket auch an andere weitergeben. Ein Fehler bei der Paketherstellung ist schnell gemacht, und dann freut sich der Benutzer, wenn er einen Ansprechpartner hat.

Einen kurzen Blick sollte man dem Punkt Group gönnen. Hier legen Sie fest, unter welcher Rubrik grafische Paketverwaltungsprogramme wie z. B. kpackage die Software später einordnen. Theoretisch kann man sich eigene Gruppen ausdenken, will man jedoch Pakete weitergeben, hält man sich besser an die gängigen Konventionen. Die möglichen Gruppennamen stehen in der Datei GROUPS der RPM-Dokumentation unterhalb von /usr/share/doc.

Der Bauplan

Im Hauptabschnitt des Specfiles stehen die Anweisungen zum Entpacken, Konfigurieren und Installieren der Software. Das Vorgehen kann sich von Anwendung zu Anwendung unterscheiden, besteht jedoch meistens aus dem altbekannten Dreisatz

configure
make
make install

Das ist so in etwa auch bei xpuyopuyo der Fall. Hängen Sie also die Zeilen aus Listing 2 an Ihre Spec-Datei an.

%description
Netzwerkfähiges tetris-artiges Spiel mit coolem Sound.
%prep
%setup
./configure --prefix=/usr/local --with-gnome=no
%build
make
%install
make install-strip
cp doc/xpuyopuyo.txt /usr/local/share/xpuyopuyo

Einem Prozentzeichen folgen hier RPM-spezifische Schlagworte. Der Punkt %description nimmt den Text auf, der sich Ihnen später präsentiert, wenn Sie mit dem Befehl rpm -qi xpuyopuyo Informationen zum Paket abfragen. Er darf sich über mehrere Zeilen erstrecken und alle Zeichen enthalten. Der Abschnitt %prep beendet die Beschreibung und leitet die Vorbereitung des Build-Prozesses ein. In dieser Phase wird alles erledigt, was nötig ist, um das Quellpaket in einen kompilierfähigen Zustand zu versetzen.

Der Punkt %setup macht Sie mit einer Arbeitserleichterung bekannt, die RPM dem Paketbauer bietet: dem Einsatz von Makros. So wie Sie in einem Office-Programm Makros aufzeichnen können, um immer wiederkehrende Aufgaben zu erledigen, kennt auch RPM solche praktischen Helfer. Das wohl am meisten genutzte ist das Setup-Makro, was gleich mehrere Aufgaben abarbeitet. Es entpackt das im Verzeichnis SOURCES liegende Archiv nach BUILD und wechselt danach mit dem cd-Befehl dorthin. Handelt es sich nicht um den ersten Versuch, das Paket zu bauen, löscht das Setup-Makro vor dem Entpacken der Quellen die Rückstände, die von einem vorherigen Compiler-Lauf in BUILD zurückgeblieben sind.

In der nächsten Zeile der %prep-Sektion beginnt der eigentliche Bau. Den Befehl ./configure würden Sie von Hand aufrufen, wenn Sie das Programm zum Kompilieren vorbereiten wollten. Dessen --prefix-Parameter dient in diesem Fall nur als Beispiel, da das Skript dieses Verzeichnis standardmäßig als Ziel für das Programm auswählt. Sie schreiben hier die configure-Optionen hin, mit denen Sie das Verhalten des Konfigurationsskripts in der Shell modifizieren würden. Sie sollten das Paket wie andere selbstkompilierte Software nach /usr/local installieren. Dadurch haben Sie immer noch eine gewisse Trennung zwischen selbstkompilierter Software und Distributionspaketen. Auch ein Update ist damit kein Problem, sofern Ihr Distributor seine Pakete ordentlich pflegt. Die xpuyopuyo-typische configure-Option --with-gnome=no bewirkt, dass keine Icons für den GNOME-Desktop erstellt und in die Verzeichnisse unterhalb von /usr/share kopiert werden.

In der nun folgenden Sektion %build kompiliert RPM die Software. Bei xpuyopuyo erledigt das wie bei den meisten anderen Paketen der Befehl make. Der nächste Punkt ist dann logischerweise %install, wo das Kommando make install- aufgerufen wird, um die kompilierte Software nach /usr/local zu installieren.

Damit ist der Hauptteil des Specfiles komplett, obwohl es noch weitere Sektionen gibt, die man dort einfügen könnte, so z. B. das %patch-Makro, das die Anwendung von Patches ("Flicken") automatisiert, die Fehler bereinigen oder der Software zusätzliche Funktionalität verleihen. Mit der %package-Anweisung teilt man Software in mehrere Pakete auf, etwa in programm.rpm, programm-doc.rpm und programm-devel.rpm. Falls Sie einmal ein Paket bauen, das eine Bibliothek enthält, sollten Sie Ihrem Specfile auf jeden Fall die beiden Zeilen

%post
ldconfig

hinzufügen. Das ruft nach der Installation des Pakets den Befehl ldconfig auf. Er registriert die neu eingespielte Bibliothek, so dass Sie auch von anderen Programmen gefunden wird.

Grundsätzlich können Sie in den Unterabschnitten des Hauptteils einer Spec-Datei jeden Befehl aufrufen. In den Abschnitten, die jedoch später bei der Installation des Pakets ausgeführt werden (ein Beispiel dafür ist die %post-Sektion), sollten Sie nur solche Kommandos verwenden, von denen Sie sicher wissen, dass Sie auf jedem Linux-System vorhanden sind.