Fedora-Paketbaurichtlinien

Paketersteller DÜRFEN KEINE Fedora-Markenzeichen, einschließlich des Fedora-Logos, der Fedora-Logo-Symbole oder Grafiken, die das Fedora-Logo enthalten, hinzufügen. Diese Elemente MÜSSEN dem Paket fedora-logos hinzugefügt werden. Ihre Pakete installieren die Logos, indem sie vom Paket fedora-logos abhängen. Sollte die Originalsoftware Fedora-Markenzeichen enthalten, die Ihrer Meinung nach unsachgemäß verwendet werden, wenden Sie sich bitte per E-Mail an legal@fedoraproject.org.

Dies liegt daran, dass das Fedora-Logo eine Marke ist, die einem anderen rechtlichen Rahmen unterliegt als Softwarecode. Es darf nur unter Bedingungen verbreitet werden, die die Marke schützen. Die separate Speicherung der Fedora-Marken in einem eigenen Paket anstatt deren Verteilung auf verschiedene andere Pakete ist außerdem unerlässlich, um Remixes zu ermöglichen, die notwendigerweise die Fedora-Marke nicht verwenden dürfen und stattdessen ein eigenes *-logos-Paket erstellen oder das generic-logos-Paket verwenden müssen.

Es obliegt dem Paketersteller, den Hauptzweck eines Pakets festzulegen. Oftmals hat der Upstream-Entwickler dies bereits durch seine Namenswahl getan, und diese Wahl SOLLTE vom Fedora-Paketersteller übernommen werden.

Viele Pakete enthalten, unabhängig von ihrem Hauptzweck, sowohl Anwendungen als auch Bibliotheken. In diesem Fall SOLLTEN eine oder beide Komponenten in Teilpaketen verpackt werden, damit andere Anwendungen nur von der Bibliothek und nicht von der/den zugehörigen Anwendung(en) abhängen. Die Installation einer Anwendung, die von einer Bibliothek oder einem Dienst abhängt, sollte nicht automatisch andere Anwendungen mitinstallieren, die mit dieser Bibliothek oder diesem Dienst verknüpft sind.

Sie Spec-Datei MUSS nach dem Schema %{name}.spec benannt werden. Das heißt, wenn Ihr Paket example heißt, muss die Spec-Datei example.spec heißen.

Alle Spec-Dateien MÜSSEN lesbar sein und so gepflegt werden, dass die Gemeinschaft der Paketentwickler sie verstehen und mit ihnen arbeiten kann.

Um die Lesbarkeit zu erleichtern, dürfen in Fedora-Paketen ausschließlich Makros und Bedingungsanweisungen für Fedora und EPEL verwendet werden. Die Verwendung von Makros und Bedingungsanweisungen für andere Distributionen, einschließlich Fedora-Derivaten, ist in den Spec-Dateien von Paketen in den Haupt-Fedora-Paketquellen nicht gestattet, es sei denn, diese Makros und Bedingungsanweisungen sind auch in Fedora vorhanden.

Sofern Sie keine Zeichen außerhalb des ASCII-Zeichensatzes benötigen, müssen Sie sich keine Gedanken über die Kodierung der Spec-Datei machen. Falls Sie Nicht-ASCII-Zeichen benötigen, speichern Sie Ihre Spec-Dateien als UTF-8. Wenn Sie sich nicht sicher sind, welche Zeichen ASCII-Zeichen sind, konsultieren Sie bitte diese Tabelle.

Das Git-Archiv von Fedora ist der offizielle Speicherort für Fedora-Spec-Dateien.Paketbetreuer MÜSSEN damit rechnen, dass andere Betreuer und automatisierte WerkzeugeÄnderungen an ihren Paketen vornehmen, möglicherweise ohne vorherige Kommunikation (obwohl Kommunikation stets empfohlen wird). Wenn einige Betreuerzusätzlich Kopien einer Spec-Datei in einer externen Paketquelle speichern,MÜSSEN sie bereit sein, Änderungen an der Spec-Datei in der Fedora-Paketquelle zusammenzuführen,und DÜRFEN diese Änderungen NICHT mit einer Kopie aus einer externen Paketquelleoder mit fedpkg import überschreiben.

Das Verifizierungsverfahren erfordert eine oder mehrere OpenPGP-Schlüsselbunddateien mit öffentlichen Schlüsseln des Upstream-Projekts. Die Schlüsselbünde müssen zusammen alle Schlüssel enthalten, die zur Bestätigung der Authentizität der Quellen als vertrauenswürdig gelten, und dürfen keine weiteren Schlüssel enthalten.

Idealerweise veröffentlicht das Upstream-Projekt einen solchen Schlüsselbund als herunterladbare Datei. Laden Sie diese Datei herunter und tun Sie alles Erdenkliche, um ihre Authentizität zu überprüfen. Fügen Sie sie anschließend unverändert dem Paket-SCM hinzu und geben Sie die zugehörige URL in der Spec-Datei an, damit andere sie überprüfen können. Die URL MUSS nach Möglichkeit HTTPS oder ein ähnlich authentifiziertes Protokoll verwenden.

Selbst wenn Sie den Schlüssel beim ersten Hinzufügen noch nicht verifizieren können, erhöht er dennoch die Sicherheit durch Vertrauen bei der ersten Verwendung. Er stellt sicher, dass zukünftige Angriffe erkannt werden, wenn der Schlüssel der richtige ist, oder dass ein aktueller Angriff später erkannt wird, wenn zukünftige Versionen mit dem korrekten Schlüssel signiert werden.

Die Überprüfung der Quelldateien MUSS zuerst im Abschnitt %prep der Spec-Datei erfolgen, bevor potenziell kompromittierter Code ausgeführt wird. Die Überprüfung MUSS mit dem Makro %{openpgpverify} durchgeführt werden, welches zu einem Befehl expandiert, dessen Parameter die Pfadnamen des Schlüsselbunds, der Signatur und der signierten Datei sein müssen. BuildRequires: openpgpverify ist für die Durchführung der Überprüfung erforderlich.

Jede separate Signaturdatei (z. B. foo.tar.gz.asc oder foo.tar.gz.sig) musszusammen mit dem Quellcode in den Lookaside-Cache des Pakets hochgeladen werden, währendder Schlüsselbund direkt in das SCM des Pakets eingecheckt werden muss.

Das folgende Format muss verwendet werden:

Die erste Quelle ist das eigentliche Tarball-Archiv, die zweite die Signatur von upstream und die dritte der Schlüsselbund.

Das Makro unterstützt auch eine Kurzform, bei der Sie lediglich die Quellennummern angeben:

Falls der Upstream-Tarball mit alten Schlüsseln signiert wurde, die auf dem SHA1-Hashverfahren basieren oder anderweitig nicht zum aktuellen OpenPGP-Standard kompatibel sind, kann bis zur Behebung dieses Problems das ältere %{gpgverify}-Makro verwendet werden (es verfügt über dieselbe API und lässt sich als direkter Ersatz nutzen). Die Upstream-Betreuer sollten dazu angehalten werden, ihre Schlüssel zu aktualisieren – beispielsweise unter Verwendung der folgenden Anleitung:

https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel

Wenn der ursprüngliche Tarball eines Pakets geändert werden muss, beispielsweise weil er unzulässige Elemente enthält, kann der Tarball nicht im Rahmen des Bauprozesses verifiziert werden. In diesem Fall muss der ursprüngliche OpenPGP-Schlüsselbund weiterhin im Paket-SCM enthalten sein, und die Anweisungen/das Skript zum Erstellen des reduzierten Tarballs müssen die ursprüngliche Quelle verifizieren.

Wenn das Upstream-Projekt keine Schlüsselbunddatei veröffentlicht (z.B. wenn esnur einen Fingerabdruck auf seiner Website veröffentlicht und auf ein Schlüsselserver-Netzwerk zum Herunterladen des Schlüssels verweist), müssen Sie möglicherweise einen Schlüsselbund erstellen, nachdem Sie den Schlüssel verifiziert haben. In diesem Fall gibt es keine Upstream-URL zum Schlüsselbund,daher sollten Sie stattdessen in einem Kommentar in der Spec-Datei dokumentieren, wie Sie den Schlüsselbund erstellt haben. Ein minimaler Schlüsselbund mit dem Schlüssel mit dem Fingerabdruck`7D33D762FD6C35130481347FDB4B54CBA4826A18` kann mit dem folgenden Befehl erstellt werden:

oder mit der Sequoia-Befehlszeilenschnittstelle:

Wenn der Upstream-Anbieter einen Tarball anders signiert hat, beispielsweise nur die unkomprimierte Tarball-Version, aber dann eine komprimierte Version verteilt hat, muss der Verifizierungsschritt entsprechend angepasst werden, zum Beispiel:

Wenn die Daten und die Signatur in einer einzigen Datei kombiniert werden, dann müssen die signierten Daten in eine Ausgabedatei geschrieben werden:

Pakete, die für den Start von Fedora unerlässlich sind, können das Flag bootstrap flag verwenden, um die Überprüfung vor dem Kompilieren von GPGverify und GnuPG zu überspringen.

Wenn Sie Hilfe benötigen, um Ihr Paket an diese Richtlinie anzupassen, oder wenn Sie nicht wissen, was zu tun ist, wenn ein Bauvorgang bei der Signaturprüfung fehlschlägt, sollten Sie sich an die Fedora-Entwickler-Mailingliste wenden, bevor Sie die Prüfung umgehen, um sicherzustellen, dass Sie keine kompromittierte Software erstellen.

Wenn ein Fedora-Paket auf einer bestimmten Architektur nicht kompiliert, erstellt oder ausgeführt werden kann, sollten diese Architekturen in der Spec-Datei in ExcludeArch aufgeführt werden. Für jede in ExcludeArch aufgeführte Architektur muss ein Bugzilla-Eintrag erstellt werden, der den Grund für das Kompilierungs-/Erstellungs-/Funktionsproblem des Pakets auf dieser Architektur beschreibt. Die Bugnummer sollte dann in einem Kommentar neben der entsprechenden ExcludeArch-Zeile eingefügt werden. Neue Pakete haben während des Review-Prozesses keine Bugzilla-Einträge. Daher sollten sie diese Beschreibung bis zur Genehmigung des Pakets im Kommentar einfügen und anschließend den Bugzilla-Eintrag erstellen und die ausführliche Erklärung durch die Bugnummer ersetzen. Der Bug sollte als blockierend für einen (oder mehrere) der folgenden Bugs markiert werden, um die Nachverfolgung solcher Probleme zu vereinfachen:

Manchmal arbeitet man an einem noarch-Paket, das nur dort ausgeführt werden kann, wo ein anderes, architekturabhängiges Paket aufbaut. Dies ist häufig der Fall bei Paketen, die in einer Skriptsprache geschrieben sind und beispielsweise vom Interpreterpaket der Sprache abhängen. Wenn das architekturabhängige Paket, von dem Ihr Paket abhängt, nicht auf allen Architekturen verfügbar ist, auf die Fedora (oder EPEL) abzielt, kann es vorkommen, dass Sie Ihr Paket aus den Paketquellen bestimmter Architekturen ausschließen oder verhindern müssen, dass es auf bestimmten Architekturen im Bausystem erstellt wird.

Pakete DÜRFEN KEINE Source:- oder Patch:-Tags enthalten, die von der Architektur abhängig sind. Beispielsweise ist Folgendes verboten:

Die bedingte Verwendung von Source:- oder Patch:-Tags anhand der Architektur führt dazu, dass sich der Inhalt des Quellpakets je nach der Architektur, die zum Erstellen verwendet wurde, unterscheidet.

Beachten Sie, dass dies leider verhindert, dass %autosetup zum Anwenden von Patches verwendet werden kann, wenn einige dieser Patches nur für bestimmte Architekturen gelten. Die beste Lösung besteht darin, Patches zu schreiben, die einfach auf allen Architekturen funktionieren. Wenn dies nicht möglich ist, verwenden Sie einfach %autosetup -N und das Makro %patch, um jeden Patch mit %ifarch oder %ifnarch anzuwenden. Zum Beispiel: