How to create a GNU Hello RPM package/de

https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de

Click here to set up this language box

Einleitung

Der Artikel beschreibt exemplarisch an Hand eines "Hallo-Welt"-Projekts wie der Weg zu einem RPM ist.

Vorbereitung

Für die folgenden Schritte werden volgende Tools benötigt.

• GNU Make
• rpmbuild
• Ein Editor

Wie die die Software-Pakte der oben genannten Tools heißen ist Distrebutionsabhängig.

Erstellen des eigentlichen Programms

Zunächst das (Beispiel-)Programm. Es handelt sich in unserem Falle um ein Bash-Skript das aus einer einzigen Zeile Code besteht (Die erste Zeile bestimmt nur den Interpreter):

 #!/bin/bash
 echo "Hallo whoami";

Was tut dieses Programm? Beim Aufruf Gibt es einfach nur "Hallo" aus, gefolgt von dem Loginnahmen, der Person, die es aufruft. Das ist - zugegeben - wenig Sinn anstiftend aber für unseren Zweck reicht es.

Das Skript speichern wir in die Datei "rpm-uebung.sh". Diese Datei speichern wir - der Ordnung halber in das Verzeichnis "/src". "src" steht für Source-Code. Diesen Ordner, speichern wir in einem Projektordner. So das unsere Struktur (bisher) so aussieht:

• rpm-uebung
  • src
    • rpm-uebung.sh

Warum ein Makefile?

In aller Regel wird in Unix- und Linux-Umgebungen gern und viel mit Makefiles gearbeitet. Das macht Sinn! Denn es abstrahiert den Umgang mit dem Programm. In der Regel ist Derjenige, der das Programm installiert nicht der selbe der das Programm programmiert. Die Idee hinter Makefiles ist, das der User nicht viel wissen muss über das Programm um es installieren zu können. Makefiles sind auch nur Skripte die etwas automatisch tun. Die Konvention ist, das der Benutzer erwarten darf, das es mindestens zwei Befehle gibt, die ihm zur Verfügung stehen:

 make

und

 make install

Der Benutzer erwartet, das der erste Befehl das Programm zusammenbaut und zweite, es auf seinem System installiert.

Darüber hinaus kann man GNU Make so einrichten das es Beliebige Parameter akzeptiert und dann definierte Aktionen ausführt. Zum Beispiel ein RPM erstellt. Und das ist der Grund, warum wir rpmbuild (das Tool zum erstellen von rpms) nicht direkt aufrufen, sondern über GNU Make. Wir versuchen die Komplexität vor dem User zu verstecken, in dem wir ihm eine definierte Schnittstellen geben. So muss er die Feinheiten von rpmbuild nicht verstehen.

Für Fedora-Maintainer sieht die Situation anders aus. Doch bevor eine Software von einem Maintainer betreut wird, muss sich in der Regel der Entwickler bzw. der User mit dem RPM-Bau rumschlagen.

Makefile erstellen

Zunächst legen wir eine neues Makefile an in unserem Projektordner. So das Unsere Struktur so aussieht:

• rpm-uebung
  • src
    • rpm-uebung.sh
  • Makefile

Zunächst der Komplette Inhalt als Übersicht und zum kopieren (Ganz wichtig! Die Einrückungen müssen Tabs sein und dürfen keine leerzeichen sein. Sonst wird GNU Make die Arbeit verweigern):

 PREFIX=
 RPM_ROOT=~/rpmbuild
 RPM_BOUILD_ENV= $(RPM_ROOT)/BUILD $(RPM_ROOT)/RPMS $(RPM_ROOT)/SOURCES $(RPM_ROOT)/SPECS $(RPM_ROOT)/SRPMS
 RPM_SOURCES=$(RPM_ROOT)/SOURCES
 VERSION=1
 PROGNAME=rpm-uebung
 ARCHIV=$(PROGNAME)-$(VERSION).tar.gz
 
 make:
  
 install:
       [ -d $(PREFIX)/usr/bin/ ] || mkdir -p $(PREFIX)/usr/bin/
       cp ./src/$(PROGNAME).sh $(PREFIX)/usr/bin/
       chmod uoa+x $(PREFIX)/usr/bin/$(PROGNAME).sh
 
 dist-tar:
       [ -d ./$(PROGNAME)-$(VERSION) ] ||  mkdir ./$(PROGNAME)-$(VERSION) 
       cp -r ./src ./$(PROGNAME)-$(VERSION)/src/
       cp ./Makefile ./$(PROGNAME)-$(VERSION)
       tar -cvzf $(ARCHIV) ./$(PROGNAME)-$(VERSION)
       rm -rvf ./rpm-uebung-$(VERSION)
 
 rpm-init:
       [ -d $(RPM_ROOT) ] || mkdir $(RPM_ROOT) ; mkdir $(RPM_BOUILD_ENV)
 
 pre-rpm: dist-tar
       cp ./$(ARCHIV) $(RPM_ROOT)/SOURCES
 
 dist-rpm: pre-rpm
       rpmbuild -ba --target=noarch $(PROGNAME).spec
 
 .PHONY: dist-rpm dist-tar install

Jetzt noch mal zur Struktur. Im ersten Teil werden verschiedene Variablen gesetzt. Variablen aus zwei Gründen:

• Zum einen, muss man deren Werde nur an einer Stelle ändern, falls sie geändert werden müssen. Und es ist zu erwarten, das sie sich ändern. So zum Beispiel die Versionsnummer.
• Zum anderen kann man beiGNU Make über Parameter die Variablen setzen. Diese Eigenschaft werden wir später im Wechselspiel mit dem rpmbuild-tool brauchen.

Der zweite Teil sind die Definitionen der Kommandos die GNU Make kennen und ausführen können soll. Der Komando-Name steht immer links, am Anfang der Zeile und Endet mit einem Doppelpunkt. Alle darauf folgenden Zeilen, mit einem Tab eingerückt werden sind dann die Schritte die bei dem Befehlsaufruf abgearbeitet werden.

Bei manchen Befehlsdefinitionen, steht noch ein Wort dahinter. So zum Beispiel in der Zeile...

 pre-rpm: dist-tar

Das sind Bedingungen oder Abhängigkeiten. Hier wird zum Beispiel GNU Make gesagt, das bevor der Befehl pre-rpm abgearbeitet wird, noch der Befehl dist-rpm abgearbeitet werden muss.

Die letzte Zeile definiert, welche Funktionen/Befehle nach Außen sichtbar bzw. über Parameter aufrufbar sind.

Oben haben wir schon gesagt, das vom Benutzer in der Regel erwartet wird das der Befehl...

 make  

...unterstützt wird. In unserem Fall gibt es aber nichts zu übersetzen. Unser Skript ist fertig benutzbar. Deshalb ist da auch nichts definiert. Anders sieht es mit dem Befehl...

 make install

...aus. Hier kopieren wir unser Skript die richtige stelle in das System. Die Variable $(PREFIX) kommt hier in Spiel. Die ist für uns wichtig, mit wir später das rpm ohne root-Rechte bauen können. Oder mit der Benutzer, das Skript an eine Stelle installieren kann, wo er es lieber hat. Das macht er dann so...

 make PREFIX=opt install 

...in diesem Fall würde das Skript nach /opt/usr/bin/ installiert werden. Soweit erst mal. Auf die anderen Teile kommen wir noch zu sprechen.

Der RPM-Bau (Spec-File)

Jetzt kommen wir zum eigentlich RPM-Bau. Das wird ein recht komplexes Zusammenspiel zwischen GNU Make und rpmbuild. Man könnte natürlich auch völlig ohne Makefile arbeiten. Oder GNU Make und rpmbuild völlig getrennt benutzen. Nur hat das Nachteile:

• Keine einheitliche leicht benutzbare Schnittstelle für den Benutzer.
• Redundante Daten (Informationen müssen in zwei Dateien gepflegt werden)

Zunächst das Spec-Fiel in der Übersicht zund zum kopieren:

 BuildRoot: %(echo $HOME)/rpmbuild/
 Summary: GNU rpm-uebung
 License: GPL
 Name: rpm-uebung
 Version: 1
 Release: 1
 Source: rpm-uebung-1.tar.gz
 Group:  Development/Tools
 
 %description
 create a Hello RPM.
 
 %prep
 %setup -q
 
 %build
 make PREFIX=$RPM_BUILD_ROOT pre-rpm
 
 %install
 rm -rf $RPM_BUILD_ROOT
 make PREFIX=$RPM_BUILD_ROOT install
 
 %files
 %defattr(0755,root,root)
 /usr/bin/rpm-uebung.sh

...Der Aufbau ist syntaktisch völlig anders. Am Anfang stehen wieder die Definition von Variablen. Hier ist das ":" eine Zuweisung und keine Bedingung wie bei GNU Make. Die Variablen Namen und Bedeutungen sind hier Fix gesetzt.

Bevor ich ins Detail gehe, speichern wir die Datei als "rpm-uebung.spec". Unser Verzeichnis sollte nun so aussehen:

• rpm-uebung
  • src
    • rpm-uebung.sh
  • Makefiles
  • rpm-uebung.spec

Noch mal ins Detail...

 BuildRoot: %(echo $HOME)/rpmbuild/

Das ist das Verzeichnis, was die Build-Umgebung beherbergt.

 Summary: GNU rpm-uebung

Kurze Zusammenfassung was das für ein Programm ist.

 License: GPL

Klar, die Lizenz.

 Name: rpm-uebung

Der Name unseres Programms.

 Version: 1
 Release: 1

Die Versions- und Release-Nummer

 Source: rpm-uebung-1.tar.gz

Dies ist der Name den das Tar-File hat, das rpmbuild benutzen soll.

 Group:  Development/Tools

Die Software-Gruppe. Gut, für unseren Fall gibt es hier kein wirklich sinnvollen Wehr.

 %description
 create a Hello RPM.

Hier kommt die etwas ausführliche Beschreibung (die bei uns aber nicht sehr ausführlich ist). Dann folgen die Regeln für den Build und die Installation, auf die wir gleich im Detail eingehen.

%files %defattr(0755,root,root) /usr/bin/rpm-uebung.sh

In den letzten Zeilen wird festgehalten, welche Dateien bei der Installation angelegt werden. Und (mit %defattr(0755,root,root)) wird festgelegt, welche Rechte die Dateien bekommen. Da es sich um eine Ausführbare Datei handelt, muss es 0755 sein.

An dieser Stelle ein kurzer Zwischenstopp für eine Übersicht.

Übersicht über die Interaktionen der beiden Tools GNU Make und rpmbuild.

Erläuterung:

Der User ruft dem Befehl "make dist-rpm" auf und dann folgt eine reihe gegenseitiger zum Teil parametrisierter aufrufe, die dem User zum Glück verborgen bleiben...

 rpmbuild -ba --target=noarch $(PROGNAME).spec

...hier wird rpmbuid aufgerufen und der Name des Spec-File mitgegeben und mitgeteilt das es sich um ein Paket ohne Architekturabhängigkeiten handelt (noarch), da bash-Skripte unter allen Systemen laufen ohne neu übersetzt zu werden.

Im Spec-File geht es dann weiter...

 %build
 make PREFIX=$RPM_BUILD_ROOT pre-rpm

...Die Build-Sektion ruft ihrerseits wiederum das Makefile (bzw. make) auf und gibt ihm als Parameter das Verzeichnis mit, was rpmbuild benutzt um das rpm zu bauen. Das weiß make nicht von alleine.

Im Makefile wird dann - wie übergeben - die Funktion pre-rpm aufgerufen...

 pre-rpm: dist-tar
       cp ./$(ARCHIV) $(RPM_ROOT)/SOURCES

...Hier ist eine Abhängigkeit zu Funktion "dist-tar" definiert. Das ist auch der Grund, warum das Spec-File die Arbeit an Make delegiert! Weil man könnte es auch dort definieren, aber das wäre Redundant...

 dist-tar:
       [ -d ./$(PROGNAME)-$(VERSION) ] ||  mkdir ./$(PROGNAME)-$(VERSION) 
       cp -r ./src ./$(PROGNAME)-$(VERSION)/src/
       cp ./Makefile ./$(PROGNAME)-$(VERSION)
       tar -cvzf $(ARCHIV) ./$(PROGNAME)-$(VERSION)
       rm -rvf ./rpm-uebung-$(VERSION)

In dem Abschnitt wird überprüft ob es schon ein Verzeichnis gibt, das so heißt wie das Projekt. Das wird nämlich von rpmbuild so erwartet. Wenn nicht, wird es angelegt und mit allen nötigen Dateien befüllt. Dann wird ein Tar-Archiv daraus erstellt und die temporären Dateien wieder gelöscht.

Zurück in der Funktion "pre-rpm" wird das zuvor erstellte Tar-Archiv in die Build-Umgebung in das Verzeichnis "SOURCES" verschoben.

Im Speck-File wird dann die Funktion "%install" aufgerufen, die wiederum die die Makefile-Funktion "install" parametrisiert aufruft...

 make PREFIX=$RPM_BUILD_ROOT install

Wird dem make nicht der Prefix übergeben, würde das Skript versuchen tatsächlich das Programm im System zu installieren. Das schlägt ohme root-Rechte fehl. Mit root-Rechten wäre das Programm am rpm-System vorbeiinstaliert worden. rpmbuild muss die Installation ein mal ausgeführt haben um zu überprüfen, welche Dateien tatsächlich wo in System hinein kopiert werden.

Wenn nichts schief gelaufen ist, sollte jetzt ein installierbares rpm-Paket da sein und zwar im Verzeichnis /RPMS unterhalb der rpm-Build-Umgebung, die auf jedem System wo anders sein kann.