Paketbau-Tutorial 1: banner

Version enthält die Versionsnummer der paketierten Software.

Release nummeriert Aktualisierungen der Spec-Datei, Paketneuerstellungen und andere Arbeiten innerhalb von Fedora. Der hier verwendete Wert %autorelease ist Teil von rpmautospec, das für Fedora-Pakete empfohlen wird. Er verknüpft Release mit dem Git-Verlauf des Pakets. Da wir kein Git-Repository verwenden, wird %autorelease standardmäßig auf den Wert 1 gesetzt.

Der Inhalt von Summary kann oft aus der README-Datei des Quellcodes kopiert werden. Der erste Buchstabe sollte großgeschrieben werden, um Fehlermeldungen von rpmlint zu vermeiden.

License beschreibt die Lizenz des resultierenden Binärpakets mithilfe einer SPDX-Lizenzkennung. Sie muss den Fedora-Lizenzierungsrichtlinien entsprechen. In der Praxis erfordert die Ermittlung des korrekten Werts häufig die Prüfung der Lizenzhinweise in den einzelnen Quelldateien. Gegebenenfalls müssen auch die Entwickler des Upstream-Projekts um Klärung oder Korrektur gebeten werden. In diesem Tutorial gehen wir einfach davon aus, dass die Lizenz die GNU General Public License, Version 2, ist.

URL verweist auf die Website des Upstream-Projekts, in diesem Fall die Seite des GitHub-Repositorys.

Source definiert die beim Erstellen des Pakets verwendeten Quelldateien. Normalerweise handelt es sich, wie in diesem Fall, um eine URL, die auf ein vom Quellcode bereitgestelltes Tar-Archiv verweist. Es kann aber auch eine lokale Datei sein. Bei Bedarf können mehrere Source-Tags verwendet werden.

%description kann oft aus der README-Datei des Upstream-Projekts kopiert werden.

%prep enthält ein Shell-Skript zur Vorbereitung der Quellen für den Bauprozess. Oft handelt es sich dabei lediglich um das Makro %autosetup, das in diesem Fall die Quellen entpackt.

%build enthält ein Shell-Skript für die erforderlichen Bauschritte, wie beispielsweise das Kompilieren von Quellcode zu Binärdateien. Da das Bausystem von Banner auf Autotools basiert, erfordert der Bauprozess die Ausführung von configure und make. Die Makros %configure und %make_build rufen diese Befehle mithilfe der Kompilierungsflags von Fedora und weiterer Konfigurationen auf.

%install enthält ein Shell-Skript, das die Ergebnisse von %build in ein anfänglich leeres Buildroot-Verzeichnis kopiert. Da Banner Autotools verwendet, kommt das Makro %make_install zum Einsatz.

%files listet den Inhalt des resultierenden Pakets auf. Die Dateien stammen größtenteils aus dem Build-Verzeichnis, das mit %install erstellt wurde. Dokumentations- und Lizenzdateien können aber auch direkt aus den Quellen hinzugefügt werden. Dieser Abschnitt ist vorerst leer und wird später ausgefüllt.

Das %changelog (Änderungsprotokoll) dokumentiert die Änderungen in jeder neuen Paketversion und jeder Veröffentlichung. Die Changelog-Daten können mit rpm --query --changelog PAKETNAME angezeigt werden. Dies ist beispielsweise nützlich, um herauszufinden, ob bestimmte Bug- und Sicherheitspatches enthalten sind. Der Wert %autochangelog stammt ebenfalls aus rpmautospec. Er füllt das Änderungsprotokoll mit Git-Commit-Nachrichten. Da wir kein Git-Repository verwenden, ist das Änderungsprotokoll leer.

Nicht benötigte Zeilen können mit dem Hash-Zeichen # auskommentiert werden.

Weitere Informationen finden Sie im Abschnitt Spec-Dateiformat des RPM-Referenzhandbuchs.

Dies ist das ausführbare Binärprogramm. /usr/bin hat, wie viele andere Systemverzeichnisse, ein Standard-RPM-Makro definiert. Die Makros sollten immer verwendet werden, sofern verfügbar. Daher ist die ausführbare Datei in %files wie folgt aufgeführt:

Die Paketbaurichtlinien enthalten einen eigenen Abschnitt für Handbuchseiten. Gemäß den dortigen Anweisungen werden die Handbuchseiten wie folgt aufgelistet:

An diesem Punkt wird der Mock-Build erfolgreich abgeschlossen, aber es gibt noch weitere Dateien, die wir zum Paket hinzufügen sollten.

Jedes Paket muss seine Lizenz installieren, die mit der Direktive %license gekennzeichnet ist. Im Fall von Banner, wie auch bei vielen anderen Projekten, befindet sich die Lizenzdatei im Hauptverzeichnis des Quellcode-Archivs und wird möglicherweise während der Installation gar nicht in das Buildroot-Verzeichnis kopiert. Ungeachtet dessen kann sie mithilfe eines relativen Pfads im Standardlizenzverzeichnis installiert werden:

Oft enthalten Paketquellen Dokumentationen, die auch für Endbenutzer nützlich sein können. Diese können installiert und mit der Direktive %doc als Dokumentation gekennzeichnet werden. Ähnlich wie bei %license können relative Pfade verwendet werden, um Dateien direkt aus dem Quellcode-Archiv anstatt aus dem Buildroot einzubinden:

Dateien auflisten, die im Paket enthalten sind:

Sie können sehen, dass alle im Abschnitt %files der Spec-Datei aufgeführten Dateien eingebunden sind. Unter /usr/lib/.build-id befindet sich außerdem eine automatisch generierte Datei. Dabei handelt es sich um einen symbolischen Link, der eine Build-ID der Binärdatei banner zu Debugging-Zwecken zuordnet.

Listen Sie die Laufzeitabhängigkeiten des Pakets mit folgendem Befehl auf:

Um zu überprüfen, welche Pakete in den Fedora-Paketquellen diese Abhängigkeiten bereitstellen, können Sie dnf repoquery verwenden:

Sie werden feststellen, dass glibc die einzige Abhängigkeit von banner ist, welches Symbole in libc.so.6 sowie rtld(GNU_HASH) bereitstellt.

Die rpmlib-Abhängigkeiten sind speziell. Sie geben verschiedene rpm-Funktionen an, die im rpm-Paket selbst verwendet werden, und schränken die Version von rpm ein, die zur Installation des Pakets verwendet werden kann.

Umgekehrt können Sie, um zu überprüfen, was das Paket bereitstellt, Folgendes tun:

Die „Provides“ dieses Pakets sind sehr einfach. Es stellt lediglich seinen eigenen Namen in allgemeiner und architekturspezifischer Form bereit.

Zur abschließenden Überprüfung kann das Paket installiert und ausgeführt werden:

Um Ihr System zu bereinigen, machen Sie die Installation rückgängig: