AA_grundriss_14789983_123rf_Golkin_Oleg.jpg

© Golkin Oleg, 123rf.com

Baumeister

RPM-Pakete ohne Vorlage selbst erstellen

21.06.2013
Der Prozess, mit dem Distributoren bestehende Pakete auf eine neue Software-Version heben, erlaubt auch dem Normalanwender den unkomplizierten Bau eigener Pakete.

Ist das neue Programm erst einmal kompiliert, kann man es meist kaum noch erwarten, make install auszuführen und die Anwendung endlich zu starten. Doch dieser Aufruf als Root ist gefährlich: Er überschreibt ohne Vorwarnung Dateien. Der Aufruf make uninstall ist oft gar nicht implementiert – und wenn doch, löscht er die installierten Dateien, ohne eventuell vorher überschriebene Versionen wiederherzustellen.

Sicherer ist es, auch für selbst kompilierte Software Pakete zu erstellen und diese über das systemweite Paketmanagement zu installieren. Viele Anwender schrecken vor dem zusätzlichen Aufwand zurück. Doch ein Blick auf die Arbeitsweise der Distributoren, die für jedes Release Tausende Pakete neu bauen, zeigt, dass in vielen Fällen viel weniger Arbeit dahinter steckt als erwartet.

Baumaschine

Gentoo, bei dem der Paketmanager Portage jedes Softwarepaket vollautomatisch auf dem Rechner des Anwenders kompiliert, besitzt genau genommen kein Alleinstellungsmerkmal: Sowohl in der RPM- als auch in der Debian-Welt gehört ein leistungsfähiges Build-System zur Standardausstattung, die das Kompilieren und Verpacken von Programmen in ein Paket automatisiert (Abbildung 1).

Abbildung 1: Für die meisten Anwender ist RPM ein Synonym für Binär-RPMs, die Anwendungen und andere Systemkomponenten installationsfertig verpacken. Das ausgeklügelte System aus SRC-RPMs und Rpmbuild kennen dagegen selbst viele Power-User nicht.

SRC-RPMs (Dateiendung .src.rpm) bilden die Basis für das RPM-Build-System. Anders als Binär-RPMs enthalten sie keine ausführbaren Dateien, sondern den Quellcode eines Programms samt dem "Rezept" zum kompilieren. Um ein SRC-RPM in ein normales RPM umzuwandeln, genügt daher der Aufruf:

$ rpm --rebuild Paket.src.rpm

Dieser Befehl stößt das Kompilieren aus den Quellen an und verpackt die entstanden Programmdateien in ein Binär-RPM. Das dazu erforderliche Rpmbuild-Programm finden Sie unter OpenSuse im Paket rpm-build. Unter Fedora installieren Sie die Gruppe @development-tools sowie das Paket fedora-packager.

TIPP

Das Debian-Pendant zu SRC-RPMs bietet einen ähnlichen Leistungsumfang, die Bedienung fällt jedoch grundlegend anders aus. Ihr widmet sich der zweite Teil dieser Artikelserie im nächsten Heft.

Transportabler Container

Schon der GPL wegen stellen die Distributionen jedem Binär-Repository dessen Quellcode-Pendant zur Seite. Wenn Sie dieses im Paketmanager aktivieren, lädt yumdownloader --source Paket unter Fedora ein Quellcode-RPM für das genannte Programm herunter. Für OpenSuse finden Sie die SRC-RPMs in der Online-Paketsuche [1] des Build-Service nach einem Klick auf Show other Versions.

Der Aufruf rpm --rebuild Paket.src.rpm erzeugt aus dem SRC-RPM ein zum offiziellen Distributionspaket identisches Binär-RPM. Liegt Ihnen lediglich ein SRC-RPM für eine andere Version der von Ihnen genutzten Distribution vor, lohnt sich der Rpmbuild-Durchlauf ganz besonders: Quelltext-RPMs sind deutlich weniger an eine bestimmte Distributionsversion gebunden als Binärpakete (siehe Kasten "Programmpakete und Abhängigkeiten").

Beim ersten Aufruf fehlen meist noch einige Devel-Pakete (Abbildung 2). Nach deren Einrichten erzeugt ein erneuter Aufruf des Befehls ein auf Ihr System zugeschnittenes Binary. Dabei laufen neben wenigen zum Paketbau gehörigen Meldungen auch solche über den Bildschirm, die Sie beim Aufruf von make zu sehen bekämen.

Abbildung 2: Bevor rpm --rebuild den Quellcode kompiliert und in ein installationsfertiges Binär-RPM verpackt, prüft das Tool, ob alle zum Kompilieren nötigen Devel-Pakete vorliegen.

Programmpakete und Abhängigkeiten

Jede der unüberschaubar vielen Linux-Distributionen enthält andere Versionen der gängigen Bibliotheken. Kompilierte Programme – also auch Binär-RPMs – funktionieren oft nur mit einer bestimmten Version dieser Hilfsprogramme, während beim Kompilieren eine neuere Version der Bibliothek meist keine Probleme bereitet.

Ein Blick in die Verzeichnisse /usr/lib/ oder /usr/lib64/ hilft zu verstehen, warum das so ist. Die meisten Dateien darin tragen einen Namen der Form libName.so.1.23. Wenn die Entwickler aus einer Bibliothek Funktionen entfernen oder deren Aufrufparameter verändern, stürzen Programme ab, die noch mit der alten Schnittstelle der Library rechnen. Das passiert oft nicht gleich beim Start, sondern erst beim Aufruf eines bestimmten Menüpunkts. Um solche unangenehmen Überraschungen zu verhindern, signalisieren die Entwickler nicht rückwärtskompatible Änderungen durch Erhöhen der zwei- oder dreistelligen Versionsnummer im Namen der Bibliothek.

Manchmal geht es dabei lediglich um kleine Anpassungen, die längst nicht alle Anwendungen betreffen. Ob ein Programm mit der neuen Bibliotheksversion zusammenarbeitet, zeigt aber erst das Kompilieren. RPMs speichern die Bibliotheksversionen (Soname, von "shared object name"), gegen die die enthaltenen Programme übersetzt sind, als Abhängigkeit. Die Distributionen übersetzen daher jedes Paket beim Update der Distribution neu aus dem Quellcode.

Auch als Anwender müssen Sie den Compiler bemühen, wenn kein passendes Paket vorliegt. Dafür bleibt ihnen die DLL-Hölle früherer Windows-Versionen erspart. Dass alle Programme gegen eine bestimmte Version der Hilfsprogramme kompiliert sind, spart unter Linux auch Plattenplatz und Arbeitsspeicher ein.

Ein eigenes Binär-RPM aus einen SRC-RPM zu kompilieren ist viel sicherer, als wegen der aktuellen Version eines Programms ein instabiles Repository einzubinden. Dabei zieht die Installation nämlich oft so viele Abhängigkeiten nach, dass dies unter Umständen einem Upgrade auf eine instabile Distributionsversion nahe kommt.

Scripted Reality

Ihr volles Potential geben SRC-RPMs (Abbildung 3) erst dann preis, wenn Sie sie auf dem System installieren. Wie bei gewöhnlichen RPMs erledigt dies der Aufruf rpm -i Paket.src.rpm – allerdings als normaler Anwender, nicht als Root. OpenSuse-Anwender installieren SRC-RPMs mit zypper source-install Paket direkt aus dem Online-Repository. Zypper spielt dabei auch gleich alle für das Kompilieren nötigen Devel-Pakete (BuildRequires) ein.

Abbildung 3: Ein SRC-RPM schnürt alle für den Paketbau erforderlichen Komponenten in eine Datei zusammen.

Das SRC-RPM-Paket enthält neben dem Quellcode und andere systemweit zu installierende Dateien. Dazu gehören neben Startmenü-Einträgen auch Patches, die vor dem Kompilieren Fehler im Quellcode bereinigen, sowie Spec-Dateien, die Name, Version, Beschreibung und Abhängigkeiten sowie die Befehle zum Kompilieren des Quellcodes enthalten. Wie Sie Patches selbst bauen, klärt der Kasten "Patches erstellen".

Patches erstellen

Wie Sie Änderungen am Quellcode eines Programms in einen Patch verpacken, zeigt Listing 1. Zunächst benennen Sie zunächst das Basisverzeichnis um (Zeile 1) und entpacken dann das unveränderte Quellcode-Archiv erneut. Im nächsten Schritt erzeugen Sie einen Patch für alle Änderungen (Zeile 2). Möchten Sie die Änderungen einzelner Dateien separat erfassen, dann rufen Sie Diff wie in Zeile 3 gezeigt auf.

Listing 1

$ mv galculator-2.0.1 galculator-2.0.1_changed
$ diff -ur galculator-2.0.1 galculator-2.0.1_changed > my.patch
$ diff -u galculator-2.0.1/fDatei galculator-2.0.1_changed/Datei

Beim ersten Installieren eines SRC-RPMs legt RPM in Ihrem Heimatverzeichnis das Verzeichnis rpmbuild inklusive der Unterverzeichnisse BUILD, BUILDROOT, RPMS, SOURCES, SPECS und SRPMS an. Unter SOURCES finden Sie die Tarballs und Patches mit dem Quellcode für alle installierten SRC-RPMs.

Die Spec-Dateien im Verzeichnis SPECS bündeln beschreibende Daten und Handlungsanweisungen für Rpmbuild, das daraus den Quellcode kompiliert und in ein Binär-RPM verpackt. Wenn Sie SRC-RPMs installieren, anstatt direkt binäre RPMs daraus zu bauen, können Sie die Spec-Dateien vor dem Rpmbuild-Aufruf mit einem Texteditor verändern. Der folgende Aufruf erzeugt schließlich ein Binär-RPM:

$ rpmbuild -bb Name.spec

Alle im Spec referenzierten Quellcode-Archive und Patches müssen dabei unter SOURCES bereitliegen.

Dreh- und Angelpunkt

Als einfaches Beispiel für das Update einer Spec-Datei auf eine neue Version des enthaltenen Programms eignet sich die Taschenrechner-Software Galculator [2] unter OpenSuse 12.2. Auf anderen RPM-basierten Linux-Distributionen fällt die Spec-Datei im Detail anders aus, doch das geschilderte Vorgehen lässt sich übertragen. OpenSuse 12.2 bringt Galculator 1.3.4 mit, doch inzwischen steht schon Version 2.0.1 bereit, die nun GTK3 benutzt und sich so besser in den aktuellen Gnome-Desktop einfügt.

Installieren Sie zuerst das bei OpenSuse mitgelieferte Quellpaket zu Galculator mit dem Aufruf zypper source-install galculator als normaler User. Dies überträgt die Datei gcalculator.spec nach rpmbuild/SPECS/ sowie die beiden Files galculator-1.3.4.tar.bz2 und galculator-ld_fix.diff nach rpmbuild/SOURCES/. Danach öffnen Sie galculator.spec in einem Texteditor (Listing 2).

Listing 2

Name:           galculator
Summary:        A GTK 2 based calculator
Version:        1.3.4
Release:        18.1.2
License:        GPL-2.0
Group:          System/GUI/GNOME
Url:            http://galculator.sourceforge.net/index.html
Source0:        %name-%version.tar.bz2
Patch0:         %name-ld_fix.diff
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
BuildRequires:  autoconf automake fdupes gcc gcc-c++ make
BuildRequires:  doxygen gtk2-devel intltool pkg-config
BuildRequires:  libglade2-devel update-desktop-files
BuildRequires:  libtool
%description
Galculator is a GTK 2 based calculator with ordinary notation/reverse
polish notation, [...]
%prep
%setup -q
%patch0
%build
autoreconf -fi
%configure
%__make %{?jobs:-j%{jobs}}
%install
%makeinstall
%suse_update_desktop_file -r %name GTK Utility Calculator
%find_lang %name
%fdupes -s %{buildroot}
%clean
%__rm -fr %buildroot
%if 0%{?suse_version} >= 1140
%post
%desktop_database_post
%icon_theme_cache_post
%postun
%desktop_database_postun
%icon_theme_cache_postun
%endif
%files -f %name.lang
%defattr(-,root,root)
%_bindir/%name
%_datadir/applications/*
%dir %_datadir/%name
%dir %_datadir/%name/glade
%_datadir/%name/glade/*.glade
%_mandir/man1/%name.1.gz
%_datadir/pixmaps/%name.*
%changelog
* Sat Oct  1 2011 xxxx@suse.com
- add libtool as buildrequire to make the spec file more reliable
* Sat Sep 17 2011 xxxxx@gmx.de
- added Patch0 (gcalculator-ld_fix.diff) to fix the build for factory
  (this patch requires a autoreconf call)
[...]

Die ersten 15 Zeilen von galculator.spec bilden einzeilige Felder in der Form Feldname: Feldinhalt. Die Zeilen 1 bis 7 liefern dem Paketmanagement elementare Daten wie Name, Version und Upstream-URL, Lizenz sowie eine kurze Beschreibung. In den Zeilen darunter folgen Informationen für Rpmbuild bestimmte Informationen.

Source0 nennt den Dateinamen des ersten (und hier einzigen) Quellcode-Archivs. Während des Rpmbuild-Ablaufs stehen eine Reihe von Makros zur Verfügung (%macroname, siehe Tabelle "Gängige RPM-Makros"). Die Anweisung %name-%version.tar.bz2 expandiert Rpmbuild mit Rückgriff auf die Datenfelder Name: und Version:. Bei den vorliegenden Daten ergibt das galculator-1.3.4.tar.bz2, also den Namen des Quellcode-Archivs im Verzeichnis SOURCES.

Gängige RPM-Makros

Makro Funktion
%{_bindir} Installationsverzeichnis für Binaries
%{_datadir} Verzeichnis /share
%{_libdir} Verzeichnis für Shared-Libraries
%{_mandir} Verzeichnis für Manpages

Beim Update auf Version 2.0.1 gilt es daher lediglich später das Feld Version: zu ändern. Dann sucht Rpmbuild nach galculator-2.0.1.tar.bz2, das sich im Verzeichnis SOURCES befinden muss.

In der Zeile darunter folgt noch ein Patch (Patch0:), der ein Problem mit dem Makefile beim Kompilieren unter OpenSuse behebt. Die %prep-Sektion wendet ihn nach dem Auspacken des Quellcodes mit %patch0 an. Beim Lesen von Patch-Dateien hilft die Unified Diff Notation [3].

BuildRoot: zeigt auf ein temporäres mit Anwenderrechten beschreibbares Verzeichnis, das die beim Kompilieren und Installieren mit make und make install erzeugten Dateien aufnimmt. Der Standardwert %{_tmppath}/%{name}-%{version}-build passt praktisch immer. Die folgenden BuildRequires:-Felder listen alle zum erfolgreichen Kompilieren von Galculator erforderlichen Pakete auf.

Etwas verwirrend: Mehrzeilige Datenfelder beginnen genau wie Makros mit dem Prozent-Zeichen. Die Tabelle "Datenfelder in Spec-Dateien" führt alle Fälle auf, in denen das Prozent-Zeichen für ein Datenfeld steht und nicht für ein Makro.

Datenfelder in Spec-Dateien

Datenfeld Beschreibung
%description mehrzeilige Beschreibung, Zeilenlänge <= 80 Zeichen.
%prep Shell-Befehle, die den Quellcode für den Aufruf von configure; make; make install vorbereiten. Dazu gehört zum Beispiel das Auspacken des Quellcode-Archivs. In vielen Fällen genügt das Makro setup -q.
%build Befehl(e) zum Kompilieren, typischerweise configure und make.
%check Tests nach dem Kompilieren ausführen, fehlt häufig.
%install Befehl zum Installieren des kompilierten Programms, allerdings relativ zum Buildroot-Verzeichnis. (~/rpmbuild/BUILDROOT/Paket.Version). Typischerweise make DESTDIR=%{buildroot} install, abkürzbar mit %makeinstall.
%clean Befehl zum Entfernen des Verzeichnisses Paket.Version im BUILDROOT. Geschieht automatisch, wenn das %clean-Feld fehlt.
%files Dateiliste für das Binärpaket.
%changelog Changelog für das Paket beziehungsweise die Spec-Datei.

Außer %description, das eine mehrzeilige Beschreibung für den Paketmanager enthält, sind für unsere Zwecke die Felder %prep, %buildund %install interessant, denn sie steuern das Kompilieren des Quellcodes. Hier stehen prinzipiell die gleichen Befehle, die Sie auch beim manuellen Kompilieren auf der Konsole ausführen würden.

Sancta Simplicitas

Das OpenSuse-Spec-File ersetzt beinahe alle Shell-Befehle für das Kompilieren des Quellcodes durch Makros. Vieles lässt sich für ein Paket vereinfachen, das immer noch funktioniert, allerdings nicht mehr die Qualitätsnorm für OpenSuse-Pakete erfüllt [4]. Listing 3 enthält daher eine simplere Fassung. Orientieren Sie sich an dieser, wenn Sie Ihre erste eigene Spec-Datei erstellen.

Listing 3

[bis inklusive %description-Block wie oben]
%prep
%setup -q
%patch0
%build
autoreconf -fi
%configure
make
%install
%makeinstall
%files
%{_bindir}/galculator
%{_datadir}*

Das Makro %setup -q in der Sektion %prep entpackt das Archiv und wechselt mit cd in das Quellcode-Verzeichnis. Der Autoconf-Aufruf unter %build ist ein ausgesprochener Sonderfall, bedingt durch Veränderungen am Makefile-Template in Patch0. %configure ruft ./configure auf, fügt jedoch eine Vielzahl von auf das OpenSuse-System abgestimmter Optionen hinzu. Wer die im Detail sehen möchte, kann sie in der RPM-Konfigurationsdatei /usr/lib/rpm/macros nachlesen.

Zum Kompilieren des Programms genügt das altbekannte make, %__make in der Suse-Originalversion expandiert schlicht zu /usr/bin/make. Die Make-Option %{?jobs:-j%{jobs}} sorgt dafür, dass dem Build-Prozess im Rechner-Cluster des OpenSuse-Build-Service eine angemessene Zahl an CPUs zur Verfügung stehen. Für lokale Builds ist sie nicht erforderlich.

Das %install-Feld enthält lediglich eine unverzichtbare Zeile: Jene mit %makeinstall, die den Konsolenbefehl make install vertritt. Dieser blanke Aufruf genügt beim Bauen von Paketen allerdings nicht. Der Befehl muss hier make DESTDIR=%{buildroot} install lauten, sonst versucht Make die Dateien an die für die endgültige Installation vorgesehenen Stellen zu schreiben, etwa nach /usr/bin/ oder /usr/share/, was mit User-Rechten fehlschlägt.

Das Setzen der Umgebungsvariablen DESTDIR weist make install an, die Dateien relativ zum dort genannten Verzeichnis zu installieren. %{buildroot} gibt ein für Paketnamen und -version eindeutiges Verzeichnis unterhalb von ~/rpmbuild/BUILD/ zurück, %makeinstall kürzt den Aufruf ab.

Die Abschnitte %post und %postun enthalten Makros, die der Paketmanager beim Installieren und Deinstallieren des Pakets ausführen soll. Bedingt durch das Makro %if 0%{?suse_version} >= 1140 aktualisieren sie im Beispiel die Startmenüs und den Icon-Cache für Suse-Versionen ab 11.4 – Feinheiten, die Anfänger ungestraft ignorieren dürfen.

Inhaltsverzeichnis

Das mehrzeilige Feld %files darf in keiner Spec-Datei fehlen, denn ohne es bleibt das binäre RPM leer: Rpmbuild packt beim Paketbau nur die dort zeilenweise gelisteten Dateien ein. Der *-Operator funktioniert dabei als Wildcard.

Die vereinfachte Version des %files-Felds benutzt nur die zwei Makros %{_bindir} (Verzeichnis für ausführbare Dateien) und %{_datadir} (share/-Verzeichnis), die passend zum mit %configure gesetzten Prefix zu usr/bin/ und usr/share/ unterhalb des per DESTDIR angegeben Pseudo-Root /home/~/rpmbuild/BUILDROOT/galculator-1.3.4-18.1.2.i386/ expandieren.

Die vereinfachte Dateiliste packt die Hauptprogrammdatei galculator und alle von make install unter share/ abgelegten Datei in das RPM-Paket. Das Original-Spec pickt gezielt die Unterverzeichnisse aus share/ heraus. Das ist im Hinblick auf Updates sicherer: Rpmbuild meldet dann neu hinzugekommene Dateien zunächst mit dem Fehler unpackaged files found. Der Maintainer kann prüfen, ob diese mit anderen Paketen in Konflikt stehen. Weitere Tricks zur %files-Sektion der OpenSuse-Spec-Datei erläutert ein englischsprachiger Artikel auf OpenSuse.org [5].

Einfacher als gedacht

Da Patches für eine bestimmte Version eines Programms geschrieben sind und die neuere Fassung die mit ihnen adressierten Fehler hoffentlich ohnehin beseitigt hat, sollten Sie zunächst einmal alle entsprechenden Zeilen mit einer Raute (#) auskommentieren.

Im Galculator-Spec betrifft dies die Zeilen 11 (Patch0: %name-ld_fix.diff), 24 (%patch0) sowie den Aufruf von autoreconf-fi in Zeile 27, der erst durch den Patch nötig wird, wie sich dem Changelog-Eintrag 2 entnehmen lässt.

Dass Galculator++2.0 jetzt GTK3 benutzt, lässt sich auf der als Upstream-URL in der Spec-Datei genannten Programm-Homepage nachlesen. Ändern Sie daher unter BuildRequires: die Abhängigkeit gtk2-devel nach gtk3-devel. Dann brauchen Sie nur noch das Version:-Feld auf 2.0.1 sowie die Release-Nummer für das Paket (Release:) auf 1.0.0 zu setzen und das Quellcode-Archiv galculator-2.0.1.tar.bz2 von der Projektseite in das Verzeichnis rpmbuild/SOURCES/ herunterzuladen.

Nun ist die Spec-Datei reif für den Aufruf rpmbuild -bb galculator.spec. Installieren Sie gegebenenfalls noch alle als Failed build dependencies angemahnten Pakete. Bei einem erneuten Aufruf von Rpmbuild signalisiert dann die Zeile Wrote: /home/user/rpmbuild/RPMS/i586/galculator-2.0.1-1.0.0.i586.rpm gegen Ende der Meldungen, dass ein RPM für Galculator 2.0.1 in Ihrem RPMS-Verzeichnis liegt (Abbildung 4).

Abbildung 4: Treffer! Rpmbuild hat ein Paket für Galculator 2.0.1 gebaut (rot) und die Abhängigkeiten dabei automatisch berechnet (blau). Auch der Check auf in %files übersehene Dateien war erfolgreich (keine Meldung, grün).

Schritt für Schritt

Nicht immer verläuft ein Update auf eine neue Programmversion so reibungslos wie beim Galculator-Beispiel, wo schon ein Auskommentieren der Patches und Anpassen des Version-Felds zum Erfolg führt. Für einen Fehlschlag gibt es die verschiedensten Ursachen: Oft stimmen die BuildRequires nicht mehr, manchmal ändern sich die Optionen für configure. Dass die %files-Liste in unserem Beispiel trotz Major-Versionssprung noch zutrifft, ist eher die Ausnahme.

Wenn es Ihnen aber gelingt, das Programm von Hand zu kompilieren, lässt es sich praktisch immer auch in ein RPM verpacken. Wechseln Sie nach einem Misserfolg mit Rpmbuild auf der Konsole in das Verzeichnis ~/rpmbuild/BUILD/Name-Version/, denn dort liegt der Quellcode in dem Zustand, wie ihn der abgebrochene Paketbauversuch hinterlässt. Kompilieren Sie das Programm von dort aus und verändern Sie mit den so gewonnenen Erkenntnissen die %build-Sektion in der Spec-Datei. Das Kommando rpmbuild -bc name.spec führt nur die Befehle unter %prep und %build aus, womit Sie prüfen, ob die Spec-Datei bis einschließlich %build nun in Ordnung ist (Abbildung 5).

Abbildung 5: Wenn Rpmbuild nicht bis zum Ende durchläuft, helfen Schalter, die den Bauprozess nur bis zu einer bestimmten Stelle ausführen, bei der Fehlersuche.

Bei rpmbuild -bi name.spec laufen zusätzlich noch die Befehle unter %install durch. Klappt auch dabei noch alles, dann liegen alle Dateien, die make install einspielt, unter ~/rpmbuild/BUILDROOT/Name-Version/. Überprüfen Sie nun, ob die %files-Liste diese alle erfasst. Trifft das zu, sollte sich das Binärpaket mit rpmbuild -bb name.spec bauen lassen. Bei allen Zwischenschritten sorgt die Option -vv beim Rpmbuild-Aufruf für zusätzliche Information.

Weiterführendes

Wer mehr Informationen braucht, findet im Fedora-Wiki eine vom Umfang her verdauliche Anleitung [6], die sich auch auf andere RPM-basierte Distributionen übertragen lässt. Als umfassendes Standardwerk gilt Eric Foster-Johnsons "RPM-Guide" [7].

Suse-spezifische Informationen liefern die ebenfalls sehr umfangreichen und auf professionelle Maintainer zugeschnittenen OpenSuse-Packaging-Guidelines [4], die Einsteiger allerdings überfordern dürften. Das gilt auch für das Fedora-Pendant [8]. Die zahlreichen Makros für OpenSuse- [5] beziehungsweise Fedora-Spec-Dateien [9] beschreiben Artikel auf den Webseiten der beiden Projekte.

Auf dem OpenSuse-Build-Service [10] und im Git-Repository für Fedora-Pakete [11] sind Spec-Dateien für nicht bei der Distribution mitgelieferten Programme oder Programmversionen zu finden.

So fern und doch so nah

Die auf Verlässlichkeit getrimmten Spec-Dateien, aus denen die offiziellen Distributionspakete entstehen, im Detail zu verstehen ist oft mühevoll. Darüber sollte man aber nicht vergessen, dass zum Update einer bestehenden Spec-Datei auf eine neue Software-Version manchmal das Anpassen des Version:-Feldes und das Herunterladen des Quellcode-Archives nach ~/rpmbuild/SOURCES genügt.

Wer ein paar Fingerübungen dieser Art hinter sich gebracht hat, dem fällt es auch nicht mehr schwer, ein RPM-Paket ohne Vorlage zu erzeugen. Auch wenn das Resultat nicht den Qualitätsanforderungen der Distributionen entspricht, lässt es sich zumindest wieder sicher deinstallieren oder durch das Originalpaket des Systems ersetzen. Der Paketmanager verhindert dabei das Überschreiben von Dateien, die zu anderen Paketen gehören, und schützt so das System vor Schaden. 

Glossar

DLL-Hölle

Unkontrolliertes Überschreiben der von mehreren Programmen genutzten Bibliotheken (DLLs, Entsprechung zu So-Dateien unter Linux) durch die Setup-Programme bis Windows Vista.

Patch

"Flicken". Eine mit Diff erzeugte Textdatei, die Änderungen am Quellcode eines Programm in einer speziellen Notation festhält. Das Programm Patch, das Rpmbuild wenn nötig automatisch aufruft, spielt die Änderungen ein. Es gilt als guter Stil, in SRC-RPMs den von den Programmautoren veröffentlichten Code unverändert einzupacken und alle Änderungen in Patches auszulagern.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 8 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Related content

Kommentare