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 Patches). 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 Patches). 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 sich Guix auf einem beliebigen System aus einem alle Komponenten umfassenden Tarball installieren lässt, 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 in den nächsten Abschnitten beschrieben wird. Vorausgesetzt wird hier lediglich, dass GNU tar und Xz verfügbar sind.

Anmerkung: Wir empfehlen, dass Sie dieses Installations-Skript für die Shell verwenden, welches Guix automatisch herunterlädt, installiert und eine erste Konfiguration von Guix mit sich bringt. Es sollte als der Administratornutzer (als „root“) ausgeführt werden.

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

Wenn Sie Debian oder ein Debian-Derivat wie Ubuntu verwenden, können Sie stattdessen das Guix-Paket installieren (obwohl es eine ältere Version als 1.4.0 mitbringen könnte, können Sie es anschließend über den Befehl ‘guix pull’ aktualisieren):

sudo apt install guix

Das Gleiche gilt auf openSUSE:

sudo zypper install guix

Wenn Sie das 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 in Guix, um loszulegen!

Die Installation läuft so ab:

1. Laden Sie den binären Tarball von ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz’ herunte. Falls Sie Guix auf einer Maschine mit i686-Architektur (32 Bit) einrichten, auf der bereits der Linux-Kernel läuft, ersetzen Sie x86_64-linux durch i686-linux oder entsprechend für andere Maschinen (siehe GNU-Distribution).

   Achten Sie darauf, auch die zugehörige .sig-Datei herunterzuladen und verifizieren Sie damit die Authentizität des Tarballs, ungefähr so:

   $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz.sig
   $ gpg --verify guix-binary-1.4.0.x86_64-linux.tar.xz.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.

2. Nun müssen Sie zum Administratornutzer root wechseln. Abhängig von Ihrer Distribution müssen Sie dazu etwa su - oder sudo -i ausführen. Danach führen Sie als root-Nutzer aus:

   # cd /tmp
   # tar --warning=no-timestamp -xf \
        /pfad/zur/guix-binary-1.4.0.x86_64-linux.tar.xz
   # mv var/guix /var/ && mv gnu /
   

   Dadurch wird /gnu/store (siehe Der Store) und /var/guix erzeugt. Letzteres enthält ein fertiges Guix-Profil für den Administratornutzer root (wie im nächsten Schritt beschrieben).

   Entpacken Sie den Tarball nicht auf einem schon funktionierenden Guix-System, denn es würde seine eigenen essenziellen Dateien überschreiben.

   Die Befehlszeilenoption --warning=no-timestamp stellt sicher, dass GNU tar nicht vor „unplausibel alten Zeitstempeln“ warnt (solche Warnungen traten bei GNU tar 1.26 und älter auf, neue Versionen machen keine Probleme). Sie treten auf, weil alle Dateien im Archiv als Änderungszeitpunkt 1 eingetragen bekommen haben (das bezeichnet den 1. Januar 1970). Das ist Absicht, damit der Inhalt des Archivs nicht davon abhängt, wann es erstellt wurde, und es somit reproduzierbar wird.

3. Machen Sie das Profil als ~root/.config/guix/current verfügbar, wo guix pull es aktualisieren kann (siehe guix pull aufrufen):

   # mkdir -p ~root/.config/guix
   # ln -sf /var/guix/profiles/per-user/root/current-guix \
            ~root/.config/guix/current
   

   „Sourcen“ Sie etc/profile, um PATH und andere relevante Umgebungsvariable zu ergänzen:

   # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
     source $GUIX_PROFILE/etc/profile
   

4. Erzeugen Sie Nutzergruppe und Nutzerkonten für die Erstellungs-Benutzer wie folgt (siehe Einrichten der Erstellungsumgebung).
5. Führen Sie den Daemon aus, und lassen Sie ihn automatisch bei jedem Hochfahren starten.

   Wenn Ihre Wirts-Distribution systemd als „init“-System verwendet, können Sie das mit folgenden Befehlen veranlassen:

   # cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \
        ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
        /etc/systemd/system/
   # systemctl enable --now gnu-store.mount guix-daemon
   

   Außerdem, wenn Sie möchten, dass regelmäßig guix gc durchgeführt wird:

   # cp ~root/.config/guix/current/lib/systemd/system/guix-gc.service \
        ~root/.config/guix/current/lib/systemd/system/guix-gc.timer \
        /etc/systemd/system/
   # systemctl enable --now guix-gc.timer
   

   Vielleicht möchten Sie die in guix-gc.service verwendeten Befehlszeilenoptionen an Ihre Bedürfnisse anpassen (siehe guix gc aufrufen).

   Wenn Ihre Wirts-Distribution als „init“-System Upstart verwendet:

   # initctl reload-configuration
   # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
        /etc/init/
   # start guix-daemon
   

   Andernfalls können Sie den Daemon immer noch manuell starten, mit:

   # ~root/.config/guix/current/bin/guix-daemon \
          --build-users-group=guixbuild
   

6. Stellen Sie den guix-Befehl auch anderen Nutzern Ihrer Maschine zur Verfügung, zum Beispiel so:

   # mkdir -p /usr/local/bin
   # cd /usr/local/bin
   # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
   

   Es ist auch eine gute Idee, die Info-Version dieses Handbuchs ebenso verfügbar zu machen:

   # mkdir -p /usr/local/share/info
   # cd /usr/local/share/info
   # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
     do ln -s $i ; done
   

   Auf diese Art wird, unter der Annahme, dass bei Ihnen /usr/local/share/info im Suchpfad eingetragen ist, das Ausführen von info guix.de dieses Handbuch öffnen (siehe Other Info Directories in GNU Texinfo hat weitere Details, wie Sie den Info-Suchpfad ändern können).

7. Um Substitute von ci.guix.gnu.org, bordeaux.guix.gnu.org oder einem Spiegelserver davon zu benutzen (siehe Substitute), müssen sie erst autorisiert werden:

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

   Anmerkung: Wenn Sie Substitute abgeschaltet lassen, 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 Substitute abschalten wollen könnte.

8. Alle Nutzer müssen womöglich ein paar zusätzliche Schritte ausführen, damit ihre Guix-Umgebung genutzt werden kann, siehe Anwendungen einrichten.

Voilà, die Installation ist fertig!

Sie können nachprüfen, dass Guix funktioniert, indem Sie ein Beispielpaket in das root-Profil installieren:

# guix install hello

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.

2.2 Voraussetzungen

Dieser Abschnitt listet Voraussetzungen auf, um Guix aus seinem Quellcode zu erstellen. Der Erstellungsprozess für Guix ist derselbe wie für andere GNU-Software und wird hier nicht beschrieben. Bitte lesen Sie die Dateien README und INSTALL im Guix-Quellbaum, um weitere Details zu erfahren.

GNU Guix kann von seinem Webauftritt unter http://www.gnu.org/software/guix/ heruntergeladen werden.

GNU Guix hat folgende Pakete als Abhängigkeiten:

• GNU Guile, Version 3.0.x, Version 3.0.3 oder neuer,
• Guile-Gcrypt, Version 0.1.0 oder neuer,
• Guile-GnuTLS (siehe die Installationsanleitung der GnuTLS-Anbindungen für Guile in GnuTLS-Guile)⁵,
• Guile-SQLite3, Version 0.1.0 oder neuer,
• Guile-zlib, Version 0.1.0 oder neuer,
• Guile-lzlib,
• Guile-Avahi,
• Guile-Git, Version 0.5.0 oder neuer,
• Guile-JSON 4.3.0 oder später,
• GNU Make.

Folgende Abhängigkeiten sind optional:

• Unterstützung für das Auslagern von Erstellungen (siehe Nutzung der Auslagerungsfunktionalität) und guix copy (siehe guix copy aufrufen) hängt von Guile-SSH, Version 0.13.0 oder neuer, ab.
• Guile-zstd, für die Kompression und Dekompression mit zstd in guix publish und für Substitute (siehe guix publish aufrufen).
• Guile-Semver für den crate-Importer (siehe guix import aufrufen).
• Guile-Lib für den go-Importer (siehe guix import aufrufen) und für einige der Aktualisierungsprogramme (siehe guix refresh aufrufen).
• Wenn libbz2 verfügbar ist, kann guix-daemon damit Erstellungsprotokolle komprimieren.

Sofern nicht --disable-daemon beim Aufruf von configure übergeben wurde, benötigen Sie auch folgende Pakete:

• GNU libgcrypt,
• SQLite 3,
• GCC’s g++ mit Unterstützung für den C++11-Standard.

Sollten Sie Guix auf einem System konfigurieren, auf dem Guix bereits installiert ist, dann stellen Sie sicher, dasselbe Zustandsverzeichnis wie für die bestehende Installation zu verwenden. Benutzen Sie dazu die Befehlszeilenoption --localstatedir des configure-Skripts (siehe localstatedir in GNU Coding Standards). Die localstatedir-Option wird normalerweise auf den Wert /var festgelegt. Das configure-Skript schützt vor ungewollter Fehlkonfiguration der localstatedir, damit Sie nicht versehentlich Ihren Store verfälschen (siehe Der Store).

2.3 Den Testkatalog laufen lassen

Nachdem configure und make erfolgreich durchgelaufen sind, ist es ratsam, den Testkatalog auszuführen. Er kann dabei helfen, Probleme mit der Einrichtung oder Systemumgebung zu finden, oder auch Probleme in Guix selbst – und Testfehler zu melden ist eine wirklich gute Art und Weise, bei der Verbesserung von Guix mitzuhelfen. Um den Testkatalog auszuführen, geben Sie Folgendes ein:

make check

Testfälle können parallel ausgeführt werden. Sie können die Befehlszeiltenoption -j von GNU make benutzen, damit es schneller geht. Der erste Durchlauf kann auf neuen Maschinen ein paar Minuten dauern, nachfolgende Ausführungen werden schneller sein, weil der für die Tests erstellte Store schon einige Dinge zwischengespeichert haben wird.

Es ist auch möglich, eine Teilmenge der Tests laufen zu lassen, indem Sie die TESTS-Variable des Makefiles ähnlich wie in diesem Beispiel definieren:

make check TESTS="tests/store.scm tests/cpio.scm"

Standardmäßig werden Testergebnisse pro Datei angezeigt. Um die Details jedes einzelnen Testfalls zu sehen, können Sie wie in diesem Beispiel die SCM_LOG_DRIVER_FLAGS-Variable des Makefiles definieren:

make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"

Mit dem eigens geschriebenen SRFI-64-Testtreiber für Automake, über den der „check“-Testkatalog läuft (zu finden in build-aux/test-driver.scm), können auch die Testfälle genauer ausgewählt werden, die ausgeführt werden sollen. Dazu dienen dessen Befehlszeilenoptionen --select und --exclude. Hier ist ein Beispiel, um alle Testfälle aus der Testdatei tests/packages.scm auszuführen, deren Name mit „transaction-upgrade-entry“ beginnt:

export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry"
make check TESTS="tests/packages.scm"

Möchte man die Ergebnisse fehlgeschlagener Tests direkt über die Befehlszeile einsehen, fügt man die Befehlszeilenoption --errors-only=yes in die Makefile-Variable SCM_LOG_DRIVER_FLAGS ein und setzt Automakes Makefile-Variable VERBOSE, etwa so:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1

Sie können die Befehlszeilenoption --show-duration=yes benutzen, damit ausgegeben wird, wie lange jeder einzelne Testfall gebraucht hat, in Kombination mit --brief=no:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"

Siehe Parallel Test Harness in GNU Automake für mehr Informationen über den parallelen Testrahmen von Automake.

Kommt es zum Fehlschlag, senden Sie bitte eine E-Mail an bug-guix@gnu.org und fügen Sie die Datei test-suite.log als Anhang bei. Bitte geben Sie dabei in Ihrer Nachricht die benutzte Version von Guix an sowie die Versionsnummern der Abhängigkeiten (siehe Voraussetzungen).

Guix wird auch mit einem Testkatalog für das ganze System ausgeliefert, der vollständige Instanzen des „Guix System“-Betriebssystems testet. Er kann nur auf Systemen benutzt werden, auf denen Guix bereits installiert ist, mit folgendem Befehl:

make check-system

Oder, auch hier, indem Sie TESTS definieren, um eine Teilmenge der auszuführenden Tests anzugeben:

make check-system TESTS="basic mcron"

Diese Systemtests sind in den (gnu tests …)-Modulen definiert. Sie funktionieren, indem Sie das getestete Betriebssystem mitsamt schlichter Instrumentierung in einer virtuellen Maschine (VM) ausführen. Die Tests können aufwendige Berechnungen durchführen oder sie günstig umgehen, je nachdem, ob für ihre Abhängigkeiten Substitute zur Verfügung stehen (siehe Substitute). Manche von ihnen nehmen viel Speicherplatz in Anspruch, um die VM-Abbilder zu speichern.

Auch hier gilt: Falls Testfehler auftreten, senden Sie bitte alle Details an bug-guix@gnu.org.

2.4 Den Daemon einrichten

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 auch 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 etc/guix-daemon.cil

ps -Zax | grep guix-daemon

2.5 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://ci.guix.gnu.org https://bordeaux.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 0, was bedeutet, dass es keine Zeitbeschränkung gibt.

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.

Der Vorgabewert ist 0, was bedeutet, dass es keine Zeitbeschränkung gibt.

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

Bevor Sie mit der Installation fortfahren, sollten Sie dennoch die folgenden merklichen Einschränkungen der Version 1.4.0 beachten:

• Immer mehr Systemdienste sind verfügbar (siehe Dienste), aber manche könnten noch fehlen.
• GNOME, Xfce, LXDE und Enlightenment stehen zur Verfügung (siehe Desktop-Dienste), ebenso eine Reihe von X11-Fensterverwaltungsprogrammen, allerdings fehlt KDE zurzeit noch.

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-1.4.0.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-1.4.0.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-1.4.0.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-1.4.0.x86_64-linux.iso of=/dev/sdX status=progress
sync

growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.4.0.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 --type luks2 --pbkdf pbkdf2 /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! Von jetzt an können Sie Guix System aktualisieren, wann Sie möchten, indem Sie zum Beispiel 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 (siehe guix system aufrufen). Wir empfehlen, diese Schritte regelmäßig zu wiederholen, damit Ihr System die aktuellen Sicherheitsaktualisierungen benutzt (siehe Sicherheitsaktualisierungen).

Anmerkung: Beachten Sie, dass bei Nutzung von sudo guix der guix-Befehl des aktiven Benutzers ausgeführt wird und nicht der des Administratornutzers „root“, weil sudo die Umgebungsvariable PATH unverändert lässt. Um ausdrücklich das guix-Programm des Administrators aufzurufen, müssen Sie sudo -i guix … eintippen.

Das macht hier einen Unterschied, weil guix pull den guix-Befehl und Paketdefinitionen nur für dasjenige Benutzerkonto aktualisiert, mit dem es ausgeführt wird. Würden Sie stattdessen in der Login-Shell des „root“-Nutzers guix system reconfigure ausführen, müssten Sie auch für ihn guix pull ausführen.

Werfen Sie nun einen Blick auf Einstieg in Guix 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,file=guix-system-install-1.4.0.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.

4.1 Chroot ins vorliegende System

In diesem Abschnitt wird erklärt, wie Sie mit chroot in ein kaputtes Guix System hineinkommen, um es durch reconfigure auf eine gültige Konfiguration zu bringen, etwa wenn GRUB beim letzten Mal falsch installiert wurde. Auf anderen GNU/Linux-Systemen würde man ähnlich vorgehen, aber Guix System ist in mancher Hinsicht anders, insbesondere muss der Daemon laufen und Sie müssen Ihre Profile erreichen. Darauf geht diese Erklärung ein.

1. Beschaffen Sie ein bootfähiges Abbild von Guix System. Das neueste Entwicklungs-Image wäre geeignet, weil darin der Kernel und die Werkzeuge mindestens so neu sind wie im installierten System. Sie können es von der URL https://ci.guix.gnu.org bekommen. Im Abschnitt Installation von USB-Stick oder DVD wird erklärt, wie Sie das Image auf ein bootfähiges Medium überspielen.
2. Fahren Sie vom Medium mit dem Abbild den Rechner hoch und machen Sie die ersten Schritte im grafischen textbasierten Installationsprogramm, bis die Netzwerkverbindung eingerichtet ist. Alternativ können Sie die Netzwerkverbindung manuell einrichten wie es im Abschnitt manual-installation-networking beschrieben ist. Sofern Sie den Fehler ‘RTNETLINK answers: Operation not possible due to RF-kill’ zu sehen bekommen, hilft vielleicht ‘rfkill list’ gefolgt von ‘rfkill unblock 0’, wobei ‘0’ Ihr Geräteidentifikator (ID) ist.
3. Wechseln Sie zu einer virtuellen Konsole (TTY), falls noch nicht geschehen, indem Sie die Tasten Steuerungstaste + Alt + F4 gleichzeitig drücken. Binden Sie Ihr Dateisystem unter /mnt ein. Angenommen Sie haben Ihr Wurzeldateisystem auf der Partition /dev/sda2, dann geht das mit diesen Befehlen:

   mount /dev/sda2 /mnt
   

4. Binden Sie die blockorientierten Spezialgeräte und Linux-eigene Verzeichnisse ein:

   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   mount --bind /dev /mnt/dev
   

   Sofern Ihr System EFI benutzt, müssen Sie auch die als ESP dienende Partition einbinden. Wenn Sie bei Ihnen /dev/sda1 heißt, lautet der Befehl:

   mount /dev/sda1 /mnt/boot/efi
   

5. Nun betreten Sie Ihr System als eine chroot-Umgebung:

   chroot /mnt /bin/sh
   

6. Binden Sie das Systemprofil sowie das Profil von Ihrem benutzer ein, damit die Umgebung vollständig ist. Mit benutzer ist hier der Benutzername gemeint, den Sie auf dem Guix System haben, das Sie zu reparieren versuchen:

   source /var/guix/profiles/system/profile/etc/profile
   source /home/benutzer/.guix-profile/etc/profile
   

   Damit Sie auch dieselbe Guix-Version zur Verfügung haben, die Sie normalerweise in Ihrem Benutzerkonto haben, laden Sie mit source auch Ihr aktuelles Guix-Profil:

   source /home/benutzer/.config/guix/current/etc/profile
   

7. Starten Sie einen minimal funktionsfähigen guix-daemon als Hintergrundprozess:

   guix-daemon --build-users-group=guixbuild --disable-chroot &
   

8. Wenn es nötig ist, ändern Sie die Konfigurationsdatei Ihres Guix System, damit sie wieder stimmt. Dann rekonfigurieren Sie etwa so:

   guix system reconfigure Ihre-config.scm
   

9. Endlich sollte Ihr System so weit sein, dass Sie neustarten können und ausprobieren, ob Sie es so in Ordnung gebracht haben.

6.1 Funktionalitäten

Wir nehmen hier an, dass Sie schon Ihre ersten Erfahrungen mit Guix gemacht haben (siehe Einstieg in Guix) 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 Das Konfigurationssystem nutzen).

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.

6.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 base) 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": "https://example.com/greeter-1.0.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).

6.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/ci.guix.gnu.org.pub
# guix archive --authorize < prefix/share/guix/bordeaux.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"

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

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

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

6.6 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,
3. die systemweite /etc/guix/channels.scm-Datei,
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. Stellen Sie sicher, dass es am Anfang Ihres Suchpfades steht, damit Sie auch wirklich das neueste Guix und sein Info-Handbuch sehen (siehe Dokumentation):

export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

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.

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

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

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.

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.

Wie bei guix pull wird in Ermangelung anderer Optionen der letzte Commit auf dem master-Branch benutzt. Mit dem Befehl

guix time-machine -- build hello

wird dementsprechend das Paket hello erstellt, so wie es auf dem master-Branch definiert ist, was in der Regel einer neueren Guix-Version entspricht als der, die Sie installiert haben. Zeitreisen funktionieren also in beide Richtungen!

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

6.8 Untergeordnete

Anmerkung: Die hier beschriebenen Funktionalitäten sind in der Version 1.4.0 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:

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

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

Scheme-Prozedur: inferior-packages Untergeordneter

Liefert die Liste der Pakete in Untergeordneter.

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

Scheme-Prozedur: inferior-package? Objekt

Liefert wahr, wenn das obj ein Untergeordneter ist.

Scheme-Prozedur: inferior-package-name Paket

Scheme-Prozedur: inferior-package-version Paket

Scheme-Prozedur: inferior-package-synopsis Paket

Scheme-Prozedur: inferior-package-description Paket

Scheme-Prozedur: inferior-package-home-page Paket

Scheme-Prozedur: inferior-package-location Paket

Scheme-Prozedur: inferior-package-inputs Paket

Scheme-Prozedur: inferior-package-native-inputs Paket

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

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

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

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

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

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

6.10 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 ci.guix.gnu.org geliefert wird, nach /tmp/emacs:

$ wget -O - \
  https://ci.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://ci.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

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

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

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

7.4 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!

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

7.6 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. Dann würden Sie zunächst Module mit diesen Paketdefinitionen schreiben (siehe Paketmodule) und diese dann in einem Git-Repository verwalten, welches Sie selbst oder jeder andere dann als zusätzlichen Kanal eintragen können, von dem Pakete geladen werden. Klingt gut, oder?

Warnung: Bevor Sie, verehrter Nutzer, ausrufen: „Wow, das ist soooo coool!“, und Ihren eigenen 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.
• Wenn Sie Paketdefinitionen außerhalb von Guix betreuen, sehen wir Guix-Entwickler es als Ihre Aufgabe an, deren Kompatibilität sicherzstellen. Bedenken Sie, dass Paketmodule und Paketdefinitionen nur Scheme-Code sind, der verschiedene Programmierschnittstellen (APIs) benutzt. Wir nehmen uns das Recht heraus, diese APIs jederzeit zu ändern, damit wir Guix besser machen können, womöglich auf eine Art, wodurch Ihr Kanal nicht mehr funktioniert. Wir ändern APIs nie einfach so, werden aber auch nicht versprechen, APIs nicht zu verändern.
• 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.

Um einen Kanal zu erzeugen, müssen Sie ein Git-Repository mit Ihren eigenen Paketmodulen erzeugen und den Zugriff darauf ermöglichen. Das Repository kann beliebigen Inhalt haben, aber wenn es ein nützlicher Kanal sein soll, muss es Guile-Module enthalten, die Pakete exportieren. Sobald Sie anfangen, einen Kanal zu benutzen, verhält sich Guix, als wäre das Wurzelverzeichnis des Git-Repositorys des Kanals in Guiles Ladepfad enthalten (siehe Load Paths in Referenzhandbuch zu GNU Guile). Wenn Ihr Kanal also zum Beispiel eine Datei als my-packages/my-tools.scm enthält, die ein Guile-Modul definiert, dann wird das Modul unter dem Namen (my-packages my-tools) verfügbar sein und Sie werden es wie jedes andere Modul benutzen können (siehe Modules in Referenzhandbuch zu GNU Guile).

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

7.7 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"))

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

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

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

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

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

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. Dabei wird der Netzwerkzugriff des Wirtssystems geteilt und die Umgebungsvariable DISPLAY bleibt erhalten, aber nicht einmal das aktuelle Arbeitsverzeichnis wird geteilt zugänglich gemacht.

guix shell --container --network --no-cwd ungoogled-chromium \
  --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.64 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 von der FHS-Spezifikation 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 der FHS-Spezifikation 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.

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

8.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.64 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 von der FHS-Spezifikation 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 der FHS-Spezifikation 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).

8.3 guix pack aufrufen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

guix pack -f squashfs bash guile emacs emacs-geiser

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

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

--format=Format

-f Format

Generiert ein Bündel im angegebenen Format.

Die verfügbaren Formate sind:

tarball

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

docker

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

squashfs

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

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

guix pack -f squashfs bash …

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

deb

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

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

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

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

--relocatable

-R

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

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

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

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

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

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

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

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

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

default

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

performance

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

userns

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

proot

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

fakechroot

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

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

--entry-point=Befehl

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

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

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

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

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

--expression=Ausdruck

-e Ausdruck

Als Paket benutzen, wozu der Ausdruck ausgewertet wird.

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

--manifest=Datei

-m Datei

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

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

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

--system=System

-s System

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

--target=Tripel ¶

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

--compression=Werkzeug

-C Werkzeug

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

--symlink=Spezifikation

-S Spezifikation

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

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

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

--save-provenance

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

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

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

--root=Datei ¶

-r Datei

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

--localstatedir

--profile-name=Name

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

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

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

--derivation

-d

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

--bootstrap

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

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

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

8.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). Mit den unten aufgeführten Befehlszeilenoptionen können Sie Feineinstellungen am Prozess vornehmen.

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

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

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

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

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

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