Mit nur wenigen Handgriffen bauen Sie aus einem Quelltextarchiv ein fertiges RPM-Paket. So verschwinden Dateien beim Deinstallieren wieder sauber aus dem System.

Der Paketmanager RPM bildet das Rückgrat vieler aktueller Distributionen. Dank seiner Hilfe installieren Sie in Windeseile neue Software-Pakete und fegen nicht mehr benötigte Anwendungen komfortabel von der Festplatte. Ein Blick auf den Herstellungsprozess derartiger Pakete lohnt insbesondere, wenn Sie für eine neue Software kein passendes Paket finden.

Sofern kein fertiges Paket für die eigene Distribution bereit steht, bleibt nur noch der Griff zum so genannten Quellcode. Dieser besteht aus dem lesbaren Programmtext, den Sie zunächst in ein ausführbares Binary umgewandeln. Der Vorgang nennt sich kompilieren und wie er im einzelnen abläuft, ist von Programm zu Programm verschieden.

Liegt das Ergebnis vor, spielen Sie das fertige Programm ins System ein – und damit normalerweise am Paketmanager vorbei. Eine automatisierte Deinstallation funktioniert in dem Fall nur unter zwei Bedingungen: Zum einen brauchen Sie das unveränderte Makefile, und zum anderen muss der Programmierer eine entsprechende Funktion eingeplant haben. Aber selbst dann bleibt immer noch fraglich, diese auch wirklich alle Dateien von der Platte putzt.

Abbildung 1: Die Web-Seite zum RPM-Format und dem gleichnamigen Paketmanager ist die erste Anlaufstelle für technische Fragen.

Rote Hüte

Diese mühselige Kleinarbeit verbirgt ein RPM-Paket. Es enthält das fertige Programm und schreibt bei der Installation alle wichtigen Informationen in eine Datenbank. Somit weiß das System, welche Dateien zur Anwendung gehören, wenn Sie diese deinstallieren.

Die meisten größeren Distributionen verwenden das RPM-Format: So etwa Suse Linux, Mandriva, Fedora Core und nicht zuletzt Red Hat. Die Firma mit dem roten Hut war gleichzeitig der Namensgeber für den Red Hat Package Manager, kurz RPM. Mitunter findet sich im Internet auch das rekursive Akronym RPM Package Manager.

Liegt ein Programm erst einmal als RPM-Paket vor, spielen Sie es bequem über den Paketmanager ein und entsorgen es nach Gebrauch auch gleich wieder fachmännisch. Ganz nebenbei erschlägt die Software so noch alle ungelösten Abhängigkeiten – also die Installation weiterer Programme, die eine Software voraussetzt.

Am Arbeitsplatz

Alles, was Sie zum Erstellen eines RPM-Paketes benötigen, bringt Ihre Distribution bereits von Haus aus mit. Neben dem eigenlichen Paketmanager namens RPM ist dies noch eventuell das Paket rpm-build. Letzteres enthält einige zusätzliche Hilfsprogramme, die bei einigen Distributionen jedoch schon standardmäßig auf der Festplatte schlummern, so wie beispielsweise bei Suse Linux.

Im Folgenden dient das Spiel Bomberclone als Beispiel. Es realisiert das alte und auf vielen Parties erprobte Bomberman-Spielprinzip. Sie finden seinen Quellcode im Internet [2] als Tar-Archiv. Sobald die Datei auf der Festplatte liegt, melden Sie sich als Benutzer root an. Für alle weiteren Schritte benötigt Sie seine weitreichenden Rechte.

Als erstes wandert das soeben herunter geladene Archiv in ein spezielles Arbeitsverzeichnis. Linux ist hierauf vorbereitet und sieht als Packstation einen speziellen Ordner unter /usr/src vor. Wie dieses Arbeitsverzeichnis genau heißt, hängt von ihrer Distribution ab. Suse Linux nennt es packages, Mandriva rpm und unter Red Hat heißt es einfach redhat.

In jedem Fall finden Sie dort fünf weitere Unterverzeichnisse namens BUILD, RPMS, SOURCES, SPECS und SRPMS. Zunächst ist nur der Ordner SOURCES von Interesse. Dort hinein schieben Sie das Archiv mit dem Bomberman-Klon. Wollen Sie eigene Software in eine RPM-Datei packen, achten Sie darauf, dass diese ebenfalls als mit Gzip gepacktes Tar-Archiv vorliegt. Andernfalls hilft hier nur das Umwandeln mit einem passenden Komprimierungsprogramm.

Wechseln Sie in das Verzeichnis SPECS. Hier erstellen Sie jetzt die Textdatei bomberclone.spec. Prinzipiell dürfen Sie ihr einen beliebigen Dateinamen geben. Die hier gewählte Form aus Programmname und dem Suffix .spec hat sich aber mittlerweile als Standard durchgesetzt.

Die neue Textdatei füllen Sie nun mit Anweisungen, die beschreiben, wie das RPM-Paket zu erstellen ist. Da diese Textdatei somit den gesamten Packprozess steuert, heißt die Datei auch Konfigurations- oder Steuerdatei. Die englischsprachige Dokumentation spricht von einem Spec-File.

Abbildung 2: Die Homepage von BomberClone.

Abbildung 3: Das über RPM installierte BomberClone.

Vorbereitungen

Zunächst liefern Sie RPM ein paar Informationen über das zu erstellende Paket. Dies geschieht stets am Anfang eines Spec-Files. Listing 1 zeigt diesen Informationsblock für das Bomberclone-Beispiel.

#Specfile fuer BomberClone
Summary: Bomberman-Klon
Name: bomberclone
Version: 0.11.6.2
Release: meinrelease
Copyright: GPL
Group: Games/Action
Source: bomberclone-0.11.6.2.tar.gz
URL: http://www.bomberclone.de
Distribution: Suse Linux 10.0
Packager: Tim Schuermann <tschuermann@linux-user.de>

Alle Zeilen, die mit einer Raute beginnen, ignoriert RPM. Sie übernehmen somit eine Kommentarfunktion. Die restlichen Zeilen starten mit dem Namen einer Eigenschaft, dem so genannten Tag, gefolgt von einem Doppelpunkt und dem Wert der Eigenschaft.

Summary liefert zunächst eine Kurzbeschreibung des Paketinhalts. Die folgenden Punkte Name, Version und Release bilden ein besonderes Trio: Sie erscheinen nicht nur in den Paketinformationen, aus ihnen bastelt RPM auch den Dateinamen des Pakets. Im Bomberclone-Beispiel heißt die fertige Datei somit bomberclone-0.11.6.2-meinrelease.rpm. Aus diesem Grund darf die Versionsnummer nur aus Zahlen und Punkten bestehen.

Der Wert unter Release hilft, verschiedene Pakete mit gleichem Inhalt zu unterschieden. So könnten Sie hier zum Beispiel angeben, für welche Linux-Distribution das Paket bestimmt ist. Da dieser Text im späteren Dateinamen erscheint, darf auch hier das Minuszeichen nicht vorkommen.

Um bei vielen installieren Paketen die Übersicht zu behalten, steckt der RPM-Paketmanager jede Anwendung in eine Gruppe, stets nach ihrem Einsatzzweck getrennt. So landen beispielsweise alle Spiele unter Games. Jede dieser Gruppen darf noch weitere Untergruppen enthalten. Ein Action-Spiel wandert beispielsweise in die Untergruppe Games/Arcade.

Welcher Gruppe das gerade zu verpackende Programm angehört, bestimmen Sie über das Tag Group. Theoretisch dürften Sie hier selbst eine beliebige Bezeichnung eintragen. Um den Anwender später nicht zu verwirren, sollten Sie jedoch auf eine der bereits definierten Gruppen zurückzugreifen. Eine Liste mit allen vorgegebenen Gruppen finden Sie in der Datei GROUPS, die sals Bestandteil der RPM-Dokumentation im entsprechenden Unterverzeichnis von /usr/share/doc lagert.

Das Tag Source füllen Sie mit dem Dateinamen des Tar-Archives, das den Quellcode enthält. Alle weiteren Felder dienen lediglich der Information: URL enthält die Internet-Adresse des Programms. Unter Distribution nennen Sie die Distribution, auf Sie das Paket gebaut haben. Und zu guter Letzt tragen Sie Ihren eigenen Namen samt E-Mail-Adresse hinter Packager ein. Dieser Information erlaubt es später Anwendern nachzuvollziehen, wer das Paket erstellt hat.

Damit ist der erste Abschnitt bereits komplett. Da er das Spec-File einleitet, heißt er auch Präambel oder Header. Für Ihre eigenen Projekte kopieren Sie am besten eine bereits vorhandene Präambel, die Sie anschließend an Ihre vorliegenden Gegebenheiten anpassen. Wie die das Handbuch “Maximum RPM” [3] verrät, existieren zudem noch einige optionale Tags. Eines von ihnen zeigt der Kasten “Abhängigkeiten” auf.

Definitionsdatei

Nach der Präambel folgen im Spec-File ein paar weitere Abschnitte. Diese enthalten Anweisungen zum Übersetzen des Programms und zum Packen des Ergebnisses zu einem Paket. In Listing 3 finden Sie ein Beispiel für Bomberclone.

%description
Ein Bomberman-Klon, bei dem sich mehrere Spieler mit kleinen Bomben heftig unter Druck setzen. Mehrspielerpartien in einem Netzwerk sind ebenfalls möglich.
%prep
%setup
./configure
%build
make
%install
make install

Jeder Abschnitt beginnt mit einem Prozentzeichen, gefolgt von seinem Namen. Hinter %description steht zunächst eine ausführliche Beschreibung des Paketinhaltes. Sie erscheint immer dann, wenn Sie den Paketmanager in einem Terminal-Fenster per rpm -qi bomberclone um Rat fragen (Abbildung 4). Wie viel und was Sie hier schreiben, bleibt ganz alleine Ihnen überlassen. Im Gegensatz zur Präambel gibt es keine Beschränkungen.

Es folgen die nächsten drei Abschnitte %prep, %build und %install. Diese steuern den Übersetzungsprozess. Mit %prep erledigen Sie die Vorarbeiten, %build übernimmt das Kompilieren und %install enthält alle Befehle, die zur Einrichtung des Programms notwendig sind.

Bomberclone setzt beispielsweise auf Autoconf/Automake, auch bekannt als Dreisatz. Das ./configure bereitet den Übersetzungsprozess vor, indem es prüft, welche Bedingungen im aktuellen Linux_System herrschen. Dieser Aufruf gehört somit hinter %prep. Als nächstes löst ein make den Übersetzungsvorgang aus. Sein Befehl wandert in den Abschnitt %build. Das Kommando make install spielt schließlich das fertige Ergebnis in das Linux-System ein. Folglich gehört der entsprechende Befehl hinter %install.

Wie das Beispiel zeigt, dürfen Sie in den jeweiligen Abschnitten beliebige Shell-Skripte ablegen. Beispielsweise könnten Sie ./configure noch einen Parameter mit auf den Weg geben und daher per ./configure --prefix=/opt/bomberclone ein anderes Installationsverzeichnis erzwingen.

Auch existiert keine interne Grenze für Umfang und Länge der Skripte. Sie sollten jedoch ausschließlich Kommandos verwenden, die mit hoher Wahrscheinlichkeit auf jeder Distribution anzutreffen sind. Ansonsten kommt es bei der eventuellen Weitergabe des fertigen Spec-Files zu Problemen.

Abbildung 4: Alle Daten des Spec-Files tauchen auch im Paketmanager auf – hier mit KPackage als grafischen Frontend.

Makros

Für den Bomberman-Klon ist das Spec-File damit schon fast komplett. Es bleibt nur noch zu klären, was %setup aus Listing 2 bedeutet. Bei ihm handelt es sich um ein so genanntes Makro. RPM macht von dieser Technik regen Gebrauch. Wie bei jedem seiner Makros verbirgt sich auch hinter %setup nichts anderes als ein mitgeliefertes Skript, das in diesem Fall das Quellcode-Archiv dem Verzeichnis SOURCES entnimmt und anschließend unter BUILD entpackt.

Sollte hier bereits eine ältere Bomberclone-Version liegen, etwa aus einem vorherigen Packversuch, ersetzt das Setup-Skript diese automatisch gegen die neuere Variante. Zum Abschluss wechselt das Makro noch in das Verzeichnis BUILD, indem der nun folgende Übersetzungsvorgang stattfindet.

Datei im Heuhaufen

Übergeben Sie RPM das Spec-File im aktuellen Zustand, entpackt der Paketmanager lediglich das Quellcode-Archiv, kompiliert den Inhalt und installiert die Software anschließend im System. Doch wo bleibt die versprochene Deinstallation? Um auch dieses Problem zu lösen, hängen Sie dem Spec-File einen weiteren Abschnitt mit dem Namen %files an. Dort führen Sie alle Dateien auf, die zum Programm gehören. Nur sie übernimmt RPM in das fertige Paket.

Doch wie bekommen Sie heraus, welche Dateien zum Programm gehören? Dies ist in der Tat der kniffligste Teil beim Erstellen eines RPM-Pakets. Hier kommen Sie leider nicht um eine Testinstallation herum. Bei einfachen Programmen genügt es schon, das Quellcode-Archiv im eigenen Heimatverzeichnis auszupacken und dort zu kompilieren. Anschließend suchen Sie in den Unterverzeichnissen nach den Programmdateien.

Ist die Anwendung umfangreicher, führen Sie noch die Installation durch – allerdings nicht mit den Standardvorgaben, sondern in ein separates Testverzeichnis. In der Regel bietet das Configure-Skript hierfür eine entsprechende Option. Im Beispiel von Bomberclone entpacken Sie das Quellcode-Archiv in ihrem Home-Verzeichnis und rufen dann ./configure --prefix=/tmp/bomberclone auf.

Ein anschließendes make; make install kopiert alle Dateien ins Verzeichnis /tmp/bomberclone. Dort ist es ein Einfaches, die entsprechenden Dateien für die Sektion %files zu identifizieren. Achten Sie darauf, anstelle von /tmp/bomberclone den korrekten Pfad voranzustellen. Meist heißt dieser /usr/local – so auch bei Bomberclone.

Anhand eines solchen Tests finden Sie zudem sofort heraus, ob die Übersetzung ohne Fehler durchläuft und alle vorausgesetzten Entwicklerpakete installiert sind. Nachdem Sie die Sektion %files komplettiert haben, löschen Sie die Installation im temporären Verzeichnis wieder. Den fertigen Abschnitt %files für das Bomberclone zeigt Listing 3.

%files
/usr/local/bin/bomberclone
/usr/local/share/games/bomberclone
%doc /usr/local/doc/bomberclone/README
%doc AUTHORS TODO INSTALL NEWS COPYING ChangeLog

Um hier etwas Tipparbeit zu sparen, dürfen Sie auch nur einen Verzeichnisnamen angeben. Im Beispiel macht die Zeile /usr/local/share/games/bomberclone davon Gebrauch. RPM berücksichtigt automatisch alle Elemente in diesem Verzeichnis. Allerdings besitzt so viel Komfort auch einen kleinen Nachteil: Für RPM gehört das komplette Unterverzeichnis zum Paket – und daher packt es beim Erstellen des Archivs den Ordner rigoros mit ein. Sollte hier aus Versehen ein globales Verzeichnis stehen, wie zum Beispiel /usr/local, so landet dies ebenfalls im Paket.

Als weitere Hilfe erlaubt RPM noch die von der Shell bekannten Wildcards. Beispielsweise fügt /usr/local/share/games/bomberclone/gfx/menu*.png alle Dateien dem Paket hinzu, die mit menu beginnen und auf .png enden.

Mit der in Listing 3 aufgeführten Datei README, der das Makro %doc voransteht, hat es etwas besonders auf sich: Ihren Inhalt bekommen Sie später angezeigt, wenn Sie die im Paket versteckte Dokumentation über rpm -qd bomberclone abfragen. Gleichzeitig landet die Datei in einem speziellen Dokumentationsverzeichnis. Unter Suse Linux ist dies zum Beispiel /usr/share/doc/packages, wo hingegen Red Hat und Mandriva /usr/share/doc bevorzugen.

Die RPM-Dokumentation bezeichnet dieses Verzeichnis allgemein als defaultdocdir. Dieses Wissen erlaubt es, das Makro %doc dazu zu missbrauchen, auch solche Dateien zu kopieren, die ein make install normalweise ignoriert. Hierzu zählen beispielsweise die Dateien INSTALL und ChangeLog. Sie landen ebenfalls im Dokumentationsverzeichnis. Im Bomberclone-Beispiel realisiert dies die letzte Zeile im Abschnitt %files.

Baumeister

Damit ist das Spec-File endlich vollständig, und dem Bauen des RPM-Pakets steht nichts mehr im Wege. Dazu wechseln Sie in einem Terminal-Fenster in das Verzeichnis SPECS und starten dort per rpmbuild -ba bomberclone.spec den Prozess. In einigen älteren Distributionen ist diese Funktion noch im Paketmanager selbst enthalten. In einem solchen Fall führt der Befehl rpm -ba bomberclone.spec zum Ziel.

Der Parameter -ba steht für Build All und weist das Programm Rpmbuild an, zwei RPM-Pakete zu erstellen: Eines mit dem fertigen Programm in Form von Binärdateien und eines mit dem Quellcode. Alle diese Schritte begleiten mehr als üppig ausfallende Meldungen. Ein vorangestelltes + signalisiert, dass sie von Rpmbuild selbst stammen.

Habe fertig

Die Ergebnisse finden Sie anschließend im Ordner SRPMS und RPMS des Arbeitsverzeichnisses /usr/src/packages. Rpmbuild sortiert dabei alle RPM-Pakete nach Prozessortyp. Falls Sie einen herkömmlichen Pentium- oder Athlon-Prozessor mit 32-Bit-Architektur einsetzen, landen die fertigen Dateien im Unterverzeichnis RPMS/i386 oder RPMS/i686. Möchten Sie das Paket für einen anderen Computer erstellen, wie zum Beispiel einem iMac mit PowerPC-Prozesser, hängen Sie dem obigen Rpmbuild-Aufruf einfach noch ein --target Prozessortyp an.

Verzichten Sie auf das zusätzliche Quellcode-Paket, so genügt ein Aufruf von rpmbuild -bb bomberclone.spec beziehungsweise rpm -bb bomberclone.spec auf der Kommandozeile. Das -bb steht hier für Build Binary. Das fertige Paket können Sie nun auf dem herkömmlichen Weg über ihren Paketmanager einspielen. Auf der Kommandozeile führt beispielsweise ein rpm -i bomberclone-0.11.6.2-meinrelease.i686.rpm zum Ziel.

Requires: SDL_mixer, SDL_image, SDL >= 1.1.0

Fazit

Das Erstellen eines Spec-Files erfordert durchaus etwas Geschick und Experimentiergeist. Sobald Sie jedoch einmal die Konfiguration erstellt haben, belohnt RPM den fleißigen Paketbauer mit einer komfortablen und vor allen Dingen gründlichen Deinstallation der entpsrechenden Anwendung. Weitere Informationen liefert die extrem umfangreiche Dokumentation “Maximum RPM” [3].

Abschließend sei noch auf einen Schönheitsfehler des hier vorgestellten Spec-Files hingewiesen: Rpmbuild installiert das Programm vor dem Verpacken einmal vollständig auf dem System. Bei einem heimischen Computer mag dies ohne Probleme gehen, auf einem Büro-Computer weichen Sie hingegen besser auf die so genannte BUILD_ROOT-Umgebung aus. Mehr Informationen zu dieser Technik liefert wieder das erwähnte Buch.