1.1 Auf Guix-Art Software verwalten

Guix bietet eine befehlszeilenbasierte Paketverwaltungsschnittstelle (siehe guix package aufrufen), Werkzeuge als Hilfestellung bei der Software-Entwicklung (siehe Entwicklung), Befehlszeilenwerkzeuge für fortgeschrittenere Nutzung (siehe Zubehör) sowie Schnittstellen zur Programmierung in Scheme (siehe Programmierschnittstelle). Der Erstellungs-Daemon ist für das Erstellen von Paketen im Auftrag von Nutzern verantwortlich (siehe Den Daemon einrichten) und für das Herunterladen vorerstellter Binärdateien aus autorisierten Quellen (siehe Substitute).

Guix enthält Paketdefinitionen für viele Pakete, manche aus GNU und andere nicht aus GNU, die alle die Freiheit des Computernutzers respektieren. Es ist erweiterbar: Nutzer können ihre eigenen Paketdefinitionen schreiben (siehe Pakete definieren) und sie als unabhängige Paketmodule verfügbar machen (siehe Paketmodule). Es ist auch anpassbar: Nutzer können spezialisierte Paketdefinitionen aus bestehenden ableiten, auch von der Befehlszeile (siehe Paketumwandlungsoptionen).

Intern implementiert Guix die Disziplin der funktionalen Paketverwaltung, zu der Nix schon die Pionierarbeit geleistet hat (siehe Danksagungen). In Guix wird der Prozess, ein Paket zu erstellen und zu installieren, als eine Funktion im mathematischen Sinn aufgefasst. Diese Funktion hat Eingaben, wie zum Beispiel Erstellungs-Skripts, einen Compiler und Bibliotheken, und liefert ein installiertes Paket. Als eine reine Funktion hängt sein Ergebnis allein von seinen Eingaben ab – zum Beispiel kann er nicht auf Software oder Skripts Bezug nehmen, die nicht ausdrücklich als Eingaben übergeben wurden. Eine Erstellungsfunktion führt immer zum selben Ergebnis, wenn ihr die gleiche Menge an Eingaben übergeben wurde. Sie kann die Umgebung des laufenden Systems auf keine Weise beeinflussen, zum Beispiel kann sie keine Dateien außerhalb ihrer Erstellungs- und Installationsverzeichnisse verändern. Um dies zu erreichen, laufen Erstellungsprozesse in isolierten Umgebungen (sogenannte Container), wo nur ausdrückliche Eingaben sichtbar sind.

Das Ergebnis von Paketerstellungsfunktionen wird im Dateisystem zwischengespeichert in einem besonderen Verzeichnis, was als der Store bezeichnet wird (siehe Der Store). Jedes Paket wird in sein eigenes Verzeichnis im Store installiert – standardmäßig ist er unter /gnu/store zu finden. Der Verzeichnisname enthält einen Hash aller Eingaben, anhand derer das Paket erzeugt wurde, somit hat das Ändern einer Eingabe einen völlig anderen Verzeichnisnamen zur Folge.

Dieses Vorgehen ist die Grundlage für die Guix auszeichnenden Funktionalitäten: Unterstützung transaktionsbasierter Paketaktualisierungen und -rücksetzungen, Installation von Paketen für jeden Nutzer sowie Garbage Collection für Pakete (siehe Funktionalitäten).

1.2 GNU-Distribution

Mit Guix kommt eine Distribution des GNU-Systems, die nur aus freier Software³ besteht. Die Distribution kann für sich allein installiert werden (siehe Systeminstallation), aber Guix kann auch auf einem bestehenden GNU/Linux-System installiert werden. Wenn wir die Anwendungsfälle unterscheiden möchten, bezeichnen wir die alleinstehende Distribution als „Guix System“ (mit englischer Aussprache).

Die Distribution stellt den Kern der GNU-Pakete, also insbesondere GNU libc, GCC und Binutils, sowie zahlreiche zum GNU-Projekt gehörende und nicht dazu gehörende Anwendungen zur Verfügung. Die vollständige Liste verfügbarer Pakete können Sie online einsehen, oder indem Sie guix package ausführen (siehe guix package aufrufen):

guix package --list-available

Unser Ziel ist, eine zu 100% freie Software-Distribution von Linux-basierten und von anderen GNU-Varianten anzubieten, mit dem Fokus darauf, das GNU-Projekt und die enge Zusammenarbeit seiner Bestandteile zu befördern, sowie die Programme und Werkzeuge hervorzuheben, die die Nutzer dabei unterstützen, von dieser Freiheit Gebrauch zu machen.

Pakete sind zurzeit auf folgenden Plattformen verfügbar:

x86_64-linux

Intel/AMD-x86_64-Architektur, Linux-Libre als Kernel.

i686-linux

Intel-32-Bit-Architektur (IA-32), Linux-Libre als Kernel.

armhf-linux

ARMv7-A-Architektur mit „hard float“, Thumb-2 und NEON, für die EABI „hard-float application binary interface“, mit Linux-Libre als Kernel.

aarch64-linux

64-Bit-ARMv8-A-Prozessoren, little-endian, mit Linux-Libre als Kernel.

i586-gnu

GNU/Hurd auf der Intel-32-Bit-Architektur (IA32).

Diese Konfiguration ist experimentell und befindet sich noch in der Entwicklung. Wenn Sie sie ausprobieren möchten, ist es am einfachsten, eine Instanz des Diensttyps hurd-vm-service-type auf Ihrer GNU/Linux-Maschine einzurichten (siehe hurd-vm-service-type). Siehe auch Mitwirken für Informationen, wie Sie helfen können!

mips64el-linux (eingeschränkte Unterstützung)

64-Bit-MIPS-Prozessoren, little-endian, speziell die Loongson-Reihe, n32-ABI, mit Linux-Libre als Kernel. Diese Konfiguration wird nicht länger in vollem Umfang unterstützt; insbesondere gibt es keine laufenden Bemühungen, die Funktionsfähigkeit dieser Architektur sicherzustellen. Wenn sich jemand findet, der diese Architektur wiederbeleben will, dann ist der Code dafür noch verfügbar.

powerpc-linux (eingeschränkte Unterstützung)

32-Bit-PowerPC-Prozessoren, big-endian, speziell der PowerPC G4 mit AltiVec, mit Linux-Libre als Kernel. Diese Konfiguration wird nicht in vollem Umfang unterstützt und es gibt keine laufenden Bemühungen, die Funktionsfähigkeit dieser Architektur sicherzustellen.

powerpc64le-linux

64-Bit-Prozessoren mit Power-Befehlssatz, little-endian, mit Linux-Libre als Kernel. Dazu gehören POWER9-Systeme wie die RYF-zertifizierte Talos-II-Hauptplatine. Bei der Plattform handelt es sich um eine „Technologievorschau“; obwohl sie unterstützt wird, gibt es noch keine Substitute von der Erstellungsfarm (siehe Substitute) und bei manchen Paketen könnte die Erstellung fehlschlagen (siehe Überblick über gemeldete Fehler und Änderungen). Dennoch arbeitet die Guix-Gemeinde aktiv daran, diese Unterstützung auszubauen, und jetzt ist eine gute Gelegenheit, sie auszuprobieren und mitzumachen!

riscv64-linux

64-Bit-Prozessoren mit RISC-V-Befehlssatz, little-endian, speziell der RV64GC, mit Linux-Libre als Kernel. Bei der Plattform handelt es sich um eine „Technologievorschau“; obwohl sie unterstützt wird, gibt es noch keine Substitute von der Erstellungsfarm (siehe Substitute) und bei manchen Paketen könnte die Erstellung fehlschlagen (siehe Überblick über gemeldete Fehler und Änderungen). Dennoch arbeitet die Guix-Gemeinde aktiv daran, diese Unterstützung auszubauen, und jetzt ist eine gute Gelegenheit, sie auszuprobieren und mitzumachen!

Mit Guix System deklarieren Sie alle Aspekte der Betriebssystemkonfiguration und Guix kümmert sich darum, die Konfiguration auf transaktionsbasierte, reproduzierbare und zustandslose Weise zu instanziieren (siehe Systemkonfiguration). Guix System benutzt den Kernel Linux-libre, das Shepherd-Initialisierungssystem (siehe Introduction in The GNU Shepherd Manual), die wohlbekannten GNU-Werkzeuge mit der zugehörigen Werkzeugkette sowie die grafische Umgebung und Systemdienste Ihrer Wahl.

Guix System ist auf allen oben genannten Plattformen außer mips64el-linux, powerpc-linux, powerpc64le-linux und riscv64-linux verfügbar.

Informationen, wie auf andere Architekturen oder Kernels portiert werden kann, finden Sie im Abschnitt Auf eine neue Plattform portieren.

Diese Distribution aufzubauen basiert auf Kooperation, und Sie sind herzlich eingeladen, dabei mitzumachen! Im Abschnitt Mitwirken stehen weitere Informationen, wie Sie uns helfen können.

2.1 Aus Binärdatei installieren

Dieser Abschnitt beschreibt, wie Sie Guix aus einem alle Komponenten umfassenden Tarball installieren, der Binärdateien für Guix und all seine Abhängigkeiten liefert. Dies geht in der Regel schneller, als Guix aus seinen Quelldateien zu installieren, was später beschrieben wird.

Wichtig: Dieser Abschnitt gilt nur für Systeme ohne Guix. Wenn Sie eine bestehende Guix-Installation haben, würden wichtige Systemdateien überschrieben, wenn Sie der Anleitung folgten.

Auf einigen GNU/Linux-Distributionen, wie Debian, Ubuntu und openSUSE, wird Guix über deren Paketverwaltung angeboten. Vielleicht bringen sie eine ältere Version als 123b722 mit, aber Sie können Guix anschließend über den Befehl ‘guix pull’ aktualisieren.

Wir empfehlen Systemadministratoren, die Guix installieren, egal ob über das Installations-Skript oder über die Paketverwaltung ihrer Fremddistribution, regelmäßig die Sicherheitshinweise zu lesen und zu befolgen, die guix pull anzeigt.

Wenn Sie Debian oder ein Debian-Derivat wie Ubuntu oder Trisquel verwenden, rufen Sie auf:

sudo apt install guix

Das Gleiche gilt auf openSUSE:

sudo zypper install guix

Wenn bei Ihnen Parabola läuft, können Sie, nachdem Sie das Repository pcr (Parabola Community Repo) aktiviert haben, mit diesem Befehl Guix installieren:

sudo pacman -S guix

Das Guix-Projekt stellt außerdem ein Shell-Skript bereit, guix-install.sh, mit dem der Installationsvorgang aus Binärdateien ohne ein Paketverwaltungsprogramm der Fremddistribution automatisiert wird⁵. Um guix-install.sh benutzen zu können, werden Bash, GnuPG, GNU tar, wget und Xz vorausgesetzt.

Das Skript führt Sie durch Folgendes:

• Herunterladen und Entpacken des Tarballs mit Binärdateien
• Einrichten des Erstellungs-Daemons
• Bereitstellen des Befehls ‚guix‘ an Benutzer außer root
• Substitut-Server einrichten

Führen Sie als Administratornutzer „root“ aus:

# cd /tmp
# wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
# chmod +x guix-install.sh
# ./guix-install.sh

Das Skript, um Guix zu installieren, können Sie auf Parabola auch als Paket bekommen (im Repository pcr). So können Sie es installieren und ausführen:

sudo pacman -S guix-installer
sudo guix-install.sh

Anmerkung: Nach Voreinstellung richtet guix-install.sh Guix so ein, dass vorerstellte Binärdateien, die wir als Substitute bezeichnen, von den Erstellungsfarmen des Projekts heruntergeladen werden (siehe Substitute). Wenn Sie keine Zustimmung zu Substituten geben, muss Guix alles auf Ihrem Rechner aus dem Quellcode heraus erstellen, wodurch jede Installation und jede Aktualisierung sehr aufwendig wird. Siehe Vom Vertrauen gegenüber Binärdateien für eine Erörterung, aus welchen Gründen man Pakete aus dem Quellcode heraus erstellen wollen könnte.

Um Substitute von bordeaux.guix.gnu.org, ci.guix.gnu.org oder einem Spiegelserver davon zu benutzen (siehe Substitute), müssen Sie sie erst autorisieren. Zum Beispiel:

# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub

Wenn Sie die Installation von Guix erledigt haben, werfen Sie einen Blick auf Anwendungen einrichten für weitere Einstellungen, die Sie vielleicht vornehmen möchten, und lesen Sie die ersten Schritte im Einstieg, um loszulegen!

Anmerkung: Der Tarball zur Installation aus einer Binärdatei kann einfach durch Ausführung des folgenden Befehls im Guix-Quellbaum (re-)produziert und verifiziert werden:

make guix-binary.System.tar.xz

… was wiederum dies ausführt:

guix pack -s System --localstatedir \
  --profile-name=current-guix guix

Siehe guix pack aufrufen für weitere Informationen zu diesem praktischen Werkzeug.

Falls Sie Guix irgendwann deinstallieren möchten, führen Sie dasselbe Skript mit der Befehlszeilenoption --uninstall aus:

./guix-install.sh --uninstall

Durch --uninstall wird das Skript alle Dateien, Konfigurationen und Dienste von Guix unwiederbringlich löschen.

2.2 Den Daemon einrichten

Bei der Installation wurde der Erstellungs-Daemon, der laufen muss, damit man Guix benutzen kann, bereits eingerichtet und Sie können Befehle mit guix in Ihrem Terminalprogramm ausführen, siehe Einstieg:

guix build hello

Wenn dies ohne Fehler durchläuft, können Sie diesen Abschnitt auch überspringen. Ihre nächste Station wäre der nachfolgende Abschnitt, Anwendungen einrichten.

Allerdings ist jetzt ein guter Zeitpunkt, um alte Versionen des Daemons auszutauschen, Anpassungen vorzunehmen, Erstellungen auf andere Maschinen auszulagern (siehe Nutzung der Auslagerungsfunktionalität) oder ihn in speziellen Umgebungen manuell zu starten, z.B. in „chroots“ (siehe Chroot ins vorliegende System) oder WSL (nicht nötig bei mit Guix erzeugten WSL-Abbildern, siehe wsl2-image-type). Wenn Sie mehr wissen möchten oder vorhaben, Ihr System zu optimieren, lohnt es sich, diesen Abschnitt zu lesen.

Operationen wie das Erstellen eines Pakets oder Laufenlassen des Müllsammlers werden alle durch einen spezialisierten Prozess durchgeführt, den Erstellungs-Daemon, im Auftrag seiner Kunden (den Clients). Nur der Daemon darf auf den Store und seine zugehörige Datenbank zugreifen. Daher wird jede den Store verändernde Operation durch den Daemon durchgeführt. Zum Beispiel kommunizieren Befehlszeilenwerkzeuge wie guix package und guix build mit dem Daemon (mittels entfernter Prozeduraufrufe), um ihm Anweisungen zu geben, was er tun soll.

Folgende Abschnitte beschreiben, wie Sie die Umgebung des Erstellungs-Daemons ausstatten sollten. Siehe Substitute für Informationen darüber, wie Sie es dem Daemon ermöglichen, vorerstellte Binärdateien herunterzuladen.

• Einrichten der Erstellungsumgebung
• Nutzung der Auslagerungsfunktionalität
• SELinux-Unterstützung

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild                  \
            -d /var/empty -s $(which nologin)          \
            -c "Guix-Erstellungsbenutzer $i" --system  \
            guixbuilder$i;
  done

# guix-daemon --build-users-group=guixbuild

(list (build-machine
        (name "eightysix.example.org")
        (systems (list "x86_64-linux" "i686-linux"))
        (host-key "ssh-ed25519 AAAAC3Nza…")
        (user "bob")
        (speed 2.))     ;unglaublich schnell!

      (build-machine
        (name "armeight.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")

        ;; Weil 'guix offload' vom 'guix-daemon' als
        ;; Administratornutzer root gestartet wird.
        (private-key "/root/.ssh/identität-für-guix")))

ssh build-machine guix repl --version

# guix archive --generate-key

# guix archive --authorize < öffentlicher-schlüssel-hauptmaschine.txt

# guix offload test

# guix offload test maschinen-qualif.scm

# guix offload test maschinen.scm '\.gnu\.org$'

# guix offload status

semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil

mount -o remount,rw /gnu/store
restorecon -R /gnu /var/guix

systemctl restart guix-daemon

ps -Zax | grep guix-daemon

2.3 Aufruf von guix-daemon

Das Programm guix-daemon implementiert alle Funktionalitäten, um auf den Store zuzugreifen. Dazu gehört das Starten von Erstellungsprozessen, das Ausführen des Müllsammlers, das Abfragen, ob ein Erstellungsergebnis verfügbar ist, etc. Normalerweise wird er so als Administratornutzer (root) gestartet:

# guix-daemon --build-users-group=guixbuild

Sie können den Daemon auch über das systemd-Protokoll zur „Socket-Aktivierung“ starten (siehe make-systemd-constructor in The GNU Shepherd Manual).

Details, wie Sie ihn einrichten, finden Sie im Abschnitt Den Daemon einrichten.

Standardmäßig führt guix-daemon Erstellungsprozesse mit unterschiedlichen UIDs aus, die aus der Erstellungsgruppe stammen, deren Name mit --build-users-group übergeben wurde. Außerdem läuft jeder Erstellungsprozess in einer chroot-Umgebung, die nur die Teilmenge des Stores enthält, von der der Erstellungsprozess abhängt, entsprechend seiner Ableitung (siehe Ableitungen), und ein paar bestimmte Systemverzeichnisse, darunter standardmäßig auch /dev und /dev/pts. Zudem ist die Erstellungsumgebung auf GNU/Linux eine isolierte Umgebung, d.h. ein Container: Nicht nur hat sie ihren eigenen Dateisystembaum, sie hat auch einen separaten Namensraum zum Einhängen von Dateisystemen, ihren eigenen Namensraum für PIDs, für Netzwerke, etc. Dies hilft dabei, reproduzierbare Erstellungen zu garantieren (siehe Funktionalitäten).

Wenn der Daemon im Auftrag des Nutzers eine Erstellung durchführt, erzeugt er ein Erstellungsverzeichnis, entweder in /tmp oder im Verzeichnis, das durch die Umgebungsvariable TMPDIR angegeben wurde. Dieses Verzeichnis wird mit dem Container geteilt, solange die Erstellung noch läuft, allerdings trägt es im Container stattdessen immer den Namen „/tmp/guix-build-NAME.drv-0“.

Nach Abschluss der Erstellung wird das Erstellungsverzeichnis automatisch entfernt, außer wenn die Erstellung fehlgeschlagen ist und der Client --keep-failed angegeben hat (siehe --keep-failed).

Der Daemon lauscht auf Verbindungen und erstellt jeweils einen Unterprozess für jede von einem Client begonnene Sitzung (d.h. von einem der guix-Unterbefehle). Der Befehl guix processes zeigt Ihnen eine Übersicht solcher Systemaktivitäten; damit werden Ihnen alle aktiven Sitzungen und Clients gezeigt. Weitere Informationen finden Sie unter guix processes aufrufen.

Die folgenden Befehlszeilenoptionen werden unterstützt:

--build-users-group=Gruppe

Verwende die Benutzerkonten aus der Gruppe, um Erstellungsprozesse auszuführen (siehe Erstellungsbenutzer).

--no-substitutes ¶

Benutze keine Substitute für Erstellungsergebnisse. Das heißt, dass alle Objekte lokal erstellt werden müssen, und kein Herunterladen von vorab erstellten Binärdateien erlaubt ist (siehe Substitute).

Wenn der Daemon mit --no-substitutes ausgeführt wird, können Clients trotzdem Substitute explizit aktivieren über den entfernten Prozeduraufruf set-build-options (siehe Der Store).

--substitute-urls=URLs

URLs als standardmäßige, leerzeichengetrennte Liste der Quell-URLs für Substitute benutzen. Wenn diese Befehlszeilenoption nicht angegeben wird, wird ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org’ verwendet.

Das hat zur Folge, dass Substitute von den URLs heruntergeladen werden können, solange sie mit einer Signatur versehen sind, der vertraut wird (siehe Substitute).

Siehe Substitute von anderen Servern holen für weitere Informationen, wie der Daemon konfiguriert werden kann, um Substitute von anderen Servern zu beziehen.

--no-offload

Nicht versuchen, an andere Maschinen ausgelagerte Erstellungen zu benutzen (siehe Nutzung der Auslagerungsfunktionalität). Somit wird lokal erstellt, statt Erstellungen auf entfernte Maschinen auszulagern.

--cache-failures

Fehler bei der Erstellung zwischenspeichern. Normalerweise werden nur erfolgreiche Erstellungen gespeichert.

Wenn diese Befehlszeilenoption benutzt wird, kann guix gc --list-failures benutzt werden, um die Menge an Store-Objekten abzufragen, die als Fehlschläge markiert sind; guix gc --clear-failures entfernt Store-Objekte aus der Menge zwischengespeicherter Fehlschläge. Siehe guix gc aufrufen.

--cores=n

-c n

n CPU-Kerne zum Erstellen jeder Ableitung benutzen; 0 heißt, so viele wie verfügbar sind.

Der Vorgabewert ist 0, jeder Client kann jedoch eine abweichende Anzahl vorgeben, zum Beispiel mit der Befehlszeilenoption --cores von guix build (siehe Aufruf von guix build).

Dadurch wird die Umgebungsvariable NIX_BUILD_CORES im Erstellungsprozess definiert, welcher sie benutzen kann, um intern parallele Ausführungen zuzulassen – zum Beispiel durch Nutzung von make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Höchstenss n Erstellungsaufträge parallel bearbeiten. Der Vorgabewert liegt bei 1. Wird er auf 0 gesetzt, werden keine Erstellungen lokal durchgeführt, stattdessen lagert der Daemon sie nur aus (siehe Nutzung der Auslagerungsfunktionalität) oder sie schlagen einfach fehl.

--max-silent-time=Sekunden

Wenn der Erstellungs- oder Substitutionsprozess länger als Sekunden-lang keine Ausgabe erzeugt, wird er abgebrochen und ein Fehler beim Erstellen gemeldet.

Der Vorgabewert ist 3600 (eine Stunde).

Clients können einen anderen Wert als den hier angegebenen verwenden lassen (siehe --max-silent-time).

--timeout=Sekunden

Entsprechend wird hier der Erstellungs- oder Substitutionsprozess abgebrochen und als Fehlschlag gemeldet, wenn er mehr als Sekunden-lang dauert.

Vorgegeben sind 24 Stunden.

Clients können einen anderen Wert verwenden lassen (siehe --timeout).

--rounds=N

Jede Ableitung n-mal hintereinander erstellen und einen Fehler melden, wenn nacheinander ausgewertete Erstellungsergebnisse nicht Bit für Bit identisch sind. Beachten Sie, dass Clients wie guix build einen anderen Wert verwenden lassen können (siehe Aufruf von guix build).

Wenn dies zusammen mit --keep-failed benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen /gnu/store/…-check. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden.

--debug

Informationen zur Fehlersuche ausgeben.

Dies ist nützlich, um Probleme beim Starten des Daemons nachzuvollziehen; Clients könn aber auch ein abweichenden Wert verwenden lassen, zum Beispiel mit der Befehlszeilenoption --verbosity von guix build (siehe Aufruf von guix build).

--chroot-directory=Verzeichnis

Füge das Verzeichnis zum chroot von Erstellungen hinzu.

Dadurch kann sich das Ergebnis von Erstellungsprozessen ändern – zum Beispiel, wenn diese optionale Abhängigkeiten aus dem Verzeichnis verwenden, wenn sie verfügbar sind, und nicht, wenn es fehlt. Deshalb ist es nicht empfohlen, dass Sie diese Befehlszeilenoption verwenden, besser sollten Sie dafür sorgen, dass jede Ableitung alle von ihr benötigten Eingabgen deklariert.

--disable-chroot

Erstellungen ohne chroot durchführen.

Diese Befehlszeilenoption zu benutzen, wird nicht empfohlen, denn auch dadurch bekämen Erstellungsprozesse Zugriff auf nicht deklarierte Abhängigkeiten. Sie ist allerdings unvermeidlich, wenn guix-daemon auf einem Benutzerkonto ohne ausreichende Berechtigungen ausgeführt wird.

--log-compression=Typ

Erstellungsprotokolle werden entsprechend dem Typ komprimiert, der entweder gzip, bzip2 oder none (für keine Kompression) sein muss.

Sofern nicht --lose-logs angegeben wurde, werden alle Erstellungsprotokolle in der localstatedir gespeichert. Um Platz zu sparen, komprimiert sie der Daemon standardmäßig automatisch mit gzip.

--discover[=yes|no]

Ob im lokalen Netzwerk laufende Substitutserver mit mDNS und DNS-SD ermittelt werden sollen oder nicht.

Diese Funktionalität ist noch experimentell. Trotzdem sollten Sie bedenken:

1. Es könnte schneller bzw. günstiger sein, als Substitute von entfernten Servern zu beziehen.
2. Es gibt keine Sicherheitsrisiken, weil nur echte Substitute benutzt werden können (siehe Substitutauthentifizierung).
3. Wenn ein Angreifer Ihnen sein guix publish in Ihrem LAN mitteilt, kann er Ihnen keine bösartigen Programmdateien unterjubeln, aber er kann lernen, welche Software Sie installieren.
4. Server können Ihnen Substitute über unverschlüsseltes HTTP anbieten, wodurch auch jeder andere in Ihrem LAN vielleicht mitschneiden könnte, welche Software Sie installieren.

Das Erkennen von Substitutservern können Sie auch nachträglich zur Laufzeit an- oder abschalten („on“ oder „off“), indem Sie dies ausführen:

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication ¶

Automatische Dateien-„Deduplizierung“ im Store ausschalten.

Standardmäßig werden zum Store hinzugefügte Objekte automatisch „dedupliziert“: Wenn eine neue Datei mit einer anderen im Store übereinstimmt, wird die neue Datei stattdessen als harte Verknüpfung auf die andere Datei angelegt. Dies reduziert den Speicherverbrauch auf der Platte merklich, jedoch steigt andererseits die Auslastung bei der Ein-/Ausgabe im Erstellungsprozess geringfügig. Durch diese Option wird keine solche Optimierung durchgeführt.

--gc-keep-outputs[=yes|no]

Gibt an, ob der Müllsammler (Garbage Collector, GC) die Ausgaben lebendiger Ableitungen behalten muss („yes“) oder nicht („no“).

Für yes behält der Müllsammler die Ausgaben aller lebendigen Ableitungen im Store – die .drv-Dateien. Der Vorgabewert ist aber no, so dass Ableitungsausgaben nur vorgehalten werden, wenn sie von einer Müllsammlerwurzel aus erreichbar sind. Siehe den Abschnitt guix gc aufrufen für weitere Informationen zu Müllsammlerwurzeln.

--gc-keep-derivations[=yes|no]

Gibt an, ob der Müllsammler (GC) Ableitungen behalten muss („yes“), wenn sie lebendige Ausgaben haben, oder nicht („no“).

Für yes, den Vorgabewert, behält der Müllsammler Ableitungen – z.B. .drv-Dateien –, solange zumindest eine ihrer Ausgaben lebendig ist. Dadurch können Nutzer den Ursprung der Dateien in ihrem Store nachvollziehen. Setzt man den Wert auf no, wird ein bisschen weniger Speicher auf der Platte verbraucht.

Auf diese Weise überträgt sich, wenn --gc-keep-derivations auf yes steht, die Lebendigkeit von Ausgaben auf Ableitungen, und wenn --gc-keep-outputs auf yes steht, die Lebendigkeit von Ableitungen auf Ausgaben. Stehen beide auf yes, bleiben so alle Erstellungsvoraussetzungen wie Quelldateien, Compiler, Bibliotheken und andere Erstellungswerkzeuge lebendiger Objekte im Store erhalten, ob sie von einer Müllsammlerwurzel aus erreichbar sind oder nicht. Entwickler können sich so erneute Erstellungen oder erneutes Herunterladen sparen.

--impersonate-linux-2.6

Auf Linux-basierten Systemen wird hiermit vorgetäuscht, dass es sich um Linux 2.6 handeln würde, indem der Kernel für einen uname-Systemaufruf als Version der Veröffentlichung mit 2.6 antwortet.

Dies kann hilfreich sein, um Programme zu erstellen, die (normalerweise zu Unrecht) von der Kernel-Versionsnummer abhängen.

--lose-logs

Keine Protokolle der Erstellungen vorhalten. Normalerweise würden solche in localstatedir/guix/log gespeichert.

--system=System

Verwende System als aktuellen Systemtyp. Standardmäßig ist dies das Paar aus Befehlssatz und Kernel, welches beim Aufruf von configure erkannt wurde, wie zum Beispiel x86_64-linux.

--listen=Endpunkt

Lausche am Endpunkt auf Verbindungen. Dabei wird der Endpunkt als Dateiname eines Unix-Sockets verstanden, wenn er mit einem / (Schrägstrich) beginnt. Andernfalls wird der Endpunkt als Rechnername (d.h. Hostname) oder als Rechnername-Port-Paar verstanden, auf dem gelauscht wird. Hier sind ein paar Beispiele:

--listen=/gnu/var/daemon

Lausche auf Verbindungen am Unix-Socket /gnu/var/daemon, falls nötig wird er dazu erstellt.

--listen=localhost ¶

Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die localhost entspricht, auf Port 44146.

--listen=128.0.0.42:1234

Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die 128.0.0.42 entspricht, auf Port 1234.

Diese Befehlszeilenoption kann mehrmals wiederholt werden. In diesem Fall akzeptiert guix-daemon Verbindungen auf allen angegebenen Endpunkten. Benutzer können bei Client-Befehlen angeben, mit welchem Endpunkt sie sich verbinden möchten, indem sie die Umgebungsvariable GUIX_DAEMON_SOCKET festlegen (siehe GUIX_DAEMON_SOCKET).

Anmerkung: Das Daemon-Protokoll ist weder authentifiziert noch verschlüsselt. Die Benutzung von --listen=Rechner eignet sich für lokale Netzwerke, wie z.B. in Rechen-Clustern, wo sich nur solche Knoten mit dem Daemon verbinden, denen man vertraut. In Situationen, wo ein Fernzugriff auf den Daemon durchgeführt wird, empfehlen wir, über Unix-Sockets in Verbindung mit SSH zuzugreifen.

Wird --listen nicht angegeben, lauscht guix-daemon auf Verbindungen auf dem Unix-Socket, der sich unter localstatedir/guix/daemon-socket/socket befindet.

2.4 Anwendungen einrichten

Läuft Guix aufgesetzt auf einer GNU/Linux-Distribution außer Guix System – einer sogenannten Fremddistribution –, so sind ein paar zusätzliche Schritte bei der Einrichtung nötig. Hier finden Sie manche davon.

• Locales
• Name Service Switch
• X11-Schriftarten
• X.509-Zertifikate
• Emacs-Pakete

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-kanadische-utf8-locales"))

guix install fontconfig
fc-cache -rv

guix install font-adobe-source-han-sans:cn

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

2.5 Aktualisieren von Guix

Um Guix zu aktualisieren, führen Sie aus:

guix pull

Siehe guix pull aufrufen für weitere Informationen.

Auf einer Fremddistribution können Sie den Erstellungsdaemon aktualisieren, indem Sie diesen Befehl:

sudo -i guix pull

gefolgt von diesem ausführen (unter der Annahme, dass Ihre Distribution zur Dienstverwaltung das systemd-Werkzeug benutzt):

systemctl restart guix-daemon.service

Auf Guix System wird der Daemon aktualisiert, indem Sie das System rekonfigurieren (siehe guix system reconfigure).

3.1 Einschränkungen

Wir denken, dass Guix System für viele Anwendungszwecke von Heim- und Bürorechnern bis hin zu Servern geeignet ist. Die Verlässlichkeitsgarantien, die es einem bietet – transaktionelle Aktualisierungen und Rücksetzungen, Reproduzierbarkeit – machen es zu einer soliden Grundlage.

Immer mehr Systemdienste sind verfügbar (siehe Dienste).

Bevor Sie mit der Installation fortfahren, denken Sie daran, dass in der Version 123b722 vielleicht von Ihnen benötigte Dienste fehlen.

Dies soll allerdings nicht nur ein Hinweis sein, sondern auch als Einladung aufgefasst werden, uns Fehler (und Erfolgsgeschichten!) zu melden und bei uns mitzumachen, um Guix zu verbessern. Siehe den Abschnitt Mitwirken.

3.2 Hardware-Überlegungen

GNU Guix legt den Fokus darauf, die Freiheit des Nutzers auf seinem Rechner zu respektieren. Es baut auf Linux-libre als Kernel auf, wodurch nur Hardware unterstützt wird, für die Treiber und Firmware existieren, die freie Software sind. Heutzutage wird ein großer Teil der handelsüblichen Hardware von GNU/Linux-libre unterstützt – von Tastaturen bis hin zu Grafikkarten, Scannern und Ethernet-Adaptern. Leider gibt es noch Bereiche, wo die Hardwareanbieter ihren Nutzern die Kontrolle über ihren eigenen Rechner verweigern. Solche Hardware wird von Guix System nicht unterstützt.

Einer der wichtigsten Bereiche, wo es an freien Treibern und freier Firmware mangelt, sind WLAN-Geräte. WLAN-Geräte, von denen wir wissen, dass sie funktionieren, sind unter anderem solche, die die Atheros-Chips AR9271 und AR7010 verbauen, welche der Linux-libre-Treiber ath9k unterstützt, und die, die Broadcom/AirForce-Chips BCM43xx (mit Wireless-Core Revision 5) verbauen, welche der Linux-libre-Treiber b43-open unterstützt. Freie Firmware gibt es für beide und sie wird von Haus aus mit Guix System als ein Teil von %base-firmware mitgeliefert (siehe firmware).

Das Installationsprogramm zeigt zu Beginn eine Warnung an, wenn es Geräte erkennt, die bekanntlich nicht funktionieren, weil es keine freie Firmware oder keine freien Treiber dafür gibt.

Die Free Software Foundation betreibt Respects Your Freedom (RYF), ein Zertifizierungsprogramm für Hardware-Produkte, die Ihre Freiheit respektieren, Datenschutz gewährleisten und sicherstellen, dass Sie die Kontrolle über Ihr Gerät haben. Wir ermutigen Sie dazu, die Liste RYF-zertifizierter Geräte zu beachten.

Eine weitere nützliche Ressource ist die Website H-Node. Dort steht ein Katalog von Hardware-Geräten mit Informationen darüber, wie gut sie von GNU/Linux unterstützt werden.

3.3 Installation von USB-Stick oder DVD

Sie können ein ISO-9660-Installationsabbild von ‘https://ftp.gnu.org/gnu/guix/guix-system-install-123b722.x86_64-linux.iso’ herunterladen, dass Sie auf einen USB-Stick aufspielen oder auf eine DVD brennen können, wobei Sie anstelle von x86_64-linux eines der folgenden schreiben können:

x86_64-linux

für ein GNU/Linux-System auf Intel/AMD-kompatiblen 64-Bit-Prozessoren,

i686-linux

für ein 32-Bit-GNU/Linux-System auf Intel-kompatiblen Prozessoren.

Laden Sie auch die entsprechende .sig-Datei herunter und verifizieren Sie damit die Authentizität Ihres Abbilds, indem Sie diese Befehle eingeben:

$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-123b722.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-123b722.x86_64-linux.iso.sig

Falls dieser Befehl fehlschlägt, weil Sie nicht über den nötigen öffentlichen Schlüssel verfügen, können Sie ihn mit diesem Befehl importieren:

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 \
      -qO - | gpg --import -

und den Befehl gpg --verify erneut ausführen.

Beachten Sie, dass eine Warnung wie „Dieser Schlüssel trägt keine vertrauenswürdige Signatur!“ normal ist.

Dieses Abbild enthält die Werkzeuge, die Sie zur Installation brauchen. Es ist dafür gedacht, so wie es ist auf einen hinreichend großen USB-Stick oder eine DVD kopiert zu werden.

• Kopieren auf einen USB-Stick
• Auf eine DVD brennen
• Das System starten

dd if=guix-system-install-123b722.x86_64-linux.iso of=/dev/sdX status=progress
sync

growisofs -dvd-compat -Z /dev/srX=guix-system-install-123b722.x86_64-linux.iso

3.4 Vor der Installation

Wenn Sie Ihren Rechner gebootet haben, können Sie sich vom grafischen Installationsprogramm durch den Installationsvorgang führen lassen, was den Einstieg leicht macht (siehe Geführte grafische Installation). Alternativ können Sie sich auch für einen „manuellen“ Installationsvorgang entscheiden, wenn Sie bereits mit GNU/Linux vertraut sind und mehr Kontrolle haben möchten, als sie das grafische Installationsprogramm bietet (siehe Manuelle Installation).

Das grafische Installationsprogramm steht Ihnen auf TTY1 zur Verfügung. Auf den TTYs 3 bis 6 können Sie vor sich eine Eingabeaufforderung für den Administratornutzer „root“ sehen, nachdem Sie strg-alt-f3, strg-alt-f4 usw. gedrückt haben. TTY2 zeigt Ihnen dieses Handbuch, das Sie über die Tastenkombination strg-alt-f2 erreichen. In dieser Dokumentation können Sie mit den Steuerungsbefehlen Ihres Info-Betrachters blättern (siehe Stand-alone GNU Info). Auf dem Installationssystem läuft der GPM-Maus-Daemon, wodurch Sie Text mit der linken Maustaste markieren und ihn mit der mittleren Maustaste einfügen können.

Anmerkung: Für die Installation benötigen Sie Zugang zum Internet, damit fehlende Abhängigkeiten Ihrer Systemkonfiguration heruntergeladen werden können. Im Abschnitt „Netzwerkkonfiguration“ weiter unten finden Sie mehr Informationen dazu.

3.5 Geführte grafische Installation

Das grafische Installationsprogramm ist mit einer textbasierten Benutzeroberfläche ausgestattet. Es kann Sie mit Dialogfeldern durch die Schritte führen, mit denen Sie GNU Guix System installieren.

Die ersten Dialogfelder ermöglichen es Ihnen, das System aufzusetzen, wie Sie es bei der Installation benutzen: Sie können die Sprache und Tastaturbelegung festlegen und die Netzwerkanbindung einrichten, die während der Installation benutzt wird. Das folgende Bild zeigt den Dialog zur Einrichtung der Netzwerkanbindung.

Mit den danach kommenden Schritten können Sie Ihre Festplatte partitionieren, wie im folgenden Bild gezeigt, und auswählen, ob Ihre Dateisysteme verschlüsselt werden sollen oder nicht. Sie können Ihren Rechnernamen und das Administratorpasswort (das „root“-Passwort) festlegen und ein Benutzerkonto einrichten, und noch mehr.

Beachten Sie, dass Sie mit dem Installationsprogramm jederzeit den aktuellen Installationsschritt verlassen und zu einem vorherigen Schritt zurückkehren können, wie Sie im folgenden Bild sehen können.

Sobald Sie fertig sind, erzeugt das Installationsprogramm eine Betriebssystemkonfiguration und zeigt sie an (siehe Das Konfigurationssystem nutzen). Zu diesem Zeitpunkt können Sie auf „OK“ drücken und die Installation wird losgehen. Ist sie erfolgreich, können Sie neu starten und Ihr neues System genießen. Siehe Nach der Systeminstallation für Informationen, wie es weitergeht!

3.6 Manuelle Installation

Dieser Abschnitt beschreibt, wie Sie GNU Guix System auf manuelle Weise auf Ihrer Maschine installieren. Diese Alternative setzt voraus, dass Sie bereits mit GNU/Linux, der Shell und üblichen Administrationswerkzeugen vertraut sind. Wenn Sie glauben, dass das nichts für Sie ist, dann möchten Sie vielleicht das geführte grafische Installationsprogramm benutzen (siehe Geführte grafische Installation).

Das Installationssystem macht Eingabeaufforderungen auf den TTYs 3 bis 6 zugänglich, auf denen Sie als Administratornutzer Befehle eingeben können; Sie erreichen diese, indem Sie die Tastenkombinationen strg-alt-f3, strg-alt-f4 und so weiter benutzen. Es enthält viele übliche Werkzeuge, mit denen Sie diese Aufgabe bewältigen können. Da es sich auch um ein vollständiges „Guix System“-System handelt, können Sie aber auch andere Pakete mit dem Befehl guix package nachinstallieren, wenn Sie sie brauchen (siehe guix package aufrufen).

• Tastaturbelegung, Netzwerkanbindung und Partitionierung
• Fortfahren mit der Installation

loadkeys dvorak

ifconfig -a

ip address

dhclient -v Schnittstelle

ping -c 3 gnu.org

herd set-http-proxy guix-daemon URL

herd start ssh-daemon

cfdisk

parted /dev/sda set 1 esp on

mkfs.fat -F32 /dev/sda1

mkfs.ext4 -L my-root /dev/sda2

cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

mount LABEL=my-root /mnt

mkswap /dev/sda3
swapon /dev/sda3

# Das bedeutet 10 GiB Swapspeicher. "count" anpassen zum Ändern.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# Zur Sicherheit darf nur der Administrator lesen und schreiben.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

herd start cow-store /mnt

# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm

guix system init /mnt/etc/config.scm /mnt

3.7 Nach der Systeminstallation

Sie haben es geschafft: Sie haben Guix System erfolgreich gebootet! Sie können Guix System aktualisieren, wann Sie möchten, indem Sie das hier ausführen:

guix pull
sudo guix system reconfigure /etc/config.scm

Dadurch wird eine neue Systemgeneration aus den neuesten Paketen und Diensten erstellt.

Werfen Sie nun einen Blick auf Einstieg und besuchen Sie uns auf #guix auf dem Libera.Chat-IRC-Netzwerk oder auf der Mailing-Liste guix-devel@gnu.org, um uns Rückmeldung zu geben!

3.8 Guix in einer virtuellen Maschine installieren

Wenn Sie Guix System auf einer virtuellen Maschine (VM) oder einem „Virtual Private Server“ (VPS) statt auf Ihrer echten Maschine installieren möchten, ist dieser Abschnitt hier richtig für Sie.

Um eine virtuelle Maschine für QEMU aufzusetzen, mit der Sie Guix System in ein „Disk-Image“ installieren können (also in eine Datei mit einem Abbild eines Plattenspeichers), gehen Sie so vor:

1. Zunächst laden Sie das Installationsabbild des Guix-Systems wie zuvor beschrieben herunter und entpacken es (siehe Installation von USB-Stick oder DVD).
2. Legen Sie nun ein Disk-Image an, das das System nach der Installation enthalten soll. Um ein qcow2-formatiertes Disk-Image zu erstellen, benutzen Sie den Befehl qemu-img:

   qemu-img create -f qcow2 guix-system.img 50G
   

   Die Datei, die Sie herausbekommen, wird wesentlich kleiner als 50 GB sein (typischerweise kleiner als 1 MB), vergrößert sich aber, wenn der virtualisierte Speicher gefüllt wird.

3. Starten Sie das USB-Installationsabbild auf einer virtuellen Maschine:

   qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
     -nic user,model=virtio-net-pci -boot menu=on,order=d \
     -drive file=guix-system.img \
     -drive media=cdrom,readonly=on,file=guix-system-install-123b722.System.iso
   

   -enable-kvm ist optional, verbessert die Rechenleistung aber erheblich, siehe Guix in einer virtuellen Maschine betreiben.

4. Sie sind nun in der virtuellen Maschine als Administratornutzer root angemeldet und können mit der Installation wie gewohnt fortfahren. Folgen Sie der Anleitung im Abschnitt Vor der Installation.

Wurde die Installation abgeschlossen, können Sie das System starten, das sich nun als Abbild in der Datei guix-system.img befindet. Der Abschnitt Guix in einer virtuellen Maschine betreiben erklärt, wie Sie das tun können.

3.9 Ein Abbild zur Installation erstellen

Das oben beschriebene Installationsabbild wurde mit dem Befehl guix system erstellt, genauer gesagt mit:

guix system image -t iso9660 gnu/system/install.scm

Die Datei gnu/system/install.scm finden Sie im Quellbaum von Guix. Schauen Sie sich die Datei und auch den Abschnitt guix system aufrufen an, um mehr Informationen über das Installationsabbild zu erhalten.

3.10 Abbild zur Installation für ARM-Rechner erstellen

Viele ARM-Chips funktionieren nur mit ihrer eigenen speziellen Variante des U-Boot-Bootloaders.

Wenn Sie ein Disk-Image erstellen und der Bootloader nicht anderweitig schon installiert ist (auf einem anderen Laufwerk), ist es ratsam, ein Disk-Image zu erstellen, was den Bootloader enthält, mit dem Befehl:

guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 ist der Name des Chips. Wenn Sie einen ungültigen Namen eingeben, wird eine Liste möglicher Chip-Namen ausgegeben.

5.1 Funktionalitäten

Wir nehmen hier an, dass Sie schon Ihre ersten Erfahrungen mit Guix gemacht haben (siehe Einstieg) und gerne einen Überblick darüber bekommen würden, wie Guix im Detail funktioniert.

Wenn Sie Guix benutzen, landet jedes Paket schließlich im Paket-Store in seinem eigenen Verzeichnis – der Name ist ähnlich wie /gnu/store/xxx-package-1.2, wobei xxx eine Zeichenkette in Base32-Darstellung ist.

Statt diese Verzeichnisse direkt anzugeben, haben Nutzer ihr eigenes Profil, welches auf diejenigen Pakete zeigt, die sie tatsächlich benutzen wollen. Diese Profile sind im Persönlichen Verzeichnis des jeweiligen Nutzers gespeichert als $HOME/.guix-profile.

Zum Beispiel installiert alice GCC 4.7.2. Dadurch zeigt dann /home/alice/.guix-profile/bin/gcc auf /gnu/store/…-gcc-4.7.2/bin/gcc. Auf demselben Rechner hat bob bereits GCC 4.8.0 installiert. Das Profil von bob zeigt dann einfach weiterhin auf /gnu/store/…-gcc-4.8.0/bin/gcc – d.h. beide Versionen von GCC koexistieren auf demselben System, ohne sich zu stören.

Der Befehl guix package ist das zentrale Werkzeug, um Pakete zu verwalten (siehe guix package aufrufen). Es arbeitet auf dem eigenen Profil jedes Nutzers und kann mit normalen Benutzerrechten ausgeführt werden.

Der Befehl stellt die offensichtlichen Installations-, Entfernungs- und Aktualisierungsoperationen zur Verfügung. Jeder Aufruf ist tatsächlich eine eigene Transaktion: Entweder die angegebene Operation wird erfolgreich durchgeführt, oder gar nichts passiert. Wenn also der Prozess von guix package während der Transaktion beendet wird, oder es zum Stromausfall während der Transaktion kommt, dann bleibt der alte, nutzbare Zustands des Nutzerprofils erhalten.

Zudem kann jede Pakettransaktion zurückgesetzt werden (Rollback). Wird also zum Beispiel durch eine Aktualisierung eine neue Version eines Pakets installiert, die einen schwerwiegenden Fehler zur Folge hat, können Nutzer ihr Profil einfach auf die vorherige Profilinstanz zurücksetzen, von der sie wissen, dass sie gut lief. Ebenso unterliegt bei Guix auch die globale Systemkonfiguration transaktionellen Aktualisierungen und Rücksetzungen (siehe Einstieg).

Alle Pakete im Paket-Store können vom Müllsammler (Garbage Collector) gelöscht werden. Guix ist in der Lage, festzustellen, welche Pakete noch durch Benutzerprofile referenziert werden, und entfernt nur diese, die nachweislich nicht mehr referenziert werden (siehe guix gc aufrufen). Benutzer können auch ausdrücklich alte Generationen ihres Profils löschen, damit die zugehörigen Pakete vom Müllsammler gelöscht werden können.

Guix verfolgt einen rein funktionalen Ansatz bei der Paketverwaltung, wie er in der Einleitung beschrieben wurde (siehe Einführung). Jedes Paketverzeichnis im /gnu/store hat einen Hash all seiner bei der Erstellung benutzten Eingaben im Namen – Compiler, Bibliotheken, Erstellungs-Skripts etc. Diese direkte Entsprechung ermöglicht es Benutzern, eine Paketinstallation zu benutzen, die sicher dem aktuellen Stand ihrer Distribution entspricht. Sie hilft auch dabei, die Reproduzierbarkeit der Erstellungen zu maximieren: Dank den isolierten Erstellungsumgebungen, die benutzt werden, resultiert eine Erstellung wahrscheinlich in bitweise identischen Dateien, auch wenn sie auf unterschiedlichen Maschinen durchgeführt wird (siehe Container).

Auf dieser Grundlage kann Guix transparent Binär- oder Quelldateien ausliefern. Wenn eine vorerstellte Binärdatei für ein /gnu/store-Objekt von einer externen Quelle verfügbar ist – ein Substitut –, lädt Guix sie einfach herunter und entpackt sie, andernfalls erstellt Guix das Paket lokal aus seinem Quellcode (siehe Substitute). Weil Erstellungsergebnisse normalerweise Bit für Bit reproduzierbar sind, müssen die Nutzer den Servern, die Substitute anbieten, nicht blind vertrauen; sie können eine lokale Erstellung erzwingen und Substitute anfechten (siehe guix challenge aufrufen).

Kontrolle über die Erstellungsumgebung ist eine auch für Entwickler nützliche Funktionalität. Der Befehl guix shell ermöglicht es Entwicklern eines Pakets, schnell die richtige Entwicklungsumgebung für ihr Paket einzurichten, ohne manuell die Abhängigkeiten des Pakets in ihr Profil installieren zu müssen (siehe guix shell aufrufen).

Ganz Guix und all seine Paketdefinitionen stehen unter Versionskontrolle und guix pull macht es möglich, auf dem Verlauf der Entwicklung von Guix selbst „in der Zeit zu reisen“ (siehe guix pull aufrufen). Dadurch kann eine Instanz von Guix auf einer anderen Maschine oder zu einem späteren Zeitpunkt genau nachgebildet werden, wodurch auch vollständige Software-Umgebungen gänzlich nachgebildet werden können, mit genauer Provenienzverfolgung, wo diese Software herkommt.

5.2 guix package aufrufen

Der Befehl guix package ist ein Werkzeug, womit Nutzer Pakete installieren, aktualisieren, entfernen und auf vorherige Konfigurationen zurücksetzen können. Diese Operationen arbeiten auf einem Benutzerprofil, d.h. einem Verzeichnis, das installierte Pakete enthält. Jeder Benutzer verfügt über ein Standardprofil in $HOME/.guix-profile. Dabei wird nur das eigene Profil des Nutzers verwendet, und es funktioniert mit normalen Benutzerrechten, ohne Administratorrechte (siehe Funktionalitäten). Die Syntax ist:

guix package Optionen

In erster Linie geben die Optionen an, welche Operationen in der Transaktion durchgeführt werden sollen. Nach Abschluss wird ein neues Profil erzeugt, aber vorherige Generationen des Profils bleiben verfügbar, falls der Benutzer auf sie zurückwechseln will.

Um zum Beispiel lua zu entfernen und guile und guile-cairo in einer einzigen Transaktion zu installieren:

guix package -r lua -i guile guile-cairo

Um es Ihnen einfacher zu machen, bieten wir auch die folgenden Alias-Namen an:

• guix search ist eine andere Schreibweise für guix package -s,
• guix install ist eine andere Schreibweise für guix package -i,
• guix remove ist eine andere Schreibweise für guix package -r,
• guix upgrade ist eine andere Schreibweise für guix package -u
• und guix show ist eine andere Schreibweise für guix package --show=.

Diese Alias-Namen sind weniger ausdrucksstark als guix package und stellen weniger Befehlszeilenoptionen bereit, deswegen werden Sie vermutlich manchmal guix package direkt benutzen wollen.

guix package unterstützt auch ein deklaratives Vorgehen, wobei der Nutzer die genaue Menge an Paketen, die verfügbar sein sollen, festlegt und über die Befehlszeilenoption --manifest übergibt (siehe --manifest).

Für jeden Benutzer wird automatisch eine symbolische Verknüpfung zu seinem Standardprofil angelegt als $HOME/.guix-profile. Diese symbolische Verknüpfung zeigt immer auf die aktuelle Generation des Standardprofils des Benutzers. Somit können Nutzer $HOME/.guix-profile/bin z.B. zu ihrer Umgebungsvariablen PATH hinzufügen. Wenn Sie nicht Guix System benutzen, sollten Sie in Betracht ziehen, folgende Zeilen zu Ihrem ~/.bash_profile hinzuzufügen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash), damit in neu erzeugten Shells alle Umgebungsvariablen richtig definiert werden:

GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$GUIX_PROFILE/etc/profile"

Ist Ihr System für mehrere Nutzer eingerichtet, werden Nutzerprofile an einem Ort gespeichert, der als Müllsammlerwurzel registriert ist, auf die $HOME/.guix-profile zeigt (siehe guix gc aufrufen). Dieses Verzeichnis ist normalerweise localstatedir/guix/profiles/per-user/Benutzer, wobei localstatedir der an configure als --localstatedir übergebene Wert ist und Benutzer für den jeweiligen Benutzernamen steht. Das per-user-Verzeichnis wird erstellt, wenn guix-daemon gestartet wird, und das Unterverzeichnis Benutzer wird durch guix package erstellt.

Als Optionen kann vorkommen:

--install=Paket …

-i Paket …

Die angegebenen Pakete installieren.

Jedes Paket kann einfach durch seinen Paketnamen aufgeführt werden, wie guile, optional gefolgt von einem At-Zeichen @ und einer Versionsnummer, wie guile@3.0.7 oder auch nur guile@3.0. In letzterem Fall wird die neueste Version mit Präfix 3.0 ausgewählt.

Wird keine Versionsnummer angegeben, wird die neueste verfügbare Version ausgewählt. Zudem kann in der Spezifikation von Paket ein Doppelpunkt auftauchen, gefolgt vom Namen einer der Ausgaben des Pakets, wie gcc:doc oder binutils@2.22:lib (siehe Pakete mit mehreren Ausgaben.).

Pakete mit zugehörigem Namen (und optional der Version) werden unter den Modulen der GNU-Distribution gesucht (siehe Paketmodule).

Alternativ können Sie für Paket auch einen Dateinamen aus dem Store direkt angeben, etwa /gnu/store/…-guile-3.0.7. Den Dateinamen erfahren Sie zum Beispiel mit guix build.

Manchmal haben Pakete propagierte Eingaben: Als solche werden Abhängigkeiten bezeichnet, die automatisch zusammen mit dem angeforderten Paket installiert werden (im Abschnitt propagated-inputs in package-Objekten sind weitere Informationen über propagierte Eingaben in Paketdefinitionen zu finden).

Ein Beispiel ist die GNU-MPC-Bibliothek: Ihre C-Headerdateien verweisen auf die der GNU-MPFR-Bibliothek, welche wiederum auf die der GMP-Bibliothek verweisen. Wenn also MPC installiert wird, werden auch die MPFR- und GMP-Bibliotheken in das Profil installiert; entfernt man MPC, werden auch MPFR und GMP entfernt – außer sie wurden noch auf andere Art ausdrücklich vom Nutzer installiert.

Abgesehen davon setzen Pakete manchmal die Definition von Umgebungsvariablen für ihre Suchpfade voraus (siehe die Erklärung von --search-paths weiter unten). Alle fehlenden oder womöglich falschen Definitionen von Umgebungsvariablen werden hierbei gemeldet.

--install-from-expression=Ausdruck

-e Ausdruck

Das Paket installieren, zu dem der Ausdruck ausgewertet wird.

Beim Ausdruck muss es sich um einen Scheme-Ausdruck handeln, der zu einem <package>-Objekt ausgewertet wird. Diese Option ist besonders nützlich, um zwischen gleichnamigen Varianten eines Pakets zu unterscheiden, durch Ausdrücke wie (@ (gnu packages commencement) guile-final).

Beachten Sie, dass mit dieser Option die erste Ausgabe des angegebenen Pakets installiert wird, was unzureichend sein kann, wenn eine bestimmte Ausgabe eines Pakets mit mehreren Ausgaben gewünscht ist.

--install-from-file=Datei

-f Datei

Das Paket installieren, zu dem der Code in der Datei ausgewertet wird.

Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Entwickler könnten es für nützlich erachten, eine solche guix.scm-Datei im Quellbaum ihres Projekts abzulegen, mit der Zwischenstände der Entwicklung getestet und reproduzierbare Erstellungsumgebungen aufgebaut werden können (siehe guix shell aufrufen).

Es ist auch möglich, eine Datei mit einer JSON-Repräsentation von einer oder mehr Paketdefinitionen anzugeben. Wenn Sie guix package -f auf hello.json mit folgendem Inhalt ausführen würden, würde das Paket greeter installiert, nachdem myhello erstellt wurde:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    },
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]

--remove=Paket …

-r Paket …

Die angegebenen Pakete entfernen.

Wie auch bei --install kann jedes Paket neben dem Paketnamen auch eine Versionsnummer und/oder eine Ausgabe benennen. Zum Beispiel würde ‘-r glibc:debug’ die debug-Ausgabe von glibc aus dem Profil entfernen.

--upgrade[=Regexp …] ¶

-u [Regexp …]

Alle installierten Pakete aktualisieren. Wenn einer oder mehr reguläre Ausdrücke (Regexps) angegeben wurden, werden nur diejenigen installierten Pakete aktualisiert, deren Name zu einer der Regexps passt. Siehe auch weiter unten die Befehlszeilenoption --do-not-upgrade.

Beachten Sie, dass das Paket so auf die neueste Version unter den Paketen gebracht wird, die in der aktuell installierten Distribution vorliegen. Um jedoch Ihre Distribution zu aktualisieren, sollten Sie regelmäßig guix pull ausführen (siehe guix pull aufrufen).

Wenn Sie Ihre Pakete aktualisieren, werden die bei der Erstellung des vorherigen Profils angewandten Paketumwandlungen automatisch erneut angwandt (siehe Paketumwandlungsoptionen). Nehmen wir zum Beispiel an, Sie haben zuerst Emacs von der Spitze seines Entwicklungs-Branches installiert:

guix install emacs-next --with-branch=emacs-next=master

Wenn Sie das nächste Mal guix upgrade ausführen, lädt Guix von neuem die Spitze des Emacs-Entwicklungsbranches, um aus diesem Checkout emacs-next zu erstellen.

Beachten Sie, dass Umwandlungsoptionen wie --with-branch und --with-source von externem Zustand abhängen. Es liegt an Ihnen, sicherzustellen, dass sie wie erwartet funktionieren. Sie können auf Pakete angewandte Umwandlungen auch weglassen, indem Sie das ausführen:

guix install Paket

--do-not-upgrade[=Regexp …]

In Verbindung mit der Befehlszeilenoption --upgrade, führe keine Aktualisierung von Paketen durch, deren Name zum regulären Ausdruck Regexp passt. Um zum Beispiel alle Pakete im aktuellen Profil zu aktualisieren mit Ausnahme derer, die „emacs“ im Namen haben:

$ guix package --upgrade . --do-not-upgrade emacs

--manifest=Datei ¶

-m Datei

Erstellt eine neue Generation des Profils aus dem vom Scheme-Code in Datei gelieferten Manifest-Objekt. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.

Dadurch könnrn Sie den Inhalt des Profils deklarieren, statt ihn durch eine Folge von Befehlen wie --install u.Ä. zu generieren. Der Vorteil ist, dass die Datei unter Versionskontrolle gestellt werden kann, auf andere Maschinen zum Reproduzieren desselben Profils kopiert werden kann und Ähnliches.

Der Code in der Datei muss ein Manifest-Objekt liefern, was ungefähr einer Liste von Paketen entspricht:

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Eine bestimmte Paketausgabe nutzen.
       (list guile-2.0 "debug")))

Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest schreibt. Siehe --export-manifest, um zu erfahren, wie Sie aus einem bestehenden Profil eine Manifestdatei erzeugen können.

--roll-back ¶

Wechselt zur vorherigen Generation des Profils zurück – d.h. macht die letzte Transaktion rückgängig.

In Verbindung mit Befehlszeilenoptionen wie --install wird zuerst zurückgesetzt, bevor andere Aktionen durchgeführt werden.

Ein Rücksetzen der ersten Generation, die installierte Pakete enthält, wechselt das Profil zur nullten Generation, die keinerlei Dateien enthält, abgesehen von Metadaten über sich selbst.

Nach dem Zurücksetzen überschreibt das Installieren, Entfernen oder Aktualisieren von Paketen vormals zukünftige Generationen, d.h. der Verlauf der Generationen eines Profils ist immer linear.

--switch-generation=Muster ¶

-S Muster

Wechselt zu der bestimmten Generation, die durch das Muster bezeichnet wird.

Als Muster kann entweder die Nummer einer Generation oder eine Nummer mit vorangestelltem „+“ oder „-“ dienen. Letzteres springt die angegebene Anzahl an Generationen vor oder zurück. Zum Beispiel kehrt --switch-generation=+1 nach einem Zurücksetzen wieder zur neueren Generation zurück.

Der Unterschied zwischen --roll-back und --switch-generation=-1 ist, dass --switch-generation keine nullte Generation erzeugen wird; existiert die angegebene Generation nicht, bleibt schlicht die aktuelle Generation erhalten.

--search-paths[=Art] ¶

Führe die Definitionen von Umgebungsvariablen auf, in Bash-Syntax, die nötig sein könnten, um alle installierten Pakete nutzen zu können. Diese Umgebungsvariablen werden benutzt, um die Suchpfade für Dateien festzulegen, die von einigen installierten Paketen benutzt werden.

Zum Beispiel braucht GCC die Umgebungsvariablen CPATH und LIBRARY_PATH, um zu wissen, wo sich im Benutzerprofil Header und Bibliotheken befinden (siehe Environment Variables in Using the GNU Compiler Collection (GCC)). Wenn GCC und, sagen wir, die C-Bibliothek im Profil installiert sind, schlägt --search-paths also vor, diese Variablen jeweils auf profile/include und profile/lib verweisen zu lassen (siehe Suchpfade für Informationen, wie Paketen Suchpfadspezifikationen zugeordnet werden).

Die typische Nutzung ist, in der Shell diese Variablen zu definieren:

$ eval $(guix package --search-paths)

Als Art kann entweder exact, prefix oder suffix gewählt werden, wodurch die gelieferten Definitionen der Umgebungsvariablen entweder exakt die Einstellungen für Guix meldet, oder sie als Präfix oder Suffix an den aktuellen Wert dieser Variablen anhängt. Gibt man keine Art an, wird der Vorgabewert exact verwendet.

Diese Befehlszeilenoption kann auch benutzt werden, um die kombinierten Suchpfade mehrerer Profile zu berechnen. Betrachten Sie dieses Beispiel:

$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths

Der letzte Befehl oben meldet auch die Definition der Umgebungsvariablen GUILE_LOAD_PATH, obwohl für sich genommen weder foo noch bar zu dieser Empfehlung führen würden.

--profile=Profil

-p Profil

Auf Profil anstelle des Standardprofils des Benutzers arbeiten.

Als Profil muss der Name einer Datei angegeben werden, die dann nach Abschluss der Transaktion erzeugt wird. Konkret wird Profil nur zu einer symbolischen Verknüpfung („Symlink“) auf das eigentliche Profil gemacht, in das Pakete installiert werden.

$ guix install hello -p ~/code/mein-profil
…
$ ~/code/mein-profil/bin/hello
Hallo, Welt!

Um das Profil loszuwerden, genügt es, die symbolische Verknüpfung und damit einhergehende Verknüpfungen, die auf bestimmte Generationen verweisen, zu entfernen:

$ rm ~/code/mein-profil ~/code/mein-profil-*-link

--list-profiles

Alle Profile des Benutzers auflisten:

$ guix package --list-profiles
/home/charlie/.guix-profile
/home/charlie/code/my-profile
/home/charlie/code/devel-profile
/home/charlie/tmp/test

Wird es als Administratornutzer „root“ ausgeführt, werden die Profile aller Benutzer aufgelistet.

--allow-collisions

Kollidierende Pakete im neuen Profil zulassen. Benutzung auf eigene Gefahr!

Standardmäßig wird guix package Kollisionen als Fehler auffassen und melden. Zu Kollisionen kommt es, wenn zwei oder mehr verschiedene Versionen oder Varianten desselben Pakets im Profil landen.

--bootstrap

Erstellt das Profil mit dem Bootstrap-Guile. Diese Option ist nur für Entwickler der Distribution nützlich.

Zusätzlich zu diesen Aktionen unterstützt guix package folgende Befehlszeilenoptionen, um den momentanen Zustand eines Profils oder die Verfügbarkeit von Paketen nachzulesen:

--search=Regexp

-s Regexp

Führt alle verfügbaren Pakete auf, deren Name, Zusammenfassung oder Beschreibung zum regulären Ausdruck Regexp passt, ohne Groß- und Kleinschreibung zu unterscheiden und sortiert nach ihrer Relevanz. Alle Metadaten passender Pakete werden im recutils-Format geliefert (siehe GNU-recutils-Datenbanken in GNU recutils manual).

So können bestimmte Felder mit dem Befehl recsel extrahiert werden, zum Beispiel:

$ guix package -s malloc | recsel -p name,version,relevance
name: jemalloc
version: 4.5.0
relevance: 6

name: glibc
version: 2.25
relevance: 1

name: libgc
version: 7.6.0
relevance: 1

Ebenso kann der Name aller zu den Bedingungen der GNU LGPL, Version 3, verfügbaren Pakete ermittelt werden:

$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils

name: gmp
…

Es ist auch möglich, Suchergebnisse näher einzuschränken, indem Sie -s mehrmals an guix package übergeben, oder mehrere Argumente an guix search übergeben. Zum Beispiel liefert folgender Befehl eines Liste von Brettspielen:

$ guix search '\<board\>' game | recsel -p name
name: gnubg
…

Würden wir -s game weglassen, bekämen wir auch Software-Pakete aufgelistet, die mit „printed circuit boards“ (elektronischen Leiterplatten) zu tun haben; ohne die spitzen Klammern um board bekämen wir auch Pakete, die mit „keyboards“ (Tastaturen, oder musikalischen Keyboard) zu tun haben.

Es ist Zeit für ein komplexeres Beispiel. Folgender Befehl sucht kryptografische Bibliotheken, filtert Haskell-, Perl-, Python- und Ruby-Bibliotheken heraus und gibt Namen und Zusammenfassung passender Pakete aus:

$ guix search crypto library | \
    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

Siehe Selection Expressions in GNU recutils manual, es enthält weitere Informationen über Auswahlausdrücke mit recsel -e.

--show=Paket

Zeigt Details über das Paket aus der Liste verfügbarer Pakete, im recutils-Format (siehe GNU-recutils-Datenbanken in GNU recutils manual).

$ guix package --show=guile | recsel -p name,version
name: guile
version: 3.0.5

name: guile
version: 3.0.2

name: guile
version: 2.2.7
…

Sie können auch den vollständigen Namen eines Pakets angeben, um Details nur über diese Version angezeigt zu bekommen (diesmal benutzen wir die andere Schreibweise guix show):

$ guix show guile@3.0.5 | recsel -p name,version
name: guile
version: 3.0.5

--list-installed[=Regexp]

-I [Regexp]

Listet die derzeit installierten Pakete im angegebenen Profil auf, die zuletzt installierten Pakete zuletzt. Wenn ein regulärer Ausdruck Regexp angegeben wird, werden nur installierte Pakete aufgeführt, deren Name zu Regexp passt.

Zu jedem installierten Paket werden folgende Informationen angezeigt, durch Tabulatorzeichen getrennt: der Paketname, die Version als Zeichenkette, welche Teile des Pakets installiert sind (zum Beispiel out, wenn die Standard-Paketausgabe installiert ist, include, wenn seine Header installiert sind, usw.) und an welchem Pfad das Paket im Store zu finden ist.

--list-available[=Regexp]

-A [Regexp]

Listet Pakete auf, die in der aktuell installierten Distribution dieses Systems verfügbar sind (siehe GNU-Distribution). Wenn ein regulärer Ausdruck Regexp angegeben wird, werden nur Pakete aufgeführt, deren Name zum regulären Ausdruck Regexp passt.

Zu jedem Paket werden folgende Informationen getrennt durch Tabulatorzeichen ausgegeben: der Name, die Version als Zeichenkette, die Teile des Programms (siehe Pakete mit mehreren Ausgaben.) und die Stelle im Quellcode, an der das Paket definiert ist.

--list-generations[=Muster] ¶

-l [Muster]

Liefert eine Liste der Generationen zusammen mit dem Datum, an dem sie erzeugt wurden; zu jeder Generation werden zudem die installierten Pakete angezeigt, zuletzt installierte Pakete zuletzt. Beachten Sie, dass die nullte Generation niemals angezeigt wird.

Zu jedem installierten Paket werden folgende Informationen durch Tabulatorzeichen getrennt angezeigt: der Name des Pakets, die Version als Zeichenkette, welcher Teil des Pakets installiert ist (siehe Pakete mit mehreren Ausgaben.) und an welcher Stelle sich das Paket im Store befindet.

Wenn ein Muster angegeben wird, liefert der Befehl nur dazu passende Generationen. Gültige Muster sind zum Beispiel:

• Ganze Zahlen und kommagetrennte ganze Zahlen. Beide Muster bezeichnen Generationsnummern. Zum Beispiel liefert --list-generations=1 die erste Generation.

  Durch --list-generations=1,8,2 werden drei Generationen in der angegebenen Reihenfolge angezeigt. Weder Leerzeichen noch ein Komma am Schluss der Liste ist erlaubt.

• Bereiche. --list-generations=2..9 gibt die angegebenen Generationen und alles dazwischen aus. Beachten Sie, dass der Bereichsanfang eine kleinere Zahl als das Bereichsende sein muss.

  Sie können auch kein Bereichsende angeben, zum Beispiel liefert --list-generations=2.. alle Generationen ab der zweiten.

• Zeitdauern. Sie können auch die letzten N Tage, Wochen oder Monate angeben, indem Sie eine ganze Zahl gefolgt von jeweils „d“, „w“ oder „m“ angeben (dem ersten Buchstaben der Maßeinheit der Dauer im Englischen). Zum Beispiel listet --list-generations=20d die Generationen auf, die höchstens 20 Tage alt sind.

--delete-generations[=Muster]

-d [Muster]

Wird kein Muster angegeben, werden alle Generationen außer der aktuellen entfernt.

Dieser Befehl akzeptiert dieselben Muster wie --list-generations. Wenn ein Muster angegeben wird, werden die passenden Generationen gelöscht. Wenn das Muster für eine Zeitdauer steht, werden diejenigen Generationen gelöscht, die älter als die angegebene Dauer sind. Zum Beispiel löscht --delete-generations=1m die Generationen, die mehr als einen Monat alt sind.

Falls die aktuelle Generation zum Muster passt, wird sie nicht gelöscht. Auch die nullte Generation wird niemals gelöscht.

Beachten Sie, dass Sie auf gelöschte Generationen nicht zurückwechseln können. Dieser Befehl sollte also nur mit Vorsicht benutzt werden.

--export-manifest

Auf die Standardausgabe ein Manifest ausgeben, das mit --manifest genutzt werden kann und dem/den gewählten Profil(en) entspricht.

Diese Befehlszeilenoption erleichtert Ihnen den Wechsel vom „imperativen“ Betriebsmodus, wo Sie immer wieder guix install, guix upgrade etc. ausführen, zum deklarativen Modus, der mit --manifest zur Verfügung steht.

Seien Sie sich bewusst, dass das erzeugte Manifest nur eine Annäherung des Inhalts Ihres Profils ist. Je nachdem, wie Ihr Profil erzeugt wurde, kann es auf andere Pakete oder Paketversionen verweisen.

Beachten Sie, dass ein Manifest rein symbolisch ist; es enthält nur die Namen und vielleicht Versionen der Pakete, aber die Bedeutung davon wandelt sich mit der Zeit. Wenn Sie wollen, dass die Pakete aus immer derselben Kanalversion stammen, mit der das Profil oder die Profile erstellt wurden, siehe --export-channels unten.

--export-channels

Auf die Standardausgabe die Liste der Kanäle schreiben, die das gewählte Profil benutzt bzw. die die gewählten Profile benutzen. Das Format der Kanalspezifikation ist für guix pull --channels und guix time-machine --channels geeignet (siehe Kanäle).

Zusammen mit --export-manifest macht diese Befehlszeilenoption Informationen verfügbar, um das aktuelle Profil nachzubilden (siehe Guix nachbilden).

Beachten Sie jedoch, dass die Ausgabe dieses Befehls nur eine Annäherung dessen ist, woraus ein Profil tatsächlich erstellt wurde. Insbesondere kann ein Profil aus mehreren Versionen desselben Kanals aufgebaut worden sein. In diesem Fall wählt --export-manifest die neueste aus und schreibt die anderen Versionen in einem Kommentar dazu. Wenn Sie wirklich Pakete aus unterschiedlichen Kanalversionen zu nehmen brauchen, können Sie dazu in Ihrem Manifest Untergeordnete angeben (siehe Untergeordnete).

Dies stellt zusammen mit --export-manifest eine gute Gelegenheit dar, wenn Sie bereit sind, vom „imperativen“ Modell auf das vollständig deklarative Modell zu wechseln, wo Sie eine Manifestdatei zusammen mit einer Kanaldatei benutzen, die ganz genau festlegt, welche Kanalversion(en) Sie wollen.

Zu guter Letzt können Sie, da guix package Erstellungsprozesse zu starten vermag, auch alle gemeinsamen Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen) verwenden. Auch Paketumwandlungsoptionen wie --with-source sind möglich und bleiben über Aktualisierungen hinweg erhalten (siehe Paketumwandlungsoptionen).

5.3 Substitute

Guix kann transparent Binär- oder Quelldateien ausliefern. Das heißt, Dinge können sowohl lokal erstellt als auch als vorerstellte Objekte von einem Server heruntergeladen werden, oder beides gemischt. Wir bezeichnen diese vorerstellten Objekte als Substitute – sie substituieren lokale Erstellungsergebnisse. In vielen Fällen geht das Herunterladen eines Substituts wesentlich schneller, als Dinge lokal zu erstellen.

Substitute können alles sein, was das Ergebnis einer Ableitungserstellung ist (siehe Ableitungen). Natürlich sind sie üblicherweise vorerstellte Paket-Binärdateien, aber wenn zum Beispiel ein Quell-Tarball das Ergebnis einer Ableitungserstellung ist, kann auch er als Substitut verfügbar sein.

• Offizielle Substitut-Server
• Substitut-Server autorisieren
• Substitute von anderen Servern holen
• Substitutauthentifizierung
• Proxy-Einstellungen
• Fehler bei der Substitution
• Vom Vertrauen gegenüber Binärdateien

# guix archive --authorize < prefix/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub

$ guix build emacs --dry-run
Folgende Ableitungen würden erstellt:
   /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
   /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
   /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
   /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
…

$ guix build emacs --dry-run
112.3 MB würden heruntergeladen:
   /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
   /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
   /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
   /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
…

(operating-system
  ;; …
  (services
    ;; Wir nehmen hier '%desktop-services' als Grundlage; geben Sie
    ;; an deren Stelle die Liste der bei Ihnen benutzten Dienste an.
    (modify-services %desktop-services
      (guix-service-type config =>
                        (guix-configuration
                          (inherit config)
                          (substitute-urls
                            (append (list "https://guix.example.org")
                                    %default-substitute-urls))
                          (authorized-keys
                            (append (list (local-file "./key.pub"))
                                    %default-authorized-guix-keys)))))))

$ sudo guix system reconfigure /etc/config.scm
$ sudo herd restart guix-daemon

--substitute-urls="https://a.example.org https://b.example.org"

5.4 Pakete mit mehreren Ausgaben.

Oft haben in Guix definierte Pakete eine einzige Ausgabe – d.h. aus dem Quellpaket entsteht genau ein Verzeichnis im Store. Wenn Sie guix install glibc ausführen, wird die Standard-Paketausgabe des GNU-libc-Pakets installiert; die Standardausgabe wird out genannt, aber ihr Name kann weggelassen werden, wie Sie am obigen Befehl sehen. In diesem speziellen Fall enthält die Standard-Paketausgabe von glibc alle C-Headerdateien, gemeinsamen Bibliotheken („Shared Libraries“), statischen Bibliotheken („Static Libraries“), Dokumentation für Info sowie andere zusätzliche Dateien.

Manchmal ist es besser, die verschiedenen Arten von Dateien, die aus einem einzelnen Quellpaket hervorgehen, in getrennte Ausgaben zu unterteilen. Zum Beispiel installiert die GLib-C-Bibliothek (die von GTK und damit zusammenhängenden Paketen benutzt wird) mehr als 20 MiB an HTML-Seiten mit Referenzdokumentation. Um den Nutzern, die das nicht brauchen, Platz zu sparen, wird die Dokumentation in einer separaten Ausgabe abgelegt, genannt doc. Um also die Hauptausgabe von GLib zu installieren, zu der alles außer der Dokumentation gehört, ist der Befehl:

guix install glib

Der Befehl, um die Dokumentation zu installieren, ist:

guix install glib:doc

Jedoch ist die Schreibweise mit Doppelpunkt nur richtig bei der Spezifikation von Paketausgaben auf der Befehlszeile. Sie ist falsch, wenn Sie eine Paket-Variable in Scheme-Code angeben. Um zum Beispiel die Dokumentation von glib zu den global installierten Paketen eines operating-system-Objekts hinzuzufügen (siehe operating-system-Referenz), muss stattdessen eine Liste von zwei Einträgen verwendet werden, als Erstes die Paket-Variable und als Zweites der Name der gewählten Ausgabe:

(use-modules (gnu packages glib))
;; glib-with-documentation ist das Guile-Symbol für das glib-Paket
(operating-system
 …
 (packages
  (append
   (list (list glib-with-documentation "doc"))
         %base-packages)))

Manche Pakete installieren Programme mit unterschiedlich großem „Abhängigkeiten-Fußabdruck“. Zum Beispiel installiert das Paket WordNet sowohl Befehlszeilenwerkzeuge als auch grafische Benutzerschnittstellen (GUIs). Erstere hängen nur von der C-Bibliothek ab, während Letztere auch von Tcl/Tk und den zu Grunde liegenden X-Bibliotheken abhängen. Jedenfalls belassen wir deshalb die Befehlszeilenwerkzeuge in der Standard-Paketausgabe, während sich die GUIs in einer separaten Ausgabe befinden. So können Benutzer, die die GUIs nicht brauchen, Platz sparen. Der Befehl guix size kann dabei helfen, solche Situationen zu erkennen (siehe guix size aufrufen). guix graph kann auch helfen (siehe guix graph aufrufen).

In der GNU-Distribution gibt es viele solche Pakete mit mehreren Ausgaben. Andere Konventionen für Ausgabenamen sind zum Beispiel lib für Bibliotheken und eventuell auch ihre Header-Dateien, bin für eigenständige Programme und debug für Informationen zur Fehlerbehandlung (siehe Dateien zur Fehlersuche installieren). Die Ausgaben eines Pakets stehen in der dritten Spalte der Anzeige von guix package --list-available (siehe guix package aufrufen).

5.5 guix locate aufrufen

Uns steht solch eine Fülle an freier Software zur Verfügung, dass wir früher oder später suchen müssen, welches Paket wir benötigen. Mit dem Befehl guix search, den wir bereits kennengelernt haben (siehe guix package aufrufen), können wir anhand von Schlüsselwörtern suchen:

guix search video editor

Manchmal möchte man eher wissen, in welchem Paket eine bestimmte Datei angeboten wird. Hierfür ist guix locate das Richtige. So können Sie z.B. herausfinden, welches Paket den Befehl ls verfügbar macht:

$ guix locate ls
coreutils@9.1       /gnu/store/…-coreutils-9.1/bin/ls

Natürlich funktioniert es auch mit anderen Dateien, nicht nur für Befehle:

$ guix locate unistr.h
icu4c@71.1          /gnu/store/…/include/unicode/unistr.h
libunistring@1.0    /gnu/store/…/include/unistr.h

Sie können auch glob-Muster mit Platzhaltern verwenden. Zum Beispiel würden Sie so nach Paketen suchen, die .service-Dateien verfügbar machen:

$ guix locate -g '*.service'
man-db@2.11.1        …/lib/systemd/system/man-db.service
wpa-supplicant@2.10  …/system-services/fi.w1.wpa_supplicant1.service

Der Befehl guix locate braucht eine Datenbank, die Dateinamen zu Paketnamen zuordnet. Nach den Vorgabeeinstellungen wird diese Datenbank automatisch angelegt, wenn sie noch nicht existiert, wozu die lokal verfügbaren Pakete betrachtet werden, was ein paar Minuten dauern kann (je nachdem wie groß Ihr Store und wie schnell Ihr Speichermedium ist).

Anmerkung: Im Moment kann guix locate seine Datenbank nur auf lokalem Wissen aufbauen – Pakete außerhalb Ihres Stores werden nicht aufgenommen. Das soll sich noch ändern und dann wird es eine vorerstellte Datenbank herunterladen können, mit der sie auch andere Pakete finden können.

Vorgegeben ist, dass guix locate zunächst schaut, ob eine systemweite Datenbank vorhanden ist, in der Regel in /var/cache/guix/locate. Wenn Sie nicht existiert oder zu alt ist, wird stattdessen auf eine nutzereigene Datenbank zurückgegriffen, vorgegeben ist ~/.cache/guix/locate. In einem Mehrbenutzersystem können Administratoren die Aufgabe übernehmen, regelmäßig die systemweite Datenbank zu aktualisieren, damit alle Benutzer etwas davon haben, zum Beispiel mit Hilfe des package-database-service-type (siehe package-database-service-type).

Die allgemeine Syntax lautet:

guix locate [Optionen…] Datei…

Dabei ist Datei der Name einer aufzufindenden Datei (genauer gesagt ihr „Basisname“: Dateien, die ein Elternverzeichnis namens Datei haben, landen nicht im Ergebnis).

Folgende Optionen gibt es:

--glob

-g

Datei… werden als glob-Muster aufgefasst – also Muster, die auch Platzhalterzeichen enthalten können wie ‘*.scm’, was alle Dateien aufgreift, die in ‘.scm’ enden.

--stats

Statistiken über die Datenbank zeigen.

--update

-u

Die Datenbank mit den Dateien auf den neuesten Stand bringen.

Nach den Vorgabeeinstellungen wird die Datenbank dann aktualisiert, wenn sie zu alt ist.

--clear

Die Datenbank leeren und neu befüllen.

Mit dieser Befehlszeilenoption können sie von vorn anfangen, so dass alte Daten nicht mehr in der Datenbank auftauchen. So stellen Sie sicher, dass die Datenbank nicht endlos anwächst. Nach den Vorgabeeinstellungen für guix locate geschieht das regelmäßig automatisch, wenn auch nicht oft.

--database=Datei

Die Datei als Datenbank benutzen. Wenn nötig, wird sie erzeugt.

Nach den Vorgabeeinstellungen benutzt guix locate die Datenbank unter ~/.cache/guix oder /var/cache/guix, je nachdem, welche neuer ist.

--method=Methode

-m Methode

Nach der Methode auswählen, welche Pakete in den Index aufgenommn werden. Mögliche Werte sind:

manifests

Dies ist die vorgegebene Methode: Für sie werden die Profile auf der Maschine betrachtet und die darin vorkommenden Pakete ermittelt – das sind die Pakete, die Sie oder andere Benutzer derselben Maschine direkt oder indirekt installiert haben. Das geht schnell, aber Pakete, die aus anderem Grund im Store sind, fehlen, wenn kein Profil darauf verweist.

store

Diese Methode ist langsamer, aber gründlicher: Alle Pakete, die im Store vorhanden sind, werden in die Datenbank aufgenommen.

5.6 guix gc aufrufen

Pakete, die zwar installiert sind, aber nicht benutzt werden, können vom Müllsammler entfernt werden. Mit dem Befehl guix gc können Benutzer den Müllsammler ausdrücklich aufrufen, um Speicher im Verzeichnis /gnu/store freizugeben. Dies ist der einzige Weg, Dateien aus /gnu/store zu entfernen – das manuelle Entfernen von Dateien kann den Store irreparabel beschädigen!

Der Müllsammler kennt eine Reihe von Wurzeln: Jede Datei in /gnu/store, die von einer Wurzel aus erreichbar ist, gilt als lebendig und kann nicht entfernt werden; jede andere Datei gilt als tot und ist ein Kandidat, gelöscht zu werden. Die Menge der Müllsammlerwurzeln (kurz auch „GC-Wurzeln“, von englisch „Garbage Collector“) umfasst Standard-Benutzerprofile; standardmäßig werden diese Müllsammlerwurzeln durch symbolische Verknüpfungen in /var/guix/gcroots dargestellt. Neue Müllsammlerwurzeln können zum Beispiel mit guix build --root festgelegt werden (siehe Aufruf von guix build). Der Befehl guix gc --list-roots listet sie auf.

Bevor Sie mit guix gc --collect-garbage Speicher freimachen, wollen Sie vielleicht alte Generationen von Benutzerprofilen löschen, damit alte Paketerstellungen von diesen Generationen entfernt werden können. Führen Sie dazu guix package --delete-generations aus (siehe guix package aufrufen).

Unsere Empfehlung ist, dass Sie den Müllsammler regelmäßig laufen lassen und wenn Sie wenig freien Speicherplatz zur Verfügung haben. Um zum Beispiel sicherzustellen, dass Sie mindestens 5 GB auf Ihrer Platte zur Verfügung haben, benutzen Sie einfach:

guix gc -F 5G

Es ist völlig sicher, dafür eine nicht interaktive, regelmäßige Auftragsausführung vorzugeben (siehe Geplante Auftragsausführung für eine Erklärung, wie man das tun kann). guix gc ohne Befehlszeilenargumente auszuführen, lässt so viel Müll wie möglich sammeln, aber das ist oft nicht, was man will, denn so muss man unter Umständen Software erneut erstellen oder erneut herunterladen, weil der Müllsammler sie als „tot“ ansieht, sie aber zur Erstellung anderer Software wieder gebraucht wird – das trifft zum Beispiel auf die Compiler-Toolchain zu.

Der Befehl guix gc hat drei Arbeitsmodi: Er kann benutzt werden, um als Müllsammler tote Dateien zu entfernen (das Standardverhalten), um ganz bestimmte, angegebene Datein zu löschen (mit der Befehlszeilenoption --delete), um Müllsammlerinformationen auszugeben oder fortgeschrittenere Anfragen zu verarbeiten. Die Müllsammler-Befehlszeilenoptionen sind wie folgt:

--collect-garbage[=Minimum]

-C [Minimum]

Lässt Müll sammeln – z.B. nicht erreichbare Dateien in /gnu/store und seinen Unterverzeichnissen. Wird keine andere Befehlszeilenoption angegeben, wird standardmäßig diese durchgeführt.

Wenn ein Minimum angegeben wurde, hört der Müllsammler auf, sobald Minimum Bytes gesammelt wurden. Das Minimum kann die Anzahl der Bytes bezeichnen oder mit einer Einheit als Suffix versehen sein, wie etwa MiB für Mebibytes und GB für Gigabytes (siehe Größenangaben in GNU Coreutils).

Wird kein Minimum angegeben, sammelt der Müllsammler allen Müll.

--free-space=Menge

-F Menge

Sammelt Müll, bis die angegebene Menge an freiem Speicher in /gnu/store zur Verfügung steht, falls möglich; die Menge ist eine Speichergröße wie 500MiB, wie oben beschrieben.

Wenn die angegebene Menge oder mehr bereits in /gnu/store frei verfügbar ist, passiert nichts.

--delete-generations[=Dauer]

-d [Dauer]

Bevor der Müllsammelvorgang beginnt, werden hiermit alle Generationen von allen Benutzerprofilen und von allen Persönlichen Umgebungen gelöscht, die älter sind als die angegebene Dauer; wird es als Administratornutzer „root“ ausgeführt, geschieht dies mit den Profilen von allen Benutzern.

Zum Beispiel löscht der folgende Befehl alle Generationen Ihrer Profile, die älter als zwei Monate sind (ausgenommen die momentanen Generationen), und schmeißt dann den Müllsammler an, um Platz freizuräumen, bis mindestens 10 GiB verfügbar sind:

guix gc -d 2m -F 10G

--delete

-D

Versucht, alle als Argumente angegebenen Dateien oder Verzeichnisse im Store zu löschen. Dies schlägt fehl, wenn manche der Dateien oder Verzeichnisse nicht im Store oder noch immer lebendig sind.

--list-failures

Store-Objekte auflisten, die zwischengespeicherten Erstellungsfehlern entsprechen.

Hierbei wird nichts ausgegeben, sofern der Daemon nicht mit --cache-failures gestartet wurde (siehe --cache-failures).

--list-roots

Die Müllsammlerwurzeln auflisten, die dem Nutzer gehören. Wird der Befehl als Administratornutzer ausgeführt, werden alle Müllsammlerwurzeln aufgelistet.

--list-busy

Solche Store-Objekte auflisten, die von aktuell laufenden Prozessen benutzt werden. Diese Store-Objekte werden praktisch wie Müllsammlerwurzeln behandelt; sie können nicht gelöscht werden.

--clear-failures

Die angegebenen Store-Objekte aus dem Zwischenspeicher für fehlgeschlagene Erstellungen entfernen.

Auch diese Option macht nur Sinn, wenn der Daemon mit --cache-failures gestartet wurde. Andernfalls passiert nichts.

--list-dead

Zeigt die Liste toter Dateien und Verzeichnisse an, die sich noch im Store befinden – das heißt, Dateien, die von keiner Wurzel mehr erreichbar sind.

--list-live

Zeige die Liste lebendiger Store-Dateien und -Verzeichnisse.

Außerdem können Referenzen unter bestehenden Store-Dateien gefunden werden:

--references ¶

--referrers

Listet die referenzierten bzw. sie referenzierenden Objekte der angegebenen Store-Dateien auf.

--requisites ¶

-R

Listet alle Voraussetzungen der als Argumente übergebenen Store-Dateien auf. Voraussetzungen sind die Store-Dateien selbst, ihre Referenzen sowie die Referenzen davon, rekursiv. Mit anderen Worten, die zurückgelieferte Liste ist der transitive Abschluss dieser Store-Dateien.

Der Abschnitt guix size aufrufen erklärt ein Werkzeug, um den Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe guix graph aufrufen für ein Werkzeug, um den Referenzgraphen zu veranschaulichen.

--derivers ¶

Liefert die Ableitung(en), die zu den angegebenen Store-Objekten führen (siehe Ableitungen).

Zum Beispiel liefert dieser Befehl:

guix gc --derivers $(guix package -I ^emacs$ | cut -f4)

die .drv-Datei(en), die zum in Ihrem Profil installierten emacs-Paket führen.

Beachten Sie, dass es auch sein kann, dass keine passenden .drv-Dateien existieren, zum Beispiel wenn diese Dateien bereits dem Müllsammler zum Opfer gefallen sind. Es kann auch passieren, dass es mehr als eine passende .drv gibt, bei Ableitungen mit fester Ausgabe.

Zuletzt können Sie mit folgenden Befehlszeilenoptionen die Integrität des Stores prüfen und den Plattenspeicherverbrauch im Zaum halten.

--verify[=Optionen] ¶

Die Integrität des Stores verifizieren

Standardmäßig wird sichergestellt, dass alle Store-Objekte, die in der Datenbank des Daemons als gültig markiert wurden, auch tatsächlich in /gnu/store existieren.

Wenn angegeben, müssen die Optionen eine kommagetrennte Liste aus mindestens einem der Worte contents und repair sein.

Wenn Sie --verify=contents übergeben, berechnet der Daemon den Hash des Inhalts jedes Store-Objekts und vergleicht ihn mit dem Hash in der Datenbank. Sind die Hashes ungleich, wird eine Datenbeschädigung gemeldet. Weil dabei alle Dateien im Store durchlaufen werden, kann der Befehl viel Zeit brauchen, besonders auf Systemen mit langsamer Platte.

Mit --verify=repair oder --verify=contents,repair versucht der Daemon, beschädigte Store-Objekte zu reparieren, indem er Substitute für selbige herunterlädt (siehe Substitute). Weil die Reparatur nicht atomar und daher womöglich riskant ist, kann nur der Systemadministrator den Befehl benutzen. Eine weniger aufwendige Alternative, wenn Sie wissen, welches Objekt beschädigt ist, ist, guix build --repair zu benutzen (siehe Aufruf von guix build).

--optimize ¶

Den Store durch Nutzung harter Verknüpfungen für identische Dateien optimieren – mit anderen Worten wird der Store dedupliziert.

Der Daemon führt Deduplizierung automatisch nach jeder erfolgreichen Erstellung und jedem Importieren eines Archivs durch, sofern er nicht mit --disable-deduplication (siehe --disable-deduplication) gestartet wurde. Diese Befehlszeilenoption brauchen Sie also in erster Linie dann, wenn der Daemon zuvor mit --disable-deduplication gestartet worden ist.

--vacuum-database ¶

Für Guix wird eine SQLite-Datenbank verwendet, um über die Objekte im Store Buch zu führen (siehe Der Store). Mit der Zeit kann die Datenbank jedoch eine gigantische Größe erreichen und fragmentieren. Deshalb kann es sich lohnen, den freien Speicher aufzuräumen und nur teilweise genutzte Datenbankseiten, die beim Löschen von Paketen bzw. nach dem Müllsammeln entstanden sind, zusammenzulegen. Führen Sie sudo guix gc --vacuum-database aus, und die Datenbank wird gesperrt und eine VACUUM-Operation auf dem Store durchgeführt, welche die Datenbank defragmentiert und leere Seiten wegschafft. Wenn alles fertig ist, wird die Datenbank entsperrt.

5.7 guix pull aufrufen

Nach der Installation oder Aktualisierung wird stets die neueste Version von Paketen verwendet, die in der aktuell installierten Distribution verfügbar ist. Um die Distribution und die Guix-Werkzeuge zu aktualisieren, führen Sie guix pull aus. Der Befehl lädt den neuesten Guix-Quellcode einschließlich Paketbeschreibungen herunter und installiert ihn. Quellcode wird aus einem Git-Repository geladen, standardmäßig dem offiziellen Repository von GNU Guix, was Sie aber auch ändern können. guix pull stellt sicher, dass der heruntergeladene Code authentisch ist, indem es überprüft, dass die Commits durch Guix-Entwickler signiert worden sind.

Genauer gesagt lädt guix pull Code von den Kanälen herunter (siehe Kanäle), die an einer der folgenden Stellen, in dieser Reihenfolge, angegeben wurden:

1. die Befehlszeilenoption --channels,
2. die Datei ~/.config/guix/channels.scm des Benutzers, außer wenn -q übergeben wird,
3. die systemweite /etc/guix/channels.scm-Datei, außer wenn -q übergeben wird (auf Guix System können Sie die Datei als Teil der Betriebssystemkonfiguration deklarieren, siehe das Feld channels von guix-configuration),
4. die eingebauten vorgegebenen Kanäle, wie sie in der Variablen %default-channels festgelegt sind.

Danach wird guix package Pakete und ihre Versionen entsprechend der gerade heruntergeladenen Kopie von Guix benutzen. Nicht nur das, auch alle Guix-Befehle und Scheme-Module werden aus der neuesten Version von Guix kommen. Neue guix-Unterbefehle, die durch die Aktualisierung hinzugekommen sind, werden also auch verfügbar.

Jeder Nutzer kann seine Kopie von Guix mittels guix pull aktualisieren, wodurch sich nur für den Nutzer etwas verändert, der guix pull ausgeführt hat. Wenn also zum Beispiel der Administratornutzer root den Befehl guix pull ausführt, hat das keine Auswirkungen auf die für den Benutzer alice sichtbare Guix-Version, und umgekehrt.

Das Ergebnis von guix pull ist ein als ~/.config/guix/current verfügbares Profil mit dem neuesten Guix.

Die Befehlszeilenoption --list-generations oder kurz -l listet ältere von guix pull erzeugte Generationen auf, zusammen mit Informationen zu deren Provenienz.

$ guix pull -l
Generation 1	10. Juni 2018 00:18:18
  guix 65956ad
    Repository-URL: https://git.savannah.gnu.org/git/guix.git
    Branch: origin/master
    Commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Generation 2	11. Juni 2018 11:02:49
  guix e0cc7f6
    Repository-URL: https://git.savannah.gnu.org/git/guix.git
    Branch: origin/master
    Commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d

Generation 3	13. Juni 2018 23:31:07	(aktuell)
  guix 844cc1c
    Repository-URL: https://git.savannah.gnu.org/git/guix.git
    Branch: origin/master
    Commit: 844cc1c8f394f03b404c5bb3aee086922373490c

Im Abschnitt guix describe werden andere Möglichkeiten erklärt, sich den momentanen Zustand von Guix beschreiben zu lassen.

Das Profil ~/.config/guix/current verhält sich genau wie die durch guix package erzeugten Profile (siehe guix package aufrufen). Das bedeutet, Sie können seine Generationen auflisten und es auf die vorherige Generation – also das vorherige Guix – zurücksetzen und so weiter:

$ guix pull --roll-back
Von Generation „3“ zu „2“ gewechselt
$ guix pull --delete-generations=1
/var/guix/profiles/per-user/charlie/current-guix-1-link wird gelöscht

Sie können auch guix package benutzen (siehe guix package aufrufen), um das Profil zu verwalten, indem Sie es explizit angeben.:

$ guix package -p ~/.config/guix/current --roll-back
switched from generation 3 to 2
$ guix package -p ~/.config/guix/current --delete-generations=1
deleting /var/guix/profiles/per-user/charlie/current-guix-1-link

Der Befehl guix pull wird in der Regel ohne Befehlszeilenargumente aufgerufen, aber er versteht auch folgende Befehlszeilenoptionen:

--url=URL

--commit=Commit

--branch=Branch

Code wird für den guix-Kanal von der angegebenen URL für den angegebenen Commit (eine gültige Commit-ID, dargestellt als hexadezimale Zeichenkette oder Namen eines Git-Tags) oder Branch heruntergeladen.

Diese Befehlszeilenoptionen sind manchmal bequemer, aber Sie können Ihre Konfiguration auch in der Datei ~/.config/guix/channels.scm oder über die Option --channels angeben (siehe unten).

--channels=Datei

-C Datei

Die Liste der Kanäle aus der angegebenen Datei statt aus ~/.config/guix/channels.scm oder aus /etc/guix/channels.scm auslesen. Die Datei muss Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet wird. Siehe Kanäle für nähere Informationen.

--no-channel-files

-q

Unterdrückt das Laden der Kanaldatei des Benutzers ~/.config/guix/channels.scm und der systemweiten Kanaldatei /etc/guix/channels.scm.

--news

-N

Neuigkeiten anzeigen, die Kanalautoren für ihre Nutzer geschrieben haben, um sie über Veränderungen seit der vorigen Generation in Kenntnis zu setzen (siehe Kanalneuigkeiten verfassen). Wenn Sie --details übergeben, werden auch neue und aktualisierte Pakete gezeigt.

Sie können sich mit guix pull -l diese Informationen für vorherige Generationen ansehen.

--list-generations[=Muster]

-l [Muster]

Alle Generationen von ~/.config/guix/current bzw., wenn ein Muster angegeben wird, die dazu passenden Generationen auflisten. Die Syntax für das Muster ist dieselbe wie bei guix package --list-generations (siehe guix package aufrufen).

Nach Voreinstellung werden Informationen über die benutzten Kanäle in der jeweiligen Version sowie die zugehörigen Neuigkeiten ausgegeben. Wenn Sie --details übergeben, wird außerdem die Liste der neu hinzugefügten oder aktualisierten Pakete in jeder Generation verglichen mit der vorigen angezeigt.

--details

Bei --list-generations oder --news wird Guix angewiesen, mehr Informationen über die Unterschiede zwischen aufeinanderfolgenden Generationen anzuzeigen – siehe oben.

--roll-back ¶

Zur vorherigen Generation von ~/.config/guix/current zurückwechseln – d.h. die letzte Transaktion rückgängig machen.

--switch-generation=Muster ¶

-S Muster

Wechselt zu der bestimmten Generation, die durch das Muster bezeichnet wird.

Als Muster kann entweder die Nummer einer Generation oder eine Nummer mit vorangestelltem „+“ oder „-“ dienen. Letzteres springt die angegebene Anzahl an Generationen vor oder zurück. Zum Beispiel kehrt --switch-generation=+1 nach einem Zurücksetzen wieder zur neueren Generation zurück.

--delete-generations[=Muster]

-d [Muster]

Wird kein Muster angegeben, werden alle Generationen außer der aktuellen entfernt.

Dieser Befehl akzeptiert dieselben Muster wie --list-generations. Wenn ein Muster angegeben wird, werden die passenden Generationen gelöscht. Wenn das Muster für eine Zeitdauer steht, werden diejenigen Generationen gelöscht, die älter als die angegebene Dauer sind. Zum Beispiel löscht --delete-generations=1m die Generationen, die mehr als einen Monat alt sind.

Falls die aktuelle Generation zum Muster passt, wird sie nicht gelöscht.

Beachten Sie, dass Sie auf gelöschte Generationen nicht zurückwechseln können. Dieser Befehl sollte also nur mit Vorsicht benutzt werden.

Im Abschnitt guix describe wird eine Möglichkeit erklärt, sich Informationen nur über die aktuelle Generation anzeigen zu lassen.

--profile=Profil

-p Profil

Auf Profil anstelle von ~/.config/guix/current arbeiten.

--dry-run

-n

Anzeigen, welche(r) Commit(s) für die Kanäle benutzt würde(n) und was jeweils erstellt oder substituiert würde, ohne es tatsächlich durchzuführen.

--allow-downgrades

Beziehen einer älteren oder mit der bisheriger Version eines Kanals nicht zusammenhängenden Version zulassen.

Nach Voreinstellung schützt guix pull den Nutzer vor Herabstufungsangriffen („Downgrade Attacks“). Damit werden Versuche bezeichnet, jemanden eine frühere oder unzusammenhängende Version des Git-Repositorys eines Kanals benutzen zu lassen, wodurch diese Person dazu gebracht werden kann, ältere Versionen von Softwarepaketen mit bekannten Schwachstellen zu installieren.

Anmerkung: Sie sollten verstehen, was es für die Sicherheit Ihres Rechners bedeutet, ehe Sie --allow-downgrades benutzen.

--disable-authentication

Beziehen von Kanalcode ohne Authentifizierung zulassen.

Nach Voreinstellung wird durch guix pull von Kanälen heruntergeladener Code darauf überprüft, dass deren Commits durch autorisierte Entwickler signiert worden sind; andernfalls wird ein Fehler gemeldet. Mit dieser Befehlszeilenoption können Sie anweisen, keine solche Verifikation durchzuführen.

Anmerkung: Sie sollten verstehen, was es für die Sicherheit Ihres Rechners bedeutet, ehe Sie --disable-authentication benutzen.

--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.

--bootstrap

Das neueste Guix mit dem Bootstrap-Guile erstellen. Diese Befehlszeilenoption ist nur für Guix-Entwickler von Nutzen.

Mit Hilfe von Kanälen können Sie guix pull anweisen, von welchem Repository und welchem Branch Guix aktualisiert werden soll, sowie von welchen weiteren Repositorys Paketmodule bezogen werden sollen. Im Abschnitt Kanäle finden Sie nähere Informationen.

Außerdem unterstützt guix pull alle gemeinsamen Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen).

5.8 guix time-machine aufrufen

Der Befehl guix time-machine erleichtert den Zugang zu anderen Versionen von Guix. Damit können ältere Versionen von Paketen installiert werden oder eine Berechnung in einer identischen Umgebung reproduziert werden. Die zu benutzende Guix-Version wird über eine Commit-Angabe oder eine Kanalbeschreibungsdatei, wie sie durch guix describe erzeugt werden kann, festgelegt (siehe guix describe aufrufen).

Sagen wir, Sie würden gerne in der Zeit zurückreisen zu den Tagen um November 2020, als die Version 1.2.0 von Guix veröffentlicht worden ist, und außerdem möchten Sie nach Ihrer Ankunft den damaligen guile-Befehl ausführen:

guix time-machine --commit=v1.2.0 -- \
  environment -C --ad-hoc guile -- guile

Mit obigem Befehl wird Guix 1.2.0 geladen (möglicherweise auch andere Kanäle, die in Ihren channels.scm genannten Konfigurationsdateien festgelegt sind – siehe unten) und daraufhin dessen Befehl guix environment ausgeführt, um eine Umgebung, in einen Container verpackt, zu betreten, wo dann guile gestartet wird (guix environment ist mittlerweile Teil von guix shell, siehe guix shell aufrufen). Es ist so, als würden Sie einen DeLorean fahren¹²! Der erste Aufruf von guix time-machine kann lange dauern, weil vielleicht viele Pakete heruntergeladen oder sogar erstellt werden müssen, aber das Ergebnis bleibt in einem Zwischenspeicher und danach geschehen Befehle für denselben Commit fast sofort.

Wie auch bei guix pull werden, wenn keine abweichenden Befehlszeilenoptionen angegeben wurden, mit time-machine die neuesten Commits derjenigen Kanäle geladen, die in ~/.config/guix/channels.scm, /etc/guix/channels.scm oder den vorgegebenen Kanälen festgelegt sind. Die Konfigurationsdateien können Sie mit der Befehlszeilenoption -q ignorieren lassen. Mit dem Befehl:

guix time-machine -q -- build hello

wird dementsprechend das Paket hello erstellt, so wie es auf Guix’ Haupt-Branch ohne zusätzliche Kanäle definiert ist, was in der Regel einer neueren Guix-Version entspricht als der, die Sie installiert haben. Zeitreisen funktionieren also in beide Richtungen!

Anmerkung: Vergangene Commits zu Guix sind unveränderlich und guix time-machine bietet genau dieselbe Software, wie sie in einer damaligen Guix-Version bestanden hat. Demzufolge werden auch keine Sicherheitspatches für alte Versionen von Guix oder dessen Kanäle nachgeliefert. Unbedachter Gebrauch der guix time-machine lässt Sicherheitsschwachstellen freien Raum. Siehe --allow-downgrades.

Einen Fehler meldet guix time-machine, wenn Sie eine Zeitreise zu einem älteren Commit als „v0.16.0“ (Commit ‘4a0b87f0’) vom Dezember 2018 versuchen. Es handelt sich um einen der frühesten Commits, der den Kanalmechanismus unterstützt hat, durch den „Zeitreisen“ möglich werden.

Anmerkung: Technisch gesehen sollte es zwar möglich sein, so einen alten Commit von Guix zu besuchen, aber Sie müssen unter Umständen einige Hürden überwinden, falls keine Substitute der Binärdateien mehr angeboten werden. Wenn Sie in die ferne Vergangenheit reisen, können manche Pakete vielleicht nicht mehr so einfach aus ihrem Quellcode erstellt werden. Ein Beispiel dafür sind alte Versionen von OpenSSL, dessen Tests fehlschlagen, wenn ein bestimmtes Datum vergangen ist. Dieses spezielle Problem lässt sich umgehen, indem Sie eine virtuelle Erstellungsmaschine einrichten, deren Uhr Sie auf einen passenden Zeitpunkt zurückdrehen (siehe Virtuelle Erstellungsmaschinen).

Die allgemeine Syntax lautet:

guix time-machine Optionen… -- Befehl Argument…

Dabei werden der Befehl und jedes Argument… unverändert an den guix-Befehl der angegebenen Version übergeben. Die Optionen, die die Version definieren, sind dieselben wie bei guix pull (siehe guix pull aufrufen):

--url=URL

--commit=Commit

--branch=Branch

Den guix-Kanal von der angegebenen URL benutzen, für den angegebenen Commit (eine gültige Commit-ID, dargestellt als hexadezimale Zeichenkette oder Namen eines Git-Tags) oder Branch.

--channels=Datei

-C Datei

Die Liste der Kanäle aus der angegebenen Datei auslesen. Die Datei muss Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet wird. Siehe Kanäle für nähere Informationen.

--no-channel-files

-q

Unterdrückt das Laden der Kanaldatei des Benutzers ~/.config/guix/channels.scm und der systemweiten Kanaldatei /etc/guix/channels.scm.

Anstelle von guix time-machine -q können Sie daher auch den folgenden Bash-Befehl verwenden, der die Syntax für „Prozesssubstitutionen“ verwendet (siehe Process Substitution in Referenzhandbuch zu GNU Bash):

guix time-machine -C <(echo %default-channels) …

Beachten Sie, dass durch guix time-machine Erstellungen von Kanälen und deren Abhängigkeiten ausgelöst werden können, welche durch die gemeinsamen Erstellungsoptionen gesteuert werden können (siehe Gemeinsame Erstellungsoptionen).

5.9 Untergeordnete

Anmerkung: Die hier beschriebenen Funktionalitäten sind in der Version 123b722 bloß eine „Technologie-Vorschau“, daher kann sich die Schnittstelle in Zukunft noch ändern.

Manchmal könnten Sie Pakete aus der gerade laufenden Fassung von Guix mit denen mischen wollen, die in einer anderen Guix-Version verfügbar sind. Guix-Untergeordnete ermöglichen dies, indem Sie verschiedene Guix-Versionen beliebig mischen können.

Aus technischer Sicht ist ein „Untergeordneter“ im Kern ein separater Guix-Prozess, der über eine REPL (siehe guix repl aufrufen) mit Ihrem Haupt-Guix-Prozess verbunden ist. Das Modul (guix inferior) ermöglicht es Ihnen, Untergeordnete zu erstellen und mit ihnen zu kommunizieren. Dadurch steht Ihnen auch eine hochsprachliche Schnittstelle zur Verfügung, um die von einem Untergeordneten angebotenen Pakete zu durchsuchen und zu verändern – untergeordnete Pakete.

In Kombination mit Kanälen (siehe Kanäle) bieten Untergeordnete eine einfache Möglichkeit, mit einer anderen Version von Guix zu interagieren. Nehmen wir zum Beispiel an, Sie wollen das aktuelle guile-Paket in Ihr Profil installieren, zusammen mit dem guile-json, wie es in einer früheren Guix-Version existiert hat – vielleicht weil das neuere guile-json eine inkompatible API hat und Sie daher Ihren Code mit der alten API benutzen möchten. Dazu könnten Sie ein Manifest für guix package --manifest schreiben (siehe Manifeste verfassen); in diesem Manifest würden Sie einen Untergeordneten für diese alte Guix-Version erzeugen, für die Sie sich interessieren, und aus diesem Untergeordneten das guile-json-Paket holen:

(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;für die Prozedur 'first'

(define channels
  ;; Dies ist die alte Version, aus der wir
  ;; guile-json extrahieren möchten.
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; Ein Untergeordneter, der obige Version repräsentiert.
  (inferior-for-channels channels))

;; Daraus erzeugen wir jetzt ein Manifest mit dem aktuellen
;; „guile“-Paket und dem alten „guile-json“-Paket.
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

Bei seiner ersten Ausführung könnte für guix package --manifest erst der angegebene Kanal erstellt werden müssen, bevor der Untergeordnete erstellt werden kann; nachfolgende Durchläufe sind wesentlich schneller, weil diese Guix-Version bereits zwischengespeichert ist.

Folgende Prozeduren werden im Modul (guix inferior) angeboten, um einen Untergeordneten zu öffnen:

Prozedur: inferior-for-channels Kanäle [#:cache-directory] [#:ttl]

Liefert einen Untergeordneten für die Kanäle, einer Liste von Kanälen. Dazu wird der Zwischenspeicher im Verzeichnis cache-directory benutzt, dessen Einträge nach ttl Sekunden gesammelt werden dürfen. Mit dieser Prozedur wird eine neue Verbindung zum Erstellungs-Daemon geöffnet.

Als Nebenwirkung erstellt oder substituiert diese Prozedur unter Umständen Binärdateien für die Kanäle, was einige Zeit in Anspruch nehmen kann.

Prozedur: open-inferior Verzeichnis [#:command "bin/guix"]

Öffnet das untergeordnete Guix mit dem Befehl command im angegebenen Verzeichnis durch Ausführung von Verzeichnis/command repl oder entsprechend. Liefert #f, wenn der Untergeordnete nicht gestartet werden konnte.

Die im Folgenden aufgeführten Prozeduren ermöglichen es Ihnen, untergeordnete Pakete abzurufen und zu verändern.

Prozedur: inferior-packages Untergeordneter

Liefert die Liste der Pakete in Untergeordneter.

Prozedur: lookup-inferior-packages Untergeordneter Name [Version]

Liefert die sortierte Liste der untergeordneten Pakete in Untergeordneter, die zum Muster Name in Untergeordneter passen, dabei kommen höhere Versionsnummern zuerst. Wenn Version auf wahr gesetzt ist, werden nur Pakete geliefert, deren Versionsnummer mit dem Präfix Version beginnt.

Prozedur: inferior-package? Objekt

Liefert wahr, wenn das Objekt ein Untergeordneter ist.

Prozedur: inferior-package-name Paket

Prozedur: inferior-package-version Paket

Prozedur: inferior-package-synopsis Paket

Prozedur: inferior-package-description Paket

Prozedur: inferior-package-home-page Paket

Prozedur: inferior-package-location Paket

Prozedur: inferior-package-inputs Paket

Prozedur: inferior-package-native-inputs Paket

Prozedur: inferior-package-propagated-inputs Paket

Prozedur: inferior-package-transitive-propagated-inputs Paket

Prozedur: inferior-package-native-search-paths Paket

Prozedur: inferior-package-transitive-native-search-paths Paket

Prozedur: inferior-package-search-paths Paket

Diese Prozeduren sind das Gegenstück zu den Zugriffsmethoden des Verbunds „package“ für Pakete (siehe package-Referenz). Die meisten davon funktionieren durch eine Abfrage auf dem Untergeordneten, von dem das Paket kommt, weshalb der Untergeordnete noch lebendig sein muss, wenn Sie diese Prozeduren aufrufen.

Untergeordnete Pakete können transparent wie jedes andere Paket oder dateiartige Objekt in G-Ausdrücken verwendet werden (siehe G-Ausdrücke). Sie werden auch transparent wie reguläre Pakete von der Prozedur packages->manifest behandelt, welche oft in Manifesten benutzt wird (siehe die Befehlszeilenoption --manifest von guix package). Somit können Sie ein untergeordnetes Paket ziemlich überall dort verwenden, wo Sie ein reguläres Paket einfügen würden: in Manifesten, im Feld packages Ihrer operating-system-Deklaration und so weiter.

5.10 guix describe aufrufen

Sie könnten sich des Öfteren Fragen stellen wie: „Welche Version von Guix benutze ich gerade?“ oder „Welche Kanäle benutze ich?“ Diese Informationen sind in vielen Situationen nützlich: wenn Sie eine Umgebung auf einer anderen Maschine oder mit einem anderen Benutzerkonto nachbilden möchten, wenn Sie einen Fehler melden möchten, wenn Sie festzustellen versuchen, welche Änderung an den von Ihnen verwendeten Kanälen diesen Fehler verursacht hat, oder wenn Sie Ihren Systemzustand zum Zweck der Reproduzierbarkeit festhalten möchten. Der Befehl guix describe gibt Ihnen Antwort auf diese Fragen.

Wenn Sie ihn aus einem mit guix pull bezogenen guix heraus ausführen, zeigt Ihnen guix describe die Kanäle an, aus denen es erstellt wurde, jeweils mitsamt ihrer Repository-URL und Commit-ID (siehe Kanäle):

$ guix describe
Generation 10	03. September 2018 17:32:44	(aktuell)
  guix e0fa68c
    Repository-URL: https://git.savannah.gnu.org/git/guix.git
    Branch: master
    Commit: e0fa68c7718fffd33d81af415279d6ddb518f727

Wenn Sie mit dem Versionskontrollsystem Git vertraut sind, erkennen Sie vielleicht die Ähnlichkeit zu git describe; die Ausgabe ähnelt auch der von guix pull --list-generations eingeschränkt auf die aktuelle Generation (siehe die Befehlszeilenoption --list-generations). Weil die oben gezeigte Git-Commit-ID eindeutig eine bestimmte Version von Guix bezeichnet, genügt diese Information, um die von Ihnen benutzte Version von Guix zu beschreiben, und auch, um sie nachzubilden.

Damit es leichter ist, Guix nachzubilden, kann Ihnen guix describe auch eine Liste der Kanäle statt einer menschenlesbaren Beschreibung wie oben liefern:

$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (commit
          "e0fa68c7718fffd33d81af415279d6ddb518f727")
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
              "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

Sie können die Ausgabe in einer Datei speichern, die Sie an guix pull -C auf einer anderen Maschine oder zu einem späteren Zeitpunkt übergeben, wodurch dann eine Instanz von genau derselben Guix-Version installiert wird (siehe die Befehlszeilenoption -C). Daraufhin können Sie, weil Sie jederzeit dieselbe Version von Guix installieren können, auch gleich eine vollständige Softwareumgebung genau nachbilden. Wir halten das trotz aller Bescheidenheit für klasse und hoffen, dass Ihnen das auch gefällt!

Die genauen Befehlszeilenoptionen, die guix describe unterstützt, lauten wie folgt:

--format=Format

-f Format

Die Ausgabe im angegebenen Format generieren, was eines der Folgenden sein muss:

human

für menschenlesbare Ausgabe,

channels

eine Liste von Kanalspezifikationen erzeugen, die an guix pull -C übergeben werden oder als ~/.config/guix/channels.scm eingesetzt werden können (siehe guix pull aufrufen),

channels-sans-intro

verhält sich wie channels, aber ohne das introduction-Feld; benutzen Sie es, um eine Kanalspezifikation zu erzeugen, die für die Guix-Version 1.1.0 oder früher geeignet ist – das introduction-Feld ist für Kanalauthentifizierung gedacht (siehe Kanalauthentifizierung), die von diesen älteren Versionen nicht unterstützt wird,

json ¶

generiert eine Liste von Kanalspezifikationen im JSON-Format,

recutils

generiert eine Liste von Kanalspezifikationen im Recutils-Format.

--list-formats

Verfügbare Formate für die Befehlszeilenoption --format anzeigen.

--profile=Profil

-p Profil

Informationen über das Profil anzeigen.

5.11 guix archive aufrufen

Der Befehl guix archive ermöglicht es Nutzern, Dateien im Store in eine einzelne Archivdatei zu exportieren und diese später auf einer Maschine, auf der Guix läuft, zu importieren. Insbesondere können so Store-Objekte von einer Maschine in den Store einer anderen Maschine übertragen werden.

Anmerkung: Wenn Sie nach einer Möglichkeit suchen, Archivdateien für andere Werkzeuge als Guix zu erstellen, finden Sie Informationen dazu im Abschnitt guix pack aufrufen.

Führen Sie Folgendes aus, um Store-Dateien als ein Archiv auf die Standardausgabe zu exportieren:

guix archive --export Optionen Spezifikationen…

Spezifikationen sind dabei entweder die Namen von Store-Dateien oder Paketspezifikationen wie bei guix package (siehe guix package aufrufen). Zum Beispiel erzeugt der folgende Befehl ein Archiv der gui-Ausgabe des Pakets git sowie die Hauptausgabe von emacs:

guix archive --export git:gui /gnu/store/…-emacs-24.3 > groß.nar

Wenn die angegebenen Pakete noch nicht erstellt worden sind, werden sie durch guix archive automatisch erstellt. Der Erstellungsprozess kann durch die gemeinsamen Erstellungsoptionen gesteuert werden (siehe Gemeinsame Erstellungsoptionen).

Um das emacs-Paket auf eine über SSH verbundene Maschine zu übertragen, würde man dies ausführen:

guix archive --export -r emacs | ssh die-maschine guix archive --import

Auf gleiche Art kann auch ein vollständiges Benutzerprofil von einer Maschine auf eine andere übertragen werden:

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh die-maschine guix archive --import

Jedoch sollten Sie in beiden Beispielen beachten, dass alles, was zu emacs, dem Profil oder deren Abhängigkeiten (wegen -r) gehört, übertragen wird, egal ob es schon im Store der Zielmaschine vorhanden ist oder nicht. Mit der Befehlszeilenoption --missing lässt sich herausfinden, welche Objekte im Ziel-Store noch fehlen. Der Befehl guix copy vereinfacht und optimiert diesen gesamten Prozess, ist also, was Sie in diesem Fall wahrscheinlich eher benutzen wollten (siehe guix copy aufrufen).

Dabei wird jedes Store-Objekt als „normalisiertes Archiv“, kurz „Nar“, formatiert (was im Folgenden beschrieben wird) und die Ausgabe von guix archive --export (bzw. die Eingabe von guix archive --import) ist ein Nar-Bündel.

Das Nar-Format folgt einem ähnlichen Gedanken wie beim „tar“-Format, unterscheidet sich aber auf eine für unsere Zwecke geeignetere Weise. Erstens werden im Nar-Format nicht sämtliche Unix-Metadaten aller Dateien aufgenommen, sondern nur der Dateityp (ob es sich um eine reguläre Datei, ein Verzeichnis oder eine symbolische Verknüpfung handelt). Unix-Dateiberechtigungen sowie Besitzer und Gruppe werden nicht gespeichert. Zweitens entspricht die Reihenfolge, in der der Inhalt von Verzeichnissen abgelegt wird, immer der Reihenfolge, in der die Dateinamen gemäß der C-Locale sortiert würden. Dadurch wird die Erstellung von Archivdateien völlig deterministisch.

Das Nar-Bündel-Format setzt sich im Prinzip aus null oder mehr aneinandergehängten Nars zusammen mit Metadaten für jedes enthaltene Store-Objekt, nämlich dessen Dateinamen, Referenzen, der zugehörigen Ableitung sowie einer digitalen Signatur.

Beim Exportieren versieht der Daemon den Inhalt des Archivs mit einer digitalen Signatur, auch Beglaubigung genannt. Diese digitale Signatur wird an das Archiv angehängt. Beim Importieren verifiziert der Daemon die Signatur und lehnt den Import ab, falls die Signatur ungültig oder der Signierschlüssel nicht autorisiert ist.

Die wichtigsten Befehlszeilenoptionen sind:

--export

Exportiert die angegebenen Store-Dateien oder Pakete (siehe unten) und schreibt das resultierende Archiv auf die Standardausgabe.

Abhängigkeiten fehlen in der Ausgabe, außer wenn --recursive angegeben wurde.

-r

--recursive

Zusammen mit --export wird guix archive hiermit angewiesen, Abhängigkeiten der angegebenen Objekte auch ins Archiv aufzunehmen. Das resultierende Archiv ist somit eigenständig; es enthält den Abschluss der exportierten Store-Objekte.

--import

Ein Archiv von der Standardeingabe lesen und darin enthaltende Dateien in den Store importieren. Der Import bricht ab, wenn das Archiv keine gültige digitale Signatur hat oder wenn es von einem öffentlichen Schlüssel signiert wurde, der keiner der autorisierten Schlüssel ist (siehe --authorize weiter unten).

--missing

Eine Liste der Store-Dateinamen von der Standardeingabe lesen, je ein Name pro Zeile, und auf die Standardausgabe die Teilmenge dieser Dateien schreiben, die noch nicht im Store vorliegt.

--generate-key[=Parameter] ¶

Ein neues Schlüsselpaar für den Daemon erzeugen. Dies ist erforderlich, damit Archive mit --export exportiert werden können. Normalerweise wird diese Option sofort umgesetzt, jedoch kann sie, wenn erst der Entropie-Pool neu gefüllt werden muss, einige Zeit in Anspruch nehmen. Auf Guix System kümmert sich der guix-service-type darum, dass beim ersten Systemstart das Schlüsselpaar erzeugt wird.

Das erzeugte Schlüsselpaar wird typischerweise unter /etc/guix gespeichert, in den Dateien signing-key.pub (für den öffentlichen Schlüssel) und signing-key.sec (für den privaten Schlüssel, der geheim gehalten werden muss). Wurden keine Parameters angegeben, wird ein ECDSA-Schlüssel unter Verwendung der Kurve Ed25519 erzeugt, oder, falls die Libgcrypt-Version älter als 1.6.0 ist, ein 4096-Bit-RSA-Schlüssel. Sonst geben die Parameter für Libgcrypt geeignete Parameter für genkey an (siehe gcry_pk_genkey in Referenzhandbuch von Libgcrypt).

--authorize ¶

Mit dem auf der Standardeingabe übergebenen öffentlichen Schlüssel signierte Importe autorisieren. Der öffentliche Schlüssel muss als „advanced“-formatierter S-Ausdruck gespeichert sein, d.h. im selben Format wie die Datei signing-key.pub.

Die Liste autorisierter Schlüssel wird in der Datei /etc/guix/acl gespeichert, die auch von Hand bearbeitet werden kann. Die Datei enthält „advanced“-formatierte S-Ausdrücke und ist als eine Access Control List für die Simple Public-Key Infrastructure (SPKI) aufgebaut.

--extract=Verzeichnis

-x Verzeichnis

Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern geliefert wird (siehe Substitute), und ins Verzeichnis entpacken. Dies ist eine systemnahe Operation, die man nur selten direkt benutzt; siehe unten.

Zum Beispiel entpackt folgender Befehl das Substitut für Emacs, wie es von bordeaux.guix.gnu.org geliefert wird, nach /tmp/emacs:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/gzip/…-emacs-24.5 \
  | gunzip | guix archive -x /tmp/emacs

Archive mit nur einem einzelnen Objekt unterscheiden sich von Archiven für mehrere Dateien, wie sie guix archive --export erzeugt; sie enthalten nur ein einzelnes Store-Objekt und keine eingebettete Signatur. Beim Entpacken findet also keine Signaturprüfung statt und ihrer Ausgabe sollte so erst einmal nicht vertraut werden.

Der eigentliche Zweck dieser Operation ist, die Inspektion von Archivinhalten von Substitutservern möglich zu machen, auch wenn diesen unter Umständen nicht vertraut wird (siehe guix challenge aufrufen).

--list

-t

Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern geliefert wird (siehe Substitute), und die Dateien darin ausgeben, wie in diesem Beispiel:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

6.1 Weitere Kanäle angeben

Sie können auch weitere Kanäle als Bezugsquelle angeben. Um einen Kanal zu benutzen, tragen Sie ihn in ~/.config/guix/channels.scm ein, damit guix pull diesen Kanal zusätzlich zu den standardmäßigen Guix-Kanälen als Paketquelle verwendet:

;; Paketvarianten zu denen von Guix dazunehmen.
(cons (channel
        (name 'paketvarianten)
        (url "https://example.org/variant-packages.git"))
      %default-channels)

Beachten Sie, dass der obige Schnipsel (wie immer!) Scheme-Code ist; mit cons fügen wir einen Kanal zur Liste der Kanäle hinzu, an die die Variable %default-channels gebunden ist (siehe cons and lists in Referenzhandbuch zu GNU Guile). Mit diesem Dateiinhalt wird guix pull nun nicht mehr nur Guix, sondern auch die Paketmodule aus Ihrem Repository erstellen. Das Ergebnis in ~/.config/guix/current ist so die Vereinigung von Guix und Ihren eigenen Paketmodulen.

$ guix describe
Generation 19	27. August 2018 16:20:48
  guix d894ab8
    Repository-URL: https://git.savannah.gnu.org/git/guix.git
    Branch: master
    Commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  paketvarianten dd3df5e
    Repository-URL: https://example.org/variant-packages.git
    Branch: master
    Commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb

Obige Ausgabe von guix describe zeigt an, dass jetzt Generation 19 läuft und diese sowohl Guix als auch Pakete aus dem Kanal paketvarianten enthält (siehe guix describe aufrufen).

6.2 Eigenen Guix-Kanal benutzen

Der Kanal namens guix gibt an, wovon Guix selbst – seine Befehlszeilenwerkzeuge und seine Paketsammlung – heruntergeladen werden sollen. Wenn Sie zum Beispiel mit einer anderen Kopie des Guix-Repositorys arbeiten möchten und diese auf example.org zu finden ist, und zwar im Branch namens super-hacks, dann schreiben Sie folgende Spezifikation in ~/.config/guix/channels.scm:

;; 'guix pull' ein anderes Repository benutzen lassen.
(list (channel
        (name 'guix)
        (url "https://example.org/anderes-guix.git")
        (branch "super-hacks")))

Ab dann wird guix pull seinen Code vom Branch super-hacks des Repositorys auf example.org beziehen. Wie man dessen Autorisierung bewerkstelligt, können Sie im Folgenden lesen (siehe Kanalauthentifizierung).

Wir weisen darauf hin, dass Sie oben im url-Feld den Namen eines lokalen Verzeichnisses angeben können, wenn sich der Kanal, den Sie benutzen möchten, auf einem lokalen Dateisystem befindet. Allerdings wird guix dabei überprüfen, ob das besagte Verzeichnis auch Ihrem Benutzer gehört, bevor es mit der Verarbeitung fortfährt. Das bedeutet, dass Benutzer, die ein Verzeichnis standardmäßig beziehen möchten, das ihnen nicht gehört, einen Eintrag in deren globaler Git-Konfigurationsdatei machen müssen, um das Verzeichnis ausdrücklich als sicher einzustufen. Andernfalls wird sich guix weigern, es auch nur zu lesen. Wenn wir annehmen, dass ein systemweites lokales Verzeichnis unter /src/guix.git benutzt werden soll, müsste dafür eine Git-Konfigurationsdatei namens ~/.gitconfig mit folgendem Inhalt angelegt werden:

[safe]
        directory = /src/guix.git

Dies gilt auch für den Administratorbenutzer root, außer wenn der Besitzer des Verzeichnisses einen Aufruf mit sudo macht.

6.3 Guix nachbilden

Der Befehl guix describe zeigt genau, aus welchen Commits die Guix-Instanz erstellt wurde, die Sie benutzen (siehe guix describe aufrufen). Sie können diese Instanz auf einer anderen Maschine oder zu einem späteren Zeitpunkt nachbilden, indem Sie eine Kanalspezifikation angeben, die auf diese Commits „festgesetzt“ ist.

;; Ganz bestimmte Commits der relevanten Kanäle installieren.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "6298c3ffd9654d3231a6f25390b056483e8f407c"))
      (channel
       (name 'paketvarianten)
       (url "https://example.org/variant-packages.git")
       (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

Um so eine festgesetzte Kanalspezifikation zu bekommen, ist es am einfachsten, guix describe auszuführen und seine Ausgabe in channels-Formatierung in einer Datei zu speichern. Das geht so:

guix describe -f channels > channels.scm

Die erzeugte Datei channels.scm kann mit der Befehlszeilenoption -C von guix pull (siehe guix pull aufrufen) oder von guix time-machine (siehe guix time-machine aufrufen) übergeben werden. Ein Beispiel:

guix time-machine -C channels.scm -- shell python -- python3

Anhand der Datei channels.scm ist festgelegt, dass der obige Befehl immer genau dieselbe Guix-Instanz lädt und dann mit dieser Instanz genau dasselbe Python startet (siehe guix shell aufrufen). So werden auf jeder beliebigen Maschine zu jedem beliebigen Zeitpunkt genau dieselben Binärdateien ausgeführt, Bit für Bit.

Das Problem, das solche festgesetzten Kanäle lösen, ist ähnlich zu dem, wofür andere Werkzeuge zur Softwareauslieferung „Lockfiles“ einsetzen – ein Satz von Paketen wird reproduzierbar auf eine bestimmte Version festgesetzt. Im Fall von Guix werden allerdings sämtliche mit Guix ausgelieferte Pakete auf die angegebenen Commits fixiert; tatsächlich sogar der ganze Rest von Guix mitsamt seinen Kernmodulen und Programmen für die Befehlszeile. Dazu wird sicher garantiert, dass Sie wirklich genau dieselbe Software vorfinden werden.

Das verleiht Ihnen Superkräfte, mit denen Sie die Provenienz binärer Artefakte sehr feinkörnig nachverfolgen können und Software-Umgebungen nach Belieben nachbilden können. Sie können es als eine Art Fähigkeit zur „Meta-Reproduzierbarkeit“ auffassen, wenn Sie möchten. Der Abschnitt Untergeordnete beschreibt eine weitere Möglichkeit, diese Superkräfte zu nutzen.

6.4 Anpassung des systemweiten Guix

Wenn bei Ihnen Guix System läuft oder Sie Guix System benutzen, um Abbilder („Images“) zu erstellen, möchten Sie vielleicht Anpassungen vornehmen, welches guix darin systemweit verfügbar ist – um genau zu sein, an /run/current-system/profile/bin/guix. Zum Beispiel könnten Sie zusätzliche Kanäle vorsehen oder genau festschreiben, welche Version es verwendet.

Dazu verwenden Sie die Prozedur guix-for-channels, die ein Paket für die angegebenen Pakete zurückliefert, welche sie in Ihrer Betriebssystemkonfiguration so benutzen wie in diesem Beispiel:

(use-modules (gnu packages package-management)
             (guix channels))

(define meine-kanäle
  ;; Die Kanäle, die in /run/current-system/profile/bin/guix
  ;; verfügbar sein sollen.
  (append
   (list (channel
          (name 'guix-science)
          (url "https://github.com/guix-science/guix-science")
          (branch "master")))
   %default-channels))

(operating-system
  ;; …
  (services
    ;; Ändern, welches Paket 'guix-service-type' verwendet.
    (modify-services %base-services
      (guix-service-type
       config => (guix-configuration
                  (inherit config)
                  (channels meine-kanäle)
                  (guix (guix-for-channels meine-kanäle)))))))

Das Ergebnis ist ein Betriebssystem, in dem sowohl der guix-Kanal als auch der Kanal guix-science als Voreinstellung sichtbar sind. Das Feld channels in der obigen guix-configuration bewirkt zudem, dass die Datei /etc/guix/channels.scm, die von guix pull benutzt wird, dieselben Kanäle angibt (siehe das Feld channels in guix-configuration).

Das Modul (gnu packages package-management) exportiert die Prozedur guix-for-channels, die im Folgenden beschrieben wird.

Prozedur: guix-for-channels Kanäle

Liefert ein Paket mit jedem der Kanäle.

Das Ergebnis ist ein „normales“ Paket, das für die Nutzung in guix-configuration geeignet ist, wie oben gezeigt, aber auch überall sonst wo ein Paket erwartet wird.

6.5 Kanalauthentifizierung

Die Befehle guix pull und guix time-machine authentifizieren den von Kanälen bezogenen Code. Es wird geprüft, dass jeder geladene Commit von einem autorisierten Entwickler signiert wurde. Das Ziel ist, Sie vor unautorisierten Änderungen am Kanal, die Nutzer bösartigen Code ausführen lassen, zu schützen.

Als Nutzer müssen Sie eine Kanaleinführung („Channel Introduction“) in Ihrer Kanaldatei angeben, damit Guix weiß, wie der erste Commit authentifiziert werden kann. Eine Kanalspezifikation, zusammen mit seiner Einführung, sieht in etwa so aus:

(channel
  (name 'ein-kanal)
  (url "https://example.org/ein-kanal.git")
  (introduction
   (make-channel-introduction
    "6f0d8cc0d88abb59c324b2990bfee2876016bb86"
    (openpgp-fingerprint
     "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))

Obige Spezifikation zeigt den Namen und die URL des Kanals. Der Aufruf von make-channel-introduction, den Sie oben sehen, gibt an, dass die Authentifizierung dieses Kanals bei Commit 6f0d8cc… beginnt, welcher mit dem OpenPGP-Schlüssel mit Fingerabdruck CABB A931… signiert ist.

Für den Hauptkanal mit Namen guix bekommen Sie diese Informationen automatisch mit Ihrer Guix-Installation. Für andere Kanäle tragen Sie die Kanaleinführung, die Ihnen die Kanalautoren mitteilen, in die Datei channels.scm ein. Achten Sie dabei darauf, die Kanaleinführung von einer vertrauenswürdigen Quelle zu bekommen, denn sie stellt die Wurzel all Ihren Vertrauens dar.

Wenn Sie neugierig sind, wie die Authentifizierung funktioniert, lesen Sie weiter!

6.6 Kanäle mit Substituten

Wenn Sie guix pull ausführen, wird Guix als Erstes die Definition jedes verfügbaren Pakets kompilieren. Das ist eine teure Operation, für die es aber Substitute geben könnte (siehe Substitute). Mit dem folgenden Schnipsel in channels.scm wird sichergestellt, dass guix pull den neuesten Commit benutzt, für den bereits Substitute für die Paketdefinitionen vorliegen. Dazu wird der Server für Kontinuierliche Integration auf https://ci.guix.gnu.org angefragt.

(use-modules (guix ci))

(list (channel-with-substitutes-available
       %default-guix-channel
       "https://ci.guix.gnu.org"))

Beachten Sie: Das heißt nicht, dass für alle Pakete, die Sie installieren werden, nachdem Sie guix pull durchgeführt haben, bereits Substitute vorliegen. Es wird nur sichergestellt, dass guix pull keine Paketdefinitionen zu kompilieren versucht. Das hilft besonders auf Maschinen mit eingeschränkten Rechenressourcen.

6.7 Einen Kanal erstellen

Sagen wir, Sie haben ein paar eigene Paketvarianten oder persönliche Pakete, von denen Sie meinen, dass sie nicht geeignet sind, ins Guix-Projekt selbst aufgenommen zu werden, die Ihnen aber dennoch wie andere Pakete auf der Befehlszeile zur Verfügung stehen sollen. Indem Sie einen Kanal damit anlegen, wird Ihre Sammlung von Paketen nutzbar und Sie können sie mit anderen teilen. Dazu sind folgende Schritte nötig:

1. Kanäle werden in Git-Repositorys verwaltet, daher ist der erste Schritt beim Anlegen eines Kanals, dass Sie sein Repository erzeugen.

   mkdir my-channel
   cd my-channel
   git init
   

2. Im nächsten Schritt erzeugen Sie Dateien für Paketmodule (siehe Paketmodule). In jeder können eine oder mehrere Paketdefinitionen stehen (siehe Pakete definieren). Über einen Kanal können Sie auch andere Dinge als nur Pakete bekommen, etwa Erstellungssysteme oder Dienste; hier geht es um Pakete, weil sie der häufigste Verwendungszweck sind.

   Ein Beispiel: Alice könnte ein Modul mit dem Namen (alice packages greetings) bereitstellen für ihre Lieblings-Hallo-Welt-Implementierungen. Zu diesem Zweck würde Alice ein Verzeichnis entsprechend dem Modulnamen erzeugen.

   mkdir -p alice/packages
   $EDITOR alice/packages/greetings.scm
   git add alice/packages/greetings.scm
   

   Welchen Namen Sie einem Paketmodul geben möchten, bleibt Ihnen überlassen. Behalten Sie nur die Einschränkung im Kopf, dass sich der Name von anderen Paketsammlungen unterscheiden muss, deshalb trifft Alice aus unserem Beispiel die weise Entscheidung für (alice packages …) als Namensraum.

   Es sei erwähnt, dass Sie Paketmodule auch in einem Unterverzeichnis innerhalb des Repositorys ablegen können; siehe dazu Paketmodule in einem Unterverzeichnis.

3. Nachdem das erste Modul eingerichtet ist, geht es als nächster Schritt ans Testen der angebotenen Pakete. Dazu können Sie guix build verwenden, wobei Sie mitteilen, dass es die Module aus dem Git-Checkout verwenden soll. Nehmen wir zum Beispiel an, in (alice packages greetings) wird ein Paket namens hi-from-alice angeboten. Dann führt Alice aus dem Git-Checkout diesen Befehl aus:

   guix build -L. hi-from-alice
   

   Hier wird mit -L. das aktuelle Verzeichnis zu Guiles Ladepfad hinzugefügt (siehe Load Paths in Referenzhandbuch zu GNU Guile).

4. Es kann ein paar Versuche dauern, aber bald ist Alice zufrieden mit ihren Paketdefinitionen und committet die Datei:

   git commit
   

   Als Kanalautor möchten Sie vielleicht Materialien mitliefern, damit dessen Nutzer ihn authentifizieren können. Siehe Kanalauthentifizierung und Kanalautorisierungen angeben für Informationen, wie das geht.

5. Wenn jemand also Alice’ Kanal benutzen möchte, muss er diese Kanalautorisierungen nur in seiner Kanaldatei eintragen (siehe Weitere Kanäle angeben) und guix pull ausführen (siehe guix pull aufrufen):

   $EDITOR ~/.config/guix/channels.scm
   guix pull
   

   Von nun an verhält sich Guix so, als hätte man das Wurzelverzeichnis des Git-Repositorys jenes Kanals dauerhaft zu Guiles Ladepfad hinzugefügt. In Alice’ Fall wird also (alice packages greetings) automatisch durch den guix-Befehl gefunden.

Erledigt!

Warnung: Ehe Sie Ihren Kanal der Welt zur Verfügung stellen, möchten wir Ihnen auch ein paar Worte der Warnung mit auf den Weg geben:

• Bevor Sie einen Kanal veröffentlichen, überlegen Sie sich bitte erst, ob Sie die Pakete nicht besser zum eigentlichen Guix-Projekt beisteuern (siehe Mitwirken). Das Guix-Projekt ist gegenüber allen Arten freier Software offen und zum eigentlichen Guix gehörende Pakete stehen allen Guix-Nutzern zur Verfügung, außerdem profitieren sie von Guix’ Qualitätssicherungsprozess.
• Bedenken Sie, dass Paketmodule und Paketdefinitionen Scheme-Code sind, der verschiedene Programmierschnittstellen (APIs) benutzt. Wir, die Entwickler von Guix, ändern APIs nie einfach so, versprechen aber auch nicht, APIs nicht zu verändern. Wenn Sie Paketdefinitionen außerhalb von Guix betreuen, sehen wir es als Ihre Aufgabe an, deren Kompatibilität sicherzustellen.
• Das bedeutet auch, dass Sie, wenn Sie einen externen Kanal verwenden und dieser kaputt geht, Sie dies bitte den Autoren des Kanals und nicht dem Guix-Projekt melden.

Wir haben Sie gewarnt! Allerdings denken wir auch, dass externe Kanäle eine praktische Möglichkeit sind, die Paketsammlung von Guix zu ergänzen und Ihre Verbesserungen mit anderen zu teilen, wie es dem Grundgedanken freier Software entspricht. Bitte schicken Sie eine E-Mail an guix-devel@gnu.org, wenn Sie dies diskutieren möchten.

6.8 Paketmodule in einem Unterverzeichnis

Als Kanalautor möchten Sie vielleicht Ihre Kanalmodule in einem Unterverzeichnis anlegen. Wenn sich Ihre Module im Unterverzeichnis guix befinden, müssen Sie eine Datei .guix-channel mit Metadaten einfügen:

(channel
  (version 0)
  (directory "guix"))

Die Module müssen sich unterhalb des als directory angegebenen Verzeichnisses befinden, weil directory Guiles Einstellung für load-path verändert. Zum Beispiel muss sich, wenn in .guix-channel (directory "base") eingetragen ist, ein Modul, was als (define-module (gnu packages fun)) definiert ist, in base/gnu/packages/fun.scm befinden.

Dadurch ist es möglich, nur einen Teil eines Repositorys als Kanal zu benutzen, was nützlich ist, weil Guix verlangt, dass beim Beziehen von Kanälen alle Guile-Module darin auch gültig sind. Zum Beispiel handelt es sich bei Konfigurationsdateien der Maschinen für guix deploy nicht um gültige Guile-Module und sie zu beziehen würde guix pull fehlschlagen lassen.

6.9 Kanalabhängigkeiten deklarieren

Kanalautoren können auch beschließen, die Paketsammlung von anderen Kanälen zu erweitern. Dazu können sie in einer Metadatendatei .guix-channel deklarieren, dass ihr Kanal von anderen Kanälen abhängt. Diese Datei muss im Wurzelverzeichnis des Kanal-Repositorys platziert werden.

Die Metadatendatei sollte einen einfachen S-Ausdruck wie diesen enthalten:

(channel
 (version 0)
 (dependencies
  (channel
   (name irgendeine-sammlung)
   (url "https://example.org/erste-sammlung.git")

   ;; Der Teil mit der 'introduction' hier ist optional. Sie geben hier
   ;; die Kanaleinführung an, wenn diese Abhängigkeiten authentifiziert
   ;; werden können.
   (introduction
    (channel-introduction
      (version 0)
      (commit "a8883b58dc82e167c96506cf05095f37c2c2c6cd")
      (signer "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))
  (channel
   (name eine-andere-sammlung)
   (url "https://example.org/zweite-sammlung.git")
   (branch "testing"))))

Im Beispiel oben wird deklariert, dass dieser Kanal von zwei anderen Kanälen abhängt, die beide automatisch geladen werden. Die vom Kanal angebotenen Module werden in einer Umgebung kompiliert, in der die Module all dieser deklarierten Kanäle verfügbar sind.

Um Verlässlichkeit und Wartbarkeit zu gewährleisten, sollten Sie darauf verzichten, eine Abhängigkeit von Kanälen herzustellen, die Sie nicht kontrollieren, außerdem sollten Sie sich auf eine möglichst kleine Anzahl von Abhängigkeiten beschränken.

6.10 Kanalautorisierungen angeben

Wie wir oben gesehen haben, wird durch Guix sichergestellt, dass von Kanälen geladener Code von autorisierten Entwicklern stammt. Als Kanalautor müssen Sie die Liste der autorisierten Entwickler in der Datei .guix-authorizations im Git-Repository des Kanals festlegen. Die Regeln für die Authentifizierung sind einfach: Jeder Commit muss mit einem Schlüssel signiert sein, der in der Datei .guix-authorizations seines bzw. seiner Elterncommits steht¹³ Die Datei .guix-authorizations sieht so aus:

;; Beispiel für eine '.guix-authorizations'-Datei.

(authorizations
 (version 0)               ;aktuelle Version des Dateiformats

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alice"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "bob"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "charlie"))))

Auf jeden Fingerabdruck folgen optional Schlüssel-/Wert-Paare wie im obigen Beispiel. Derzeit werden diese Schlüssel-/Wert-Paare ignoriert.

Diese Authentifizierungsregel hat ein Henne-Ei-Problem zur Folge: Wie authentifizieren wir den ersten Commit? Und damit zusammenhängend: Was tun wir, wenn die Historie eines Kanal-Repositorys nicht signierte Commits enthält und eine .guix-authorizations-Datei fehlt? Und wie legen wir eine Abspaltung („Fork“) existierender Kanäle an?

Kanaleinführungen beantworten diese Fragen, indem sie den ersten Commit eines Kanals angeben, der authentifiziert werden soll. Das erste Mal, wenn ein Kanal durch guix pull oder guix time-machine geladen wird, wird nachgeschaut, was der einführende Commit ist und ob er mit dem angegebenen OpenPGP-Schlüssel signiert wurde. Von da an werden Commits gemäß obiger Regel authentifiziert. Damit die Authentifizierung erfolgreich ist, muss der Ziel-Commit entweder Nachkomme oder Vorgänger des einführenden Commits sein.

Außerdem muss Ihr Kanal alle OpenPGP-Schlüssel zur Verfügung stellen, die jemals in .guix-authorizations erwähnt wurden, gespeichert in Form von .key-Dateien, entweder als Binärdateien oder mit „ASCII-Hülle“. Nach Vorgabe wird nach diesen .key-Dateien im Branch namens keyring gesucht, aber Sie können wie hier einen anderen Branchnamen in .guix-channel angeben:

(channel
  (version 0)
  (keyring-reference "my-keyring-branch"))

Zusammenfassen haben Kanalautoren drei Dinge zu tun, damit Nutzer deren Code authentifizieren können:

1. Exportieren Sie die OpenPGP-Schlüssel früherer und aktueller Committer mittels gpg --export und speichern Sie sie in .key-Dateien, nach Vorgabe gespeichert in einem Branch namens keyring (wir empfehlen, dass Sie diesen als einen verwaisten Branch, d.h. einen „Orphan Branch“, anlegen).
2. Sie müssen eine anfängliche .guix-authorizations-Datei im Kanalrepository platzieren. Der Commit dazu muss signiert sein (siehe Commit-Zugriff für Informationen, wie Sie Git-Commits signieren).
3. Sie müssen veröffentlichen, wie die Kanaleinführung aussieht, zum Beispiel auf der Webseite des Kanals. Die Kanaleinführung besteht, wie wir oben gesehen haben, aus einem Paar aus Commit und Schlüssel – für denjenigen Commit, der .guix-authorizations hinzugefügt hat, mit dem Fingerabdruck des OpenPGP-Schlüssels, mit dem er signiert wurde.

Bevor Sie auf Ihr öffentliches Git-Repository pushen, können Sie guix git authenticate ausführen, um zu überprüfen, dass Sie alle Commits, die Sie pushen würden, mit einem autorisierten Schlüssel signiert haben:

guix git authenticate Commit Unterzeichner

Dabei sind Commit und Unterzeichner Ihre Kanaleinführung. Siehe guix git authenticate aufrufen für die Details.

Um einen signierten Kanal anzubieten, ist Disziplin vonnöten: Jeder Fehler, wie z.B. ein unsignierter Commit oder ein mit einem unautorisierten Schlüssel signierter Commit, verhindert, das Nutzer den Kanal benutzen können – naja, das ist ja auch der Zweck der Authentifizierung! Passen Sie besonders bei Merges auf: Merge-Commits werden dann und nur dann als authentisch angesehen, wenn sie mit einem Schlüssel aus der .guix-authorizations-Datei beider Branches signiert wurden.

6.11 Primäre URL

Kanalautoren können die primäre URL des Git-Repositorys ihres Kanals in der Datei .guix-channel hinterlegen, etwa so:

(channel
  (version 0)
  (url "https://example.org/guix.git"))

Dadurch kann der Befehl guix pull feststellen, ob er Code von einem Spiegelserver des Kanals lädt. In diesem Fall wird der Benutzer davor gewarnt, dass Spiegelserver veraltete Versionen anbieten könnten, und die eigentliche, primäre URL anzeigen. Auf diese Weise wird verhindert, dass Nutzer manipuliert werden, Code von einem veralteten Spiegelserver zu benutzen, der keine Sicherheitsaktualisierungen bekommt.

Diese Funktionalität ergibt nur bei authentifizierbaren Repositorys Sinn, wie zum Beispiel dem offiziellen guix-Kanal, für den guix pull sicherstellt, dass geladener Code authentisch ist.

6.12 Kanalneuigkeiten verfassen

Kanalautoren möchten ihren Nutzern vielleicht manchmal Informationen über wichtige Änderungen im Kanal zukommen lassen. Man könnte allen eine E-Mail schicken, aber das wäre unbequem.

Stattdessen können Kanäle eine Datei mit Neuigkeiten („News File“) anbieten: Wenn die Kanalnutzer guix pull ausführen, wird diese Datei automatisch ausgelesen. Mit guix pull --news kann man sich die Ankündigungen anzeigen lassen, die den neu gepullten Commits entsprechen, falls es welche gibt.

Dazu müssen Kanalautoren zunächst den Namen der Datei mit Neuigkeiten in der Datei .guix-channel nennen:

(channel
  (version 0)
  (news-file "etc/news.txt"))

Die Datei mit Neuigkeiten, etc/news.txt in diesem Beispiel, muss selbst etwa so aussehen:

(channel-news
  (version 0)
  (entry (tag "the-bug-fix")
         (title (en "Fixed terrible bug")
                (fr "Oh la la"))
         (body (en "@emph{Good news}!  It's fixed!")
               (eo "Certe ĝi pli bone funkcias nun!")))
  (entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
         (title (en "Added a great package")
                (ca "Què vol dir guix?"))
         (body (en "Don't miss the @code{hello} package!"))))

Obwohl die Datei für Neuigkeiten Scheme-Syntax verwendet, sollten Sie ihr keinen Dateinamen mit der Endung .scm geben, sonst wird sie bei der Erstellung des Kanals miteinbezogen und dann zu einem Fehler führen, weil es sich bei ihr um kein gültiges Modul handelt. Alternativ können Sie auch das Kanalmodul in einem Unterverzeichnis platzieren und die Datei für Neuigkeiten in einem Verzeichnis außerhalb platzieren.

Die Datei setzt sich aus einer Liste von Einträgen mit Neuigkeiten („News Entries“) zusammen. Jeder Eintrag ist mit einem Commit oder einem Git-Tag assoziiert und beschreibt die Änderungen, die in diesem oder auch vorangehenden Commits gemacht wurden. Benutzer sehen die Einträge nur beim erstmaligen Übernehmen des Commits, auf den sich der jeweilige Eintrag bezieht.

Das title-Feld sollte eine einzeilige Zusammenfassung sein, während body beliebig lang sein kann. Beide können Texinfo-Auszeichnungen enthalten (siehe Overview in GNU Texinfo). Sowohl title als auch body sind dabei eine Liste aus Tupeln mit jeweils Sprachcode und Mitteilung, wodurch guix pull Neuigkeiten in derjenigen Sprache anzeigen kann, die der vom Nutzer eingestellten Locale entspricht.

Wenn Sie Neuigkeiten mit einem gettext-basierten Arbeitsablauf übersetzen möchten, können Sie übersetzbare Zeichenketten mit xgettext extrahieren (siehe xgettext Invocation in GNU Gettext Utilities). Unter der Annahme, dass Sie Einträge zu Neuigkeiten zunächst auf Englisch verfassen, können Sie mit diesem Befehl eine PO-Datei erzeugen, die die zu übersetzenden Zeichenketten enthält:

xgettext -o news.po -l scheme -ken etc/news.txt

Kurz gesagt, ja, Sie können Ihren Kanal sogar als Blog missbrauchen. Aber das ist nicht ganz, was Ihre Nutzer erwarten dürften.

7.1 guix shell aufrufen

Der Zweck von guix shell ist, dass Sie Software-Umgebungen für außergewöhnliche Fälle einfach aufsetzen können, ohne dass Sie Ihr Profil ändern müssen. Normalerweise braucht man so etwas für Entwicklungsumgebungen, aber auch wenn Sie Anwendungen ausführen wollen, ohne Ihr Profil mit ihnen zu verunreinigen.

Anmerkung: Der Befehl guix shell wurde erst kürzlich eingeführt als Neuauflage von guix environment (siehe guix environment aufrufen). Wenn Sie mit guix environment vertraut sind, werden Sie die Ähnlichkeit bemerken, aber wir hoffen, der neue Befehl erweist sich als praktischer.

Die allgemeine Syntax lautet:

guix shell [Optionen] [Pakete…]

Folgendes Beispiel zeigt, wie Sie eine Umgebung erzeugen lassen, die Python und NumPy enthält, – jedes dazu fehlende Paket wird erstellt oder heruntergeladen –, und in der Umgebung dann python3 ausführen.

guix shell python python-numpy -- python3

Wir betonen, dass Sie auch das zu Grunde liegende python-Paket in dem Befehl angeben müssen, sogar wenn Python schon in Ihre Umgebung installiert ist. Das bewirkt, dass in der Shell-Umgebung PYTHONPATH und andere zugehörige Variable gesetzt werden können. Die Shell-Umgebung kann dafür nicht darauf zurückgreifen, was vorher in der Umgebung installiert war, weil es nichtdeterministisch wäre. Das gilt für die meisten Bibliotheken: Auch das zu deren Programmiersprache gehörige Paket muss im Shell-Aufruf angegeben werden.

Anmerkung: guix shell kann auch als Skript-Interpretierer dienen; man spricht auch von einem Shebang. Hier ist ein Beispiel, wie es in einem eigenständigen Python-Skript benutzt werden kann:

#!/usr/bin/env -S guix shell python python-numpy -- python3
import numpy
print("Hier spricht numpy", numpy.version.version)

Sie können beliebige Befehlszeilenoptionen auf diese Weise an guix shell übergeben, doch beachten Sie: Der Linux-Kernel beschränkt die Länge eines Shebangs auf maximal 127 Bytes.

Entwicklungsumgebungen erzeugen Sie wie im folgenden Beispiel, wo eine interaktive Shell gestartet wird, in der alle Abhängigkeiten und Variable vorliegen, die zur Arbeit an Inkscape nötig sind:

guix shell --development inkscape

Sobald er die Shell beendet, findet sich der Benutzer in der ursprünglichen Umgebung wieder, in der er sich vor dem Aufruf von guix shell befand. Beim nächsten Durchlauf des Müllsammlers (siehe guix gc aufrufen) dürfen Pakete von der Platte gelöscht werden, die innerhalb der Umgebung installiert worden sind und außerhalb nicht länger benutzt werden.

Um die Nutzung zu vereinfachen, wird guix shell, wenn Sie es interaktiv ohne Befehlszeilenargumente aufrufen, das bewirken, was es dann vermutlich soll. Also:

guix shell

Wenn im aktuellen Arbeitsverzeichnis oder irgendeinem übergeordneten Verzeichnis eine Datei manifest.scm vorkommt, wird sie so behandelt, als hätten Sie sie mit --manifest übergeben. Ebenso wird mit einer Datei guix.scm, wenn sie in selbigen Verzeichnissen enthalten ist, eine Entwicklungsumgebung hergestellt, als wären --development und --file beide angegeben worden. So oder so wird die jeweilige Datei nur dann geladen, wenn das Verzeichnis, in dem sie steckt, in ~/.config/guix/shell-authorized-directories aufgeführt ist. Damit lassen sich Entwicklungsumgebungen leicht definieren, teilen und betreten.

Vorgegeben ist, dass für die Shell-Sitzung bzw. den Befehl eine ergänzte Umgebung aufgebaut wird, in der die neuen Pakete zu Suchpfad-Umgebungsvariablen wie PATH hinzugefügt werden. Sie können stattdessen auch beschließen, eine isolierte Umgebung anzufordern mit nichts als den Paketen, die Sie angegeben haben. Wenn Sie die Befehlszeilenoption --pure angeben, werden alle Definitionen von Umgebungsvariablen aus der Elternumgebung gelöscht¹⁴. Wenn Sie --container angeben, wird die Shell darüber hinaus in einem Container vom restlichen System isoliert:

guix shell --container emacs gcc-toolchain

Dieser Befehl startet eine interaktive Shell in einem Container, der den Zugriff auf alles außer emacs, gcc-toolchain und deren Abhängigkeiten unterbindet. Im Container haben Sie keinen Netzwerkzugriff und es werden außer dem aktuellen Arbeitsverzeichnis keine Dateien mit der äußeren Umgebung geteilt. Das dient dazu, den Zugriff auf systemweite Ressourcen zu verhindern, wie /usr/bin auf Fremddistributionen.

Diese --container-Befehlszeilenoption kann sich aber auch als nützlich erweisen, um Anwendungen mit hohem Sicherheitsrisiko wie z.B. Webbrowser in eine isolierte Umgebung eingesperrt auszuführen. Folgender Befehl startet zum Beispiel Ungoogled-Chromium in einer isolierten Umgebung, für die gilt:

• Netzwerkzugriff des Wirtssystems wird geteilt
• Umgebungsvariable DISPLAY und XAUTHORITY bleiben erhalten
• hat Zugriff auf Wirts-Autorisierungsinformationen für XAUTHORITY file
• das aktuelle Arbeitsverzeichnis des Wirts ist unbekannt

guix shell --container --network --no-cwd ungoogled-chromium \
  --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \
  --preserve='^DISPLAY$' -- chromium

guix shell definiert die Variable GUIX_ENVIRONMENT in der neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer .bashrc festzulegen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

… oder um ihr Profil durchzusehen:

$ ls "$GUIX_ENVIRONMENT/bin"

Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.

--check

Hiermit wird die Umgebung angelegt und gemeldet, ob die Shell Umgebungsvariable überschreiben würde. Es ist eine gute Idee, diese Befehlszeilenoption anzugeben, wenn Sie zum ersten Mal guix shell zum Starten einer interaktiven Sitzung einsetzen, um sicherzugehen, dass Ihre Shell richtig eingestellt ist.

Wenn die Shell zum Beispiel den Wert der Umgebungsvariablen PATH ändert, meldet dies --check, weil Sie dadurch nicht die Umgebung bekämen, die Sie angefordert haben.

In der Regel sind solche Probleme ein Zeichen dafür, dass Dateien, die beim Start der Shell geladen werden, die Umgebungsvariablen unerwartet verändern. Wenn Sie zum Beispiel Bash benutzen, vergewissern Sie sich, dass Umgebungsvariable in ~/.bash_profile festgelegt oder geändert werden, nicht in ~/.bashrc – erstere Datei wird nur von Login-Shells mit „source“ geladen. Siehe Bash Startup Files in Referenzhandbuch zu GNU Bash für Details über beim Starten von Bash gelesene Dateien.

--development

-D

Lässt guix shell die Abhängigkeiten des danach angegebenen Pakets anstelle des Pakets in die Umgebung aufnehmen. Es kann mit anderen Paketen kombiniert werden. Zum Beispiel wird mit folgendem Befehl eine interaktive Shell gestartet, die die zum Erstellen nötigen Abhängigkeiten von GNU Guile sowie Autoconf, Automake und Libtool enthält:

guix shell -D guile autoconf automake libtool

--expression=Ausdruck

-e Ausdruck

Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der Ausdruck ausgewertet wird.

Zum Beispiel startet dies:

guix shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc.

Wenn man dies ausführt:

guix shell -e '(@ (gnu) %base-packages)'

bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind.

Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden:

guix shell -e '(list (@ (gnu packages bash) bash) "include")'

Siehe package->development-manifest, für Informationen, wie Sie die Entwicklungsumgebung für ein Paket in einem Manifest wiedergeben.

--file=Datei

-f Datei

Eine Umgebung erstellen mit dem Paket oder der Liste von Paketen, zu der der Code in der Datei ausgewertet wird.

Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

Mit so einer Datei können Sie eine Entwicklungsumgebung für GDB betreten, indem Sie dies ausführen:

guix shell -D -f gdb-devel.scm

--manifest=Datei

-m Datei

Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.

Dies verhält sich ähnlich wie die gleichnamige Option des Befehls guix package (siehe --manifest) und benutzt auch dieselben Manifestdateien.

Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest schreibt. Siehe --export-manifest im folgenden Text, um zu erfahren, wie Sie ein erstes Manifest erhalten.

--export-manifest

Auf die Standardausgabe ein Manifest ausgeben, das mit --manifest genutzt werden kann und den angegebenen Befehlszeilenoptionen entspricht.

Auf diese Weise können Sie die Argumente der Befehlszeile in eine Manifestdatei verwandeln. Nehmen wir an, Sie wären es leid, lange Befehlszeilen abzutippen, und hätten stattdessen lieber ein gleichbedeutendes Manifest:

guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

Fügen Sie einfach --export-manifest zu der obigen Befehlszeile hinzu:

guix shell --export-manifest \
  -D guile git emacs emacs-geiser emacs-geiser-guile

… und schon sehen Sie ein Manifest, was so ähnlich aussieht:

(concatenate-manifests
  (list (specifications->manifest
          (list "git"
                "emacs"
                "emacs-geiser"
                "emacs-geiser-guile"))
        (package->development-manifest
          (specification->package "guile"))))

Diese Ausgabe können Sie in einer Datei speichern, nennen wir sie manifest.scm, die Sie dann an guix shell oder so ziemlich jeden beliebigen guix-Befehl übergeben:

guix shell -m manifest.scm

Na bitte. Aus der langen Befehlszeile ist ein Manifest geworden! Beim Verwandlungsvorgang werden Paketumwandlungsoptionen berücksichtigt (siehe Paketumwandlungsoptionen), d.h. er sollte verlustfrei sein.

--profile=Profil

-p Profil

Eine Umgebung mit den Paketen erzeugen, die im Profil installiert sind. Benutzen Sie guix package (siehe guix package aufrufen), um Profile anzulegen und zu verwalten.

--pure

Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit --preserve angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts.

--preserve=Regexp

-E Regexp

Wenn das hier zusammen mit --pure angegeben wird, bleiben die zum regulären Ausdruck Regexp passenden Umgebungsvariablen erhalten – mit anderen Worten werden sie auf eine „weiße Liste“ von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden.

guix shell --pure --preserve=^SLURM openmpi … \
  -- mpirun …

In diesem Beispiel wird mpirun in einem Kontext ausgeführt, in dem die einzig definierten Umgebungsvariablen PATH und solche sind, deren Name mit ‘SLURM’ beginnt, sowie die üblichen besonders „kostbaren“ Variablen (HOME, USER, etc.).

--search-paths

Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.

--system=System

-s System

Versuchen, für das angegebene System zu erstellen – z.B. i686-linux.

--container ¶

-C

Den Befehl in einer isolierten Umgebung (einem sogenannten „Container“) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption --user nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei /etc/passwd.

Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption --user wird übergeben (siehe unten).

--network

-N

Bei isolierten Umgebungen („Containern“) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät.

--link-profile

-P

Bei isolierten Umgebungen („Containern“) wird das Umgebungsprofil im Container als ~/.guix-profile verknüpft und ~/.guix-profile dann in GUIX_ENVIRONMENT gespeichert. Das ist äquivalent dazu, ~/.guix-profile im Container zu einer symbolischen Verknüpfung auf das tatsächliche Profil zu machen. Wenn das Verzeichnis bereits existiert, schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser Fehler wird immer eintreten, wenn guix shell im persönlichen Verzeichnis des Benutzers aufgerufen wurde.

Bestimmte Pakete sind so eingerichtet, dass sie in ~/.guix-profile nach Konfigurationsdateien und Daten suchen,¹⁵ weshalb --link-profile benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten.

--user=Benutzer

-u Benutzer

Bei isolierten Umgebungen („Containern“) wird der Benutzername Benutzer anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in /etc/passwd im Container wird also den Namen Benutzer enthalten und das persönliche Verzeichnis wird den Namen /home/BENUTZER tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. Benutzer muss auf dem System nicht existieren.

Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils --share und --expose), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu /home/BENUTZER erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses.

# wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren
cd $HOME/wd
guix shell --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Datenschutz und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden.

--no-cwd

In isolierten Umgebungen („Containern“) ist das vorgegebene Verhalten, das aktuelle Arbeitsverzeichnis mit dem isolierten Container zu teilen und in der Umgebung sofort in dieses Verzeichnis zu wechseln. Wenn das nicht gewünscht wird, kann das Angeben von --no-cwd dafür sorgen, dass das Arbeitsverzeichnis nicht automatisch geteilt wird und stattdessen in das Persönliche Verzeichnis („Home“-Verzeichnis) gewechselt wird. Siehe auch --user.

--expose=Quelle[=Ziel]

--share=Quelle[=Ziel]

Bei isolierten Umgebungen („Containern“) wird das Dateisystem unter Quelle vom Wirtssystem als Nur-Lese-Dateisystem Ziel (bzw. für --share auch mit Schreibrechten) im Container zugänglich gemacht. Wenn kein Ziel angegeben wurde, wird die Quelle auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt.

Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis /austausch nur für Lesezugriffe zugänglich gemacht wurde:

guix shell --container --expose=$HOME=/austausch guile -- guile

--symlink=Spezifikation

-S Spezifikation

Für Container werden hiermit die in der Spezifikation angegebenen symbolischen Verknüpfungen hergestellt. Siehe die Dokumentation in pack-symlink-option.

--emulate-fhs

-F

Wenn Sie dies zusammen mit --container angeben, wird im Container eine Konfiguration emuliert, die dem Filesystem Hierarchy Standard (FHS) folgt, so dass es /bin, /lib und weitere Verzeichnisse gibt, wie es der FHS vorschreibt.

Obwohl Guix vom FHS-Standard abweicht, kann das System in Ihrem Container mit dieser Befehlszeilenoption zu anderen GNU/Linux-Distributionen ähnlicher werden. Dadurch lassen sich dortige Entwicklungsumgebungen reproduzieren und Sie können Programme testen und benutzen, die das Befolgen des FHS-Standards voraussetzen. Wenn die Option angegeben wird, enthält der Container eine Version von glibc, die die im Container befindliche /etc/ld.so.cache als Zwischenspeicher gemeinsamer Bibliotheken ausliest (anders als glibc im normalen Gebrauch von Guix), und die im FHS verlangten Verzeichnisse /bin, /etc, /lib und /usr werden aus dem Profil des Containers übernommen.

--nesting

-W

Wenn Sie dies zusammen mit --container angeben, wird Guix im Container verfügbar gemacht, so dass man sich von innerhalb mit dem Erstellungs-Daemon verbinden kann, der außerhalb des Containers läuft. Das können Sie gebrauchen, wenn Sie vom isolierten Container aus wiederum andere Container erzeugen lassen können wollen wie in dieser Beispielsitzung:

$ guix shell -CW coreutils
[env]$ guix shell -C guile -- guile -c '(display "Hallo!\n")'
Hallo!
[env]$ exit

In der Sitzung wird ein Container gestartet, in dem die coreutils-Programme in PATH zur Verfügung stehen. Von da aus legen wir mit guix shell einen inneren, verschachtelten Container an, der außer Guile nichts verfügbar macht.

Ein weiteres Anwendungsbeispiel ist, wenn Sie eine guix.scm auswerten möchten, der Sie nicht vertrauen, wie hier:

guix shell -CW -- guix build -f guix.scm

Durch einen so durchgeführten Befehl guix build sind nur Zugriffe auf Ihr aktuelles Arbeitsverzeichnis möglich.

Intern werden für die Befehlszeilenoption -W mehrere Einstellungen vorgenommen:

• Der Socket für den Daemon (in der Vorgabeeinstellung ist das /var/guix/daemon-socket/socket) wird im Container verfügbar gemacht.
• Der gesamte Store (in der Vorgabeeinstellung ist das /gnu/store) wird im Container verfügbar gemacht, damit auf Store-Objekte von verschachtelten guix-Aufrufen zugegriffen werden kann.
• Der aktuell benutzte guix-Befehl wird zum Profil innerhalb des Containers hinzugefügt, so dass guix describe innerhalb und außerhalb des Containers den gleichen Zustand ausgibt.
• Der Zwischenspeicher (in der Vorgabeeinstellung ist das ~/.cache/guix) des Wirtssystems wird mit Schreibzugriff zugänglich gemacht. Dadurch können Befehle wie guix time-machine und guix shell effizient ablaufen.

--rebuild-cache ¶

In der Regel wird guix shell die Umgebung zwischenspeichern, damit weitere Aufrufe sie ohne Verzögerung verwenden können. Am längsten nicht verwendete („least recently used“) Einträge im Zwischenspeicher werden bei guix shell regelmäßig entfernt. Auch wenn Sie --file oder --manifest nutzen, wird der Zwischenspeicher ungültig, sobald die entsprechende Datei geändert wurde.

Mit der Befehlszeilenoption --rebuild-cache wird die zwischengespeicherte Umgebung erneuert. Sie können --rebuild-cache verwenden, wenn Sie --file oder --manifest nutzen und die Datei guix.scm oder manifest.scm auf externe Abhängigkeiten verweist oder eine andere Umgebung ergeben sollte, wenn sich zum Beispiel Umgebungsvariable geändert haben.

--root=Datei ¶

-r Datei

Die Datei zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren.

Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie „persistent“ zu machen.

Wenn diese Option weggelassen wird, wird das Profil von guix shell zwischengespeichert, damit weitere Aufrufe es ohne Verzögerung verwenden können. Das ist vergleichbar damit, wenn Sie --root angeben, jedoch wird guix shell die am längsten nicht verwendeten Müllsammlerwurzeln („least recently used“) regelmäßig entfernt.

In manchen Fällen wird guix shell keinen Zwischenspeicher für die Profile anlegen, z.B. wenn Umwandlungsoptionen wie --with-latest angegeben wurde. Das bedeutet, die Umgebung ist nur, solange die Sitzung von guix shell besteht, vor dem Müllsammler sicher. Dann müssen Sie, wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, vielleicht Pakete neu erstellen oder neu herunterladen.

guix gc aufrufen hat mehr Informationen über Müllsammlerwurzeln.

guix shell unterstützt auch alle gemeinsamen Erstellungsoptionen, die von guix build unterstützt werden (siehe Gemeinsame Erstellungsoptionen), und die Paketumwandlungsoptionen (siehe Paketumwandlungsoptionen).

7.2 guix environment aufrufen

Der Zweck von guix environment ist es, dass Sie Entwicklungsumgebungen leicht anlegen können.

Diese Funktionalität wird demnächst verschwinden: Der Befehl guix environment gilt als veraltet. Stattdessen sollten Sie guix shell benutzen, was einen ähnlichen Zweck erfüllt, aber leichter zu benutzen ist. Siehe guix shell aufrufen.

Veraltet heißt, guix environment wird letztendlich entfernt, aber das Guix-Projekt wird gewährleisten, dass guix environment bis zum 1. Mai 2023 verfügbar bleibt. Reden Sie mit uns unter guix-devel@gnu.org, wenn Sie dabei mitdiskutieren möchten!

Die allgemeine Syntax lautet:

guix environment Optionen Paket…

Folgendes Beispiel zeigt, wie eine neue Shell gestartet wird, auf der alles für die Entwicklung von GNU Guile eingerichtet ist:

guix environment guile

Wenn benötigte Abhängigkeiten noch nicht erstellt worden sind, wird guix environment sie automatisch erstellen lassen. Die Umgebung der neuen Shell ist eine ergänzte Version der Umgebung, in der guix environment ausgeführt wurde. Sie enthält neben den existierenden Umgebungsvariablen auch die nötigen Suchpfade, um das angegebene Paket erstellen zu können. Um eine „reine“ Umgebung zu erstellen, in der die ursprünglichen Umgebungsvariablen nicht mehr vorkommen, kann die Befehlszeilenoption --pure benutzt werden¹⁶.

Eine Guix-Umgebung zu verlassen ist gleichbedeutend mit dem Verlassen der Shell; danach findet sich der Benutzer in der alten Umgebung wieder, in der er sich vor dem Aufruf von guix environment befand. Beim nächsten Durchlauf des Müllsammlers (siehe guix gc aufrufen) werden Pakete von der Platte gelöscht, die innerhalb der Umgebung installiert worden sind und außerhalb nicht länger benutzt werden.

guix environment definiert die Variable GUIX_ENVIRONMENT in der neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer .bashrc festzulegen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

… oder um ihr Profil durchzusehen:

$ ls "$GUIX_ENVIRONMENT/bin"

Des Weiteren kann mehr als ein Paket angegeben werden. In diesem Fall wird die Vereinigung der Eingaben der jeweiligen Pakete zugänglich gemacht. Zum Beispiel erzeugt der folgende Befehl eine Shell, in der alle Abhängigkeiten von sowohl Guile als auch Emacs verfügbar sind:

guix environment guile emacs

Manchmal will man keine interaktive Shell-Sitzung. Ein beliebiger Befehl kann aufgerufen werden, indem Sie nach Angabe der Pakete noch -- vor den gewünschten Befehl schreiben, um ihn von den übrigen Argumenten abzutrennen:

guix environment guile -- make -j4

In anderen Situationen ist es bequemer, aufzulisten, welche Pakete in der Umgebung benötigt werden. Zum Beispiel führt der folgende Befehl python aus einer Umgebung heraus aus, in der Python 3 und NumPy enthalten sind:

guix environment --ad-hoc python-numpy python -- python3

Man kann auch sowohl die Abhängigkeiten eines Pakets haben wollen als auch ein paar zusätzliche Pakete, die nicht Erstellungs- oder Laufzeitabhängigkeiten davon sind, aber trotzdem bei der Entwicklung nützlich sind. Deshalb hängt die Wirkung von der Position der Befehlszeilenoption --ad-hoc ab. Pakete, die links von --ad-hoc stehen, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden. Pakete, die rechts stehen, werden selbst zur Umgebung hinzugefügt. Zum Beispiel erzeugt der folgende Befehl eine Guix-Entwicklungsumgebung, die zusätzlich Git und strace umfasst:

guix environment --pure guix --ad-hoc git strace

Manchmal ist es wünschenswert, die Umgebung so viel wie möglich zu isolieren, um maximale Reinheit und Reproduzierbarkeit zu bekommen. Insbesondere ist es wünschenswert, den Zugriff auf /usr/bin und andere Systemressourcen aus der Entwicklungsumgebung heraus zu verhindern, wenn man Guix auf einer fremden Wirtsdistribution benutzt, die nicht Guix System ist. Zum Beispiel startet der folgende Befehl eine Guile-REPL in einer isolierten Umgebung, einem sogenannten „Container“, in der nur der Store und das aktuelle Arbeitsverzeichnis eingebunden sind:

guix environment --ad-hoc --container guile -- guile

Anmerkung: Die Befehlszeilenoption --container funktioniert nur mit Linux-libre 3.19 oder neuer.

Ein weiterer typischer Anwendungsfall für Container ist, gegenüber Sicherheitslücken anfällige Anwendungen auszuführen, z.B. Webbrowser. Um Eolie auszuführen, müssen wir den Zugriff auf manche Dateien und Verzeichnisse über --expose und --share gewähren. Wir lassen nss-certs bereitstellen und machen /etc/ssl/certs/ für die HTTPS-Authentifizierung sichtbar. Zu guter Letzt behalten wir die DISPLAY-Umgebungsvariable bei, weil isolierte grafische Anwendungen ohne sie nicht angezeigt werden können.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.

--check

Hiermit wird die Umgebung angelegt und gemeldet, ob die Shell Umgebungsvariable überschreiben würde. Siehe --check für weitere Informationen.

--root=Datei ¶

-r Datei

Die Datei zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren.

Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie „persistent“ zu machen.

Wird diese Option weggelassen, ist die Umgebung nur, solange die Sitzung von guix environment besteht, vor dem Müllsammler sicher. Das bedeutet, wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, müssen Sie vielleicht Pakete neu erstellen oder neu herunterladen. guix gc aufrufen hat mehr Informationen über Müllsammlerwurzeln.

--expression=Ausdruck

-e Ausdruck

Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der Ausdruck ausgewertet wird.

Zum Beispiel startet dies:

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc.

Wenn man dies ausführt:

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind.

Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden:

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=Datei

-l Datei

Eine Umgebung erstellen für das Paket oder die Liste von Paketen, zu der der Code in der Datei ausgewertet wird.

Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

--manifest=Datei

-m Datei

Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.

Dies verhält sich ähnlich wie die gleichnamige Option des Befehls guix package (siehe --manifest) und benutzt auch dieselben Manifestdateien.

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

--ad-hoc

Alle angegebenen Pakete in der resultierenden Umgebung einschließen, als wären sie Eingaben eines ad hoc definierten Pakets. Diese Befehlszeilenoption ist nützlich, um schnell Umgebungen aufzusetzen, ohne dafür einen Paketausdruck schreiben zu müssen, der die gewünschten Eingaben enthält.

Zum Beispiel wird mit diesem Befehl:

guix environment --ad-hoc guile guile-sdl -- guile

guile in einer Umgebung ausgeführt, in der sowohl Guile als auch Guile-SDL zur Verfügung stehen.

Beachten Sie, dass in diesem Beispiel implizit die vorgegebene Ausgabe von guile und guile-sdl verwendet wird, es aber auch möglich ist, eine bestimmte Ausgabe auszuwählen – z.B. wird mit glib:bin die Ausgabe bin von glib gewählt (siehe Pakete mit mehreren Ausgaben.).

Diese Befehlszeilenoption kann mit dem standardmäßigen Verhalten von guix environment verbunden werden. Pakete, die vor --ad-hoc aufgeführt werden, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden, was dem standardmäßigen Verhalten entspricht. Pakete, die danach aufgeführt werden, werden selbst zur Umgebung hinzugefügt.

--profile=Profil

-p Profil

Eine Umgebung mit den Paketen erzeugen, die im Profil installiert sind. Benutzen Sie guix package (siehe guix package aufrufen), um Profile anzulegen und zu verwalten.

--pure

Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit --preserve angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts.

--preserve=Regexp

-E Regexp

Wenn das hier zusammen mit --pure angegeben wird, bleiben die zum regulären Ausdruck Regexp passenden Umgebungsvariablen erhalten – mit anderen Worten werden sie auf eine „weiße Liste“ von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

In diesem Beispiel wird mpirun in einem Kontext ausgeführt, in dem die einzig definierten Umgebungsvariablen PATH und solche sind, deren Name mit ‘SLURM’ beginnt, sowie die üblichen besonders „kostbaren“ Variablen (HOME, USER, etc.).

--search-paths

Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.

--system=System

-s System

Versuchen, für das angegebene System zu erstellen – z.B. i686-linux.

--container ¶

-C

Den Befehl in einer isolierten Umgebung (einem sogenannten „Container“) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption --user nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei /etc/passwd.

Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption --user wird übergeben (siehe unten).

--network

-N

Bei isolierten Umgebungen („Containern“) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät.

--link-profile

-P

Bei isolierten Umgebungen („Containern“) wird das Umgebungsprofil im Container als ~/.guix-profile verknüpft und ~/.guix-profile dann in GUIX_ENVIRONMENT gespeichert. Das ist äquivalent dazu, ~/.guix-profile im Container zu einer symbolischen Verknüpfung auf das tatsächliche Profil zu machen. Wenn das Verzeichnis bereits existiert, schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser Fehler wird immer eintreten, wenn guix environment im persönlichen Verzeichnis des Benutzers aufgerufen wurde.

Bestimmte Pakete sind so eingerichtet, dass sie in ~/.guix-profile nach Konfigurationsdateien und Daten suchen,¹⁷ weshalb --link-profile benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten.

--user=Benutzer

-u Benutzer

Bei isolierten Umgebungen („Containern“) wird der Benutzername Benutzer anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in /etc/passwd im Container wird also den Namen Benutzer enthalten und das persönliche Verzeichnis wird den Namen /home/BENUTZER tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. Benutzer muss auf dem System nicht existieren.

Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils --share und --expose), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu /home/BENUTZER erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses.

# wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren
cd $HOME/wd
guix environment --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Datenschutz und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden.

--no-cwd

In isolierten Umgebungen („Containern“) ist das vorgegebene Verhalten, das aktuelle Arbeitsverzeichnis mit dem isolierten Container zu teilen und in der Umgebung sofort in dieses Verzeichnis zu wechseln. Wenn das nicht gewünscht wird, kann das Angeben von --no-cwd dafür sorgen, dass das Arbeitsverzeichnis nicht automatisch geteilt wird und stattdessen in das Persönliche Verzeichnis („Home“-Verzeichnis) gewechselt wird. Siehe auch --user.

--expose=Quelle[=Ziel]

--share=Quelle[=Ziel]

Bei isolierten Umgebungen („Containern“) wird das Dateisystem unter Quelle vom Wirtssystem als Nur-Lese-Dateisystem Ziel (bzw. für --share auch mit Schreibrechten) im Container zugänglich gemacht. Wenn kein Ziel angegeben wurde, wird die Quelle auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt.

Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis /austausch nur für Lesezugriffe zugänglich gemacht wurde:

guix environment --container --expose=$HOME=/austausch --ad-hoc guile -- guile

--emulate-fhs

-F

In Containern wird eine Konfiguration emuliert, die dem Filesystem Hierarchy Standard (FHS) folgt, siehe dessen offizielle Spezifikation. Obwohl Guix vom FHS-Standard abweicht, kann das System in Ihrem Container mit dieser Befehlszeilenoption zu anderen GNU/Linux-Distributionen ähnlicher werden. Dadurch lassen sich dortige Entwicklungsumgebungen reproduzieren und Sie können Programme testen und benutzen, die das Befolgen des FHS-Standards voraussetzen. Wenn die Option angegeben wird, enthält der Container eine Version von glibc, die die im Container befindliche /etc/ld.so.cache als Zwischenspeicher gemeinsamer Bibliotheken ausliest (anders als glibc im normalen Gebrauch von Guix), und die im FHS verlangten Verzeichnisse /bin, /etc, /lib und /usr werden aus dem Profil des Containers übernommen.

guix environment unterstützt auch alle gemeinsamen Erstellungsoptionen, die von guix build unterstützt werden (siehe Gemeinsame Erstellungsoptionen), und die Paketumwandlungsoptionen (siehe Paketumwandlungsoptionen).

7.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äß des Standards für Docker-Abbilder. Der „Repository-Name“, wie er in der Ausgabe des Befehls docker images erscheint, wird in der Vorgabeeinstellung anhand der Paketnamen berechnet, die auf der Befehlszeile oder in der Manifest-Datei angegeben wurden. Sie können den Repository-Namen auch über die Befehlszeilenoption --image-tag festlegen. Siehe die Ausgabe mit --help-docker-format für mehr Details zu solchen weitergehenden Optionen.

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. Allerdings dürfen beliebig viele Guix-Pakete Teil dieses einen Archivs sein.

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.

rpm ¶

Hiermit wird ein RPM-Archiv erzeugt (ein Paket mit der Dateinamenserweiterung „.rpm“), in dem alle angegebenen Binärdateien und symbolischen Verknüpfungen enthalten sind. Es kann auf jeder RPM-basierten GNU/Linux-Distribution installiert werden. Beim RPM-Format werden Prüfsummen zu jeder enthaltenen Datei eingebettet, welche der rpm-Befehl benutzt, um die Integrität des Archivs zu gewährleisten.

Fortgeschrittene RPM-bezogene Befehlszeilenoptionen werden Ihnen angezeigt, wenn Sie die Befehlszeilenoption --help-rpm-format angeben. Mit diesen Befehlszeilenoptionen können Paketbetreuer Skripte einbinden, die zum Beispiel vor oder nach der Installation des RPM-Archivs ablaufen sollen.

Das RPM-Format kennt verschiebbare Pakete. Mit der Befehlszeilenoption --prefix des rpm-Befehls ist es Ihnen möglich, ein RPM-Paket unter ein angegebenes Präfix zu installieren.

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

sudo rpm --install --prefix=/opt /gnu/store/…-hello.rpm

Anmerkung: Anders als bei Debian-Paketen dürfen mehrere RPM-Pakete gleichzeitig installiert werden, wenn Dateien darin im Konflikt stehen, aber identisch sind. Es ist daher in der Regel problemlos möglich, mehrere mit guix pack erzeugte RPM-Pakete nebeneinander zu installieren.

Warnung: rpm übernimmt die Zuständigkeit für alle Dateien, die im Bündel enthalten sind. Folglich wird rpm das Verzeichnis /gnu/store einfach löschen, sobald Sie ein mit Guix erzeugtes RPM-Paket deinstallieren, wenn Sie bei der Installation nicht die Befehlszeilenoption --prefix des rpm-Befehls benutzt haben. Es ist unklug, mit Guix erzeugte „.rpm“-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-rpm-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

--entry-point-argument=Befehl

-A Befehl

Befehl als Argument zum Einsprungpunkt des erzeugten Bündels mitgeben. Diese Befehlszeilenoption wirkt sich nur in Verbindung mit --entry-point aus und sie darf auf der Befehlszeile mehrmals angegeben werden.

guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile

--max-layers=n

Gibt an, auf wie viele Schichten ein Docker-Abbild höchstens aufgeteilt werden soll, wenn das Abbild erzeugt wird.

guix pack -f docker --max-layers=100 guile

Mit dieser Befehlszeilenoption können Sie begrenzen, wie kleinteilig ein Docker-Abbild geschichtet werden soll. Docker-Abbilder können auf mehrere Schichten aufgeteilt werden, wobei das Abbild mit jeder Schicht größer und komplexer wird. Indem Sie die Anzahl Schichten begrenzen, bestimmen Sie, inwieweit folgende Wirkungen erzielt werden sollen:

• Platzverbrauch: Wenn Sie mehr Schichten verwenden, können sich eher mehrere Abbilder gemeinsame Abschnitte ihres Paketgraphen teilen, wenn sich dieser ähnelt.
• Ladezeit: Bei der Übertragung der Abbilder auf andere Knoten oder Systeme müssen Sie bei mehrschichtigen Abbildern in diesem Fall weniger lang warten.

--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).

7.4 GCC-Toolchain

Wenn Sie einen vollständigen Werkzeugsatz zum Kompilieren und Binden von Quellcode in C oder C++ brauchen, werden Sie das Paket gcc-toolchain haben wollen. Das Paket bietet eine vollständige GCC-Toolchain für die Entwicklung mit C/C++, einschließlich GCC selbst, der GNU-C-Bibliothek (Header-Dateien und Binärdateien samt Symbolen zur Fehlersuche/Debugging in der debug-Ausgabe), Binutils und einen Wrapper für den Binder/Linker.

Der Zweck des Wrappers ist, die an den Binder übergebenen Befehlszeilenoptionen mit -L und -l zu überprüfen und jeweils passende Argumente mit -rpath anzufügen, womit dann der echte Binder aufgerufen wird. Standardmäßig weigert sich der Binder-Wrapper, mit Bibliotheken außerhalb des Stores zu binden, um „Reinheit“ zu gewährleisten. Das kann aber stören, wenn man die Toolchain benutzt, um mit lokalen Bibliotheken zu binden. Um Referenzen auf Bibliotheken außerhalb des Stores zu erlauben, müssen Sie die Umgebungsvariable GUIX_LD_WRAPPER_ALLOW_IMPURITIES setzen.

Das Paket gfortran-toolchain stellt eine vollständige GCC-Toolchain für die Entwicklung mit Fortran zur Verfügung. Pakete für die Entwicklung mit anderen Sprachen suchen Sie bitte mit ‘guix search gcc toolchain’ (siehe Invoking guix package).

7.5 guix git authenticate aufrufen

Der Befehl guix git authenticate authentifiziert ein Git-Checkout nach derselben Regel wie für Kanäle (siehe Kanalauthentifizierung). Das bedeutet, dass angefangen beim angegebenen Commit sichergestellt wird, dass alle nachfolgenden Commits mit einem OpenPGP-Schlüssel signiert worden sind, dessen Fingerabdruck in der .guix-authorizations-Datei seines bzw. seiner jeweiligen Elterncommits aufgeführt ist.

Sie werden diesen Befehl zu schätzen wissen, wenn Sie einen Kanal betreuen. Tatsächlich ist dieser Authentifizierungsmechanismus aber auch bei weiteren Dingen nützlich; vielleicht möchten Sie ihn für Git-Repositorys einsetzen, die gar nichts mit Guix zu tun haben?

Die allgemeine Syntax lautet:

guix git authenticate Commit Unterzeichner [Optionen…]

Nach Vorgabe wird mit diesem Befehl das Git-Checkout im aktuellen Arbeitsverzeichnis authentifiziert. Es wird bei Erfolg nichts ausgegeben und der Exit-Status null zurückgeliefert; bei einem Fehler wird ein von null verschiedener Exit-Status zurückgeliefert. Commit gibt den ersten Commit an, der authentifiziert wird, und Unterzeichner ist der OpenPGP-Fingerabdruck des öffentlichen Schlüssels, mit dem der Commit signiert wurde. Zusammen bilden sie eine „Kanaleinführung“ (siehe Kanaleinführung). Bei Ihrer ersten erfolgreichen Ausführung wird die Einführung in der Datei .git/config in Ihrem Checkout gespeichert, so dass Sie sie bei späteren Aufrufen nicht mehr anzugeben brauchen:

guix git authenticate [Optionen…]

Should you have branches that require different introductions, you can specify them directly in .git/config. For example, if the branch called personal-fork has a different introduction than other branches, you can extend .git/config along these lines:

[guix "authentication-personal-fork"]
	introduction-commit = cabba936fd807b096b48283debdcddccfea3900d
	introduction-signer = C0FF EECA BBA9 E6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
	keyring = keyring

The first run also attempts to install pre-push and post-merge hooks, such that guix git authenticate is invoked as soon as you run git push, git pull, and related commands; it does not overwrite preexisting hooks though.

The command-line options described below allow you to fine-tune the process.

--repository=Verzeichnis

-r Verzeichnis

Das Git-Repository im Verzeichnis statt im aktuellen Verzeichnis öffnen.

--keyring=Referenz

-k Referenz

Den OpenPGP-Schlüsselbund („Keyring“) von der angegebenen Referenz laden, einem Verweis auf einen Branch wie origin/keyring oder my-keyring. Der Branch muss öffentliche Schlüssel im OpenPGP-Format in .key-Dateien enthalten, entweder als Binärdateien oder mit „ASCII-Hülle“. Nach Vorgabe wird der Schlüsselbund von einem Branch namens keyring geladen.

--end=Commit

Revisionen bis Commit authentifizieren.

--stats

Nach Abschluss Statistiken über die signierten Commits anzeigen.

--cache-key=Schlüssel

Bereits authentifizierte Commits werden in einer Datei unter ~/.cache/guix/authentication zwischengespeichert. Diese Option erzwingt, dass der Speicher innerhalb dieses Verzeichnisses in der Datei Schlüssel angelegt wird.

--historical-authorizations=Datei

Nach Vorgabe wird jeder Commit, dessen Elterncommit(s) die Datei .guix-authorizations fehlt, als gefälscht angesehen. Mit dieser Option werden dagegen die Autorisierungen in der Datei für jeden Commit ohne .guix-authorizations verwendet. Das Format der Datei ist dasselbe wie bei .guix-authorizations (siehe Format von .guix-authorizations).

8.1 Paketmodule

Aus Programmierersicht werden die Paketdefinitionen der GNU-Distribution als Guile-Module in Namensräumen wie (gnu packages …) sichtbar gemacht¹⁹ (siehe Guile-Module in Referenzhandbuch zu GNU Guile). Zum Beispiel exportiert das Modul (gnu packages emacs) eine Variable namens emacs, die an ein <package>-Objekt gebunden ist (siehe Pakete definieren).

Der Modulnamensraum (gnu packages …) wird von Befehlszeilenwerkzeugen automatisch nach Paketen durchsucht. Wenn Sie zum Beispiel guix install emacs ausführen, werden alle (gnu packages …)-Module durchlaufen, bis eines gefunden wird, das ein Paketobjekt mit dem Namen emacs exportiert. Diese Paketsuchfunktion ist im Modul (gnu packages) implementiert.

Benutzer können Paketdefinitionen auch in Modulen mit anderen Namen unterbringen – z.B. (my-packages emacs)²⁰. Es gibt zwei Arten, solche Paketdefinitionen für die Benutzungsschnittstelle sichtbar zu machen:

1. Eine Möglichkeit ist, das Verzeichnis, in dem Ihre Paketmodule stehen, mit der Befehlszeilenoption -L von guix package und anderen Befehlen (siehe Gemeinsame Erstellungsoptionen) oder durch Setzen der unten beschriebenen Umgebungsvariablen GUIX_PACKAGE_PATH zum Suchpfad hinzuzufügen.
2. Die andere Möglichkeit ist, einen Kanal zu definieren und guix pull so zu konfigurieren, dass es davon seine Module bezieht. Ein Kanal ist im Kern nur ein Git-Repository, in welchem Paketmodule liegen. Siehe Kanäle für mehr Informationen, wie Kanäle definiert und benutzt werden.

GUIX_PACKAGE_PATH funktioniert ähnlich wie andere Variable mit Suchpfaden:

Umgebungsvariable: GUIX_PACKAGE_PATH

Dies ist eine doppelpunktgetrennte Liste von Verzeichnissen, die nach zusätzlichen Paketmodulen durchsucht werden. In dieser Variablen aufgelistete Verzeichnisse haben Vorrang vor den Modulen, die zur Distribution gehören.

Die Distribution wird komplett von Grund auf initialisiert – man sagt zur Initialisierung auch Bootstrapping – und sie ist eigenständig („self-contained“): Jedes Paket wird nur auf Basis von anderen Paketen in der Distribution erstellt. Die Wurzel dieses Abhängigkeitsgraphen ist ein kleiner Satz von Initialisierungsbinärdateien, den Bootstrap-Binärdateien, die im Modul (gnu packages bootstrap) verfügbar gemacht werden. Für mehr Informationen über Bootstrapping, siehe Bootstrapping.

8.2 Pakete definieren

Mit den Modulen (guix packages) und (guix build-system) können Paketdefinitionen auf einer hohen Abstraktionsebene geschrieben werden. Zum Beispiel sieht die Paketdefinition bzw. das Rezept für das Paket von GNU Hello so aus:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Auch ohne ein Experte in Scheme zu sein, könnten Leser erraten haben, was die verschiedenen Felder dabei bedeuten. Dieser Ausdruck bindet die Variable hello an ein <package>-Objekt, was an sich nur ein Verbund (Record) ist (siehe Scheme-Verbünde in Referenzhandbuch zu GNU Guile). Die Felder dieses Paket-Objekts lassen sich mit den Prozeduren aus dem Modul (guix packages) auslesen, zum Beispiel liefert (package-name hello) – Überraschung! – "hello".

Mit etwas Glück können Sie die Definition vielleicht teilweise oder sogar ganz aus einer anderen Paketsammlung importieren, indem Sie den Befehl guix import verwenden (siehe guix import aufrufen).

In obigem Beispiel wurde hello in einem eigenen Modul ganz für sich alleine definiert, und zwar (gnu packages hello). Technisch gesehen muss es nicht unbedingt in einem solchen Modul definiert werden, aber es ist bequem, denn alle Module unter (gnu packages …) werden automatisch von den Befehlszeilenwerkzeugen gefunden (siehe Paketmodule).

Ein paar Dinge sind noch erwähnenswert in der obigen Paketdefinition:

• Das source-Feld für die Quelle des Pakets ist ein <origin>-Objekt, was den Paketursprung angibt (siehe origin-Referenz für eine vollständige Referenz). Hier wird dafür die Methode url-fetch aus dem Modul (guix download) benutzt, d.h. die Quelle ist eine Datei, die über FTP oder HTTP heruntergeladen werden soll.

  Das Präfix mirror://gnu lässt url-fetch einen der GNU-Spiegelserver benutzen, die in (guix download) definiert sind.

  Das Feld sha256 legt den erwarteten SHA256-Hashwert der herunterzuladenden Datei fest. Ihn anzugeben ist Pflicht und er ermöglicht es Guix, die Integrität der Datei zu überprüfen. Die Form (base32 …) geht der base32-Darstellung des Hash-Wertes voraus. Sie finden die base32-Darstellung mit Hilfe der Befehle guix download (siehe guix download aufrufen) und guix hash (siehe guix hash aufrufen).

  Wenn nötig kann in der origin-Form auch ein patches-Feld stehen, wo anzuwendende Patches aufgeführt werden, sowie ein snippet-Feld mit einem Scheme-Ausdruck mit den Anweisungen, wie der Quellcode zu modifizieren ist.

• Das Feld build-system legt fest, mit welcher Prozedur das Paket erstellt werden soll (siehe Erstellungssysteme). In diesem Beispiel steht gnu-build-system für das wohlbekannte GNU-Erstellungssystem, wo Pakete mit der üblichen Befehlsfolge ./configure && make && make check && make install konfiguriert, erstellt und installiert werden.

  Sobald Sie anfangen, Pakete für nichttriviale Software zu schreiben, könnten Sie Werkzeuge benötigen, um jene Erstellungsphasen abzuändern, Dateien zu verändern oder Ähnliches. Siehe Werkzeuge zur Erstellung für mehr Informationen dazu.

• Das Feld arguments gibt an, welche Optionen dem Erstellungssystem mitgegeben werden sollen (siehe Erstellungssysteme). In diesem Fall interpretiert gnu-build-system diese als Auftrag, configure mit der Befehlszeilenoption --enable-silent-rules auszuführen.

  Was hat es mit diesen einfachen Anführungszeichen (') auf sich? Sie gehören zur Syntax von Scheme und führen eine wörtlich zu interpretierende Datenliste ein; dies nennt sich Maskierung oder Quotierung. ' ist synonym mit quote. Ihnen könnte auch ` begegnen (ein Backquote, stattdessen kann man auch das längere Synonym quasiquote schreiben); damit können wir eine wörtlich als Daten interpretierte Liste einführen, aber bei dieser „Quasimaskierung“ kann , (ein Komma, oder dessen Synonym unquote) benutzt werden, um den ausgewerteten Wert eines Ausdrucks in diese Liste einzufügen. Quotierung in Referenzhandbuch zu GNU Guile enthält weitere Details. Hierbei ist also der Wert des arguments-Feldes eine Liste von Argumenten, die an das Erstellungssystem weitergereicht werden, wie bei apply (siehe apply in Referenzhandbuch zu GNU Guile).

  Ein Doppelkreuz gefolgt von einem Doppelpunkt (#:) definiert ein Scheme-Schlüsselwort (siehe Keywords in Referenzhandbuch zu GNU Guile) und #:configure-flags ist ein Schlüsselwort, um eine Befehlszeilenoption an das Erstellungssystem mitzugeben (siehe Coding With Keywords in Referenzhandbuch zu GNU Guile).

• Das Feld inputs legt Eingaben an den Erstellungsprozess fest – d.h. Abhängigkeiten des Pakets zur Erstellungs- oder Laufzeit. Hier fügen wir eine Eingabe hinzu, eine Referenz auf die Variable gawk; gawk ist auch selbst wiederum an ein <package>-Objekt als Variablenwert gebunden.

  Beachten Sie, dass GCC, Coreutils, Bash und andere essenzielle Werkzeuge hier nicht als Eingaben aufgeführt werden müssen. Stattdessen sorgt schon gnu-build-system dafür, dass diese vorhanden sein müssen (siehe Erstellungssysteme).

  Sämtliche anderen Abhängigkeiten müssen aber im inputs-Feld aufgezählt werden. Jede hier nicht angegebene Abhängigkeit wird während des Erstellungsprozesses schlicht nicht verfügbar sein, woraus ein Erstellungsfehler resultieren kann.

Siehe package-Referenz für eine umfassende Beschreibung aller erlaubten Felder.

Vertiefung: Fühlen Sie sich eingeschüchtert von der Scheme-Sprache oder wurde Ihre Neugier geweckt? Im Kochbuch gibt es einen kurzen Abschnitt, wie man anfängt. Dort werden einige der oben gezeigten Dinge wiederholt und die Grundlagen erklärt. Siehe Ein Schnellkurs in Scheme in GNU-Guix-Kochbuch für weitere Informationen.

Sobald eine Paketdefinition eingesetzt wurde, können Sie das Paket mit Hilfe des Befehlszeilenwerkzeugs guix build dann auch tatsächlich erstellen (siehe Aufruf von guix build) und dabei jegliche Erstellungsfehler, auf die Sie stoßen, beseitigen (siehe Fehlschläge beim Erstellen untersuchen). Sie können den Befehl guix edit benutzen, um leicht zur Paketdefinition zurückzuspringen (siehe guix edit aufrufen). Unter Paketrichtlinien finden Sie mehr Informationen darüber, wie Sie Paketdefinitionen testen, und unter guix lint aufrufen finden Sie Informationen, wie Sie prüfen, ob eine Definition alle Stilkonventionen einhält. Zuletzt finden Sie unter Kanäle Informationen, wie Sie die Distribution um Ihre eigenen Pakete in einem „Kanal“ erweitern.

Zu all dem sei auch erwähnt, dass Sie das Aktualisieren einer Paketdefinition auf eine vom Anbieter neu veröffentlichte Version mit dem Befehl guix refresh teilweise automatisieren können (siehe guix refresh aufrufen).

Hinter den Kulissen wird die einem <package>-Objekt entsprechende Ableitung zuerst durch package-derivation berechnet. Diese Ableitung wird in der .drv-Datei unter /gnu/store gespeichert. Die von ihr vorgeschriebenen Erstellungsaktionen können dann durch die Prozedur build-derivations umgesetzt werden (siehe Der Store).

Prozedur: package-derivation Store Paket [System]

Das <derivation>-Objekt zum Paket für das angegebene System liefern (siehe Ableitungen).

Als Paket muss ein gültiges <package>-Objekt angegeben werden und das System muss eine Zeichenkette sein, die das Zielsystem angibt – z.B. "x86_64-linux" für ein auf x86_64 laufendes, Linux-basiertes GNU-System. Store muss eine Verbindung zum Daemon sein, der die Operationen auf dem Store durchführt (siehe Der Store).

Auf ähnliche Weise kann eine Ableitung berechnet werden, die ein Paket für ein anderes System cross-erstellt.

Prozedur: package-cross-derivation Store Paket Ziel [System]

Liefert das <derivation>-Objekt, um das Paket zu cross-erstellen vom System aus für das Ziel-System.

Als Ziel muss ein gültiges GNU-Tripel angegeben werden, was die Ziel-Hardware und das zugehörige Betriebssystem beschreibt, wie z.B. "aarch64-linux-gnu" (siehe Specifying Target Triplets in Autoconf).

Wenn Sie einmal Paketdefinitionen fertig verfasst haben, können Sie leicht Varianten derselben Pakete definieren. Siehe Paketvarianten definieren für mehr Informationen dazu.

• package-Referenz
• origin-Referenz