Inhalt

7. RPM-Pakete erstellen

Ein eigenes RPM-Paket zusammenzustellen ist recht einfach, insbesondere wenn man die Software, die man in ein Paket zusammenpacken möchte, dazu bringen kann, ohne Eingriff eines Nutzers automatisch zu kompilieren.

Der grundlegende Ablauf beim Erstellen eines RPM-Paketes ist wie folgt:

Standardmäßig erzeugt der RPM sowohl Quell- als auch Binärcode.

7.1 Die Datei rpmrc

Im Moment wird die Konfiguration des RPM ausschließlich über die Datei /etc/rpmrc erledigt. Eine Beispieldatei könnte so aussehen:

require_vendor: 1
distribution: Marke Eigenbau!
require_distribution: 1
topdir: /usr/src/meins
vendor: Mickiesoft
packager:  Mickeysoft Packaging Account <packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp

Die Zeile require_vendor veranlaßt RPM dazu, eine Vendorzeile zu verlangen. Diese kann dann sowohl in /etc/rpmrc als auch im Header der Spec-Datei selbst festgelegt werden. Um dieses Feature abzuschalten, wird es auf 0 gesetzt. Gleiches gilt für die Zeilen require_distribution und require_group.

Die nächste Zeile ist die distribution Zeile. Diese kann entweder hier oder erst später im Header der Spec-Datei definiert werden. Wenn man das Archiv für eine bestimmte Distribution zusammenstellt, ist es sinnvoll, die Zeile entsprechend anzugeben, es ist jedoch nicht unbedingt erforderlich. Die vendor Zeile ist ähnlich, kann jedoch alles mögliche enthalten (z.B. Joe's Software and Rock Music Emporium).

RPM unterstützt jetzt auch das Packen von Archiven für verschiedene Architekturen. Die Datei rpmrc kann ``optflags'' Variablen beinhalten, die für einzelne Architekturen spezifische Flags für das Kompilieren usw. enthalten. Die Verwendung dieser Variablen wird in einem späteren Abschnitt behandelt.

Zusätzlich zu den obigen Makros gibt es noch einige weitere. Man kann

rpm --showrc
benutzen, um herauszufinden, wie die Tags im Moment gesetzt sind und was die verfügbaren Flags sind.

7.2 Die Spec-Datei

Kommen wir jetzt zu den Spec-Dateien. Sie sind erforderlich, um ein Paket zu erstellen. Sie enthalten eine Beschreibung der Software, Hinweise zum Übersetzen der selbigen und eine Dateiliste aller Binaries, die installiert werden.

Man sollte die Spec-Datei nach der Standardkonvention benennen. Diese lautet Paketname-Strich-Versionsnummer-Strich-Releasenummer-Punkt-spec.

Hier ein Beispiel für eine Spec-Datei (vim-3.0-1.spec):

Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1
Die erläuternden Texte wie %description oder Summary sollten sinnvollerweise in Englisch verfaßt werden, es sei denn, es handelt sich um ein Paket, das nur für deutschsprachige Anwender gedacht ist.

7.3 Der Header

Der Header hat einige Standardfelder, die angegeben werden müssen. Es gibt auch ein paar kleine "Problemzonen", die man kennen sollte. Die Felder haben folgenden Inhalt:

7.4 Prep

Das ist der zweite Abschnitt in der Spec-Datei. Hiermit werden die Quellen fürs Übersetzen angepaßt. Man sollte hier alle Dinge veranlassen, die nötig sind, um die Quellen zu patchen und für ein make vorzubereiten.

Anmerkung: Jeder dieser Abschnitte ist eigentlich nur ein Platz, an dem Shellskripte ausgeführt werden. Man könnte einfach ein Shellskript schreiben, das nach dem %prep Tag eingetragen wird und die Quellen entpackt und patcht. Wir haben jedoch Makros geschrieben, die das ein wenig vereinfachen sollen.

Das erste dieser Makros ist das %setup Makro. Im einfachsten Fall (keine Parameter auf der Kommandozeile) entpackt es nur die Quellen und macht ein cd ins Quellverzeichnis. Es versteht die folgenden Optionen:

Das nächste verfügbare Makro ist das %patch Makro. Dieses Makro erleichtert das Anwenden von Patches auf die Quellen. Es kennt die folgenden Optionen

Das sollten alle Makros sein, die man benötigt. Wenn man diese richtig verstanden hat, kann man auch andere Arten von Setup's via sh-Skripten erstellen. Alles was bis zum %build Makro, näher erläutert im nächsten Abschnitt, eingefügt wird, wird von der sh abgearbeitet. Siehe das Beispiel oben für Aktionen, die hier ausgeführt werden können.

7.5 Build

Für diesen Abschnitt gibt es keine eigenen Makros. Hier werden alle Kommandos eingetragen, die notwendig sind, um ein Programm zu übersetzen, nachdem die Quellen entpackt und gepacht wurden und man ins entsprechende Verzeichnis gewechselt hat. Auch dies hier ist wieder nur eine Folge von Anweisungen, die der shzur Ausführung übergeben werden, d.h. alle gültigen sh-Kommandos können hier benutzt werden, inklusive Kommentare. Das aktuelle Verzeichnis wird nach jedem dieser Abschnitte wieder auf das Toplevel-Verzeichnis der Quellen gesetzt, man sollte das immer beachten. Man kann, wenn notwendig, in ein Unterverzeichnis wechseln.

7.6 Install

Auch für diesen Abschnitt gibt es keine eigenen Makros. Es werden hier ebenfalls alle Kommandos aufgelistet, die notwendig sind, um das fertige Programm zu installieren. Falls das Paket ein make install hat, kann man es hier einsetzen. Wenn nicht, kann das Makefile entsprechend gepatcht werden, oder die Installation von Hand mit Shellkommandos bewerkstelligt werden. Das aktuelle Verzeichnis ist hier wieder das Toplevel-Verzeichnis der Quellen.

7.7 Optionale Pre- und Postinstall/deinstall Skripten

Hier können Skripten angegeben werden, die vor und nach der Installation und der Deinstallation von fertig übersetzten Paketen abgearbeitet werden. Einer der Hauptgründe dafür ist das Ausführen von speziellen Programmen, wie z.B. ldconfig nach dem Installieren oder Entfernen von Paketen mit Shared Libraries. Die Makros für die jeweiligen Skripte sind:

Der Inhalt dieser Abschnitte ist ein beliebiges sh-Skript, jedoch ohne die #!/bin/sh Zeile.

7.8 Files

In diesem Abschnitt müssen die Dateien des fertig übersetzten Paketes angegeben werden. RPM hat keine Möglichkeit, herauszufinden, welche Dateien als Ergebnis eines make install im System installiert werden. Hierfür gibt es KEINE Möglichkeit. Es gab Vorschläge, dieses mit einem find vor und nach dem Installieren zu bewerkstelligen. In einem Multiusersystem, bei dem zur gleichen Zeit von anderen Prozessen Dateien geschaffen werden können, die mit dem Paket nichts zu tun haben, ist dies jedoch nicht sinnvoll.

Hier gibt es ebenfalls einige Makros für spezielle Zwecke. Folgende Makros stehen zur Verfügung:

Das größte Problem der Dateilisten ist das Auflisten von Verzeichnissen. Wenn man aus Versehen /usr/bin mit auflistet, werden alle Dateien in /usr/bin des Systems als zum Paket gehörig betrachtet. .

7.9 Übersetzen

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:

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 ein 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. Danach wird der Patch erstellt mit

diff -uNr verzname.orig verzname > ../SOURCES/dirname-linux.patch
o.ä., je nach konkretem Fall. Das erzeugt einen Patch, der in der Spec-Datei verwendet werden kann. Der ``linux'' Teil des Patchnamens ist 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.

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 setzt die einfachen Teile ein, und ergänzt dann nach und nach die anderen Teile im weiteren Verlauf.

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

Es gibt weitere Optionen, die mit dem -b Switch zusammen nützlich sind:

Es gibt noch einige Optionen zum Modifizieren des Ablaufs des -b-Switch:

7.10 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 das es nun bereits recht gut installiert sein sollte.

Man kann das Paket mit rpm -u packagename 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.

7.11 Wenn das neue rpm fertig ist

Wenn man ein neues rpm von irgend etwas fertiggestellt hat, kann man es - unter der Voraussetzung, daß 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.

7.12 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 sollte 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 Netscape, ssh, pgp, usw.


Inhalt