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:
BUILD ist das Verzeichnis, in dem die Übersetzung durch den RPM
stattfindet. Es ist nicht notwendig, die Testpakete in einem speziellen
Verzeichnis erstellen, aber dies ist der Platz, wo der RPM seine Übersetzungen
durchführt.
SOURCES hier sollten alle tar-Archive mit den originalen Quellen
und die Patches stehen. Hier sucht der RPM per Default nach den Quelldateien.
SPECS In dieses Verzeichnis gehören die Spec-Dateien.
RPMS das Verzeichnis für die fertig übersetzten und gepackten
rpm's.
SRPMS das Verzeichnis für die Quell-rpm's.
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
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.
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.
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:
p Ausführen des prep Abschnittes der Spec-Datei.
l ist ein Listencheck, der einige Tests mit
%files macht.
c Ausführen von prep und kompilieren. Kann verwendet werden, um
zu testen, ob die Quellen auch wirklich durchkompilieren. Das sieht auf den
ersten Blick etwas sinnlos aus, da man seine Quellen üblicherweise erst zum
Übersetzen bringt und dann erst den RPM anwirft, aber wenn man erst mit dem RPM
vertraut ist, gibt es Gelegenheiten, in denen das sinnvoll ist.
i Ausführen von prep, kompilieren und installieren.
b Ausführen von prep, kompilieren, installieren und nur erstellen
des Binärpaketes.
a alles erstellen (Quell- und Binärpakete).
Es gibt noch einige Optionen zum Modifizieren der Wirkung des -b-
Switches:
--short-circuit beginnt direkt mit dem angegebenen Abschnitt (nur
zusammen mit c und i).
--clean entfernt nach Beendigung die Übersetzungsverzeichnisse.
--keep-temps behält alle temporären Dateien und Skripte, die in
/tmp angelegt wurden. Mit der Option -v kann man sehen, was in
/tmp erzeugt wurde.
--test führt keine wirklichen Aktionen aus, bewahrt aber temp-
Dateien.
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.
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.
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.