Ein Paket bauen

In der Build-Umgebung zimmert der Entwickler jetzt sein erstes Paket, beispielsweise eines für den Editor Beaver [3], der hier auch als Beispiel für ein einfaches Programm dient. Die Spec-Datei, die den Paketbau steuert, legt der Paketierer dazu in das Verzeichnis »SPECS« und das Quellarchiv, das er von der Homepage heruntergeladen hat, in das Verzeichnis »SOURCES« . Dann startet »rpm --ba SPECS/beaver.spec« den Bau des Paketes (Abbildung 1).

Abbildung 1: Rpmbuild baut ein Softwarepaket aus einer Spec-Datei. Die lässt sich einfach anpassen und bietet viele Möglichkeiten.

Das Paket lässt sich anschießend mit Rpm problemlos installieren. Leider warnt das Konsolentool nicht wegen der fehlenden Signatur, wohl aber die Paketverwaltungen moderner Distributionen wie Yum (Listing 4), Yast oder Packagekit (Abbildung 2). Während Packagekit immerhin den Anwender noch einmal um Eingabe des Rootpasswort bittet, verweigert Yum die Installation kategorisch, sofern die Überprüfung des GPG Schlüssels nicht mit der Option »--nogpgcheck« deaktiviert ist.

01 # yum localinstall /home/chris/rpmbuild/RPMS/x86_64/beaver-0.4.1-1.x86_64.rpm
02 Geladene Plugins: langpacks, presto, refresh-packagekit,
03 Adding de_DE to language list
04 Einrichten der lokalen Paketverarbeitung
05 Untersuche /home/chris/rpmbuild/RPMS/x86_64/beaver-0.4.1-1.x86_64.rpm: beaver-0.4.1-1.x86_64
06 Markiere /home/chris/rpmbuild/RPMS/x86_64/beaver-0.4.1-1.x86_64.rpm zum Installieren
07 Löse Abhängigkeiten auf
08 --> Führe Transaktionsprüfung aus
09 ---> Paket beaver.x86_64 0:0.4.1-1 markiert, um installiert zu werden
10 --> Abhängigkeitsauflösung beendet
11 Abhängigkeiten aufgelöst
12 =====================================================================
13  Paket         Arch       Version   Repository                Grösse
14 =====================================================================
15 Installieren:
16  beaver        x86_64     0.4.1-1  /beaver-0.4.1-1.x86_64     448 k
17 Vorgangsübersicht
18 =====================================================================
19 Install       1 Package(s)
20 Gesamtgrösse: 448 k
21 Installed size: 448 k
22 Ist dies in Ordnung? [j/N] :j
23 Lade Pakete herunter:
24 Paket beaver-0.4.1-1.x86_64.rpm ist nicht unterschrieben

Abbildung 2: Package Kit warnt den Anwender eindringlich davor, unsignierte Pakete zu verwenden, und verlangt erneut das Admin-Passwort.

Um diese Warnung loszuwerden, sind zwei Schritte notwendig: Der Paketbaumeister muss das Paket signieren [4] und der Benutzer den öffentlichen Schlüssel in sein System integrieren. Als erstes signiert der Ersteller das Paket mit dem Befehl »rpm --addsign« .

$ rpm --addsign rpmbuild/RPMS/x86_64/beaver-0.4.1-1.x86_64.rpm
Bitte das Passwort eingeben:
Das Passwort ist richtig.
rpmbuild/RPMS/x86_64/beaver-0.4.1-1.x86_64.rpm:

Der Befehl akzeptiert auch Wildcards, was es möglich macht, mehrere Pakete gleichzeitig kryptografisch zu unterzeichnen, ohne das Passwort erneut von Hand eingeben zu müssen.

Im Prinzip reicht ein einzelner Ordner mit signierten Paketen für Downloads aus, aber erst wenn dazu eine bestimmte Verzeichnisstruktur kommt, sprechen Entwickler von einem Repository. Vor dem Aufsetzen des "Repos" sollte sich der Admin Gedanken darüber machen, welche Distributionen und Versionen er bedienen will. Das folgende Beispiel bietet Pakete in 32 und 64 Bit für Fedora 14 an und veröffentlicht auch die passenden Quellpakete dazu. »mkdir -p repo/fedora/14/{i386,x86_64,sources}« erstellt die Ordnerstruktur, in der die fertigen Pakete landen.

Repository bauen

Damit die Paketverwaltung die Pakete erkennt, extrahiert »createrepo« einige Metadaten aus dem RPMs, zum Beispiel den Namen, die Version oder die Abhängigkeiten. Creatrepo ruft der Entwickler einfach im Verzeichnis mit den Paketen auf, es legt die Metadaten in dem Unterordner »repodata« ab:

$ cd ~/repo/fedora/14
$ for i in i386 x86_64 sources ; do
> cd $i
> createrepo .
> cd ..
> done

Createrepo darf der Admin aber erst nach dem Signieren des Paketes ausführen, weil sich das Paket durch die Signatur natürlich verändert, ebenso wie seine Metadaten. Im Wurzelverzeichnis des Repositorys hinterlegt er zusätzlich zwei Dateien, die Repository-Beschreibung und den Schlüssel.

Damit ein Benutzer das Lager in seine Paketverwaltung einbinden kann, braucht es eine ».repo« -Datei. Landet die auf dem Client, zum Beispiel mit Yum im Ordner »/etc/yum.repos.d/« , kann der Admin dort sofort Pakete aus dem Repository installieren. Listing 5 zeigt die ersten Zeilen einer solchen Datei. Dank des Eintrags »gpgkey« weiß die Paketverwaltung nun, welcher Schlüssel zum Signieren der Pakete diente und wo der passende Public Key zu finden ist. Der Paketersteller exportiert ihn mit dem Kommando:

01 [...]
05 [max-mustermann]
06 name=Max Mustermann's RPM packages
07 baseurl=http://example.net/repo/fedora/$releasever/$basearch/
08 enabled=1
09 skip_if_unavailable=1
10 gpgcheck=1
11 gpgkey=http://example.net/repo/RPM-GPG-KEY-Mustermann
12
13 [max-mustermann-sources]
14 name=Max Mustermann's RPM packages - Sources
15 baseurl=http://example.net/repo/fedora/$releasever/sources/
16 enabled=1
17 skip_if_unavailable=1
18 gpgcheck=1
19 gpgkey=http://example.net/repo/RPM-GPG-KEY-Mustermann
20 [...]

$ gpg --export --armor max.mustermann@example.net > RPM-GPG-KEY-Mustermann

Damit die in der Repo-Datei angegebene URL auch nach dem Upload auf den Server noch stimmt, landet die Schlüsseldatei »RPM-GPG-KEY-Mustermann« direkt im Wurzelverzeichnis des Repository.