Fedora-Paketbaurichtlinien

Diese Richtlinien gelten im Allgemeinen für die aktuell veröffentlichten Versionen von Fedora (jedoch NICHT für die nicht mehr unterstützten) sowie für die Entwicklungsversion von Fedora (Rawhide). Sollte ein bestimmter Abschnitt dieser Richtlinien nur für eine Untermenge dieser Versionen relevant sein, wird dies ausdrücklich vermerkt. Bitte beachten Sie jedoch, dass sich Rawhide schnell ändern kann, und es kann vorkommen, dass Änderungen dort bereits sichtbar sind, die hier noch nicht berücksichtigt wurden.

Die Richtlinien decken in gewissem Umfang auch Pakete für EPEL ab, jedoch nur in Kombination mit den EPEL-Paketbaurichtlinien. Die Fedora-Paketierung ändert sich deutlich schneller als die EPEL-Paketierung, so dass diese Richtlinien im Laufe der Zeit immer weiter von den jeweiligen EPEL-Versionen abweichen werden. Bei älteren unterstützten EPEL-Versionen können die Unterschiede daher recht erheblich sein. Abschnitte dieser Richtlinien, die nicht für EPEL gelten, werden in der Regel nicht gesondert gekennzeichnet.

Da diese Richtlinien niemals alle möglichen Eventualitäten abdecken können, wird es immer Pakete geben, die Ausnahmen erfordern. Es liegt in der Verantwortung des Paketbetreuers, diese Richtlinien so genau wie möglich zu befolgen und Fälle, in denen sie nicht eingehalten werden können, als Kommentare in der Spec-Datei des Pakets klar zu dokumentieren.

Wenn in einer Richtlinie die Formulierung „sollte“ oder „wird empfohlen“ verwendet wird und es für das Paket nicht möglich ist, dieser Richtlinie zu entsprechen, darf der Paketersteller davon abweichen. Die Art der Abweichung und die Begründung dafür MÜSSEN in der Spec-Datei dokumentiert werden.

Wo Formulierungen wie „muss“, „ist erforderlich“ oder „benötigt“ verwendet werden, darf der Paketersteller nur mit Genehmigung des Packaging Committee von der Richtlinie abweichen. Bitte befolgen Sie das Verfahren auf der Seite des Packaging Committee, um solche Anträge zu stellen.

Bitte schauen Sie sich das Dokument Was kann paketiert werden an, um sicherzustellen, dass das, was Sie paketieren wollen, in Fedora erlaubt ist.

Schauen Sie in die Benennungsrichtlinien, um sicherzustellen, dass Ihr Paket korrekt benannt ist.

Eine Dokumentation zur korrekten Verwendung der Felder „Version“ und „Release“ finden Sie hier.

Sie sollten die Informationen zu den in Fedora zulässigen Lizenzen und die Lizenzierungsrichtlinien lesen, um sicherzustellen, dass Ihr Paket ordnungsgemäß lizenziert und die Lizenz korrekt angegeben ist.

Viele sprach- oder domänenspezifische Richtlinien beziehen sich auf „Bibliotheken“,„Module“, „Plugins“ oder andere für die jeweilige Sprache oder Domäne spezifische Begriffe. Dies ist insbesondere für die Paketbenennung wichtig. Einige Anwendungen können Bibliotheken enthalten, und einige Bibliotheken können Anwendungen enthalten, so dass die Unterscheidung nicht immer eindeutig ist.

Pakete SOLLTEN, sofern technisch möglich, unabhängig voneinander installierbar sein, MÜSSEN aber gegebenenfalls Abhängigkeiten des korrekten Typs zu anderen Paketen angeben (siehe Abschnitt „Abhängigkeitstypen“ weiter unten).

Desktop-Anwendungen DÜRFEN NICHT von anderen Desktop-Anwendungen abhängen, es sei denn, dass dies unbedingt erforderlich ist. Insbesondere Pakete, die eine sichtbare .desktop-Datei enthalten (eine .desktop-Datei, die nicht die Zeile NoDisplay=true enthält), sollten keine Requires-, Recommends- oder Supplements-Anweisungen für andere Pakete enthalten, die direkt oder indirekt eine sichtbare Desktop-Datei enthalten.

Es wäre beispielsweise sinnvoll, wenn ein Level-Editor für Videospiele das zugehörige Videospiel benötigt, um zu funktionieren, oder wenn ein Plugin einer Anwendung die zugehörige Anwendung benötigt. Es wäre jedoch nicht sinnvoll, wenn eine Anwendung, die zufällig eine Datenbankbibliothek verwendet, von einer Datenbankverwaltungssoftware abhängig wäre, die mit dieser Bibliothek verknüpft ist, oder wenn eine Anwendung, die zufällig eine bestimmte Programmiersprache verwendet, von Verwaltungswerkzeugen abhängig wäre, die mit dieser Programmiersprache verknüpft sind.

Wenn ein Quellpaket mehrere grafische Anwendungen bereitstellt, sollten diese Anwendungen nach Möglichkeit in separate Teilpakete ausgelagert werden.

Die Spec-Datei („.spec“) ist ein grundlegendes Element im Paketierungsprozess.Jede Änderung am Paket führt zu einer Änderung der Spec-Datei.Da Pakete in Fedora sowohl von einer Gemeinschaft von Paketierstellern als auch von automatisierten Werkzeugen verwaltet werden, ist es wichtig, dass die Spec-Dateien bestimmten Konventionen folgen. Der Großteil dieser Richtlinien für die Paketierung betrifft den Inhalt einer Spec-Datei; hier sind einige allgemeine Punkte.

Sofern das Upstream-Projekt OpenPGP-Signaturen seiner Releases veröffentlicht, sollten Fedora-Pakete diese Signatur im Rahmen des RPM-Bauprozesses verifizieren.

Obwohl eine Prüfsumme in der Quelldatei bestätigt, dass eine aus dem Lookaside-Cache abgerufene Datei diejenige ist, die der Paketersteller hochgeladen hat, gibt sie keine Auskunft darüber, ob es sich um die vom Upstream-Projekt veröffentlichte Datei handelt. Eine Signatur der Upstream-Entwickler bestätigt, dass der Quellcode mit der von ihnen veröffentlichten Version identisch ist. Die Überprüfung der Signatur im Rahmen des Bauprozesses stellt sicher, dass Paketersteller die Überprüfung nicht vergessen.

Alle Fedora-Pakete müssen auf mindestens einer unterstützten primären Architektur erfolgreich kompiliert und in binäre RPM-Dateien umgewandelt werden können, außer wenn das Paket nur auf einer sekundären Architektur nützlich ist (z.B. ein architekturspezifisches Boot-Dienstprogramm, ein Microcode-Loader oder ein Hardware-Konfigurationswerkzeug). Fedora-Paketentwickler sollten sich nach Kräften bemühen, alle primären Architekturen zu unterstützen.

Inhalt, Code, der nicht kompiliert oder erstellt werden muss, und architekturunabhängiger Code (noarch) sind erwähnenswerte Ausnahmen.

Fedora folgt hinsichtlich des Dateisystemlayouts dem Dateisystemhierarchie-Standard (Filesystem Hierarchie Standard, FHS) der Linux Foundation, mit den unten aufgeführten Ausnahmen. Der FHS definiert, wo Dateien im System abgelegt werden sollen.

Führen Sie rpmlint auf Binär- und Source-RPMs aus, um sie auf häufige Fehler zu untersuchen und zu beheben (sofern rpmlint nicht fehlerhaft ist, was ebenfalls vorkommen kann). Falls die Ausgabe von rpmlint kryptisch erscheint, können Sie mit dem Schalter -e ausführlichere Beschreibungen der meisten Fehler und Warnungen erhalten. Beachten Sie, dass rpmlint zusätzliche Prüfungen durchführt, wenn der Name eines installierten Pakets angegeben wird. Beispielsweise führt dnf install foo-1.0-1.f20.x86_64.rpm; rpmlint -i foo eine Reihe von Tests für das Paket foo durch, die rpmlint foo-1.0-1.f20.x86_64.rpm nicht durchführen kann. Eine von der Community gepflegte Seite zu rpmlint-Problemen finden Sie hier.

Alle Paketabhängigkeiten (BAU- oder Laufzeitabhängigkeiten, reguläre, weiche oder sonstige) MÜSSEN IMMER innerhalb der offiziellen Fedora-Paketquellen erfüllt werden können.

RPM kann Abhängigkeiten für die meisten kompilierten Bibliotheken und für einige Skriptsprachen wie Perl automatisch ermitteln. Automatisch ermittelte Abhängigkeiten DÜRFEN NICHT durch manuelle Abhängigkeiten dupliziert werden.

Bauabhängigkeiten MÜSSEN jedoch explizit aufgeführt werden, es sei denn, Sie verwenden einen automatischen Bauabhängigkeitsgenerator (z.B. Rust oder Python). Siehe Bauabhängigkeiten (BuildRequires).

Versionierte Abhängigkeiten (zur Bauzeit oder Laufzeit) SOLLTEN NUR dann verwendet werden, wenn sie tatsächlich notwendig sind, um sicherzustellen, dass die richtige Version eines Pakets vorhanden ist. Wenn eine versionierte Abhängigkeit durch eine Version erfüllt werden könnte, die in drei vorherigen Fedora-Versionen vorhanden war, ist eine versionierte Abhängigkeit nicht erforderlich und stattdessen SOLLTE eine reguläre, nicht versionierte Abhängigkeit verwendet werden.

Eine versionierte Abhängigkeit von einem Paket mit definierter Epoche MUSS in dieser Abhängigkeit enthalten sein. Andernfalls wird die Abhängigkeit nicht wie erwartet funktionieren.

Es ist wichtig, dass Ihr Paket alle notwendigen Bauabhängigkeiten mithilfe des Tags BuildRequires: auflistet. Sie KÖNNEN davon ausgehen, dass eine ausreichende Umgebung für die Funktion von RPM, das Erstellen von Paketen und das Ausführen einfacher Shell-Skripte vorhanden ist, aber Sie SOLLTEN NICHT davon ausgehen, dass andere Pakete als RPM-Abhängigkeiten vorhanden sind, da sich alles, was vom Build-System in das Build-Verzeichnis gebracht wird, im Laufe der Zeit ändern kann.

Wenn die Spec-Datei bedingte Abhängigkeiten enthält, die basierend auf dem Vorhandensein optionaler --with(out) foo-Argumente für rpmbuild ausgewählt wurden, wird das Source-RPM mit den Standardoptionen erstellt, das heißt, so dass keines dieser Argumente in der Befehlszeile von rpmbuild vorhanden ist. Der Grund dafür ist, dass diese Abhängigkeiten in das resultierende Source-RPM „serialisiert“ werden, das heißt, die Bedingungen gelten dann nicht mehr.

Die Zusammenfassung (Summary) sollte eine kurze und prägnante Beschreibung des Pakets sein. Die Beschreibung (Description) sollte dies weiter ausführen.

Jegliche relevante Dokumentation, die in der Quelldistribution enthalten ist, sollte im entsprechenden Dokumentationsverzeichnis des Pakets abgelegt werden. Nicht relevante Dokumentation umfasst Bauanweisungen, die allgegenwärtige Datei INSTALL mit allgemeinen Bauanweisungen oder Beispielen sowie Dokumentation für Nicht-Linux-Systeme, z.B. README.MSDOS. Achten Sie außerdem darauf, in welches Teilpaket Sie die Dokumentation einfügen. Die API-Dokumentation beispielsweise gehört in das Teilpaket -devel, nicht in das Hauptpaket. Bei umfangreichen Dokumentationen empfiehlt es sich, sie in ein eigenes Teilpaket auszulagern. In diesem Fall wird empfohlen, *-doc als Namen für das Teilpaket zu verwenden.

Die Kennzeichnung eines relativen Pfades mit %doc im Abschnitt %files bewirkt, dass RPM die referenzierte Datei oder das Verzeichnis von %_builddir an den korrekten Speicherort für die Dokumentation kopiert. Dateien können auch in %_pkgdocdir abgelegt werden, und die Bauskripte der zu paketiernden Software können dies automatisch tun, wenn sie in %install aufgerufen werden. Die Kombination dieser Methoden ist jedoch problematisch und kann zu doppelten oder in Konflikt stehenden Dateien führen. Daher ist die Verwendung von %doc mit relativen Pfaden und die direkte Installation von Dateien in %_pkgdocdir im selben Quellpaket nicht zulässig.

Als Dokumentation gekennzeichnete Dateien dürfen nicht dazu führen, dass das Paket mehr Abhängigkeiten einbindet, als es ohne die Dokumentation der Fall wäre. Eine einfache Möglichkeit, dies in den meisten Fällen sicherzustellen, besteht darin, alle Ausführungsberechtigungen für Dateien im Verzeichnis %_pkgdocdir zu entfernen.

Dateien im Verzeichnis %_pkgdocdir dürfen die paketierte Software zur Laufzeit nicht beeinflussen. Die Software muss auch dann einwandfrei und mit unveränderter Funktionalität arbeiten, wenn diese Dateien geändert, entfernt oder gar nicht erst installiert werden.

Obwohl Lizenzdateien Dokumentationen darstellen, werden sie speziell behandelt(unter anderem durch die Verwendung eines anderen Tags). In den Lizenzierungsrichtlinien lesen Sie, wie Sie damit umgehen.

Das Änderungsprotokoll (Changelog) beschreibt die Änderungen am Paket, die für die Benutzer relevant sind. Dies umfasst neue Upstream-Versionen, wichtige Änderungen am Bauprozess, Rebuilds und andere Änderungen, die das Ergebnis beeinflussen. Änderungen, die nur für Paketersteller relevant sind, sollten nicht im Änderungsprotokoll erwähnt werden. Dazu gehören Bereinigungen von Spec-Dateien, Fehlerbehebungen oder Workarounds für Baufehler sowie andere Änderungen, die keinen Einfluss auf den Inhalt der Binärpakete haben.

Das Änderungsprotokoll sollte automatisch aus den Git-Commit-Protokollen mit Hilfe des Makros %autochangelog generiert werden:

Der Betreff des Commits (die erste Zeile der Commit-Nachricht) und optional einige zusätzliche Zeilen werden verwendet, um den Changelog-Text zu generieren. Der Name und die E-Mail-Adresse des Commit-Autors sowie der Commit-Zeitstempel werden ebenfalls im Changelog-Eintrag verwendet.

Der Text der Commit-Nachricht, die Teil des Änderungsprotokolls wird, sollte eine kurze Zusammenfassung der für den Benutzer relevanten Änderungen enthalten. Die Commit-Nachricht kann auch zusätzliche Informationen enthalten, die für Paketersteller relevant sind.

Wenn eine bestimmte Änderung mit einem Bugzilla-Fehlerbericht zusammenhängt, fügen Sie die Bug-ID zur einfacheren Referenz in den Änderungsprotokolleintrag ein, z.B.

Wenn ein bestimmter Commit eine CVE behebt, sollten diese Informationen ebenfalls angegeben werden.

Ziel ist es, dem Benutzer einen Hinweis auf die Änderungen in einer Paketaktualisierung zu geben, ohne ihn mit technischen Details zu überfordern. Die Einträge dürfen niemals einfach eine vollständige Kopie der CHANGELOG-Einträge des Quellcodes enthalten. Links zu den entsprechenden NEWS-Dateien oder Changelogs können für diejenigen hinzugefügt werden, die zusätzliche Informationen wünschen.

In der https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html [Autochangelog-Dokumentation] finden Sie Details zur Generierung des Changelogs aus Git-Commit-Nachrichten und zur Erstellung mehrzeiliger Einträge oder zum Überspringen von Einträgen für bestimmte Commits.

Paketierer können alternativ ein manuelles Änderungsprotokoll anstelle des Makros %autochangelog verwenden. Die Vorgehensweise wird hier beschrieben.

Da Unix-Handbuchseiten (Manpages) die traditionelle Methode sind, um Hilfe auf einem Unix-System zu erhalten, sollten Pakete sie für alle ausführbaren Dateien enthalten. Falls Manpages fehlen, sollten die Paketersteller mit dem Upstream-Projekt zusammenarbeiten, um diese hinzuzufügen. Gelegentlich findet man auch Manpages anderer Distributionen oder kann die Ausgabe des Programms help2man verwenden; diese sind oft ein nützlicher Ausgangspunkt. Beachten Sie bei der Installation von Manpages, dass RPM sie in sein bevorzugtes Format komprimiert. Daher muss der Abschnitt %files die Manpages mit einem Muster referenzieren, das dies berücksichtigt:

Beachten Sie außerdem, dass Dateien, die in %{_mandir} installiert sind, von RPM automatisch als Dokumentation gekennzeichnet werden. Daher ist die Verwendung von %doc nicht erforderlich.

Für lokalisierte Manpages verwenden Sie %find_lang --with-man, wie in Umgang mit Locale-Dateien beschrieben.

Fedora-Pakete sollten standardmäßig gcc als Compiler verwenden (für alle von gcc unterstützten Sprachen) oder clang, falls die Upstream-Software das Kompilieren mit gcc nicht unterstützt. Aus technischen Gründen können sich Paketersteller jedoch entscheiden, nicht den Standard-Compiler zu verwenden. Beispiele für solche Gründe sind unter anderem:

Paketersteller, die einen nicht standardmäßigen Compiler verwenden, sollten den Grund für diese Entscheidung in einem Kommentar in der Spec-Datei dokumentieren.

Wenn Clang zum Erstellen eines Pakets verwendet wird, müssen Paketersteller das Makro %toolchain auf „clang“ setzen:

Dies stellt sicher, dass beim Kompilieren die Clang-spezifischen Compiler-Flags von Fedora verwendet werden.

Wenn ein Paketersteller bedingte Makros in einer Spec-Datei verwenden möchte, um den Wechsel zwischen zwei verschiedenen Compilern zu vereinfachen, sollten die folgenden Makronamen verwendet werden:

Paketersteller können anstelle der festen Angabe des Compilernamens auch die Makros %build_cc, %build_cxx oder %build_cpp in der Spec-Datei verwenden. Die Werte dieser Variablen werden durch Setzen des Makros %toolchain auf „clang“ oder „gcc“ gesteuert.

Compiler, die zum Bauen von Paketen verwendet werden, müssen die entsprechenden Compiler-Flags berücksichtigen, die in der System-RPM-Konfiguration festgelegt sind. Dies bedeutet, dass der Inhalt dieser Variable als Grundlage für die Flags dient, die der Compiler während des Paketbaus tatsächlich verwendet.

Für C-, C++- und Fortran-Code enthält das %{optflags}-Makro diese Flags. Das Außerkraftsetzen dieser Flags zur Leistungsoptimierung (z.B. -O3 statt -O2) wird generell nicht empfohlen. Sollten Sie Benchmarks vorlegen können, die eine signifikante Beschleunigung für diesen speziellen Code belegen, kann dies im Einzelfall erneut geprüft werden. Das Hinzufügen, Außerkraftsetzen oder Filtern von Teilen dieser Flags ist zulässig, sofern ein triftiger Grund dafür vorliegt; die Begründung hierfür muss in der Spec-Datei dokumentiert werden.

Pakete SOLLTEN die manuelle Bearbeitung der Umgebungsvariablen 'CFLAGS' usw. vermeiden und stattdessen die in der Dokumentation hier beschriebenen Methoden zur Manipulation von Compiler-Flags verwenden.

Es gibt bestimmte sicherheitsrelevante Flags, die allgemein zulässig sind. Diese Flags können die Performance geringfügig beeinträchtigen, aber die erhöhte Sicherheit kann sich für manche Programme lohnen.

Pakete sollten nützliche -debuginfo-Pakete erzeugen oder diese explizit deaktivieren, wenn dies nicht möglich ist, rpmbuild dies aber trotzdem tun würde. Wenn ein -debuginfo-Paket explizit deaktiviert wird, ist eine Erklärung dafür in der Spec-Datei erforderlich. Debuginfo-Pakete werden in einem separaten Dokument ausführlicher beschrieben: Packaging:Debuginfo.

Fedora-Pakete müssen logisch nach Dateistruktur aufgebaut sein.Insbesondere müssen -devel-Pakete Dateien enthalten, dieausschließlich für die Entwicklung bestimmt sind oder nur zur Bauzeit benötigt werden. Dies dient dazu,den Installationsaufwand für Benutzer zu minimieren. Es gibt einige Dateitypen,die fast immer in ein -devel-Paket gehören:

Die versionierten gemeinsam genutzten Bibliotheksdateien (/usr/lib/libfoo.so.3.2.0 und /usr/lib/libfoo.so.3) sind erforderlich, damit Benutzer Programme ausführen können, die mit libfoo verknüpft sind. Daher gehören sie in das Basispaket. Die andere, nicht versionierte gemeinsam genutzte Bibliotheksdatei (/usr/lib/libfoo.so) wird nur verwendet, um libfoo mit dem zu kompilierenden Code zu verknüpfen, und muss nicht auf dem System des Benutzers installiert sein. Das bedeutet, dass sie in ein -devel-Paket gehört. Bitte beachten Sie, dass in den meisten Fällen nur die vollständig versionierte gemeinsam genutzte Bibliotheksdatei (/usr/lib/libfoo.so.3.2.0) eine tatsächliche Datei ist; alle anderen Dateien sind symbolische Links darauf. Wenn eine gemeinsam genutzte Bibliotheksdatei nur in einem nicht versionierten Format bereitgestellt wird, sollte der Paketersteller die Upstream-Entwickler bitten, die Bereitstellung einer ordnungsgemäß versionierten Bibliotheksdatei in Betracht zu ziehen. Wenn die gemeinsam genutzte Bibliotheksdatei jedoch für die Ausführung von Programmen, die damit verknüpft sind, erforderlich ist, muss sie in das Basispaket aufgenommen werden. Falls die gemeinsam genutzte Bibliotheksdatei später von einem Upstream-Projekt versioniert wird, müssen die Paketbetreuer darauf achten, auf das oben beschriebene Versionsschema umzustellen.

Teilpakete sind oft Erweiterungen ihres Basispakets und sollten in diesem Fall ihr Basispaket benötigen. Wenn ein Teilpaket das Basispaket benötigt, muss es dies über eine vollständig versionierte, architekturspezifische Abhängigkeit (für Nicht-noarch-Pakete) tun:

Devel-Pakete sind ein Beispiel für Pakete, die ihre Basispakete über eine vollständig versionierte Abhängigkeit benötigen. -libs-Teilpakete, die nur gemeinsam genutzte Bibliotheken enthalten, müssen normalerweise nicht explizit von ihren Basispaketen abhängen, da sie diese in der Regel nicht für die Funktionalität ihrer Bibliotheken benötigen.

Wenn Sie in eine Situation geraten, in der das Hauptpaket vom Teilpaket abhängt,und das Teilpaket wiederum vom Hauptpaket, sollten Sie sorgfältig darüber nachdenken, warumnicht einfach alles im Hauptpaket enthalten ist.

Wann immer möglich (und praktikabel), SOLLTEN Fedora-Pakete, die Bibliotheken enthalten, diese als gemeinsam genutzte Bibliotheken erstellen. Es ist nicht notwendig, ldconfig beim Installieren gemeinsam genutzter Bibliotheken aufzurufen.

Pakete, die Bibliotheken enthalten, SOLLTEN statische Bibliotheken so weit wie möglich ausschließen (z. B. durch Konfiguration mit --disable-static). Anwendungen, die gegen Bibliotheken gelinkt sind, SOLLTEN dynamische Bibliotheken und nicht statische Versionen verwenden.

Libtool-Archive (Dateien mit der Endung foo.la) SOLLTEN NICHT eingebunden werden. Pakete, die libtool verwenden, installieren diese standardmäßig, selbst wenn Sie mit --disable-static konfigurieren. Daher müssen sie möglicherweise vor dem Paketieren entfernt werden. Aufgrund von Fehlern in älteren Versionen von libtool oder in Programmen, die libtool verwenden, kann es vorkommen, dass *.la-Dateien nicht ohne Programmänderungen entfernt werden können. In den meisten Fällen ist es jedoch recht einfach, diese Probleme in Zusammenarbeit mit den Upstream-Entwicklern zu beheben. Beachten Sie: Wenn Sie eine Bibliothek in einer stabilen Version (nicht Entwicklungsversion) aktualisieren und das Paket bereits *.la-Dateien enthält, SOLLTE das Entfernen der *.la-Dateien als API-/ABI-Änderung behandelt werden. — Das heißt, ihre Entfernung verändert die Schnittstelle, die die Bibliothek dem „Rest der Welt“ bietet. Daher MÜSSEN die Fedora-Richtlinien für potenziell destabilisierende Aktualisierungen befolgt werden.

Fedora-Pakete SOLLTEN alles daransetzen, zu vermeiden, dass mehrere separate Upstream-Projekte in einem einzigen Paket zusammengefasst werden.

Alle Pakete, deren Upstream-Projekte die Verwendung von Systembibliotheken erlauben, MÜSSEN mit Systembibliotheken kompiliert werden. In diesem Fall MÜSSEN die mitgelieferten Bibliotheken (und/oder deren Quellcode) während %prep explizit gelöscht werden. Die Bauskripte müssen möglicherweise angepasst werden, um diese Situation zu berücksichtigen. Wenn möglich, sollte der Patch die Verwendung der mitgelieferten Bibliotheken bedingt festlegen, damit er zur Prüfung an den Upstream-Entwickler weitergeleitet werden kann.

Alle Pakete, deren Upstream-Projekte keinen Mechanismus zum Kompilieren gegen Systembibliotheken besitzen, KÖNNEN optional gebündelte Bibliotheken bereitstellen. In diesem Fall MÜSSEN sie jedoch angeben, welche Bibliotheken gebündelt sind. Dies ermöglicht es, Bibliotheken mit gebündeltem Code zu finden, was beispielsweise dabei helfen kann, Pakete mit potenziellen Sicherheitslücken zu identifizieren.

Um einen Fall von Bibliotheksbündelung zu identifizieren, ermitteln Sie zunächst den Namen und die Version der gebündelten Bibliothek:

Fügen Sie dann an einer geeigneten Stelle in Ihrer Spec-Datei Provides: bundled(<Bibliotheksname>)= <Version> hinzu, wobei <Bibliotheksname> und <Version> der Name und die Version sind, die Sie oben ermittelt haben. Falls keine Version ermittelt werden konnte, verwenden Sie stattdessen`Provides: bundled(<Bibliotheksname>)`.

Zusätzlich zur Kennzeichnung der Bündelung auf diese Weise müssen Pakete, deren Upstream-Entwickler keinen Mechanismus zum Kompilieren mit Systembibliotheken besitzen, öffentlich kontaktiert werden, um einen Weg zur Unterstützung von Systembibliotheken zu finden. Falls sich die Upstream-Entwickler weigern, muss dies in der Spec-Datei vermerkt werden, entweder in Kommentaren neben dem obigen Abschnitt Provides: oder in einer zusätzlichen Datei, die in das SCM eingecheckt und durch einen Kommentar neben dem obigen Abschnitt Provides: referenziert wird.

Manchmal werden beim Linken von Binärdateien bestimmte Bibliothekspfade fest kodiert (mithilfe des Schalters -rpath oder -R). Dies wird üblicherweise als rpath bezeichnet. Normalerweise lösen der dynamische Linker und Loader (ld.so) die Abhängigkeiten der ausführbaren Datei von gemeinsam genutzten Bibliotheken auf und laden die benötigten. Wird jedoch -rpath oder -R verwendet, werden die Pfadinformationen fest in die Binärdatei codiert und von ld.so zu Beginn der Ausführung geprüft. Da der dynamische Linker von Linux in der Regel intelligenter ist als ein fest kodierter Pfad, erlauben wir die Verwendung von rpath in Fedora normalerweise nicht.

Es gibt ein Tool namens check-rpaths, das im Paket rpmdevtools enthalten ist. Es empfiehlt sich, es dem Makro %__arch_install_post in Ihrer Konfigurationsdatei ~/.rpmmacros hinzuzufügen:

Wenn check-rpaths ausgeführt wird, könnte die Ausgabe beispielsweise so aussehen:

Jeder durch check-rpaths festgestellte rpath MUSS entfernt werden.

Konfigurationsdateien müssen in Paketen als solche gekennzeichnet werden.

Als Faustregel gilt: Verwenden Sie %config(noreplace) anstelle von %config, es sei denn, Sie sind sich sicher, dass dies zu Problemen führen wird. Anders ausgedrückt: Überlegen Sie gut, bevor Sie lokale Änderungen in Konfigurationsdateien bei Paketaktualisierungen überschreiben. Ein Beispiel, wann Sie noreplace nicht verwenden sollten, ist, wenn sich die Konfigurationsdatei eines Pakets so ändert, dass die neue Paketrevision nicht zur Konfigurationsdatei der vorherigen Paketrevision kompatibel ist. Wenn Sie %config verwenden, fügen Sie der Spec-Datei einen kurzen Kommentar hinzu, der den Grund dafür erläutert.

Verwenden Sie unter /usr nicht %config oder %config(noreplace). /usr enthält in Fedora keine Konfigurationsdateien.

In der Fedora.next-Welt bieten wir eine Auswahl kuratierter Fedora-Produkte sowie die klassische Fedora-Version an. Bisher haben wir für alle Fedora-Installationen einheitliche Standardkonfigurationen verwendet. Für unterschiedliche Anwendungsfälle ergeben sich jedoch unterschiedliche Anforderungen. Informationen zur Erstellung von Paketen, die sich in verschiedenen Fedora.next-Produkten unterschiedlich verhalten sollen, finden Sie in den Richtlinien zur produktspezifischen Konfiguration.

In Fedora sind Init-Skripte im SystemV-Stil nicht erlaubt. Stattdessen müssen Systemd-Units verwendet werden.

Detaillierte Richtlinien für das Paketieren von Systemd-Units und systemd-verwalteten Diensten finden Sie hier.

Enthält ein Paket eine GUI-Anwendung, muss es auch eine korrekt installierte .desktop-Datei enthalten. Im Sinne dieser Richtlinien ist eine GUI-Anwendung jede Anwendung, die ein Fenster zeichnet und innerhalb dieses Fensters ausgeführt wird. Installierte .desktop-Dateien MÜSSEN den Standards desktop-entry-spec entsprechen. Dabei ist insbesondere auf die korrekte Verwendung der Einträge Name, GenericName, Categories und StartupNotify zu achten.

Pakete mit grafischen Anwendungen sollten AppData-Dateien enthalten. SiehePackaging:AppData für die entsprechenden Richtlinien.

Paketerstellern wird dringend empfohlen, Makros anstelle von fest kodierten Verzeichnisnamen zu verwenden (siehe RPM-Makros). In Fällen, in denen das Makro länger als der zugehörige Pfad ist oder in denen der Paketersteller die Verwendung des eigentlichen Pfads als übersichtlicher empfindet, ist es ihm jedoch gestattet, den eigentlichen Pfad anstelle des Makros zu verwenden. Es gibt einige Einschränkungen bei diesem Vorgehen:

Makros, deren Namen mit Unterstrichen beginnen, gelten im Allgemeinen alsinterne Implementierungsdetails für RPM und die zugehörigen Makropakete undSOLLTEN in Spec-Dateien NICHT referenziert werden, außer um ihre Werte festzulegen, um das Verhalten von RPM zu beeinflussen. Dies bedeutet, dass Makroformen von SystemprogrammenNICHT verwendet werden SOLLTEN. Beispielsweise sollte rm anstelle von %{__rm} verwendet werden. In manchen Fällen sind die benötigten Daten jedoch unter Namen ohne vorangestellte Unterstriche nicht verfügbar. In diesem Fall KANN das Makro mit vorangestellten Unterstrichen verwendet werden. Autoren von Makropaketenwird empfohlen, bei der Benennung von Makros, die in Spec-Dateien verwendet (und nicht festgelegt) werden sollen, auf vorangestellte Unterstriche zu verzichten.

Die Verwendung von Makros in einer Source:- oder Patch:-Zeile ist eine Stilfrage. Manche schätzen die bessere Lesbarkeit einer Quellcodezeile ohne Makros. Andere bevorzugen die einfachere Aktualisierung auf neue Versionen durch die Verwendung von Makros. In jedem Fall sollten Sie in Ihrer Spec-Datei auf Konsistenz achten und die Gültigkeit der angegebenen URLs überprüfen. Das Werkzeug spectool (aus dem Paket rpmdevtools) kann Ihnen dabei helfen, festzustellen, ob eine URL Makros enthält.

Wenn Sie die tatsächliche Zeichenkette ermitteln müssen, wenn diese Makros enthält, können Sie rpm verwenden. Um beispielsweise den tatsächlichen Wert von „Source:“ zu ermitteln, können Sie Folgendes ausführen:

Manchmal ist es notwendig, ein kurzes Skript (vielleicht einen Einzeiler) zu schreiben, das in den Abschnitten %prep, %build oder %install einer Spec-Datei ausgeführt wird, um Informationen über die Build-Umgebung zu erhalten. Um den Abhängigkeitsgraphen zu vereinfachen, sollten Spec-Dateien für diesen Zweck nur die folgenden Sprachen verwenden:

Wenn Ihr Paket ohne eine bestimmte Skriptsprache (wie Ruby oder Tcl) nicht gebaut werden kann und daher bereits eine BuildRequires-Anweisung für diese Sprache enthält, kann diese auch aus der Spec-Datei aufgerufen werden.

Hinweis: Wenn Sie Perl oder Python in Ihrer Spec-Datei verwenden (und es sich nicht bereits um eine BuildRequires-Anweisung für das Paket handelt), müssen Sie explizit eine BuildRequires-Anweisung für Perl oder Python hinzufügen.

Verwenden Sie %global anstelle von %define, es sei denn, Sie benötigen wirklich nur lokal definierte Submakros innerhalb anderer Makrodefinitionen (ein sehr seltener Fall).

Begründung: Die beiden Makrodefinitionsanweisungen verhalten sich gleich, wenn sie sich auf der obersten Ebene der Verschachtelungsebene von rpm befinden.

Werden sie jedoch in verschachtelten Makroerweiterungen verwendet (wie in %{!?foo: ... }-Konstrukten), so gilt %define theoretisch nur bis zur schließenden Klammer (lokaler Gültigkeitsbereich), während %global-Definitionen globalen Gültigkeitsbereich haben.

Beachten Sie, dass sich %define und %global nicht nur im Gültigkeitsbereich unterscheiden: Der Textkörper eines mit %define definierten Makros wird erst bei Verwendung expandiert, der Textkörper von %global hingegen bereits bei der Definition. Mithilfe von %%-Maskierung lässt sich die verzögerte Expansion von %global erzwingen.

Übersetzungsdateien werden möglicherweise von verschiedenen Programmen für unterschiedliche Frameworks verarbeitet. Stellen Sie sicher, dass Sie BuildRequires: für das richtige Paket hinzufügen, da Ihr Paket sonst möglicherweise keine Übersetzungsdateien im Buildroot generiert.

Falls das Paket gettext für Übersetzungen verwendet, fügen Sie Folgendes hinzu:

Für Qt-basierte Pakete, die die Linguist-Toolchain verwenden, fügen Sie für die Lokalisierungs-Dienstprogramme das entsprechende qtX-linguist-Paket hinzu.

Wenn Sie nur wenige Sprachdateien haben, die für ein einziges Paket nicht zu umfangreich wären,können Sie das Makro %find_lang verwenden (falls Sie Ihr Paket in separate Sprachpakete aufteilen müssen, lesen Sie bitte die Richtlinien für Sprachpakete). Dieses Makro findet alle zu Ihrem Paket gehörenden Sprachdateien (anhand des Namens) und speichert die Liste in einer Datei. Anschließend können Sie diese Datei verwenden, um alle Sprachdateien einzubinden. %find_lang sollte im Abschnitt %install Ihrer Spec-Datei ausgeführt werden, nachdem alle Dateien im Buildroot installiert wurden. Die korrekte Syntax für %find_lang lautet üblicherweise:

In manchen Fällen verwendet die Anwendung möglicherweise einen anderen Namen („name“) für ihre Sprachdateien.Sie müssen gegebenenfalls die Sprachdateien überprüfen und deren Namen ermitteln.Wenn sie beispielsweise meineanwendung.mo heißen, müssen Sie meineanwendung anstelle von %{name} an %find_lang übergeben. Nach der Ausführung von %find_lang wird eine Datei im aktiven Verzeichnis (standardmäßig im Verzeichnis der obersten Ebene des Quellverzeichnisses) erstellt. Der Name dieser Datei richtet sich nach der Option, die Sie dem Makro %find_lang übergeben haben. Üblicherweise lautet der Name %{name}.lang. Diese Datei sollten Sie anschließend in der Liste %files verwenden, um die von %find_lang erkannten Sprachdateien einzubinden. Dazu fügen Sie sie mit dem Parameter -f zu %files hinzu.

Beachten Sie, dass %find_lang zwar standardmäßig nach gettext-Sprachdateien sucht, aber auch Qt-Übersetzungen, lokalisierte Handbuchseiten und Hilfedateien verarbeiten kann.

Verwenden Sie Folgendes, um GNOME-Hilfedateien in /usr/share/gnome/help/ zu installieren:

Verwenden Sie Folgendes, um KDE-Hilfedateien in /usr/share/doc/HTML/ zu installieren:

Verwenden Sie Folgendes, um binäre Qt-Übersetzungsdateien (.qm) zu verarbeiten:

Verwenden Sie Folgendes, um übersetzte Handbuchseiten (Manpages) zu verarbeiten (dies schließt nicht die nicht übersetzten Handbuchseiten ein):

Rufen Sie /usr/lib/rpm/find-lang.sh im Terminal auf, um alle Optionen zu sehen.

Namen, die von %{name} abweichen (z.B. mehrere Manpages), müssenüber separate Aufrufe von %find_lang verarbeitet werden.

Hier ist ein Beispiel für die korrekte Verwendung von %find_lang in foo.spec mitder Anwendung „foo“, die mit gettext lokalisiert wurde, und Manpages namens „bar“ anstatt „foo“:

Pakete, die Protokolldateien erzeugen, sollten diese in einem paketspezifischen (und dem Paket zugeordneten) Verzeichnis unter %{_localstatedir}/log speichern. Sofern die paketierte Software ihre Protokolle nicht selbst rotiert, muss sie außerdem eine Logrotate-Konfigurationsdatei zur Rotation ihrer Protokolldatei(en) mitliefern.

Beim Hinzufügen von Befehlen zum Kopieren von Dateien in der Spec-Datei sollten Sie einen Befehl verwenden, der die Zeitstempel der Dateien beibehält, z.B. cp -p oder install -p.

Beim Herunterladen von Quellcode, Patches usw. empfiehlt sich die Verwendung eines Clients, der die Upstream-Zeitstempel beibehält. Beispiele hierfür sind wget -N oder curl -R. Um die Änderung für wget global zu aktivieren, fügen Sie Folgendes zu Ihrer ~/.wgetrc hinzu: timestamping = on. Für curl fügen Sie Folgendes zu Ihrer ~/.curlrc hinzu: -R.

Wo immer es möglich ist, sollte make wie folgt aufgerufen werden:

Dies beschleunigt im Allgemeinen die Bauprozesse, insbesondere auf SMP-Maschinen.

Stellen Sie jedoch sicher, dass das Paket auf diese Weise fehlerfrei erstellt wird, da einige Make-Dateien die parallele Erstellung nicht unterstützen. Daher sollten Sie Folgendes in Betracht ziehen:

Fügen Sie dies zu Ihrer Datei ~/.rpmmacros hinzu – selbst auf UP-Maschinen – da dadurch die meisten dieser Fehler aufgedeckt werden.

Pakete können Laufzeitcode enthalten, der während DNF-Transaktionen ausgeführt wird. Diese Codeabschnitte werden als Scriptlets bezeichnet und sind hier dokumentiert.

Die Bauskripte der Pakete (%prep, %build, %install, %check und %clean) dürfen nur Dateien unter %{buildroot}, %{_builddir} und gültigen temporären Verzeichnissen wie /tmp, /var/tmp (oder $TMPDIR oder %{_tmppath}, wie vom rpmbuild-Prozess festgelegt) gemäß der folgenden Matrix ändern (erstellen, ändern, löschen):

Zur weiteren Klarstellung: Das sollte unabhängig von der Benutzerkennung des Paketerstellers gelten.

Beim Erstellen von Software, für die Sie kein vollständiges Sicherheitsaudit durchgeführt haben, schützen Sie sensible Daten wie Ihren privaten GPG-Schlüssel in einem separaten Benutzerkonto.

Dasselbe gilt für Reviewer/Tester. Erstellen Sie Pakete Source-RPMs in einem separaten Konto neu, das keinen Zugriff auf sensible Daten hat.

Von der Verwendung der RPM-Funktion zum Generieren verschiebbarer Pakete wird dringend abgeraten. Sie ist schwierig korrekt zu implementieren, weder über den Installer noch über yum nutzbar und in der Regel nicht erforderlich, wenn andere Paketierungsrichtlinien befolgt werden. Sollten Sie jedoch ausnahmsweise einen triftigen Grund haben, ein Paket verschiebbar zu gestalten, MÜSSEN Sie diese Absicht und Begründung in Ihrem Antrag auf Paketprüfung angeben.

Ihr Paket sollte alle Dateien enthalten, die im Rahmen des Installationsprozesses installiert werden.

In den meisten Fällen ist es nicht erforderlich, dass mehrere Pakete identische Kopien derselben Datei enthalten. Sollte dies jedoch notwendig sein, können mehrere Pakete durchaus identische Kopien derselben Datei enthalten, sofern die folgenden Anforderungen erfüllt sind:

ODER

Darüber hinaus werden identische Dateien als Dateien definiert, die in jedem Paket hinsichtlich Inhalt, Prüfsumme, Zugriffsrechten und Speicherort im Dateisystem immer identisch sind.

Ein wichtiger Dateityp, der häufig in allen Teilpaketen identisch verwendet wird, ist der Lizenztext. In bestimmten Fällen ist es erforderlich, den Lizenztext in mehreren %files-Abschnitten innerhalb eines Pakets zu duplizieren. Weitere Informationen finden Sie unter Subpackage Licensing.

Die Verzeichniseigentümerschaften sind etwas komplexer als die von Dateien. Pakete müssen alle Verzeichnisse besitzen, in denen sie Dateien ablegen, mit folgenden Ausnahmen:

In diesem Kontext wird die „native Abhängigkeitskette“ eines Pakets als die Menge der Pakete definiert, die für die normale Funktion dieses Pakets notwendig sind. Genauer gesagt: Sie müssen ein Paket nicht allein deshalb in die Abhängigkeiten einbeziehen, weil es zufällig ein Verzeichnis besitzt, in dem Ihr Paket Dateien ablegt. Wenn Ihr Paket dieses Paket bereits aus anderen Gründen benötigt, sollte es dieses Verzeichnis nicht auch besitzen.

Wir wollen in jedem Fall verhindern, dass nicht zugeordnete Verzeichnisse auf einem System vorhanden sind. Weitere Informationen finden Sie unter Packaging:Nicht zugeordnete Verzeichnisse.

Hier sind Beispiele, die beschreiben, wie die meisten Fälle von Verzeichnisbesitz gehandhabt werden.

Manche Pakete benötigen oder nutzen dedizierte Laufzeitbenutzer- und/oder Gruppenkonten. Richtlinien für den Umgang mit diesen Fällen finden Sie in einem separaten Dokument.

Beachten Sie: Für Fedora bereitgestellte Systemdienste DÜRFEN NICHT als Benutzer nobody ausgeführt werden, sondern müssen stattdessen einem eigenen Systembenutzer zugewiesen werden.

Web-Anwendungen, die in Fedora paketiert sind, sollten ihren Inhalt in /usr/share/%{name} und NICHT in /var/www/ ablegen. Dies geschieht aus folgendem Grund:

Fedora-Pakete sollten nach Möglichkeit Konflikte vermeiden. Leider ist dies nicht immer möglich. Ausführliche Informationen zur Konfliktrichtlinie von Fedora finden Sie unter: Konflikte.

Werkzeuge wie „Alternativen“ und „Umgebungsmodule“ können auch dabei helfen, Paketkonflikte zu vermeiden.

RPM unterstützt ein Feld namens „Epoch:“, ein numerisches Feld, das, falls gesetzt, einen weiteren Qualifikator für RPM-Paketvergleiche hinzufügt. Genauer gesagt: Ist die Epoche eines Pakets gesetzt, hat sie Vorrang vor allen anderen Vergleichen (außer bei einem größeren „Epoch:“-Wert). Ist die Epoche eines Pakets nicht gesetzt, behandelt RPM sie so, als wäre sie auf 0 gesetzt.

Beispiel:

Ein Paket mit diesen Definitionen wäre höherwertig als ein Paket mit einer höheren Versionsnummer oder einem höheren Release. Da „Epoch“ für Menschen verwirrend ist (und nach der Verwendung nicht mehr aus einem Paket entfernt werden kann), sollte es in Fedora nur als letztes Mittel zur Klärung der Aktualisierungsreihenfolge eines Pakets verwendet und nach Möglichkeit vermieden werden.

Außerdem verkompliziert die Verwendung von Epoch-Werten die üblichen Richtlinien für die Paketieruung. Wenn ein Paket eine Epoche verwendet, muss diese überall dort angegeben werden, wo %{version}-%{release} verwendet wird. Wenn beispielsweise ein abhängiges Paket eine Epoche hat, muss diese beim Hinzufügen einer versionierten Abhängigkeit aufgeführt werden:

Es gibt zwei Möglichkeiten, einen Symlink zu erstellen: einen relativen oder einen absoluten Link. In Fedora wird keine der beiden Methoden bevorzugt. Paketierer sollten nach bestem Wissen und Gewissen entscheiden, welche Methode zur Erstellung symbolischer Links am besten geeignet ist.

In manchen Fällen erfordert das Ersetzen eines Symlinks zu einem Verzeichnis eine besondere Vorgehensweise. Beim Ersetzen eines Verzeichnisses durch eine beliebige Datei ist dies immer erforderlich.

In Ersetzen eines Symlinks durch ein Verzeichnis oder ein Verzeichnis durch eine Datei beliebigen Typs finden Sie Informationen dazu.

Wenn der Quellcode des Pakets eine Testsuite bereitstellt, sollte diese im Abschnitt %check ausgeführt werden, sofern dies praktikabel ist.

Es gibt spezifische Richtlinien für den Umgang mit tmpfiles.d-Konfigurationen und -Verzeichnissen (in /run und /run/lock): Tmpfiles.d.

Sollte es notwendig werden, ein bestehendes Paket umzubenennen oder zu ersetzen, sollte die Änderung für Endbenutzer im neuen Paket – soweit anwendbar – transparent gestaltet werden.

Wird ein Paket umbenannt, ohne dass sich die Funktionalität ändert, oder ist es ein ausreichend kompatibler Ersatz für ein bestehendes Paket (wobei „ausreichend“ bedeutet, dass es nur Änderungen von der Größenordnung enthält, die üblicherweise bei Versionsaktualisierungen vorkommen), so stellen Sie saubere Aktualisierungspfade und Kompatibilität auf folgende Weise sicher:

$provEVR bezieht sich auf ein (Epochen-)Versions-Release-Tupel, das das ursprüngliche, unveränderte Paket gehabt hätte, wenn seine Version oder sein Release erhöht worden wäre. Normalerweise verwendet man hier Makros, da der Wert von provesEVR mit dem Versions- und Release-Fortschritt des umbenannten Pakets weiter steigen sollte. $obsEVR ist ein (Epochen-)Versions-Release-Tupel, das so angeordnet ist, dass ein sauberer Aktualisierungspfad vorhanden ist, ohne den Versionsbereich unnötig nach oben zu erweitern. Normalerweise verwendet man hierfür keine Makros, da man lediglich versucht, über die letzte bekannte Version unter dem alten Namen hinauszugehen.

Wenn ein Paket ein bestehendes Paket ersetzt, ohne ein ausreichend kompatibler Ersatz im oben definierten Sinne zu sein, verwenden Sie nur die Zeile Obsoletes: aus dem obigen Beispiel.

Wenn stillgelegte Pakete von Endbenutzerrechnern entfernt werden müssen, weil sie Abhängigkeitsprobleme verursachen, die Aktualisierungen behindern oder anderweitig schädlich sind, sollte ein Paketierer beantragen, dass Obsoletes: zu fedora-obsolete-packages hinzugefügt wird. Erstellen Sie dazu hier einfach ein Bugzilla-Ticket. Bitte geben Sie an, welche Pakete als veraltet markiert werden müssen, welche genauen Versionen betroffen sind und warum sie nicht installiert bleiben dürfen.

Wenn das veraltete Paket eine Epoche hatte, muss diese sowohl in Provides: als auch in Obsoletes: beibehalten werden. Angenommen, foo wird in bar umbenannt, bar ist zu foo kompatibel und die letzte Version des foo-Pakets ist foo-1.0-3.fcNN mit Epoch: 2. Folgendes sollte dann zu bar hinzugefügt werden (und analog für alle Teilpakete, sofern zutreffend):

Explizite Provides:-Anweisungen müssen berücksichtigen, ob das Paket Elemente bereitstellt, die architekturunabhängig oder architekturspezifisch verwendet werden können. Für Pakete, die nicht architekturunabhängig sind, sollte Provides: architekturspezifisch gemacht werden, indem das Makro %{?_isa} am Ende der Zeichenkette in „Provides:“ angehängt wird (z.B. Provides: foo%{?_isa} = 2:%{version}-%{release}). Pakete, die explizit architekturunabhängige Elemente bereitstellen (z.B. solche, deren Abhängigkeiten nicht dieselbe Architektur haben müssen), benötigen dieses Makro nicht. In manchen Fällen stellt ein Paket mehrere Elemente bereit, von denen einige nur von Abhängigkeiten derselben Architektur und andere von Abhängigkeiten beliebiger Architektur verwendet werden können. In solchen Fällen sind sowohl architekturspezifische als auch architekturunabhängige „Provides:“ gerechtfertigt.

Beispiele für Pakete, die explizit nur architekturspezifische Provides:-Informationen bereitstellen sollten, sind native Codebibliotheken oder Plug-ins und ihre zugehörigen -devel-Pakete. Pakete, die explizit nur architekturunabhängige Provides:-Informationen bereitstellen sollten, umfassen die meisten eigenständigen Programme (zusätzlich zu allen noarch-Paketen). Auch wenn diese Programme selbst architekturspezifisch sein können, sollte die Architektur für die Clients, die sie ausführen, in den meisten Fällen irrelevant sein. Ein Paket, das beispielsweise sowohl eine native Codebibliothek als auch eine Interpretersprachenschnittstelle zu dieser Bibliothek explizit bereitstellt, sollte sowohl architekturspezifische (für Clients der nativen Codebibliothek) als auch architekturunabhängige (für Clients der Interpretersprachenschnittstelle) Provides:-Informationen enthalten.

Wenn es keine Standardbenennung für ein Paket oder andere langfristige Namenskompatibilitätsanforderungen im Zusammenhang mit der Umbenennung gibt, sollte davon ausgegangen werden, dass die „Provides“ veraltet und nur von kurzer Dauer sind und in der Distributionsversion nach der nächsten entfernt werden (das heißt, wenn sie in FC-X eingeführt wurden, sollten sie in allen nachfolgenden Paketrevisionen für Distributionen FC-X und FC-(X+1) beibehalten und in FC-(X+2) entfernt werden). Die Distributionsversion, in der die Entfernung geplant ist, sollte in einem Kommentar in der Spec-Datei dokumentiert werden. Die Betreuer betroffener Pakete sollten benachrichtigt und dazu angehalten werden, auf den neuen Namen umzusteigen. Aufwärtskompatibilitäts-Provides in älteren Distributionszweigen können berücksichtigt werden, um es den Paketbetreuern zu ermöglichen, dieselben einfachen Spec-Dateien zwischen den Zweigen beizubehalten und dennoch auf den neueren Namen umzusteigen.

Für Pakete, die üblicherweise nicht über den Paketnamen als Abhängigkeit eingebunden werden, wie z.B. reine Bibliothekspakete (die über Bibliotheks-Soname-Abhängigkeiten eingebunden werden), ist das Hinzufügen von Provides normalerweise nicht erforderlich. Beachten Sie jedoch, dass die -devel-Teilpakete von Bibliothekspaketen als Bauabhängigkeiten über den Paketnamen eingebunden werden, so dass das Hinzufügen von Provides dort oft angebracht ist.

Es gibt ein Verfahren, um anzuzeigen, dass ein Paket veraltet ist und möglicherweise in Zukunft aus der Distribution entfernt wird. Siehe Pakete als veraltet markieren.

Wenn eine Anwendung native und stabile Unterstützung für IPv4 und IPv6 bietet und IPv4 durch die Unterstützung für IPv6 nicht beeinträchtigt wird, dann MÜSSEN beide im Fedora-Paket aktiviert sein.

Details zum Paketieren von Cron-Dateien finden Sie hier.

Wenn eine Aktualisierung Ihres Pakets ein bekanntes Sicherheitsproblem (zum Zeitpunkt der Aktualisierung) mit einer zugehörigen CVE-Nummer (Common Vulnerabilities and Exposures) behebt, sollten Sie die CVE-Nummer im RPM-Änderungsprotokolleintrag angeben.

Pakete im Fedora-Buildsystem werden in einem simulierten Chroot ohne Internetzugang erstellt. Pakete dürfen keine Netzwerkressourcen verwenden, die sie nicht selbst erzeugen (z.B. für Tests). Der Quellcode darf in keinem Fall von externen Quellen heruntergeladen werden, sondern ausschließlich aus dem Lookaside-Cache und/oder dem Fedora-Git-Repository.

Falls Ihr Paket zirkuläre Abhängigkeiten zur Bauzeit erzeugt, sollten Sie dieses Makro verwenden, um Ihr Paket zu initialisieren („Bootstrapping“):

Wenn Ihr Paket explizit über Provides: eine Funktionalität bereitstellt, die beim Start fehlt, dann sollte diese Bereitstellung wie folgt aussehen:

Bitte beachten Sie, dass die Verwendung vorkompilierter Binärdateien im Bootstrap-Prozess weiterhin eine Ausnahmegenehmigung des Packaging Committee erfordert, wie in der [General Exception Policy] beschrieben.

Anwendungen, die die kryptografischen Protokolle SSL oder TLS verwenden, MÜSSEN den Kryptografie-Richtlinien folgen.

Beim Paketieren von Skriptdateien, bei denen der zu verwendende Interpreter in der ersten Zeile des Skripts (der Shebang-Zeile) nach #! angegeben wird, gelten die folgenden Regeln:

Shebang-Zeilen für ausführbare Skripte werden automatisch angepasst, um Aufrufe von env in die direkte Verwendung der entsprechenden ausführbaren Datei in /usr/bin umzuwandeln. Verschiedene Prüfungen stellen sicher, dass die Shebang-Zeilen gültig sind, und der Bauprozess kann dadurch fehlschlagen. Schließlich können auch weitere sprachspezifische Anpassungen vorgenommen werden. Daher ist es im Allgemeinen unnötig, ausführbare Skripte manuell zu ändern, um die Verwendung von env zu korrigieren, solange diese Funktionalität aktiviert ist.

Falls die automatischen Prüfungen und Änderungen ein Paket beschädigen, gibt es zwei primäre Optionen:

Wenn das Skript ausführbar bleiben muss (und nur dann!) und nicht so verändert werden kann, dass es die Prüfungen besteht, kann der Betreuer die Prüfungen und Änderungen deaktivieren. Es ist auch möglich, die Funktionalität für bestimmte Pfade oder Shebang-Zeilen zu deaktivieren, indem __brp_mangle_shebangs_exclude_from bzw. %__brp_mangle_shebangs_exclude gesetzt werden. Die Syntax entspricht den Einstellungen in Packaging:AutoProvidesAndRequiresFiltering. Alternativ kann die Funktionalität vollständig deaktiviert werden, indem %undefine __brp_mangle_shebangs am Anfang der Spec-Datei hinzugefügt wird.

BRP-Skripte werden am Ende von %install (über das Makro %__os_install_post) eingefügt und führen automatische Plausibilitätsprüfungen bzw. Anpassungen an den im Build-Root installierten Dateien durch.

Alle Pakete SOLLTEN grundsätzlich alle BRP-Skripte ausführen, aber manchmal ist es notwendig, dass ein Paket bestimmte Skripte deaktiviert. Es ist möglich, jedes BRP-Skript zu deaktivieren, indem die entsprechende Variable auf %{nil} gesetzt wird. So können Sie beispielsweise das Skript brp-python-bytecompile deaktivieren:

Jedes Paket, das ein BRP-Skript auf diese Weise deaktiviert, MUSS den Grund in einem zugehörigen Kommentar angeben. Eine Liste der standardmäßig ausgeführten BRP-Skripte erhalten Sie mit folgendem Befehl:

Eine Liste aller BRP-Skripte erhalten Sie mit folgendem Aufruf:

Diese Richtlinien und die unten stehenden anwendungsspezifischen Richtlinien decken größtenteils die Paketierung für sowohl Fedora als auch EPEL ab. Es gibt jedoch notwendigerweise einige Unterschiede. Für die Paketierung für EPEL lesen Sie bitte zusätzlich die EPEL-Paketierungsrichtlinien, um weitere Informationen zu erhalten.

Für einige Anwendungen, Sprachen und Build-Systeme gibt es spezifische Richtlinien, die auf eigenen Seiten zu finden sind: