Richtlinien für Paket-Reviews

Dies ist eine Richtlinie für Paket-Reviews. Eine vollständige Liste aller zu prüfenden Punkte ist nicht möglich, jedoch wurde alles unternommen, um dieses Dokument so umfassend wie möglich zu gestalten. Prüfer und Mitwirkende (Paketierer) sollten bei Unklarheiten ihr bestes Urteilsvermögen einsetzen und im Zweifelsfall die Fedora-Paketbau-Mailingliste konsultieren.

Richtlinien für Paket-Reviews

Mitwirkende und Reviewer MÜSSEN den unter Paket-Review-Prozess beschriebenen Prozess befolgen, mit den im nächsten Abschnitt aufgeführten Ausnahmen.

Ausnahmen für Paket-Reviews

Für den oben verlinkten Paket-Review-Prozess gelten die folgenden Ausnahmen:

  • 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).

Ausnahmen, die explizit gewährt werden:

  • 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.

Gelockerte Regeln für bestehende Komponenten

Einige Richtlinien, die für „neue“ Pakete gelten, müssen nicht angewendet werden, wenn Pakete überprüft werden, die der Distribution nur in dem Sinne „hinzugefügt“ wurden, dass der Name des Quellpakets „neu“ ist, die Komponente aber bereits in einem bestehenden Paket enthalten war. Das heißt …

  • … 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.

Beispielsweise ist es zulässig, dass ein „neues“ Paket wie dieses von Paketen abhängt, die als deprecated() gekennzeichnet sind, da keine tatsächlich neue Komponente von dem veralteten Paket abhängen wird.

Beim Review zu überprüfende Dinge

Es gibt unzählige Punkte, die bei einem Review zu beachten sind. Diese Liste soll neuen Reviewern helfen, die relevanten Aspekte zu identifizieren, ist aber keinesfalls vollständig. Reviewer sollten bei der Bewertung von Softwarepaketen ihr eigenes Urteilsvermögen einsetzen. Die aufgeführten Punkte lassen sich in zwei Kategorien einteilen: SOLLTE und MUSS.

  • 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.

  • MUST: The spec file must be written in American English. See Packaging Guidelines: Summary and description.

  • MUST: The spec file for the package MUST be legible. See Packaging Guidelines: Spec Legibility.

  • MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the sources file once imported into git. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.

  • MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. See Packaging Guidelines: Architecture Support.

  • MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. See Packaging Guidelines: Architecture Build Failures.

  • MUST: All build dependencies must be listed in BuildRequires. See Packaging Guidelines: Build-Time Dependencies (BuildRequires).

  • MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. See Packaging Guidelines: Handling Locale Files.

  • MUST: Packages must NOT bundle copies of system libraries. See Packaging Guidelines: Bundling and Duplication of System Libraries.

  • MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. See Packaging Guidelines: Relocatable Packages.

  • MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. See Packaging Guidelines: File And Directory Ownership.

  • MUST: A Fedora package must not list a file more than once in the spec file’s %files listings. (Notable exception: license texts in specific situations)See Packaging Guidelines: Duplicate Files.

  • MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. See Packaging Guidelines: File Permissions.

  • MUST: Each package must consistently use macros. See Packaging Guidelines: Macros.

  • MUST: The package must contain code, or permissible content. See What Can Be Packaged.

  • MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager’s best judgement, but is not restricted to size. Large can refer to either size or quantity). See Packaging Guidelines: Documentation.

  • MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. See Packaging Guidelines: Documentation.

  • MUST: Static libraries must be in a -static package. See Packaging Guidelines: Packaging Static Libraries.

  • MUST: Development files must be in a -devel package. See Packaging Guidelines: Devel Packages.

  • MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}. See Packaging Guidelines: Requiring Base Package.

  • MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. See Packaging Guidelines: Packaging Static Libraries.

  • MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. See Packaging Guidelines: Desktop files.

  • MUST: Packages must not own files or directories that are already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. See Packaging Guidelines: File and Directory Ownership.

  • MUST: All filenames in rpm packages must be valid UTF-8. See Packaging Guidelines: Non-ASCII Filenames.

  • MUST: Packages being added to the distribution MUST NOT depend on any packages which have been marked as being deprecated. See Deprecating Packages.

  • SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. See Licensing Guidelines: License Text.

  • SHOULD: The reviewer should test that the package builds in mock. See Using Mock to test package builds.

  • SHOULD: The package should compile and build into binary rpms on all supported architectures. See Packaging Guidelines: Architecture Support.

  • SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.

  • SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. See Packaging Guidelines: Scriptlets.

  • SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. See Packaging Guidelines: Requiring Base Package.

  • SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. See Packaging Guidelines: Pkgconfig Files.

  • SHOULD: Your package should contain man pages for binaries/scripts. If it doesn’t, work with upstream to add them where they make sense. See Packaging Guidelines: Manpages.

A note on dependencies

It is often useful to submit a package for review along with its dependencies in separate tickets. As long as the submitter sets up the Depends on: and Blocks: fields in BugZilla properly, this is not an issue, and it is perfectly possible to review these packages before the full dependency chain is in the distribution (by maintaining a local repository, building and installing the packages locally, or maintaining a COPR).

However, please keep in mind that you cannot do koji builds unless all of the build dependencies are met (because you cannot provide additional dependencies to koji) and when the time comes to build these packages, they must be built in order and you must wait between builds for the dependencies to make it into the appropriate branch of the distribution. This can be automated using side tags and chain builds.

Please also note that while you may actually be able to build a package because all of its build-time dependencies are met, the package may still be non-installable (and thus useless) if its runtime dependencies are not met. A package MUST not be built if any of its runtime dependencies are unsatisfied.

Want to help? Learn how to contribute to Fedora Docs ›