Private Paketzentrale

Der mühsame Teil

Alles ist eingerichtet, doch RPM weiß immer noch nicht, welche Dateien denn nun zum Paket gehören sollen. Sie wissen es bis jetzt genausowenig, denn Sie haben xpuyopuyo ja noch gar nicht installiert. Einen Königsweg, um an die Dateiliste zu kommen, gibt es nicht. Manch einer installiert die Software vorab und lässt sich vom Programm installwatch eine Liste der kopierten Dateien erstellen. Nichts anderes macht checkinstall, und die Methode ist nicht 100-prozentig zuverlässig. Ganz hartgesottene Naturen klauben die Dateiliste aus dem Makefile zusammen. Alternativ installiert man die Software zunächst als normaler Benutzer in ein Unterverzeichnis seines Home. Die Dateiliste bekommt man dann entweder durch ein selbstgeschriebenes Skript oder stellt sie aus der Ausgabe von ls -R selbst zusammen. Natürlich müssen dann im Specfile die Pfade angepasst werden: Statt /home/nutzername/test/bin/date steht im Specfile /usr/local/bin/datei.

Obwohl ziemlich aufwendig ist letztgenannter Weg empfehlenswert. Dadurch, dass Sie das Paket zunächst als normaler Benutzer bauen stellen Sie sicher, dass der "make install"-Aufruf tatsächlich nur Dateien in die Unterverzeichnisse des angegebenen --prefix installiert, und Sie wissen, dass das Makefile keinen fatalen "rm -rf"-Aufruf enthält. Außerdem stellen Sie so sicher, dass beim Build-Prozess alle benötigten Entwicklerpakete vorhanden sind (xpuyopuyo verlangt die Development-Pakete von gtk, xpm, XFree, glib und mikmod).

Manchmal sind auch die Programmierer selbst so nett, ihrer Software ein passendes Specfile mit kompletter Dateiliste beizulegen. Für das Beispiel haben wir in bester Fernsehkoch-Manier schon einmal etwas vorbereitet: Den letzten Teil des Specfiles finden Sie in Listing 3.

%files
/usr/local/man/man6/xpuyopuyo.6
/usr/local/bin/xpuyopuyo
/usr/local/share/xpuyopuyo
%doc /usr/local/share/xpuyopuyo/xpuyopuyo.txt

Interessant sind die beiden letzten Zeilen. Ins Verzeichnis /usr/local/share/xpuyopuyo werden bei der Installation mehrere Unterverzeichnisse mit Bildern und Sounds kopiert. Steht im %files-Abschnitt ein Verzeichnis, wird dieses samt Inhalt eingepackt und Bestandteil des Pakets – achten Sie also darauf, dass Ihnen auf keinen Fall die Zeile /usr/local in diesen Abschnitt rutscht. Das vorangestellte %doc in der letzten Zeile markiert die danach genannte Datei als Dokumentation. Diese Datei bekommen Sie angezeigt, wenn Sie bei der Abfrage des Pakets den Befehl rpm -qd xpuyopuyo benutzen. Es gibt noch eine weitere Anwendungsmöglichkeit für das %doc-Tag: Oft bringen Programme Dokumentation mit, die make install nicht kopiert. Steht in der Datei-Sektion des Specfiles eine Zeile der Art

%doc README FAQ CREDITS

kopiert RPM diese drei Dateien aus dem Quellcode-Verzeichnis in ein Unterverzeichnis des defaultdocdir und packt sie mit ins Paket. Das defaultdocdir ist auf jedem System ein anderes, unter Mandrake und Red Hat /usr/share/doc, bei SuSE /usr/share/doc/packages. Der Vorgabewert kann über die Datei .rpmrc im Home-Verzeichnis von root geändert werden.

Wildcards erleichtern das Leben im %files-Abschnitt des Specfiles. Kopiert ein Programm sehr viele Lokalisierungsdateien nach /usr/local/share/locale, erschlägt man alle diese Dateien mit der Zeile:

/usr/local/share/locale/@L: */LC_MESSAGES/programmname.mo

RPM meckert zwar, wenn einige der Sprachverzeichnisse keine Datei dieses Namens enthalten, arbeitet jedoch artig weiter.

Pakete schnüren

Nun ist endlich alles bereit, um das Paket zu bauen. Rufen Sie im Verzeichnis SPECS den Befehl rpm -ba xpuyopuyo.spec auf, unter Red Hat müssen Sie rpmbuild -ba xpuyopuyo.spec eingeben. Der Parameter -b sagt RPM, dass er die Steuerinformationen für den Build-Prozess aus einer Datei lesen soll. In diesem Fall wünschen wir uns einen kompletten Build-Durchlauf, RPM soll also alle Abschnitte des Specfiles abarbeiten und sowohl ein Binär- als auch ein Source-Paket erzeugen. Das signalisiert der Parameter a. Wer auf das Source-RPM verzichten kann, wählt stattdessen b, gibt also rpm -bb xpuyopuyo.spec ein. Der Aufruf rpm -bc xpuyopuyo.spec testet, ob ein Paket überhaupt kompiliert. Dabei wird das Specfile nur bis zum Punkt %build ausgeführt, also keine Dateien kopiert.

Welchen Aufruf Sie auch eingeben, rpm ist in jedem Fall sehr gesprächig. Sie sehen, was der Paketmanager tut und bekommen außerdem auch die Ausgabe der einzelnen Befehlsaufrufe präsentiert:

+ cd xpuyopuyo-0.9.5
+ ./configure --prefix=/usr/local
creating cache ./config.cache

Die mit einem Plus-Zeichen beginnenden Zeilen zeigen die Aktionen von RPM, hier den Wechsel ins Quellcode-Verzeichnis und den Aufruf des ./configure-Befehls. Danach folgen die Ausgaben des aufgerufenen Skripts. Hat alles geklappt, sollten die letzten Zeilen aussehen wie in Abbildung 2.

Abbildung 2: RPM hat ein Binär- und ein Source-Paket erzeugt.

Vor der Erfolgsmeldung sieht man, dass RPM in gewissem Rahmen selbst ermittelt, welche Abhängigkeiten ein Paket hat. Dafür wird für jede eingepackte Binärdatei der Befehl ldd aufgerufen, der ermittelt, gegen welche Bibliotheken ein Programm gelinkt ist. Dem neu entstandenen xpuyopuyo-Paket wird also die Installation verweigert, wenn die mikmod-Bibliothek nicht installiert ist. Abhängigkeiten, die ldd nicht erkennt, muss man ins optionale Tag Requires: in der Präambel zu schreiben. Das Mail-Programm Mutt beispielsweise benötigt einen lokalen Mailserver, enthält also das Tag Requires: mailserver. Das Gegenstück dazu ist das Tag Provides:. Ein Distributor, der seine Pakete gut pflegt, wird Provides: mailserver in die Präambel von sendmail und postfix schreiben.

Das fertige Binärpaket liegt nun im Unterverzeichnis i686 des Ordners RPM. Auf welchen Prozessor-Typ optimiert wird, ist distributionsabhängig, kann aber jederzeit durch die rpm-Kommandozeilenoption --target Prozessortyp überschrieben werden.

Der Aufruf make install-strip im Specfile kopiert die xpuyopuyo-Dateien zwar, nimmt das neu erstellte Paket jedoch nicht in die Paketdatenbank auf. Um das Tetris-Spiel dort hinzuzufügen, installiert man das Paket über den Aufruf rpm -i ../RPMS/i686/xpuyopuyo-0.9.5-apocalypse.i686.rpm. Falls Sie sich nicht mehr im Verzeichnis SPECS befinden, geben Sie den absoluten Pfad ein. Mit dem Befehl rpm -qil xpuyopuyo | less können Sie danach alle Informationen zu Ihrem selbstgebauten Paket abfragen.

Sicher hat jeder schon einmal ein Paket installiert, bei dem dann manches nicht so funktionierte wie erwartet. Oft liegt das nur an einer fehlenden Datei. Um den Benutzern Ihrer Pakete solchen Ärger zu ersparen, testen Sie jedes selbstgebaute RPM erst auf einem anderen Rechner als dem Build-System, bevor Sie es weitergeben.