Richtlinien für Paket-Reviews

Das FPC gewährt eine ausdrückliche Ausnahme von diesem Verfahren, wie hier angegeben.

Das Paket wird so erstellt, dass mehrere Versionen desselben Pakets in der Distribution (oder zwischen EPEL und RHEL) parallel existieren können. Das Paket MUSS gemäß den Namensrichtlinien korrekt benannt sein und DARF NICHT mit anderen Versionen desselben Pakets in Konflikt geraten.

Das Paket existiert sowohl in Fedora als auch in RHEL, aber der Paketierer möchte es in EPEL unter einem alternativen Namen ausliefern (wie im EPEL-Regelwerk gefordert), um ein Teilpaket bereitzustellen, das zwar in Fedora, aber nicht in RHEL existiert (oder nicht ausgeliefert wird).

fXX-backgrounds (Ticket): Dieses Paket folgt nicht den üblichen Namenskonventionen für versionierte Pakete, sondern es wird für jede Fedora-Version ein neues erstellt.

… beim Umbenennen eines vorhandenen Pakets,

beim Verschieben einer Teilkomponente eines vorhandenen Pakets in ein separates Quellpaket,

beim Hinzufügen einer alternativen Version („Kompatibilitätspaket“) eines vorhandenen Pakets, oder

beim Hinzufügen einer EPEL-exklusiven alternativen Version eines vorhandenen Pakets.

MUSS: rpmlint muss auf dem Source-RPM und allen beim Bau erzeugten Binär-RPMs ausgeführt werden. Die Ausgabe sollte im Review veröffentlicht werden. Siehe rpmlint verwenden.

MUSS: Das Paket muss gemäß den Richtlinien für die Paketbenennung benannt werden.

MUSS: Der Name der Spec-Datei muss mit dem Namen des Basispakets %{name} im Format %{name}.spec übereinstimmen, es sei denn, Ihrem Paket wurde eine Ausnahme gewährt. Siehe Benennung von Spec-Dateien.

MUSS: Das Paket muss den Paketbaurichtlinien entsprechen.

MUSS: Das Lizenz des Pakets muss zu den von Fedora genehmigten Lizenzen gehören und den Richtlinien für die Lizenzierung entsprechen.

MUSS: Das Feld „License“ in der Spec-Datei muss mit der tatsächlichen Lizenz übereinstimmen. Siehe Gültige Kurznamen für Lizenzen.

MUSS: Wenn (und nur wenn) das Quellpaket den Lizenztext in einer eigenen Datei enthält, muss diese Datei mit dem Lizenztext für das Paket in %license eingebunden werden. Siehe Lizenztext.

MUSS: Die Spec-Datei muss in amerikanischem Englisch verfasst sein. Siehe Paketbaurichtlinien: Summary und Description.

MUSS: Die Spec-Datei für das Paket MUSS lesbar sein. Siehe Paketbaurichtlinien: Lesbarkeit der Spec-Datei.

MUSS: Die zum Erstellen des Pakets verwendeten Quellen müssen mit der Upstream-Quelle übereinstimmen, wie in der URL in der spec-Datei angegeben. Reviewer sollten hierfür sha256sum verwenden, da diese Funktion von der Datei sources nach dem Import in Git verwendet wird. Falls für dieses Paket keine Upstream-URL angegeben werden kann, finden Sie in den Richtlinien für Quell-URLs Hinweise zum weiteren Vorgehen.

MUSS: Das Paket MUSS auf mindestens einer primären Architektur erfolgreich kompiliert und in binäre RPM-Dateien umgewandelt werden. Siehe Architekturunterstützung.

MUSS: Wenn das Paket auf einer bestimmten Architektur nicht kompiliert, erstellt oder ausgeführt werden kann, müssen diese Architekturen in der Spec-Datei unter ExcludeArch aufgeführt werden. Für jede in ExcludeArch aufgeführte Architektur MUSS ein Bugzilla-Fehlerbericht erstellt werden, der den Grund für das Fehlschlagen der Kompilierung/Erstellung/Ausführung des Pakets auf dieser Architektur beschreibt. Die Bugnummer MUSS als Kommentar neben der entsprechenden ExcludeArch-Zeile angegeben werden. Siehe Architekturbezogene Baufehler.

MUSS: Alle Bauabhängigkeiten müssen in BuildRequires aufgeführt sein. Siehe Bauabhängigkeiten (BuildRequires).

MUSS: Die Spec-Datei MUSS Locales korrekt verarbeiten. Dies geschieht mithilfe des Makros %find_lang. Die Verwendung von %{_datadir}/locale/* ist strengstens untersagt. Siehe Umgang mit Locale-Dateien.

MUSS: Pakete dürfen keine Kopien von Systembibliotheken bündeln. Siehe Bündelung und Duplizierung von Systembibliotheken.

MUSS: Wenn das Paket für die Verschiebung vorgesehen ist, muss der Paketierer dies im Review-Antrag angeben und die Gründe für die Verschiebung des jeweiligen Pakets erläutern. Andernfalls gilt die Verwendung von „Prefix: /usr“ als Ausschlusskriterium. Siehe Verschiebbare Pakete.

MUSS: Ein Paket muss Eigentümer aller von ihm erstellten Verzeichnisse sein. Erstellt es ein Verzeichnis nicht, das es verwendet, sollte es ein anderes Paket benötigen, das dieses Verzeichnis erstellt. Siehe Eigentümerschaft von Dateien und Verzeichnissen.

MUSS: Ein Fedora-Paket darf eine Datei nicht mehr als einmal in den %files-Einträgen der Spec-Datei auflisten (erwähnenswerte Ausnahme: Lizenztexte in bestimmten Fällen). Siehe Packaging Guidelines: Duplicate Files.

MUSS: Die Dateiberechtigungen müssen korrekt gesetzt sein. Ausführbare Dateien sollten beispielsweise mit Ausführungsberechtigungen versehen werden. Siehe Dateizugriffsrechte.

MUSS: Jedes Paket muss Makros konsistent verwenden. Siehe Makros.

MUSS: Das Paket muss Code oder zulässige Inhalte enthalten. Siehe Was kann paketiert werden?.

MUSS: Große Dokumentationsdateien müssen in ein Teilpaket mit der Endung -doc ausgelagert werden (die Definition von „groß“ liegt im Ermessen des Paketierers, ist aber nicht auf die Größe beschränkt; „groß“ kann sich sowohl auf die Größe als auch auf die Anzahl beziehen). Siehe Dokumentation.

MUSS: Wenn ein Paket etwas als %doc enthält, darf dies die Anwendung zur Laufzeit nicht beeinträchtigen. Zusammengefasst: Wenn es in %doc enthalten ist, muss das Programm auch ohne dieses Dokument ordnungsgemäß funktionieren. Siehe Dokumentation.

MUSS: Statische Bibliotheken gehören in ein -static-Teilpaket. Siehe Paketieren statischer Bibliotheken.

MUSS: Entwicklungsdateien gehören in ein -devel-Teilpaket. Siehe Devel-Pakete.

MUSS: In den allermeisten Fällen müssen Entwicklungspakete das Basispaket mit einer vollständig versionierten Abhängigkeit einbinden: Requires: %{name}%{?_isa} = %{version}-%{release}. Siehe Abhängigkeit vom Basispaket.

MUSS: Pakete DÜRFEN KEINE .la-libtool-Archive enthalten. Diese müssen in der Spec-Datei entfernt werden, falls sie gebaut werden. Siehe Paketieren statischer Bibliotheken.

MUSS: Pakete mit GUI-Anwendungen müssen eine %{name}.desktop-Datei enthalten, die mit desktop-file-install im Abschnitt %install korrekt installiert werden muss. Falls Sie der Meinung sind, dass Ihre paketierte GUI-Anwendung keine .desktop-Datei benötigt, müssen Sie dies in der Spec-Datei begründen. Siehe Desktop-Dateien.

MUSS: Pakete dürfen keine Dateien oder Verzeichnisse besitzen, die bereits anderen Paketen gehören. Grundsätzlich gilt: Das zuerst installierte Paket sollte die Dateien oder Verzeichnisse besitzen, auf die andere Pakete zugreifen. Das bedeutet beispielsweise, dass kein Paket in Fedora jemals die Besitzrechte mit Dateien oder Verzeichnissen teilen sollte, die dem Paket filesystem oder man gehören. Sollten Sie einen triftigen Grund haben, eine Datei oder ein Verzeichnis zu besitzen, das bereits einem anderen Paket gehört, tragenSie diesen bitte zum Review vor. Siehe Eigentümerschaft von Dateien und Verzeichnissen.

MUSS: Alle Dateinamen in RPM-Paketen müssen gültiges UTF-8 sein. Siehe Nicht-ASCII-Dateinamen.

MUSS: Pakete, die der Distribution hinzugefügt werden, DÜRFEN NICHT von Paketen abhängen, die als veraltet gekennzeichnet wurden. Siehe Pakete als veraltet markieren.

SOLLTE: Falls das Quellpaket die Lizenztexte nicht als separate Datei vom Upstream-Entwickler enthält, SOLLTE der Paketierer den Upstream-Entwickler bitten, diese hinzuzufügen. Siehe Lizenztext.

SOLLTE: Der Reviewer sollte testen, ob das Paket in Mock gebaut werden kann. Siehe Using Mock to test package builds.

SOLLTE: Das Paket sollte auf allen unterstützten Architekturen kompilieren und zu binären RPM-Dateien erstellt werden können. Siehe Architekturunterstützung.

SOLLTEN: Gemeinsam genutzte Bibliotheken sollten versionierte Symbole bereitstellen (wie in „libc.so.6(GLIBC_2.41)(64bit)“). Die Betreuer werden ermutigt, mit den Upstream-Projekten zusammenzuarbeiten, die noch keine versionierten Symbole bereitstellen, um diese hinzuzufügen. Siehe Versionierte Symbole.

SOLLTE: Der Reviewer sollte testen, ob das Paket wie beschrieben funktioniert. Ein Paket sollte beispielsweise nicht zu einem Segmentierungsfehler führen, anstatt ausgeführt zu werden.

SOLLTE: Falls Scriptlets verwendet werden, müssen diese Scriptlets sinnvoll sein. Diese Formulierung ist vage und überlässt die Beurteilung der Sinnhaftigkeit den Prüfern. Siehe Scriptlets.

SOLLTE: Normalerweise sollten Teilpakete – außer dem Entwicklungspaket – das Basispaket mit einer vollständig versionierten Abhängigkeit einbinden. Siehe Abhängigkeit vom Basispaket.

SOLLTE: Die Platzierung von pkgconfig-Dateien (.pc) hängt von ihrem Anwendungsfall ab. Da diese üblicherweise für Entwicklungszwecke verwendet werden, sollten sie in ein -devel-Paket ausgelagert werden. Eine sinnvolle Ausnahme besteht, wenn das Hauptpaket selbst ein Entwicklungswerkzeug ist, das nicht in einer Benutzerlaufzeitumgebung installiert ist, z.B. gcc oder gdb. Siehe Pkgconfig-Dateien.

SOLLTE: Ihr Paket sollte Handbuchseiten für Binärdateien/Skripte enthalten. Sollte dies nicht der Fall sein, arbeiten Sie mit dem Entwicklerteam zusammen, um diese gegebenenfalls hinzuzufügen. Siehe Handbuchseiten.