Private Paketzentrale

Was sammelt sich nicht im Laufe der Zeit an selbstkompilierter Software auf dem eigenen System an? Hat man bei Binärdateien zumindest eine grobe Vorstellung, wo sie herumliegen, ist man spätestens im Unterverzeichnis /usr/local/lib heillos verloren. Händische Löschaktionen und das Rätselraten nach dem Ursprung einer Datei lassen sich vermeiden, wenn das Paketmanagement der Distribution auch selbstkompilierte Software verwaltet.

Das am weitesten verbreitete Programm dafür ist rpm, der Red Hat Package Manager. Er schreibt nicht nur alle Informationen über die installierten Pakete in seine Datenbank, sondern kümmert sich darüber hinaus auch um die Abhängigkeiten, so dass eine rückstandslose Entfernung möglich wird. Das ist ein unschätzbarer Vorteil, denn selbst wenn Sie eine Bibliothek installiert haben, damit Programm A läuft, können Sie diese nicht bedenkenlos zusammen mit Programm A entfernen. Möglicherweise wurde nachträglich noch weitere Software eingespielt, die ebenfalls auf die fragliche Bibliothek angewiesen ist. RPM wacht darüber und warnt Sie in einem solchen Fall.

Handarbeit bevorzugt

Damit RPM auch selbstkompilierte Software verwaltet, muss aus dem Quellcode erst einmal ein Paket werden. Mit checkinstall [1,2] existiert ein Programm, das die Installation überwacht und beim Aufruf von make install aus den kopierten Dateien ein RPM-Paket baut.

Wie alle automatisierten Lösungen hat auch diese den Nachteil, dass sie nicht alle Möglichkeiten des RPM-Befehls bietet. Sie kann eine Software nicht in mehrere Einzelpakete aufteilen, und bei manchen Programmen verweigert checkinstall ganz die Mitarbeit.

Das gravierendste Manko: Sie erstellt die Dateiliste für das Paket erst während der Installation, man hat also keinerlei Kontrolle darüber, ob nicht Dateien überschrieben werden. Das soll jedoch in einer der nächsten Versionen durch Unterstützung der RPM-BUILDROOT-Option ausgemerzt werden. Damit lassen sich Pakete in einer Art Sandbox bauen, etwa im Verzeichnis /tmp. Das Programm betrachtet /tmp während der Installation als Wurzelverzeichnis, so dass keine System-Dateien überschrieben werden.

Wer keine halben Sachen mag, verlässt sich daher nicht auf Zusatz-Tools, sondern baut seine Pakete selbst. Wie das geht, darüber schweigt sich die RPM-Dokumentation leider weitgehend aus und "Maximum RPM" [3], die Referenz für Paketbauer und alle die es werden wollen, eignet sich wegen des Umfangs von mehreren hundert Seiten nicht für einen schnellen Einstieg.

Um Sie nicht mit trockener Theorie zu Tode zu langweilen, beschreiben wir, wie man ein Paket des Programms xpuyopuyo [4] baut. Das ist ein netzwerkfähiges, Tetris-ähnliches Spiel mit netter Grafik, lustigem Sound und hohem Suchtfaktor(Abbildung 1), sollte also genug Anreiz bieten, die Mühe des Paketbauens auf sich zu nehmen.

Abbildung 1: Das Programm Xpuyopuyo dient als Beispiel zum Erstellen eines RPM-Pakets.

Vorbereitungen

Wer denkt, er könne sofort loslegen, irrt. Die meisten Distributoren installieren nur die Programme, die nötig sind, um RPMs zu installieren, nicht aber jene, die man zur Erstellung benötigt. In diesem Fall muss zunächst das Paket rpm-build eingespielt werden. Die Packtheke, also das Arbeitsverzeichnis des Paketbauers, befindet sich unterhalb des Verzeichnisses /usr/src, und auch hier geht jeder Distributor eigene Wege. Unter SuSE nennt es sich packages, bei Mandrake RPM, und der amerikanische Marktführer hat den entsprechenden Ordner ganz egozentrisch redhat genannt.

In den dort liegenden fünf Unterverzeichnissen SOURCES, SPECS, BUILD, RPMS und SRPMS geht der Paketbau vonstatten. RPMS und SRPMS nehmen später die erzeugten Binär- und Source-Pakete auf und im Verzeichnis BUILD wird die Software kompiliert. Da Sie beim Erstellen von RPMs die entsprechenden Befehle nicht selbst eingeben, sondern RPM sie aus einer Steuerdatei, dem so genannten Specfile, liest, gibt es in diesem Ordner für Sie nichts zu tun.

Der Paketbauer bewegt sich in SOURCES und SPECS. Unter SOURCES muss sich das tar.gz-Archiv mit der zu verpackenden Software befinden. Liegt Ihr Quellcode in einer anderen Form vor, müssen Sie ihn vorher in ein tar.gz-Archiv umwandeln.

Werden Sie zunächst durch den Befehl su und nachfolgende Eingabe des root- Passwortes zum Administrator. Sie brauchen während des gesamten Build-Prozesses Superuser-Rechte. Man kann auch normalen Benutzern das Paketebauen erlauben, was jedoch kompliziert einzurichten ist. Laden Sie die Datei http://chaos2.org/xpuyopuyo/xpuyopuyo-0.9.7.tar.gz herunter und kopieren Sie sie nach SOURCES. Wechseln Sie danach in das Verzeichnis SPECS. Dort erwartet RPM die Steuerdatei. Wie Sie diese nennen ist egal, es hat sich jedoch eingebürgert, einen Namen nach dem Schema Programmname.spec zu wählen. Öffnen Sie dann als root einen Editor und beginnen Sie mit der Erstellung der Textdatei xpuyopuyo.spec.