|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| {{lang|en|page=How_to_create_a_GNU_Hello_RPM_package}} | | {{lang|en|page=How_to_create_a_GNU_Hello_RPM_package}} |
|
| |
| == 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)/
| |
| 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 bei''GNU 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.
| |
|
| |
| [[File:Rpmbuild-ablauf-diagramm.svg|thumb|left|Ü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.
| |
