---

10.1.2 Paketumwandlungsoptionen

Eine weitere Gruppe von Befehlszeilenoptionen, die guix build und auch guix package unterstützen, sind Paketumwandlungsoptionen. Diese Optionen ermöglichen es, Paketvarianten zu definieren – zum Beispiel können Pakete aus einem anderen Quellcode als normalerweise erstellt werden. Damit ist es leicht, angepasste Pakete schnell zu erstellen, ohne die vollständigen Definitionen von Paketvarianten einzutippen (siehe Pakete definieren).

Paketumwandlungsoptionen bleiben über Aktualisierungen hinweg erhalten: guix upgrade versucht, Umwandlungsoptionen, die vorher zur Erstellung des Profils benutzt wurden, auf die aktualisierten Pakete anzuwenden.

Im Folgenden finden Sie die verfügbaren Befehlszeilenoptionen. Die meisten Befehle unterstützen sie ebenso wie eine Option --help-transform, mit der all die verfügbaren Optionen und je eine Kurzbeschreibung dazu angezeigt werden. (Diese Optionen werden der Kürze wegen nicht in der Ausgabe von --help aufgeführt.)

--tune[=CPU]

Die optimierte Version als „tunebar“ markierter Pakete benutzen. CPU gibt die Prozessorarchitektur an, für die optimiert werden soll. Wenn als CPU die Bezeichnung native angegeben wird oder nichts angegeben wird, wird für den Prozessor optimiert, auf dem der Befehl guix läuft.

Gültige Namen für CPU sind genau die, die vom zugrunde liegenden Compiler erkannt werden. Vorgegeben ist, dass als Compiler die GNU Compiler Collection benutzt wird. Auf x86_64-Prozessoren gehören nehalem, haswell, und skylake zu den CPU-Namen (siehe -march in Using the GNU Compiler Collection (GCC)).

Mit dem Erscheinen neuer Generationen von Prozessoren wächst der Standardbefehlssatz (die „Instruction Set Architecture“, ISA) um neue Befehle an, insbesondere wenn es um Befehle zur Parallelverarbeitung geht („Single-Instruction/Multiple-Data“, SIMD). Zum Beispiel implementieren sowohl die Core2- als auch die Skylake-Prozessoren den x86_64-Befehlssatz, jedoch können nur letztere AVX2-SIMD-Befehle ausführen.

Der Mehrwert, den --tune bringt, besteht in erster Linie bei Programmen, für die SIMD-Fähigkeiten geeignet wären und die über keinen Mechanismus verfügen, zur Laufzeit die geeigneten Codeoptimierungen zuzuschalten. Pakete, bei denen die Eigenschaft tunable? angegeben wurde, werden bei der Befehlszeilenoption --tune als tunebare Pakete optimiert. Eine Paketdefinition, bei der diese Eigenschaft hinterlegt wurde, sieht so aus:

(package
  (name "hello-simd")
  ;; …

  ;; Dieses Paket kann von SIMD-Erweiterungen profitieren,
  ;; deshalb markieren wir es als "tunebar".
  (properties '((tunable? . #t))))

Andere Pakete werden als nicht tunebar aufgefasst. Dadurch kann Guix allgemeine Binärdateien verwenden, wenn sich die Optimierung für einen bestimmten Prozessor wahrscheinlich nicht lohnt.

Bei der Erstellung tunebarer Pakete wird -march=CPU übergeben. Intern wird die Befehlszeilenoption -march durch einen Compiler-Wrapper an den eigentlichen Wrapper übergeben. Weil die Erstellungsmaschine den Code für die Mikroarchitektur vielleicht gar nicht ausführen kann, wird der Testkatalog bei der Erstellung tunebarer Pakete übersprungen.

Damit weniger Neuerstellungen erforderlich sind, werden die von tunebaren Paketen abhängigen Pakete mit den optimierten Paketen veredelt (siehe Veredelungen). Wenn Sie --no-grafts übergeben, wirkt --tune deshalb nicht mehr.

Wir geben dieser Technik den Namen Paket-Multiversionierung: Mehrere Varianten des tunebaren Pakets können erstellt werden; eine für jede Prozessorvariante. Das ist die grobkörnige Entsprechung der Funktions-Multiversionierung, die in der GNU-Toolchain zu finden ist (siehe Function Multiversioning in Using the GNU Compiler Collection (GCC)).

--with-source=Quelle

--with-source=Paket=Quelle

--with-source=Paket@Version=Quelle

Den Paketquellcode für das Paket von der angegebenen Quelle holen und die Version als seine Versionsnummer verwenden. Die Quelle muss ein Dateiname oder eine URL sein wie bei guix download (siehe guix download aufrufen).

Wird kein Paket angegeben, wird als Paketname derjenige auf der Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende der Quelle passt – wenn z.B. als Quelle die Datei /src/guile-2.0.10.tar.gz angegeben wurde, entspricht das dem guile-Paket.

Ebenso wird, wenn keine Version angegeben wurde, die Version als Zeichenkette aus der Quelle abgeleitet; im vorherigen Beispiel wäre sie 2.0.10.

Mit dieser Option können Nutzer versuchen, eine andere Version ihres Pakets auszuprobieren, als die in der Distribution enthaltene Version. Folgendes Beispiel lädt ed-1.7.tar.gz von einem GNU-Spiegelserver herunter und benutzt es als Quelle für das ed-Paket:

guix build ed --with-source=mirror://gnu/ed/ed-1.4.tar.gz

Für Entwickler wird es einem durch --with-source leicht gemacht, „Release Candidates“, also Vorabversionen, zu testen, oder sogar welchen Einfluss diese auf abhängige Pakete haben:

guix build elogind --with-source=…/shepherd-0.9.0rc1.tar.gz 

… oder ein Checkout eines versionskontrollierten Repositorys in einer isolierten Umgebung zu erstellen:

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix

--with-input=Paket=Ersatz

Abhängigkeiten vom Paket durch eine Abhängigkeit vom Ersatz-Paket ersetzen. Als Paket muss ein Paketname angegeben werden und als Ersatz eine Paketspezifikation wie guile oder guile@1.8.

Mit folgendem Befehl wird zum Beispiel Guix erstellt, aber statt der aktuellen stabilen Guile-Version hängt es von der alten Guile-Version guile@2.0 ab:

guix build --with-input=guile=guile@2.0 guix

Die Ersetzung ist rekursiv und umfassend. In diesem Beispiel würde nicht nur guix, sondern auch seine Abhängigkeit guile-json (was auch von guile abhängt) für guile@2.0 neu erstellt.

Implementiert wird das alles mit der Scheme-Prozedur package-input-rewriting (siehe package-input-rewriting).

--with-graft=Paket=Ersatz

Dies verhält sich ähnlich wie mit --with-input, aber mit dem wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette neu erstellt wird, sondern das Ersatz-Paket erstellt und die ursprünglichen Binärdateien, die auf das Paket verwiesen haben, damit veredelt werden. Im Abschnitt Sicherheitsaktualisierungen finden Sie weitere Informationen über Veredelungen.

Zum Beispiel veredelt folgender Befehl Wget und alle Abhängigkeiten davon mit der Version 3.5.4 von GnuTLS, indem Verweise auf die ursprünglich verwendete GnuTLS-Version ersetzt werden:

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Das hat den Vorteil, dass es viel schneller geht, als alles neu zu erstellen. Die Sache hat aber einen Haken: Veredelung funktioniert nur, wenn das Paket und sein Ersatz miteinander streng kompatibel sind – zum Beispiel muss, wenn diese eine Programmbibliothek zur Verfügung stellen, deren Binärschnittstelle („Application Binary Interface“, kurz ABI) kompatibel sein. Wenn das Ersatz-Paket auf irgendeine Art inkompatibel mit dem Paket ist, könnte das Ergebnispaket unbrauchbar sein. Vorsicht ist also geboten!

--with-debug-info=Paket

Das Paket auf eine Weise erstellen, die Informationen zur Fehlersuche enthält, und von ihm abhängige Pakete damit veredeln. Das ist nützlich, wenn das Paket noch keine Fehlersuchinformationen als installierbare debug-Ausgabe enthält (siehe Dateien zur Fehlersuche installieren).

Als Beispiel nehmen wir an, Inkscape stürzt bei Ihnen ab und Sie möchten wissen, was dabei in GLib passiert. Die GLib-Bibliothek liegt tief im Abhängigkeitsgraphen von Inkscape und verfügt nicht über eine debug-Ausgabe; das erschwert die Fehlersuche. Glücklicherweise können Sie GLib mit Informationen zur Fehlersuche neu erstellen und an Inkscape anheften:

guix install inkscape --with-debug-info=glib

Nur GLib muss neu kompiliert werden, was in vernünftiger Zeit möglich ist. Siehe Dateien zur Fehlersuche installieren für mehr Informationen.

Anmerkung: Intern funktioniert diese Option, indem ‘#:strip-binaries? #f’ an das Erstellungssystem des betreffenden Pakets übergeben wird (siehe Erstellungssysteme). Die meisten Erstellungssysteme unterstützen diese Option, manche aber nicht. In diesem Fall wird ein Fehler gemeldet.

Auch wenn ein in C/C++ geschriebenes Paket ohne -g erstellt wird (was selten der Fall ist), werden Informationen zur Fehlersuche weiterhin fehlen, obwohl #:strip-binaries? auf falsch steht.

--with-c-toolchain=Paket=Toolchain

Mit dieser Befehlszeilenoption wird die Kompilierung des Pakets und aller davon abhängigen Objekte angepasst, so dass mit der Toolchain statt der vorgegebenen GNU-Toolchain für C/C++ erstellt wird.

Betrachten Sie dieses Beispiel:

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

Mit dem obigen Befehl wird eine Variante der Pakete fftw und fftwf mit Version 10 der gcc-toolchain anstelle der vorgegebenen Toolchain erstellt, um damit anschließend eine diese benutzende Variante des GNU-Octave-Befehlszeilenprogramms zu erstellen. Auch GNU Octave selbst wird mit gcc-toolchain@10 erstellt.

Das zweite Beispiel bewirkt eine Erstellung der „Hardware Locality“-Bibliothek (hwloc) sowie ihrer abhängigen Objekte bis einschließlich intel-mpi-benchmarks mit dem Clang-C-Compiler:

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Anmerkung: Es kann vorkommen, dass die Anwendungsbinärschnittstellen („Application Binary Interfaces“, kurz ABIs) der Toolchains inkompatibel sind. Das tritt vor allem bei der C++-Standardbibliothek und Bibliotheken zur Laufzeitunterstützung wie denen von OpenMP auf. Indem alle abhängigen Objekte mit derselben Toolchain erstellt werden, minimiert --with-c-toolchain das Risiko, dass es zu Inkompatibilitäten kommt, aber es kann nicht ganz ausgeschlossen werden. Bedenken Sie, für welches Paket Sie dies benutzen.

--with-git-url=Paket=URL ¶

Das Paket aus dem neuesten Commit im master-Branch des unter der URL befindlichen Git-Repositorys erstellen. Git-Submodule des Repositorys werden dabei rekursiv geladen.

Zum Beispiel erstellt der folgende Befehl die NumPy-Python-Bibliothek unter Verwendung des neuesten Commits von Python auf dessen „master“-Branch.

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Diese Befehlszeilenoption kann auch mit --with-branch oder --with-commit kombiniert werden (siehe unten).

Da es den neuesten Commit auf dem verwendeten Branch benutzt, ändert sich das Ergebnis natürlich mit der Zeit. Nichtsdestoweniger ist es eine bequeme Möglichkeit, ganze Softwarestapel auf dem neuesten Commit von einem oder mehr Paketen aufbauen zu lassen. Es ist besonders nützlich im Kontext Kontinuierlicher Integration (englisch „Continuous Integration“, kurz CI).

Checkouts bleiben zwischengespeichert als ~/.cache/guix/checkouts, damit danach schneller auf dasselbe Repository zugegriffen werden kann. Eventuell möchten Sie das Verzeichnis ab und zu bereinigen, um Plattenplatz zu sparen.

--with-branch=Paket=Branch

Das Paket aus dem neuesten Commit auf dem Branch erstellen. Wenn das source-Feld des Pakets ein origin-Objekt mit der Methode git-fetch (siehe origin-Referenz) oder ein git-checkout-Objekt ist, wird die URL des Repositorys vom source-Feld genommen. Andernfalls müssen Sie die Befehlszeilenoption --with-git-url benutzen, um die URL des Git-Repositorys anzugeben.

Zum Beispiel wird mit dem folgenden Befehl guile-sqlite3 aus dem neuesten Commit seines master-Branches erstellt und anschließend guix (was von guile-sqlite3 abhängt) und cuirass (was von guix abhängt) unter Nutzung genau dieser guile-sqlite3-Erstellung erstellt:

guix build --with-branch=guile-sqlite3=master cuirass

--with-commit=Paket=Commit

Dies verhält sich ähnlich wie --with-branch, außer dass es den angegebenen Commit benutzt statt die Spitze eines angegebenen Branches. Als Commit muss ein gültiger SHA1-Bezeichner, ein Tag oder ein Bezeichner wie von git describe (wie 1.0-3-gabc123) für einen Git-Commit angegeben werden.

--with-patch=Paket=Datei

Die Datei zur Liste der auf das Paket anzuwendenden Patches hinzufügen. Als Paket muss eine Spezifikation wie python@3.8 oder glibc benutzt werden. In der Datei muss ein Patch enthalten sein; er wird mit den im Ursprung (origin) des Pakets angegebenen Befehlszeilenoptionen angewandt (siehe origin-Referenz). Die vorgegebenen Optionen enthalten -p1 (siehe patch Directories in Comparing and Merging Files).

Zum Beispiel wird mit dem folgenden Befehl für die Neuerstellung von Coreutils die GNU-C-Bibliothek (glibc) wie angegeben gepatcht:

guix build coreutils --with-patch=glibc=./glibc-frob.patch

In diesem Beispiel wird glibc selbst und alles, was im Abhängigkeitsgraphen auf dem Weg zu Coreutils liegt, neu erstellt.

--with-latest=Paket

Sie hätten gerne das Neueste vom Neuen? Dann ist diese Befehlszeilenoption das Richtige für Sie! Damit wird jedes Vorkommen von Paket im Abhängigkeitsgraphen durch dessen neueste angebotene Version ersetzt, wie sie auch von guix refresh gemeldet würde (siehe guix refresh aufrufen).

Dazu wird die neueste angebotene Version des Pakets ermittelt (wenn möglich), heruntergeladen und, wenn eine OpenPGP-Signatur mit dabei ist, es damit authentifiziert.

Zum Beispiel wird durch folgenden Befehl Guix mit der neuesten Version von Guile-JSON erstellt:

guix build guix --with-latest=guile-json

Es gibt jedoch Einschränkungen. Erstens gehen Sie in dem Fall, dass das Werkzeug nicht in der Lage ist oder nicht weiß, wie es den Quellcode authentifiziert, das Risiko ein, dass bösartiger Code ausgeführt wird; Ihnen wird dann eine Warnung angezeigt. Zweitens wird mit dieser Option einfach der Quellcode ausgetauscht und die übrige Paketdefinition bleibt erhalten. Manchmal reicht das nicht; es könnte sein, dass neue Abhängigkeiten hinzugefügt oder neue Patches angewandt werden müssen oder dass ganz allgemein Arbeiten zur Qualitätssicherung, die Guix-Entwickler normalerweise leisten, fehlen werden.

Sie sind gewarnt worden! Wenn aber kein Problem auftritt, können Sie das Paket zackig auf den neuesten Stand bringen. Wir ermutigen Sie dazu, Patches einzureichen, die die eigentliche Paketdefinition aktualisieren, sobald Sie die neue Version erfolgreich getestet haben (siehe Mitwirken).

--without-tests=Paket

Das Paket erstellen, ohne seine Tests zu durchlaufen. Das erweist sich als nützlich, wenn Sie Testkataloge überspringen möchten, die viel Zeit in Anspruch nehmen, oder wenn der Testkatalog eines Pakets nichtdeterministisch fehlschlägt. Dies sollte mit Bedacht eingesetzt werden, denn das Ausführen des Testkatalogs sichert zu, dass ein Paket wie gewollt funktioniert.

Wenn die Tests abgeschaltet werden, ergibt sich ein anderes Store-Objekt. Dadurch muss, wenn diese Option benutzt wird, auch alles, was vom Paket abhängt, neu erstellt werden, wie Sie in diesem Beispiel sehen können:

guix install --without-tests=python python-notebook

Mit obigem Befehl wird python-notebook für ein python installiert, dessen Testkatalog nicht ausgeführt wurde. Dazu wird auch alles neu erstellt, was von python abhängt, einschließlich python-notebook.

Intern funktioniert --without-tests, indem es die Option #:tests? der check-Phase eines Pakets abändert (siehe Erstellungssysteme). Beachten Sie, dass manche Pakete eine angepasste check-Phase benutzen, die eine Einstellung wie #:tests? #f nicht berücksichtigt. Deshalb wirkt sich --without-tests auf diese Pakete nicht aus.

Sie fragen sich sicher, wie Sie dieselbe Wirkung mit Scheme-Code erzielen können, zum Beispiel wenn Sie Ihr Manifest oder eine eigene Paketumwandlung schreiben? Siehe Paketvarianten definieren für eine Übersicht über verfügbare Programmierschnittstellen.