Paketbau/SUSE-Paketkonventionen/RPM-Stil

aus openSUSE, der freien Wissensdatenbank

1. RPM-Paketstil

Dieser Abschnitt beschreibt den Stil eines SUSE-RPM-Pakets. Die meisten Informationen sind in Abschnitte aufgeteilt, die nach den jeweils zugehörigen Zeilen oder Tags in der spec-Datei benannt sind. Einzige Ausnahme davon bildet der letzte Abschnitt, welcher Unterpakete beschreibt.

1.1. Einführende Kommentare

Die SUSE-spec-Datei beginnt mit einem standardisierten Einführungskommentar:

#
 # spec file for package PAKETNAME (Version PAKETVERSION)
 #
 # Copyright (c) 2003 SuSE Linux AG, Nuernberg, Germany.
 # This file and all modifications and additions to the pristine
 # package are under the same license as the package itself.
 #
 # Please submit bug fixes or comments via http://www.suse.de/feedback/
 #

1.2. norootforbuild

Die Zeile, die mit

# norootforbuild

beginnt, definiert, dass das Paket von einem normalen Nutzer an Stelle von root mit dem build-Skript gebaut wurde. Dies bedeutet, dass das Bauen des Pakets sicherer ist, da, wenn es ohne root-Zugriffsrechte gebaut wurde, nur eine geringe Möglichkeit besteht, dass das installierte System beschädigt wird.

1.3. BuildRequires Tag

Dieses Tag gibt die Pakete an, zum Bau des Pakets installiert sein müssen; Abhängigkeiten werden automatisch aufgelöst. Vor SL 10.1 wurde dieses Tag beim Bau des Pakets innerhalb von SUSE automatisch aus der Zeile neededforbuild generiert. Diese wurde seit SL 9.1 an Stelle der Zeile usedforbuild genutzt.

Siehe auch Prereq Tag, Requires Tag.

1.4. usedforbuild

Die Zeile, die mit

# usedforbuild

beginnt, erwähnt alle Pakete, die für den Bau des Pakets verwendet werden. Seit SL 9.1 wurde Sie durch das BuildRequires Tag überflüssig.

1.5. Name Tag

Der Name des Pakets und der Name des Quellkodearchivs sollten gleich sein, solange der Name nicht eine der folgenden Regelnd bricht:

• Der Paketname kann aus alphanumerischen Zeichen, Bindestrichen und Unterstrichen bestehen (a-z, A-Z, 0-9, -, _).
• Es gibt spezielle Konventionen für bestimmte Arten von Paketen:

1.6. License Tag

Dieses Tag definiert eine durch Kommata separierte Liste von mit dem Paket verbundenen Lizenznamen. Es wird automatisch mit Hilfe einer Datenbank beim Bau des Pakets innerhalb von SUSE erstellt. Falls die Lizenz über keinen bekannten Namen verfügt, so wird nur der standardisierte Text "Other License(s), see package" genutzt.

Beispiele:

License:      GPL
License:      Public domain, Freeware
License:      Other License(s), see package
License:      LGPL, Other License(s), see package

1.7. Group Tag

Die volle Liste aller verfügbaren RPM-Gruppen samt Beschreibung finden Sie unter RPM-Gruppen.

1.8. Version Tag

Die Paketversion und die Version des Quellkodearchivs sollten die gleichen sein, solange dadurch keine Probleme bei der Paketaktualisierung entstehen.

RPM nutzt die Paketversion und die Veröffentlichungsnummer dazu, um entscheiden zu können, welches Paket neuer ist, und erlaubt nur Aktualisierungen von einer niedrigeren auf eine höhere Version. RPM teilt die Paketversion durch Punkte in Hauptversionsnummer, Unterversionsnummer usw. auf und vergleicht die zusammengehörigen Versionsnummern alphabetisch. Wenn ein Nutzer eine Paketversion zurückstufen möchte, dann sollte er dafür die Option --oldpackage verwenden.

Die folgende Tabelle zeigt einige typische und korrekte Versionssequenzen:

Die folgende Tabelle zeigt einige typische aber inkorrekte Versionssequenzen. Die dritte Spalte enthält mögliche Lösungen:

1.9. Release Tag

Die Veröffentlichungsnummer wird mit jeder Versionsaktualisierung auf Null zurückgesetzt. Sie wird bei jeder Änderung am Paket um eins erhöht.

Es wurde ein Mechanismus hinzugefügt, Pakete unterscheiden zu können, die sich von der allgemeinen Kodebasis unterscheiden. Es kann passieren, dass mehrere Produkte auf der gleichen Kodebasis basieren und Pakete spezielle Anpassungen für ein Produkt benötigen. Die Lösung besteht darin, die Veröffentlichungsnummer zu versionieren. Wenn der letzte allgemeine Bau eines Pakets die Veröffentlichungsnummer 14 trägt und die Paketquellen für ein bestimmtes Produkt angepasst werden, dann trägt das Paket für das Produkt die Veröffentlichungsnummern 14.0, 14.1, 14.2 usw., und das gleiche Paket in der allgemeinen Kodebasis trägt die Veröffentlichungsnummern 15, 16, 17 usw.

In der Vergangenheit wurde dieser Wert bei jedem Neubau des Paket einfach um eins erhöht. Die Idee dabei war, zwei Bauten des selben Pakets unterscheiden zu können, falls die zum Bau verwendeten Pakete verändert wurden. Dies brachte allerdings mehr Probleme als Vorteile mit sich, weshalb die Veröffentlichungsnummer nun nur noch verändert wird, wenn das Paket selbst verändert wird.

1.10. Autoreqprov Tag

Dieses Tag sollte immer aktiviert sein, da alle Abhängigkeiten, die automatische erkannt werden können, genutzt werden sollten. Es kann nur in sehr seltenen Fällen deaktiviert werden. Ein Beispiel dafür ist ein Paket, welches ein Plug-In enthält, welches zwar eine tiefe Abhängigkeit erzeugt, allerdings nicht standardmäßig geladen wird und nur von einer kleinen Gruppe Nutzer verwendet wird. In diesem Fall könnte es Sinn ergeben, die automatische Erkennung zu deaktivieren, um weitgehende Abhängigkeiten zu vermeiden, und das Problem in einer README zu beschreiben. Allerdings existiert in diesem Fall auch eine korrektere Lösung, bei der die automatische Erkennung aktiviert bleiben kann. Das problematisch Plug-In kann in ein separates Paket verpackt werden, welches zwar die tiefen Abhängigkeiten aufweist, allerdings optional installiert werden kann.

1.11. PreReq Tag

Dieses Tag definiert Abhängigkeiten, die erfüllt sein müssen, damit das Paket korrekt installiert wird. Das Feld muss alle Pakete oder absoluten Pfade zu den Werkzeugen verwenden, die in den Skripten %pre, %post, und %triggerin verwendet werden.

Der absolute Pfad wird normalerweise für Basiswerkzeuge wie /bin/touch und /bin/rm verwendet. Dies ist unproblematisch, da diese Pfade stabil sind und auf allen UN*Xes allgemein verfügbar sind. Außerdem sind sie resistent gegenüber Paketumbennenungen und Paketaufteilungen. Für weniger allgemeines Zeug sollte der Name des Pakets genutzt werden. Es hängt davon ab, was in der Zukunft am wahrscheinlichsten geändert wird.

Das folgende Beispiel stammt aus dem Paket deb:

PreReq:       /bin/touch
[...]
%post
cd /var/lib/dpkg
for f in diversions statoverride status ; do
        if [ ! -f "$f" ] ; then
                touch "$f"
        fi
done

Das nächste Beispiel ist dem Paket cups-drivers entnommen:

PreReq:       sysvinit, sh-utils
 [...]
 %post
 test -x /etc/init.d/cups && \
         /etc/init.d/cups status >/dev/null && \
         /etc/init.d/cups reload >/dev/null
 # exit 0 needed here to ignore test return code
 exit 0
 

SUSE stellt einige Makros bereit, die im PreReq Tag genutzt werden können. Sie stellen die nötigen Abhängigkeiten für die im %post-Skript verwendeten Makros bereit. Ein Beispiel dazu finden Sie bei %install_info im Kapitel über die RPM-Makros.

Siehe auch Requires Tag und BuildRequires Tag.

1.12. Requires Tag

Dieses Tag definiert Pakete, die für die korrekte Funktion des Pakets installiert sein müssen. Dieses Feld muss zumindest all die Pakete enthalten, die nicht automatisch erkannt werden, aber für die Funktion des Pakets notwendig sind.

Vorzugsweise sollten hier nur Paketnamen angegeben werden. Wenn sich allerdings die Schnittstelle zwischen einem Haupt- und einem Unterpaket zwischen verschiedenen Versionen verändert, dann sollte das Unterpaket die exakte Version des Hauptpakets verlangen, allerdings ohne Veröffentlichungsnummer. Dies ist typischerweise bei devel-Unterpaketen der Fall,glibc-devel-<Version> benötigt bspw. glibc-<version>. Eine exakte Anforderung, die auch die Veröffentlichungsnummer umfasst, ist nur in extrem seltenen Fällen nötig.

Sieh auch PreReq Tag und BuildRequires Tag.

1.13. Summary Tag

Die Zusammenfassung besteht aus einer eine Zeile langen Zeichenkette, welche das Paket beschreibt. Die Maximallänge beträgt 80 Zeichen. Sie sollte auf alle Standardsituationen passen und sich keines speziellen Kontexts annehmen. Sie sollte alleine hilfreich sein, in alphabetisch sortierten oder unsortierten Listen einiger ausgewählter Pakete, und in alphabetisch sortierten oder unsortierten Listen von allen Paketen.

Sie sollte die Hauptfunktion des Pakets beschreiben und jedwede spezielle Eigenschaften herausstellen, um den Nutzer dabei zu unterstützen, sich zwischen ähnlichen Paketen entscheiden zu können. So fassen die beiden Wörtchen "Web Browser" bspw. alle Web Browser zusammen, aber indem man zusätzlich noch Adjektive (wie minimalistisch, komplex, GNOME, KDE, textbasiert, oder Autorennamen) benutzt, kann man ein bestimmtes Paket genauer charakterisieren.

Die RPM-spec-Datei enthält nur die englische Version, um die RPM-Datenbank klein zu halten. Die Lokalisierungen werden von YaST verwaltet.

1.13.1. Stilrichtlinien

• Verwenden Sie großgeschriebene Anfangsbuchstaben. Das heißt, dass die meisten Wörter großgeschrieben werden, bis auf Präpositionen und Artikel.
• Verwenden Sie am Anfang der Zeile keinen Artikel.
• Verwenden Sie am Ende der Zeile keine Punkte.
• Versuchen Sie, komplette Sätze zu vermeiden. Schreiben Sie zum Beispiel “Meta Package with SUSE Contributors as Authors.” an Stelle von “This is a meta package. It contains SUSE contributors as authors.”

Beispiele:

Summary:    High Quality Asteroids Clone
Summary:    Enhanced Interactive Python Shell
Summary:    Tool to Verify 3D Configuration
Summary:    Graphics Library for Framebuffer Devices
Summary:    Converter for Several 3-Dimensional Object File Formats

1.14. Source Tag

Das Quellkodearchiv sollte mit bzip2 komprimiert sein. Zögern Sie nicht, das Quellkodearchiv neu zu packen, wenn diese die Lizenz nicht verletzt. Jede separate Quelle sollte mit bzip2 komprimiert werden, wenn ihre Größe 100kB übersteigt. Nutzen Sie wenn immer möglich die Makros %name und %version.

1.15. Patch Tag

Jedes Problem sollte durch einen separaten Patch gelöst werden. Um die Betreuung der Patches zu vereinfachen, sollte jeder Patch über einen Kopfteil mit den folgenden Informationen verfügen:

• Name des Autors
• Detaillierte Beschreibung des gelösten Problems
• URL der originalen Quelle des Patch, falls es eine gibt

Der Name der Patch-Datei sollte folgendermaßen aufgebaut sein:

• Name und Version des Quellkodearchivs aus welchem der Patch erzeugt wurde
• Einige Worte, die den Inhalt des Patch kategorisieren
• Der Dateinamensendung .patch

Patches liegen im vereinheitlichten Format (diff -u) vor und sollten in der spec-Datei mit dem Vertiefungslevel Null gehandhabt werden (%patch -p0). Einzige Ausnahme stellen die Patches dar, die von einer anderen Hauptquellseite stammen. In diesem Fall werden die originalen Namen, Endungen und Formate beibehalten.

Jeder Patch der größer als 100kB ist, sollte mit bzip2 komprimiert werden. Wenn immer möglich, sollten die Makros %name und %version verwendet werden.

Beispiele:

Source:   %{name}-%{version}.tar.bz2
Patch0:   %{name}-%{version}-autoconf.patch
Patch1:   %{name}-%{version}-gcc31.patch

1.16. BuildRoot Tag

Diese Fähigkeit sollte immer genutzt werden. De bevorzugte Pfad ist %{_tmppath}/%{name}-%{version}-build.

1.17. Description Tag

Die Paketbeschreibung soll dem Nutzer dabei helfen, das für seine Zwecke geeignetste Paket zu finde, ohne dass er dafür ähnliche Pakete erst selber testen muss. Dies ist der richtige Ort, um den Nutzer genauer über die Funktionalität des Pakets zu informieren. Sie sollte weitergehende Informationen über die Fähigkeiten des Pakets enthalten und Unterschiede zu anderen, vergleichbaren Paketen aufzeigen. Falls ein Paket die Installation des Nutzers beschädigen könnte, dann sollte die Beschreibung klare Hinweise zu den potentiellen Risiken und Nebeneffekten enthalten.

Die Beschreibung kann Informationen darüber enthalten, wo weitere Dokumentation des Pakets gefunden werden kann und wie eine Anwendung am besten gestartet wird, sollte aber nicht schon vorhandene Informationen abermals abhandeln. Eine Ausnahme davon kann gemacht werden, wenn dies dem Nutzer hilft, sich zwischen zwei ähnlichen Paketen zu entscheiden.

Die Paketbeschreibung sollte keine unnötigen Informationen enthalten, die dem Nutzer nicht dabei behilflich sind, dass für ihn sinnvollste Paket auszuwählen, da viele Nutzer dazu tendieren, längere Texte zu ignorieren. Hoch detaillierte Informationen und die Pakethistorie sind bspw. besser in der Paketdokumentation aufgehoben.

Die RPM-spec-Datei enthält lediglich die englische Version, um die RPM-Datenbank klein zu halten. Die Lokalisierungen werden von YaST verwaltet.

1.17.1. Stilrichtlinien

• Wenn Sie den Nutzer ansprechen, dann verwenden Sie da Pronomen "you."
• Vermeiden Sie Zusammenziehungen wie "can't" und "isn't."
• Klarheit ist entscheidend. Verwenden Sie kurze Sätze und einfache Strukturen, um einen klaren, professionellen Stil aufrechtzuerhalten. An Stelle von Semikolons sollten Sie einen Satz in zwei Sätze aufteilen. Falls die Satzlänge ausufert oder der Satz holprig wirkt sollten Sie versuchen, ihn neu zu bilden.
• Vermeiden Sie Emotionen und "please."
• If-Then ist keine grammatikalische Struktur. Auf einen Satz der mit "if" beginnt, muss auch ein Satz folgen, der mit "then" beginnt.
• Verwenden Sie nach einem Doppelpunkt keine Großschreibung, es sei denn, dass der auf den Doppelpunkt folgende Satz Teil von mehreren Sätzen ist.
• Vermeiden Sie die Nutzung von "etc." Es tendiert dazu , den Satzfluss aufzubrechen. Falls es verwendet wird, dann sollte ihm ein Komma folgen, außer es steht am Ende eines Satzes. Wenn Sie ein Beispiel geben wollen, dann ist es nicht nötig, dass Sie "etc." oder eine Ersatzstruktur verwenden, da der Leser kein allumfassendes Beispiel erwartet.
• Semikolons (;) werden hauptsächlich genutzt, um zwei zusammenhängende Sätze zusammenzuführen. In einer komplizierten Abfolge können Sie auch an Stelle von Kommata verwendet werden. Wenn möglich sollten Sie sie vermeiden und den Satz lieber in kleine Stücke aufteilen.
• Vermeiden Sie wo möglich "e.g." und "i.e.". Viele Leute verstehen die Korrekte Bedeutung dieser Abkürzungen nicht, weshalb es am besten ist, sie zu vermeiden. Ersetzen Sie sie durch Phrasen wie "for example" oder "such as". Falls Sie sie unbedingt benötigen, dann verwenden Sie Kommata um "e.g.," "i.e.," und "for example" herum (außer, sie stehen am Anfang oder am Ende der Aussage. In diesem Fall setzen Sie nur danach oder davor ein Komma). Zum Beispiel, ist dies ein Beispiel.
• Die Symbole "/" und "\" werden unter keinen Umständen als Satzzeichen verwendet.
• Verwenden Sie "so-called" nur, wenn der Ausdruck, auf den es sich bezieht, ein Spitzname oder eine Fehlbezeichnung ist, aber nicht als Verweis auf den korrekten Ausdruck. Ersetzen Sie es auch nicht durch "what is known as" oder ähnliche Konstruktionen.
• Wörterliste: address book, applet, back-end, Bash (according to GNU Bash manual), boot loader, check box, check mark, command line, deactivate, deselect (verb), dialog, dial-up (not dial-in), double-click, e-mail, filename, file system, formulas, framebuffer, front-end, The GIMP (current project standard), GNOME (current project standard), graphical user interface, graphics card, hard disk.
• Witze reisen nicht. Bauen Sie keine Witze oder lustige Aussagen ein, da diese normalerweise meist nur in bestimmten Gegenden verstanden werden und möglicherweise andere Menschen irritieren, die nicht mit der lokalen Verwendung vertraut sind.
• "commandline command" ist doppelt gemoppelt. "command" ist für gewöhnlich ein kommandozeilenspezifischer Ausdruck.

1.18. Unterpakete

Unterpakete werden aus den folgenden Gründen erstellt:

• Einige Dateien werden für die Basisfunktionen nicht benötigt (optionale Dateien) und sind im Vergleich zur Größe des Hauppakets groß
• Einige Dateien werden mit anderen Paketen geteilt (gemeinsam genutzte Dateien)

Der Name eines Unterpakets besteht normalerweise aus:

• dem Namen des Hauptpakets
• einigen Worten, die den Inhalt des Unterpaktes beschreiben

Ein Bindestrich (-) ist das bevorzugte Trennzeichen zwischen dem Paketnamen und den zusätzlichen Wörtern.

Zum Beispiel:

apache.rpm
apache-contrib.rpm
apache-devel.rpm
apache-doc.rpm
apache-example-pages.rpm
apache-testsuite.rpm

Zu guter Letzt müssen für jedes Unterpaket auch noch die folgenden Tags definiert werden:

• Group
• Summary
• Description

1.19. Provides und Obsoletes Tags

Diese Tags werden verwendet, wenn wir Paket umbenennen, aufteilen oder zusammenführen. Weitere Informationen dazu finden Sie im Artikel Paketabhängigkeiten.