NAS-Speicher mit einer Kapazität von einigen Dutzend Terabyte, wie sie sich für mittelständische Anwender eignen, nimmt die ADMIN-Redaktion in der Ausgabe ... (mehr)

Ran an den Spec

Wer auf Fedora Linux mit dem Vim-Editor eine Datei mit der Endung ».spec« öffnet, hat es einfach, denn er bekommt ein leeres Template für Spec-Dateien präsentiert ( Abbildung 1 ). Zur Veranschaulichung soll im Folgenden zunächst ein RPM-Paket für ein selbst geschriebenes Python-Tool entstehen, das aus einem Skript, einer Glade-Datei für die GUI und einer Konfigurationsdatei besteht. Nach der Installation des Pakets sollen die Dateien an folgenden Stellen auf dem Dateisystem liegen.

Abbildung 1: Praktisch: Unter Fedora bringt der Vim-Editor ein Template für Spec-Files mit.
/etc/encoder.cfg
/usr/bin/encoder-gui
/usr/share/encoder/encoder-gui.glade

Wer dies nachmachen möchte, kann dazu einfach beliebige Dateien verwenden und entsprechend benennen.

Der »Name« (erste Zeile der Spec-Datei) soll »encoder« lauten, die »Version« ist »1.0« . Die darauf folgende Release-Zahl ist spezifisch für das RPM-Paket und soll dazu dienen, dass es für ein und dieselbe Upstream-Version einer Software mehrere RPMs geben kann, etwa für distributionsspezifische Updates. Die »Summary« gibt eine kurze Beschreibung der Software, dann folgt die Anwendungsgruppe, in die sie eingeordnet werden soll. Im Beispiel soll es »Applications/Multimedia« sein, da es sich um einen einfachen Video-Encoder handelt. Listen existierender Gruppen für Fedora und Open Suse finden sich unter [6] und [7] . Dann folgen die Lizenz und eine URL für das zu paketierende Projekt.

Interessanter wird es beim Eintrag »Source0« . Hierher gehört meistens ein Tar-Paket, in dem sich der Quellcode des Programms verbirgt und das das Build-Skript im Verzeichnis »SOURCES« erwartet. Im Beispiel ist es die Datei »encoder-1.0.tar.gz« , die folgende Dateien enthält:

$ tar tfz encoder-1.0.tar.gz
encoder-1.0/
encoder-1.0/encoder.cfg
encoder-1.0/encoder-gui.glade
encoder-1.0/encoder-gui

Der vorgegebene Eintrag »BuildRequires« wird im Beispiel gelöscht, denn eine Übersetzung des Programms findet nicht statt, also gibt es dafür auch keine Voraussetzungen. Üblicherweise werden hier sonst Pakete aufgeführt, die vorhanden sein müssen, damit die Übersetzung klappt, also Entwicklungspakete mit Header-Dateien und so weiter.

Das Feld »Requires« gibt dagegen Pakete an, die vorhanden sein müssen, damit das installierte Programm starten kann. Fürs Erste soll es hier keine Voraussetzungen geben, also löschen Sie auch dieses Feld, damit es keine Fehlermeldung gibt. Die Architektur ist bei plattformübergreifenden Skripts wie Python als »noarch« zu kennzeichnen. Unterhalb des Makros »%description« sollten Sie noch eine ausführlichere Beschreibung einfügen.

Dann folgen die Stufen des eigentlichen Paketbaus: Prepare, Build, Install und Clean mit ihren jeweiligen Makros. Für das einfache Beispiel können die Phasen »%prep« und »%build« leer bleiben, man könnte aber beispielsweise hier Variablen und Pfade in Skripten ersetzen. An dieser Stelle lassen sich die Syntax der Spec-Datei und die Prepare-Phase mit dem Befehl »rpmbuild -bp« testen:

rpmbuild -bp rpmbuild/SPECS/encoder.spec

Ohne Fehlermeldung mit Error 0 beendet, hat das Spec-File den Test bestanden ( Abbildung 2 )

Abbildung 2: Der Befehl

In der Install-Phase simuliert das RPM-Build-Tool eine Installation im sogenannten Build-Root, das für diesen Zweck die Wurzel des Dateisystems darstellt. Bei der "echten" Installation des fertigen RPMs wandern die enthaltenen Dateien an die entsprechenden Orte im Dateisystem.

Vor dem simulierten Installationsprozess löscht der Befehl »rm -rf $RPM_BUILD_ROOT« sicherheitshalber die alten Dateien. Üblicherweise wird über die Spec-Datei danach nur »make install« aufgerufen, was die nötigen Unterverzeichnisse erstellt. Das einfache Beispiel führt alle nötigen Befehle stattdessen direkt im Spec-File auf: Erst werden die nötigen Verzeichnisse angelegt, dann die drei enthaltenen Dateien an ihren Bestimmungsort kopiert. Auch das Clean-Makro entfernt anschließen wieder das Build-Root. Abschließend müssen Sie beim Makro »%files« noch alle Dateien auflisten, die letztlich im RPM enthalten sein sollen. Listing 2 zeigt ausschnittweise die wichtigsten Einträge im Spec-File.

Listing 2

encoder.spec

 

Den Bau des RPM-Pakets startet nun der Aufruf »rpmbuild -ba« beziehungsweise »rpmbuild -bb« . Der Unterschied besteht darin, dass die erste Variante alle ( »a« ) Pakete baut, das heißt das Binärpaket und das Source-RPM (SRPM), während der zweite Aufruf sich auf das Binärpaket beschränkt ( »b« ). Den erfolgreichen Ablauf zeigt Abbildung 3 . Als Ergebnis finden sich die beiden Dateien »~/rpmbuild/SRPMS/encoder-1.0-1.fc16.src.rpm« und »~/rpmbuild/RPMS/noarch/encoder-1.0-1.fc16.noarch.rpm« . Letztere lässt sich mit »rpm -i« wie gewohnt installieren.

Abbildung 3: Der Befehl

Abhängig

In der Praxis ist es oft etwas komplizierter, zum Beispiel, wenn das Skript Abhängigkeiten von anderen Paketen besitzt. So verwendet der oben paketierte Video-Encoder zum Parsen von XML das Elementtree-Modul [8] . Diese Abhängigkeit lässt sich im Spec-Datei über die folgende Zeile festlegen:

Requires: elementtree

Baut man nun das Encoder-Paket neu und versucht es zu installieren, quittiert RPM das mit einer Fehlermeldung über das fehlende Elementtree-Paket. Das wiederum fehlt im Fedora-Repository und ist somit ein Kandidat für ein weiteres RPM-Projekt. Per Wget lässt sich das Quellcodepaket gleich im passenden Verzeichns herunterladen:

cd rpmbuild/SOURCES
wget http://effbot.org/media/downloads/elementtree-1.2.6-20050316.tar.gz

In »rpmbuild/SPECS« editieren Sie dann die Datei »elementtree.spec« . Wie gehabt füllen Sie die einzelnen Felder für Name und so weiter aus. Die Version ist hier die Upstream-Version von Elementtree, also 1.2.6. Als »Source0« geben Sie die Datei »elementtree-1.2.6-20050316.tar.gz« an. Wenn Sie nun »rpmbuild -bp« aufrufen, bekommen Sie eine Fehlermeldung, denn das Tool findet das Verzeichnis der entpackten Dateien nicht. Standardmäßig erwartet es, entsprechend dem Projektnamen und der Versionsnummer, das Verzeichnis »elementtree-1.2.6« , aber das entpackte Verzeichnis heißt »elementtree-1.2.6-20050316« . Damit alles funktioniert, übergeben Sie dem Setup-Makro den richtigen Verzeichnisnamen:

%setup -q -n elementtree-1.2.6-20050316

Auch der Build-Abschnitt lässt sich dieses Mal sinnvoll nutzen, denn mit den Python-Distutils gebaute Module können mit »python setup.py config« konfiguriert werden. Damit ersetzen Sie das im Template vorgegebene »%configure« -Makro und löschen die Zeile mit »make« . Schließlich ist es in diesem Fall auch nicht nötig, die Dateien von Hand zu kopieren, dies übernimmt ein Aufruf von »python setup.py install« , hinter dem aber noch ein Parameter folgen muss, der das Build-Root angibt:

python setup.py install --root %{buildroot}

Die im RPM enthaltenen Dateien können beim Files-Makro dieses Mal mit einer Wildcard angegeben werden:

/usr/lib/python2.7/site-packages/*

Wer jetzt den Paketbau mit »rpmbuild -bb« startet, findet nur wenige Augenblicke später das RPM-Paket »elementtree-1.2.6-1.fc16.noarch.rpm« im Verzeichnis »~/rpmbuild/RPMS/noarch« . Das Spec-File dafür ist noch einmal in Listing 3 zu sehen.

Listing 3

elementtree.spec

 

Weil viele Python-Module die Distutils zur Konfiguration verwenden, lässt sich der eben beschriebene Weg dazu verwenden, RPM-Pakete aus ihnen zu bauen. In anderen Fällen müssen gegebenenfalls nur die Aufrufe zur Konfiguration und Übersetzung angepasst werden.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023