Wiki » Paketbau für Anfänger-de

Andere Sprachen Deutsch ; English ; Español ; Français

Warum Pakete bauen?

Leute schreiben Software. Diese stellen sie häufig auf ihrer Webseite zur Verfügung und erklären den Nutzer, wie diese kompiliert wird. Manchmal bekommen einige Programme später weitere Funktionen (welche zusätzliche Abhängigkeiten voraussetzen) was das verstehen und durchführen der Kompilierung auf dem bisherigen Weg deutlich schwerer macht. Hier kommen die Paketmaintainer ins Spiel. Bei einer binären Distribution packen wir das kompilierte Programm, splitten dieses manchmal in bestimmte Teile, bei optionalen Funktionen, auf, damit die Nutzer nur die benötigten Pakete installieren müssen und wenn die Arbeit richtig durchgeführt wurde funktioniert das Programm.

Pakete bauen ist keine einfache Arbeit und Pakete bieten die Anwendungen auf einem Weg an, der für die meisten Nutzer akzeptabel ist. Häufig sind die Pakete für eine spezifische GNU/Linux Distribution angepasst, was bedeutet dass es am besten ist, Pakete zu installieren welche für die verwendete Distribution gebaut worden sind.

Falls Sie mehr über den Paketbau und vielleicht wie Sie Ihre eigenen Anwendungen packen können wissen möchten lesen Sie weiter!

Paketbau verstehen

Allgemein gesagt: Paketbau ist die Automatisierung des Kompilierungs-Aufwand samt Verweis auf die Abhängigkeiten und was noch dazugehört. Kompilieren einer Anwendung und Zusammenführen mit einem Installationsscript und weiteren Informationen, welche für die Installation auf Ihrem System benötigt wird, ohne das man selbst ein "Softwarespezialist" sein muss.

Spezifischer Jargon

In alphabetischer Reihenfolge:

arch	Prozessorarchitektur, z.B.: i586 (32-Bit) oder x86_64 (64-Bit)
build	der Vorgang um ein source rpm (SRPM) Paket in ein installierbares RPM Paket zu konvertieren.
buildrequires	spec file keyword um die Pakete aufzuführen welche zum bauen des gewünschten Pakets benötigt werden. z.B. gtk libraries für Gnome Programme
dependencies	Abhängigkeiten - alle Pakete die benötigt werden um ein RPM Paket zu bauen (buildrequires) oder um ein installiertes RPM Paket zu starten (requires)
desktop file	ein Dateiformat das die Menüeinträge bestimmt
patch	eine Datei, welche alle Änderungen auflistet die für eine andere Datei oder andere Dateien durchgeführt wurden bestimmte auftretende Probleme zu beheben oder neue Funktionen hinzuzufügen
provides	spec file keyword für Funktionen die das RPM Paket mitbringt, häufig der Name von anderen (oft obsolete) RPM Pakete.
RPM	ein Paketformat (Herkunft: Redhat Package Manager, heute RPM package manager). Eine RPM Datei enthält alles was benötigt wird um die Software zu installieren. Diese hat den suffix .rpm.
requires	spec file keyword für andere Pakete oder Funktionen die benötigt werden damit das installierte RPM Paket einwandfrei funktioniert.
spec	die .spec Datei in der SRPM enthält Anweisungen wie das RPM Paket oder die RPM Pakete gebaut werden
SRPM oder src.rpm	source rpm package, welche nur die Quellen (sources) + Patches + die .spec Datei enthält. Diese wird dazu verwendet um eine oder mehrere installierbare RPM Dateien zu erstellen (bauen)
suggests	spec file keyword um zusätzliche Pakete aufzuführen die zur Installation mit dem aktuellen Paket vorgeschlagen werden
tarball	ein Archiv an Quellen. Diese werdem im 'tar' (tape archive) Format ausgeliefert
upstream	die aktuellen (normalerweiße die Original-) Entwickler, von dessen Software Sie das Paket bauen (oder deren Webseite)

Was befindet sich in einem RPM Paket?

Häufig eine Bibliothek und/oder ein Programm, etwas Dokumentation, gegebenenfalls manpages, etc...

z.B.

• /usr/lib64/libfoo.so
• /usr/bin/foo
• /usr/share/doc/foo/README
• /usr/share/man/man1/foo.1

Was befindet sich in einem SRPM Paket?

Ein SRPM ist häufig ein Tarball und eine specfile, gegebenenfalls mit Patches, manchmal mit zusätzlichen Dateien (z.B. Desktop Dateien oder Symbole)

z.B.

• SPECS/foo.spec
• SOURCES/foo-2.3.5.tar.bz2
• SOURCES/foo-2.3.5-path-to-fix-specific-bug.patch
• SOURCES/foo.desktop
• SOURCES/foo.png

Quick & Dirty: Wie man von einem SRPM zu einem RPM kommt

Eine SRPM ist der nicht kompilierte Programmcode (Sourcecode) und unabhängig von der Prozessorarchitektur, während RPMs kompilierte Binärpakete sind und zudem auch häufig architekturspezifisch.

rpmbuild --rebuild file.src.rpm

Es werden keine buildrequires (Pakete die zum Bau des Pakets benötigt werden) installiert. Diese müssen von Ihnen manuell installiert werden.

Nützliche Dinge die man wissen sollte

Eine RPM Datei sieht häufig folgendermaßen aus: foo-2.3.5-2.mga1.x86_64.rpm

• name: foo
• version: 2.3.5
• release: 2
• disttag: mga
• distrelease: 1
• arch: x86_64
• extension: rpm

Eine SRPM Datei sieht häufig folgendermaßen aus: foo-2.3.5-1.mga1.src.rpm

• name: foo
• version: 2.3.5
• release: 1
• disttag: mga
• distrelease: 1
• extension: src.rpm

(oder Sie können auch gedanklich arch durch "src" -> source ersetzen)

Ein Tarball von Upstream sieht häufig folgendermaßen aus: foo-2.3.5.tar.bz2

• name: foo
• version: 2.3.5
• extension: tar.bz2

Wie Sie sehen können wird der Name und die Versionsnummer direkt von "upstream" (der eigentlichen Programmquelle) übernommen, welche wir auch nicht modifizieren. release ist eine Nummer die mit 1 beginnt und erhöht wird sobald wir eine Aktualisierung mit der gleichen Versionsnummer veröffentlichen (z.B. foo-2.3.5-1 ; foo-2.3.5-2 ; foo-2.3.5-3 usw.).

Eine SRPM kann mehrere RPMs erstellen

Zum Beispiel kann das Paket foo-2.3.5-2.mga1.src.rpm folgende RPMs erstellen:

• foo-2.3.5-2.mga1.x86_64.rpm : das Hauptpaket mit den binären Daten
• lib64foo2-2.3.5-2.mga1.x86_64.rpm : ein Paket mit der benötigten Bibliothek
• foo-data-2.3.5-2.mga1.noarch.rpm : ein Paket (Architekur unabhängig) welche z.B. Daten wie Beispiel-Daten zur Verwendung für das Paket foo enthält
• foo-qt4-2.3.5-2.mga1.x86_64.rpm : ein optionales Paket für die Qt4 (KDE) Unterstützung
• foo-gtk-2.3.5-2.mga1.x86_64.rpm : ein optionales Paket für die GTK (GNOME) Unterstützung
• foo-devel-2.3.5-2.mga1.x86_64.rpm : Ein Paket welches z.B. Header-Dateien enthält (häufig können buildrequres von anderen Paketen in dieser Datei integriert werden)
• foo-debug-2.3.5-2.mga1.x86_64.rpm : ein automatisch generiertes Debug-Paket für foo

Beispiel A: Erstelle eine Umgebung für Ihr erstes RPM

Hier sind einige Vorschläge:

• Beginne einfach mit einem bestehenden Paket Ihrer aktuellen Distribution (zum Beispiel die neuste in Mageia verfügbare).
• Lass uns, z.B. 'TeXworks' nehmen, welches eine LaTeX IDE ist.

In diesem Abschnitt werden Sie folgendes tun können:

• überprüfen ob die Software bereits als Paket vorliegt
• eine funktionierende Paketbau Umgebung erhalten
• ein Pakete erstellen das (erfolgreich) gebaut wird
• etwas Verständnis bezüglich Paketbau-Abhängigkeiten und Voraussetzungen (verwenden von rpm, urpmq und verstehen der Verzeichnisstruktur) bekommen
• Erstellen einer lokale Umgebung für Ihre aktuelle Distribution um Software als Paket zu packen. Der nächste Schritt wäre das Paket überprüfen und einreichen zu lassen, damit Sie für später Zugriff auf das Build-System erhalten.

Vorläufige Aufgaben

Schaue bitte in diese Anleitung für einige vorläufige Aufgaben.

.rpm und src.rpm verstehen

Finde anhand des Anwendungsnamens "TeXworks" den RPM Name:

• entweder in rpmdrake (es gibt einen Suchbereich)
  • Sie sollten schnell herausfinden können, dass der Paketname texworks lautet
• oder durch verwenden von urpmq (oder rpm falls Sie es bereits installiert haben) um Pakete mit ähnlichem Namen zu finden:

urpmq -a -y TeX

• Falls Sie eine zu lange Liste an Paketen als Suchergebnisse zurückerhalten oder garkeine Suchergebnisse, verändern Sie die Suchanfrage so, dass dieses präziser ausfällt, oder etwas umfassender:

urpmq -a -y works

Es sollte Ihnen dann möglich sein die src.rpm Datei zu finden:

• entweder in rpmdrake falls Sie die src Repositorys konfiguriert haben
• oder durch eingeben von

  urpmq -i texworks

  in einem Terminalfenster. Das verwenden der Befehlszeile ist nicht so schwer wie es klingt und Sie können die Befehle aus diesem How-To kopieren-und-einfügen um es Ihnen leichter zu machen
  • Nehmen wir an Sie haben die folgende Source RPM gefunden : texworks-0.4.5-1.mga4.src.rpm

Erstellen Sie Ihre Paketumgebung

Falls Sie versuche ein Paket welches in C geschrieben wurde neu zu bauen, müssen Sie hierfür das task-c-devel Paket installieren. Falls Ihr Paket in C++ geschrieben wurde, müssen Sie das Paket task-c++-devel installieren. Durch das installieren der Pakete werden eine bestimmte Anzahl an zusätzlichen Paketen mitinstalliert.

Installiere das Paket rpm-build:

[root@localhost ~]# urpmi rpm-build

Dies sollte einen Bündel an Abhängigkeiten mitinstallieren, welches per "J" oder "Y" bestätigt werden sollte, damit diese installiert werden.

Sie können auch bm für ein nutzerfreundlicheren Build-Manager installieren.

Erstelle nun die Verzeichnisstruktur:

mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}

Später, wenn das Source-Paket (.src.rpm) oder ein Paket gebaut wird installiert wird, werden weitere Verzeichnisse wie BUILD, BUILDROOT und RPM erstellt.

Verstehen der Verzeichnisstruktur

Nachdem Sie nun den Namen der src.rpm haben, können Sie diesen von einem der Repositorys herunterladen:

cd ~/rpmbuild/SRPMS

wget ftp://ftp.mirrorservice.org/pub/mageia/distrib/cauldron/SRPMS/core/release/texworks-0.4.5-1.mga4.src.rpm

rpm -ivh texworks-0.4.5-1.mga4.src.rpm

Warnung, es installiert die binären Daten nicht wirklich; es entpackt die spec/tarbal+patch in das entsprechende Verzeichnis.

Installieren von Bau-Abhängigkeiten (build dependencies)

Die meisten Pakete sind von anderen Paketen in gewisser Weise abhängig. Um ein Paket zu kompilieren müssen Sie die benötigten abhängigen Pakete installiert haben. In den meisten Fällen besitzen die abhängigen Pakete den Suffix -devel, welche diese als 'Entwickler' Version der Pakete kennzeichnet. Falls ein benötigtes Paket nicht installiert ist, erhalten Sie beim (Neu-)Bau der Pakete eine Fehlermeldung die anzeigt weshalb dies fehlschlug. In den meisten Fällen wird Ihnen die Fehlermeldung genau mitteilen, welche abhängigen Pakete fehlen, jedoch kann manchmal die Fehlermeldung ziemlich kryptisch sein. Zum Glück ist es sehr einfach die ganzen benötigten Pakete zu installieren.

cd ~/rpmbuild/SPECS
su -c 'urpmi texworks.spec'

Ein alternativer Weg ist den Befehl sudo anstatt su -c zu verwenden. Überprüfen Sie anhand der Anleitung Sudo einrichten, dass sudo installiert und eingerichtet ist.

cd ~/rpmbuild/SPECS
/usr/bin/sudo urpmi texworks.spec

(Neu-)Bau Ihrer src.rpm um eine rpm für Ihre Architektur zu erstellen

cd ~/rpmbuild/SPECS
rpmbuild -ba texworks.spec

Überprüfe ~/rpmbuild/RPMS/i586 (oder x86_64 abhängig von Ihrer Architektur): Hier finden Sie Ihre erstellten Pakete.

 bm -l 

baut auch Ihr Paket erneut wenn Sie sich im Verzeichnis befinden in dem die Quelldateien liegen.

Beispiel B: Aktualisieren einer bestehenden RPM auf die neuste Version

Finde die aktuellste Version Ihrer Software

Lass uns das Beispiel von oben nehmen

• urpmq -i texworks # zeigt eine Zeile

  URL        : http://www.tug.org/texworks/

• schau nach der letzte (stabil) verfügbaren Version, die Webseite zeigt Version 0.4.X?

Übernimm diese neue Version in Ihr System, baue

Aus dem vorherigen Abschnitt haben Sie bereits

• eine .spec
• eine tarfile
• eventuelle einige Patches (überprüfe dass diese upstream gemeldet wurden)
• (Verzeichnis mit weiteren Details und Inhalte mit weiteren Erklärungen)

Um fortzufahren,

• mache nur die dementsprechenden Änderungen (aktualisiere die Versionsnummer und Paketversion in der spec Datei, ersetzte tarball mit der neusten Version im SOURCES Verzeichnis)
• und versuche das Paket erneut mit der neusten Version zu bauen, solange keine Fehler- oder Warnmeldungen erscheinen, während dieser gebaut wird
• aktualisiere danach die .spec Datei und führe

  rpmbuild -ba texworks.spec

  aus, bis die RPM Datei erstellt wurde
• vergiss nicht eine Testinstallation durchzuführen und zu testen, dass das alles funktioniert!

Zurück zum Paketbau-Team Informationsportal