Paketbaurichtlinien für Golang

go2rpm ist ein Werkzeug, das viele dieser Schritte automatisiert. Es empfiehlt sich, zunächst go2rpm --name NAME --profile vendor IMPORT_PATH auszuprobieren, bevor man versucht, eine Spec-Datei manuell zu schreiben. go2rpm generiert eine richtlinienkonforme Spec-Datei, lädt die Upstream-Quellen herunter, erstellt mit go_vendor_archive aus den Go Vendor Tools ein Vendor-Archiv und verwendet anschließend go_vendor_license, um die Upstream-Quellen und die eingebundenen Abhängigkeiten nach Lizenzdateien zu durchsuchen. Dabei fordert es den Benutzer zur Eingabe fehlender Lizenzen auf und generiert schließlich einen kumulativen SPDX-Ausdruck.

In Golang werden Pakete über vollständige URLs referenziert, die in der go.mod-Datei des Projekts aufgeführt sind.

Neue Golang-Bibliothekspakete sind nicht mehr zulässig. Daher sind alle Golang-Pakete benutzerorientierte Anwendungen, die gemäß den Benennungsrichtlinien benannt werden MÜSSEN. Insbesondere DÜRFEN Go-Pakete, die von externen Anbietern bereitgestellt werden, KEIN Präfix golang- haben, es sei denn, dieses ist Bestandteil des Namens des übergeordneten Projekts.

Dies gilt auch für bestehende Pakete. Bei der Umstellung eines Pakets mit dem Präfix golang-, das nach den alten Richtlinien für die Verwendung von Vendored-Abhängigkeiten erstellt wurde, muss das Paket den Paketumbenennungsprozess durchlaufen. Diese Richtlinie dient der klaren Trennung zwischen Paketen, die nach dem alten Ansatz und dem neuen Vendored-Verfahren erstellt wurden, und soll verhindern, dass Teilpakete mit dem Präfix -devel aus bestehenden golang--Paketen entfernt und anschließend wieder in stabile Zweige integriert werden.

Für die Kompilierung auf verschiedenen Architekturen stehen die Compiler golang und gcc-go zur Verfügung. Der golang-Compiler unterstützt derzeit x86, x86_64, ppc64le, ppc64 (teilweise, siehe Upstream-Ticket #13192), s390x, armv7hl und aarch64.

Binärdateien SOLLTEN ExclusiveArch setzen, damit Pakete nur auf den angegebenen Architekturen erstellt werden. Dies wird nun automatisch durch das Makro %gometa mithilfe des Makros %{golang_arches} hinzugefügt. Paketierer können %ix86 ausschließen (siehe Changes/EncourageI686LeafRemoval), indem sie -f an das Makro %gometa übergeben. Das Flag -f weist %gometa an, ExclusiveArch: %{golang_arches_future} anstelle von ExclusiveArch: %{golang_arches} zu setzen. %{golang_arches_future} umfasst dieselben Architekturen wie {golang_arches}, jedoch ohne %ix86.

Pakete MÜSSEN BuildRequires: go-rpm-macros enthalten, um die Go-Makros und den Compiler einzubinden.

Dies wird durch das Makro %gometa automatisiert.

Pakete, die die %go_vendor_license_*-Makros verwenden, MÜSSEN BuildRequires: go-vendor-tools haben.

Pakete MÜSSEN ihre Go-Modulabhängigkeiten einbinden. Paketierer SOLLTEN den Befehl go_vendor_archive aus den Go Vendor Tools (gvt) verwenden, um ein reproduzierbares Vendor-Archiv zu erstellen. Pakete, die die Go Vendor Tools nicht verwenden, müssen ein Skript oder eine andere standardisierte, dokumentierte Vorgehensweise zum Herunterladen der Quellen mit go mod vendor und zum reproduzierbaren Erstellen eines Tarballs enthalten. Paketierer SOLLTEN Vendor-Archive selbst neu generieren, selbst wenn die Upstream-Projekte ein Vendor-Verzeichnis in ihren Upstream-Quellen enthalten. Dies ermöglicht einfachere Sicherheitsupdates mit den Go Vendor Tools.

Üblicherweise ist Source0 in der Spec-Datei das primäre Archiv und Source1 das Vendor-Archiv, wobei die Werte automatisch mithilfe der Forge-Makros ausgefüllt werden.

Führen Sie anschließend go_vendor_archive create <PAKETNAME>.spec aus, um einen Vendor-Tarball zu erstellen.

Pakete müssen den Fedora-Lizenzrichtlinien entsprechen. Für Vendored-Go-Pakete bedeutet dies, dass die Lizenzdateien des Hauptprojekts sowie aller Vendored-Go-Module im Paket enthalten und mit %license gekennzeichnet sein MÜSSEN. Jedes Vendored-Go-Modul MUSS eine Lizenzdatei enthalten; Go-Module ohne Lizenzdatei DÜRFEN NICHT in Vendored-Archive aufgenommen werden, bis die Lizenzierung geklärt ist.

Darüber hinaus MUSS der License:-Tag des Pakets einen kumulativen SPDX-Ausdruck enthalten, der sowohl das Hauptpaket als auch die Vendored-Go-Module umfasst.

Go Vendor Tools stellt den Befehl go_vendor_license und Makros bereit, um den korrekten License:-Ausdruck zu ermitteln und Lizenzdateien gemäß dem vorherigen Abschnitt zu installieren.

Paketierer MÜSSEN go_vendor_license report ausführen (entweder direkt über go2rpm oder mithilfe des Makros https://fedora.gitlab.io/sigs/go/go-vendor-tools/man/rpm_macros/#go_vendor_license_check%go_vendor_license_check] in einem lokalen Mock-Build) und dessen Ausgabe sorgfältig prüfen, bevor sie die Quellen in den Lookaside-Cache hochladen. Alle Fehler MÜSSEN behoben werden. Falls ein Teil der Ausgabe fehlerhaft ist, kann das Verhalten von go_vendor_license in dem Lizenzierungsabschnitt der Go Vendor Tools-Konfigurationsdatei angepasst werden.

Dieses Dokument beschreibt lediglich die Standardverwendung der Go Vendor Tools, die zur Einhaltung der Richtlinien erforderlich ist. Details zur erweiterten Verwendung finden Sie in der Dokumentation der Go Vendor Tools. Paketierer können den beschriebenen Szenarien folgen, um mit go2rpm eine neue Spec-Datei zu generieren oder bestehende Spec-Dateien für neue Upstream-Versionen zu aktualisieren. Anschließend führen sie go_vendor_license aus, um sicherzustellen, dass die Lizenz gültig ist und sie gegebenenfalls vor dem vollständigen Bauvorgang automatisch zu aktualisieren.

Sie SOLLTEN Unit-Tests ausführen.

Einige Tests können deaktiviert werden, insbesondere die folgenden Arten von Unit-Tests sind zu einer sicheren Bauumgebung wie Mock nicht kompatibel:

Wenn ein Test aus einem anderen Grund fehlschlägt, können Sie ihn auf dieselbe Weise deaktivieren. Sie SOLLTEN das Problem jedoch auch dem Upstream-Projekt melden. Vergessen Sie nicht, in einem Kommentar nachzuvollziehen, warum jeder einzelne Test deaktiviert wurde, und gegebenenfalls Links zu den Upstream-Fehlerberichten hinzuzufügen.

Tests können mit dem %gocheck2-Makro ausgeführt werden, welches intern go test aufruft, wobei die Fedora-Build-Flags erhalten bleiben und zusätzliche Optionen zum Überspringen bestimmter Tests bereitgestellt werden.

Pakete DÜRFEN das veraltete Makro %gocheck NICHT verwenden.

Pakete SOLLTEN den Go-Modulmodus aktivieren, indem sie %global gomodulesmode GO111MODULE=on in die Spec-Datei einfügen, um die Umgebungsvariable GO111MODULE zu setzen. Üblicherweise wird diese Definition am Anfang von %build vor dem Aufruf von %gobuild eingefügt.

Die von go-vendor-tools bereitgestellten RPM-Makros dienen der Lizenzvalidierung und -installation. Siehe die Dokumentation zu den RPM-Makros der Go Vendor Tools und Lizenzierung mit den Go Vendor Tools.

go-rpm-macros ist hauptsächlich für das Makro %gobuild verantwortlich, das go build mit den Build-Flags von Fedora aufruft.

go-rpm-macros bietet außerdem Wrapper für die Forge-Makros aus dem Paket forge-srpm-macros, die das Angeben der Quell-URL und das Entpacken von Quellcode für Go-Projekte auf gängigen Software-Plattformen wie GitHub vereinfachen. Zu diesen Makros gehören %gometa, %gosource und %goprep. Paketierer können diese Makros verwenden, anstatt Quellcode anzugeben und %autosetup / %setup manuell aufzurufen. Weitere Informationen finden Sie in der Dokumentation zu forge-wrappers und in der Beispiel-Spec-Datei in diesen Richtlinien.