8.3 guix pack aufrufen

Manchmal möchten Sie Software an Leute weitergeben, die (noch!) nicht das Glück haben, Guix zu benutzen. Mit Guix würden sie nur guix package -i irgendetwas einzutippen brauchen, aber wenn sie kein Guix haben, muss es anders gehen. Hier kommt guix pack ins Spiel.

Anmerkung: Wenn Sie aber nach einer Möglichkeit suchen, Binärdateien unter Maschinen auszutauschen, auf denen Guix bereits läuft, sollten Sie einen Blick auf die Abschnitte guix copy aufrufen, guix publish aufrufen und guix archive aufrufen werfen.

Der Befehl guix pack erzeugt ein gut verpacktes Software-Bündel: Konkret wird dadurch ein Tarball oder eine andere Art von Archiv mit den Binärdateien der Software erzeugt, die Sie sich gewünscht haben, zusammen mit all ihren Abhängigkeiten. Der resultierende Archiv kann auch auf jeder Maschine genutzt werden, die kein Guix hat, und jeder kann damit genau dieselben Binärdateien benutzen, die Ihnen unter Guix zur Verfügung stehen. Das Bündel wird dabei auf eine Bit für Bit reproduzierbare Art erzeugt, damit auch jeder nachprüfen kann, dass darin wirklich diejenigen Binärdateien enthalten sind, von denen Sie es behaupten.

Um zum Beispiel ein Bündel mit Guile, Emacs, Geiser und all ihren Abhängigkeiten zu erzeugen, führen Sie diesen Befehl aus:

$ guix pack guile emacs emacs-geiser
…
/gnu/store/…-pack.tar.gz

Als Ergebnis erhalten Sie einen Tarball mit einem Verzeichnis /gnu/store, worin sich alles relevanten Pakete befinden. Der resultierende Tarball enthält auch ein Profil mit den drei angegebenen Paketen; es ist dieselbe Art von Profil, die auch guix package -i erzeugen würde. Mit diesem Mechanismus wird auch der binäre Tarball zur Installation von Guix erzeugt (siehe Aus Binärdatei installieren).

Benutzer des Bündels müssten dann aber zum Beispiel /gnu/store/…-profile/bin/guile eintippen, um Guile auszuführen, was Ihnen zu unbequem sein könnte. Ein Ausweg wäre, dass Sie etwa eine symbolische Verknüpfung /opt/gnu/bin auf das Profil anlegen:

guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser

Benutzer müssten dann nur noch /opt/gnu/bin/guile eintippen, um Guile zu genießen.

Doch was ist, wenn die Empfängerin Ihres Bündels keine Administratorrechte auf ihrer Maschine hat, das Bündel also nicht ins Wurzelverzeichnis ihres Dateisystems entpacken kann? Dann möchten Sie vielleicht die Befehlszeilenoption --relocatable benutzen (siehe weiter unten). Mit dieser Option werden verschiebliche Binärdateien erzeugt, die auch in einem beliebigen anderen Verzeichnis in der Dateisystemhierarchie abgelegt und von dort ausgeführt werden können. Man könnte sagen, sie sind pfad-agnostisch. In obigem Beispiel würden Benutzer Ihren Tarball in ihr Persönliches Verzeichnis (das „Home“-Verzeichnis) entpacken und von dort den Befehl ./opt/gnu/bin/guile ausführen.

Eine weitere Möglichkeit ist, das Bündel im Format eines Docker-Abbilds (englisch Docker-Image) zu erzeugen. Das geht mit dem folgenden Befehl:

guix pack -f docker -S /bin=bin guile guile-readline

Das Ergebnis ist ein Tarball, der dem Befehl docker load übergeben werden kann, gefolgt von docker run:

docker load < Datei
docker run -ti guile-guile-readline /bin/guile

Dabei steht Datei für das durch guix pack gelieferte Abbild und guile-guile-readline für den „Image-Tag“, der diesem zugewiesen wurde. In der Dokumentation von Docker finden Sie nähere Informationen.

Und noch eine weitere Möglichkeit ist, dass Sie ein SquashFS-Abbild mit folgendem Befehl erzeugen:

guix pack -f squashfs bash guile emacs emacs-geiser

Das Ergebnis ist ein SquashFS-Dateisystemabbild, dass entweder als Dateisystem eingebunden oder mit Hilfe der Singularity-Container-Ausführungsumgebung als Dateisystemcontainer benutzt werden kann, mit Befehlen wie singularity shell oder singularity exec.

Es gibt mehrere Befehlszeilenoptionen, mit denen Sie Ihr Bündel anpassen können:

--format=Format

-f Format

Generiert ein Bündel im angegebenen Format.

Die verfügbaren Formate sind:

tarball

Das standardmäßig benutzte Format. Damit wird ein Tarball generiert, der alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält.

docker

Generiert einen Tarball gemäß der Spezifikation für Docker-Abbilder. Der „Repository-Name“, wie er in der Ausgabe des Befehls docker images erscheint, wird anhand der Paketnamen berechnet, die auf der Befehlszeile oder in der Manifest-Datei angegeben wurden.

squashfs

Generiert ein SquashFS-Abbild, das alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält, sowie leere Einhängepunkte für virtuelle Dateisysteme wie procfs.

Anmerkung: Für Singularity müssen Sie eine /bin/sh in das Abbild aufnehmen. Aus diesem Grund gilt für guix pack -f squashfs implizit immer auch -S /bin=bin. Daher muss Ihr Aufruf von guix pack immer ungefähr so beginnen:

guix pack -f squashfs bash …

Wenn Sie vergessen, das bash-Paket (oder etwas Ähnliches) zu bündeln, werden singularity run und singularity exec mit der wenig hilfreichen Meldung „Datei oder Verzeichnis nicht gefunden“ scheitern.

deb

Hiermit wird ein Debian-Archiv erzeugt (ein Paket mit der Dateinamenserweiterung „.deb“), in dem alle angegebenen Binärdateien und symbolischen Verknüpfungen enthalten sind. Es kann auf jeder dpkg-basierten GNU(/Linux)-Distribution installiert werden. Fortgeschrittene Optionen werden Ihnen angezeigt, wenn Sie die Befehlszeilenoption --help-deb-format angeben. Mit jenen können Control-Dateien hinzugefügt werden für eine genaue Steuerung z.B. welche bestimmten Trigger aktiviert werden oder um mit einem Betreuerskript beliebigen Konfigurations-Code einzufügen, der bei Installation ausgeführt werden soll.

guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello

Anmerkung: Weil in den mit guix pack erzeugten Archiven eine Ansammlung von Store-Objekten enthalten ist und weil in jedem dpkg-Paket keine im Konflikt stehenden Dateien enthalten sein dürfen, können Sie de facto wahrscheinlich nur ein einziges mit guix pack erzeugtes „.deb“-Archiv je System installieren.

Warnung: dpkg übernimmt die Zuständigkeit für alle Dateien, die im Bündel enthalten sind, auch wenn es die Dateien nicht kennt. Es ist unklug, mit Guix erzeugte „.deb“-Dateien auf einem System zu installieren, auf dem /gnu/store bereits von anderer Software verwendet wird, also wenn z.B. Guix bereits installiert ist oder andere Nicht-deb-Bündel installiert sind.

--relocatable

-R

Erzeugt verschiebliche Binärdateien – also pfad-agnostische, „portable“ Binärdateien, die an einer beliebigen Stelle in der Dateisystemhierarchie platziert und von dort ausgeführt werden können.

Wenn diese Befehlszeilenoption einmal übergeben wird, funktionieren die erzeugten Binärdateien nur dann, wenn Benutzernamensräume des Linux-Kernels unterstützt werden. Wenn sie zweimal¹⁸ übergeben wird, laufen die Binärdateien notfalls mit anderen Methoden, wenn keine Benutzernamensräume zur Verfügung stehen, funktionieren also ziemlich überall – siehe unten für die Auswirkungen.

Zum Beispiel können Sie ein Bash enthalltendes Bündel erzeugen mit:

guix pack -RR -S /meine-bin=bin bash

… Sie können dieses dann auf eine Maschine ohne Guix kopieren und als normaler Nutzer aus Ihrem Persönlichen Verzeichnis (auch „Home“-Verzeichnis genannt) dann ausführen mit:

tar xf pack.tar.gz
./meine-bin/sh

Wenn Sie in der so gestarteten Shell dann ls /gnu/store eintippen, sehen Sie, dass Ihnen angezeigt wird, in /gnu/store befänden sich alle Abhängigkeiten von bash, obwohl auf der Maschine überhaupt kein Verzeichnis /gnu/store existiert! Dies ist vermutlich die einfachste Art, mit Guix erstellte Software für eine Maschine ohne Guix auszuliefern.

Anmerkung: Wenn die Voreinstellung verwendet wird, funktionieren verschiebliche Binärdateien nur mit Benutzernamensräumen (englisch User namespaces), einer Funktionalität des Linux-Kernels, mit der Benutzer ohne besondere Berechtigungen Dateisysteme einbinden (englisch „mount“) oder die Wurzel des Dateisystems wechseln können („change root“, kurz „chroot“). Alte Versionen von Linux haben diese Funktionalität noch nicht unterstützt und manche Distributionen von GNU/Linux schalten sie ab.

Um verschiebliche Binärdateien zu erzeugen, die auch ohne Benutzernamensräume funktionieren, können Sie die Befehlszeilenoption --relocatable oder -R zweimal angeben. In diesem Fall werden die Binärdateien zuerst überprüfen, ob Benutzernamensräume unterstützt werden, und sonst notfalls einen anderen Ausführungstreiber benutzen, um das Programm auszuführen, wenn Benutzernamensräume nicht unterstützt werden. Folgende Ausführungstreiber werden unterstützt:

default

Es wird versucht, Benutzernamensräume zu verwenden. Sind Benutzernamensräume nicht verfügbar (siehe unten), wird auf PRoot zurückgegriffen.

performance

Es wird versucht, Benutzernamensräume zu verwenden. Sind Benutzernamensräume nicht verfügbar (siehe unten), wird auf Fakechroot zurückgegriffen.

userns

Das Programm wird mit Hilfe von Benutzernamensräumen ausgeführt. Wenn sie nicht unterstützt werden, bricht das Programm ab.

proot

Durch PRoot ausführen. Das Programm PRoot bietet auch Unterstützung für Dateisystemvirtualisierung, indem der Systemaufruf ptrace auf das laufende Programm angewendet wird. Dieser Ansatz funktioniert auch ohne besondere Kernel-Unterstützung, aber das Programm braucht mehr Zeit, um selbst Systemaufrufe durchzuführen.

fakechroot

Durch Fakechroot laufen lassen. Fakechroot virtualisiert Dateisystemzugriffe, indem Aufrufe von Funktionen der C-Bibliothek wie open, stat, exec und so weiter abgefangen werden. Anders als bei PRoot entsteht dabei kaum Mehraufwand. Jedoch funktioniert das nicht immer, zum Beispiel werden manche Dateisystemzugriffe aus der C-Bibliothek heraus nicht abgefangen, ebenso wenig wie Dateisystemaufrufe über direkte Systemaufrufe, was zu fehlerbehaftetem Verhalten führt.

Wenn Sie ein verpacktes Programm ausführen, können Sie einen der oben angeführten Ausführungstreiber ausdrücklich anfordern, indem Sie die Umgebungsvariable GUIX_EXECUTION_ENGINE entsprechend festlegen.

--entry-point=Befehl

Den Befehl als den Einsprungpunkt des erzeugten Bündels verwenden, wenn das Bündelformat einen solchen unterstützt – derzeit tun das docker und squashfs (Singularity). Der Befehl wird relativ zum Profil ausgeführt, das sich im Bündel befindet.

Der Einsprungpunkt gibt den Befehl an, der mit docker run oder singularity run beim Start nach Voreinstellung automatisch ausgeführt wird. Zum Beispiel können Sie das hier benutzen:

guix pack -f docker --entry-point=bin/guile guile

Dann kann das erzeugte Bündel mit z.B. docker run ohne weitere Befehlszeilenargumente einfach geladen und ausgeführt werden, um bin/guile zu starten:

docker load -i pack.tar.gz
docker run Abbild-ID

--expression=Ausdruck

-e Ausdruck

Als Paket benutzen, wozu der Ausdruck ausgewertet wird.

Der Zweck hiervon ist derselbe wie bei der gleichnamigen Befehlszeilenoption in guix build (siehe --expression in guix build).

--manifest=Datei

-m Datei

Die Pakete benutzen, die im Manifest-Objekt aufgeführt sind, das vom Scheme-Code in der angegebenen Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.

Dies hat einen ähnlichen Zweck wie die gleichnamige Befehlszeilenoption in guix package (siehe --manifest) und benutzt dieselben Regeln für Manifest-Dateien. Damit können Sie eine Reihe von Paketen einmal definieren und dann sowohl zum Erzeugen von Profilesn als auch zum Erzeugen von Archiven benutzen, letztere für Maschinen, auf denen Guix nicht installiert ist. Beachten Sie, dass Sie entweder eine Manifest-Datei oder eine Liste von Paketen angeben können, aber nicht beides.

Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest schreibt. Siehe guix shell --export-manifest für Informationen, wie Sie Befehlszeilenoptionen in ein Manifest „verwandeln“ können.

--system=System

-s System

Versuchen, für die angegebene Art von System geeignete Binärdateien zu erstellen – z.B. i686-linux – statt für die Art von System, das die Erstellung durchführt.

--target=Tripel ¶

Lässt für das angegebene Tripel cross-erstellen, dieses muss ein gültiges GNU-Tripel wie z.B. "aarch64-linux-gnu" sein (siehe GNU-Tripel für configure in Autoconf).

--compression=Werkzeug

-C Werkzeug

Komprimiert den resultierenden Tarball mit dem angegebenen Werkzeug – dieses kann gzip, zstd, bzip2, xz, lzip oder none für keine Kompression sein.

--symlink=Spezifikation

-S Spezifikation

Fügt die in der Spezifikation festgelegten symbolischen Verknüpfungen zum Bündel hinzu. Diese Befehlszeilenoption darf mehrmals vorkommen.

Die Spezifikation muss von der Form Quellort=Zielort sein, wobei der Quellort der Ort der symbolischen Verknüpfung, die erstellt wird, und Zielort das Ziel der symbolischen Verknüpfung ist.

Zum Beispiel wird mit -S /opt/gnu/bin=bin eine symbolische Verknüpfung /opt/gnu/bin auf das Unterverzeichnis bin im Profil erzeugt.

--save-provenance

Provenienzinformationen für die auf der Befehlszeile übergebenen Pakete speichern. Zu den Provenienzinformationen gehören die URL und der Commit jedes benutzten Kanals (siehe Kanäle).

Provenienzinformationen werden in der Datei /gnu/store/…-profile/manifest im Bündel zusammen mit den üblichen Paketmetadaten abgespeichert – also Name und Version jedes Pakets, welche Eingaben dabei propagiert werden und so weiter. Die Informationen nützen den Empfängern des Bündels, weil sie dann wissen, woraus das Bündel (angeblich) besteht.

Der Vorgabe nach wird diese Befehlszeilenoption nicht verwendet, weil Provenienzinformationen genau wie Zeitstempel nichts zum Erstellungsprozess beitragen. Mit anderen Worten gibt es unendlich viele Kanal-URLs und Commit-IDs, aus denen dasselbe Bündel stammen könnte. Wenn solche „stillen“ Metadaten Teil des Ausgabe sind, dann wird also die bitweise Reproduzierbarkeit von Quellcode zu Binärdateien eingeschränkt.

--root=Datei ¶

-r Datei

Die Datei zu einer symbolischen Verknüpfung auf das erzeugte Bündel machen und als Müllsammlerwurzel registrieren.

--localstatedir

--profile-name=Name

Das „lokale Zustandsverzeichnis“ /var/guix ins resultierende Bündel aufnehmen, speziell auch das Profil /var/guix/profiles/per-user/root/Name – der vorgegebene Name ist guix-profile, was ~root/.guix-profile entspricht.

/var/guix enthält die Store-Datenbank (siehe Der Store) sowie die Müllsammlerwurzeln (siehe guix gc aufrufen). Es ins Bündel aufzunehmen, bedeutet, dass der enthaltene Store „vollständig“ ist und von Guix verwaltet werden kann, andernfalls wäre der Store im Bündel „tot“ und nach dem Auspacken des Bündels könnte Guix keine Objekte mehr dort hinzufügen oder entfernen.

Ein Anwendungsfall hierfür ist der eigenständige, alle Komponenten umfassende binäre Tarball von Guix (siehe Aus Binärdatei installieren).

--derivation

-d

Den Namen der Ableitung ausgeben, die das Bündel erstellt.

--bootstrap

Mit den Bootstrap-Binärdateien das Bündel erstellen. Diese Option ist nur für Guix-Entwickler nützlich.

Außerdem unterstützt guix pack alle gemeinsamen Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen) und alle Paketumwandlungsoptionen (siehe Paketumwandlungsoptionen).