Veraltete Paketbaurichtlinien für Golang

Die von Ihrer Spec-Datei erzeugten Binärdateien SOLLTEN im Allgemeinen im Hauptpaket aufgeführt werden. Falls Sie jedoch einen passenderen Namen wünschen oder die Binärdateien auf verschiedene Pakete verteilen möchten, können Sie zusätzliche Binär-Teilpakete erstellen. Diese Teilpakete DÜRFEN natürlich NICHT architekturunabhängig („noarch“) sein.

Wir können beispielsweise das Paket bbolt erstellen, das die gleichnamige Binärdatei enthält:

Die meisten golang-*-Pakete enthalten nur Quellcode. Das *-devel-Teilpaket, das den Quellcode enthält, sollte explizit die benötigten Go-Importe bereitstellen. Diese Bereitstellungen werden automatisch aus den Importpfaden abgeleitet.

Binärdateien, die diese Importe enthalten, verwenden sie beispielsweise in BuildRequires:

Aktuell SOLLTEN Go-Projekte, die in Fedora paketiert sind, standardmäßig „entbündelt“ werden. Das bedeutet, dass die Projekte aus den in Fedora enthaltenen Abhängigkeiten erstellt werden.

Für manche Projekte kann es sinnvoll sein, aus mitgelieferten Abhängigkeiten zu kompilieren. Jede solche Bündelung bedarf einer triftigen Begründung.

Die BuildRequires des Projekts enthalten die Abhängigkeiten, die von Unit-Tests und Binärdateien benötigt werden.

Sie können sie manuell mit golist sammeln. Zum Beispiel:

gibt Folgendes aus:

Wenn automatische BuildRequires für Ihr Bauziel verfügbar sind, können Sie das Makro %go_generate_buildrequires in %generate_buildrequires verwenden:

Dieses Makro nutzt golist, um Bau- und Testabhängigkeiten aus dem Paketquellcode zu sammeln.

Wir können die üblichen RPM-Header deklarieren, indem wir die von %gometa ermittelten Werte verwenden:

Sie können diese durch manuelle Definitionen ersetzen. Ersetzen Sie beispielsweise %{gourl} durch die Projekt-Homepage, falls diese separat von der Repository-URL existiert. Achten Sie darauf, %{go*}-Variablen nur dann zu ersetzen, wenn dies einen Mehrwert für die Spec-Datei bietet und Sie sich der Konsequenzen bewusst sind. Anderenfalls führen Sie lediglich zu wartungsintensiven Diskrepanzen in der Distribution.

Falls sie nicht automatisch generiert werden, können Sie jetzt die für die Paketerstellung und die Unit-Tests benötigten Abhängigkeiten hinzufügen:

Siehe dieser Abschnitt, um zu erfahren, wie Sie die BuildRequires manuell abrufen können.

Fügen Sie nun die Hauptpaketbeschreibung hinzu:

Die Deklaration von Go-Codepaketen wurde mit dem Makro %{gopkg} automatisiert. Es generiert automatisch ein %package und ein %description für alle primären Importpfade und Kompatibilitätspfade.

Wenn Sie nur Go-Entwicklungs-Teilpakete ohne Kompatibilität generieren müssen, verwenden Sie Folgendes:

Bei Bedarf können Sie anschließend ein oder mehrere Go-Pakete definieren, die die zu erstellenden Binärdateien enthalten. Siehe dazu den vorherigen Abschnitt Go-Binärpakete.

%goprep entpackt die Go-Quellarchive und erstellt den Projektverzeichnisbaum „GOPATH“, der im restlichen Teil der Spec-Datei verwendet wird. Es entfernt mitgelieferten („vendored“) Code: Verwenden Sie das Flag -k, wenn Sie diesen mitgelieferten Code behalten möchten, und berücksichtigen Sie die Auswirkungen im restlichen Teil der Spec-Datei.

%goprep führt nur eine grundlegende Erkennung von Vendoring durch. Innovative Methoden zum Einbinden von Code werden nicht erkannt. Entfernen Sie den übersehenen Vendoring-Code nach der Zeile %goprep manuell.

%goprep wird die Upstream-Quellen nicht automatisch für Sie korrigieren. Da alle nachfolgenden Makroaufrufe von fehlerfreien Quellen ausgehen, müssen Sie diese direkt nach der Zeile %goprep korrigieren:

Wenn Sie einen Importpfad paketieren, der Teil einer Abhängigkeitsschleife ist, benötigen Sie Bootstrapping, um die ersten Bauvorgänge zu verwalten. Für Go-Code bedeutet dies, dass Ihr Bootstrap-Abschnitt Folgendes enthalten sollte:

Manchmal lassen sich Abhängigkeitsschleifen auflösen, indem man bestimmte Unterverzeichnisse in ein separates -devel-Teilpaket auslagert. Siehe auch Umgang mit zirkulären Abhängigkeiten.

Wenn BuildRequires-Generatoren unterstützt werden, können Sie diese nun zu Ihrem Bauvorgang hinzufügen:

Wenn es sich bei Ihrem Paket nur um ein Quellpaket handelt, können Sie diesen %build-Abschnitt komplett überspringen.

Andernfalls müssen Sie zunächst manuell die Projektteile identifizieren, die kompiliert werden können, und festlegen, wie das Ergebnis benannt werden soll. Praktisch gesehen ist jedes Verzeichnis relevant, das einen main()-Abschnitt in Go enthält. In gut organisierten Projekten werden diese in Unterverzeichnissen mit dem Namen cmd abgelegt, die nach dem zu kompilierenden Befehl benannt sind. Dies wird auch hier dokumentiert, ist aber keine allgemeine Regel. Manchmal wird das gesamte Verzeichnis %goipath als eine einzige Binärdatei kompiliert.

Wie bereits erwähnt, MÜSSEN Sie Unit-Tests in %check ausführen:

Oft ist es jedoch notwendig, einige davon zu deaktivieren. Dafür stehen Ihnen drei Ausschlussflags zur Verfügung:

Vergessen Sie nicht, zu dokumentieren, warum ein Test deaktiviert wurde.