Inhalt

8. Übersetzen und packen

8.1 Die Struktur der Quellenverzeichnisse

Zunächst braucht man natürlich einen passenden Verzeichnisbaum für die Quelldateien. Man kann diesen in der Datei /etc/rpmrc festlegen, üblicherweise wird hier einfach /usr/src verwendet.

Eventuell müssen die folgenden Verzeichnisse angelegt werden, um einen Verzeichnisbaum für das Übersetzen zu erstellen:

8.2 Testübersetzung

Zunächst sollte man dafür sorgen, daß die Quellen korrekt ohne den RPM übersetzt werden. Dazu entpackt man die Quellen und benennt das Verzeichnis um nach $NAME.orig. Danach werden die Quellen ein zweites Mal entpackt. Diese zweite Version wird dann zum Übersetzen benutzt. Man wechselt ins Quellverzeichnis und folgt den Anweisungen zum Übersetzen des Paketes. Wenn man, um die Quellen zu übersetzen, Änderungen an ihnen vornehmen mußte, braucht man einen Patch. Um einen solchen zu erstellen, entfernt man alle Dateien, die von einem configure Skript o.ä. angelegt wurden, aus dem Verzeichnis, das die jetzt vollständig übersetzbaren Quellen enthält. Danach wechselt man in das übergeordnete Verzeichnis des obersten Quellverzeichnisses. Dann wird der Patch erstellt mit

diff -uNr verzname.orig verzname > ../SOURCES/dirname-linux.patch
o.ä., je nach konkretem Fall.

Dieser Schritt erzeugt einen Patch, der in der Spec-Datei verwendet werden kann. Der »linux« Teil des Patchnamens dient hier nur als Beispiel, man kann hier einen Namen verwenden, der etwas mehr über den Grund für diesen Patch aussagt, z.B. »config« oder »bugs«. Man sollte außerdem noch einen Blick in die fertige Patchdatei werfen, um sicherzustellen, daß nicht aus Versehen Binaries o.ä. mit eingetragen wurden.

8.3 Erstellen der Dateiliste

Nachdem man funktionierende Quellen hat, werden diese übersetzt und installiert, so wie es beim Endbenutzer geschehen würde. Aus dem Resultat dieser Installation wird dann die Dateiliste erstellt. Wir erstellen die Spec-Datei normalerweise gleichzeitig mit den beschriebenen Schritten. Man erstellt eine Startversion der Datei und füllt die einfachen Teile aus, und ergänzt dann im weiteren Verlauf nach und nach die anderen Teile.

8.4 Erstellen des Paketes mit dem RPM

Wenn die Spec-Datei fertig ist, kann man versuchen, ein RPM-Paket zu erzeugen. Dies geschieht meistens mit einem

rpm -ba foobar-1.0.spec

Darüber hinaus gibt es weitere Optionen, die mit dem -b Switch zusammen verwendet werden können:

Es gibt noch einige Optionen zum Modifizieren der Wirkung des -b- Switches:

8.5 Austesten

Wenn man ein fertiges Paket für die Quellen und die Binaries hat, sollte man es testen. Das Beste und Einfachste ist es, das Paket auf einem völlig anderen Rechner zu testen als dem, auf dem man es erstellt hat. Schließlich hat man das Paket bereits mehrfach auf diesem Rechner mit make install o.ä. installiert, so daß es nun bereits recht gut installiert sein sollte.

Man kann das Paket mit rpm -e paketname zwar wieder deinstallieren, wenn man aber in der Liste der Dateien eine oder mehrere vergessenen hat, die aber durch das make install installiert wurden, werden diese nicht wieder deinstalliert. Wenn man danach das Paket wieder installiert, ist es wieder vollständig auf dem Rechner, auch wenn das rpm selbst unvollständig ist. Darüber hinaus sollte man beachten, daß man selbst zwar eine Testinstallation mit rpm -ba package macht, die meisten Leute jedoch nur ein rpm -i package machen werden. Man muß daher darauf achten, daß in den build oder install Abschnitten nichts getan wird, was auch für eine reine Installation der Binaries notwendig ist.

8.6 Wenn das neue rpm fertig ist

Wenn man ein neues rpm von fertiggestellt hat, kann man es - falls es noch nicht als rpm existiert - anderen zur Verfügung stellen. Hierbei muß das, was man zusammengepackt hat, natürlich ein entsprechendes Copyright haben. Man kann es dann auf den FTP-Server ftp.redhat.com stellen.

8.7 Was weiter?

Es sei hier noch einmal besonders auf die vorhergehenden Abschnitte zum Testen und der Verwendung der fertigen rpm's hingewiesen. Wir wollen so viele rpm's wie möglich in guter Qualität zur Verfügung stellen. Bitte die rpm's gründlich austesten und dann zum Nutzen aller ins Netz stellen. Unbedingt sollte man jedoch vorher sicherstellen, daß das Copyright dieses auch zuläßt. Kommerzielle Software und Shareware sollten nicht öffentlich zur Verfügung gestellt werden, es sei denn, das Copyright der entsprechenden Software läßt das ausdrücklich zu. Das gilt z.B. für Programme wie ssh, pgp usw.


Inhalt