Referenzhandbuch zu GNU Guix

Inhaltsverzeichnis

Nächste: , Nach oben: (dir)   [Inhalt][Index]

GNU Guix

Dieses Dokument beschreibt GNU Guix, Version 1.2.0, ein Werkzeug zur funktionalen Verwaltung von Softwarepaketen, das für das GNU-System geschrieben wurde.

Dieses Handbuch ist auch auf Englisch (siehe GNU Guix Reference Manual), in Vereinfachtem Chinesisch (siehe GNU Guix参考手册), auf Französisch (siehe Manuel de référence de GNU Guix), auf Spanisch (siehe Manual de referencia de GNU Guix) und auf Russisch verfügbar (siehe Руководство GNU Guix). Wenn Sie es in Ihre eigene Sprache übersetzen möchten, dann sind Sie beim Translation Project herzlich willkommen.


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

1 Einführung

GNU Guix1 ist ein Werkzeug zur Verwaltung von Softwarepaketen für das GNU-System und eine Distribution (eine „Verteilung“) desselbigen GNU-Systems. Guix macht es nicht mit besonderen Berechtigungen ausgestatteten, „unprivilegierten“ Nutzern leicht, Softwarepakete zu installieren, zu aktualisieren oder zu entfernen, zu einem vorherigen Satz von Paketen zurückzuwechseln, Pakete aus ihrem Quellcode heraus zu erstellen und hilft allgemein bei der Erzeugung und Wartung von Software-Umgebungen.

Sie können GNU Guix auf ein bestehendes GNU/Linux-System aufsetzen, wo es die bereits verfügbaren Werkzeuge ergänzt, ohne zu stören (siehe Installation), oder Sie können es als eine eigenständige Betriebssystem-Distribution namens Guix System verwenden2. Siehe GNU-Distribution.


Nächste: , Nach oben: Einführung   [Inhalt][Index]

1.1 Auf Guix-Art Software verwalten

Guix bietet eine befehlszeilenbasierte Paketverwaltungsschnittstelle (siehe Aufruf von guix package), 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 isolieren 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).


Vorige: , Nach oben: Einführung   [Inhalt][Index]

1.2 GNU-Distribution

Mit Guix kommt eine Distribution des GNU-Systems, die nur aus freier Software3 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 Aufruf von guix package):

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 („deprecated“, 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.

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 Einführung 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 verfügbar.

Informationen, wie auf andere Architekturen oder Kernels portiert werden kann, finden Sie im Abschnitt Portierung.

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.


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

2 Installation

Anmerkung: Wir empfehlen, dieses Shell-basierte Installationsskript zu benutzen, um Guix auf ein bestehendes GNU/Linux-System zu installieren — im Folgenden als Fremddistribution bezeichnet.4 Das Skript automatisiert das Herunterladen, das Installieren und die anfängliche Konfiguration von Guix. Es sollte als der Administratornutzer „root“ ausgeführt werden.

Wenn es auf einer Fremddistribution installiert wird, ergänzt GNU Guix die verfügbaren Werkzeuge, ohne dass sie sich gegenseitig stören. Guix’ Daten befinden sich ausschließlich in zwei Verzeichnissen, üblicherweise /gnu/store und /var/guix; andere Dateien auf Ihrem System wie /etc bleiben unberührt.

Sobald es installiert ist, kann Guix durch Ausführen von guix pull aktualisiert werden (siehe Aufruf von guix pull).

Sollten Sie es vorziehen, die Installationsschritte manuell durchzuführen, oder falls Sie Anpassungen daran vornehmen möchten, könnten sich die folgenden Unterabschnitte als nützlich erweisen. Diese beschreiben die Software-Voraussetzungen von Guix und wie man es manuell installiert, so dass man es benutzen kann.


Nächste: , Nach oben: Installation   [Inhalt][Index]

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 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.2.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.2.0.x86_64-linux.tar.xz.sig
    $ gpg --verify guix-binary-1.2.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.2.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 Aufruf von guix pull):
    # 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
    

    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 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
    
  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 Aufruf von guix pack für weitere Informationen zu diesem praktischen Werkzeug.


Nächste: , Vorige: , Nach oben: Installation   [Inhalt][Index]

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:

Folgende Abhängigkeiten sind optional:

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

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


Nächste: , Vorige: , Nach oben: Installation   [Inhalt][Index]

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"

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.


Nächste: , Vorige: , Nach oben: Installation   [Inhalt][Index]

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.


Nächste: , Nach oben: Den Daemon einrichten   [Inhalt][Index]

2.4.1 Einrichten der Erstellungsumgebung

In einem normalen Mehrbenutzersystem werden Guix und sein Daemon — das Programm guix-daemon — vom Systemadministrator installiert; /gnu/store gehört root und guix-daemon läuft als root. Nicht mit erweiterten Rechten ausgestattete Nutzer können Guix-Werkzeuge benutzen, um Pakete zu erstellen oder anderweitig auf den Store zuzugreifen, und der Daemon wird dies für sie erledigen und dabei sicherstellen, dass der Store in einem konsistenten Zustand verbleibt und sich die Nutzer erstellte Pakete teilen.

Wenn guix-daemon als Administratornutzer root läuft, wollen Sie aber vielleicht dennoch nicht, dass Paketerstellungsprozesse auch als root ablaufen, aus offensichtlichen Sicherheitsgründen. Um dies zu vermeiden, sollte ein besonderer Pool aus Erstellungsbenutzern geschaffen werden, damit vom Daemon gestartete Erstellungsprozesse ihn benutzen. Diese Erstellungsbenutzer müssen weder eine Shell noch ein Persönliches Verzeichnis zugewiesen bekommen, sie werden lediglich benutzt, wenn der Daemon root-Rechte in Erstellungsprozessen ablegt. Mehrere solche Benutzer zu haben, ermöglicht es dem Daemon, verschiedene Erstellungsprozessen unter verschiedenen Benutzeridentifikatoren (UIDs) zu starten, was garantiert, dass sie einander nicht stören — eine essenzielle Funktionalität, da Erstellungen als reine Funktionen angesehen werden (siehe Einführung).

Auf einem GNU/Linux-System kann ein Pool von Erstellungsbenutzern wie folgt erzeugt werden (mit Bash-Syntax und den Befehlen von shadow):

# 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

Die Anzahl der Erstellungsbenutzer entscheidet, wie viele Erstellungsaufträge parallel ausgeführt werden können, wie es mit der Befehlszeilenoption --max-jobs vorgegeben werden kann (siehe --max-jobs). Um guix system vm und ähnliche Befehle nutzen zu können, müssen Sie die Erstellungsbenutzer unter Umständen zur kvm-Benutzergruppe hinzufügen, damit sie Zugriff auf /dev/kvm haben, mit -G guixbuild,kvm statt -G guixbuild (siehe Aufruf von guix system).

Das Programm guix-daemon kann mit dem folgenden Befehl als root gestartet werden5:

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

Auf diese Weise startet der Daemon Erstellungsprozesse in einem chroot als einer der guixbuilder-Benutzer. Auf GNU/Linux enthält die chroot-Umgebung standardmäßig nichts außer:

Sie können beeinflussen, in welchem Verzeichnis der Daemon Verzeichnisbäume zur Erstellung unterbringt, indem sie den Wert der Umgebungsvariablen TMPDIR ändern. Allerdings heißt innerhalb des chroots der Erstellungsbaum immer /tmp/guix-build-Name.drv-0, wobei Name der Ableitungsname ist — z.B. coreutils-8.24. Dadurch hat der Wert von TMPDIR keinen Einfluss auf die Erstellungsumgebung, wodurch Unterschiede vermieden werden, falls Erstellungsprozesse den Namen ihres Erstellungsbaumes einfangen.

Der Daemon befolgt außerdem den Wert der Umgebungsvariablen http_proxy und https_proxy für von ihm durchgeführte HTTP- und HTTPS-Downloads, sei es für Ableitungen mit fester Ausgabe (siehe Ableitungen) oder für Substitute (siehe Substitute).

Wenn Sie Guix als ein Benutzer ohne erweiterte Rechte installieren, ist es dennoch möglich, guix-daemon auszuführen, sofern Sie --disable-chroot übergeben. Allerdings können Erstellungsprozesse dann nicht voneinander und vom Rest des Systems isoliert werden. Daher können sich Erstellungsprozesse gegenseitig stören und auf Programme, Bibliotheken und andere Dateien zugreifen, die dem restlichen System zur Verfügung stehen — was es deutlich schwerer macht, sie als reine Funktionen aufzufassen.


Nächste: , Vorige: , Nach oben: Den Daemon einrichten   [Inhalt][Index]

2.4.2 Nutzung der Auslagerungsfunktionalität

Wenn erwünscht, kann der Erstellungs-Daemon Ableitungserstellungen auf andere Maschinen auslagern, auf denen Guix läuft, mit Hilfe des offload-Build-Hooks7. Wenn diese Funktionalität aktiviert ist, wird eine nutzerspezifizierte Liste von Erstellungsmaschinen aus /etc/guix/machines.scm gelesen. Wann immer eine Erstellung angefragt wird, zum Beispiel durch guix build, versucht der Daemon, sie an eine der Erstellungsmaschinen auszulagern, die die Einschränkungen der Ableitung erfüllen, insbesondere ihre Systemtypen — z.B. x86_64-linux. Eine einzelne Maschine kann mehrere Systemtypen haben, entweder weil ihre Architektur eine native Unterstützung vorsieht, weil Emulation eingerichtet wurde (siehe Transparente Emulation mit QEMU) oder beides. Fehlende Voraussetzungen für die Erstellung werden über SSH auf die Zielmaschine kopiert, welche dann mit der Erstellung weitermacht. Hat sie Erfolg damit, so werden die Ausgabe oder Ausgaben der Erstellung zurück auf die ursprüngliche Maschine kopiert. Die Auslagerungsfunktion verfügt über einen einfachen Planungsalgorithmus (einen Scheduler), mit dem versucht wird, die jeweils beste Maschine auszuwählen. Unter den verfügbaren wird die beste Maschine nach Kriterien wie diesen ausgewählt:

  1. Ob Zeitfenster für Erstellungen frei sind („build slots“). Eine Erstellungsmaschine kann so viele Erstellungszeitfenster (Verbindungen) unterhalten wie es dem Wert des parallel-builds-Feldes des build-machine-Objekts entspricht.
  2. Was ihre relative Geschwindigkeit ist, gemäß ihrer Definition im speed-Feld ihres build-machine-Objekts.
  3. Ihrer Auslastung („load“). Die normalisierte Auslastung der Maschine darf einen Schwellwert nicht überschreiten. Dieser ist über das overload-threshold-Feld ihres build-machine-Objekts einstellbar.
  4. Verfügbarem Speicherplatz auf ihrem Datenträger. Es müssen mehr als 100 MiB verfügbar sein.

Die Datei /etc/guix/machines.scm sieht normalerweise so aus:

(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")
        (private-key
         (string-append (getenv "HOME")
                        "/.ssh/identität-für-guix"))))

Im obigen Beispiel geben wir eine Liste mit zwei Erstellungsmaschinen vor, eine für die x86_64- und i686-Architektur und eine für die aarch64-Architektur.

Tatsächlich ist diese Datei — wenig überraschend! — eine Scheme-Datei, die ausgewertet wird, wenn der offload-Hook gestartet wird. Der Wert, den sie zurückliefert, muss eine Liste von build-machine-Objekten sein. Obwohl dieses Beispiel eine feste Liste von Erstellungsmaschinen zeigt, könnte man auch auf die Idee kommen, etwa mit DNS-SD eine Liste möglicher im lokalen Netzwerk entdeckter Erstellungsmaschinen zu liefern (siehe Guile-Avahi in Using Avahi in Guile Scheme Programs). Der Datentyp build-machine wird im Folgenden weiter ausgeführt.

Datentyp: build-machine

Dieser Datentyp repräsentiert Erstellungsmaschinen, an die der Daemon Erstellungen auslagern darf. Die wichtigen Felder sind:

name

Der Rechnername (d.h. der Hostname) der entfernten Maschine.

systems

Die Systemtypen, die die entfernte Maschine unterstützt — z.B. (list "x86_64-linux" "i686-linux").

user

Das Benutzerkonto, mit dem eine Verbindung zur entfernten Maschine über SSH aufgebaut werden soll. Beachten Sie, dass das SSH-Schlüsselpaar nicht durch eine Passphrase geschützt sein darf, damit nicht-interaktive Anmeldungen möglich sind.

host-key

Dies muss der öffentliche SSH-Host-Schlüssel der Maschine im OpenSSH-Format sein. Er wird benutzt, um die Identität der Maschine zu prüfen, wenn wir uns mit ihr verbinden. Er ist eine lange Zeichenkette, die ungefähr so aussieht:

ssh-ed25519 AAAAC3NzaC…mde+UhL hint@example.org

Wenn auf der Maschine der OpenSSH-Daemon, sshd, läuft, ist der Host-Schlüssel in einer Datei wie /etc/ssh/ssh_host_ed25519_key.pub zu finden.

Wenn auf der Maschine der SSH-Daemon von GNU lsh, nämlich lshd, läuft, befindet sich der Host-Schlüssel in /etc/lsh/host-key.pub oder einer ähnlichen Datei. Er kann ins OpenSSH-Format umgewandelt werden durch lsh-export-key (siehe Converting keys in LSH Manual):

$ lsh-export-key --openssh < /etc/lsh/host-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV…

Eine Reihe optionaler Felder kann festgelegt werden:

port (Vorgabe: 22)

Portnummer des SSH-Servers auf der Maschine.

private-key (Vorgabe: ~root/.ssh/id_rsa)

Die Datei mit dem privaten SSH-Schlüssel, der beim Verbinden zur Maschine genutzt werden soll, im OpenSSH-Format. Dieser Schlüssel darf nicht mit einer Passphrase geschützt sein.

Beachten Sie, dass als Vorgabewert der private Schlüssel des root-Benutzers genommen wird. Vergewissern Sie sich, dass er existiert, wenn Sie die Standardeinstellung verwenden.

compression (Vorgabe: "zlib@openssh.com,zlib")
compression-level (Vorgabe: 3)

Die Kompressionsmethoden auf SSH-Ebene und das angefragte Kompressionsniveau.

Beachten Sie, dass Auslagerungen SSH-Kompression benötigen, um beim Übertragen von Dateien an Erstellungsmaschinen und zurück weniger Bandbreite zu benutzen.

daemon-socket (Vorgabe: "/var/guix/daemon-socket/socket")

Dateiname des Unix-Sockets, auf dem guix-daemon auf der Maschine lauscht.

overload-threshold (Vorgabe: 0.6)

Der Schwellwert für die Auslastung (englisch „load“), ab der eine potentielle Auslagerungsmaschine für den Auslagerungsplaner nicht mehr in Betracht kommt. Der Wert entspricht grob der gesamten Prozessornutzung der Erstellungsmaschine. Er reicht von 0.0 (0%) bis 1.0 (100%). Wenn er ignoriert werden soll, dann setzen Sie overload-threshold auf #f.

parallel-builds (Vorgabe: 1)

Die Anzahl der Erstellungen, die auf der Maschine parallel ausgeführt werden können.

speed (Vorgabe: 1.0)

Ein „relativer Geschwindigkeitsfaktor“. Der Auslagerungsplaner gibt tendenziell Maschinen mit höherem Geschwindigkeitsfaktor den Vorrang.

features (Vorgabe: '())

Eine Liste von Zeichenketten, die besondere von der Maschine unterstützte Funktionalitäten bezeichnen. Ein Beispiel ist "kvm" für Maschinen, die über die KVM-Linux-Module zusammen mit entsprechender Hardware-Unterstützung verfügen. Ableitungen können Funktionalitäten dem Namen nach anfragen und werden dann auf passenden Erstellungsmaschinen eingeplant.

Der Befehl guix muss sich im Suchpfad der Erstellungsmaschinen befinden. Um dies nachzuprüfen, können Sie Folgendes ausführen:

ssh build-machine guix repl --version

Es gibt noch eine weitere Sache zu tun, sobald machines.scm eingerichtet ist. Wie zuvor erklärt, werden beim Auslagern Dateien zwischen den Stores der Maschinen hin- und hergeschickt. Damit das funktioniert, müssen Sie als Erstes ein Schlüsselpaar auf jeder Maschine erzeugen, damit der Daemon signierte Archive mit den Dateien aus dem Store versenden kann (siehe Aufruf von guix archive):

# guix archive --generate-key

Jede Erstellungsmaschine muss den Schlüssel der Hauptmaschine autorisieren, damit diese Store-Objekte von der Hauptmaschine empfangen kann:

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

Andersherum muss auch die Hauptmaschine den jeweiligen Schlüssel jeder Erstellungsmaschine autorisieren.

Der ganze Umstand mit den Schlüsseln soll ausdrücken, dass sich Haupt- und Erstellungsmaschinen paarweise gegenseitig vertrauen. Konkret kann der Erstellungs-Daemon auf der Hauptmaschine die Unverfälschtheit von den Erstellungsmaschinen empfangener Dateien gewährleisten (und umgekehrt), und auch dass sie nicht sabotiert wurden und mit einem autorisierten Schlüssel signiert wurden.

Um zu testen, ob Ihr System funktioniert, führen Sie diesen Befehl auf der Hauptmaschine aus:

# guix offload test

Dadurch wird versucht, zu jeder Erstellungsmaschine eine Verbindung herzustellen, die in /etc/guix/machines.scm angegeben wurde, sichergestellt, dass auf jeder Guile und die Guix-Module nutzbar sind, und jeweils versucht, etwas auf die Erstellungsmaschine zu exportieren und von dort zu imporieren. Dabei auftretende Fehler werden gemeldet.

Wenn Sie stattdessen eine andere Maschinendatei verwenden möchten, geben Sie diese einfach auf der Befehlszeile an:

# guix offload test maschinen-qualif.scm

Letztendlich können Sie hiermit nur die Teilmenge der Maschinen testen, deren Name zu einem regulären Ausdruck passt:

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

Um die momentane Auslastung aller Erstellungsrechner anzuzeigen, führen Sie diesen Befehl auf dem Hauptknoten aus:

# guix offload status

Vorige: , Nach oben: Den Daemon einrichten   [Inhalt][Index]

2.4.3 SELinux-Unterstützung

Guix enthält eine SELinux-Richtliniendatei („Policy“) unter etc/guix-daemon.cil, die auf einem System installiert werden kann, auf dem SELinux aktiviert ist, damit Guix-Dateien gekennzeichnet sind und um das erwartete Verhalten des Daemons anzugeben. Da Guix System keine Grundrichtlinie („Base Policy“) für SELinux bietet, kann diese Richtlinie für den Daemon auf Guix System nicht benutzt werden.

2.4.3.1 Installieren der SELinux-Policy

Um die Richtlinie (Policy) zu installieren, führen Sie folgenden Befehl mit Administratorrechten aus:

semodule -i etc/guix-daemon.cil

Kennzeichnen Sie dann das Dateisystem neu mit restorecon oder einem anderen, von Ihrem System angebotenen Mechanismus.

Sobald die Richtlinie installiert ist, das Dateisystem neu gekennzeichnet wurde und der Daemon neugestartet wurde, sollte er im Kontext guix_daemon_t laufen. Sie können dies mit dem folgenden Befehl nachprüfen:

ps -Zax | grep guix-daemon

Beobachten Sie die Protokolldateien von SELinux, wenn Sie einen Befehl wie guix build hello ausführen, um sich zu überzeugen, dass SELinux alle notwendigen Operationen gestattet.

2.4.3.2 Einschränkungen

Diese Richtlinie ist nicht perfekt. Im Folgenden finden Sie eine Liste von Einschränkungen oder merkwürdigen Verhaltensweisen, die bedacht werden sollten, wenn man die mitgelieferte SELinux-Richtlinie für den Guix-Daemon einspielt.

  1. guix_daemon_socket_t wird nicht wirklich benutzt. Keine der Socket-Operationen benutzt Kontexte, die irgendetwas mit guix_daemon_socket_t zu tun haben. Es schadet nicht, diese ungenutzte Kennzeichnung zu haben, aber es wäre besser, für die Kennzeichnung auch Socket-Regeln festzulegen.
  2. guix gc kann nicht auf beliebige Verknüpfungen zu Profilen zugreifen. Die Kennzeichnung des Ziels einer symbolischen Verknüpfung ist notwendigerweise unabhängig von der Dateikennzeichnung der Verknüpfung. Obwohl alle Profile unter $localstatedir gekennzeichnet sind, erben die Verknüpfungen auf diese Profile die Kennzeichnung desjenigen Verzeichnisses, in dem sie sich befinden. Für Verknüpfungen im Persönlichen Verzeichnis des Benutzers ist das user_home_t, aber Verknüpfungen aus dem Persönlichen Verzeichnis des Administratornutzers, oder /tmp, oder das Arbeitsverzeichnis des HTTP-Servers, etc., funktioniert das nicht. guix gc würde es nicht gestattet, diese Verknüpfungen auszulesen oder zu verfolgen.
  3. Die vom Daemon gebotene Funktionalität, auf TCP-Verbindungen zu lauschen, könnte nicht mehr funktionieren. Dies könnte zusätzliche Regeln brauchen, weil SELinux Netzwerk-Sockets anders behandelt als Dateien.
  4. Derzeit wird allen Dateien mit einem Namen, der zum regulären Ausdruck /gnu/store/.+-(guix-.+|profile)/bin/guix-daemon passt, die Kennzeichnung guix_daemon_exec_t zugewiesen, wodurch jede beliebige Datei mit diesem Namen in irgendeinem Profil gestattet wäre, in der Domäne guix_daemon_t ausgeführt zu werden. Das ist nicht ideal. Ein Angreifer könnte ein Paket erstellen, dass solch eine ausführbare Datei enthält, und den Nutzer überzeugen, es zu installieren und auszuführen. Dadurch käme es in die Domäne guix_daemon_t. Ab diesem Punkt könnte SELinux nicht mehr verhindern, dass es auf Dateien zugreift, auf die Prozesse in dieser Domäne zugreifen dürfen.

    Wir könnten zum Zeitpunkt der Installation eine wesentlich restriktivere Richtlinie generieren, für die nur genau derselbe Dateiname des gerade installierten guix-daemon-Programms als guix_daemon_exec_t gekennzeichnet würde, statt einen vieles umfassenden regulären Ausdruck zu benutzen. Aber dann müsste der Administratornutzer zum Zeitpunkt der Installation jedes Mal die Richtlinie installieren oder aktualisieren müssen, sobald das Guix-Paket aktualisiert wird, dass das tatsächlich in Benutzung befindliche guix-daemon-Programm enthält.


Nächste: , Vorige: , Nach oben: Installation   [Inhalt][Index]

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

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 Aufruf von guix processes.

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’ 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 Auslagern des Daemons einrichten). 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 Aufruf von guix gc.

--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 Auslagern des Daemons einrichten) 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 Bzip2.

--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 Aufruf von guix gc 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.


Nächste: , Vorige: , Nach oben: Installation   [Inhalt][Index]

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.

2.6.1 Locales

Über Guix installierte Pakete benutzen nicht die Daten zu Regions- und Spracheinstellungen (Locales) des Wirtssystems. Stattdessen müssen Sie erst eines der Locale-Pakete installieren, die für Guix verfügbar sind, und dann den Wert Ihrer Umgebungsvariablen GUIX_LOCPATH passend festlegen:

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

Beachten Sie, dass das Paket glibc-locales Daten für alle von GNU libc unterstützten Locales enthält und deswegen um die 917 MiB wiegt. Alternativ gibt es auch glibc-utf8-locales, was kleiner, aber auf ein paar UTF-8-Locales beschränkt ist.

Die Variable GUIX_LOCPATH spielt eine ähnliche Rolle wie LOCPATH (siehe LOCPATH in Referenzhandbuch der GNU-C-Bibliothek). Es gibt jedoch zwei wichtige Unterschiede:

  1. GUIX_LOCPATH wird nur von der libc in Guix beachtet und nicht der von Fremddistributionen bereitgestellten libc. Mit GUIX_LOCPATH können Sie daher sicherstellen, dass die Programme der Fremddistribution keine inkompatiblen Locale-Daten von Guix laden.
  2. libc hängt an jeden GUIX_LOCPATH-Eintrag /X.Y an, wobei X.Y die Version von libc ist — z.B. 2.22. Sollte Ihr Guix-Profil eine Mischung aus Programmen enthalten, die an verschiedene libc-Versionen gebunden sind, wird jede nur die Locale-Daten im richtigen Format zu laden versuchen.

Das ist wichtig, weil das Locale-Datenformat verschiedener libc-Versionen inkompatibel sein könnte.

2.6.2 Name Service Switch

Wenn Sie Guix auf einer Fremddistribution verwenden, empfehlen wir stärkstens, dass Sie den Name Service Cache Daemon der GNU-C-Bibliothek, nscd, laufen lassen, welcher auf dem Socket /var/run/nscd/socket lauschen sollte. Wenn Sie das nicht tun, könnten mit Guix installierte Anwendungen Probleme beim Auflösen von Hostnamen (d.h. Rechnernamen) oder Benutzerkonten haben, oder sogar abstürzen. Die nächsten Absätze erklären warum.

Die GNU-C-Bibliothek implementiert einen Name Service Switch (NSS), welcher einen erweiterbaren Mechanismus zur allgemeinen „Namensauflösung“ darstellt: Hostnamensauflösung, Benutzerkonten und weiteres (siehe Name Service Switch in Referenzhandbuch der GNU-C-Bibliothek).

Für die Erweiterbarkeit unterstützt der NSS Plugins, welche neue Implementierungen zur Namensauflösung bieten: Zum Beispiel ermöglicht das Plugin nss-mdns die Namensauflösung für .local-Hostnamen, das Plugin nis gestattet die Auflösung von Benutzerkonten über den Network Information Service (NIS) und so weiter. Diese zusätzlichen „Auflösungsdienste“ werden systemweit konfiguriert in /etc/nsswitch.conf und alle auf dem System laufenden Programme halten sich an diese Einstellungen (siehe NSS Configuration File in GNU-C-Referenzhandbuch).

Wenn sie eine Namensauflösung durchführen — zum Beispiel, indem sie die getaddrinfo-Funktion in C aufrufen —, versuchen die Anwendungen als Erstes, sich mit dem nscd zu verbinden; ist dies erfolgreich, führt nscd für sie die weiteren Namensauflösungen durch. Falls nscd nicht läuft, führen sie selbst die Namensauflösungen durch, indem sie die Namensauflösungsdienste in ihren eigenen Adressraum laden und ausführen. Diese Namensauflösungsdienste — die libnss_*.so-Dateien — werden mit dlopen geladen, aber sie kommen von der C-Bibliothek des Wirtssystems und nicht von der C-Bibliothek, an die die Anwendung gebunden wurde (also der C-Bibliothek von Guix).

Und hier kommt es zum Problem: Wenn die Anwendung an die C-Bibliothek von Guix (etwa glibc 2.24) gebunden wurde und die NSS-Plugins von einer anderen C-Bibliothek (etwa libnss_mdns.so für glibc 2.22) zu laden versucht, wird sie vermutlich abstürzen oder die Namensauflösungen werden unerwartet fehlschlagen.

Durch das Ausführen von nscd auf dem System wird, neben anderen Vorteilen, dieses Problem der binären Inkompatibilität vermieden, weil diese libnss_*.so-Dateien vom nscd-Prozess geladen werden, nicht in den Anwendungen selbst.

2.6.3 X11-Schriftarten

Die Mehrheit der grafischen Anwendungen benutzen Fontconfig zum Finden und Laden von Schriftarten und für die Darstellung im X11-Client. Im Paket fontconfig in Guix werden Schriftarten standardmäßig in $HOME/.guix-profile gesucht. Um es grafischen Anwendungen, die mit Guix installiert wurden, zu ermöglichen, Schriftarten anzuzeigen, müssen Sie die Schriftarten auch mit Guix installieren. Essenzielle Pakete für Schriftarten sind unter anderem gs-fonts, font-dejavu und font-gnu-freefont.

Sobald Sie Schriftarten installiert oder wieder entfernt haben oder wenn Ihnen auffällt, dass eine Anwendung Schriftarten nicht finden kann, dann müssen Sie vielleicht Fontconfig installieren und den folgenden Befehl ausführen, damit dessen Zwischenspeicher für Schriftarten aktualisiert wird:

guix install fontconfig
fc-cache -rv

Um auf Chinesisch, Japanisch oder Koreanisch verfassten Text in grafischen Anwendungen anzeigen zu können, möchten Sie vielleicht font-adobe-source-han-sans oder font-wqy-zenhei installieren. Ersteres hat mehrere Ausgaben, für jede Sprachfamilie eine (siehe Pakete mit mehreren Ausgaben.). Zum Beispiel installiert folgender Befehl Schriftarten für chinesische Sprachen:

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

Ältere Programme wie xterm benutzen kein Fontconfig, sondern X-Server-seitige Schriftartendarstellung. Solche Programme setzen voraus, dass der volle Name einer Schriftart mit XLFD (X Logical Font Description) angegeben wird, z.B. so:

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

Um solche vollen Namen für die in Ihrem Guix-Profil installierten TrueType-Schriftarten zu verwenden, müssen Sie den Pfad für Schriftarten (Font Path) des X-Servers anpassen:

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

Danach können Sie den Befehl xlsfonts ausführen (aus dem Paket xlsfonts), um sicherzustellen, dass dort Ihre TrueType-Schriftarten aufgeführt sind.

2.6.4 X.509-Zertifikate

Das Paket nss-certs bietet X.509-Zertifikate, womit Programme die Identität von Web-Servern authentifizieren können, auf die über HTTPS zugegriffen wird.

Wenn Sie Guix auf einer Fremddistribution verwenden, können Sie dieses Paket installieren und die relevanten Umgebungsvariablen festlegen, damit Pakete wissen, wo sie Zertifikate finden. Unter X.509-Zertifikate stehen genaue Informationen.

2.6.5 Emacs-Pakete

Wenn Sie Emacs-Pakete mit Guix installieren, werden die Elisp-Dateien innerhalb des Verzeichnisses share/emacs/site-lisp/ in demjenigen Profil platziert, wohin sie installiert werden. Die Elisp-Bibliotheken werden in Emacs über die EMACSLOADPATH-Umgebungsvariable verfügbar gemacht, die durch die Installation von Emacs eingerichtet wird.

Bei der Initialisierung von Emacs werden „Autoload“-Definitionen automatisch über die Guix-spezifische Prozedur guix-emacs-autoload-packages ausgewertet. Wenn Sie aber aus irgendeinem Grund die mit Guix installierten Pakete nicht automatisch laden lassen möchten, können Sie Emacs mit der Befehlszeilenoption --no-site-file starten (siehe Init File in The GNU Emacs Manual).


Vorige: , Nach oben: Installation   [Inhalt][Index]

2.7 Aktualisieren von Guix

Um Guix zu aktualisieren, führen Sie aus:

guix pull

Siehe Aufruf von guix pull 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).


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

3 Systeminstallation

Dieser Abschnitt beschreibt, wie Sie „Guix System“ auf einer Maschine installieren. Guix kann auch als Paketverwaltungswerkzeug ein bestehendes GNU/Linux-System ergänzen, mehr dazu finden Sie im Abschnitt Installation.


Nächste: , Nach oben: Systeminstallation   [Inhalt][Index]

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.2.0 beachten:

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.


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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

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.


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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.2.0.x86_64-linux.iso.xz’ herunterladen, dass Sie auf einen USB-Stick aufspielen oder auf eine DVD brennen können, wobei Sie an Stelle 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.2.0.x86_64-linux.iso.xz.sig
$ gpg --verify guix-system-install-1.2.0.x86_64-linux.iso.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.

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

Um das Abbild auf einen USB-Stick zu kopieren, führen Sie folgende Schritte durch:

  1. Entpacken Sie das Abbild mit dem xz-Befehl:
    xz -d guix-system-install-1.2.0.x86_64-linux.iso.xz
    
  2. Stecken Sie einen USB-Stick in Ihren Rechner ein, der mindestens 1 GiB groß ist, und bestimmen Sie seinen Gerätenamen. Ist der Gerätename des USB-Sticks /dev/sdX, dann kopieren Sie das Abbild mit dem Befehl:
    dd if=guix-system-install-1.2.0.x86_64-linux.iso of=/dev/sdX status=progress
    sync
    

    Sie benötigen in der Regel Administratorrechte, um auf /dev/sdX zuzugreifen.

Auf eine DVD brennen

Um das Abbild auf eine DVD zu kopieren, führen Sie diese Schritte durch:

  1. Entpacken Sie das Abbild mit dem xz-Befehl:
    xz -d guix-system-install-1.2.0.x86_64-linux.iso.xz
    
  2. Legen Sie eine unbespielte DVD in Ihren Rechner ein und bestimmen Sie ihren Gerätenamen. Angenommen der Name des DVD-Laufwerks ist /dev/srX, kopieren Sie das Abbild mit:
    growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.2.0.x86_64-linux.iso
    

    Der Zugriff auf /dev/srX setzt in der Regel Administratorrechte voraus.

Das System starten

Sobald das erledigt ist, sollten Sie Ihr System neu starten und es vom USB-Stick oder der DVD hochfahren („booten“) können. Dazu müssen Sie wahrscheinlich beim Starten des Rechners in das BIOS- oder UEFI-Boot-Menü gehen, von wo aus Sie auswählen können, dass vom USB-Stick gebootet werden soll. Um aus Libreboot heraus zu booten, wechseln Sie in den Befehlsmodus, indem Sie die c-Taste drücken, und geben Sie search_grub usb ein.

Lesen Sie den Abschnitt Guix in einer VM installieren, wenn Sie Guix System stattdessen in einer virtuellen Maschine (VM) installieren möchten.


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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.


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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.

Netzwerkanbindung einrichten mit dem
grafischen Installationsprogramm

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.

Partitionieren mit dem grafischen
Installationsprogramm

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.

Mit einem Installationsschritt
fortfahren

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!


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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 Aufruf von guix package).


Nächste: , Nach oben: Manuelle Installation   [Inhalt][Index]

3.6.1 Tastaturbelegung, Netzwerkanbindung und Partitionierung

Bevor Sie das System installieren können, wollen Sie vielleicht die Tastaturbelegung ändern, eine Netzwerkverbindung herstellen und die Zielfestplatte partitionieren. Dieser Abschnitt wird Sie durch diese Schritte führen.

3.6.1.1 Tastaturbelegung

Das Installationsabbild verwendet die US-amerikanische QWERTY-Tastaturbelegung. Wenn Sie dies ändern möchten, können Sie den loadkeys-Befehl benutzen. Mit folgendem Befehl würden Sie zum Beispiel die Dvorak-Tastaturbelegung auswählen:

loadkeys dvorak

Schauen Sie sich an, welche Dateien im Verzeichnis /run/current-system/profile/share/keymaps stehen, um eine Liste verfügbarer Tastaturbelegungen zu sehen. Wenn Sie mehr Informationen brauchen, führen Sie man loadkeys aus.

3.6.1.2 Netzwerkkonfiguration

Führen Sie folgenden Befehl aus, um zu sehen, wie Ihre Netzwerkschnittstellen benannt sind:

ifconfig -a

… oder mit dem GNU/Linux-eigenen ip-Befehl:

ip address

Der Name kabelgebundener Schnittstellen (engl. Interfaces) beginnt mit dem Buchstaben ‘e’, zum Beispiel heißt die dem ersten fest eingebauten Ethernet-Adapter entsprechende Schnittstelle ‘eno1’. Drahtlose Schnittstellen werden mit einem Namen bezeichnet, der mit dem Buchstaben ‘w’ beginnt, etwa ‘w1p2s0’.

Kabelverbindung

Um ein kabelgebundenes Netzwerk einzurichten, führen Sie den folgenden Befehl aus, wobei Sie statt Schnittstelle den Namen der kabelgebundenen Schnittstelle eintippen, die Sie benutzen möchten.

ifconfig Schnittstelle up

… oder mit dem GNU/Linux-eigenen ip-Befehl:

ip link set Schnittstelle up
Drahtlose Verbindung

Um Drahtlosnetzwerke einzurichten, können Sie eine Konfigurationsdatei für das Konfigurationswerkzeug des wpa_supplicant schreiben (wo Sie sie speichern, ist nicht wichtig), indem Sie eines der verfügbaren Textbearbeitungsprogramme wie etwa nano benutzen:

nano wpa_supplicant.conf

Zum Beispiel können Sie die folgende Formulierung in der Datei speichern, die für viele Drahtlosnetzwerke funktioniert, sofern Sie die richtige SSID und Passphrase für das Netzwerk eingeben, mit dem Sie sich verbinden möchten:

network={
  ssid="meine-ssid"
  key_mgmt=WPA-PSK
  psk="geheime Passphrase des Netzwerks"
}

Starten Sie den Dienst für Drahtlosnetzwerke und lassen Sie ihn im Hintergrund laufen, indem Sie folgenden Befehl eintippen (ersetzen Sie dabei Schnittstelle durch den Namen der Netzwerkschnittstelle, die Sie benutzen möchten):

wpa_supplicant -c wpa_supplicant.conf -i Schnittstelle -B

Führen Sie man wpa_supplicant aus, um mehr Informationen zu erhalten.

Zu diesem Zeitpunkt müssen Sie sich eine IP-Adresse beschaffen. Auf einem Netzwerk, wo IP-Adressen automatisch via DHCP zugewiesen werden, können Sie das hier ausführen:

dhclient -v Schnittstelle

Versuchen Sie, einen Server zu pingen, um zu prüfen, ob sie mit dem Internet verbunden sind und alles richtig funktioniert:

ping -c 3 gnu.org

Einen Internetzugang herzustellen, ist in jedem Fall nötig, weil das Abbild nicht alle Software und Werkzeuge enthält, die nötig sein könnten.

Wenn HTTP- und HTTPS-Zugriffe bei Ihnen über einen Proxy laufen sollen, führen Sie folgenden Befehl aus:

herd set-http-proxy guix-daemon URL

Dabei ist URL die URL des Proxys, zum Beispiel http://example.org:8118.

Wenn Sie möchten, können Sie die weitere Installation auch per Fernwartung durchführen, indem Sie einen SSH-Server starten:

herd start ssh-daemon

Vergewissern Sie sich vorher, dass Sie entweder ein Passwort mit passwd festgelegt haben, oder dass Sie für OpenSSH eine Authentifizierung über öffentliche Schlüssel eingerichtet haben, bevor Sie sich anmelden.

3.6.1.3 Plattenpartitionierung

Sofern nicht bereits geschehen, ist der nächste Schritt, zu partitionieren und dann die Zielpartition zu formatieren.

Auf dem Installationsabbild sind mehrere Partitionierungswerkzeuge zu finden, einschließlich (siehe Overview in GNU Parted User Manual), fdisk und cfdisk. Starten Sie eines davon und partitionieren Sie Ihre Festplatte oder sonstigen Massenspeicher, wie Sie möchten:

cfdisk

Wenn Ihre Platte mit einer „GUID Partition Table“ (GPT) formatiert ist, und Sie vorhaben, die BIOS-basierte Variante des GRUB-Bootloaders zu installieren (was der Vorgabe entspricht), stellen Sie sicher, dass eine Partition als BIOS-Boot-Partition ausgewiesen ist (siehe BIOS installation in GNU GRUB manual).

Falls Sie stattdessen einen EFI-basierten GRUB installieren möchten, muss auf der Platte eine FAT32-formatierte EFI-Systempartition (ESP) vorhanden sein. Diese Partition kann unter dem Pfad /boot/efi eingebunden („gemountet“) werden und die esp-Flag der Partition muss gesetzt sein. Dazu würden Sie beispielsweise in parted eintippen:

parted /dev/sda set 1 esp on

Anmerkung: Falls Sie nicht wissen, ob Sie einen EFI- oder BIOS-basierten GRUB installieren möchten: Wenn bei Ihnen das Verzeichnis /sys/firmware/efi im Dateisystem existiert, möchten Sie vermutlich eine EFI-Installation durchführen, wozu Sie in Ihrer Konfiguration grub-efi-bootloader benutzen. Ansonsten sollten Sie den BIOS-basierten GRUB benutzen, der mit grub-bootloader bezeichnet wird. Siehe Bootloader-Konfiguration, wenn Sie mehr Informationen über Bootloader brauchen.

Sobald Sie die Platte fertig partitioniert haben, auf die Sie installieren möchten, müssen Sie ein Dateisystem auf Ihrer oder Ihren für Guix System vorgesehenen Partition(en) erzeugen8. Wenn Sie eine ESP brauchen und dafür die Partition /dev/sda1 vorgesehen haben, müssen Sie diesen Befehl ausführen:

mkfs.fat -F32 /dev/sda1

Für das Wurzeldateisystem ist ext4 das am häufigsten genutzte Format. Andere Dateisysteme, wie Btrfs, unterstützen Kompression, wovon berichtet wird, es habe sich als sinnvolle Ergänzung zur Dateideduplikation erwiesen, die der Daemon unabhängig vom Dateisystem bietet (siehe Deduplizieren).

Geben Sie Ihren Dateisystemen auch besser eine Bezeichnung („Label“), damit Sie sie zuverlässig wiedererkennen und später in den file-system-Deklarationen darauf Bezug nehmen können (siehe Dateisysteme). Dazu benutzen Sie typischerweise die Befehlszeilenoption -L des Befehls mkfs.ext4 oder entsprechende Optionen für andere Befehle. Wenn wir also annehmen, dass /dev/sda2 die Partition ist, auf der Ihr Wurzeldateisystem (englisch „root“) wohnen soll, können Sie dort mit diesem Befehl ein Dateisystem mit der Bezeichnung my-root erstellen:

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

Falls Sie aber vorhaben, die Partition mit dem Wurzeldateisystem zu verschlüsseln, können Sie dazu die Cryptsetup-/LUKS-Werkzeuge verwenden (siehe man cryptsetup, um mehr darüber zu erfahren). Angenommen Sie wollen die Partition für das Wurzeldateisystem verschlüsselt auf /dev/sda2 installieren, dann brauchen Sie eine Befehlsfolge ähnlich wie diese:

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

Sobald das erledigt ist, binden Sie dieses Dateisystem als Installationsziel mit dem Einhängepunkt /mnt ein, wozu Sie einen Befehl wie hier eintippen (auch hier unter der Annahme, dass my-root die Bezeichnung des künftigen Wurzeldateisystems ist):

mount LABEL=my-root /mnt

Binden Sie auch alle anderen Dateisysteme ein, die Sie auf dem Zielsystem benutzen möchten, mit Einhängepunkten relativ zu diesem Pfad. Wenn Sie sich zum Beispiel für einen Einhängepunkt /boot/efi für die EFI-Systempartition entschieden haben, binden Sie sie jetzt als /mnt/boot/efi ein, damit guix system init sie später findet.

Wenn Sie zudem auch vorhaben, eine oder mehrere Swap-Partitionen zu benutzen (siehe Swap-Speicher in Referenzhandbuch der GNU-C-Bibliothek), initialisieren Sie diese nun mit mkswap. Angenommen Sie haben eine Swap-Partition auf /dev/sda3, dann würde der Befehl so lauten:

mkswap /dev/sda3
swapon /dev/sda3

Alternativ können Sie eine Swap-Datei benutzen. Angenommen, Sie wollten die Datei /swapdatei im neuen System als eine Swapdatei benutzen, dann müssten Sie Folgendes ausführen9:

# 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

Bedenken Sie, dass, wenn Sie die Partition für das Wurzeldateisystem („root“) verschlüsselt und eine Swap-Datei in diesem Dateisystem wie oben beschrieben erstellt haben, die Verschlüsselung auch die Swap-Datei schützt, genau wie jede andere Datei in dem Dateisystem.


Vorige: , Nach oben: Manuelle Installation   [Inhalt][Index]

3.6.2 Fortfahren mit der Installation

Wenn die Partitionen des Installationsziels bereit sind und dessen Wurzeldateisystem unter /mnt eingebunden wurde, kann es losgehen mit der Installation. Führen Sie zuerst aus:

herd start cow-store /mnt

Dadurch wird /gnu/store copy-on-write, d.h. dorthin von Guix erstellte Pakete werden in ihrer Installationsphase auf dem unter /mnt befindlichen Zieldateisystem gespeichert, statt den Arbeitsspeicher auszulasten. Das ist nötig, weil die erste Phase des Befehls guix system init (siehe unten) viele Dateien nach /gnu/store herunterlädt oder sie erstellt, Änderungen am /gnu/store aber bis dahin wie das übrige Installationssystem nur im Arbeitsspeicher gelagert werden konnten.

Als Nächstes müssen Sie eine Datei bearbeiten und dort eine Deklaration des Betriebssystems, das Sie installieren möchten, hineinschreiben. Zu diesem Zweck sind im Installationssystem drei Texteditoren enthalten. Wir empfehlen, dass Sie GNU nano benutzen (siehe GNU nano Manual), welcher Syntax und zueinander gehörende Klammern hervorheben kann. Andere mitgelieferte Texteditoren, die Sie benutzen können, sind GNU Zile (ein Emacs-Klon) und nvi (ein Klon des ursprünglichen vi-Editors von BSD). Wir empfehlen sehr, dass Sie diese Datei im Zieldateisystem der Installation speichern, etwa als /mnt/etc/config.scm, weil Sie Ihre Konfigurationsdatei im frisch installierten System noch brauchen werden.

Der Abschnitt Das Konfigurationssystem nutzen gibt einen Überblick über die Konfigurationsdatei. Die in dem Abschnitt diskutierten Beispielkonfigurationen sind im Installationsabbild im Verzeichnis /etc/configuration zu finden. Um also mit einer Systemkonfiguration anzufangen, die einen grafischen Anzeigeserver (einen „Display-Server“ zum Darstellen einer „Desktop“-Arbeitsumgebung) bietet, könnten Sie so etwas ausführen:

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

Achten Sie darauf, was in Ihrer Konfigurationsdatei steht, und besonders auf Folgendes:

Wenn Sie damit fertig sind, Ihre Konfigurationsdatei vorzubereiten, können Sie das neue System initialisieren (denken Sie daran, dass zukünftige Wurzeldateisystem muss unter /mnt wie bereits beschrieben eingebunden sein):

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

Dies kopiert alle notwendigen Dateien und installiert GRUB auf /dev/sdX, sofern Sie nicht noch die Befehlszeilenoption --no-bootloader benutzen. Weitere Informationen finden Sie im Abschnitt Aufruf von guix system. Der Befehl kann das Herunterladen oder Erstellen fehlender Softwarepakete auslösen, was einige Zeit in Anspruch nehmen kann.

Sobald der Befehl erfolgreich — hoffentlich! — durchgelaufen ist, können Sie mit dem Befehl reboot das neue System booten lassen. Der Administratornutzer root hat im neuen System zunächst ein leeres Passwort, und Passwörter der anderen Nutzer müssen Sie später setzen, indem Sie den Befehl passwd als root ausführen, außer Ihre Konfiguration enthält schon Passwörter (siehe Passwörter für Benutzerkonten). Siehe Nach der Systeminstallation für Informationen, wie es weiter geht!


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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 Aufruf von guix system). 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 Anmelde-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 Freenode-IRC-Netzwerk oder auf der Mailing-Liste guix-devel@gnu.org, um uns Rückmeldung zu geben!


Nächste: , Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

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.2.0.System.iso
    

    -enable-kvm ist optional, verbessert die Rechenleistung aber erheblich, siehe Guix in einer VM starten.

  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 VM starten erklärt, wie Sie das tun können.


Vorige: , Nach oben: Systeminstallation   [Inhalt][Index]

3.9 Ein Abbild zur Installation erstellen

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

guix system disk-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 Aufruf von guix system 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 disk-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.


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

4 Einstieg in Guix

Wenn Sie in diesem Abschnitt angekommen sind, haben Sie vermutlich zuvor entweder Guix auf einer fremden Distribution installiert (siehe Installation) oder Sie haben das eigenständige „Guix System“ installiert (siehe Systeminstallation). Nun wird es Zeit für Sie, Guix kennenzulernen. Darum soll es in diesem Abschnitt gehen. Wir möchten Ihnen ein Gefühl vermitteln, wie sich Guix anfühlt.

Bei Guix geht es darum, Software zu installieren, also wollen Sie vermutlich zunächst Software finden, die Sie haben möchten. Sagen wir, Sie suchen ein Programm zur Textverarbeitung. Dann führen Sie diesen Befehl aus:

guix search text editor

Durch diesen Befehl stoßen Sie auf eine Reihe passender Pakete. Für jedes werden Ihnen der Name des Pakets, seine Version, eine Beschreibung und weitere Informationen angezeigt. Sobald Sie das Paket gefunden haben, dass Sie benutzen möchten, sagen wir mal Emacs (aha!), dann können Sie weitermachen und es installieren (führen Sie diesen Befehl als normaler Benutzer aus, Guix braucht hierfür keine Administratorrechte!):

guix install emacs

Sie haben soeben Ihr erstes Paket installiert, Glückwunsch! Während Sie das getan haben, ist Ihnen wahrscheinlich aufgefallen, dass Guix vorerstellte Programmbinärdateien herunterlädt, statt sie auf Ihrem Rechner zu kompilieren, außer wenn Sie diese Funktionalität vorher ausdrücklich abgeschaltet haben. In diesem Fall ist Guix wahrscheinlich noch immer mit der Erstellung beschäftigt. Siehe Substitute für mehr Informationen.

Wenn Sie nicht Guix System benutzen, wird der Befehl guix install diesen Hinweis ausgegeben haben:

Hinweis: Vielleicht möchten Sie die nötigen Umgebungsvariablen
festlegen, indem Sie dies ausführen:

     GUIX_PROFILE="$HOME/.guix-profile"
     . "$GUIX_PROFILE/etc/profile"

Sie können sie auch mit `guix package --search-paths -p "$HOME/.guix-profile"' nachlesen.

Tatsächlich ist es erforderlich, dass Sie Ihrer Shell erst einmal mitteilen, wo sich emacs und andere mit Guix installierte Programme befinden. Wenn Sie die obigen zwei Zeilen in die Shell einfügen, wird genau das bewerkstelligt: $HOME/.guix-profile/bin — wo sich das installierte Paket befindet — wird in die PATH-Umgebungsvariable eingefügt. Sie können diese zwei Zeilen in Ihre Shell hineinkopieren, damit sie sich sofort auswirken, aber wichtiger ist, dass Sie sie in ~/.bash_profile kopieren (oder eine äquivalente Datei, wenn Sie nicht Bash benutzen), damit die Umgebungsvariablen nächstes Mal gesetzt sind, wenn Sie wieder eine Shell öffnen. Das müssen Sie nur einmal machen und es sorgt auch bei anderen Umgebungsvariablen mit Suchpfaden dafür, dass die installierte Software gefunden wird. Wenn Sie zum Beispiel python und Bibliotheken für Python installieren, wird PYTHONPATH definiert.

Sie können nun weitere Pakete installieren, wann immer Sie möchten. Um die installierten Pakete aufzulisten, führen Sie dies aus:

guix package --list-installed

Um ein Paket wieder zu entfernen, benutzen Sie wenig überraschend guix remove. Guix hebt sich von anderen Paketverwaltern darin ab, dass Sie jede Operation, die Sie durchgeführt haben, auch wieder zurücksetzen können, egal ob install, remove oder upgrade, indem Sie dies ausführen:

guix package --roll-back

Das geht deshalb, weil jede Operation eigentlich als Transaktion durchgeführt wird, die eine neue Generation erstellt. Über folgenden Befehl bekommen Sie diese Generationen und den Unterschied zwischen ihnen angezeigt:

guix package --list-generations

Jetzt kennen Sie die Grundlagen der Paketverwaltung!

Vertiefung: Lesen Sie den Abschnitt zur Paketverwaltung für mehr Informationen dazu. Vielleicht gefällt Ihnen deklarative Paketverwaltung mit guix package --manifest, die Verwaltung separater Profile mit --profile, das Löschen alter Generationen und das „Müllsammeln“ (Garbage Collection) sowie andere raffinierte Funktionalitäten, die sich als nützlich erweisen werden, wenn Sie sich länger mit Guix befassen. Wenn Sie Software entwickeln, lernen Sie im Abschnitt Entwicklung hilfreiche Werkzeuge kennen. Und wenn Sie neugierig sind, wird Ihnen im Abschnitt Funktionalitäten ein Überblick gegeben, wie und nach welchen Prinzipien Guix aufgebaut ist.

Sobald Sie eine Reihe von Paketen installiert haben, werden Sie diese regelmäßig auf deren neueste und beste Version aktualisieren wollen. Dazu ist es erforderlich, dass Sie zunächst die neueste Version von Guix und seiner Paketsammlung mit einem „Pull“ laden:

guix pull

Das Endergebnis ist ein neuer guix-Befehl innerhalb von ~/.config/guix/current/bin. Sofern Sie nicht Guix System benutzen, sollten Sie dem Hinweis Folge leisten, den Sie bei der ersten Ausführung von guix pull angezeigt bekommen, d.h. ähnlich wie oben beschrieben, fügen Sie diese zwei Zeilen in Ihr Terminal und Ihre .bash_profile ein:

GUIX_PROFILE="$HOME/.config/guix/current/etc/profile"
. "$GUIX_PROFILE/etc/profile"

Ebenso müssen Sie Ihre Shell auf diesen neuen guix-Befehl hinweisen:

hash guix

Wenn das geschafft ist, benutzen Sie ein brandneues Guix. Jetzt können Sie damit fortfahren, alle zuvor installierten Pakete zu aktualisieren:

guix upgrade

Während dieser Befehl ausgeführt wird, werden Sie sehen, dass Binärdateien heruntergeladen werden (vielleicht müssen manche Pakete auch auf Ihrem Rechner erstellt werden). Letztendlich stehen Ihnen die aktualisierten Pakete zur Verfügung. Falls eine der Aktualisierungen nicht Ihren Wünschen entspricht, haben Sie immer auch die Möglichkeit, sie auf den alten Stand zurückzusetzen!

Sie können sich anzeigen lassen, welche Version von Guix Sie genau verwenden, indem Sie dies ausführen:

guix describe

Die angezeigten Informationen sind alles, was nötig ist, um genau dasselbe Guix zu installieren. Damit können Sie zu einem anderen Zeitpunkt oder auf einer anderen Maschine genau dieselbe Software nachbilden.

Vertiefung: Siehe Aufruf von guix pull für weitere Informationen. Siehe Kanäle für Erklärungen, wie man zusätzliche Kanäle als Paketquellen angibt, wie man Guix nachbilden kann, und mehr. Vielleicht hilft Ihnen auch die time-machine-Funktion (siehe Aufruf von time-machine).

Wenn Sie Guix System installieren, dürfte eines der ersten Dinge, das Sie tun wollen, eine Aktualisierung Ihres Systems sein. Sobald Sie guix pull ausgeführt haben, können Sie mit diesem Befehl das System aktualisieren:

sudo guix system reconfigure /etc/config.scm

Nach Abschluss läuft auf dem System die neueste Version seiner Software-Pakete. Sobald Sie den Rechner neu starten, wird Ihnen ein Untermenü im Bootloader auffallen, das mit „Old system generations“ bezeichnet wird. Über dieses können Sie eine ältere Generation Ihres Systems starten, falls die neueste Generation auf irgendeine Weise „kaputt“ ist oder auf andere Weise nicht Ihren Wünschen entspricht. Genau wie bei Paketen können Sie jederzeit das gesamte System auf eine vorherige Generation zurücksetzen:

sudo guix system roll-back

Es gibt viele Feineinstellungen, die Sie an Ihrem System wahrscheinlich vornehmen möchten. Vielleicht möchten Sie neue Benutzerkonten oder neue Systemdienste hinzufügen, mit anderen Konfigurationen solcher Dienste experimentieren oder Ähnliches. Die gesamte Systemkonfiguration wird durch die Datei /etc/config.scm beschrieben. Siehe Das Konfigurationssystem nutzen, wo erklärt wird, wie man sie ändert.

Jetzt wissen Sie genug, um anzufangen!

Weitere Ressourcen: Der Rest dieses Handbuchs stellt eine Referenz für alles rund um Guix dar. Hier sind ein paar andere Ressourcen, die sich als nützlich erweisen könnten:

Wir hoffen, dass Ihnen Guix genauso viel Spaß bereitet wie der Guix-Gemeinde bei seiner Entwicklung!


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

5 Paketverwaltung

Der Zweck von GNU Guix ist, Benutzern die leichte Installation, Aktualisierung und Entfernung von Software-Paketen zu ermöglichen, ohne dass sie ihre Erstellungsprozeduren oder Abhängigkeiten kennen müssen. Guix kann natürlich noch mehr als diese offensichtlichen Funktionalitäten.

Dieses Kapitel beschreibt die Hauptfunktionalitäten von Guix, sowie die von Guix angebotenen Paketverwaltungswerkzeuge. Zusätzlich zu den im Folgenden beschriebenen Befehlszeilen-Benutzerschnittstellen (siehe guix package) können Sie auch mit der Emacs-Guix-Schnittstelle (siehe Referenzhandbuch von Emacs-Guix) arbeiten, nachdem Sie das Paket emacs-guix installiert haben (führen Sie zum Einstieg in Emacs-Guix den Emacs-Befehl M-x guix-help aus):

guix install emacs-guix

Nächste: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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 Aufruf von guix package). 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 Aufruf von guix gc). 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 der 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 Aufruf von guix challenge).

Kontrolle über die Erstellungsumgebung ist eine auch für Entwickler nützliche Funktionalität. Der Befehl guix environment 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 Aufruf von guix environment).

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 Aufruf von guix pull). 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.


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.2 guix package aufrufen

Der Befehl guix package ist ein Werkzeug, womit Nutzer Pakete installieren, aktualisieren, entfernen und auf vorherige Konfigurationen zurücksetzen können. 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:

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 "$HOME/.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 Aufruf von guix gc). 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 entweder einfach durch seinen Paketnamen aufgeführt werden, wie guile, oder als Paketname gefolgt von einem At-Zeichen @ und einer Versionsnummer, wie guile@1.8.8 oder auch nur guile@1.8 (in letzterem Fall wird die neueste Version mit Präfix 1.8 ausgewählt.)

Wird keine Versionsnummer angegeben, wird die neueste verfügbare Version ausgewählt. Zudem kann im 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).

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 Aufruf von guix environment).

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 Aufruf von guix pull).

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

In diesem Beispiel müssen wir wissen, welche Module die Variablen emacs und guile-2.0 definieren, um die richtige Angabe mit use-package-modules machen zu können, was umständlich sein kann. Wir können auch normale Paketnamen angeben und sie durch specifications->manifest zu den entsprechenden Paketobjekten auflösen, zum Beispiel so:

(specifications->manifest
 '("emacs" "guile@2.2" "guile@2.2:debug"))
--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.

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=python | recsel -p name,version
name: python
version: 2.7.6

name: python
version: 3.3.5

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 python@3.4 | recsel -p name,version
name: python
version: 3.4.3
--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:

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

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 (siehe Paketumwandlungsoptionen). Beachten Sie jedoch, dass die verwendeten Paketumwandlungsoptionen verloren gehen, nachdem Sie die Pakete aktualisiert haben. Damit Paketumwandlungen über Aktualisierungen hinweg erhalten bleiben, sollten Sie Ihre eigene Paketvariante in einem Guile-Modul definieren und zur Umgebungsvariablen GUIX_PACKAGE_PATH hinzufügen (siehe Pakete definieren).


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.3 Substitute

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

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


Nächste: , Nach oben: Substitute   [Inhalt][Index]

5.3.1 Offizieller Substitut-Server

Der Server ci.guix.gnu.org ist die Fassade für eine offizielle Erstellungsfarm („Build-Farm“), die kontinuierlich Guix-Pakete für einige Prozessorarchitekturen erstellt und sie als Substitute zur Verfügung stellt. Dies ist die standardmäßige Quelle von Substituten; durch Übergeben der Befehlszeilenoption --substitute-urls an entweder den guix-daemon (siehe guix-daemon --substitute-urls) oder Client-Werkzeuge wie guix package (siehe die Befehlszeilenoption --substitute-urls beim Client) kann eine abweichende Einstellung benutzt werden.

Substitut-URLs können entweder HTTP oder HTTPS sein. HTTPS wird empfohlen, weil die Kommunikation verschlüsselt ist; umgekehrt kann bei HTTP die Kommunikation belauscht werden, wodurch der Angreifer zum Beispiel erfahren könnte, ob Ihr System über noch nicht behobene Sicherheitsschwachstellen verfügt.

Substitute von der offiziellen Erstellungsfarm sind standardmäßig erlaubt, wenn Sie Guix System verwenden (siehe GNU-Distribution). Auf Fremddistributionen sind sie allerdings standardmäßig ausgeschaltet, solange Sie sie nicht ausdrücklich in einem der empfohlenen Installationsschritte erlaubt haben (siehe Installation). Die folgenden Absätze beschreiben, wie Sie Substitute für die offizielle Erstellungsfarm an- oder ausschalten; dieselbe Prozedur kann auch benutzt werden, um Substitute für einen beliebigen anderen Substitutserver zu erlauben.


Nächste: , Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.2 Substitut-Server autorisieren

Um es Guix zu gestatten, Substitute von ci.guix.gnu.org oder einem Spiegelserver davon herunterzuladen, müssen Sie den zugehörigen öffentlichen Schlüssel zur Access Control List (ACL, Zugriffssteuerungsliste) für Archivimporte hinzufügen, mit Hilfe des Befehls guix archive (siehe Aufruf von guix archive). Dies impliziert, dass Sie darauf vertrauen, dass ci.guix.gnu.org nicht kompromittiert wurde und unverfälschte Substitute liefert.

Anmerkung: Wenn Sie Guix System benutzen, können Sie diesen Abschnitt hier überspringen, denn Guix System ist so voreingestellt, Substitute von ci.guix.gnu.org zu autorisieren.

Der öffentliche Schlüssel für ci.guix.gnu.org wird zusammen mit Guix installiert, in das Verzeichnis prefix/share/guix/hydra.gnu.org.pub, wobei prefix das bei der Installation angegebene Präfix von Guix ist. Wenn Sie Guix aus seinem Quellcode heraus installieren, sollten Sie sichergehen, dass Sie die GPG-Signatur (auch „Beglaubigung“ genannt) von guix-1.2.0.tar.gz prüfen, worin sich dieser öffentliche Schlüssel befindet. Dann können Sie so etwas wie hier ausführen:

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

Sobald es eingerichtet wurde, sollte sich die Ausgabe eines Befehls wie guix build von so etwas:

$ 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
…

in so etwas verwandeln:

$ 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
…

Der Text hat sich von „Folgende Ableitungen würden erstellt“ zu „112.3 MB würden heruntergeladen“ geändert. Das zeigt an, dass Substitute von ci.guix.gnu.org nutzbar sind und für zukünftige Erstellungen heruntergeladen werden, wann immer es möglich ist.

Der Substitutsmechanismus kann global ausgeschaltet werden, indem Sie dem guix-daemon beim Starten die Befehlszeilenoption --no-substitutes übergeben (siehe Aufruf des guix-daemon). Er kann auch temporär ausgeschaltet werden, indem Sie --no-substitutes an guix package, guix build und andere Befehlszeilenwerkzeuge übergeben.


Nächste: , Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.3 Substitute von anderen Servern holen

Guix kann auf unterschiedlichen Servern nach Substituten schauen und sie von dort laden. Das lohnt sich, wenn Sie Pakete von zusätzlichen Kanälen laden, für die es auf dem offiziellen Server keine Substitute gibt, auf einem anderen aber schon. Eine andere Situation, wo es sich anbietet, ist, wenn Sie Substitute lieber vom Substitutserver beziehen, der zu Ihrer Organisation gehört, und den offiziellen Server nur im Ausnahmefall einsetzen oder ganz weglassen möchten.

Sie können Guix eine Liste von URLs der Substitutserver mitgeben, damit es sie in der angegebenen Reihenfolge anfragt. Außerdem müssen Sie die öffentlichen Schlüssel der Substitutserver ausdrücklich autorisieren, damit Guix von ihnen signierte Substitute annimmt.

Auf Guix System ginge dies vonstatten, indem Sie die Konfiguration des guix-Dienstes modifizieren. Weil der guix-Dienst zu der Liste der vorgegebenen Dienste gehört, sowohl für %base-services als auch für %desktop-services, können Sie dessen Konfiguration mit modify-services ändern und dort die URLs und Substitutschlüssel eintragen, die Sie möchten (siehe modify-services).

Ein Beispiel: Nehmen wir an, Sie möchten Substitute zusätzlich zum vorgegebenen ci.guix.gnu.org von guix.example.org beziehen und den Signierschlüssel dieses Servers autorisieren. Die Betriebssystemkonfiguration, die sich damit ergibt, wird ungefähr so aussehen:

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

Dabei gehen wir davon aus, dass der Signierschlüssel von guix.example.org in der Datei key.pub steht. Sobald Sie diese Änderung an der Datei mit Ihrer Betriebssystemkonfiguration vorgenommen haben (etwa /etc/config.scm), können Sie rekonfigurieren und den guix-daemon-Dienst (oder den ganzen Rechner) neu starten, damit die Änderung in Kraft tritt:

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

Wenn Sie Guix auf einer „Fremddistribution“ laufen lassen, würden Sie stattdessen nach den folgenden Schritten vorgehen, um Substitute von zusätzlichen Servern zu bekommen:

  1. Bearbeiten Sie die Konfigurationsdatei für den guix-daemon; wenn Sie systemd benutzen, wäre das normalerweise /etc/systemd/system/guix-daemon.service. Schreiben Sie in die Konfigurationsdatei die Option --substitute-urls zur guix-daemon-Befehlszeile dazu und listen Sie dabei die gewünschten URLs auf (siehe guix-daemon --substitute-urls):
    … --substitute-urls='https://guix.example.org https://ci.guix.gnu.org'
    
  2. Starten Sie den Daemon neu. Bei systemd geht das so:
    systemctl daemon-reload
    systemctl restart guix-daemon.service
    
  3. Autorisieren Sie den Schlüssel des neuen Servers (siehe Aufruf von guix archive):
    guix archive --authorize < key.pub
    

    Wir nehmen auch hier an, dass key.pub den öffentlichen Schlüssel enthält, mit dem guix.example.org Substitute signiert.

Und wir sind fertig! Substitute werden bevorzugt von https://guix.example.org bezogen und ci.guix.gnu.org bleibt notfalls als Reserve. Natürlich können Sie so viele Substitutserver auflisten, wie Sie wollen, allerdings kann das Erfragen von Substituten etwas länger dauern, wenn zu viele Server kontaktiert werden müssen.

Aber bedenken Sie, es gibt auch Situationen, wo man nur die URL eines Substitutservers hinzufügen will, ohne den Schlüssel zu autorisieren. Siehe Substitutauthentifizierung, um diese bestimmten Gründe zu verstehen.


Nächste: , Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.4 Substitutauthentifizierung

Guix erkennt, wenn ein verfälschtes Substitut benutzt würde, und meldet einen Fehler. Ebenso werden Substitute ignoriert, die nich signiert sind, oder nicht mit einem in der ACL aufgelisteten Schlüssel signiert sind.

Es gibt nur eine Ausnahme: Wenn ein unautorisierter Server Substitute anbietet, die Bit für Bit identisch mit denen von einem autorisierten Server sind, können sie auch vom unautorisierten Server heruntergeladen werden. Zum Beispiel, angenommen wir haben zwei Substitutserver mit dieser Befehlszeilenoption ausgewählt:

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

Wenn in der ACL nur der Schlüssel für ‘b.example.org’ aufgeführt wurde, aber ‘a.example.orgexakt dieselben Substitute anbietet, wird Guix auch Substitute von ‘a.example.org’ herunterladen, weil es in der Liste zuerst kommt und als Spiegelserver für ‘b.example.org’ aufgefasst werden kann. In der Praxis haben unabhängige Maschinen bei der Erstellung normalerweise dieselben Binärdateien als Ergebnis, dank bit-reproduzierbarer Erstellungen (siehe unten).

Wenn Sie HTTPS benutzen, wird das X.509-Zertifikat des Servers nicht validiert (mit anderen Worten, die Identität des Servers wird nicht authentifiziert), entgegen dem, was HTTPS-Clients wie Web-Browser normalerweise tun. Da Guix Substitutinformationen selbst überprüft, wie oben erklärt, wäre es unnötig (wohingegen mit X.509-Zertifikaten geprüft wird, ob ein Domain-Name zu öffentlichen Schlüsseln passt).


Nächste: , Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.5 Proxy-Einstellungen

Substitute werden über HTTP oder HTTPS heruntergeladen. Die Umgebungsvariablen http_proxy und https_proxy können in der Umgebung von guix-daemon definiert werden und wirken sich dann auf das Herunterladen von Substituten aus. Beachten Sie, dass der Wert dieser Variablen in der Umgebung, in der guix build, guix package und andere Client-Befehle ausgeführt werden, keine Rolle spielt.


Nächste: , Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.6 Fehler bei der Substitution

Selbst wenn ein Substitut für eine Ableitung verfügbar ist, schlägt die versuchte Substitution manchmal fehl. Das kann aus vielen Gründen geschehen: die Substitutsserver könnten offline sein, das Substitut könnte kürzlich gelöscht worden sein, die Netzwerkverbindunge könnte unterbrochen worden sein, usw.

Wenn Substitute aktiviert sind und ein Substitut für eine Ableitung zwar verfügbar ist, aber die versuchte Substitution fehlschlägt, kann Guix versuchen, die Ableitung lokal zu erstellen, je nachdem, ob --fallback übergeben wurde (siehe common build option --fallback). Genauer gesagt, wird keine lokale Erstellung durchgeführt, solange kein --fallback angegeben wurde, und die Ableitung wird als Fehlschlag angesehen. Wenn --fallback übergeben wurde, wird Guix versuchen, die Ableitung lokal zu erstellen, und ob die Ableitung erfolgreich ist oder nicht, hängt davon ab, ob die lokale Erstellung erfolgreich ist oder nicht. Beachten Sie, dass, falls Substitute ausgeschaltet oder erst gar kein Substitut verfügbar ist, immer eine lokale Erstellung durchgeführt wird, egal ob --fallback übergeben wurde oder nicht.

Um eine Vorstellung zu bekommen, wie viele Substitute gerade verfügbar sind, können Sie den Befehl guix weather benutzen (siehe Aufruf von guix weather). Dieser Befehl zeigt Statistiken darüber an, wie es um die von einem Server verfügbaren Substitute steht.


Vorige: , Nach oben: Substitute   [Inhalt][Index]

5.3.7 Vom Vertrauen gegenüber Binärdateien

Derzeit hängt die Kontrolle jedes Individuums über seine Rechner von Institutionen, Unternehmen und solchen Gruppierungen ab, die über genug Macht und Entschlusskraft verfügen, die Rechnerinfrastruktur zu sabotieren und ihre Schwachstellen auszunutzen. Auch wenn es bequem ist, Substitute von ci.guix.gnu.org zu benutzen, ermuntern wir Nutzer, auch selbst Erstellungen durchzuführen oder gar ihre eigene Erstellungsfarm zu betreiben, damit ci.guix.gnu.org ein weniger interessantes Ziel wird. Eine Art, uns zu helfen, ist, die von Ihnen erstellte Software mit dem Befehl guix publish zu veröffentlichen, damit andere eine größere Auswahl haben, von welchem Server sie Substitute beziehen möchten (siehe Aufruf von guix publish).

Guix hat die richtigen Grundlagen, um die Reproduzierbarkeit von Erstellungen zu maximieren (siehe Funktionalitäten). In den meisten Fällen sollten unabhängige Erstellungen eines bestimmten Pakets zu bitweise identischen Ergebnissen führen. Wir können also mit Hilfe einer vielschichtigen Menge an unabhängigen Paketerstellungen die Integrität unseres Systems besser gewährleisten. Der Befehl guix challenge hat das Ziel, Nutzern zu ermöglichen, Substitutserver zu beurteilen, und Entwickler dabei zu unterstützen, nichtdeterministische Paketerstellungen zu finden (siehe Aufruf von guix challenge). Ebenso ermöglicht es die Befehlszeilenoption --check von guix build, dass Nutzer bereits installierte Substitute auf Unverfälschtheit zu prüfen, indem sie durch lokales Erstellen nachgebildet werden (siehe guix build --check).

In Zukunft wollen wir, dass Sie mit Guix Binärdateien von Netzwerkteilnehmer zu Netzwerkteilnehmer („peer-to-peer“) veröffentlichen und empfangen können. Wenn Sie mit uns dieses Projekt diskutieren möchten, kommen Sie auf unsere Mailing-Liste guix-devel@gnu.org.


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.4 Pakete mit mehreren Ausgaben.

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

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

guix install glib

Der Befehl, um die Dokumentation zu installieren, ist:

guix install glib:doc

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 Aufruf von guix size). guix graph kann auch helfen (siehe Aufruf von guix graph).

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 Aufruf von guix package).


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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 Aufruf von guix package).

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 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 Aufruf von guix size erklärt ein Werkzeug, um den Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe Aufruf von guix graph 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.


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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	Jun 10 2018 00:18:18
  guix 65956ad
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Generation 2	Jun 11 2018 11:02:49
  guix e0cc7f6
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d
  2 new packages: keepalived, libnfnetlink
  6 packages upgraded: emacs-nix-mode@2.0.4,
    guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac,
    heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4

Generation 3	Jun 13 2018 23:31:07	(current)
  guix 844cc1c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: 844cc1c8f394f03b404c5bb3aee086922373490c
  28 new packages: emacs-helm-ls-git, emacs-helm-mu, …
  69 packages upgraded: borg@1.1.6, cheese@3.28.0, …

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 Aufruf von guix package). 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 Aufruf von guix package), 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 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

Die Liste anzeigen, welche Pakete seit der vorherigen Generation hinzugefügt oder aktualisiert wurden, und gelegentlich auch, welche Neuigkeiten die Kanalautoren für ihre Nutzer geschrieben haben (siehe Kanalneuigkeiten verfassen).

Die Paketinformationen sind dieselben, die auch nach Abschluss von guix pull angezeigt werden, aber ohne Auslassungen; sie ähnelt auch der Ausgabe von guix pull -l für die neueste Generation (siehe unten).

--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 Aufruf von guix package).

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


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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 Aufruf von guix describe).

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 Aufruf von guix pull):

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


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.8 Untergeordnete

Anmerkung: Die hier beschriebenen Funktionalitäten sind in der Version 1.2.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 Aufruf von guix repl) 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 Aufruf von guix package); 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.


Nächste: , Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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	Sep 03 2018 17:32:44	(current)
  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,

Kanäle

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

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.


Vorige: , Nach oben: Paketverwaltung   [Inhalt][Index]

5.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 Aufruf von guix pack.

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 Aufruf von guix package). 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 Aufruf von guix copy).

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 Aufruf von guix challenge).

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

Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

6 Kanäle

Guix und die Sammlung darin verfügbarer Pakete können Sie durch Ausführen von guix pull aktualisieren (siehe Aufruf von guix pull). Standardmäßig lädt guix pull Guix selbst vom offiziellen Repository von GNU Guix herunter und installiert es. Diesen Vorgang können Sie anpassen, indem Sie Kanäle in der Datei ~/.config/guix/channels.scm angeben. Ein Kanal enthält eine Angabe einer URL und eines Branches eines zu installierenden Git-Repositorys. Sie können guix pull veranlassen, die Aktualisierungen von einem oder mehreren Kanälen zu beziehen. Mit anderen Worten können Kanäle benutzt werden, um Guix anzupassen und zu erweitern, wie wir im Folgenden sehen werden. Guix ist in der Lage, dabei Sicherheitsbedenken zu berücksichtigen und Aktualisierungen zu authentifizieren.


Nächste: , Nach oben: Kanäle   [Inhalt][Index]

6.1 Weitere Kanäle angeben

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

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

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

$ guix pull --list-generations
…
Generation 19	Aug 27 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
  11 new packages: gimp-variante, emacs-variante-mit-coolen-features, …
  4 packages upgraded: emacs-racket-mode@0.0.2-2.1b78827, …

Obige Ausgabe von guix pull zeigt an, dass Generation 19 sowohl Guix als auch Pakete aus dem Kanal paketvarianten enthält. Unter den aufgeführten neuen und aktualisierten Paketen kommen vielleicht manche wie gimp-variante und emacs-variante-mit-coolen-features aus paketvarianten, während andere aus dem Standard-Guix-Kanal kommen.


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

6.2 Eigenen Guix-Kanal benutzen

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

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

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


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

6.3 Guix nachbilden

Die Ausgabe von guix pull --list-generations oben zeigt genau, aus welchen Commits diese Guix-Instanz erstellt wurde. Wir können Guix so zum Beispiel auf einer anderen Maschine nachbilden, indem wir eine Kanalspezifikation in ~/.config/guix/channels.scm 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")))

Der Befehl guix describe --format=channels kann diese Kanalliste sogar direkt erzeugen (siehe Aufruf von guix describe). Die erzeugte Datei kann mit den -C genannten Befehlszeilenoptionen von guix pull (siehe Aufruf von guix pull) oder von guix time-machine (siehe Aufruf von time-machine) benutzt werden.

Somit läuft auf beiden Maschinen genau dasselbe Guix und es hat Zugang zu genau denselben Paketen. Die Ausgabe von guix build gimp auf der einen Maschine wird Bit für Bit genau dieselbe wie die desselben Befehls auf der anderen Maschine sein. Das bedeutet auch, dass beide Maschinen Zugang zum gesamten Quellcode von Guix und daher auch transitiv Zugang zum Quellcode jedes davon definierten Pakets haben.

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.


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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

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


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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

Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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

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 Commiter 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 Aufruf von guix git authenticate 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.


Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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


Vorige: , Nach oben: Kanäle   [Inhalt][Index]

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


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

7 Entwicklung

Wenn Sie ein Software-Entwickler sind, gibt Ihnen Guix Werkzeuge an die Hand, die Sie für hilfreich erachten dürften — ganz unabhängig davon, in welcher Sprache Sie entwickeln. Darum soll es in diesem Kapitel gehen.

Der Befehl guix environment stellt eine bequeme Möglichkeit dar, wie Sie eine Entwicklungsumgebung aufsetzen können, in der all die Abhängigkeiten und Werkzeuge enthalten sind, die Sie brauchen, wenn Sie an Ihrem Lieblingssoftwarepaket arbeiten. Der Befehl guix pack macht es Ihnen möglich, Anwendungsbündel zu erstellen, die leicht an Nutzer verteilt werden können, die kein Guix benutzen.


Nächste: , Nach oben: Entwicklung   [Inhalt][Index]

7.1 guix environment aufrufen

Der Zweck von guix environment ist es, Hacker beim Aufbau einer reproduzierbaren Entwicklungsumgebung zu unterstützen, ohne dass diese ihr Paketprofil verunreinigen müssen. Das Werkzeug guix environment nimmt eines oder mehrere Pakete entgegen und erstellt erst all ihre Eingaben, um dann eine Shell-Umgebung herzustellen, in der diese benutzt werden können.

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

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 2.7 und NumPy enthalten sind:

guix environment --ad-hoc python2-numpy python-2.7 -- python

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.

--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. Aufruf von guix gc 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 `(("autoconf" ,autoconf-2.64)
                   ("automake" ,automake)
                   ("texinfo" ,texinfo)
                   ,@(package-native-inputs gdb))))
--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.

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

--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,12 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

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


Nächste: , Vorige: , Nach oben: Entwicklung   [Inhalt][Index]

7.2 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 Aufruf von guix copy, Aufruf von guix publish und Aufruf von guix archive 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 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 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 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.

--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 zweimal13 ü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 /mybin=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.

--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-Konfigurationstripel 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 Aufruf von guix gc). 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).


Nächste: , Vorige: , Nach oben: Entwicklung   [Inhalt][Index]

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


Vorige: , Nach oben: Entwicklung   [Inhalt][Index]

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


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

8 Programmierschnittstelle

GNU Guix bietet mehrere Programmierschnittstellen (APIs) in der Programmiersprache Scheme an, mit denen Software-Pakete definiert, erstellt und gesucht werden können. Die erste Schnittstelle erlaubt es Nutzern, ihre eigenen Paketdefinitionen in einer Hochsprache zu schreiben. Diese Definitionen nehmen Bezug auf geläufige Konzepte der Paketverwaltung, wie den Namen und die Version eines Pakets, sein Erstellungssystem (Build System) und seine Abhängigkeiten (Dependencies). Diese Definitionen können dann in konkrete Erstellungsaktionen umgewandelt werden.

Erstellungsaktionen werden vom Guix-Daemon für dessen Nutzer durchgeführt. Bei einer normalen Konfiguration hat der Daemon Schreibzugriff auf den Store, also das Verzeichnis /gnu/store, Nutzer hingegen nicht. Die empfohlene Konfiguration lässt den Daemon die Erstellungen in chroot-Umgebungen durchführen, mit eigenen Benutzerkonten für „Erstellungsbenutzer“, um gegenseitige Beeinflussung der Erstellung und des übrigen Systems zu minimieren.

Systemnahe APIs stehen zur Verfügung, um mit dem Daemon und dem Store zu interagieren. Um den Daemon anzuweisen, eine Erstellungsaktion durchzuführen, versorgen ihn Nutzer jeweils mit einer Ableitung. Eine Ableitung ist, wie durchzuführende Erstellungsaktionen, sowie die Umgebungen, in denen sie durchzuführen sind, in Guix eigentlich intern dargestellt werden. Ableitungen verhalten sich zu Paketdefinitionen vergleichbar mit Assembler-Code zu C-Programmen. Der Begriff „Ableitung“ kommt daher, dass Erstellungsergebnisse daraus abgeleitet werden.

Dieses Kapitel beschreibt der Reihe nach all diese Programmierschnittstellen (APIs), angefangen mit hochsprachlichen Paketdefinitionen.


Nächste: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.1 Paketmodule

Aus Programmierersicht werden die Paketdefinitionen der GNU-Distribution als Guile-Module in Namensräumen wie (gnu packages …) sichtbar gemacht14 (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)15. 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.


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.2 Pakete definieren

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

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

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs `(("gawk" ,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 Aufruf von guix import).

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:

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

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 Aufruf von guix edit). Unter Paketrichtlinien finden Sie mehr Informationen darüber, wie Sie Paketdefinitionen testen, und unter Aufruf von guix lint 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 Aufruf von guix refresh).

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.


Nächste: , Nach oben: Pakete definieren   [Inhalt][Index]

8.2.1 package-Referenz

Dieser Abschnitt fasst alle in package-Deklarationen zur Verfügung stehenden Optionen zusammen (siehe Pakete definieren).

Datentyp: package

Dieser Datentyp steht für ein Paketrezept.

name

Der Name des Pakets als Zeichenkette.

version

Die Version des Pakets als Zeichenkette.

source

Ein Objekt, das beschreibt, wie der Quellcode des Pakets bezogen werden soll. Meistens ist es ein origin-Objekt, welches für eine aus dem Internet heruntergeladene Datei steht (siehe „origin“-Referenz). Es kann aber auch ein beliebiges anderes „dateiähnliches“ Objekt sein, wie z.B. ein local-file, was eine Datei im lokalen Dateisystem bezeichnet (siehe local-file).

build-system

Das Erstellungssystem, mit dem das Paket erstellt werden soll (siehe Erstellungssysteme).

arguments (Vorgabe: '())

Die Argumente, die an das Erstellungssystem übergeben werden sollen. Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren.

inputs (Vorgabe: '())
native-inputs (Vorgabe: '())
propagated-inputs (Vorgabe: '())

In diesen Feldern werden die Abhängigkeiten des Pakets aufgeführt. Jedes dieser Felder enthält eine Liste von Tupeln, wobei jedes Tupel eine Bezeichnung für die Eingabe (als Zeichenkette) als erstes Element, dann ein „package“-, „origin“- oder „derivation“-Objekt (Paket, Ursprung oder Ableitung) als zweites Element und optional die Benennung der davon zu benutzenden Ausgabe umfasst; letztere hat als Vorgabewert "out" (siehe Pakete mit mehreren Ausgaben. für mehr Informationen zu Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:

`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;Ausgabe "bin" von Glib

Die Unterscheidung zwischen native-inputs und inputs ist wichtig, damit Cross-Kompilieren möglich ist. Beim Cross-Kompilieren werden als inputs aufgeführte Abhängigkeiten für die Ziel-Prozessorarchitektur (target) erstellt, andersherum werden als native-inputs aufgeführte Abhängigkeiten für die Prozessorarchitektur der erstellenden Maschine (build) erstellt.

native-inputs listet typischerweise die Werkzeuge auf, die während der Erstellung gebraucht werden, aber nicht zur Laufzeit des Programms gebraucht werden. Beispiele sind Autoconf, Automake, pkg-config, Gettext oder Bison. guix lint kann melden, ob wahrscheinlich Fehler in der Auflistung sind (siehe Aufruf von guix lint).

Schließlich ist propagated-inputs ähnlich wie inputs, aber die angegebenen Pakete werden automatisch mit ins Profil installiert (siehe die Rolle von Profilen in Guix), wenn das Paket installiert wird, zu dem sie gehören (siehe guix package für Informationen darüber, wie guix package mit propagierten Eingaben umgeht).

Dies ist zum Beispiel nötig, wenn Sie ein Paket für eine C-/C++-Bibliothek schreiben, die Header-Dateien einer anderen Bibliothek braucht, um mit ihr kompilieren zu können, oder wenn sich eine pkg-config-Datei auf eine andere über ihren Requires-Eintrag bezieht.

Noch ein Beispiel, wo propagated-inputs nützlich ist, sind Sprachen, die den Laufzeit-Suchpfad nicht zusammen mit dem Programm abspeichern (nicht wie etwa im RUNPATH bei ELF-Dateien), also Sprachen wie Guile, Python, Perl und weitere. Wenn Sie ein Paket für eine in solchen Sprachen geschriebene Bibliothek schreiben, dann sorgen Sie dafür, dass es zur Laufzeit den von ihr benötigten Code finden kann, indem Sie ihre Laufzeit-Abhängigkeiten in propagated-inputs statt in inputs aufführen.

outputs (Vorgabe: '("out"))

Die Liste der Benennungen der Ausgaben des Pakets. Der Abschnitt Pakete mit mehreren Ausgaben. beschreibt übliche Nutzungen zusätzlicher Ausgaben.

native-search-paths (Vorgabe: '())
search-paths (Vorgabe: '())

Eine Liste von search-path-specification-Objekten, die Umgebungsvariable für von diesem Paket beachtete Suchpfade („search paths“) beschreiben.

replacement (Vorgabe: #f)

Dies muss entweder #f oder ein package-Objekt sein, das als Ersatz (replacement) dieses Pakets benutzt werden soll. Im Abschnitt zu Veredelungen wird dies erklärt.

synopsis

Eine einzeilige Beschreibung des Pakets.

description

Eine ausführlichere Beschreibung des Pakets.

license

Die Lizenz des Pakets; benutzt werden kann ein Wert aus dem Modul (guix licenses) oder eine Liste solcher Werte.

home-page

Die URL, die die Homepage des Pakets angibt, als Zeichenkette.

supported-systems (Vorgabe: %supported-systems)

Die Liste der vom Paket unterstützten Systeme als Zeichenketten der Form Architektur-Kernel, zum Beispiel "x86_64-linux".

location (Vorgabe: die Stelle im Quellcode, wo die package-Form steht)

Wo im Quellcode das Paket definiert wurde. Es ist sinnvoll, dieses Feld manuell zuzuweisen, wenn das Paket von einem anderen Paket erbt, weil dann dieses Feld nicht automatisch berichtigt wird.

Scheme-Syntax: this-package

Wenn dies im lexikalischen Geltungsbereich der Definition eines Feldes im Paket steht, bezieht sich dieser Bezeichner auf das Paket, das gerade definiert wird.

Das folgende Beispiel zeigt, wie man ein Paket als native Eingabe von sich selbst beim Cross-Kompilieren deklariert:

(package
  (name "guile")
  ;; …

  ;; Wenn es cross-kompiliert wird, hängt zum Beispiel
  ;; Guile von einer nativen Version von sich selbst ab.
  ;; Wir fügen sie hier hinzu.
  (native-inputs (if (%current-target-system)
                     `(("self" ,this-package))
                     '())))

Es ist ein Fehler, außerhalb einer Paketdefinition auf this-package zu verweisen.

Weil Pakete herkömmliche Scheme-Objekte sind, die einen vollständigen Abhängigkeitsgraphen und die zugehörigen Erstellungsprozeduren umfassen, bietet es sich oftmals an, Prozeduren zu schreiben, die ein Paket entgegennehmen und in Abhängigkeit bestimmter Parameter eine abgeänderte Fassung desselben zurückliefern. Es folgen einige Beispiele.

Scheme-Prozedur: package-with-c-toolchain Paket Toolchain

Liefert eine Variante des Pakets, die die angegebene Toolchain anstelle der vorgegebenen GNU-C/C++-Toolchain benutzt. Als Toolchain muss eine Liste von Eingaben (als Tupel aus Bezeichnung und bezeichnetem Paket) angegeben werden, die eine gleichartige Funktion erfüllen, wie zum Beispiel das Paket gcc-toolchain.

Das folgende Beispiel liefert eine Variante des Pakets hello, die mit GCC 10.x und den übrigen Komponenten der GNU-Toolchain (Binutils und GNU-C-Bibliothek) erstellt wurde statt mit der vorgegebenen Toolchain:

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

Die Erstellungs-Toolchain gehört zu den impliziten Eingaben von Paketen — sie wird normalerweise nicht ausdrücklich unter den verschiedenen „inputs“-Feldern mit verschiedenen Arten von Eingaben aufgeführt, stattdessen kommt sie über das Erstellungssystem dazu. Daher funktioniert diese Prozedur intern so, dass sie das Erstellungssystem des Pakets verändert, damit es die ausgewählte Toolchain statt der vorgegebenen benutzt. Siehe Erstellungssysteme für weitere Informationen zu Erstellungssystemen.


Vorige: , Nach oben: Pakete definieren   [Inhalt][Index]

8.2.2 origin-Referenz

In diesem Abschnitt werden Paketursprünge — englisch Origins — beschrieben. Eine origin-Deklaration legt Daten fest, die „produziert“ werden müssen — normalerweise heißt das heruntergeladen. Die Hash-Prüfsumme von deren Inhalt muss dabei im Voraus bekannt sein. Ursprünge werden in erster Linie benutzt, um den Quellcode von Paketen zu repräsentieren (siehe Pakete definieren). Aus diesem Grund können Sie mit der origin-Form Patches angeben, die auf den ursprünglichen Quellcode angewandt werden sollen, oder auch Schnipsel von Code, der Veränderungen daran vornimmt.

Datentyp: origin

Mit diesem Datentyp wird ein Ursprung, von dem Quellcode geladen werden kann, beschrieben.

uri

Ein Objekt, was die URI des Quellcodes enthält. Der Objekttyp hängt von der Methode ab (siehe unten). Zum Beispiel sind, wenn die url-fetch-Methode aus (guix download) benutzt wird, die gültigen Werte für uri: eine URL dargestellt als Zeichenkette oder eine Liste solcher URLs.

method

Eine monadische Prozedur, um die angegebene URL zu benutzen. Die Prozedur muss mindestens drei Argumente akzeptieren: den Wert des uri-Feldes, den Hash-Algorithmus und den Hash-Wert, der im hash-Feld angegeben wird. Sie muss ein Store-Objekt oder eine Ableitung in der Store-Monade liefern (siehe Die Store-Monade). Die meisten Methoden liefern eine Ableitung mit fester Ausgabe (siehe Ableitungen).

Zu den häufig benutzten Methoden gehören url-fetch, das Daten von einer URL lädt, und git-fetch, das Daten aus einem Git-Repository lädt (siehe unten).

sha256

Ein Byte-Vektor mit dem SHA-256-Hash des Quellcodes. Seine Funktion ist dieselbe wie das Angeben eines content-hash-SHA256-Objekts im weiter unten beschriebenen hash-Feld.

hash

Das content-hash-Objekt des Quellcodes. Siehe unten für eine Erklärung, wie Sie content-hash benutzen.

Diese Informationen liefert Ihnen der Befehl guix download (siehe Aufruf von guix download) oder guix hash (siehe Aufruf von guix hash).

file-name (Vorgabe: #f)

Der Dateiname, unter dem der Quellcode abgespeichert werden soll. Wenn er auf #f steht, wird ein vernünftiger Name automatisch gewählt. Falls der Quellcode von einer URL geladen wird, wird der Dateiname aus der URL genommen. Wenn der Quellcode von einem Versionskontrollsystem bezogen wird, empfiehlt es sich, den Dateinamen ausdrücklich anzugeben, weil dann keine sprechende Benennung automatisch gefunden werden kann.

patches (Vorgabe: '())

Eine Liste von Dateinamen, Ursprüngen oder dateiähnlichen Objekten (siehe dateiartige Objekte) mit Patches, welche auf den Quellcode anzuwenden sind.

Die Liste von Patches kann nicht von Parametern der Erstellung abhängen. Insbesondere kann sie nicht vom Wert von %current-system oder %current-target-system abḧängen.

snippet (Vorgabe: #f)

Ein im Quellcode-Verzeichnis auszuführender G-Ausdruck (siehe G-Ausdrücke) oder S-Ausdruck. Hiermit kann der Quellcode bequem modifiziert werden, manchmal ist dies bequemer als mit einem Patch.

patch-flags (Vorgabe: '("-p1"))

Eine Liste der Befehlszeilenoptionen, die dem patch-Befehl übergeben werden sollen.

patch-inputs (Vorgabe: #f)

Eingabepakete oder -ableitungen für den Patch-Prozess. Bei #f werden die üblichen Patcheingaben wie GNU Patch bereitgestellt.

modules (Vorgabe: '())

Eine Liste von Guile-Modulen, die während des Patch-Prozesses und während der Ausführung des snippet-Felds geladen sein sollen.

patch-guile (Vorgabe: #f)

Welches Guile-Paket für den Patch-Prozess benutzt werden soll. Bei #f wird ein vernünftiger Vorgabewert angenommen.

Datentyp: content-hash Wert [Algorithmus]

Erzeugt ein Inhaltshash-Objekt für den gegebenen Algorithmus und benutzt dabei den Wert als dessen Hashwert. Wenn kein Algorithmus angegeben wird, wird sha256 angenommen.

Als Wert kann ein Zeichenketten-Literal, was base32-dekodiert wird, oder ein Byte-Vektor angegeben werden.

Folgende Formen sind äquivalent:

(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
              sha256)
(content-hash (base32
               "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
(content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
              sha256)

Als interne Implementierung wird für content-hash derzeit ein Makro benutzt. Es überprüft, wenn möglich, zum Zeitpunkt der Makroumschreibung, ob die Angaben in Ordnung sind, z.B. ob der Wert die richtige Größe für den angegebenen Algorithmus hat.

Wie wir oben gesehen haben, hängt es von der im method-Feld angegebenen Methode ab, wie die in einem Paketursprung verwiesenen Daten geladen werden. Das Modul (guix download) stellt die am häufigsten benutzte Methode zur Verfügung, nämlich url-fetch, die im Folgenden beschrieben wird.

Scheme-Prozedur: url-fetch URL Hash-Algo Hash [name] [#:executable? #f] Liefert eine Ableitung mit fester Ausgabe, die

Daten von der URL lädt (einer Zeichenkette oder Liste von Zeichenketten für alternativ mögliche URLs). Es wird erwartet, dass die Daten Hash als Prüfsumme haben, gemäß dem Algorithmus, der in Hash-Algo (einem Symbol) angegebenen wurde. Nach Vorgabe ergibt sich der Dateiname aus dem Basisnamen der URL; optional kann in name ein anderslautender Name festgelegt werden. Wenn executable? wahr ist, wird die heruntergeladene Datei als ausführbar markiert.

Wenn eine der URL mit mirror:// beginnt, wird der „Host Part“ an deren Anfang als Name eines Spiegelserver-Schemas aufgefasst, wie es in %mirror-file steht.

Alternativ wird, wenn die URL mit file:// beginnt, der zugehörige Dateiname in den Store eingefügt und zurückgeliefert.

Ebenso ist im Modul (guix git-download) die git-fetch-Methode für Paketursprünge definiert. Sie lädt Daten aus einem Repository des Versionskontrollsystems Git. Der Datentyp git-reference beschreibt dabei das Repository und den daraus zu ladenden Commit.

Scheme-Prozedur: git-fetch Ref Hash-Algo Hash

Liefert eine Ableitung mit fester Ausgabe, die Ref lädt, ein <git-reference>-Objekt. Es wird erwartet, dass die Ausgabe rekursiv die Prüfsumme Hash aufweist (ein „rekursiver Hash“) gemäß dem Typ Hash-Algo (einem Symbol). Als Dateiname wird name verwendet, oder ein generischer Name, falls name #f ist.

Datentyp: git-reference

Dieser Datentyp steht für eine Git-Referenz, die git-fetch laden soll.

url

Die URL des zu klonenden Git-Repositorys.

commit

Diese Zeichenkette gibt entweder den zu ladenden Commit an (eine Zeichenkette aus Hexadezimalzeichen, entweder der vollständige SHA1-Commit oder eine „kurze“ Commit-Zeichenkette, aber wir raten vom Verkürzen ab) oder sie entspricht dem zu ladenden Tag.

recursive? (Vorgabe: #f)

Dieser boolesche Wert gibt an, ob Git-Submodule rekursiv geladen werden sollen.

Im folgenden Beispiel wird der Tag v2.10 des Repositorys für GNU Hello bezeichnet:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "v2.10"))

Das ist äquivalent zu folgender Referenz, wo der Commit ausdrücklich benannt wird:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "dc7dc56a00e48fe6f231a58f6537139fe2908fb9"))

Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.3 Paketvarianten definieren

Eine der schönen Sachen an Guix ist, dass Sie aus einer Paketdefinition leicht Varianten desselben Pakets ableiten können — solche, die vom Anbieter eine andere Paketversion nehmen, als im Guix-Repository angegeben, solche mit anderen Abhängigkeiten, anders gearteten Compiler-Optionen und mehr. Manche dieser eigenen Pakete lassen sich direkt aus der Befehlszeile definieren (siehe Paketumwandlungsoptionen). Dieser Abschnitt beschreibt, wie man Paketvarianten mit Code definiert. Das kann in „Manifesten“ nützlich sein (siehe --manifest) und in Ihrer eigenen Paketsammlung (siehe Einen Kanal erstellen), unter anderem!

Wie zuvor erörtert, sind Pakete Objekte erster Klasse in der Scheme-Sprache. Das Modul (guix packages) stellt das package-Konstrukt zur Verfügung, mit dem neue Paketobjekte definiert werden können (siehe „package“-Referenz). Am einfachsten ist es, eine Paketvariante zu definieren, indem Sie das inherit-Schlüsselwort mit einem package-Objekt verwenden. Dadurch können Sie die Felder einer Paketdefinition erben lassen, aber die Felder selbst festlegen, die Sie festlegen möchten.

Betrachten wir zum Beispiel die Variable hello, die eine Definition für die aktuelle Version von GNU Hello enthält. So können Sie eine Variante für Version 2.2 definieren (welche 2006 veröffentlicht wurde — ein guter Jahrgang!):

(use-modules (gnu packages base))    ;für „hello“

(define hello-2.2
  (package
    (inherit hello)
    (version "2.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0lappv4slgb5spyqbh6yl5r013zv72yqg2pcl30mginf3wdqd8k9"))))))

Das obige Beispiel entspricht dem, was Sie mit der Paketumwandlungsoption --with-source erreichen können. Im Kern erhält hello-2.2 alle Felder von hello mit Ausnahme von version und source, die ersetzt werden (die beiden unterliegen einem „Override“). Beachten Sie, dass es die ursprüngliche hello-Variable weiterhin gibt, sie bleibt unverändert in dem Modul (gnu packages base). Wenn Sie auf diese Weise ein eigenes Paket definieren, fügen Sie tatsächlich eine neue Paketdefinition hinzu; das Original bleibt erhalten.

Genauso gut können Sie Varianten mit einer anderen Menge von Abhängigkeiten als im ursprünglichen Paket definieren. Zum Beispiel hängt das vorgegebene gdb-Paket von guile ab, aber weil es eine optionale Abhängigkeit ist, können Sie eine Variante definieren, die jene Abhängigkeit entfernt, etwa so:

(use-modules (gnu packages gdb)    ;für 'gdb'
             (srfi srfi-1))        ;für 'alist-delete'

(define gdb-sans-guile
  (package
    (inherit gdb)
    (inputs (alist-delete "guile"
                          (package-inputs gdb)))))

Der obige Aufruf von alist-delete entfernt das Tupel aus dem inputs-Feld, dessen erstes Element "guile" ist (siehe SRFI-1 Association Lists in Referenzhandbuch zu GNU Guile).

Manchmal bietet es sich an, Funktionen (also „Prozeduren“, wie Scheme-Anwender sagen) zu schreiben, die ein Paket abhängig von bestimmten Parametern zurückliefern. Als Beispiel betrachten wir die luasocket-Bibliothek für die Programmiersprache Lua. Wir möchten luasocket-Pakete für die hauptsächlichen Versionen von Lua verfügbar machen. Eine Möglichkeit, das zu erreichen, ist, eine Prozedur zu definieren, die ein Lua-Paket nimmt und ein von diesem abhängiges luasocket-Paket liefert.

(define (make-lua-socket name lua)
  ;; Liefert ein luasocket-Paket, das mit LUA erstellt wird.
  (package
    (name name)
    (version "3.0")
    ;; hier würden noch ein paar Felder stehen
    (inputs
     `(("lua" ,lua)))
    (synopsis "Socket library for Lua")))

(define-public lua5.1-socket
  (make-lua-socket "lua5.1-socket" lua-5.1))

(define-public lua5.2-socket
  (make-lua-socket "lua5.2-socket" lua-5.2))

Damit haben wir Pakete lua5.1-socket und lua5.2-socket definiert, indem wir make-lua-socket mit verschiedenen Argumenten aufgerufen haben. Siehe Procedures in Referenzhandbuch von GNU Guile für mehr Informationen über Prozeduren. Weil wir mit define-public öffentlich sichtbare Definitionen auf oberster Ebene („top-level“) für diese beiden Pakete angegeben haben, kann man sie von der Befehlszeile aus benutzen (siehe Paketmodule).

Bei diesen handelt es sich um sehr einfache Paketvarianten. Bequemer ist es dann, mit dem Modul (guix transformations) eine hochsprachliche Schnittstelle einzusetzen, die auf die komplexeren Paketumwandlungsoptionen direkt abbildet (siehe Paketumwandlungsoptionen):

Scheme-Prozedur: options->transformation Optionen

Liefert eine Prozedur, die gegeben ein zu erstellendes Objekt (ein Paket, eine Ableitung oder Ähnliches) die durch Optionen festgelegten Umwandlungen daran umsetzt und die sich ergebenden Objekte zurückliefert. Optionen muss eine Liste von Paaren aus Symbol und Zeichenkette sein wie:

((with-branch . "guile-gcrypt=master")
 (without-tests . "libgcrypt"))

Jedes Symbol benennt eine Umwandlung. Die entsprechende Zeichenkette ist ein Argument an diese Umwandlung.

Zum Beispiel wäre ein gleichwertiges Manifest zu diesem Befehl:

guix build guix \
  --with-branch=guile-gcrypt=master \
  --with-debug-info=zlib

… dieses hier:

(use-modules (guix transformations))

(define transform
  ;; Die Prozedur zur Paketumwandlung.
  (options->transformation
   '((with-branch . "guile-gcrypt=master")
     (with-debug-info . "zlib"))))

(packages->manifest
 (list (transform (specification->package "guix"))))

Die Prozedur options->transformation lässt sich einfach benutzen, ist aber vielleicht nicht so flexibel, wie Sie es sich wünschen. Wie sieht ihre Implementierung aus? Aufmerksamen Lesern mag aufgefallen sein, dass die meisten Paketumwandlungen die oberflächlichen Änderungen aus den ersten Beispielen in diesem Abschnitt übersteigen: Sie schreiben Eingaben um, was im Abhängigkeitsgraphen bestimmte Eingaben durch andere ersetzt.

Das Umschreiben des Abhängigkeitsgraphen, damit Pakete im Graphen ausgetauscht werden, ist in der Prozedur package-input-rewriting aus (guix packages) implementiert.

Scheme-Prozedur: package-input-rewriting Ersetzungen [umgeschriebener-Name] [#:deep? #t] Eine Prozedur liefern, die für ein

ihr übergebenes Paket dessen direkte und indirekte Abhängigkeit gemäß den Ersetzungen umschreibt, einschließlich ihrer impliziten Eingaben, wenn deep? wahr ist. Ersetzungen ist eine Liste von Paketpaaren; das erste Element eines Paares ist das zu ersetzende Paket und das zweite ist, wodurch es ersetzt werden soll.

Optional kann als umgeschriebener-Name eine ein Argument nehmende Prozedur angegeben werden, die einen Paketnamen nimmt und den Namen nach dem Umschreiben zurückliefert.

Betrachten Sie dieses Beispiel:

(define libressl-statt-openssl
  ;; Dies ist eine Prozedur, mit der OPENSSL durch LIBRESSL
  ;; rekursiv ersetzt wird.
  (package-input-rewriting `((,openssl . ,libressl))))

(define git-mit-libressl
  (libressl-statt-openssl git))

Hier definieren wir zuerst eine Umschreibeprozedur, die openssl durch libressl ersetzt. Dann definieren wir damit eine Variante des git-Pakets, die libressl statt openssl benutzt. Das ist genau, was auch die Befehlszeilenoption --with-input tut (siehe --with-input).

Die folgende Variante von package-input-rewriting kann für die Ersetzung passende Pakete anhand ihres Namens finden, statt zu prüfen, ob der Wert identisch ist.

Scheme-Prozedur: package-input-rewriting/spec Ersetzungen [#:deep? #t]

Liefert eine Prozedur, die für ein gegebenes Paket die angegebenen Ersetzungen auf dessen gesamten Paketgraphen anwendet (einschließlich impliziter Eingaben, außer wenn deep? falsch ist). Ersetzungen muss dabei eine Liste von Paaren aus je einer Spezifikation und Prozedur sein. Dabei ist jede Spezifikation eine Paketspezifikation wie "gcc" oder "guile@2" und jede Prozedur nimmt ein passendes Paket und liefert dafür einen Ersatz für das Paket.

Das obige Beispiel könnte auch so geschrieben werden:

(define libressl-statt-openssl
  ;; Rekursiv alle Pakete namens "openssl" durch LibreSSL ersetzen.
  (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

Der Hauptunterschied ist hier, dass diesmal Pakete zur Spezifikation passen müssen und nicht deren Wert identisch sein muss, damit sie ersetzt werden. Mit anderen Worten wird jedes Paket im Graphen ersetzt, das openssl heißt.

Eine allgemeiner anwendbare Prozedur, um den Abhängigkeitsgraphen eines Pakets umzuschreiben, ist package-mapping. Sie unterstützt beliebige Änderungen an den Knoten des Graphen.

Scheme-Prozedur: package-mapping Prozedur [Schnitt?] [#:deep? #f]

Liefert eine Prozedur, die, wenn ihr ein Paket übergeben wird, die an package-mapping übergebene Prozedur auf alle vom Paket abhängigen Pakete anwendet. Die Prozedur liefert das resultierende Paket. Wenn Schnitt? für ein Paket davon einen wahren Wert liefert, findet kein rekursiver Abstieg in dessen Abhängigkeiten statt. Steht deep? auf wahr, wird die Prozedur auch auf implizite Eingaben angewandt.


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.4 Erstellungssysteme

Jede Paketdefinition legt ein Erstellungssystem („build system“) sowie dessen Argumente fest (siehe Pakete definieren). Das build-system-Feld steht für die Erstellungsprozedur des Pakets sowie für weitere implizite Eingaben für die Erstellungsprozedur.

Erstellungssysteme sind <build-system>-Objekte. Die Schnittstelle, um solche zu erzeugen und zu verändern, ist im Modul (guix build-system) zu finden, und die eigentlichen Erstellungssysteme werden jeweils von ihren eigenen Modulen exportiert.

Intern funktionieren Erstellungssysteme, indem erst Paketobjekte zu Bags kompiliert werden. Eine Bag (deutsch: Beutel, Sack) ist wie ein Paket, aber mit weniger Zierrat — anders gesagt ist eine Bag eine systemnähere Darstellung eines Pakets, die sämtliche Eingaben des Pakets einschließlich vom Erstellungssystem hinzugefügter Eingaben enthält. Diese Zwischendarstellung wird dann zur eigentlichen Ableitung kompiliert (siehe Ableitungen). Die Prozedur package-with-c-toolchain ist zum Beispiel eine Möglichkeit, wie die durch das Erstellungssystem hinzugenommenen impliziten Eingaben abgeändert werden können (siehe package-with-c-toolchain).

Erstellungssysteme akzeptieren optional eine Liste von Argumenten. In Paketdefinitionen werden diese über das arguments-Feld übergeben (siehe Pakete definieren). Sie sind in der Regel Schlüsselwort-Argumente (siehe Schlüsselwort-Argumente in Guile in Referenzhandbuch zu GNU Guile). Der Wert dieser Argumente wird normalerweise vom Erstellungssystem in der Erstellungsschicht ausgewertet, d.h. von einem durch den Daemon gestarteten Guile-Prozess (siehe Ableitungen).

Das häufigste Erstellungssystem ist gnu-build-system, was die übliche Erstellungsprozedur für GNU-Pakete und viele andere Pakete darstellt. Es wird vom Modul (guix build-system gnu) bereitgestellt.

Scheme-Variable: gnu-build-system

gnu-build-system steht für das GNU-Erstellungssystem und Varianten desselben (siehe Konfiguration und Makefile-Konventionen in GNU Coding Standards).

Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt und installiert mit der üblichen Befehlsfolge ./configure && make && make check && make install. In der Praxis braucht man oft noch ein paar weitere Schritte. Alle Schritte sind in voneinander getrennte Phasen unterteilt. Erwähnt werden sollten16:

unpack

Den Quell-Tarball entpacken und das Arbeitsverzeichnis wechseln in den entpackten Quellbaum. Wenn die Quelle bereits ein Verzeichnis ist, wird es in den Quellbaum kopiert und dorthin gewechselt.

patch-source-shebangs

„Shebangs“ in Quelldateien beheben, damit Sie sich auf die richtigen Store-Dateipfade beziehen. Zum Beispiel könnte #!/bin/sh zu #!/gnu/store/…-bash-4.3/bin/sh geändert werden.

configure

Das Skript configure mit einigen vorgegebenen Befehlszeilenoptionen ausführen, wie z.B. mit --prefix=/gnu/store/…, sowie mit den im #:configure-flags-Argument angegebenen Optionen.

build

make ausführen mit den Optionen aus der Liste in #:make-flags. Wenn das Argument #:parallel-build? auf wahr gesetzt ist (was der Vorgabewert ist), wird make -j zum Erstellen ausgeführt.

check

make check (oder statt check ein anderes bei #:test-target angegebenes Ziel) ausführen, außer falls #:tests? #f gesetzt ist. Wenn das Argument #:parallel-tests? auf wahr gesetzt ist (der Vorgabewert), führe make check -j aus.

install

make install mit den in #:make-flags aufgelisteten Optionen ausführen.

patch-shebangs

Shebangs in den installierten ausführbaren Dateien beheben.

strip

Symbole zur Fehlerbehebung aus ELF-Dateien entfernen (außer #:strip-binaries? ist auf falsch gesetzt) und in die debug-Ausgabe kopieren, falls diese verfügbar ist (siehe Dateien zur Fehlersuche installieren).

Das erstellungsseitige Modul (guix build gnu-build-system) definiert %standard-phases als die vorgegebene Liste der Erstellungsphasen. %standard-phases ist eine Liste von Paaren aus je einem Symbol und einer Prozedur. Letztere implementiert die eigentliche Phase.

Siehe Erstellungsphasen für weitere Informationen zu Erstellungsphasen und Möglichkeiten, diese anzupassen.

Zusätzlich stellt dieses Erstellungssystem sicher, dass die „Standard“-Umgebung für GNU-Pakete zur Verfügung steht. Diese umfasst Werkzeuge wie GCC, libc, Coreutils, Bash, Make, Diffutils, grep und sed (siehe das Modul (guix build-system gnu) für eine vollständige Liste). Wir bezeichnen sie als implizite Eingaben eines Pakets, weil Paketdefinitionen sie nicht aufführen müssen.

Andere <build-system>-Objekte werden definiert, um andere Konventionen und Werkzeuge von Paketen für freie Software zu unterstützen. Die anderen Erstellungssysteme erben den Großteil vom gnu-build-system und unterscheiden sich hauptsächlich darin, welche Eingaben dem Erstellungsprozess implizit hinzugefügt werden und welche Liste von Phasen durchlaufen wird. Manche dieser Erstellungssysteme sind im Folgenden aufgeführt.

Scheme-Variable: ant-build-system

Diese Variable wird vom Modul (guix build-system ant) exportiert. Sie implementiert die Erstellungsprozedur für Java-Pakete, die mit dem Ant build tool erstellt werden können.

Sowohl ant als auch der Java Development Kit (JDK), wie er vom Paket icedtea bereitgestellt wird, werden zu den Eingaben hinzugefügt. Wenn andere Pakete dafür benutzt werden sollen, können sie jeweils mit den Parametern #:ant und #:jdk festgelegt werden.

Falls das ursprüngliche Paket über keine nutzbare Ant-Erstellungsdatei („Ant-Buildfile“) verfügt, kann aus der Angabe im Parameter #:jar-name eine minimale Ant-Erstellungsdatei build.xml erzeugt werden, in der die für die Erstellung durchzuführenden Aufgaben (Tasks) für die Erstellung des angegebenen Jar-Archivs stehen. In diesem Fall kann der Parameter #:source-dir benutzt werden, um das Unterverzeichnis mit dem Quellcode anzugeben; sein Vorgabewert ist „src“.

Der Parameter #:main-class kann mit einer minimalen Ant-Erstellungsdatei benutzt werden, um die Hauptklasse des resultierenden Jar-Archivs anzugeben. Dies ist nötig, wenn die Jar-Datei ausführbar sein soll. Mit dem Parameter #:test-include kann eine Liste angegeben werden, welche Junit-Tests auszuführen sind. Der Vorgabewert ist (list "**/*Test.java"). Mit #:test-exclude kann ein Teil der Testdateien ignoriert werden. Der Vorgabewert ist (list "**/Abstract*.java"), weil abstrakte Klassen keine ausführbaren Tests enthalten können.

Der Parameter #:build-target kann benutzt werden, um die Ant-Aufgabe (Task) anzugeben, die während der build-Phase ausgeführt werden soll. Vorgabe ist, dass die Aufgabe (Task) „jar“ ausgeführt wird.

Scheme-Variable: android-ndk-build-system

Diese Variable wird von (guix build-system android-ndk) exportiert. Sie implementiert eine Erstellungsprozedur für das Android NDK (Native Development Kit) benutzende Pakete mit einem Guix-spezifischen Erstellungsprozess.

Für das Erstellungssystem wird angenommen, dass Pakete die zu ihrer öffentlichen Schnittstelle gehörenden Header-Dateien im Unterverzeichnis include der Ausgabe out und ihre Bibliotheken im Unterverzeichnis lib der Ausgabe out platzieren.

Ebenso wird angenommen, dass es keine im Konflikt stehenden Dateien unter der Vereinigung aller Abhängigkeiten gibt.

Derzeit wird Cross-Kompilieren hierfür nicht unterstützt, also wird dabei vorausgesetzt, dass Bibliotheken und Header-Dateien dieselben wie im Wirtssystem sind.

Scheme-Variable: asdf-build-system/source
Scheme-Variable: asdf-build-system/sbcl
Scheme-Variable: asdf-build-system/ecl

Diese Variablen, die vom Modul (guix build-system asdf) exportiert werden, implementieren Erstellungsprozeduren für Common-Lisp-Pakete, welche „ASDF“ benutzen. ASDF dient der Systemdefinition für Common-Lisp-Programme und -Bibliotheken.

Das Erstellungssystem asdf-build-system/source installiert die Pakete in Quellcode-Form und kann via ASDF mit jeder Common-Lisp-Implementierung geladen werden. Die anderen Erstellungssysteme wie asdf-build-system/sbcl installieren binäre Systeme in dem Format, das von einer bestimmten Implementierung verstanden wird. Diese Erstellungssysteme können auch benutzt werden, um ausführbare Programme zu erzeugen oder um Lisp-Abbilder mit einem vorab geladenen Satz von Paketen zu erzeugen.

Das Erstellungssystem benutzt gewisse Namenskonventionen. Bei Binärpaketen sollte dem Paketnamen die Lispimplementierung als Präfix vorangehen, z.B. sbcl- für asdf-build-system/sbcl.

Zudem sollte das entsprechende Quellcode-Paket mit der Konvention wie bei Python-Paketen (siehe Python-Module) ein cl- als Präfix bekommen.

Für Binärpakete sollte für jedes System ein Guix-Paket definiert werden. Wenn für einen Ursprung im origin mehrere Systeme enthalten sind, können Paketvarianten geschrieben werden, mit denen alle Systeme erstellt werden. Quellpakete, die asdf-build-system/source benutzen, können mehrere Systeme enthalten.

Um ausführbare Programme und Abbilder zu erzeugen, können die erstellungsseitigen Prozeduren build-program und build-image benutzt werden. Sie sollten in einer Erstellungsphase nach der create-symlinks-Phase aufgerufen werden, damit das gerade erstellte System Teil des resultierenden Abbilds sein kann. An build-program muss eine Liste von Common-Lisp-Ausdrücken über das Argument #:entry-program übergeben werden.

Wenn das System nicht in seiner eigenen gleichnamigen .asd-Datei definiert ist, sollte der Parameter #:asd-file benutzt werden, um anzugeben, in welcher Datei das System definiert ist. Außerdem wird bei Paketen, für deren Tests ein System in einer separaten Datei definiert wurde, dieses System geladen, bevor die Tests ablaufen, wenn es im Parameter #:test-asd-file steht. Ist dafür kein Wert gesetzt, werden die Dateien <system>-tests.asd, <system>-test.asd, tests.asd und test.asd durchsucht, wenn sie existieren.

Wenn aus irgendeinem Grund der Paketname nicht den Namenskonventionen folgen kann, kann der Parameter #:asd-system-name benutzt werden, um den Namen des Systems anzugeben.

Scheme-Variable: cargo-build-system

Diese Variable wird vom Modul (guix build-system cargo) exportiert. Damit können Pakete mit Cargo erstellt werden, dem Erstellungswerkzeug der Rust-Programmiersprache.

Das Erstellungssystem fügt rustc und cargo zu den Eingaben hinzu. Ein anderes Rust-Paket kann mit dem Parameter #:rust angegeben werden.

Normale cargo-Abhängigkeiten sollten zur Paketdefinition über den Parameter #:cargo-inputs als eine Liste von Paaren aus Name und Spezifikation hinzugefügt werden, wobei als Spezifikation ein Paket oder eine Quellcode-Definition angegeben werden kann. Beachten Sie, dass die Spezifikation zu einem mit gzip komprimierten Tarball ausgewertet werden muss, der eine Datei Cargo.toml in seinem Wurzelverzeichnis enthält, ansonsten wird sie ignoriert. Analog sollten solche Abhängigkeiten, die in cargo als „dev-dependencies“ deklariert werden, zur Paketdefinition über den Parameter #:cargo-development-inputs hinzugefügt werden.

In seiner configure-Phase sorgt dieses Erstellungssystem dafür, dass cargo alle Quellcodeeingaben zur Verfügung stehen, die in den Parametern #:cargo-inputs und #:cargo-development-inputs angegeben wurden. Außerdem wird eine enthaltene Cargo.lock-Datei entfernt, damit cargo selbige während der build-Phase neu erzeugt. Die install-Phase installiert die in der Crate definierten Binärdateien.

Scheme-Variable: copy-build-system

Diese Variable wird vom Modul (guix build-system copy) exportiert. Damit können einfache Pakete erstellt werden, für die nur wenig kompiliert werden muss, sondern in erster Linie Dateien kopiert werden.

Dadurch wird ein Großteil der gnu-build-system zur Menge der Paketeingaben hinzugefügt. Deswegen kann man bei Nutzung des copy-build-system auf große Teile des Codes verzichten, der beim trivial-build-system anfallen würde.

Um den Dateiinstallationsvorgang weiter zu vereinfachen, wird ein Argument #:install-plan zur Verfügung gestellt, mit dem der Paketautor angeben kann, welche Dateien wohin gehören. Der Installationsplan ist eine Liste aus (Quelle Ziel [Filter]). Die Filter sind optional.

Beispiele:

Scheme-Variable: clojure-build-system

Diese Variable wird durch das Modul (guix build-system clojure) exportiert. Sie implementiert eine einfache Erstellungsprozedur für in Clojure geschriebene Pakete mit dem guten alten compile in Clojure. Cross-Kompilieren wird noch nicht unterstützt.

Das Erstellungssystem fügt clojure, icedtea und zip zu den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können diese jeweils mit den Parametern #:clojure, #:jdk und #:zip spezifiziert werden.

Eine Liste der Quellcode-Verzeichnisse, Test-Verzeichnisse und Namen der Jar-Dateien können jeweils über die Parameter #:source-dirs, #:test-dirs und #:jar-names angegeben werden. Das Verzeichnis, in das kompiliert wird, sowie die Hauptklasse können jeweils mit den Parametern #:compile-dir und #:main-class angegeben werden. Andere Parameter sind im Folgenden dokumentiert.

Dieses Erstellungssystem ist eine Erweiterung des ant-build-system, bei der aber die folgenden Phasen geändert wurden:

build

Diese Phase ruft compile in Clojure auf, um Quelldateien zu kompilieren, und führt jar aus, um Jar-Dateien aus sowohl Quelldateien als auch kompilierten Dateien zu erzeugen, entsprechend der jeweils in #:aot-include und #:aot-exclude festgelegten Listen aus in der Menge der Quelldateien eingeschlossenen und ausgeschlossenen Bibliotheken. Die Ausschlussliste hat Vorrang vor der Einschlussliste. Diese Listen setzen sich aus Symbolen zusammen, die für Clojure-Bibliotheken stehen oder dem Schlüsselwort #:all entsprechen, was für alle im Quellverzeichis gefundenen Clojure-Bibliotheken steht. Der Parameter #:omit-source? entscheidet, ob Quelldateien in die Jar-Archive aufgenommen werden sollen.

check

In dieser Phase werden Tests auf die durch Einschluss- und Ausschlussliste #:test-include bzw. #:test-exclude angegebenen Dateien ausgeführt. Deren Bedeutung ist analog zu #:aot-include und #:aot-exclude, außer dass das besondere Schlüsselwort #:all jetzt für alle Clojure-Bibliotheken in den Test-Verzeichnissen steht. Der Parameter #:tests? entscheidet, ob Tests ausgeführt werden sollen.

install

In dieser Phase werden alle zuvor erstellten Jar-Dateien installiert.

Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch eine weitere Phase.

install-doc

Diese Phase installiert alle Dateien auf oberster Ebene, deren Basisnamen ohne Verzeichnisangabe zu %doc-regex passen. Ein anderer regulärer Ausdruck kann mit dem Parameter #:doc-regex verwendet werden. All die so gefundenen oder (rekursiv) in den mit #:doc-dirs angegebenen Dokumentationsverzeichnissen liegenden Dateien werden installiert.

Scheme-Variable: cmake-build-system

Diese Variable wird von (guix build-system cmake) exportiert. Sie implementiert die Erstellungsprozedur für Pakete, die das CMake-Erstellungswerkzeug benutzen.

Das Erstellungssystem fügt automatisch das Paket cmake zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:cmake geändert werden.

Der Parameter #:configure-flags wird als Liste von Befehlszeilenoptionen aufgefasst, die an den Befehl cmake übergeben werden. Der Parameter #:build-type abstrahiert, welche Befehlszeilenoptionen dem Compiler übergeben werden; der Vorgabewert ist "RelWithDebInfo" (kurz für „release mode with debugging information“), d.h. kompiliert wird für eine Produktionsumgebung und Informationen zur Fehlerbehebung liegen bei, was ungefähr -O2 -g entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.

Scheme-Variable: dune-build-system

Diese Variable wird vom Modul (guix build-system dune) exportiert. Sie unterstützt es, Pakete mit Dune zu erstellen, einem Erstellungswerkzeug für die Programmiersprache OCaml, und ist als Erweiterung des unten beschriebenen OCaml-Erstellungssystems ocaml-build-system implementiert. Als solche können auch die Parameter #:ocaml und #:findlib an dieses Erstellungssystem übergeben werden.

Das Erstellungssystem fügt automatisch das Paket dune zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:dune geändert werden.

Es gibt keine configure-Phase, weil dune-Pakete typischerweise nicht konfiguriert werden müssen. Vom Parameter #:build-flags wird erwartet, dass es sich um eine Liste von Befehlszeilenoptionen handelt, die zur Erstellung an den dune-Befehl übergeben werden.

Der Parameter #:jbuild? kann übergeben werden, um den Befehl jbuild anstelle des neueren dune-Befehls aufzurufen, um das Paket zu erstellen. Der Vorgabewert ist #f.

Mit dem Parameter #:package kann ein Paketname angegeben werden, wenn im Paket mehrere Pakete enthalten sind und nur eines davon erstellt werden soll. Es ist äquivalent dazu, die Befehlszeilenoption -p an dune zu übergeben.

Scheme-Variable: go-build-system

Diese Variable wird vom Modul (guix build-system go) exportiert. Mit ihr ist eine Erstellungsprozedur für Go-Pakete implementiert, die dem normalen Go-Erstellungsmechanismus entspricht.

Beim Aufruf wird ein Wert für den Schlüssel #:import-path und manchmal auch für #:unpack-path erwartet. Der „import path“ entspricht dem Dateisystempfad, den die Erstellungsskripts des Pakets und darauf Bezug nehmende Pakete erwarten; durch ihn wird ein Go-Paket eindeutig bezeichnet. Typischerweise setzt er sich aus einer Kombination der entfernten URI des Paketquellcodes und der Dateisystemhierarchie zusammen. Manchmal ist es nötig, den Paketquellcode in ein anderes als das vom „import path“ bezeichnete Verzeichnis zu entpacken; diese andere Verzeichnisstruktur sollte dann als #:unpack-path angegeben werden.

Pakete, die Go-Bibliotheken zur Verfügung stellen, sollten ihren Quellcode auch in die Erstellungsausgabe installieren. Der Schlüssel #:install-source?, sein Vorgabewert ist #t, steuert, ob Quellcode installiert wird. Bei Paketen, die nur ausführbare Dateien liefern, kann der Wert auf #f gesetzt werden.

Scheme-Variable: glib-or-gtk-build-system

Diese Variable wird vom Modul (guix build-system glib-or-gtk) exportiert. Sie ist für Pakete gedacht, die GLib oder GTK benutzen.

Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von gnu-build-system hinzu:

glib-or-gtk-wrap

Die Phase glib-or-gtk-wrap stellt sicher, dass Programme in bin/ in der Lage sind, GLib-„Schemata“ und GTK-Module zu finden. Dazu wird für das Programm ein Wrapper-Skript erzeugt, dass das eigentliche Programm mit den richtigen Werten für die Umgebungsvariablen XDG_DATA_DIRS und GTK_PATH aufruft.

Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess auszunehmen, indem Sie eine Liste ihrer Namen im Parameter #:glib-or-gtk-wrap-excluded-outputs angeben. Das ist nützlich, wenn man von einer Ausgabe weiß, dass sie keine Binärdateien enthält, die GLib oder GTK benutzen, und diese Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von GLib und GTK bekäme.

glib-or-gtk-compile-schemas

Mit der Phase glib-or-gtk-compile-schemas wird sichergestellt, dass alle GSettings-Schemata für GLib kompiliert werden. Dazu wird das Programm glib-compile-schemas ausgeführt. Es kommt aus dem Paket glib:bin, was automatisch vom Erstellungssystem importiert wird. Welches glib-Paket dieses glib-compile-schemas bereitstellt, kann mit dem Parameter #:glib spezifiziert werden.

Beide Phasen finden nach der install-Phase statt.

Scheme-Variable: guile-build-system

Dieses Erstellungssystem ist für Guile-Pakete gedacht, die nur aus Scheme-Code bestehen und so schlicht sind, dass sie nicht einmal ein Makefile und erst recht keinen configure-Skript enthalten. Hierzu wird Scheme-Code mit guild compile kompiliert (siehe Compilation in Referenzhandbuch zu GNU Guile) und die .scm- und .go-Dateien an den richtigen Pfad installiert. Auch Dokumentation wird installiert.

Das Erstellungssystem unterstützt Cross-Kompilieren durch die Befehlszeilenoption --target für ‘guild compile’.

Mit guile-build-system erstellte Pakete müssen ein Guile-Paket in ihrem native-inputs-Feld aufführen.

Scheme-Variable: julia-build-system

Diese Variable wird vom Modul (guix build-system julia) exportiert. Sie entspricht einer Implementierung der durch Julia-Pakete genutzten Erstellungsprozedur und verhält sich im Prinzip so, wie wenn man ‘julia -e 'using Pkg; Pkg.add(paket)'’ in einer Umgebung ausführt, in der die Umgebungsvariable JULIA_LOAD_PATH die Pfade aller Julia-Pakete unter den Paketeingaben enthält. Tests werden per Pkg.test ausgeführt.

Für Julia-Pakete wird vorausgesetzt, dass der Dateiname im file-name-Feld der Quelle der echte Name des Pakets ist, in der richtigen Groß-/Kleinschreibung.

Für Pakete, die als Abhängigkeiten gemeinsame Bibliotheken („Shared Libraries“) verlangen, müssen Sie die /deps/deps.jl-Datei unter Umständen selbst schreiben. Normalerweise enthält sie eine Zeile wie const variable = /gnu/store/library.so für jede Abhängigkeit sowie eine Funktion check_deps() = nothing ohne Rückgabe.

Für manche ältere Pakete, die noch keine Package.toml benutzen, muss auch diese Datei erstellt werden. Die Funktion julia-create-package-toml hilft dabei. Sie müssen ihr nur die Ausgaben und die Quelle des Pakets übergeben sowie seinen Namen (derselbe wie beim Parameter file-name), die Paket-UUID, die Paketversion und eine Liste von Abhängigkeiten, jeweils angegeben über ihren Namen und ihre UUID.

Scheme-Variable: maven-build-system

Diese Variable wird vom Modul (guix build-system maven) exportiert. Darin wird eine Erstellungsprozedur für Maven-Pakete implementiert. Maven ist ein Werkzeug zur Verwaltung der Abhängigkeiten und des „Lebenszyklus“ eines Java-Projekts. Um Maven zu benutzen, werden Abhängigkeiten und Plugins in einer Datei pom.xml angegeben, die Maven ausliest. Wenn Maven Abhängigkeiten oder Plugins fehlen, lädt es sie herunter und erstellt damit das Paket.

Durch Guix’ Maven-Erstellungssystem wird gewährleistet, dass Maven im Offline-Modus läuft und somit nicht versucht, Abhängigkeiten herunterzuladen. Maven wird in einen Fehler laufen, wenn eine Abhängigkeit fehlt. Bevor Maven ausgeführt wird, wird der Inhalt der pom.xml (auch in Unterprojekten) so verändert, dass darin die diejenige Version von Abhängigkeiten und Plugins aufgeführt wird, die in Guix’ Erstellungsumgebung vorliegt. Abhängigkeiten und Plugins müssen in das vorgetäuschte Maven-Repository unter lib/m2 installiert werden; bevor Maven ausgeführt wird, werden symbolische Verknüpfungen in ein echtes Repository hergestellt. Maven wird angewiesen, dieses Repository für die Erstellung zu verwenden und installiert erstellte Artefakte dorthin. Geänderte Dateien werden ins Verzeichnis lib/m2 der Paketausgabe kopiert.

Sie können eine pom.xml-Datei über das Argument #:pom-file festlegen oder die vom Erstellungssystem vorgegebene pom.xml-Datei im Quellverzeichnis verwenden lassen.

Sollten Sie die Version einer Abhängigkeit manuell angeben müssen, können Sie dafür das Argument #:local-packages benutzen. Es nimmt eine assoziative Liste entgegen, deren Schlüssel jeweils die groupId des Pakets und deren Wert eine assoziative Liste ist, deren Schlüssel wiederum die artifactId des Pakets und deren Wert die einzusetzende Version in pom.xml ist.

Manche Pakete haben Abhängigkeiten oder Plugins, die weder zur Laufzeit noch zur Erstellungszeit in Guix sinnvoll sind. Sie können sie entfernen, indem Sie das #:exclude-Argument verwenden, um die pom.xml-Datei zu bearbeiten. Sein Wert ist eine assoziative Liste, deren Schlüssel die groupId des Plugins oder der Abhängigkeit ist, die Sie entfernen möchten, und deren Wert eine Liste von zu entfernenden artifactId-Vorkommen angibt.

Sie können statt der vorgegebenen jdk- und maven-Pakete andere Pakete mit dem entsprechenden Argument, #:jdk bzw. #:maven, verwenden.

Mit dem Argument #:maven-plugins geben Sie eine Liste von Maven-Plugins zur Nutzung während der Erstellung an, im gleichen Format wie das inputs-Feld der Paketdeklaration. Der Vorgabewert ist (default-maven-plugins); diese Variable wird exportiert, falls Sie sie benutzen möchten.

Scheme-Variable: minify-build-system

Diese Variable wird vom Modul (guix build-system minify) exportiert. Sie implementiert eine Prozedur zur Minifikation einfacher JavaScript-Pakete.

Es fügt uglify-js zur Menge der Eingaben hinzu und komprimiert damit alle JavaScript-Dateien im src-Verzeichnis. Ein anderes Programm zur Minifikation kann verwendet werden, indem es mit dem Parameter #:uglify-js angegeben wird; es wird erwartet, dass das angegebene Paket den minifizierten Code auf der Standardausgabe ausgibt.

Wenn die Eingabe-JavaScript-Dateien nicht alle im src-Verzeichnis liegen, kann mit dem Parameter #:javascript-files eine Liste der Dateinamen übergeben werden, auf die das Minifikationsprogramm aufgerufen wird.

Scheme-Variable: ocaml-build-system

Diese Variable wird vom Modul (guix build-system ocaml) exportiert. Mit ihr ist ein Erstellungssystem für OCaml-Pakete implementiert, was bedeutet, dass es die richtigen auszuführenden Befehle für das jeweilige Paket auswählt. OCaml-Pakete können sehr unterschiedliche Befehle erwarten. Dieses Erstellungssystem probiert manche davon durch.

Wenn im Paket eine Datei setup.ml auf oberster Ebene vorhanden ist, wird ocaml setup.ml -configure, ocaml setup.ml -build und ocaml setup.ml -install ausgeführt. Das Erstellungssystem wird annehmen, dass die Datei durch OASIS erzeugt wurde, und wird das Präfix setzen und Tests aktivieren, wenn diese nicht abgeschaltet wurden. Sie können Befehlszeilenoptionen zum Konfigurieren und Erstellen mit den Parametern #:configure-flags und #:build-flags übergeben. Der Schlüssel #:test-flags kann übergeben werden, um die Befehlszeilenoptionen zu ändern, mit denen die Tests aktiviert werden. Mit dem Parameter #:use-make? kann dieses Erstellungssystem für die build- und install-Phasen abgeschaltet werden.

Verfügt das Paket über eine configure-Datei, wird angenommen, dass diese von Hand geschrieben wurde mit einem anderen Format für Argumente als bei einem Skript des gnu-build-system. Sie können weitere Befehlszeilenoptionen mit dem Schlüssel #:configure-flags hinzufügen.

Falls dem Paket ein Makefile beiliegt (oder #:use-make? auf #t gesetzt wurde), wird dieses benutzt und weitere Befehlszeilenoptionen können mit dem Schlüssel #:make-flags zu den build- und install-Phasen hinzugefügt werden.

Letztlich gibt es in manchen Pakete keine solchen Dateien, sie halten sich aber an bestimmte Konventionen, wo ihr eigenes Erstellungssystem zu finden ist. In diesem Fall führt Guix’ OCaml-Erstellungssystem ocaml pkg/pkg.ml oder ocaml pkg/build.ml aus und kümmert sich darum, dass der Pfad zu dem benötigten findlib-Modul passt. Weitere Befehlszeilenoptionen können über den Schlüssel #:build-flags übergeben werden. Um die Installation kümmert sich opam-installer. In diesem Fall muss das opam-Paket im native-inputs-Feld der Paketdefinition stehen.

Beachten Sie, dass die meisten OCaml-Pakete davon ausgehen, dass sie in dasselbe Verzeichnis wie OCaml selbst installiert werden, was wir in Guix aber nicht so haben wollen. Solche Pakete installieren ihre .so-Dateien in das Verzeichnis ihres Moduls, was für die meisten anderen Einrichtungen funktioniert, weil es im OCaml-Compilerverzeichnis liegt. Jedoch können so in Guix die Bibliotheken nicht gefunden werden, deswegen benutzen wir CAML_LD_LIBRARY_PATH. Diese Umgebungsvariable zeigt auf lib/ocaml/site-lib/stubslibs und dorthin sollten .so-Bibliotheken installiert werden.

Scheme-Variable: python-build-system

Diese Variable wird vom Modul (guix build-system python) exportiert. Sie implementiert mehr oder weniger die konventionelle Erstellungsprozedur, wie sie für Python-Pakete üblich ist, d.h. erst wird python setup.py build ausgeführt und dann python setup.py install --prefix=/gnu/store/….

Für Pakete, die eigenständige Python-Programme nach bin/ installieren, sorgt dieses Erstellungssystem dafür, dass die Programme in ein Wrapper-Skript verpackt werden, welches die eigentlichen Programme mit einer Umgebungsvariablen PYTHONPATH aufruft, die alle Python-Bibliotheken auflistet, von denen die Programme abhängen.

Welches Python-Paket benutzt wird, um die Erstellung durchzuführen, kann mit dem Parameter #:python bestimmt werden. Das ist nützlich, wenn wir erzwingen wollen, dass ein Paket mit einer bestimmten Version des Python-Interpretierers arbeitet. Das kann nötig sein, wenn das Programm nur mit einer einzigen Interpretiererversion kompatibel ist.

Standardmäßig ruft Guix setup.py auf, was zu setuptools gehört, ähnlich wie es auch pip tut. Manche Pakete sind mit setuptools (und pip) inkompatibel, deswegen können Sie diese Einstellung abschalten, indem Sie den Parameter #:use-setuptools? auf #f setzen.

Scheme-Variable: perl-build-system

Diese Variable wird vom Modul (guix build-system perl) exportiert. Mit ihr wird die Standard-Erstellungsprozedur für Perl-Pakete implementiert, welche entweder darin besteht, perl Build.PL --prefix=/gnu/store/… gefolgt von Build und Build install auszuführen, oder perl Makefile.PL PREFIX=/gnu/store/… gefolgt von make und make install auszuführen, je nachdem, ob eine Datei Build.PL oder eine Datei Makefile.PL in der Paketdistribution vorliegt. Den Vorrang hat erstere, wenn sowohl Build.PL als auch Makefile.PL in der Paketdistribution existieren. Der Vorrang kann umgekehrt werden, indem #t für den Parameter #:make-maker? angegeben wird.

Der erste Aufruf von perl Makefile.PL oder perl Build.PL übergibt die im Parameter #:make-maker-flags bzw. #:module-build-flags angegebenen Befehlszeilenoptionen, je nachdem, was verwendet wird.

Welches Perl-Paket dafür benutzt wird, kann mit #:perl angegeben werden.

Scheme-Variable: qt-build-system

Diese Variable wird vom Modul (guix build-system qt) exportiert. Sie ist für Anwendungen gedacht, die Qt oder KDE benutzen.

Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von cmake-build-system hinzu:

check-setup

Die Phase check-setup bereitet die Umgebung für Überprüfungen vor, wie sie von Qt-Test-Programmen üblicherweise benutzt werden. Zurzeit werden nur manche Umgebungsvariable gesetzt: QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 und CTEST_OUTPUT_ON_FAILURE=1.

Diese Phase wird vor der check-Phase hinzugefügt. Es handelt sich um eine eigene Phase, die nach Bedarf angepasst werden kann.

qt-wrap

In der Phase qt-wrap wird nach Qt5-Plugin-Pfaden, QML-Pfaden und manchen XDG-Daten in den Ein- und Ausgaben gesucht. Wenn solch ein Pfad gefunden wird, werden für alle Programme in den Verzeichnissen bin/, sbin/, libexec/ und lib/libexec/ in der Ausgabe Wrapper-Skripte erzeugt, die die nötigen Umgebungsvariablen definieren.

Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess auszunehmen, indem Sie eine Liste ihrer Namen im Parameter #:qt-wrap-excluded-outputs angeben. Das ist nützlich, wenn man von einer Ausgabe weiß, dass sie keine Qt-Binärdateien enthält, und diese Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von Qt, KDE oder Ähnlichem bekäme.

Diese Phase wird nach der install-Phase hinzugefügt.

Scheme-Variable: r-build-system

Diese Variable wird vom Modul (guix build-system r) exportiert. Sie entspricht einer Implementierung der durch R-Pakete genutzten Erstellungsprozedur, die wenig mehr tut, als ‘R CMD INSTALL --library=/gnu/store/…’ in einer Umgebung auszuführen, in der die Umgebungsvariable R_LIBS_SITE die Pfade aller R-Pakete unter den Paketeingaben enthält. Tests werden nach der Installation mit der R-Funktion tools::testInstalledPackage ausgeführt.

Scheme-Variable: rakudo-build-system

Diese Variable wird vom Modul (guix build-system rakudo) exportiert. Sie implementiert die Erstellungsprozedur, die von Rakudo für Perl6-Pakete benutzt wird. Pakete werden ins Verzeichnis /gnu/store/…/NAME-VERSION/share/perl6 abgelegt und Binärdateien, Bibliotheksdateien und Ressourcen werden installiert, zudem werden die Dateien im Verzeichnis bin/ in Wrapper-Skripte verpackt. Tests können übersprungen werden, indem man #f im Parameter tests? übergibt.

Welches rakudo-Paket benutzt werden soll, kann mit dem Parameter rakudo angegeben werden. Das perl6-tap-harness-Paket, das für die Tests benutzt wird, kann mit #:prove6 ausgewählt werden; es kann auch entfernt werden, indem man #f für den Parameter with-prove6? übergibt. Welches perl6-zef-Paket für Tests und Installation verwendet wird, kann mit dem Parameter #:zef angegeben werden; es kann auch entfernt werden, indem man #f für den Parameter with-zef? übergibt.

Scheme-Variable: texlive-build-system

Diese Variable wird vom Modul (guix build-system texlive) exportiert. Mit ihr werden TeX-Pakete in Stapelverarbeitung („batch mode“) mit der angegebenen Engine erstellt. Das Erstellungssystem setzt die Variable TEXINPUTS so, dass alle TeX-Quelldateien unter den Eingaben gefunden werden können.

Standardmäßig wird luatex auf allen Dateien mit der Dateiendung ins ausgeführt. Eine andere Engine oder ein anderes Format kann mit dem Argument #:tex-format angegeben werden. Verschiedene Erstellungsziele können mit dem Argument #:build-targets festgelegt werden, das eine Liste von Dateinamen erwartet. Das Erstellungssystem fügt nur texlive-bin und texlive-latex-base zu den Eingaben hinzu (beide kommen aus dem Modul (gnu packages tex). Für beide kann das zu benutzende Paket jeweils mit den Argumenten #:texlive-bin oder #:texlive-latex-base geändert werden.

Der Parameter #:tex-directory sagt dem Erstellungssystem, wohin die installierten Dateien im texmf-Verzeichnisbaum installiert werden sollen.

Scheme-Variable: ruby-build-system

Diese Variable wird vom Modul (guix build-system ruby) exportiert. Sie steht für eine Implementierung der RubyGems-Erstellungsprozedur, die für Ruby-Pakete benutzt wird, wobei gem build gefolgt von gem install ausgeführt wird.

Das source-Feld eines Pakets, das dieses Erstellungssystem benutzt, verweist typischerweise auf ein Gem-Archiv, weil Ruby-Entwickler dieses Format benutzen, wenn sie ihre Software veröffentlichen. Das Erstellungssystem entpackt das Gem-Archiv, spielt eventuell Patches für den Quellcode ein, führt die Tests aus, verpackt alles wieder in ein Gem-Archiv und installiert dieses. Neben Gem-Archiven darf das Feld auch auf Verzeichnisse und Tarballs verweisen, damit es auch möglich ist, unveröffentlichte Gems aus einem Git-Repository oder traditionelle Quellcode-Veröffentlichungen zu benutzen.

Welches Ruby-Paket benutzt werden soll, kann mit dem Parameter #:ruby festgelegt werden. Eine Liste zusätzlicher Befehlszeilenoptionen für den Aufruf des gem-Befehls kann mit dem Parameter #:gem-flags angegeben werden.

Scheme-Variable: waf-build-system

Diese Variable wird durch das Modul (guix build-system waf) exportiert. Damit ist eine Erstellungsprozedur rund um das waf-Skript implementiert. Die üblichen Phasen — configure, build und install — sind implementiert, indem deren Namen als Argumente an das waf-Skript übergeben werden.

Das waf-Skript wird vom Python-Interpetierer ausgeführt. Mit welchem Python-Paket das Skript ausgeführt werden soll, kann mit dem Parameter #:python angegeben werden.

Scheme-Variable: scons-build-system

Diese Variable wird vom Modul (guix build-system scons) exportiert. Sie steht für eine Implementierung der Erstellungsprozedur, die das SCons-Softwarekonstruktionswerkzeug („software construction tool“) benutzt. Das Erstellungssystem führt scons aus, um das Paket zu erstellen, führt mit scons test Tests aus und benutzt scons install, um das Paket zu installieren.

Zusätzliche Optionen, die an scons übergeben werden sollen, können mit dem Parameter #:scons-flags angegeben werden. Die voreingestellten Erstellungs- und Installationsziele können jeweils durch #:build-targets und #:install-targets ersetzt werden. Die Python-Version, die benutzt werden soll, um SCons auszuführen, kann festgelegt werden, indem das passende SCons-Paket mit dem Parameter #:scons ausgewählt wird.

Scheme-Variable: haskell-build-system

Diese Variable wird vom Modul (guix build-system haskell) exportiert. Sie bietet Zugang zur Cabal-Erstellungsprozedur, die von Haskell-Paketen benutzt wird, was bedeutet, runhaskell Setup.hs configure --prefix=/gnu/store/… und runhaskell Setup.hs build auszuführen. Statt das Paket mit dem Befehl runhaskell Setup.hs install zu installieren, benutzt das Erstellungssystem runhaskell Setup.hs copy gefolgt von runhaskell Setup.hs register, um keine Bibliotheken im Store-Verzeichnis des Compilers zu speichern, auf dem keine Schreibberechtigung besteht. Zusätzlich generiert das Erstellungssystem Dokumentation durch Ausführen von runhaskell Setup.hs haddock, außer #:haddock? #f wurde übergeben. Optional können an Haddock Parameter mit Hilfe des Parameters #:haddock-flags übergeben werden. Wird die Datei Setup.hs nicht gefunden, sucht das Erstellungssystem stattdessen nach Setup.lhs.

Welcher Haskell-Compiler benutzt werden soll, kann über den #:haskell-Parameter angegeben werden. Als Vorgabewert verwendet er ghc.

Scheme-Variable: dub-build-system

Diese Variable wird vom Modul (guix build-system dub) exportiert. Sie verweist auf eine Implementierung des Dub-Erstellungssystems, das von D-Paketen benutzt wird. Dabei werden dub build und dub run ausgeführt. Die Installation wird durch manuelles Kopieren der Dateien durchgeführt.

Welcher D-Compiler benutzt wird, kann mit dem Parameter #:ldc festgelegt werden, was als Vorgabewert ldc benutzt.

Scheme-Variable: emacs-build-system

Diese Variable wird vom Modul (guix build-system emacs) exportiert. Darin wird eine Installationsprozedur ähnlich der des Paketsystems von Emacs selbst implementiert (siehe Packages in The GNU Emacs Manual).

Zunächst wird eine Datei Paket-autoloads.el erzeugt, dann werden alle Emacs-Lisp-Dateien zu Bytecode kompiliert. Anders als beim Emacs-Paketsystem werden die Info-Dokumentationsdateien in das Standardverzeichnis für Dokumentation verschoben und die Datei dir gelöscht. Die Dateien des Elisp-Pakets werden direkt in share/emacs/site-lisp installiert.

Scheme-Variable: font-build-system

Diese Variable wird vom Modul (guix build-system font) exportiert. Mit ihr steht eine Installationsprozedur für Schriftarten-Pakete zur Verfügung für vom Anbieter vorkompilierte TrueType-, OpenType- und andere Schriftartendateien, die nur an die richtige Stelle kopiert werden müssen. Dieses Erstellungssystem kopiert die Schriftartendateien an den Konventionen folgende Orte im Ausgabeverzeichnis.

Scheme-Variable: meson-build-system

Diese Variable wird vom Modul (guix build-system meson) exportiert. Sie enthält die Erstellungsprozedur für Pakete, die Meson als ihr Erstellungssystem benutzen.

Mit ihr werden sowohl Meson als auch Ninja zur Menge der Eingaben hinzugefügt; die Pakete dafür können mit den Parametern #:meson und #:ninja geändert werden, wenn nötig. Das vorgegebene Meson-Paket ist meson-for-build, ein besonderes Paket, dessen Besonderheit darin besteht, den RUNPATH von Binärdateien und Bibliotheken nicht zu entfernen, wenn sie installiert werden.

Dieses Erstellungssystem ist eine Erweiterung für das gnu-build-system, aber mit Änderungen an den folgenden Phasen, die Meson-spezifisch sind:

configure

Diese Phase führt den meson-Befehl mit den in #:configure-flags angegebenen Befehlszeilenoptionen aus. Die Befehlszeilenoption --build-type wird immer auf debugoptimized gesetzt, solange nichts anderes mit dem Parameter #:build-type angegeben wurde.

build

Diese Phase ruft ninja auf, um das Paket standardmäßig parallel zu erstellen. Die Vorgabeeinstellung, dass parallel erstellt wird, kann verändert werden durch Setzen von #:parallel-build?.

check

Diese Phase führt ninja mit dem als #:test-target spezifizierten Ziel für Tests auf, der Vorgabewert ist das Ziel namens "test".

install

Diese Phase führt ninja install aus und kann nicht verändert werden.

Dazu fügt das Erstellungssystem noch folgende neue Phasen:

fix-runpath

In dieser Phase wird sichergestellt, dass alle Binärdateien die von ihnen benötigten Bibliotheken finden können. Die benötigten Bibliotheken werden in den Unterverzeichnissen des Pakets, das erstellt wird, gesucht, und zum RUNPATH hinzugefügt, wann immer es nötig ist. Auch werden diejenigen Referenzen zu Bibliotheken aus der Erstellungsphase wieder entfernt, die bei meson-for-build hinzugefügt wurden, aber eigentlich zur Laufzeit nicht gebraucht werden, wie Abhängigkeiten nur für Tests.

glib-or-gtk-wrap

Diese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter #:glib-or-gtk? aktiviert werden.

glib-or-gtk-compile-schemas

Diese Phase ist dieselbe, die auch im glib-or-gtk-build-system zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter #:glib-or-gtk? aktiviert werden.

Scheme-Variable: linux-module-build-system

Mit linux-module-build-system können Linux-Kernelmodule erstellt werden.

Dieses Erstellungssystem ist eine Erweiterung des gnu-build-system, bei der aber die folgenden Phasen geändert wurden:

configure

Diese Phase konfiguriert die Umgebung so, dass das externe Kernel-Modul durch das Makefile des Linux-Kernels erstellt werden kann.

build

Diese Phase benutzt das Makefile des Linux-Kernels, um das externe Kernel-Modul zu erstellen.

install

Diese Phase benutzt das Makefile des Linux-Kernels zur Installation des externen Kernel-Moduls.

Es ist möglich und hilfreich, den für die Erstellung des Moduls zu benutzenden Linux-Kernel anzugeben (in der arguments-Form eines Pakets, dass das linux-module-build-system als Erstellungssystem benutzt, wird dazu der Schlüssel #:linux benutzt).

Scheme-Variable: node-build-system

Diese Variable wird vom Modul (guix build-system node) exportiert. Sie stellt eine Implementierung der Erstellungsprozedur von Node.js dar, die annäherungsweise der Funktion des Befehls npm install gefolgt vom Befehl npm test entspricht.

Welches Node.js-Paket zur Interpretation der npm-Befehle benutzt wird, kann mit dem Parameter #:node angegeben werden. Dessen Vorgabewert ist node.

Letztlich gibt es für die Pakete, die bei weitem nichts so komplexes brauchen, ein „triviales“ Erstellungssystem. Es ist in dem Sinn trivial, dass es praktisch keine Hilfestellungen gibt: Es fügt keine impliziten Eingaben hinzu und hat kein Konzept von Erstellungsphasen.

Scheme-Variable: trivial-build-system

Diese Variable wird vom Modul (guix build-system trivial) exportiert.

Diesem Erstellungssystem muss im Argument #:builder ein Scheme-Ausdruck übergeben werden, der die Paketausgabe(n) erstellt — wie bei build-expression->derivation (siehe build-expression->derivation).


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.5 Erstellungsphasen

Fast alle Erstellungssysteme für Pakete implementieren ein Konzept von Erstellungsphasen: einer Abfolge von Aktionen, die vom Erstellungssystem ausgeführt werden, wenn Sie das Paket erstellen. Dabei fallen in den Store installierte Nebenerzeugnisse an. Eine Ausnahme ist der Erwähnung wert: das magere trivial-build-system (siehe Erstellungssysteme).

Wie im letzten Abschnitt erläutert, stellen diese Erstellungssysteme eine standardisierte Liste von Phasen zur Verfügung. Für gnu-build-system gehören zu den Standardphasen eine unpack-Phase, wo der Quellcode-Tarball entpackt wird, eine configure-Phase, wo ./configure ausgeführt wird, eine build-Phase, um make auszuführen, und (unter anderem) eine install-Phase, um make install auszuführen. Siehe Erstellungssysteme für eine Detailansicht dieser Phasen. cmake-build-system erbt diese Phasen, aber seine configure-Phase führt cmake statt ./configure aus. Andere Erstellungssysteme wie z.B. python-build-system haben eine völlig andere Liste von Standardphasen. Dieser gesamte Code läuft erstellungsseitig: Er wird dann ausgewertet, wenn Sie das Paket wirklich erstellen, in einem eigenen Erstellungprozess nur dafür, den der Erstellungs-Daemon erzeugt (siehe Aufruf des guix-daemon).

Erstellungsphasen werden durch assoziative Listen (kurz „Alists“) repräsentiert (siehe Association Lists in Referenzhandbuch zu GNU Guile) wo jeder Schlüssel ein Symbol für den Namen der Phase ist und der assoziierte Wert eine Prozedur ist, die eine beliebige Anzahl von Argumenten nimmt. Nach Konvention empfangen diese Prozeduren dadurch Informationen über die Erstellung in Form von Schlüsselwort-Parametern, die darin benutzt oder ignoriert werden können.

Zum Beispiel werden die %standard-phases, das ist die Variable mit der Alist der Erstellungsphasen, in (guix build gnu-build-system) so definiert17:

;; Die Erstellungsphasen von 'gnu-build-system'.

(define* (unpack #:key source #:allow-other-keys)
  ;; Quelltarball extrahieren.
  (invoke "tar" "xvf" source))

(define* (configure #:key outputs #:allow-other-keys)
  ;; 'configure'-Skript ausführen. In Ausgabe "out" installieren.
  (let ((out (assoc-ref outputs "out")))
    (invoke "./configure"
            (string-append "--prefix=" out))))

(define* (build #:allow-other-keys)
  ;; Kompilieren.
  (invoke "make"))

(define* (check #:key (test-target "check") (tests? #true)
                #:allow-other-keys)
  ;; Testkatalog ausführen.
  (if tests?
      (invoke "make" test-target)
      (display "test suite not run\n")))

(define* (install #:allow-other-keys)
  ;; Dateien ins bei 'configure' festgelegte Präfix installieren.
  (invoke "make" "install"))

(define %standard-phases
  ;; Die Liste der Standardphasen (der Kürze halber lassen wir einige
  ;; aus). Jedes Element ist ein Paar aus Symbol und Prozedur.
  (list (cons 'unpack unpack)
        (cons 'configure configure)
        (cons 'build build)
        (cons 'check check)
        (cons 'install install)))

Hier sieht man wie %standard-phases als eine Liste von Paaren aus Symbol und Prozedur (siehe Pairs in Referenzhandbuch zu GNU Guile) definiert ist. Das erste Paar assoziiert die unpack-Prozedur mit dem unpack-Symbol — es gibt einen Namen an. Das zweite Paar definiert die configure-Phase auf ähnliche Weise, ebenso die anderen. Wenn ein Paket erstellt wird, das gnu-build-system benutzt, werden diese Phasen der Reihe nach ausgeführt. Sie können beim Erstellen von Paketen im Erstellungsprotokoll den Namen jeder gestarteten und abgeschlossenen Phase sehen.

Schauen wir uns jetzt die Prozeduren selbst an. Jede davon wird mit define* definiert, dadurch können bei #:key die Schlüsselwortparameter aufgelistet werden, die die Prozedur annimmt, wenn gewünscht auch zusammen mit einem Vorgabewert, und durch #:allow-other-keys wird veranlasst, dass andere Schlüsselwortparameter ignoriert werden (siehe Optional Arguments in Referenzhandbuch zu GNU Guile).

Die unpack-Prozedur berücksichtigt den source-Parameter; das Erstellungssystem benutzt ihn, um den Dateinamen des Quell-Tarballs (oder des Checkouts aus einer Versionskontrolle) zu finden. Die anderen Parameter ignoriert sie. Die configure-Phase interessiert sich nur für den outputs-Parameter, eine Alist, die die Namen von Paketausgaben auf ihre Dateinamen im Store abbildet (siehe Pakete mit mehreren Ausgaben.). Sie extrahiert den Dateinamen für out, die Standardausgabe, und gibt ihn an ./configure als das Installationspräfix weiter, wodurch make install zum Schluss alle Dateien in dieses Verzeichnis kopieren wird (siehe configuration and makefile conventions in GNU Coding Standards). build und install ignorieren all ihre Argumente. check berücksichtigt das Argument test-target, worin der Name des Makefile-Ziels angegeben wird, um die Tests auszuführen. Es wird stattdessen eine Nachricht angezeigt und die Tests übersprungen, wenn tests? falsch ist.

Die Liste der Phasen, die für ein bestimmtes Paket benutzt werden, kann über den #:phases-Parameter an das Erstellungssystem geändert werden. Das Ändern des Satzes von Erstellungsphasen funktioniert so, dass eine neue Alist von Phasen aus der oben beschriebenen %standard-phases-Alist heraus erzeugt wird. Dazu können die Standardprozeduren zur Bearbeitung von assoziativen Listen wie alist-delete benutzt werden (siehe SRFI-1 Association Lists in Referenzhandbuch zu GNU Guile), aber es ist bequemer, dafür die Prozedur modify-phases zu benutzen (siehe modify-phases).

Hier ist ein Beispiel für eine Paketdefinition, die die configure-Phase aus %standard-phases entfernt und eine neue Phase vor der build-Phase namens set-prefix-in-makefile einfügt:

(define-public beispiel
  (package
    (name "beispiel")
    ;; wir lassen die anderen Felder aus
    (build-system gnu-build-system)
    (arguments
     '(#:phases (modify-phases %standard-phases
                  (delete 'configure)
                  (add-before 'build 'set-prefix-in-makefile
                    (lambda* (#:key outputs #:allow-other-keys)
                      ;; Makefile anpassen, damit die 'PREFIX'-
                      ;; Variable auf "out" verweist.
                      (let ((out (assoc-ref outputs "out")))
                        (substitute* "Makefile"
                          (("PREFIX =.*")
                           (string-append "PREFIX = "
                                          out "\n")))
                        #true))))))))

Die neu eingefügte Phase wurde als anonyme Prozedur geschrieben. Solche namenlosen Prozeduren schreibt man mit lambda*. Oben berücksichtigt sie den outputs-Parameter, den wir zuvor gesehen haben. Siehe Werkzeuge zur Erstellung für mehr Informationen über die in dieser Phase benutzten Hilfsmittel und für mehr Beispiele zu modify-phases.

Sie sollten im Kopf behalten, dass Erstellungsphasen aus Code bestehen, der erst dann ausgewertet wird, wenn das Paket erstellt wird. Das ist der Grund, warum der gesamte modify-phases-Ausdruck oben quotiert wird. Quotiert heißt, er steht nach einem ' oder Apostrophenzeichen: Er wird nicht sofort als Code ausgewertet, sondern nur zur späteren Ausführung vorgemerkt (wir sagen staged, siehe G-Ausdrücke für eine Erläuterung von Code-Staging und den beteiligten Code-Schichten (oder „Strata“).


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.6 Werkzeuge zur Erstellung

Sobald Sie anfangen, nichttriviale Paketdefinitionen (siehe Pakete definieren) oder andere Erstellungsaktionen (siehe G-Ausdrücke) zu schreiben, würden Sie sich wahrscheinlich darüber freuen, Helferlein für „Shell-artige“ Aktionen vordefiniert zu bekommen, also Code, den Sie benutzen können, um Verzeichnisse anzulegen, Dateien rekursiv zu kopieren oder zu löschen, Erstellungsphasen anzupassen und Ähnliches. Das Modul (guix build utils) macht solche nützlichen Werkzeugprozeduren verfügbar.

Die meisten Erstellungssysteme laden (guix build utils) (siehe Erstellungssysteme). Wenn Sie also eigene Erstellungsphasen für Ihre Paketdefinitionen schreiben, können Sie in den meisten Fällen annehmen, dass diese Prozeduren bei der Auswertung sichtbar sein werden.

Beim Schreiben von G-Ausdrücken können Sie auf der „Erstellungsseite“ (guix build utils) mit with-imported-modules importieren und anschließend mit der use-modules-Form sichtbar machen (siehe Using Guile Modules in Referenzhandbuch zu GNU Guile):

(with-imported-modules '((guix build utils))  ;importieren
  (computed-file "leerer-verzeichnisbaum"
                 #~(begin
                     ;; Sichtbar machen.
                     (use-modules (guix build utils))

                     ;; Jetzt kann man problemlos 'mkdir-p' nutzen.
                     (mkdir-p (string-append #$output "/a/b/c")))))

Der Rest dieses Abschnitts stellt eine Referenz der meisten Werkzeugprozeduren dar, die (guix build utils) anbietet.

8.6.1 Umgehen mit Store-Dateinamen

Dieser Abschnitt dokumentiert Prozeduren, die sich mit Dateinamen von Store-Objekten befassen.

Scheme-Prozedur: %store-directory

Liefert den Verzeichnisnamen des Stores.

Scheme-Prozedur: store-file-name? Datei

Liefert wahr zurück, wenn sich Datei innerhalb des Stores befindet.

Scheme-Prozedur: strip-store-file-name Datei

Liefert den Namen der Datei, die im Store liegt, ohne den Anfang /gnu/store und ohne die Prüfsumme am Namensanfang. Als Ergebnis ergibt sich typischerweise eine Zeichenkette aus "Paket-Version".

Scheme-Prozedur: package-name->name+version Name

Liefert für den Paket-Namen (so etwas wie "foo-0.9.1b") zwei Werte zurück: zum einen "foo" und zum anderen "0.9.1b". Wenn der Teil mit der Version fehlt, werden der Name und #f zurückgeliefert. Am ersten Bindestrich, auf den eine Ziffer folgt, wird der Versionsteil abgetrennt.

8.6.2 Dateitypen

Bei den folgenden Prozeduren geht es um Dateien und Dateitypen.

Scheme-Prozedur: directory-exists? Verzeichnis

Liefert #t, wenn das Verzeichnis existiert und ein Verzeichnis ist.

Scheme-Prozedur: executable-file? Datei

Liefert #t, wenn die Datei existiert und ausführbar ist.

Liefert #t, wenn die Datei eine symbolische Verknüpfung ist (auch bekannt als „Symlink“).

Scheme-Prozedur: elf-file? Datei
Scheme-Prozedur: ar-file? Datei
Scheme-Prozedur: gzip-file? Datei

Liefert #t, wenn die Datei jeweils eine ELF-Datei, ein ar-Archiv (etwa eine statische Bibliothek mit .a) oder eine gzip-Datei ist.

Scheme-Prozedur: reset-gzip-timestamp Datei [#:keep-mtime? #t]

Wenn die Datei eine gzip-Datei ist, wird ihr eingebetteter Zeitstempel zurückgesetzt (wie bei gzip --no-name) und wahr geliefert. Ansonsten wird #f geliefert. Wenn keep-mtime? wahr ist, wird der Zeitstempel der letzten Modifikation von Datei beibehalten.

8.6.3 Änderungen an Dateien

Die folgenden Prozeduren und Makros helfen beim Erstellen, Ändern und Löschen von Dateien. Sie machen Funktionen ähnlich zu Shell-Werkzeugen wie mkdir -p, cp -r, rm -r und sed verfügbar. Sie ergänzen Guiles ausgiebige aber kleinschrittige Dateisystemschnittstelle (siehe POSIX in Referenzhandbuch zu GNU Guile).

Scheme-Syntax: with-directory-excursion Verzeichnis Rumpf

Den Rumpf ausführen mit dem Verzeichnis als aktuellem Verzeichnis des Prozesses.

Im Grunde ändert das Makro das aktuelle Arbeitsverzeichnis auf Verzeichnis bevor der Rumpf ausgewertet wird, mittels chdir (siehe Processes in Referenzhandbuch zu GNU Guile). Wenn der dynamische Bereich von Rumpf wieder verlassen wird, wechselt es wieder ins anfängliche Verzeichnis zurück, egal ob der Rumpf durch normales Zurückliefern eines Ergebnisses oder durch einen nichtlokalen Sprung wie etwa eine Ausnahme verlassen wurde.

Scheme-Prozedur: mkdir-p Verzeichnis

Das Verzeichnis und all seine Vorgänger erstellen.

Scheme-Prozedur: install-file Datei Verzeichnis

Verzeichnis erstellen, wenn es noch nicht existiert, und die Datei mit ihrem Namen dorthin kopieren.

Scheme-Prozedur: make-file-writable Datei

Dem Besitzer der Datei Schreibberechtigung darauf erteilen.

Scheme-Prozedur: copy-recursively Quelle Zielort [#:log (current-output-port)] [#:follow-symlinks? #f] [#:keep-mtime? #f] Das

Verzeichnis Quelle rekursiv an den Zielort kopieren. Wenn follow-symlinks? wahr ist, folgt die Rekursion symbolischen Verknüpfungen, ansonsten werden die Verknüpfungen als solche beibehalten. Wenn keep-mtime? wahr ist, bleibt der Zeitstempel der letzten Änderung an den Dateien in Quelle dabei bei denen am Zielort erhalten. Ein ausführliches Protokoll wird in den bei log angegebenen Port geschrieben.

Scheme-Prozedur: delete-file-recursively Verzeichnis [#:follow-mounts? #f] Das Verzeichnis rekursiv löschen, wie bei

rm -rf, ohne symbolischen Verknüpfungen zu folgen. Auch Einhängepunkten wird nicht gefolgt, außer falls follow-mounts? wahr ist. Fehler dabei werden angezeigt aber ignoriert.

Scheme-Syntax: substitute* Datei ((Regexp Muster-Variable…) Rumpf…) … Den regulären

Ausdruck Regexp in der Datei durch die durch Rumpf berechnete Zeichenkette ersetzen. Bei der Auswertung von Rumpf wird jede Muster-Variable an den Teilausdruck an der entsprechenden Position der Regexp gebunden. Zum Beispiel:

(substitute* file
  (("Hallo")
   "Guten Morgen\n")
  (("foo([a-z]+)bar(.*)$" alles Buchstaben Ende)
   (string-append "baz" Buchstaben Ende)))

Jedes Mal, wenn eine Zeile in der Datei den Text Hallo enthält, wird dieser durch Guten Morgen ersetzt. Jedes Mal, wenn eine Zeile zum zweiten regulären Ausdruck passt, wird alles an die vollständige Übereinstimmung gebunden, Buchstaben wird an den ersten Teilausdruck gebunden und Ende an den letzten.

Wird für eine Muster-Variable nur _ geschrieben, so wird keine Variable an die Teilzeichenkette an der entsprechenden Position im Muster gebunden.

Alternativ kann statt einer Datei auch eine Liste von Dateinamen angegeben werden. In diesem Fall wird jede davon den Substitutionen unterzogen.

Seien Sie vorsichtig bei der Nutzung von $, um auf das Ende einer Zeile zu passen. $ passt nämlich nicht auf den Zeilenumbruch am Ende einer Zeile.

8.6.4 Dateien suchen

Dieser Abschnitt beschreibt Prozeduren, um Dateien zu suchen und zu filtern.

Scheme-Prozedur: file-name-predicate Regexp

Liefert ein Prädikat, das gegeben einen Dateinamen, dessen Basisnamen auf Regexp passt, wahr liefert.

Scheme-Prozedur: find-files Verzeichnis [Prädikat] [#:stat lstat] [#:directories? #f] [#:fail-on-error? #f] Liefert die

lexikografisch sortierte Liste der Dateien innerhalb Verzeichnis, für die das Prädikat wahr liefert. An Prädikat werden zwei Argumente übergeben: Der absolute Dateiname und der zugehörige Stat-Puffer. Das vorgegebene Prädikat liefert immer wahr. Als Prädikat kann auch ein regulärer Ausdruck benutzt werden; in diesem Fall ist er äquivalent zu (file-name-predicate Prädikat). Mit stat werden Informationen über die Datei ermittelt; wenn dafür lstat benutzt wird, bedeutet das, dass symbolische Verknüpfungen nicht verfolgt werden. Wenn directories? wahr ist, dann werden auch Verzeichnisse aufgezählt. Wenn fail-on-error? wahr ist, dann wird bei einem Fehler eine Ausnahme ausgelöst.

Nun folgen ein paar Beispiele, wobei wir annehmen, dass das aktuelle Verzeichnis der Wurzel des Guix-Quellbaums entspricht.

;; Alle regulären Dateien im aktuellen Verzeichnis auflisten.
(find-files ".")
 ("./.dir-locals.el" "./.gitignore" )

;; Alle .scm-Dateien unter gnu/services auflisten.
(find-files "gnu/services" "\\.scm$")
 ("gnu/services/admin.scm" "gnu/services/audio.scm" )

;; ar-Dateien im aktuellen Verzeichnis auflisten.
(find-files "." (lambda (file stat) (ar-file? file)))
 ("./libformat.a" "./libstore.a" )
Scheme-Prozedur: which Programm

Liefert den vollständigen Dateinamen für das Programm, der in $PATH gesucht wird, oder #f, wenn das Programm nicht gefunden werden konnte.

8.6.5 Erstellungsphasen

(guix build utils) enthält auch Werkzeuge, um die von Erstellungssystemen benutzten Erstellungsphasen zu verändern (siehe Erstellungssysteme). Erstellungsphasen werden durch assoziative Listen oder „Alists“ repräsentiert (siehe Association Lists in Referenzhandbuch zu GNU Guile), wo jeder Schlüssel ein Symbol ist, das den Namen der Phase angibt, und der assoziierte Wert eine Prozedur ist (siehe Erstellungsphasen).

Die zum Kern von Guile („Guile core“) gehörenden Prozeduren und das Modul (srfi srfi-1) stellen beide Werkzeuge zum Bearbeiten von Alists zur Verfügung. Das Modul (guix build utils) ergänzt sie um Werkzeuge, die speziell für Erstellungsphasen gedacht sind.

Scheme-Syntax: modify-phases Phasen Klausel

Die Phasen der Reihe nach entsprechend jeder Klausel ändern. Die Klauseln dürfen eine der folgenden Formen haben:

(delete alter-Phasenname)
(replace alter-Phasenname neue-Phase)
(add-before alter-Phasenname neuer-Phasenname neue-Phase)
(add-after alter-Phasenname neuer-Phasenname neue-Phase)

Jeder Phasenname oben ist ein Ausdruck, der zu einem Symbol auswertet, und neue-Phase ist ein Ausdruck, der zu einer Prozedur auswertet.

Folgendes Beispiel stammt aus der Definition des grep-Pakets. Es fügt eine neue Phase namens egrep-und-fgrep-korrigieren hinzu, die auf die install-Phase folgen soll. Diese Phase ist eine Prozedur (lambda* bedeutet, sie ist eine Prozedur ohne eigenen Namen), die ein Schlüsselwort #:outputs bekommt und die restlichen Schlüsselwortargumente ignoriert (siehe Optional Arguments in Referenzhandbuch zu GNU Guile für mehr Informationen zu lambda* und optionalen sowie Schlüsselwort-Argumenten). In der Phase wird substitute* benutzt, um die installierten Skripte egrep und fgrep so zu verändern, dass sie grep anhand seines absoluten Dateinamens aufrufen:

(modify-phases %standard-phases
  (add-after 'install 'egrep-und-fgrep-korrigieren
    ;; 'egrep' und 'fgrep' patchen, damit diese 'grep' über den
    ;; absoluten Dateinamen ausführen statt es in $PATH zu suchen.
    (lambda* (#:key outputs #:allow-other-keys)
      (let* ((out (assoc-ref outputs "out"))
             (bin (string-append out "/bin")))
        (substitute* (list (string-append bin "/egrep")
                           (string-append bin "/fgrep"))
          (("^exec grep")
           (string-append "exec " bin "/grep")))
        #t))))

In dem Beispiel, das nun folgt, werden Phasen auf zweierlei Art geändert: Die Standard-configure-Phase wird gelöscht, meistens weil das Paket über kein configure-Skript oder etwas Ähnliches verfügt, und die vorgegebene install-Phase wird durch eine ersetzt, in der die zu installierenden ausführbaren Dateien manuell kopiert werden.

(modify-phases %standard-phases
  (delete 'configure)      ;kein 'configure'-Skript
  (replace 'install
    (lambda* (#:key outputs #:allow-other-keys)
      ;; Das Makefile im Paket enthält kein "install"-Ziel,
      ;; also müssen wir es selber machen.
      (let ((bin (string-append (assoc-ref outputs "out")
                                "/bin")))
        (install-file "footswitch" bin)
        (install-file "scythe" bin)
        #t))))

Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.7 Der Store

Konzeptionell ist der Store der Ort, wo Ableitungen nach erfolgreicher Erstellung gespeichert werden — standardmäßig finden Sie ihn in /gnu/store. Unterverzeichnisse im Store werden Store-Objekte oder manchmal auch Store-Pfade genannt. Mit dem Store ist eine Datenbank assoziiert, die Informationen enthält wie zum Beispiel, welche Store-Pfade jeder Store-Pfad jeweils referenziert, und eine Liste, welche Store-Objekte gültig sind, also Ergebnisse erfolgreicher Erstellungen sind. Die Datenbank befindet sich in localstatedir/guix/db, wobei localstatedir das mit --localstatedir bei der Ausführung von „configure“ angegebene Zustandsverzeichnis ist, normalerweise /var.

Auf den Store wird nur durch den Daemon im Auftrag seiner Clients zugegriffen (siehe Aufruf des guix-daemon). Um den Store zu verändern, verbinden sich Clients über einen Unix-Socket mit dem Daemon, senden ihm entsprechende Anfragen und lesen dann dessen Antwort — so etwas nennt sich entfernter Prozeduraufruf (englisch „Remote Procedure Call“ oder kurz RPC).

Anmerkung: Benutzer dürfen niemals Dateien in /gnu/store direkt verändern, sonst wären diese nicht mehr konsistent und die Grundannahmen im funktionalen Modell von Guix, dass die Objekte unveränderlich sind, wären dahin (siehe Einführung).

Siehe guix gc --verify für Informationen, wie die Integrität des Stores überprüft und nach versehentlichen Veränderungen unter Umständen wiederhergestellt werden kann.

Das Modul (guix store) bietet Prozeduren an, um sich mit dem Daemon zu verbinden und entfernte Prozeduraufrufe durchzuführen. Diese werden im Folgenden beschrieben. Das vorgegebene Verhalten von open-connection, und daher allen guix-Befehlen, ist, sich mit dem lokalen Daemon oder dem an der in der Umgebungsvariablen GUIX_DAEMON_SOCKET angegeben URL zu verbinden.

Umgebungsvariable: GUIX_DAEMON_SOCKET

Ist diese Variable gesetzt, dann sollte ihr Wert ein Dateipfad oder eine URI sein, worüber man sich mit dem Daemon verbinden kann. Ist der Wert der Pfad zu einer Datei, bezeichnet dieser einen Unix-Socket, mit dem eine Verbindung hergestellt werden soll. Ist er eine URI, so werden folgende URI-Schemata unterstützt:

file
unix

Für Unix-Sockets. file:///var/guix/daemon-socket/socket kann gleichbedeutend auch als /var/guix/daemon-socket/socket angegeben werden.

guix

Solche URIs benennen Verbindungen über TCP/IP ohne Verschlüsselung oder Authentifizierung des entfernten Rechners. Die URI muss den Hostnamen, also den Rechnernamen des entfernten Rechners, und optional eine Port-Nummer angeben (sonst wird als Vorgabe der Port 44146 benutzt):

guix://master.guix.example.org:1234

Diese Konfiguration ist für lokale Netzwerke wie etwa in Rechen-Clustern geeignet, wo sich nur vertrauenswürdige Knoten mit dem Erstellungs-Daemon z.B. unter master.guix.example.org verbinden können.

Die Befehlszeilenoption --listen von guix-daemon kann benutzt werden, damit er auf TCP-Verbindungen lauscht (siehe --listen).

ssh

Mit solchen URIs kann eine Verbindung zu einem entfernten Daemon über SSH hergestellt werden. Diese Funktionalität setzt Guile-SSH voraus (siehe Voraussetzungen) sowie eine funktionierende guile-Binärdatei, deren Ort im PATH der Zielmaschine eingetragen ist. Authentisierung über einen öffentlichen Schlüssel oder GSSAPI ist möglich. Eine typische URL sieht so aus:

ssh://charlie@guix.example.org:22

Was guix copy betrifft, richtet es sich nach den üblichen OpenSSH-Client-Konfigurationsdateien (siehe Aufruf von guix copy).

In Zukunft könnten weitere URI-Schemata unterstützt werden.

Anmerkung: Die Fähigkeit, sich mit entfernten Erstellungs-Daemons zu verbinden, sehen wir als experimentell an, Stand 1.2.0. Bitte diskutieren Sie mit uns jegliche Probleme oder Vorschläge, die Sie haben könnten (siehe Mitwirken).

Scheme-Prozedur: open-connection [Uri] [#:reserve-space? #t]

Sich mit dem Daemon über den Unix-Socket an Uri verbinden (einer Zeichenkette). Wenn reserve-space? wahr ist, lässt ihn das etwas zusätzlichen Speicher im Dateisystem reservieren, damit der Müllsammler auch dann noch funktioniert, wenn die Platte zu voll wird. Liefert ein Server-Objekt.

Uri nimmt standardmäßig den Wert von %default-socket-path an, was dem bei der Installation mit dem Aufruf von configure ausgewählten Vorgabeort entspricht, gemäß den Befehlszeilenoptionen, mit denen configure aufgerufen wurde.

Scheme-Prozedur: close-connection Server

Die Verbindung zum Server trennen.

Scheme-Variable: current-build-output-port

Diese Variable ist an einen SRFI-39-Parameter gebunden, der auf den Scheme-Port verweist, an den vom Daemon empfangene Erstellungsprotokolle und Fehlerprotokolle geschrieben werden sollen.

Prozeduren, die entfernte Prozeduraufrufe durchführen, nehmen immer ein Server-Objekt als ihr erstes Argument.

Scheme-Prozedur: valid-path? Server Pfad

Liefert #t, wenn der Pfad ein gültiges Store-Objekt benennt, und sonst #f (ein ungültiges Objekt kann auf der Platte gespeichert sein, tatsächlich aber ungültig sein, zum Beispiel weil es das Ergebnis einer abgebrochenen oder fehlgeschlagenen Erstellung ist).

Ein &store-protocol-error-Fehlerzustand wird ausgelöst, wenn der Pfad nicht mit dem Store-Verzeichnis als Präfix beginnt (/gnu/store).

Scheme-Prozedur: add-text-to-store Server Name Text [Referenzen]

Den Text im Store in einer Datei namens Name ablegen und ihren Store-Pfad zurückliefern. Referenzen ist die Liste der Store-Pfade, die der Store-Pfad dann referenzieren soll.

Scheme-Prozedur: build-derivations Store Ableitungen [Modus] Die Ableitungen erstellen (eine Liste von

<derivation>-Objekten, .drv-Dateinamen oder Paaren aus je Ableitung und Ausgabe. Dabei gilt der angegebene Modus — vorgegeben ist (build-mode normal).

Es sei erwähnt, dass im Modul (guix monads) eine Monade sowie monadische Versionen obiger Prozeduren angeboten werden, damit an Code, der auf den Store zugreift, bequemer gearbeitet werden kann (siehe Die Store-Monade).

Dieser Abschnitt ist im Moment noch unvollständig.


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.8 Ableitungen

Systemnahe Erstellungsaktionen sowie die Umgebung, in der selbige durchzuführen sind, werden durch Ableitungen dargestellt. Eine Ableitung enthält folgende Informationen:

Ableitungen ermöglichen es den Clients des Daemons, diesem Erstellungsaktionen für den Store mitzuteilen. Es gibt davon zwei Arten, sowohl Darstellungen im Arbeitsspeicher jeweils für Client und Daemon, als auch Dateien im Store, deren Namen auf .drv enden — diese Dateien werden als Ableitungspfade bezeichnet. Ableitungspfade können an die Prozedur build-derivations übergeben werden, damit die darin niedergeschriebenen Erstellungsaktionen durchgeführt werden (siehe Der Store).

Operationen wie das Herunterladen von Dateien und Checkouts von unter Versionskontrolle stehenden Quelldateien, bei denen der Hash des Inhalts im Voraus bekannt ist, werden als Ableitungen mit fester Ausgabe modelliert. Anders als reguläre Ableitungen sind die Ausgaben von Ableitungen mit fester Ausgabe unabhängig von ihren Eingaben — z.B. liefert das Herunterladen desselben Quellcodes dasselbe Ergebnis unabhängig davon, mit welcher Methode und welchen Werkzeugen er heruntergeladen wurde.

Den Ausgaben von Ableitungen — d.h. Erstellungergebnissen — ist eine Liste von Referenzen zugeordnet, die auch der entfernte Prozeduraufruf references oder der Befehl guix gc --references liefert (siehe Aufruf von guix gc). Referenzen sind die Menge der Laufzeitabhängigkeiten von Erstellungsergebnissen. Referenzen sind eine Teilmenge der Eingaben von Ableitungen; die Teilmenge wird automatisch ermittelt, indem der Erstellungsdaemon alle Dateien unter den Ausgaben nach Referenzen durchsucht.

Das Modul (guix derivations) stellt eine Repräsentation von Ableitungen als Scheme-Objekte zur Verfügung, zusammen mit Prozeduren, um Ableitungen zu erzeugen und zu manipulieren. Die am wenigsten abstrahierte Methode, eine Ableitung zu erzeugen, ist mit der Prozedur derivation:

Scheme-Prozedur: derivation Store Name Ersteller Argumente [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] [#:recursive? #f] [#:inputs '()] [#:env-vars '()]  [#:system

(%current-system)] [#:references-graphs #f]  [#:allowed-references #f] [#:disallowed-references #f]  [#:leaked-env-vars #f] [#:local-build? #f]  [#:substitutable? #t] [#:properties ’()] Eine Ableitungen mit den Argumenten erstellen und das resultierende <derivation>-Objekt liefern.

Wurden hash und hash-algo angegeben, wird eine Ableitung mit fester Ausgabe erzeugt — d.h. eine, deren Ausgabe schon im Voraus bekannt ist, wie z.B. beim Herunterladen einer Datei. Wenn des Weiteren auch recursive? wahr ist, darf die Ableitung mit fester Ausgabe eine ausführbare Datei oder ein Verzeichnis sein und hash muss die Prüfsumme eines Archivs mit dieser Ausgabe sein.

Ist references-graphs wahr, dann muss es eine Liste von Paaren aus je einem Dateinamen und einem Store-Pfad sein. In diesem Fall wird der Referenzengraph jedes Store-Pfads in einer Datei mit dem angegebenen Namen in der Erstellungsumgebung zugänglich gemacht, in einem einfachen Text-Format.

Ist allowed-references ein wahr, muss es eine Liste von Store-Objekten oder Ausgaben sein, die die Ausgabe der Ableitung referenzieren darf. Ebenso muss disallowed-references, wenn es auf wahr gesetzt ist, eine Liste von Dingen bezeichnen, die die Ausgaben nicht referenzieren dürfen.

Ist leaked-env-vars wahr, muss es eine Liste von Zeichenketten sein, die Umgebungsvariable benennen, die aus der Umgebung des Daemons in die Erstellungsumgebung überlaufen — ein „Leck“, englisch „leak“. Dies kann nur in Ableitungen mit fester Ausgabe benutzt werden, also wenn hash wahr ist. So ein Leck kann zum Beispiel benutzt werden, um Variable wie http_proxy an Ableitungen zu übergeben, die darüber Dateien herunterladen.

Ist local-build? wahr, wird die Ableitung als schlechter Kandidat für das Auslagern deklariert, der besser lokal erstellt werden sollte (siehe Auslagern des Daemons einrichten). Dies betrifft kleine Ableitungen, wo das Übertragen der Daten aufwendiger als ihre Erstellung ist.

Ist substitutable? falsch, wird deklariert, dass für die Ausgabe der Ableitung keine Substitute benutzt werden sollen (siehe Substitute). Das ist nützlich, wenn Pakete erstellt werden, die Details über den Prozessorbefehlssatz des Wirtssystems auslesen.

properties muss eine assoziative Liste enthalten, die „Eigenschaften“ der Ableitungen beschreibt. Sie wird genau so, wie sie ist, in der Ableitung gespeichert.

Hier ist ein Beispiel mit einem Shell-Skript, das als Ersteller benutzt wird. Es wird angenommen, dass Store eine offene Verbindung zum Daemon ist und bash auf eine ausführbare Bash im Store verweist:

(use-modules (guix utils)
             (guix store)
             (guix derivations))

(let ((builder   ; das Ersteller-Bash-Skript in den Store einfügen
        (add-text-to-store store "my-builder.sh"
                           "echo Hallo Welt > $out\n" '())))
  (derivation store "foo"
              bash `("-e" ,builder)
              #:inputs `((,bash) (,builder))
              #:env-vars '(("HOME" . "/homeless"))))
 #<derivation /gnu/store/…-foo.drv => /gnu/store/…-foo>

Wie man sehen kann, ist es umständlich, diese grundlegende Methode direkt zu benutzen. Natürlich ist es besser, Erstellungsskripts in Scheme zu schreiben! Am besten schreibt man den Erstellungscode als „G-Ausdruck“ und übergibt ihn an gexp->derivation. Mehr Informationen finden Sie im Abschnitt G-Ausdrücke.

Doch es gab einmal eine Zeit, zu der gexp->derivation noch nicht existiert hatte und wo das Zusammenstellen von Ableitungen mit Scheme-Erstellungscode noch mit build-expression->derivation bewerkstelligt wurde, was im Folgenden beschrieben wird. Diese Prozedur gilt als veraltet und man sollte nunmehr die viel schönere Prozedur gexp->derivation benutzen.

Scheme-Prozedur: build-expression->derivation Store Name Ausdruck  [#:system (%current-system)] [#:inputs '()] [#:outputs '("out")] [#:hash #f] [#:hash-algo #f]  [#:recursive? #f]

[#:env-vars ’()] [#:modules ’()]  [#:references-graphs #f] [#:allowed-references #f]  [#:disallowed-references #f]  [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f] Liefert eine Ableitung, die den Scheme-Ausdruck Ausdruck als Ersteller einer Ableitung namens Name ausführt. inputs muss die Liste der Eingaben enthalten, jeweils als Tupel (Name Ableitungspfad Unterableitung); wird keine Unterableitung angegeben, wird "out" angenommen. Module ist eine Liste der Namen von Guile-Modulen im momentanen Suchpfad, die in den Store kopiert, kompiliert und zur Verfügung gestellt werden, wenn der Ausdruck ausgeführt wird — z.B. ((guix build utils) (guix build gnu-build-system)).

Der Ausdruck wird in einer Umgebung ausgewertet, in der %outputs an eine Liste von Ausgabe-/Pfad-Paaren gebunden wurde und in der %build-inputs an eine Liste von Zeichenkette-/Ausgabepfad-Paaren gebunden wurde, die aus den inputs-Eingaben konstruiert worden ist. Optional kann in env-vars eine Liste von Paaren aus Zeichenketten stehen, die Name und Wert von für den Ersteller sichtbaren Umgebungsvariablen angeben. Der Ersteller terminiert, indem er exit mit dem Ergebnis des Ausdrucks aufruft; wenn also der Ausdruck den Wert #f liefert, wird angenommen, dass die Erstellung fehlgeschlagen ist.

Ausdruck wird mit einer Ableitung guile-for-build erstellt. Wird kein guile-for-build angegeben oder steht es auf #f, wird stattdessen der Wert der Fluiden %guile-for-build benutzt.

Siehe die Erklärungen zur Prozedur derivation für die Bedeutung von references-graphs, allowed-references, disallowed-references, local-build? und substitutable?.

Hier ist ein Beispiel einer Ableitung mit nur einer Ausgabe, die ein Verzeichnis erzeugt, in dem eine einzelne Datei enthalten ist:

(let ((builder '(let ((out (assoc-ref %outputs "out")))
                  (mkdir out)    ; das Verzeichnis
                                 ; /gnu/store/…-goo erstellen
                  (call-with-output-file (string-append out "/test")
                    (lambda (p)
                      (display '(Hallo Guix) p))))))
  (build-expression->derivation store "goo" builder))

 #<derivation /gnu/store/…-goo.drv => …>

Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.9 Die Store-Monade

Die auf dem Store arbeitenden Prozeduren, die in den vorigen Abschnitten beschrieben wurden, nehmen alle eine offene Verbindung zum Erstellungs-Daemon als ihr erstes Argument entgegen. Obwohl das ihnen zu Grunde liegende Modell funktional ist, weisen sie doch alle Nebenwirkungen auf oder hängen vom momentanen Zustand des Stores ab.

Ersteres ist umständlich, weil die Verbindung zum Erstellungs-Daemon zwischen all diesen Funktionen durchgereicht werden muss, so dass eine Komposition mit Funktionen ohne diesen Parameter unmöglich wird. Letzteres kann problematisch sein, weil Operationen auf dem Store Nebenwirkungen und/oder Abhängigkeiten von externem Zustand haben und ihre Ausführungsreihenfolge deswegen eine Rolle spielt.

Hier kommt das Modul (guix monads) ins Spiel. Im Rahmen dieses Moduls können Monaden benutzt werden und dazu gehört insbesondere eine für unsere Zwecke sehr nützliche Monade, die Store-Monade. Monaden sind ein Konstrukt, mit dem zwei Dinge möglich sind: eine Assoziation von Werten mit einem „Kontext“ (in unserem Fall ist das die Verbindung zum Store) und das Festlegen einer Reihenfolge für Berechnungen (hiermit sind auch Zugriffe auf den Store gemeint). Werte in einer Monade — solche, die mit weiterem Kontext assoziiert sind — werden monadische Werte genannt; Prozeduren, die solche Werte liefern, heißen monadische Prozeduren.

Betrachten Sie folgende „normale“ Prozedur:

(define (sh-symlink store)
  ;; Eine Ableitung liefern, die mit der ausführbaren Datei „bash“
  ;; symbolisch verknüpft.
  (let* ((drv (package-derivation store bash))
         (out (derivation->output-path drv))
         (sh  (string-append out "/bin/bash")))
    (build-expression->derivation store "sh"
                                  `(symlink ,sh %output))))

Unter Verwendung von (guix monads) und (guix gexp) lässt sie sich als monadische Funktion aufschreiben:

(define (sh-symlink)
  ;; Ebenso, liefert aber einen monadischen Wert.
  (mlet %store-monad ((drv (package->derivation bash)))
    (gexp->derivation "sh"
                      #~(symlink (string-append #$drv "/bin/bash")
                                 #$output))))

An der zweiten Version lassen sich mehrere Dinge beobachten: Der Parameter Store ist jetzt implizit geworden und wurde in die Aufrufe der monadischen Prozeduren package->derivation und gexp->derivation „eingefädelt“ und der von package->derivation gelieferte monadische Wert wurde mit mlet statt einem einfachen let gebunden.

Wie sich herausstellt, muss man den Aufruf von package->derivation nicht einmal aufschreiben, weil er implizit geschieht, wie wir später sehen werden (siehe G-Ausdrücke):

(define (sh-symlink)
  (gexp->derivation "sh"
                    #~(symlink (string-append #$bash "/bin/bash")
                               #$output)))

Die monadische sh-symlink einfach aufzurufen, bewirkt nichts. Wie jemand einst sagte: „Mit einer Monade geht man um, wie mit Gefangenen, gegen die man keine Beweise hat: Man muss sie laufen lassen.“ Um also aus der Monade auszubrechen und die gewünschte Wirkung zu erzielen, muss man run-with-store benutzen:

(run-with-store (open-connection) (sh-symlink))
 /gnu/store/…-sh-symlink

Erwähnenswert ist, dass das Modul (guix monad-repl) die REPL von Guile um neue „Meta-Befehle“ erweitert, mit denen es leichter ist, mit monadischen Prozeduren umzugehen: run-in-store und enter-store-monad. Mit Ersterer wird ein einzelner monadischer Wert durch den Store „laufen gelassen“:

scheme@(guile-user)> ,run-in-store (package->derivation hello)
$1 = #<derivation /gnu/store/…-hello-2.9.drv => …>

Mit Letzterer wird rekursiv eine weitere REPL betreten, in der alle Rückgabewerte automatisch durch den Store laufen gelassen werden:

scheme@(guile-user)> ,enter-store-monad
store-monad@(guile-user) [1]> (package->derivation hello)
$2 = #<derivation /gnu/store/…-hello-2.9.drv => …>
store-monad@(guile-user) [1]> (text-file "foo" "Hallo!")
$3 = "/gnu/store/…-foo"
store-monad@(guile-user) [1]> ,q
scheme@(guile-user)>

Beachten Sie, dass in einer store-monad-REPL keine nicht-monadischen Werte zurückgeliefert werden können.

Die wichtigsten syntaktischen Formen, um mit Monaden im Allgemeinen umzugehen, werden im Modul (guix monads) bereitgestellt und sind im Folgenden beschrieben.

Scheme-Syntax: with-monad Monade Rumpf ...

Alle >>=- oder return-Formen im Rumpf in der Monade auswerten.

Scheme-Syntax: return Wert

Einen monadischen Wert liefern, der den übergebenen Wert kapselt.

Scheme-Syntax: >>= mWert mProz ...

Den monadischen Wert mWert binden, wobei sein „Inhalt“ an die monadischen Prozeduren mProz… übergeben wird18. Es kann eine einzelne mProz oder mehrere davon geben, wie in diesem Beispiel:

(run-with-state
    (with-monad %state-monad
      (>>= (return 1)
           (lambda (x) (return (+ 1 x)))
           (lambda (x) (return (* 2 x)))))
  'irgendein-Zustand)

 4
 irgendein-Zustand
Scheme-Syntax: mlet Monade ((Variable mWert) ...) Rumpf ...
Scheme-Syntax: mlet* Monade ((Variable mWert) ...) Rumpf ... Die Variablen an die monadischen Werte mWert im

Rumpf binden, der eine Folge von Ausdrücken ist. Wie beim bind-Operator kann man es sich vorstellen als „Auspacken“ des rohen, nicht-monadischen Werts, der im mWert steckt, wobei anschließend dieser rohe, nicht-monadische Wert im Sichtbarkeitsbereich des Rumpfs von der Variablen bezeichnet wird. Die Form (Variable -> Wert) bindet die Variable an den „normalen“ Wert, wie es let tun würde. Die Bindungsoperation geschieht in der Reihenfolge von links nach rechts. Der letzte Ausdruck des Rumpfs muss ein monadischer Ausdruck sein und dessen Ergebnis wird das Ergebnis von mlet oder mlet* werden, wenn es durch die Monad laufen gelassen wurde.

mlet* verhält sich gegenüber mlet wie let* gegenüber let (siehe Local Bindings in Referenzhandbuch zu GNU Guile).

Scheme-System: mbegin Monade mAusdruck ...

Der Reihe nach den mAusdruck und die nachfolgenden monadischen Ausdrücke binden und als Ergebnis das des letzten Ausdrucks liefern. Jeder Ausdruck in der Abfolge muss ein monadischer Ausdruck sein.

Dies verhält sich ähnlich wie mlet, außer dass die Rückgabewerte der monadischen Prozeduren ignoriert werden. In diesem Sinn verhält es sich analog zu begin, nur auf monadischen Ausdrücken.

Scheme-System: mwhen Bedingung mAusdr0 mAusdr* ...

Wenn die Bedingung wahr ist, wird die Folge monadischer Ausdrücke mAusdr0..mAusdr* wie bei mbegin ausgewertet. Wenn die Bedingung falsch ist, wird *unspecified* („unbestimmt“) in der momentanen Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer Ausdruck sein.

Scheme-System: munless Bedingung mAusdr0 mAusdr* ...

Wenn die Bedingung falsch ist, wird die Folge monadischer Ausdrücke mAusdr0..mAusdr* wie bei mbegin ausgewertet. Wenn die Bedingung wahr ist, wird *unspecified* („unbestimmt“) in der momentanen Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer Ausdruck sein.

Das Modul (guix monads) macht die Zustandsmonade (englisch „state monad“) verfügbar, mit der ein zusätzlicher Wert — der Zustand — durch die monadischen Prozeduraufrufe gefädelt werden kann.

Scheme-Variable: %state-monad

Die Zustandsmonade. Prozeduren in der Zustandsmonade können auf den gefädelten Zustand zugreifen und ihn verändern.

Betrachten Sie das folgende Beispiel. Die Prozedur Quadrat liefert einen Wert in der Zustandsmonade zurück. Sie liefert das Quadrat ihres Arguments, aber sie inkrementiert auch den momentanen Zustandswert:

(define (Quadrat x)
  (mlet %state-monad ((Anzahl (current-state)))
    (mbegin %state-monad
      (set-current-state (+ 1 Anzahl))
      (return (* x x)))))

(run-with-state (sequence %state-monad (map Quadrat (iota 3))) 0)
 (0 1 4)
 3

Wird das „durch“ die Zustandsmonade %state-monad laufen gelassen, erhalten wir jenen zusätzlichen Zustandswert, der der Anzahl der Aufrufe von Quadrat entspricht.

Monadische Prozedur: current-state

Liefert den momentanen Zustand als einen monadischen Wert.

Monadische Prozedur: set-current-state Wert

Setzt den momentanen Zustand auf Wert und liefert den vorherigen Zustand als einen monadischen Wert.

Monadische Prozedur: state-push Wert

Hängt den Wert vorne an den momentanen Zustand an, der eine Liste sein muss. Liefert den vorherigen Zustand als monadischen Wert.

Monadische Prozedur: state-pop

Entfernt einen Wert vorne vom momentanen Zustand und liefert ihn als monadischen Wert zurück. Dabei wird angenommen, dass es sich beim Zustand um eine Liste handelt.

Scheme-Prozedur: run-with-state mWert [Zustand]

Den monadischen Wert mWert mit Zustand als initialem Zustand laufen lassen. Dies liefert zwei Werte: den Ergebniswert und den Ergebniszustand.

Die zentrale Schnittstelle zur Store-Monade, wie sie vom Modul (guix store) angeboten wird, ist die Folgende:

Scheme-Variable: %store-monad

Die Store-Monade — ein anderer Name für %state-monad.

Werte in der Store-Monade kapseln Zugriffe auf den Store. Sobald ihre Wirkung gebraucht wird, muss ein Wert der Store-Monade „ausgewertet“ werden, indem er an die Prozedur run-with-store übergeben wird (siehe unten).

Scheme-Prozedur: run-with-store Store mWert [#:guile-for-build] [#:system (%current-system)]

Den mWert, einen monadischen Wert in der Store-Monade, in der offenen Verbindung Store laufen lassen.

Monadische Prozedur: text-file Name Text [Referenzen]

Als monadischen Wert den absoluten Dateinamen im Store für eine Datei liefern, deren Inhalt der der Zeichenkette Text ist. Referenzen ist dabei eine Liste von Store-Objekten, die die Ergebnis-Textdatei referenzieren wird; der Vorgabewert ist die leere Liste.

Monadische Prozedur: binary-file Name Daten [Referenzen]

Den absoluten Dateinamen im Store als monadischen Wert für eine Datei liefern, deren Inhalt der des Byte-Vektors Daten ist. Referenzen ist dabei eine Liste von Store-Objekten, die die Ergebnis-Binärdatei referenzieren wird; der Vorgabewert ist die leere Liste.

Monadische Prozedur: interned-file Datei [Name] [#:recursive? #t] [#:select? (const #t)] Liefert den Namen der Datei,

nachdem sie in den Store interniert wurde. Dabei wird der Name als ihr Store-Name verwendet, oder, wenn kein Name angegeben wurde, der Basisname der Datei.

Ist recursive? wahr, werden in der Datei enthaltene Dateien rekursiv hinzugefügt; ist die Datei eine flache Datei und recursive? ist wahr, wird ihr Inhalt in den Store eingelagert und ihre Berechtigungs-Bits übernommen.

Steht recursive? auf wahr, wird (select? Datei Stat) für jeden Verzeichniseintrag aufgerufen, wobei Datei der absolute Dateiname und Stat das Ergebnis von lstat ist, außer auf den Einträgen, wo select? keinen wahren Wert liefert.

Folgendes Beispiel fügt eine Datei unter zwei verschiedenen Namen in den Store ein:

(run-with-store (open-connection)
  (mlet %store-monad ((a (interned-file "README"))
                      (b (interned-file "README" "LEGU-MIN")))
    (return (list a b))))

 ("/gnu/store/rwm…-README" "/gnu/store/44i…-LEGU-MIN")

Das Modul (guix packages) exportiert die folgenden paketbezogenen monadischen Prozeduren:

Monadische Prozedur: package-file Paket [Datei] [#:system (%current-system)] [#:target #f]  [#:output "out"] Liefert als

monadischen Wert den absoluten Dateinamen der Datei innerhalb des Ausgabeverzeichnisses output des Pakets. Wird keine Datei angegeben, wird der Name des Ausgabeverzeichnisses output für das Paket zurückgeliefert. Ist target wahr, wird sein Wert als das Zielsystem bezeichnendes Tripel zum Cross-Kompilieren benutzt.

Beachten Sie, dass durch diese Prozedur das Paket nicht erstellt wird, also muss ihr Ergebnis keine bereits existierende Datei bezeichnen, kann aber. Wir empfehlen, diese Prozedur nur dann zu benutzen, wenn Sie wissen, was Sie tun.

Monadische Prozedur: package->derivation Paket [System]
Monadische Prozedur: package->cross-derivation Paket Ziel [System] Monadische Version von package-derivation

und package-cross-derivation (siehe Pakete definieren).


Nächste: , Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.10 G-Ausdrücke

Es gibt also „Ableitungen“, die eine Abfolge von Erstellungsaktionen repräsentieren, die durchgeführt werden müssen, um ein Objekt im Store zu erzeugen (siehe Ableitungen). Diese Erstellungsaktionen werden durchgeführt, nachdem der Daemon gebeten wurde, die Ableitungen tatsächlich zu erstellen; dann führt der Daemon sie in einer isolierten Umgebung (einem sogenannten Container) aus (siehe Aufruf des guix-daemon).

Wenig überraschend ist, dass wir diese Erstellungsaktionen gerne in Scheme schreiben würden. Wenn wir das tun, bekommen wir zwei verschiedene Schichten von Scheme-Code19: den „wirtsseitigen Code“ („host code“) — also Code, der Pakete definiert, mit dem Daemon kommuniziert etc. — und den „erstellungsseitigen Code“ („build code“) — also Code, der die Erstellungsaktionen auch wirklich umsetzt, indem Dateien erstellt werden, make aufgerufen wird und so weiter (siehe Erstellungsphasen).

Um eine Ableitung und ihre Erstellungsaktionen zu beschreiben, muss man normalerweise erstellungsseitigen Code im wirtsseitigen Code einbetten. Das bedeutet, man behandelt den erstellungsseitigen Code als Daten, was wegen der Homoikonizität von Scheme — dass Code genauso als Daten repräsentiert werden kann — sehr praktisch ist. Doch brauchen wir hier mehr als nur den normalen Quasimaskierungsmechanismus mit quasiquote in Scheme, wenn wir Erstellungsausdrücke konstruieren möchten.

Das Modul (guix gexp) implementiert G-Ausdrücke, eine Form von S-Ausdrücken, die zu Erstellungsausdrücken angepasst wurden. G-Ausdrücke (englisch „G-expressions“, kurz Gexps) setzen sich grundlegend aus drei syntaktischen Formen zusammen: gexp, ungexp und ungexp-splicing (alternativ einfach: #~, #$ und #$@), die jeweils mit quasiquote, unquote und unquote-splicing vergleichbar sind (siehe quasiquote in Referenzhandbuch zu GNU Guile). Es gibt aber auch erhebliche Unterschiede:

Dieser Mechanismus ist nicht auf Pakete und Ableitung beschränkt: Es können Compiler definiert werden, die weitere abstrakte, hochsprachliche Objekte auf Ableitungen oder Dateien im Store „herunterbrechen“, womit diese Objekte dann auch in G-Ausdrücken eingefügt werden können. Zum Beispiel sind „dateiartige Objekte“ ein nützlicher Typ solcher abstrakter Objekte. Mit ihnen können Dateien leicht in den Store eingefügt und von Ableitungen und anderem referenziert werden (siehe unten local-file und plain-file).

Zur Veranschaulichung dieser Idee soll uns dieses Beispiel eines G-Ausdrucks dienen:

(define build-exp
  #~(begin
      (mkdir #$output)
      (chdir #$output)
      (symlink (string-append #$coreutils "/bin/ls")
               "list-files")))

Indem wir diesen G-Ausdruck an gexp->derivation übergeben, bekommen wir eine Ableitung, die ein Verzeichnis mit genau einer symbolischen Verknüpfung auf /gnu/store/…-coreutils-8.22/bin/ls erstellt:

(gexp->derivation "das-ding" build-exp)

Wie man es erwarten würde, wird die Zeichenkette "/gnu/store/…-coreutils-8.22" anstelle der Referenzen auf das Paket coreutils im eigentlichen Erstellungscode eingefügt und coreutils automatisch zu einer Eingabe der Ableitung gemacht. Genauso wird auch #$output (was äquivalent zur Schreibweise (ungexp output) ist) ersetzt durch eine Zeichenkette mit dem Namen der Ausgabe der Ableitung.

Im Kontext der Cross-Kompilierung bietet es sich an, zwischen Referenzen auf die native Erstellung eines Pakets — also der, die auf dem Wirtssystem ausgeführt werden kann — und Referenzen auf Cross-Erstellungen eines Pakets zu unterscheiden. Hierfür spielt #+ dieselbe Rolle wie #$, steht aber für eine Referenz auf eine native Paketerstellung.

(gexp->derivation "vi"
   #~(begin
       (mkdir #$output)
       (mkdir (string-append #$output "/bin"))
       (system* (string-append #+coreutils "/bin/ln")
                "-s"
                (string-append #$emacs "/bin/emacs")
                (string-append #$output "/bin/vi")))
   #:target "aarch64-linux-gnu")

Im obigen Beispiel wird die native Erstellung der coreutils benutzt, damit ln tatsächlich auf dem Wirtssystem ausgeführt werden kann, aber danach die cross-kompilierte Erstellung von emacs referenziert.

Eine weitere Funktionalität von G-Ausdrücken stellen importierte Module dar. Manchmal will man bestimmte Guile-Module von der „wirtsseitigen Umgebung“ im G-Ausdruck benutzen können, deswegen sollten diese Module in die „erstellungsseitige Umgebung“ importiert werden. Die with-imported-modules-Form macht das möglich:

(let ((build (with-imported-modules '((guix build utils))
               #~(begin
                   (use-modules (guix build utils))
                   (mkdir-p (string-append #$output "/bin"))))))
  (gexp->derivation "leeres-Verzeichnis"
                    #~(begin
                        #$build
                        (display "Erfolg!\n")
                        #t)))

In diesem Beispiel wird das Modul (guix build utils) automatisch in die isolierte Erstellungsumgebung unseres G-Ausdrucks geholt, so dass (use-modules (guix build utils)) wie erwartet funktioniert.

Normalerweise möchten Sie, dass der Abschluss eines Moduls importiert wird — also das Modul und alle Module, von denen es abhängt — statt nur das Modul selbst. Ansonsten scheitern Versuche, das Modul zu benutzen, weil seine Modulabhängigkeiten fehlen. Die Prozedur source-module-closure berechnet den Abschluss eines Moduls, indem es den Kopf seiner Quelldatei analysiert, deswegen schafft die Prozedur hier Abhilfe:

(use-modules (guix modules))   ;„source-module-closure“ verfügbar machen

(with-imported-modules (source-module-closure
                         '((guix build utils)
                           (gnu build vm)))
  (gexp->derivation "etwas-mit-vm"
                    #~(begin
                        (use-modules (guix build utils)
                                     (gnu build vm))
                        )))

Auf die gleiche Art können Sie auch vorgehen, wenn Sie nicht bloß reine Scheme-Module importieren möchten, sondern auch „Erweiterungen“ wie Guile-Anbindungen von C-Bibliotheken oder andere „vollumfängliche“ Pakete. Sagen wir, Sie bräuchten das Paket guile-json auf der Erstellungsseite, dann könnten Sie es hiermit bekommen:

(use-modules (gnu packages guile))  ;für „guile-json“

(with-extensions (list guile-json)
  (gexp->derivation "etwas-mit-json"
                    #~(begin
                        (use-modules (json))
                        )))

Die syntaktische Form, in der G-Ausdrücke konstruiert werden, ist im Folgenden zusammengefasst.

Scheme-Syntax: #~Ausdruck
Scheme-Syntax: (gexp Ausdruck)

Liefert einen G-Ausdruck, der den Ausdruck enthält. Der Ausdruck kann eine oder mehrere der folgenden Formen enthalten:

#$Objekt
(ungexp Objekt)

Eine Referenz auf das Objekt einführen. Das Objekt kann einen der unterstützten Typen haben, zum Beispiel ein Paket oder eine Ableitung, so dass die ungexp-Form durch deren Ausgabedateiname ersetzt wird — z.B. "/gnu/store/…-coreutils-8.22.

Wenn das Objekt eine Liste ist, wird diese durchlaufen und alle unterstützten Objekte darin auf diese Weise ersetzt.

Wenn das Objekt ein anderer G-Ausdruck ist, wird sein Inhalt eingefügt und seine Abhängigkeiten zu denen des äußeren G-Ausdrucks hinzugefügt.

Wenn das Objekt eine andere Art von Objekt ist, wird es so wie es ist eingefügt.

#$Objekt:Ausgabe
(ungexp Objekt Ausgabe)

Dies verhält sich wie die Form oben, bezieht sich aber ausdrücklich auf die angegebene Ausgabe des Objekts — dies ist nützlich, wenn das Objekt mehrere Ausgaben generiert (siehe Pakete mit mehreren Ausgaben.).

#+Objekt
#+Objekt:Ausgabe
(ungexp-native Objekt)
(ungexp-native Objekt Ausgabe)

Das Gleiche wie ungexp, jedoch wird im Kontext einer Cross-Kompilierung eine Referenz auf die native Erstellung des Objekts eingefügt.

#$output[:Ausgabe]
(ungexp output [Ausgabe])

Fügt eine Referenz auf die angegebene Ausgabe dieser Ableitung ein, oder auf die Hauptausgabe, wenn keine Ausgabe angegeben wurde.

Dies ist nur bei G-Ausdrücken sinnvoll, die an gexp->derivation übergeben werden.

#$@Liste
(ungexp-splicing Liste)

Das Gleiche wie oben, jedoch wird nur der Inhalt der Liste in die äußere Liste eingespleißt.

#+@Liste
(ungexp-native-splicing Liste)

Das Gleiche, aber referenziert werden native Erstellungen der Objekte in der Liste.

G-Ausdrücke, die mit gexp oder #~ erzeugt wurden, sind zur Laufzeit Objekte vom Typ gexp? (siehe unten).

Scheme-Syntax: with-imported-modules Module Rumpf

Markiert die in Rumpf… definierten G-Ausdrücke, dass sie in ihrer Ausführungsumgebung die angegebenen Module brauchen.

Jedes Objekt unter den Modulen kann der Name eines Moduls wie (guix build utils) sein, oder es kann nacheinander ein Modulname, ein Pfeil und ein dateiartiges Objekt sein:

`((guix build utils)
  (guix gcrypt)
  ((guix config) => ,(scheme-file "config.scm"
                                  #~(define-module ))))

Im Beispiel oben werden die ersten beiden Module vom Suchpfad genommen und das letzte aus dem angegebenen dateiartigen Objekt erzeugt.

Diese Form hat einen lexikalischen Sichtbarkeitsbereich: Sie wirkt sich auf die direkt in Rumpf… definierten G-Ausdrücke aus, aber nicht auf jene, die, sagen wir, in aus Rumpf… heraus aufgerufenen Prozeduren definiert wurden.

Scheme-Syntax: with-extensions Erweiterungen Rumpf

Markiert die in Rumpf… definierten G-Ausdrücke, dass sie Erweiterungen in ihrer Erstellungs- und Ausführungsumgebung benötigen. Erweiterungen sind typischerweise eine Liste von Paketobjekten wie zum Beispiel die im Modul (gnu packages guile) definierten.

Konkret werden die unter den Erweiterungen aufgeführten Pakete zum Ladepfad hinzugefügt, während die in Rumpf… aufgeführten importierten Module kompiliert werden und sie werden auch zum Ladepfad des von Rumpf… gelieferten G-Ausdrucks hinzugefügt.

Scheme-Prozedur: gexp? Objekt

Liefert #t, wenn das Objekt ein G-Ausdruck ist.

G-Ausdrücke sind dazu gedacht, auf die Platte geschrieben zu werden, entweder als Code, der eine Ableitung erstellt, oder als einfache Dateien im Store. Die monadischen Prozeduren unten ermöglichen Ihnen das (siehe Die Store-Monade, wenn Sie mehr Informationen über Monaden suchen).

Monadische Prozedur: gexp->derivation Name Ausdruck [#:system (%current-system)] [#:target #f] [#:graft? #t]  [#:hash #f]

[#:hash-algo #f]  [#:recursive? #f] [#:env-vars ’()] [#:modules ’()]  [#:module-path %load-path]  [#:effective-version "2.2"]  [#:references-graphs #f] [#:allowed-references #f]  [#:disallowed-references #f]  [#:leaked-env-vars #f]  [#:script-name (string-append Name "-builder")]  [#:deprecation-warnings #f]  [#:local-build? #f] [#:substitutable? #t]  [#:properties ’()] [#:guile-for-build #f] Liefert eine Ableitung unter dem Namen, die jeden Ausdruck (ein G-Ausdruck) mit guile-for-build (eine Ableitung) für das System erstellt; der Ausdruck wird dabei in einer Datei namens script-name gespeichert. Wenn „target“ wahr ist, wird es beim Cross-Kompilieren als Zieltripel für mit Ausdruck bezeichnete Pakete benutzt.

modules gilt als veraltet; stattdessen sollte with-imported-modules benutzt werden. Die Bedeutung ist, dass die Module im Ausführungskontext des Ausdrucks verfügbar gemacht werden; modules ist dabei eine Liste von Namen von Guile-Modulen, die im Modulpfad module-path gesucht werden, um sie in den Store zu kopieren, zu kompilieren und im Ladepfad während der Ausführung des Ausdrucks verfügbar zu machen — z.B. ((guix build utils) (guix build gnu-build-system)).

effective-version bestimmt, unter welcher Zeichenkette die Erweiterungen des Ausdrucks zum Suchpfad hinzugefügt werden (siehe with-extensions) — z.B. "2.2".

graft? bestimmt, ob vom Ausdruck benannte Pakete veredelt werden sollen, falls Veredelungen zur Verfügung stehen.

Ist references-graphs wahr, muss es eine Liste von Tupeln in einer der folgenden Formen sein:

(Dateiname Paket)
(Dateiname Paket Ausgabe)
(Dateiname Ableitung)
(Dateiname Ableitung Ausgabe)
(Dateiname Store-Objekt)

Bei jedem Element von references-graphs wird das rechts Stehende automatisch zu einer Eingabe des Erstellungsprozesses vom Ausdruck gemacht. In der Erstellungsumgebung enthält das, was mit Dateiname bezeichnet wird, den Referenzgraphen des entsprechenden Objekts in einem einfachen Textformat.

allowed-references muss entweder #f oder eine Liste von Ausgabenamen und Paketen sein. Eine solche Liste benennt Store-Objekte, die das Ergebnis referenzieren darf. Jede Referenz auf ein nicht dort aufgeführtes Store-Objekt löst einen Erstellungsfehler aus. Genauso funktioniert disallowed-references, was eine Liste von Objekten sein kann, die von den Ausgaben nicht referenziert werden dürfen.

deprecation-warnings bestimmt, ob beim Kompilieren von Modulen Warnungen angezeigt werden sollen, wenn auf als veraltet markierten Code zugegriffen wird. deprecation-warnings kann #f, #t oder 'detailed (detailliert) sein.

Die anderen Argumente verhalten sich wie bei derivation (siehe Ableitungen).

Die im Folgenden erklärten Prozeduren local-file, plain-file, computed-file, program-file und scheme-file liefern dateiartige Objekte. Das bedeutet, dass diese Objekte, wenn sie in einem G-Ausdruck demaskiert werden, zu einer Datei im Store führen. Betrachten Sie zum Beispiel diesen G-Ausdruck:

#~(system* #$(file-append glibc "/sbin/nscd") "-f"
           #$(local-file "/tmp/my-nscd.conf"))

Der Effekt hiervon ist, dass /tmp/my-nscd.conf „interniert“ wird, indem es in den Store kopiert wird. Sobald er umgeschrieben wurde, zum Beispiel über gexp->derivation, referenziert der G-Ausdruck diese Kopie im /gnu/store. Die Datei in /tmp zu bearbeiten oder zu löschen, hat dann keinen Effekt mehr darauf, was der G-Ausdruck tut. plain-file kann in ähnlicher Weise benutzt werden, es unterscheidet sich aber darin, dass dort der Prozedur der Inhalt der Datei als eine Zeichenkette übergeben wird.

Scheme-Prozedur: local-file Datei [Name] [#:recursive? #f] [#:select? (const #t)] Liefert ein Objekt, dass die lokale

Datei Datei repräsentiert und sie zum Store hinzufügen lässt; dieses Objekt kann in einem G-Ausdruck benutzt werden. Wurde für die Datei ein relativer Dateiname als literaler Ausdruck angegeben, wird sie relativ zur Quelldatei gesucht, in der diese Form steht. Wurde die Datei nicht als literale Zeichenkette angegeben, wird sie zur Laufzeit relativ zum aktuellen Arbeitsverzeichnis gesucht. Die Datei wird unter dem angegebenen Namen im Store abgelegt — als Vorgabe wird dabei der Basisname der Datei genommen.

Ist recursive? wahr, werden in der Datei enthaltene Dateien rekursiv hinzugefügt; ist die Datei eine flache Datei und recursive? ist wahr, wird ihr Inhalt in den Store eingelagert und ihre Berechtigungs-Bits übernommen.

Steht recursive? auf wahr, wird (select? Datei Stat) für jeden Verzeichniseintrag aufgerufen, wobei Datei der absolute Dateiname und Stat das Ergebnis von lstat ist, außer auf den Einträgen, wo select? keinen wahren Wert liefert.

Dies ist das deklarative Gegenstück zur monadischen Prozedur interned-file (siehe interned-file).

Scheme-Prozedur: plain-file Name Inhalt

Liefert ein Objekt, das eine Textdatei mit dem angegebenen Namen repräsentiert, die den angegebenen Inhalt hat (eine Zeichenkette oder ein Bytevektor), welche zum Store hinzugefügt werden soll.

Dies ist das deklarative Gegenstück zu text-file.

Scheme-Prozedur: computed-file Name G-Ausdruck [#:local-build? #t] [#:options '()] Liefert ein Objekt, das das Store-Objekt

mit dem Namen repräsentiert, eine Datei oder ein Verzeichnis, das vom G-Ausdruck berechnet wurde. Wenn local-build? auf wahr steht (wie vorgegeben), wird auf der lokalen Maschine erstellt. options ist eine Liste zusätzlicher Argumente, die an gexp->derivation übergeben werden.

Dies ist das deklarative Gegenstück zu gexp->derivation.

Monadische Prozedur: gexp->script Name Ausdruck [#:guile (default-guile)] [#:module-path %load-path]  [#:system

(%current-system)] [#:target #f] Liefert ein ausführbares Skript namens Name, das den Ausdruck mit dem angegebenen guile ausführt, wobei vom Ausdruck importierte Module in seinem Suchpfad stehen. Die Module des Ausdrucks werden dazu im Modulpfad module-path gesucht.

Folgendes Beispiel erstellt ein Skript, das einfach nur den Befehl ls ausführt:

(use-modules (guix gexp) (gnu packages base))

(gexp->script "list-files"
              #~(execl #$(file-append coreutils "/bin/ls")
                       "ls"))

Lässt man es durch den Store „laufen“ (siehe run-with-store), erhalten wir eine Ableitung, die eine ausführbare Datei /gnu/store/…-list-files generiert, ungefähr so:

#!/gnu/store/…-guile-2.0.11/bin/guile -ds
!#
(execl "/gnu/store/…-coreutils-8.22"/bin/ls" "ls")
Scheme-Prozedur: program-file Name G-Ausdruck [#:guile #f] [#:module-path %load-path] Liefert ein Objekt, das eine

ausführbare Store-Datei Name repräsentiert, die den G-Ausdruck ausführt. guile ist das zu verwendende Guile-Paket, mit dem das Skript ausgeführt werden kann. Importierte Module des G-Ausdrucks werden im Modulpfad module-path gesucht.

Dies ist das deklarative Gegenstück zu gexp->script.

Monadische Prozedur: gexp->file Name G-Ausdruck [#:set-load-path? #t] [#:module-path %load-path]  [#:splice? #f]  [#:guile

(default-guile)] Liefert eine Ableitung, die eine Datei Name erstellen wird, deren Inhalt der G-Ausdruck ist. Ist splice? wahr, dann wird G-Ausdruck stattdessen als eine Liste von mehreren G-Ausdrücken behandelt, die alle in die resultierende Datei gespleißt werden.

Ist set-load-path? wahr, wird in die resultierende Datei Code hinzugefügt, der den Ladepfad %load-path und den Ladepfad für kompilierte Dateien %load-compiled-path festlegt, die für die importierten Module des G-Ausdrucks nötig sind. Die Module des G-Ausdrucks werden im Modulpfad module-path gesucht.

Die resultierende Datei referenziert alle Abhängigkeiten des G-Ausdrucks oder eine Teilmenge davon.

Scheme-Prozedur: scheme-file Name Ausdruck [#:splice? #f] [#:set-load-path? #t] Liefert ein Objekt, das die

Scheme-Datei Name mit dem G-Ausdruck als Inhalt repräsentiert.

Dies ist das deklarative Gegenstück zu gexp->file.

Monadische Prozedur: text-file* Name Text

Liefert eine Ableitung als monadischen Wert, welche eine Textdatei erstellt, in der der gesamte Text enthalten ist. Text kann eine Folge nicht nur von Zeichenketten, sondern auch Objekten beliebigen Typs sein, die in einem G-Ausdruck benutzt werden können, also Paketen, Ableitungen, Objekte lokaler Dateien und so weiter. Die resultierende Store-Datei referenziert alle davon.

Diese Variante sollte gegenüber text-file bevorzugt verwendet werden, wann immer die zu erstellende Datei Objekte im Store referenzieren wird. Typischerweise ist das der Fall, wenn eine Konfigurationsdatei erstellt wird, die Namen von Store-Dateien enthält, so wie hier:

(define (profile.sh)
  ;; Liefert den Namen eines Shell-Skripts im Store,
  ;; welcher die Umgebungsvariable „PATH“ initialisiert.
  (text-file* "profile.sh"
              "export PATH=" coreutils "/bin:"
              grep "/bin:" sed "/bin\n"))

In diesem Beispiel wird die resultierende Datei /gnu/store/…-profile.sh sowohl coreutils, grep als auch sed referenzieren, so dass der Müllsammler diese nicht löscht, während die resultierende Datei noch lebendig ist.

Scheme-Prozedur: mixed-text-file Name Text

Liefert ein Objekt, was die Store-Datei Name repräsentiert, die Text enthält. Text ist dabei eine Folge von Zeichenketten und dateiartigen Objekten wie zum Beispiel:

(mixed-text-file "profile"
                 "export PATH=" coreutils "/bin:" grep "/bin")

Dies ist das deklarative Gegenstück zu text-file*.

Scheme-Prozedur: file-union Name Dateien

Liefert ein <computed-file>, das ein Verzeichnis mit allen Dateien enthält. Jedes Objekt in Dateien muss eine zweielementige Liste sein, deren erstes Element der im neuen Verzeichnis zu benutzende Dateiname ist und deren zweites Element ein G-Ausdruck ist, der die Zieldatei benennt. Hier ist ein Beispiel:

(file-union "etc"
            `(("hosts" ,(plain-file "hosts"
                                    "127.0.0.1 localhost"))
              ("bashrc" ,(plain-file "bashrc"
                                     "alias ls='ls --color=auto'"))))

Dies liefert ein Verzeichnis etc, das zwei Dateien enthält.

Scheme-Prozedur: directory-union Name Dinge

Liefert ein Verzeichnis, was die Vereinigung (englisch „Union“) der Dinge darstellt, wobei Dinge eine Liste dateiartiger Objekte sein muss, die Verzeichnisse bezeichnen. Zum Beispiel:

(directory-union "guile+emacs" (list guile emacs))

Das liefert ein Verzeichnis, welches die Vereinigung der Pakete guile und emacs ist.

Scheme-Prozedur: file-append Objekt Suffix

Liefert ein dateiartiges Objekt, das zur Aneinanderreihung von Objekt und Suffix umgeschrieben wird, wobei das Objekt ein herunterbrechbares Objekt und jedes Suffix eine Zeichenkette sein muss.

Betrachten Sie zum Beispiel diesen G-Ausdruck:

(gexp->script "uname-ausfuehren"
              #~(system* #$(file-append coreutils
                                        "/bin/uname")))

Denselben Effekt könnte man erreichen mit:

(gexp->script "uname-ausfuehren"
              #~(system* (string-append #$coreutils
                                        "/bin/uname")))

Es gibt jedoch einen Unterschied, nämlich enthält das resultierende Skript bei file-append tatsächlich den absoluten Dateinamen als Zeichenkette, während im anderen Fall das resultierende Skript einen Ausdruck (string-append …) enthält, der den Dateinamen erst zur Laufzeit zusammensetzt.

Scheme-Syntax: let-system System Rumpf
Scheme-Syntax: let-system (System Zielsystem) Rumpf

System an das System binden, für das momentan erstellt wird — z.B. "x86_64-linux" —, während der Rumpf ausgeführt wird.

In der zweiten Form wird zusätzlich das Ziel an das aktuelle Ziel („Target“) bei der Cross-Kompilierung gebunden. Dabei handelt es sich um ein GNU-Tripel wie z.B. "arm-linux-gnueabihf" — oder um #f, wenn nicht cross-kompiliert wird.

let-system zu benutzen, bietet sich dann an, wenn einmal das in den G-Ausdruck gespleißte Objekt vom Zielsystem abhängen sollte, wie in diesem Beispiel:

#~(system*
   #+(let-system system
       (cond ((string-prefix? "armhf-" system)
              (file-append qemu "/bin/qemu-system-arm"))
             ((string-prefix? "x86_64-" system)
              (file-append qemu "/bin/qemu-system-x86_64"))
             (else
              (error "weiß nicht!"))))
   "-net" "user" #$image)
Scheme-Syntax: with-parameters ((Parameter Wert) …) Ausdruck

Mit diesem Makro verhält es sich ähnlich wie mit der parameterize-Form für dynamisch gebundene Parameter (siehe Parameters in Referenzhandbuch zu GNU Guile). Der Hauptunterschied ist, dass es sich erst auswirkt, wenn das vom Ausdruck zurückgelieferte dateiartige Objekt auf eine Ableitung oder ein Store-Objekt heruntergebrochen wird.

Eine typische Anwendung von with-parameters ist, den für ein bestimmtes Objekt geltenden Systemtyp zwingend festzulegen:

(with-parameters ((%current-system "i686-linux"))
  coreutils)

Obiges Beispiel liefert ein Objekt, das der Erstellung von Coreutils für die i686-Architektur entspricht, egal was der aktuelle Wert von %current-system ist.

Natürlich gibt es zusätzlich zu in „wirtsseitigem“ Code eingebetteten G-Ausdrücken auch Module mit „erstellungsseitig“ nutzbaren Werkzeugen. Um klarzustellen, dass sie dafür gedacht sind, in der Erstellungsschicht benutzt zu werden, bleiben diese Module im Namensraum (guix build …).

Intern werden hochsprachliche, abstrakte Objekte mit ihrem Compiler entweder zu Ableitungen oder zu Store-Objekten heruntergebrochen. Wird zum Beispiel ein Paket heruntergebrochen, bekommt man eine Ableitung, während ein plain-file zu einem Store-Objekt heruntergebrochen wird. Das wird mit der monadischen Prozedur lower-object bewerkstelligt.

Monadische Prozedur: lower-object Objekt [System] [#:target #f] Liefert die Ableitung oder das Store-Objekt, das dem

Objekt für System als Wert in der Store-Monade %store-monad entspricht, cross-kompiliert für das Zieltripel target, wenn target wahr ist. Das Objekt muss ein Objekt sein, für das es einen mit ihm assoziierten G-Ausdruck-Compiler gibt, wie zum Beispiel ein <package>.


Vorige: , Nach oben: Programmierschnittstelle   [Inhalt][Index]

8.11 guix repl aufrufen

Der Befehl guix repl erleichtert es, Guix von Guile aus zu programmieren. Dazu startet er eine Guile-REPL (Read-Eval-Print Loop, kurz REPL, deutsch Lese-Auswerten-Schreiben-Schleife) zur interaktiven Programmierung (siehe Using Guile Interactively in Referenzhandbuch zu GNU Guile) oder er führt Guile-Skripts aus (siehe Running Guile Scripts in Referenzhandbuch zu GNU Guile). Im Vergleich dazu, einfach den Befehl guile aufzurufen, garantiert guix repl, dass alle Guix-Module und deren Abhängigkeiten im Suchpfad verfügbar sind.

Die allgemeine Syntax lautet:

guix repl Optionen [Datei Argumente]

Wird ein Datei-Argument angegeben, wird die angegebene Datei als Guile-Skript ausgeführt.

guix repl my-script.scm

Um Argumente an das Skript zu übergeben, geben Sie davor -- an, damit Sie nicht als Argumente an guix repl verstanden werden:

guix repl -- my-script.scm --input=foo.txt

Wenn Sie möchten, dass ein Skript direkt aus der Shell heraus ausgeführt werden kann und diejenige ausführbare Datei von Guix benutzt wird, die sich im Suchpfad des Benutzers befindet, dann fügen Sie die folgenden zwei Zeilen ganz oben ins Skript ein.

#!/usr/bin/env -S guix repl --
!#

Ohne einen Dateinamen als Argument wird eine Guile-REPL gestartet:

$ guix repl
scheme@(guile-user)> ,use (gnu packages base)
scheme@(guile-user)> coreutils
$1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

guix repl implementiert zusätzlich ein einfaches maschinenlesbares Protokoll für die REPL, das von (guix inferior) benutzt wird, um mit Untergeordneten zu interagieren, also mit getrennten Prozessen einer womöglich anderen Version von Guix.

Folgende Optionen gibt es:

--type=Typ
-t Typ

Startet eine REPL des angegebenen Typs, der einer der Folgenden sein darf:

guile

Die Voreinstellung, mit der eine normale, voll funktionsfähige Guile-REPL gestartet wird.

machine

Startet eine REPL, die ein maschinenlesbares Protokoll benutzt. Dieses Protokoll wird vom Modul (guix inferior) gesprochen.

--listen=Endpunkt

Der Vorgabe nach würde guix repl von der Standardeingabe lesen und auf die Standardausgabe schreiben. Wird diese Befehlszeilenoption angegeben, lauscht die REPL stattdessen auf dem Endpunkt auf Verbindungen. Hier sind Beispiele gültiger Befehlszeilenoptionen:

--listen=tcp:37146

Verbindungen mit dem „localhost“ auf Port 37146 akzeptieren.

--listen=unix:/tmp/socket

Verbindungen zum Unix-Socket /tmp/socket akzeptieren.

--load-path=Verzeichnis
-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für Skript oder REPL sichtbar sind.

-q

Das Laden der ~/.guile-Datei unterdrücken. Nach Voreinstellung würde diese Konfigurationsdatei beim Erzeugen einer REPL für guile geladen.


Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

9 Zubehör

Dieser Abschnitt beschreibt die Befehlszeilenwerkzeuge von Guix. Manche davon richten sich hauptsächlich an Entwickler und solche Nutzer, die neue Paketdefinitionen schreiben, andere sind auch für ein breiteres Publikum nützlich. Sie ergänzen die Scheme-Programmierschnittstelle um bequeme Befehle.


Nächste: , Nach oben: Zubehör   [Inhalt][Index]

9.1 Aufruf von guix build

Der Befehl guix build lässt Pakete oder Ableitungen samt ihrer Abhängigkeiten erstellen und gibt die resultierenden Pfade im Store aus. Beachten Sie, dass das Nutzerprofil dadurch nicht modifiziert wird — eine solche Installation bewirkt der Befehl guix package (siehe Aufruf von guix package). guix build wird also hauptsächlich von Entwicklern der Distribution benutzt.

Die allgemeine Syntax lautet:

guix build Optionen Paket-oder-Ableitung

Zum Beispiel wird mit folgendem Befehl die neueste Version von Emacs und von Guile erstellt, das zugehörige Erstellungsprotokoll angezeigt und letztendlich werden die resultierenden Verzeichnisse ausgegeben:

guix build emacs guile

Folgender Befehl erstellt alle Pakete, die zur Verfügung stehen:

guix build --quiet --keep-going \
  `guix package -A | cut -f1,2 --output-delimiter=@`

Als Paket-oder-Ableitung muss entweder der Name eines in der Software-Distribution zu findenden Pakets, wie etwa coreutils oder coreutils@8.20, oder eine Ableitung wie /gnu/store/…-coreutils-8.19.drv sein. Im ersten Fall wird nach einem Paket mit entsprechendem Namen (und optional der entsprechenden Version) in den Modulen der GNU-Distribution gesucht (siehe Paketmodule).

Alternativ kann die Befehlszeilenoption --expression benutzt werden, um einen Scheme-Ausdruck anzugeben, der zu einem Paket ausgewertet wird; dies ist nützlich, wenn zwischen mehreren gleichnamigen Paketen oder Paket-Varianten unterschieden werden muss.

Null oder mehr Optionen können angegeben werden. Zur Verfügung stehen die in den folgenden Unterabschnitten beschriebenen Befehlszeilenoptionen.


Nächste: , Nach oben: Aufruf von guix build   [Inhalt][Index]

9.1.1 Gemeinsame Erstellungsoptionen

Einige dieser Befehlszeilenoptionen zur Steuerung des Erstellungsprozess haben guix build und andere Befehle, mit denen Erstellungen ausgelöst werden können, wie guix package oder guix archive, gemeinsam. Das sind folgende:

--load-path=Verzeichnis
-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind.

--keep-failed
-K

Den Verzeichnisbaum, in dem fehlgeschlagene Erstellungen durchgeführt wurden, behalten. Wenn also eine Erstellung fehlschlägt, bleibt ihr Erstellungsbaum in /tmp erhalten. Der Name dieses Unterverzeichnisses wird am Ende dem Erstellungsprotokolls ausgegeben. Dies hilft bei der Suche nach Fehlern in Erstellungen. Der Abschnitt Fehlschläge beim Erstellen untersuchen zeigt Ihnen Hinweise und Tricks, wie Erstellungsfehler untersucht werden können.

Diese Option impliziert --no-offload und sie hat keine Auswirkungen, wenn eine Verbindung zu einem entfernten Daemon über eine guix://-URI verwendet wurde (siehe die GUIX_DAEMON_SOCKET-Variable).

--keep-going
-k

Weitermachen, auch wenn ein Teil der Erstellungen fehlschlägt. Das bedeutet, dass der Befehl erst terminiert, wenn alle Erstellungen erfolgreich oder mit Fehler durchgeführt wurden.

Das normale Verhalten ist, abzubrechen, sobald eine der angegebenen Ableitungen fehlschlägt.

--dry-run
-n

Die Ableitungen nicht erstellen.

--fallback

Wenn das Substituieren vorerstellter Binärdateien fehlschlägt, diese ersatzweise lokal selbst erstellen (siehe Fehler bei der Substitution).

--substitute-urls=URLs

Die urls als durch Leerraumzeichen getrennte Liste von Quell-URLs für Substitute anstelle der vorgegebenen URL-Liste für den guix-daemon verwenden (siehe guix-daemon URLs).

Das heißt, die Substitute dürfen von den urls heruntergeladen werden, sofern sie mit einem durch den Systemadministrator autorisierten Schlüssel signiert worden sind (siehe Substitute).

Wenn als urls eine leere Zeichenkette angegeben wurde, verhält es sich, als wären Substitute abgeschaltet.

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

--no-grafts

Pakete nicht „veredeln“ (engl. „graft“). Praktisch heißt das, dass als Veredelungen verfügbare Paketaktualisierungen nicht angewandt werden. Der Abschnitt Sicherheitsaktualisierungen hat weitere Informationen zu Veredelungen.

--rounds=n

Jede Ableitung n-mal nacheinander erstellen und einen Fehler melden, wenn die aufeinanderfolgenden Erstellungsergebnisse nicht Bit für Bit identisch sind.

Das ist eine nützliche Methode, um nicht-deterministische Erstellungsprozesse zu erkennen. Nicht-deterministische Erstellungsprozesse sind ein Problem, weil Nutzer dadurch praktisch nicht verifizieren können, ob von Drittanbietern bereitgestellte Binärdateien unverfälscht sind. Der Abschnitt Aufruf von guix challenge erklärt dies genauer.

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.

--no-offload

Nicht versuchen, an andere Maschinen ausgelagerte Erstellungen zu benutzen (siehe Auslagern des Daemons einrichten). Somit wird lokal erstellt, statt Erstellungen auf entfernte Maschinen auszulagern.

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

Standardmäßig wird die Einstellung für den Daemon benutzt (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.

Standardmäßig wird die Einstellung für den Daemon benutzt (siehe --timeout).

-v Stufe
--verbosity=Stufe

Die angegebene Ausführlichkeitsstufe verwenden. Als Stufe muss eine ganze Zahl angegeben werden. Wird 0 gewählt, wird keine Ausgabe zur Fehlersuche angezeigt, 1 bedeutet eine knappe Ausgabe und 2 lässt alle Erstellungsprotokollausgaben auf die Standardfehlerausgabe schreiben.

--cores=n
-c n

Die Nutzung von bis zu n Prozessorkernen für die Erstellungen gestatten. Der besondere Wert 0 bedeutet, dass so viele wie möglich benutzt werden.

--max-jobs=n
-M n

Höchstens n gleichzeitige Erstellungsaufträge erlauben. Im Abschnitt --max-jobs finden Sie Details zu dieser Option und der äquivalenten Option des guix-daemon.

--debug=Stufe

Ein Protokoll zur Fehlersuche ausgeben, das vom Erstellungsdaemon kommt. Als Stufe muss eine ganze Zahl zwischen 0 und 5 angegeben werden; höhere Zahlen stehen für ausführlichere Ausgaben. Stufe 4 oder höher zu wählen, kann bei der Suche nach Fehlern, wie der Erstellungs-Daemon eingerichtet ist, helfen.

Intern ist guix build im Kern eine Schnittstelle zur Prozedur package-derivation aus dem Modul (guix packages) und zu der Prozedur build-derivations des Moduls (guix derivations).

Neben auf der Befehlszeile übergebenen Optionen beachten guix build und andere guix-Befehle, die Erstellungen durchführen lassen, die Umgebungsvariable GUIX_BUILD_OPTIONS.

Umgebungsvariable: GUIX_BUILD_OPTIONS

Nutzer können diese Variable auf eine Liste von Befehlszeilenoptionen definieren, die automatisch von guix build und anderen guix-Befehlen, die Erstellungen durchführen lassen, benutzt wird, wie in folgendem Beispiel:

$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

Diese Befehlszeilenoptionen werden unabhängig von den auf der Befehlszeile übergebenen Befehlszeilenoptionen grammatikalisch analysiert und das Ergebnis an die bereits analysierten auf der Befehlszeile übergebenen Befehlszeilenoptionen angehängt.


Nächste: , Vorige: , Nach oben: Aufruf von guix build   [Inhalt][Index]

9.1.2 Paketumwandlungsoptionen

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

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

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

--with-source=Quelle
--with-source=Paket=Quelle
--with-source=Paket@Version=Quelle

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

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

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

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

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

Für Entwickler wird es einem durch --with-source leicht gemacht, „Release Candidates“, also Vorabversionen, zu testen:

guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

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

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

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

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

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

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

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

--with-graft=Paket=Ersatz

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

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

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

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

--with-debug-info=Paket

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

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

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

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

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

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

--with-c-toolchain=Paket=Toolchain

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

Betrachten Sie dieses Beispiel:

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

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

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

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

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

--with-git-url=Paket=URL

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

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

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

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

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

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

--with-branch=Paket=Branch

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

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

guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=Paket=Commit

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

--without-tests=Paket

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

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

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

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

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

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


Nächste: , Vorige: , Nach oben: Aufruf von guix build   [Inhalt][Index]

9.1.3 Zusätzliche Erstellungsoptionen

Die unten aufgeführten Befehlszeilenoptionen funktionieren nur mit guix build.

--quiet
-q

Schweigend erstellen, ohne das Erstellungsprotokoll anzuzeigen — dies ist äquivalent zu --verbosity=0. Nach Abschluss der Erstellung ist das Protokoll in /var (oder einem entsprechenden Ort) einsehbar und kann jederzeit mit der Befehlszeilenoption --log-file gefunden werden.

--file=Datei
-f Datei

Das Paket, die Ableitung oder das dateiähnliche Objekt erstellen, zu dem der Code in der Datei ausgewertet wird (siehe dateiartige Objekte).

Zum Beispiel könnte in der Datei so eine Paketdefinition stehen (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+))

Die Datei darf auch eine JSON-Darstellung von einer oder mehreren Paketdefinitionen sein. Wenn wir guix build -f auf einer hello.json-Datei mit dem folgenden Inhalt ausführen würden, würden die Pakete myhello und greeter erstellt werden:

[
  {
    "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"]
  }
]
--manifest=Manifest
-m Manifest

Alle Pakete erstellen, die im angegebenen Manifest stehen (siehe --manifest).

--expression=Ausdruck
-e Ausdruck

Das Paket oder die Ableitung erstellen, zu der der Ausdruck ausgewertet wird.

Zum Beispiel kann der Ausdruck (@ (gnu packages guile) guile-1.8) sein, was diese bestimmte Variante der Version 1.8 von Guile eindeutig bezeichnet.

Alternativ kann der Ausdruck ein G-Ausdruck sein. In diesem Fall wird er als Erstellungsprogramm an gexp->derivation übergeben (siehe G-Ausdrücke).

Zudem kann der Ausdruck eine monadische Prozedur mit null Argumenten bezeichnen (siehe Die Store-Monade). Die Prozedur muss eine Ableitung als monadischen Wert zurückliefern, die dann durch run-with-store laufen gelassen wird.

--source
-S

Die Quellcode-Ableitung der Pakete statt die Pakete selbst erstellen.

Zum Beispiel liefert guix build -S gcc etwas in der Art von /gnu/store/…-gcc-4.7.2.tar.bz2, also den Tarball mit dem GCC-Quellcode.

Der gelieferte Quell-Tarball ist das Ergebnis davon, alle Patches und Code-Schnipsel aufzuspielen, die im origin-Objekt des Pakets festgelegt wurden (siehe Pakete definieren).

Beachten Sie, dass guix build -S nur für die angegebenen Pakete den Quellcode herunterlädt. Dazu gehört nicht der Quellcode statisch gebundener Abhängigkeiten und der Quellcode alleine reicht nicht aus, um die Pakete zu reproduzieren.

--sources

Den Quellcode für Paket-oder-Ableitung und alle Abhängigkeiten davon rekursiv herunterladen und zurückliefern. Dies ist eine praktische Methode, eine lokale Kopie des gesamten Quellcodes zu beziehen, der nötig ist, um die Pakete zu erstellen, damit Sie diese später auch ohne Netzwerkzugang erstellen lassen können. Es handelt sich um eine Erweiterung der Befehlszeilenoption --source, die jeden der folgenden Argumentwerte akzeptiert:

package

Mit diesem Wert verhält sich die Befehlszeilenoption --sources auf genau die gleiche Weise wie die Befehlszeilenoption --source.

all

Erstellt die Quellcode-Ableitungen aller Pakete einschließlich allen Quellcodes, der als Teil der Eingaben im inputs-Feld aufgelistet ist. Dies ist der vorgegebene Wert, wenn sonst keiner angegeben wird.

$ guix build --sources tzdata
Folgende Ableitungen werden erstellt:
   /gnu/store/…-tzdata2015b.tar.gz.drv
   /gnu/store/…-tzcode2015b.tar.gz.drv
transitive

Die Quellcode-Ableitungen aller Pakete sowie aller transitiven Eingaben der Pakete erstellen. Damit kann z.B. Paket-Quellcode vorab heruntergeladen und später offline erstellt werden.

$ guix build --sources=transitive tzdata
Folgende Ableitungen werden erstellt:
   /gnu/store/…-tzcode2015b.tar.gz.drv
   /gnu/store/…-findutils-4.4.2.tar.xz.drv
   /gnu/store/…-grep-2.21.tar.xz.drv
   /gnu/store/…-coreutils-8.23.tar.xz.drv
   /gnu/store/…-make-4.1.tar.xz.drv
   /gnu/store/…-bash-4.3.tar.xz.drv
…
--system=System
-s System

Versuchen, für das angegebene System — z.B. i686-linux — statt für denselben Systemtyp wie auf dem Wirtssystem zu erstellen. Beim Befehl guix build können Sie diese Befehlszeilenoption mehrmals wiederholen, wodurch für jedes angegebene System eine Erstellung durchgeführt wird; andere Befehle ignorieren überzählige -s-Befehlszeilenoptionen.

Anmerkung: Die Befehlszeilenoption --system dient der nativen Kompilierung (nicht zu verwechseln mit Cross-Kompilierung). Siehe --target unten für Informationen zur Cross-Kompilierung.

Ein Beispiel sind Linux-basierte Systeme, die verschiedene Persönlichkeiten emulieren können. Zum Beispiel können Sie --system=i686-linux auf einem x86_64-linux-System oder --system=armhf-linux auf einem aarch64-linux-System angeben, um Pakete in einer vollständigen 32-Bit-Umgebung zu erstellen.

Anmerkung: Das Erstellen für ein armhf-linux-System ist ungeprüft auf allen aarch64-linux-Maschinen aktiviert, obwohl bestimmte aarch64-Chipsätze diese Funktionalität nicht unterstützen, darunter auch ThunderX.

Ebenso können Sie, wenn transparente Emulation mit QEMU und binfmt_misc aktiviert sind (siehe qemu-binfmt-service-type), für jedes System Erstellungen durchführen, für das ein QEMU-binfmt_misc-Handler installiert ist.

Erstellungen für ein anderes System, das nicht dem System der Maschine, die Sie benutzen, entspricht, können auch auf eine entfernte Maschine mit der richtigen Architektur ausgelagert werden. Siehe Auslagern des Daemons einrichten für mehr Informationen über das Auslagern.

--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-Konfigurationstripel in Autoconf).

--check

Paket-oder-Ableitung erneut erstellen, wenn diese bereits im Store verfügbar ist, und einen Fehler melden, wenn die Erstellungsergebnisse nicht Bit für Bit identisch sind.

Mit diesem Mechanismus können Sie überprüfen, ob zuvor installierte Substitute unverfälscht sind (siehe Substitute) oder auch ob das Erstellungsergebnis eines Pakets deterministisch ist. Siehe Aufruf von guix challenge für mehr Hintergrundinformationen und Werkzeuge.

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.

--repair

Versuchen, die angegebenen Store-Objekte zu reparieren, wenn sie beschädigt sind, indem sie neu heruntergeladen oder neu erstellt werden.

Diese Operation ist nicht atomar und nur der Administratornutzer root kann sie verwenden.

--derivations
-d

Liefert die Ableitungspfade und nicht die Ausgabepfade für die angegebenen Pakete.

--root=Datei
-r Datei

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

Dadurch wird das Ergebnis dieses Aufrufs von guix build vor dem Müllsammler geschützt, bis die Datei gelöscht wird. Wird diese Befehlszeilenoption nicht angegeben, können Erstellungsergebnisse vom Müllsammler geholt werden, sobald die Erstellung abgeschlossen ist. Siehe Aufruf von guix gc für mehr Informationen zu Müllsammlerwurzeln.

--log-file

Liefert die Dateinamen oder URLs der Erstellungsprotokolle für das angegebene Paket-oder-Ableitung oder meldet einen Fehler, falls Protokolldateien fehlen.

Dies funktioniert, egal wie die Pakete oder Ableitungen angegeben werden. Zum Beispiel sind folgende Aufrufe alle äquivalent:

guix build --log-file `guix build -d guile`
guix build --log-file `guix build guile`
guix build --log-file guile
guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

Wenn ein Protokoll lokal nicht verfügbar ist und sofern --no-substitutes nicht übergeben wurde, sucht der Befehl nach einem entsprechenden Protokoll auf einem der Substitutserver (die mit --substitute-urls angegeben werden können).

Stellen Sie sich zum Beispiel vor, sie wollten das Erstellungsprotokoll von GDB auf einem MIPS-System sehen, benutzen aber selbst eine x86_64-Maschine:

$ guix build --log-file gdb -s aarch64-linux
https://ci.guix.gnu.org/log/…-gdb-7.10

So haben Sie umsonst Zugriff auf eine riesige Bibliothek von Erstellungsprotokollen!


Vorige: , Nach oben: Aufruf von guix build   [Inhalt][Index]

9.1.4 Fehlschläge beim Erstellen untersuchen

Wenn Sie ein neues Paket definieren (siehe Pakete definieren), werden Sie sich vermutlich einige Zeit mit der Fehlersuche beschäftigen und die Erstellung so lange anpassen, bis sie funktioniert. Dazu müssen Sie die Erstellungsbefehle selbst in einer Umgebung benutzen, die der, die der Erstellungsdaemon aufbaut, so ähnlich wie möglich ist.

Das Erste, was Sie dafür tun müssen, ist die Befehlszeilenoption --keep-failed oder -K von guix build einzusetzen, wodurch Verzeichnisbäume fehlgeschlagener Erstellungen in /tmp oder dem von Ihnen als TMPDIR ausgewiesenen Verzeichnis erhalten und nicht gelöscht werden (siehe --keep-failed).

Im Anschluss können Sie mit cd in die Verzeichnisse dieses fehlgeschlagenen Erstellungsbaums wechseln und mit source dessen environment-variables-Datei laden, die alle Umgebungsvariablendefinitionen enthält, die zum Zeitpunkt des Fehlschlags der Erstellung galten. Sagen wir, Sie suchen Fehler in einem Paket foo, dann würde eine typische Sitzung so aussehen:

$ guix build foo -K
… Erstellung schlägt fehl
$ cd /tmp/guix-build-foo.drv-0
$ source ./environment-variables
$ cd foo-1.2

Nun können Sie Befehle (fast) so aufrufen, als wären Sie der Daemon, und Fehlerursachen in Ihrem Erstellungsprozess ermitteln.

Manchmal passiert es, dass zum Beispiel die Tests eines Pakets erfolgreich sind, wenn Sie sie manuell aufrufen, aber scheitern, wenn der Daemon sie ausführt. Das kann passieren, weil der Daemon Erstellungen in isolierten Umgebungen („Containern“) durchführt, wo, anders als in der obigen Umgebung, kein Netzwerkzugang möglich ist, /bin/sh nicht exisiert usw. (siehe Einrichten der Erstellungsumgebung).

In solchen Fällen müssen Sie den Erstellungsprozess womöglich aus einer zu der des Daemons ähnlichen isolierten Umgebung heraus ausprobieren:

$ guix build -K foo
…
$ cd /tmp/guix-build-foo.drv-0
$ guix environment --no-grafts -C foo --ad-hoc strace gdb
[env]# source ./environment-variables
[env]# cd foo-1.2

Hierbei erzeugt guix environment -C eine isolierte Umgebung und öffnet darin eine Shell (siehe Aufruf von guix environment). Der Teil mit --ad-hoc strace gdb fügt die Befehle strace und gdb zur isolierten Umgebung hinzu, die Sie gut gebrauchen können, während Sie Fehler suchen. Wegen der Befehlszeilenoption --no-grafts bekommen Sie haargenau dieselbe Umgebung ohne veredelte Pakete (siehe Sicherheitsaktualisierungen für mehr Informationen zu Veredelungen).

Um der isolierten Umgebung des Erstellungsdaemons noch näher zu kommen, können wir /bin/sh entfernen:

[env]# rm /bin/sh

(Keine Sorge, das ist harmlos: All dies passiert nur in der zuvor von guix environment erzeugten Wegwerf-Umgebung.)

Der Befehl strace befindet sich wahrscheinlich nicht in Ihrem Suchpfad, aber wir können ihn so benutzen:

[env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

Auf diese Weise haben Sie nicht nur die Umgebungsvariablen, die der Daemon benutzt, nachgebildet, sondern lassen auch den Erstellungsprozess in einer isolierten Umgebung ähnlich der des Daemons laufen.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.2 guix edit aufrufen

So viele Pakete, so viele Quelldateien! Der Befehl guix edit erleichtert das Leben von sowohl Nutzern als auch Paketentwicklern, indem er Ihren Editor anweist, die Quelldatei mit der Definition des jeweiligen Pakets zu bearbeiten. Zum Beispiel startet dies:

guix edit gcc@4.9 vim

das mit der Umgebungsvariablen VISUAL oder EDITOR angegebene Programm und lässt es das Rezept von GCC 4.9.3 und von Vim anzeigen.

Wenn Sie ein Git-Checkout von Guix benutzen (siehe Erstellung aus dem Git) oder Ihre eigenen Pakete im GUIX_PACKAGE_PATH erstellt haben (siehe Paketmodule), werden Sie damit die Paketrezepte auch bearbeiten können. Andernfalls werden Sie zumindest in die Lage versetzt, die nur lesbaren Rezepte für sich im Moment im Store befindliche Pakete zu untersuchen.

Statt GUIX_PACKAGE_PATH zu benutzen, können Sie mit der Befehlszeilenoption --load-path=Verzeichnis (oder kurz -L Verzeichnis) das Verzeichnis vorne an den Paketmodul-Suchpfad anhängen und so Ihre eigenen Pakete sichtbar machen.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.3 guix download aufrufen

Wenn Entwickler einer Paketdefinition selbige schreiben, müssen diese normalerweise einen Quellcode-Tarball herunterladen, seinen SHA256-Hash als Prüfsumme berechnen und diese in der Paketdefinition eintragen (siehe Pakete definieren). Das Werkzeug guix download hilft bei dieser Aufgabe: Damit wird eine Datei von der angegebenen URI heruntergeladen, in den Store eingelagert und sowohl ihr Dateiname im Store als auch ihr SHA256-Hash als Prüfsumme angezeigt.

Dadurch, dass die heruntergeladene Datei in den Store eingefügt wird, wird Bandbreite gespart: Wenn der Entwickler schließlich versucht, das neu definierte Paket mit guix build zu erstellen, muss der Quell-Tarball nicht erneut heruntergeladen werden, weil er sich bereits im Store befindet. Es ist auch eine bequeme Methode, Dateien temporär aufzubewahren, die letztlich irgendwann gelöscht werden (siehe Aufruf von guix gc).

Der Befehl guix download unterstützt dieselben URIs, die in Paketdefinitionen verwendet werden. Insbesondere unterstützt er mirror://-URIs. https-URIs (HTTP über TLS) werden unterstützt, vorausgesetzt die Guile-Anbindungen für GnuTLS sind in der Umgebung des Benutzers verfügbar; wenn nicht, wird ein Fehler gemeldet. Siehe how to install the GnuTLS bindings for Guile in GnuTLS-Guile, hat mehr Informationen.

Mit guix download werden HTTPS-Serverzertifikate verifiziert, indem die Zertifikate der X.509-Autoritäten in das durch die Umgebungsvariable SSL_CERT_DIR bezeichnete Verzeichnis heruntergeladen werden (siehe X.509-Zertifikate), außer --no-check-certificate wird benutzt.

Folgende Befehlszeilenoptionen stehen zur Verfügung:

--hash=Algorithmus
-H Algorithmus

Einen Hash mit dem angegebenen Algorithmus berechnen. Siehe Aufruf von guix hash für weitere Informationen.

--format=Format
-f Format

Die Hash-Prüfsumme im angegebenen Format ausgeben. Für weitere Informationen, was gültige Werte für das Format sind, siehe Aufruf von guix hash.

--no-check-certificate

X.509-Zertifikate von HTTPS-Servern nicht validieren.

Wenn Sie diese Befehlszeilenoption benutzen, haben Sie keinerlei Garantie, dass Sie tatsächlich mit dem authentischen Server, der für die angegebene URL verantwortlich ist, kommunizieren. Das macht Sie anfällig gegen sogenannte „Man-in-the-Middle“-Angriffe.

--output=Datei
-o Datei

Die heruntergeladene Datei nicht in den Store, sondern in die angegebene Datei abspeichern.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.4 guix hash aufrufen

Der Befehl guix hash berechnet den Hash einer Datei. Er ist primär ein Werkzeug, dass es bequemer macht, etwas zur Distribution beizusteuern: Damit wird die kryptografische Hash-Prüfsumme berechnet, die bei der Definition eines Pakets benutzt werden kann (siehe Pakete definieren).

Die allgemeine Syntax lautet:

guix hash Option Datei

Wird als Datei ein Bindestrich - angegeben, berechnet guix hash den Hash der von der Standardeingabe gelesenen Daten. guix hash unterstützt die folgenden Optionen:

--hash=Algorithmus
-H Algorithmus

Mit dem angegebenen Algorithmus einen Hash berechnen. Die Vorgabe ist, sha256 zu benutzen.

Algorithmus muss der Name eines durch Libgcrypt über Guile-Gcrypt zur Verfügung gestellten kryptografischen Hashalgorithmus sein, z.B. sha512 oder sha3-256 (siehe Hash Functions in Referenzhandbuch zu Guile-Gcrypt).

--format=Format
-f Format

Gibt die Prüfsumme im angegebenen Format aus.

Unterstützte Formate: base64, nix-base32, base32, base16 (hex und hexadecimal können auch benutzt werden).

Wird keine Befehlszeilenoption --format angegeben, wird guix hash die Prüfsumme im nix-base32-Format ausgeben. Diese Darstellung wird bei der Definition von Paketen benutzt.

--recursive
-r

Die Prüfsumme der Datei rekursiv berechnen.

In diesem Fall wird die Prüfsumme eines Archivs berechnet, das die Datei enthält, und auch ihre Kinder, wenn es sich um ein Verzeichnis handelt. Einige der Metadaten der Datei sind Teil dieses Archivs. Zum Beispiel unterscheidet sich die berechnete Prüfsumme, wenn die Datei eine reguläre Datei ist, je nachdem, ob die Datei ausführbar ist oder nicht. Metadaten wie der Zeitstempel haben keinen Einfluss auf die Prüfsumme (siehe Aufruf von guix archive).

--exclude-vcs
-x

Wenn dies zusammen mit der Befehlszeilenoption --recursive angegeben wird, werden Verzeichnisse zur Versionskontrolle (.bzr, .git, .hg, etc.) vom Archiv ausgenommen.

Zum Beispiel würden Sie auf diese Art die Prüfsumme eines Git-Checkouts berechnen, was nützlich ist, wenn Sie die Prüfsumme für die Methode git-fetch benutzen (siehe „origin“-Referenz):

$ git clone http://example.org/foo.git
$ cd foo
$ guix hash -rx .

Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.5 guix import aufrufen

Der Befehl guix import ist für Leute hilfreich, die ein Paket gerne mit so wenig Arbeit wie möglich zur Distribution hinzufügen würden — ein legitimer Anspruch. Der Befehl kennt ein paar Sammlungen, aus denen mit ihm Paketmetadaten „importiert“ werden können. Das Ergebnis ist eine Paketdefinition oder eine Vorlage dafür in dem uns bekannten Format (siehe Pakete definieren).

Die allgemeine Syntax lautet:

guix import Importer Optionen

Der Importer gibt die Quelle an, aus der Paketmetadaten importiert werden, und die Optionen geben eine Paketbezeichnung und andere vom Importer abhängige Daten an.

Manche Importer setzen voraus, dass der Befehl gpgv ausgeführt werden kann. Sie funktionieren nur, wenn GnuPG installiert und im $PATH enthalten ist; falls nötig können Sie guix install gnupg ausführen.

Derzeit sind folgende „Importer“ verfügbar:

gnu

Metadaten für das angegebene GNU-Paket importieren. Damit wird eine Vorlage für die neueste Version dieses GNU-Pakets zur Verfügung gestellt, einschließlich der Prüfsumme seines Quellcode-Tarballs, seiner kanonischen Zusammenfassung und seiner Beschreibung.

Zusätzliche Informationen wie Paketabhängigkeiten und seine Lizenz müssen noch manuell ermittelt werden.

Zum Beispiel liefert der folgende Befehl eine Paketdefinition für GNU Hello:

guix import gnu hello

Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung:

--key-download=Richtlinie

Die Richtlinie zum Umgang mit fehlenden OpenPGP-Schlüsseln beim Verifizieren der Paketsignatur (auch „Beglaubigung“ genannt) festlegen, wie bei guix refresh. Siehe --key-download.

pypi

Metadaten aus dem Python Package Index importieren. Informationen stammen aus der JSON-formatierten Beschreibung, die unter pypi.python.org verfügbar ist, und enthalten meistens alle relevanten Informationen einschließlich der Abhängigkeiten des Pakets. Für maximale Effizienz wird empfohlen, das Hilfsprogramm unzip zu installieren, damit der Importer „Python Wheels“ entpacken und daraus Daten beziehen kann.

Der folgende Befehl importiert Metadaten für das Python-Paket namens itsdangerous:

guix import pypi itsdangerous
--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

gem

Metadaten von RubyGems importieren. Informationen kommen aus der JSON-formatierten Beschreibung, die auf rubygems.org verfügbar ist, und enthält die relevantesten Informationen einschließlich der Laufzeitabhängigkeiten. Dies hat aber auch Schattenseiten — die Metadaten unterscheiden nicht zwischen Zusammenfassungen und Beschreibungen, daher wird dieselbe Zeichenkette für beides eingesetzt. Zudem fehlen Informationen zu nicht in Ruby geschriebenen Abhängigkeiten, die benötigt werden, um native Erweiterungen zu in Ruby geschriebenem Code zu erstellen. Diese herauszufinden bleibt dem Paketentwickler überlassen.

Der folgende Befehl importiert Metadaten aus dem Ruby-Paket rails.

guix import gem rails
--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

cpan

Importiert Metadaten von MetaCPAN. Informationen werden aus den JSON-formatierten Metadaten genommen, die über die Programmierschnittstelle („API“) von MetaCPAN angeboten werden, und enthalten die relevantesten Informationen wie zum Beispiel Modulabhängigkeiten. Lizenzinformationen sollten genau nachgeprüft werden. Wenn Perl im Store verfügbar ist, wird das Werkzeug corelist benutzt, um Kernmodule in der Abhängigkeitsliste wegzulassen.

Folgender Befehl importiert Metadaten für das Perl-Modul Acme::Boolean:

guix import cpan Acme::Boolean
cran

Metadaten aus dem CRAN importieren, der zentralen Sammlung für die statistische und grafische Umgebung GNU R.

Informationen werden aus der Datei namens DESCRIPTION des Pakets extrahiert.

Der folgende Befehl importiert Metadaten für das Cairo-R-Paket:

guix import cran Cairo

Wird zudem --recursive angegeben, wird der Importer den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für all die Pakete erzeugen, die noch nicht Teil von Guix sind.

Wird --archive=bioconductor angegeben, werden Metadaten vom Bioconductor importiert, einer Sammlung von R-Paketen zur Analyse und zum Verständnis von großen Mengen genetischer Daten in der Bioinformatik.

Informationen werden aus der Datei namens DESCRIPTION im Archiv des Pakets extrahiert.

Der folgende Befehl importiert Metadaten für das R-Paket GenomicRanges:

guix import cran --archive=bioconductor GenomicRanges

Schließlich können Sie auch solche R-Pakete importieren, die noch nicht auf CRAN oder im Bioconductor veröffentlicht wurden, solange sie in einem Git-Repository stehen. Benutzen Sie --archive=git gefolgt von der URL des Git-Repositorys.

guix import cran --archive=git https://github.com/immunogenomics/harmony
texlive

Metadaten aus CTAN, dem umfassenden TeX-Archivnetzwerk, herunterladen, was für TeX-Pakete benutzt wird, die Teil der TeX-Live-Distribution sind.

Informationen über das Paket werden über die von CTAN angebotene XML-Programmierschnittstelle bezogen, wohingegen der Quellcode aus dem SVN-Repository des TeX-Live-Projekts heruntergeladen wird. Das wird so gemacht, weil CTAN keine versionierten Archive vorhält.

Der folgende Befehl importiert Metadaten für das TeX-Paket fontspec:

guix import texlive fontspec

Wenn --archive=Verzeichnis angegeben wird, wird der Quellcode nicht aus dem Unterverzeichnis latex des texmf-dist/source-Baums im SVN-Repository von TeX Live heruntergeladen, sondern aus dem angegebenen Schwester-Verzeichnis im selben Wurzelverzeichnis.

Der folgende Befehl importiert Metadaten für das Paket ifxetex aus CTAN und lädt die Quelldateien aus dem Verzeichnis texmf/source/generic:

guix import texlive --archive=generic ifxetex
json

Paketmetadaten aus einer lokalen JSON-Datei importieren. Betrachten Sie folgende Beispiel-Paketdefinition im JSON-Format:

{
  "name": "hello",
  "version": "2.10",
  "source": "mirror://gnu/hello/hello-2.10.tar.gz",
  "build-system": "gnu",
  "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"]
}

Die Felder sind genauso benannt wie bei einem <package>-Verbundstyp (siehe Pakete definieren). Referenzen zu anderen Paketen stehen darin als JSON-Liste von mit Anführungszeichen quotierten Zeichenketten wie guile oder guile@2.0.

Der Importer unterstützt auch eine ausdrücklichere Definition der Quelldateien mit den üblichen Feldern eines <origin>-Verbunds:

{
  …
  "source": {
    "method": "url-fetch",
    "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
    "sha256": {
      "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
    }
  }
  …
}

Der folgende Befehl liest Metadaten aus der JSON-Datei hello.json und gibt einen Paketausdruck aus:

guix import json hello.json
nix

Metadaten aus einer lokalen Kopie des Quellcodes der Nixpkgs-Distribution importieren20. Paketdefinitionen in Nixpkgs werden typischerweise in einer Mischung aus der Sprache von Nix und aus Bash-Code geschrieben. Dieser Befehl wird nur die abstrakte Paketstruktur, die in der Nix-Sprache geschrieben ist, importieren. Dazu gehören normalerweise alle grundlegenden Felder einer Paketdefinition.

Beim Importieren eines GNU-Pakets werden Zusammenfassung und Beschreibung stattdessen durch deren kanonische Variante bei GNU ersetzt.

Normalerweise würden Sie zunächst dies ausführen:

export NIX_REMOTE=daemon

damit nix-instantiate nicht versucht, die Nix-Datenbank zu öffnen.

Zum Beispiel importiert der Befehl unten die Paketdefinition von LibreOffice (genauer gesagt importiert er die Definition des an das Attribut libreoffice auf oberster Ebene gebundenen Pakets):

guix import nix ~/path/to/nixpkgs libreoffice
hackage

Metadaten aus Hackage, dem zentralen Paketarchiv der Haskell-Gemeinde, importieren. Informationen werden aus Cabal-Dateien ausgelesen. Darin sind alle relevanten Informationen einschließlich der Paketabhängigkeiten enthalten.

Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung:

--stdin
-s

Eine Cabal-Datei von der Standardeingabe lesen.

--no-test-dependencies
-t

Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden.

--cabal-environment=Aliste
-e Aliste

Aliste muss eine assoziative Liste der Scheme-Programmiersprache sein, die die Umgebung definiert, in der bedingte Ausdrücke von Cabal ausgewertet werden. Dabei werden folgende Schlüssel akzeptiert: os, arch, impl und eine Zeichenkette, die dem Namen einer Option (einer „Flag“) entspricht. Der mit einer „Flag“ assoziierte Wert muss entweder das Symbol true oder false sein. Der anderen Schlüsseln zugeordnete Wert muss mit der Definition des Cabal-Dateiformats konform sein. Der vorgegebene Wert zu den Schlüsseln os, arch and impl ist jeweils ‘linux’, ‘x86_64’ bzw. ‘ghc’.

--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

Der folgende Befehl importiert Metadaten für die neuste Version des Haskell-„HTTP“-Pakets, ohne Testabhängigkeiten zu übernehmen und bei Übergabe von false als Wert der Flag ‘network-uri’:

guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

Eine ganz bestimmte Paketversion kann optional ausgewählt werden, indem man nach dem Paketnamen anschließend ein At-Zeichen und eine Versionsnummer angibt wie in folgendem Beispiel:

guix import hackage mtl@2.1.3.1
stackage

Der stackage-Importer ist ein Wrapper um den hackage-Importer. Er nimmt einen Paketnamen und schaut dafür die Paketversion nach, die Teil einer Stackage-Veröffentlichung mit Langzeitunterstützung (englisch „Long-Term Support“, kurz LTS) ist, deren Metadaten er dann mit dem hackage-Importer bezieht. Beachten Sie, dass es Ihre Aufgabe ist, eine LTS-Veröffentlichung auszuwählen, die mit dem von Guix benutzten GHC-Compiler kompatibel ist.

Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung:

--no-test-dependencies
-t

Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden.

--lts-version=Version
-l Version

Version ist die gewünschte Version der LTS-Veröffentlichung. Wird keine angegeben, wird die neueste benutzt.

--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

Der folgende Befehl importiert Metadaten für dasjenige Haskell-„HTTP“-Paket, das in der LTS-Stackage-Veröffentlichung mit Version 7.18 vorkommt:

guix import stackage --lts-version=7.18 HTTP
elpa

Metadaten aus der Paketsammlung „Emacs Lisp Package Archive“ (ELPA) importieren (siehe Packages in The GNU Emacs Manual).

Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung:

--archive=Repo
-a Repo

Mit Repo wird die Archiv-Sammlung (ein „Repository“) bezeichnet, von dem die Informationen bezogen werden sollen. Derzeit sind die unterstützten Repositorys und ihre Bezeichnungen folgende:

  • - GNU, bezeichnet mit gnu. Dies ist die Vorgabe.

    Pakete aus elpa.gnu.org wurden mit einem der Schlüssel im GnuPG-Schlüsselbund in share/emacs/25.1/etc/package-keyring.gpg (oder einem ähnlichen Pfad) des emacs-Pakets signiert (siehe ELPA-Paketsignaturen in The GNU Emacs Manual).

  • - MELPA-Stable, bezeichnet mit melpa-stable.
  • - MELPA, bezeichnet mit melpa.
--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

crate

Metadaten aus der Paketsammlung crates.io für Rust importieren crates.io, wie Sie in diesem Beispiel sehen:

guix import crate blake2-rfc

Mit dem Crate-Importer können Sie auch eine Version als Zeichenkette angeben:

guix import crate constant-time-eq@0.1.0

Zu den zusätzlichen Optionen gehören:

--recursive
-r

Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt.

opam

Metadaten aus der Paketsammlung OPAM der OCaml-Gemeinde importieren.

guix import verfügt über eine modulare Code-Struktur. Mehr Importer für andere Paketformate zu haben, wäre nützlich, und Ihre Hilfe ist hierbei gerne gesehen (siehe Mitwirken).


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.6 guix refresh aufrufen

Die Zielgruppe des Befehls guix refresh zum Auffrischen von Paketen sind in erster Linie Entwickler der GNU-Software-Distribution. Nach Vorgabe werden damit alle Pakete in der Distribution gemeldet, die nicht der neuesten Version des Anbieters entsprechen, indem Sie dies ausführen:

$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

Alternativ können die zu betrachtenden Pakete dabei angegeben werden, was zur Ausgabe einer Warnung führt, wenn es für Pakete kein Aktualisierungsprogramm gibt:

$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

guix refresh durchsucht die Paketsammlung beim Anbieter jedes Pakets und bestimmt, was die höchste Versionsnummer ist, zu der es dort eine Veröffentlichung gibt. Zum Befehl gehören Aktualisierungsprogramme, mit denen bestimmte Typen von Paketen automatisch aktualisiert werden können: GNU-Pakete, ELPA-Pakete usw. — siehe die Dokumentation von --type unten. Es gibt jedoch auch viele Pakete, für die noch keine Methode enthalten ist, um das Vorhandensein einer neuen Veröffentlichung zu prüfen. Der Mechanismus ist aber erweiterbar, also können Sie gerne mit uns in Kontakt treten, wenn Sie eine neue Methode hinzufügen möchten!

--recursive

Hiermit werden die angegebenen Pakete betrachtet und außerdem alle Pakete, von denen sie abhängen.

$ guix refresh --recursive coreutils
gnu/packages/acl.scm:35:2: warning: no updater for acl
gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4
gnu/packages/xml.scm:68:2: warning: no updater for expat
gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp
…

Manchmal unterscheidet sich der vom Anbieter benutzte Name von dem Paketnamen, der in Guix verwendet wird, so dass guix refresh etwas Unterstützung braucht. Die meisten Aktualisierungsprogramme folgen der Eigenschaft upstream-name in Paketdefinitionen, die diese Unterstützung bieten kann.

(define-public network-manager
  (package
    (name "network-manager")
    ;; …
    (properties '((upstream-name . "NetworkManager")))))

Wenn --update übergeben wird, werden die Quelldateien der Distribution verändert, so dass für diese Paketrezepte die aktuelle Version und die aktuelle Hash-Prüfsumme des Quellcode-Tarballs eingetragen wird (siehe Pakete definieren). Dazu werden der neueste Quellcode-Tarball jedes Pakets sowie die jeweils zugehörige OpenPGP-Signatur heruntergeladen; mit Letzterer wird der heruntergeladene Tarball gegen seine Signatur mit gpgv authentifiziert und schließlich dessen Hash berechnet. Beachten Sie, dass GnuPG dazu installiert sein und in $PATH vorkommen muss. Falls dies nicht der Fall ist, führen Sie guix install gnupg aus.

Wenn der öffentliche Schlüssel, mit dem der Tarball signiert wurde, im Schlüsselbund des Benutzers fehlt, wird versucht, ihn automatisch von einem Schlüssel-Server zu holen. Wenn das klappt, wird der Schlüssel zum Schlüsselbund des Benutzers hinzugefügt, ansonsten meldet guix refresh einen Fehler.

Die folgenden Befehlszeilenoptionen werden unterstützt:

--expression=Ausdruck
-e Ausdruck

Als Paket benutzen, wozu der Ausdruck ausgewertet wird.

Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in diesem Beispiel:

guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

Dieser Befehls listet auf, was alles von der „endgültigen“ Erstellung von libc abhängt (praktisch alle Pakete).

--update
-u

Die Quelldateien der Distribution (die Paketrezepte) werden direkt „in place“ verändert. Normalerweise führen Sie dies aus einem Checkout des Guix-Quellbaums heraus aus (siehe Guix vor der Installation ausführen):

$ ./pre-inst-env guix refresh -s non-core -u

Siehe Pakete definieren für mehr Informationen zu Paketdefinitionen.

--select=[Teilmenge]
-s Teilmenge

Wählt alle Pakete aus der Teilmenge aus, die entweder core oder non-core sein muss.

Die core-Teilmenge bezieht sich auf alle Pakete, die den Kern der Distribution ausmachen, d.h. Pakete, aus denen heraus „alles andere“ erstellt wird. Dazu gehören GCC, libc, Binutils, Bash und so weiter. In der Regel ist die Folge einer Änderung an einem dieser Pakete in der Distribution, dass alle anderen neu erstellt werden müssen. Daher sind solche Änderungen unangenehm für Nutzer, weil sie einiges an Erstellungszeit oder Bandbreite investieren müssen, um die Aktualisierung abzuschließen.

Die non-core-Teilmenge bezieht sich auf die übrigen Pakete. Sie wird typischerweise dann benutzt, wenn eine Aktualisierung der Kernpakete zu viele Umstände machen würde.

--manifest=Datei
-m Datei

Wählt alle Pakete im in der Datei stehenden Manifest aus. Das ist nützlich, um zu überprüfen, welche Pakete aus dem Manifest des Nutzers aktualisiert werden können.

--type=Aktualisierungsprogramm
-t Aktualisierungsprogramm

Nur solche Pakete auswählen, die vom angegebenen Aktualisierungsprogramm behandelt werden. Es darf auch eine kommagetrennte Liste mehrerer Aktualisierungsprogramme angegeben werden. Zurzeit kann als Aktualisierungsprogramm eines der folgenden angegeben werden:

gnu

Aktualisierungsprogramm für GNU-Pakete,

savannah

Aktualisierungsprogramm auf Savannah angebotener Pakete,

gnome

Aktualisierungsprogramm für GNOME-Pakete,

kde

Aktualisierungsprogramm für KDE-Pakete,

xorg

Aktualisierungsprogramm für X.org-Pakete,

kernel.org

Aktualisierungsprogramm auf kernel.org angebotener Pakete,

elpa

Aktualisierungsprogramm für ELPA-Pakete,

cran

Aktualisierungsprogramm für CRAN-Pakete,

bioconductor

Aktualisierungsprogramm für R-Pakete vom Bioconductor,

cpan

Aktualisierungsprogramm für CPAN-Pakete,

pypi

Aktualisierungsprogramm für PyPI-Pakete,

gem

Aktualisierungsprogramm für RubyGems-Pakete.

github

Aktualisierungsprogramm für GitHub-Pakete.

hackage

Aktualisierungsprogramm für Hackage-Pakete.

stackage

Aktualisierungsprogramm für Stackage-Pakete.

crate

Aktualisierungsprogramm für Crates-Pakete.

launchpad

Aktualisierungsprogramm für Launchpad.

Zum Beispiel prüft folgender Befehl nur auf mögliche Aktualisierungen von auf elpa.gnu.org angebotenen Emacs-Paketen und von CRAN-Paketen:

$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9

An guix refresh können auch ein oder mehrere Paketnamen übergeben werden wie in diesem Beispiel:

$ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8

Der Befehl oben aktualisiert speziell das emacs- und das idutils-Paket. Eine Befehlszeilenoption --select hätte dann keine Wirkung.

Wenn Sie sich fragen, ob ein Paket aktualisiert werden sollte oder nicht, kann es helfen, sich anzuschauen, welche Pakete von der Aktualisierung betroffen wären und auf Kompatibilität hin geprüft werden sollten. Dazu kann die folgende Befehlszeilenoption zusammen mit einem oder mehreren Paketnamen an guix refresh übergeben werden:

--list-updaters
-L

Eine Liste verfügbarer Aktualisierungsprogramme anzeigen und terminieren (siehe --type oben).

Für jedes Aktualisierungsprogramm den Anteil der davon betroffenen Pakete anzeigen; zum Schluss wird der Gesamtanteil von irgendeinem Aktualisierungsprogramm betroffener Pakete angezeigt.

--list-dependent
-l

Auflisten, welche abhängigen Pakete auf oberster Ebene neu erstellt werden müssten, wenn eines oder mehrere Pakete aktualisiert würden.

Siehe den reverse-package-Typ von guix graph für Informationen dazu, wie Sie die Liste der Abhängigen eines Pakets visualisieren können.

Bedenken Sie, dass die Befehlszeilenoption --list-dependent das Ausmaß der nach einer Aktualisierungen benötigten Neuerstellungen nur annähert. Es könnten auch unter Umständen mehr Neuerstellungen anfallen.

$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop@2.4.0 geiser@0.4 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 …

Der oben stehende Befehl gibt einen Satz von Paketen aus, die Sie erstellen wollen könnten, um die Kompatibilität einer Aktualisierung des flex-Pakets beurteilen zu können.

--list-transitive

Die Pakete auflisten, von denen eines oder mehrere Pakete abhängen.

$ guix refresh --list-transitive flex
flex@2.6.4 depends on the following 25 packages: perl@5.28.0 help2man@1.47.6
bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 …

Der oben stehende Befehl gibt einen Satz von Paketen aus, die, wenn sie geändert würden, eine Neuerstellung des flex-Pakets auslösen würden.

Mit den folgenden Befehlszeilenoptionen können Sie das Verhalten von GnuPG anpassen:

--gpg=Befehl

Den Befehl als GnuPG-2.x-Befehl einsetzen. Der Befehl wird im $PATH gesucht.

--keyring=Datei

Die Datei als Schlüsselbund mit Anbieterschlüsseln verwenden. Die Datei muss im Keybox-Format vorliegen. Keybox-Dateien haben normalerweise einen Namen, der auf .kbx endet. Sie können mit Hilfe von GNU Privacy Guard (GPG) bearbeitet werden (siehe kbxutil in Using the GNU Privacy Guard für Informationen über ein Werkzeug zum Bearbeiten von Keybox-Dateien).

Wenn diese Befehlszeilenoption nicht angegeben wird, benutzt guix refresh die Keybox-Datei ~/.config/guix/upstream/trustedkeys.kbx als Schlüsselbund für Signierschlüssel von Anbietern. OpenPGP-Signaturen werden mit Schlüsseln aus diesem Schlüsselbund überprüft; fehlende Schlüssel werden auch in diesen Schlüsselbund heruntergeladen (siehe --key-download unten).

Sie können Schlüssel aus Ihrem normalerweise benutzten GPG-Schlüsselbund in eine Keybox-Datei exportieren, indem Sie Befehle wie diesen benutzen:

gpg --export rms@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx

Ebenso können Sie wie folgt Schlüssel in eine bestimmte Keybox-Datei herunterladen:

gpg --no-default-keyring --keyring mykeyring.kbx \
  --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

Siehe --keyring in Using the GNU Privacy Guard für mehr Informationen zur Befehlszeilenoption --keyring von GPG.

--key-download=Richtlinie

Fehlende OpenPGP-Schlüssel gemäß dieser Richtlinie behandeln, für die eine der Folgenden angegeben werden kann:

always

Immer fehlende OpenPGP-Schlüssel herunterladen und zum GnuPG-Schlüsselbund des Nutzers hinzufügen.

never

Niemals fehlende OpenPGP-Schlüssel herunterladen, sondern einfach abbrechen.

interactive

Ist ein Paket mit einem unbekannten OpenPGP-Schlüssel signiert, wird der Nutzer gefragt, ob der Schlüssel heruntergeladen werden soll oder nicht. Dies entspricht dem vorgegebenen Verhalten.

--key-server=Host

Den mit Host bezeichneten Rechner als Schlüsselserver für OpenPGP benutzen, wenn ein öffentlicher Schlüssel importiert wird.

--load-path=Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind.

Das github-Aktualisierungsprogramm benutzt die GitHub-Programmierschnittstelle (die „Github-API“), um Informationen über neue Veröffentlichungen einzuholen. Geschieht dies oft, z.B. beim Auffrischen aller Pakete, so wird GitHub irgendwann aufhören, weitere API-Anfragen zu beantworten. Normalerweise sind 60 API-Anfragen pro Stunde erlaubt, für eine vollständige Auffrischung aller GitHub-Pakete in Guix werden aber mehr benötigt. Wenn Sie sich bei GitHub mit Ihrem eigenen API-Token authentisieren, gelten weniger einschränkende Grenzwerte. Um einen API-Token zu benutzen, setzen Sie die Umgebungsvariable GUIX_GITHUB_TOKEN auf einen von https://github.com/settings/tokens oder anderweitig bezogenen API-Token.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.7 guix lint aufrufen

Den Befehl guix lint gibt es, um Paketentwicklern beim Vermeiden häufiger Fehler und bei der Einhaltung eines konsistenten Code-Stils zu helfen. Er führt eine Reihe von Prüfungen auf einer angegebenen Menge von Paketen durch, um in deren Definition häufige Fehler aufzuspüren. Zu den verfügbaren Prüfern gehören (siehe --list-checkers für eine vollständige Liste):

synopsis
description

Überprüfen, ob bestimmte typografische und stilistische Regeln in Paketbeschreibungen und -zusammenfassungen eingehalten wurden.

inputs-should-be-native

Eingaben identifizieren, die wahrscheinlich native Eingaben sein sollten.

source
home-page
mirror-url
github-url
source-file-name

Die URLs für die Felder home-page und source anrufen und nicht erreichbare URLs melden. Wenn passend, wird eine mirror://-URL vorgeschlagen. Wenn die Quell-URL auf eine GitHub-URL weiterleitet, wird eine Empfehlung ausgegeben, direkt letztere zu verwenden. Es wird geprüft, dass der Quell-Dateiname aussagekräftig ist, dass er also z.B. nicht nur aus einer Versionsnummer besteht oder als „git-checkout“ angegeben wurde, ohne dass ein Dateiname deklariert wurde (siehe „origin“-Referenz).

source-unstable-tarball

Analysiert die source-URL, um zu bestimmen, ob der Tarball von GitHub automatisch generiert wurde oder zu einer Veröffentlichung gehört. Leider werden GitHubs automatisch generierte Tarballs manchmal neu generiert.

Ableitung

Prüft, ob die Ableitung der angegebenen Pakete auf allen unterstützten Systmen erfolgreich berechnet werden kann (siehe Ableitungen).

profile-collisions

Prüft, ob die Installation der angegebenen Pakete in ein Profil zu Kollisionen führen würde. Kollisionen treten auf, wenn mehrere Pakete mit demselben Namen aber anderer Versionsnummer oder anderem Store-Dateinamen propagiert werden. Siehe propagated-inputs für weitere Informationen zu propagierten Eingaben.

archival

Überprüft, ob der Quellcode des Pakets bei der Software Heritage archiviert ist.

Wenn der noch nicht archivierte Quellcode aus einem Versionskontrollsystem („Version Control System“, VCS) stammt, wenn er also z.B. mit git-fetch bezogen wird, wird eine Anfrage an Software Heritage gestellt, diesen zu speichern („Save“), damit sie ihn irgendwann in deren Archiv aufnehmen. So wird gewährleistet, dass der Quellcode langfristig verfügbar bleibt und Guix notfalls auf Software Heritage zurückgreifen kann, falls der Quellcode bei seinem ursprünglichen Anbieter verschwindet. Der Status kürzlicher Archivierungsanfragen kann online eingesehen werden.

Wenn der Quellcode in Form eines über url-fetch zu beziehenden Tarballs vorliegt, wird bloß eine Nachricht ausgegeben, wenn er nicht archiviert ist. Zum Zeitpunkt, wo dies geschrieben wurde, ermöglicht Software Heritage keine Anfragen, beliebige Tarballs zu archivieren; wir arbeiten an Möglichkeiten wie auch nicht versionskontrollierter Quellcode archiviert werden kann.

Software Heritage beschränkt, wie schnell dieselbe IP-Adresse Anfragen stellen kann. Ist das Limit erreicht, gibt guix lint eine Mitteilung aus und der archival-Prüfer steht so lange still, bis die Beschränkung wieder zurückgesetzt wurde.

cve

Bekannte Sicherheitslücken melden, die in den Datenbanken der „Common Vulnerabilities and Exposures“ (CVE) aus diesem und dem letzten Jahr vorkommen, wie sie von der US-amerikanischen NIST veröffentlicht werden.

Um Informationen über eine bestimmte Sicherheitslücke angezeigt zu bekommen, besuchen Sie Webseiten wie:

wobei Sie statt CVE-YYYY-ABCD die CVE-Kennnummer angeben — z.B. CVE-2015-7554.

Paketentwickler können in ihren Paketrezepten den Namen und die Version des Pakets in der Common Platform Enumeration (CPE) angeben, falls sich diese von dem in Guix benutzten Namen und der Version unterscheiden, zum Beispiel so:

(package
  (name "grub")
  ;; …
  ;; CPE bezeichnet das Paket als "grub2".
  (properties '((cpe-name . "grub2")
                (cpe-version . "2.3"))))

Manche Einträge in der CVE-Datenbank geben die Version des Pakets nicht an, auf das sie sich beziehen, und würden daher bis in alle Ewigkeit Warnungen auslösen. Paketentwickler, die CVE-Warnmeldungen gefunden und geprüft haben, dass diese ignoriert werden können, können sie wie in diesem Beispiel deklarieren:

(package
  (name "t1lib")
  ;; …
  ;; Diese CVEs treffen nicht mehr zu und können bedenkenlos ignoriert
  ;; werden.
  (properties `((lint-hidden-cve . ("CVE-2011-0433"
                                    "CVE-2011-1553"
                                    "CVE-2011-1554"
                                    "CVE-2011-5244")))))
Formatierung

Offensichtliche Fehler bei der Formatierung von Quellcode melden, z.B. Leerraum-Zeichen am Zeilenende oder Nutzung von Tabulatorzeichen.

Die allgemeine Syntax lautet:

guix lint Optionen Pakete

Wird kein Paket auf der Befehlszeile angegeben, dann werden alle Pakete geprüft, die es gibt. Als Optionen können null oder mehr der folgenden Befehlszeilenoptionen übergeben werden:

--list-checkers
-l

Alle verfügbaren Prüfer für die Pakete auflisten und beschreiben.

--checkers
-c

Nur die Prüfer aktivieren, die hiernach in einer kommagetrennten Liste aus von --list-checkers aufgeführten Prüfern vorkommen.

--exclude
-x

Nur die Prüfer deaktivieren, die hiernach in einer kommagetrennten Liste aus von --list-checkers aufgeführten Prüfern vorkommen.

--no-network
-n

Nur die Prüfer aktivieren, die keinen Internetzugang benötigen.

--load-path=Verzeichnis
-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.8 guix size aufrufen

Der Befehl guix size hilft Paketentwicklern dabei, den Plattenplatzverbrauch von Paketen zu profilieren. Es ist leicht, die Auswirkungen zu unterschätzen, die das Hinzufügen zusätzlicher Abhängigkeiten zu einem Paket hat oder die das Verwenden einer einzelnen Ausgabe für ein leicht aufteilbares Paket ausmacht (siehe Pakete mit mehreren Ausgaben.). Das sind typische Probleme, auf die guix size aufmerksam machen kann.

Dem Befehl können eine oder mehrere Paketspezifikationen wie gcc@4.8 oder guile:debug übergeben werden, oder ein Dateiname im Store. Betrachten Sie dieses Beispiel:

$ guix size coreutils
Store-Objekt                            Gesamt   Selbst
/gnu/store/…-gcc-5.5.0-lib           60.4    30.1  38.1%
/gnu/store/…-glibc-2.27              30.3    28.8  36.6%
/gnu/store/…-coreutils-8.28          78.9    15.0  19.0%
/gnu/store/…-gmp-6.1.2               63.1     2.7   3.4%
/gnu/store/…-bash-static-4.4.12       1.5     1.5   1.9%
/gnu/store/…-acl-2.2.52              61.1     0.4   0.5%
/gnu/store/…-attr-2.4.47             60.6     0.2   0.3%
/gnu/store/…-libcap-2.25             60.5     0.2   0.2%
Gesamt: 78.9 MiB

Die hier aufgelisteten Store-Objekte bilden den transitiven Abschluss der Coreutils — d.h. die Coreutils und all ihre Abhängigkeiten und deren Abhängigkeiten, rekursiv —, wie sie hiervon angezeigt würden:<f

$ guix gc -R /gnu/store/…-coreutils-8.23

Hier zeigt die Ausgabe neben den Store-Objekten noch drei Spalten. Die erste Spalte namens „Gesamt“ gibt wieder, wie viele Mebibytes (MiB) der Abschluss des Store-Objekts groß ist — das heißt, dessen eigene Größe plus die Größe all seiner Abhängigkeiten. Die nächste Spalte, bezeichnet mit „Selbst“, zeigt die Größe nur dieses Objekts an. Die letzte Spalte zeigt das Verhältnis der Größe des Objekts zur Gesamtgröße aller hier aufgelisteten Objekte an.

In diesem Beispiel sehen wir, dass der Abschluss der Coreutils 79 MiB schwer ist, wovon das meiste durch libc und die Bibliotheken zur Laufzeitunterstützung von GCC ausgemacht wird. (Dass libc und die Bibliotheken vom GCC einen großen Anteil am Abschluss ausmachen, ist aber an sich noch kein Problem, weil es Bibliotheken sind, die auf dem System sowieso immer verfügbar sein müssen.)

Weil der Befehl auch Namen von Store-Dateien akzeptiert, kann man damit auch die Größe eines Erstellungsergebnisses ermitteln:

guix size $(guix system build config.scm)

Wenn das oder die Paket(e), die an guix size übergeben wurden, im Store verfügbar sind21, beauftragen Sie mit guix size den Daemon, die Abhängigkeiten davon zu bestimmen und deren Größe im Store zu messen, ähnlich wie es mit du -ms --apparent-size geschehen würde (siehe du invocation in GNU Coreutils).

Wenn die übergebenen Pakete nicht im Store liegen, erstattet guix size Bericht mit Informationen, die aus verfügbaren Substituten herausgelesen werden (siehe Substitute). Dadurch kann die Plattenausnutzung von Store-Objekten profiliert werden, die gar nicht auf der Platte liegen und nur auf entfernten Rechnern vorhanden sind.

Sie können auch mehrere Paketnamen angeben:

$ guix size coreutils grep sed bash
Store-Objekt                            Gesamt   Selbst
/gnu/store/…-coreutils-8.24          77.8    13.8  13.4%
/gnu/store/…-grep-2.22               73.1     0.8   0.8%
/gnu/store/…-bash-4.3.42             72.3     4.7   4.6%
/gnu/store/…-readline-6.3            67.6     1.2   1.2%
…
Gesamt: 102.3 MiB

In diesem Beispiel sehen wir, dass die Kombination der vier Pakete insgesamt 102,3 MiB Platz verbraucht, was wesentlich weniger als die Summe der einzelnen Abschlüsse ist, weil diese viele Abhängigkeiten gemeinsam verwenden.

Wenn Sie sich das von guix size gelieferte Profil anschauen, fragen Sie sich vielleicht, warum ein bestimmtes Paket überhaupt darin auftaucht. Den Grund erfahren Sie, wenn Sie guix graph --path -t references benutzen, um sich den kürzesten Pfad zwischen zwei Paketen anzeigen zu lassen (siehe Aufruf von guix graph).

Die verfügbaren Befehlszeilenoptionen sind:

--substitute-urls=URLs

Substitutinformationen von den URLs benutzen. Siehe dieselbe Option bei guix build.

--sort=Schlüssel

Zeilen anhand des Schlüssels sortieren, der eine der folgenden Alternativen sein muss:

self

die Größe jedes Objekts (die Vorgabe),

Abschluss

die Gesamtgröße des Abschlusses des Objekts.

--map-file=Datei

Eine grafische Darstellung des Plattenplatzverbrauchs als eine PNG-formatierte Karte in die Datei schreiben.

Für das Beispiel oben sieht die Karte so aus:

Karte der Plattenausnutzung der
Coreutils

Diese Befehlszeilenoption setzt voraus, dass Guile-Charting installiert und im Suchpfad für Guile-Module sichtbar ist. Falls nicht, schlägt guix size beim Versuch fehl, dieses Modul zu laden.

--system=System
-s System

Pakete für dieses System betrachten — z.B. für x86_64-linux.

--load-path=Verzeichnis
-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.9 guix graph aufrufen

Pakete und ihre Abhängigkeiten bilden einen Graphen, genauer gesagt einen gerichteten azyklischen Graphen (englisch „Directed Acyclic Graph“, kurz DAG). Es kann schnell schwierig werden, ein Modell eines Paket-DAGs vor dem geistigen Auge zu behalten, weshalb der Befehl guix graph eine visuelle Darstellung des DAGs bietet. Das vorgegebene Verhalten von guix graph ist, eine DAG-Darstellung im Eingabeformat von Graphviz auszugeben, damit die Ausgabe direkt an den Befehl dot aus Graphviz weitergeleitet werden kann. Es kann aber auch eine HTML-Seite mit eingebettetem JavaScript-Code ausgegeben werden, um ein Sehnendiagramm (englisch „Chord Diagram“) in einem Web-Browser anzuzeigen, mit Hilfe der Bibliothek d3.js, oder es können Cypher-Anfragen ausgegeben werden, mit denen eine die Anfragesprache openCypher unterstützende Graph-Datenbank einen Graphen konstruieren kann. Wenn Sie --path angeben, zeigt Guix Ihnen einfach nur den kürzesten Pfad zwischen zwei Paketen an. Die allgemeine Syntax ist:

guix graph Optionen Pakete

Zum Beispiel erzeugt der folgende Befehl eine PDF-Datei, die den Paket-DAG für die GNU Core Utilities darstellt, welcher ihre Abhängigkeiten zur Erstellungszeit anzeigt:

guix graph coreutils | dot -Tpdf > dag.pdf

Die Ausgabe sieht so aus:

Abhängigkeitsgraph der GNU Coreutils

Ein netter, kleiner Graph, oder?

Vielleicht ist es Ihnen aber lieber, den Graphen interaktiv mit dem xdot-Programm anzuschauen (aus dem Paket xdot):

guix graph coreutils | xdot -

Aber es gibt mehr als eine Art von Graph! Der Graph oben ist kurz und knapp: Es ist der Graph der Paketobjekte, ohne implizite Eingaben wie GCC, libc, grep und so weiter. Oft möchte man einen knappen Graphen sehen, aber manchmal will man auch mehr Details sehen. guix graph unterstützt mehrere Typen von Graphen; Sie können den Detailgrad auswählen.

package

Der vorgegebene Typ aus dem Beispiel oben. Er zeigt den DAG der Paketobjekte ohne implizite Abhängigkeiten. Er ist knapp, filtert aber viele Details heraus.

reverse-package

Dies zeigt den umgekehrten DAG der Pakete. Zum Beispiel liefert

guix graph --type=reverse-package ocaml

… den Graphen der Pakete, die explizit von OCaml abhängen (wenn Sie auch an Fällen interessiert sind, bei denen OCaml eine implizite Abhängigkeit ist, siehe reverse-bag weiter unten).

Beachten Sie, dass für Kernpakete damit gigantische Graphen entstehen können. Wenn Sie nur die Anzahl der Pakete wissen wollen, die von einem gegebenen Paket abhängen, benutzen Sie guix refresh --list-dependent (siehe --list-dependent).

bag-emerged

Dies ist der Paket-DAG einschließlich impliziter Eingaben.

Zum Beispiel liefert der folgende Befehl

guix graph --type=bag-emerged coreutils

… diesen größeren Graphen:

Detaillierter Abhängigkeitsgraph der
GNU Coreutils

Am unteren Rand des Graphen sehen wir alle impliziten Eingaben des gnu-build-system (siehe gnu-build-system).

Beachten Sie dabei aber, dass auch hier die Abhängigkeiten dieser impliziten Eingaben — d.h. die Bootstrap-Abhängigkeiten (siehe Bootstrapping) — nicht gezeigt werden, damit der Graph knapper bleibt.

bag

Ähnlich wie bag-emerged, aber diesmal mit allen Bootstrap-Abhängigkeiten.

bag-with-origins

Ähnlich wie bag, aber auch mit den Ursprüngen und deren Abhängigkeiten.

reverse-bag

Dies zeigt den umgekehrten DAG der Pakete. Anders als reverse-package werden auch implizite Abhängigkeiten berücksichtigt. Zum Beispiel liefert

guix graph -t reverse-bag dune

… den Graphen aller Pakete, die von Dune direkt oder indirekt abhängen. Weil Dune eine implizite Abhängigkeit von vielen Paketen über das dune-build-system ist, zeigt er eine große Zahl von Paketen, während bei reverse-package nur sehr wenige bis gar keine zu sehen sind.

Ableitung

Diese Darstellung ist am detailliertesten: Sie zeigt den DAG der Ableitungen (siehe Ableitungen) und der einfachen Store-Objekte. Verglichen mit obiger Darstellung sieht man viele zusätzliche Knoten einschließlich Erstellungs-Skripts, Patches, Guile-Module usw.

Für diesen Typ Graph kann auch der Name einer .drv-Datei anstelle eines Paketnamens angegeben werden, etwa so:

guix graph -t derivation `guix system build -d my-config.scm`
module

Dies ist der Graph der Paketmodule (siehe Paketmodule). Zum Beispiel zeigt der folgende Befehl den Graphen für das Paketmodul an, das das guile-Paket definiert:

guix graph -t module guile | xdot -

Alle oben genannten Typen entsprechen Abhängigkeiten zur Erstellungszeit. Der folgende Graphtyp repräsentiert die Abhängigkeiten zur Laufzeit:

references

Dies ist der Graph der Referenzen einer Paketausgabe, wie guix gc --references sie liefert (siehe Aufruf von guix gc).

Wenn die angegebene Paketausgabe im Store nicht verfügbar ist, versucht guix graph, die Abhängigkeitsinformationen aus Substituten zu holen.

Hierbei können Sie auch einen Store-Dateinamen statt eines Paketnamens angeben. Zum Beispiel generiert der Befehl unten den Referenzgraphen Ihres Profils (der sehr groß werden kann!):

guix graph -t references `readlink -f ~/.guix-profile`
referrers

Dies ist der Graph der ein Store-Objekt referenzierenden Objekte, wie guix gc --referrers sie liefern würde (siehe Aufruf von guix gc).

Er basiert ausschließlich auf lokalen Informationen aus Ihrem Store. Nehmen wir zum Beispiel an, dass das aktuelle Inkscape in 10 Profilen verfügbar ist, dann wird guix graph -t referrers inkscape einen Graph zeigen, der bei Inkscape gewurzelt ist und Kanten zu diesen 10 Profilen hat.

Ein solcher Graph kann dabei helfen, herauszufinden, weshalb ein Store-Objekt nicht vom Müllsammler abgeholt werden kann.

Oftmals passt der Graph des Pakets, für das Sie sich interessieren, nicht auf Ihren Bildschirm, und überhaupt möchten Sie ja nur wissen, warum das Paket von einem anderen abhängt, das scheinbar nichts damit zu tun hat. Die Befehlszeilenoption --path weist guix graph an, den kürzesten Pfad zwischen zwei Paketen (oder Ableitungen, Store-Objekten etc.) anzuzeigen:

$ guix graph --path emacs libunistring
emacs@26.3
mailutils@3.9
libunistring@0.9.10
$ guix graph --path -t derivation emacs libunistring
/gnu/store/…-emacs-26.3.drv
/gnu/store/…-mailutils-3.9.drv
/gnu/store/…-libunistring-0.9.10.drv
$ guix graph --path -t references emacs libunistring
/gnu/store/…-emacs-26.3
/gnu/store/…-libidn2-2.2.0
/gnu/store/…-libunistring-0.9.10

Folgendes sind die verfügbaren Befehlszeilenoptionen:

--type=Typ
-t Typ

Eine Graph-Ausgabe dieses Typs generieren. Dieser Typ muss einer der oben genannten Werte sein.

--list-types

Die unterstützten Graph-Typen auflisten.

--backend=Backend
-b Backend

Einen Graph mit Hilfe des ausgewählten Backends generieren.

--list-backends

Die unterstützten Graph-Backends auflisten.

Derzeit sind die verfügbaren Backends Graphviz und d3.js.

--path

Den kürzesten Pfad zwischen zwei Knoten anzeigen, die den mit --type angegebenen Typ aufweisen. Im Beispiel unten wird der kürzeste Pfad zwischen libreoffice und llvm anhand der Referenzen von libreoffice angezeigt:

$ guix graph --path -t references libreoffice llvm
/gnu/store/…-libreoffice-6.4.2.2
/gnu/store/…-libepoxy-1.5.4
/gnu/store/…-mesa-19.3.4
/gnu/store/…-llvm-9.0.1
--expression=Ausdruck
-e Ausdruck

Als Paket benutzen, wozu der Ausdruck ausgewertet wird.

Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in diesem Beispiel:

guix graph -e '(@@ (gnu packages commencement) gnu-make-final)'
--system=System
-s System

Den Graphen für das System anzeigen — z.B. i686-linux.

Der Abhängigkeitsgraph ist größtenteils von der Systemarchitektur unabhängig, aber ein paar architekturabhängige Teile können Ihnen mit dieser Befehlszeilenoption visualisiert werden.

--load-path=Verzeichnis
-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind.

Hinzu kommt, dass guix graph auch all die üblichen Paketumwandlungsoptionen unterstützt (siehe Paketumwandlungsoptionen). Somit ist es kein Problem, die Folgen einer den Paketgraphen umschreibenden Umwandlung wie --with-input zu erkennen. Zum Beispiel gibt der folgende Befehl den Graphen von git aus, nachdem openssl an allen Stellen im Graphen durch libressl ersetzt wurde:

guix graph git --with-input=openssl=libressl

Ihrem Vergnügen sind keine Grenzen gesetzt!


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.10 guix publish aufrufen

Der Zweck von guix publish ist, es Nutzern zu ermöglichen, ihren Store auf einfache Weise mit anderen zu teilen, die ihn dann als Substitutserver einsetzen können (siehe Substitute).

Wenn guix publish ausgeführt wird, wird dadurch ein HTTP-Server gestartet, so dass jeder mit Netzwerkzugang davon Substitute beziehen kann. Das bedeutet, dass jede Maschine, auf der Guix läuft, auch als Erstellungsfarm fungieren kann, weil die HTTP-Schnittstelle mit Cuirass, der Software, mit der die offizielle Erstellungsfarm ci.guix.gnu.org betrieben wird, kompatibel ist.

Um Sicherheit zu gewährleisten, wird jedes Substitut signiert, so dass Empfänger dessen Authentizität und Integrität nachprüfen können (siehe Substitute). Weil guix publish den Signierschlüssel des Systems benutzt, der nur vom Systemadministrator gelesen werden kann, muss es als der Administratornutzer „root“ gestartet werden. Mit der Befehlszeilenoption --user werden Administratorrechte bald nach dem Start wieder abgelegt.

Das Schlüsselpaar zum Signieren muss erzeugt werden, bevor guix publish gestartet wird. Dazu können Sie guix archive --generate-key ausführen (siehe Aufruf von guix archive).

Die allgemeine Syntax lautet:

guix publish Optionen

Wird guix publish ohne weitere Argumente ausgeführt, wird damit ein HTTP-Server gestartet, der auf Port 8080 lauscht:

guix publish

Sobald ein Server zum Veröffentlichen autorisiert wurde, kann der Daemon davon Substitute herunterladen. Siehe Substitute von anderen Servern holen.

Nach den Voreinstellungen komprimiert guix publish Archive erst dann, wenn sie angefragt werden. Dieser „dynamische“ Modus bietet sich an, weil so nichts weiter eingerichtet werden muss und er direkt verfügbar ist. Wenn Sie allerdings viele Clients bedienen wollen, empfehlen wir, dass Sie die Befehlszeilenoption --cache benutzen, die das Zwischenspeichern der komprimierten Archive aktiviert, bevor diese an die Clients geschickt werden — siehe unten für Details. Mit dem Befehl guix weather haben Sie eine praktische Methode zur Hand, zu überprüfen, was so ein Server anbietet (siehe Aufruf von guix weather).

Als Bonus dient guix publish auch als inhaltsadressierbarer Spiegelserver für Quelldateien, die in origin-Verbundsobjekten eingetragen sind (siehe „origin“-Referenz). Wenn wir zum Beispiel annehmen, dass guix publish auf example.org läuft, liefert folgende URL die rohe hello-2.10.tar.gz-Datei mit dem angegebenen SHA256-Hash als ihre Prüfsumme (dargestellt im nix-base32-Format, siehe Aufruf von guix hash):

http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1…ndq1i

Offensichtlich funktionieren diese URLs nur mit solchen Dateien, die auch im Store vorliegen; in anderen Fällen werden sie 404 („Nicht gefunden“) zurückliefern.

Erstellungsprotokolle sind unter /log-URLs abrufbar:

http://example.org/log/gwspk…-guile-2.2.3

Ist der guix-daemon so eingestellt, dass er Erstellungsprotokolle komprimiert abspeichert, wie es voreingestellt ist (siehe Aufruf des guix-daemon), liefern /log-URLs das unveränderte komprimierte Protokoll, mit einer entsprechenden Content-Type- und/oder Content-Encoding-Kopfzeile. Wir empfehlen dabei, dass Sie den guix-daemon mit --log-compression=gzip ausführen, weil Web-Browser dieses Format automatisch dekomprimieren können, was bei Bzip2-Kompression nicht der Fall ist.

Folgende Befehlszeilenoptionen stehen zur Verfügung:

--port=Port
-p Port

Auf HTTP-Anfragen auf diesem Port lauschen.

--listen=Host

Auf der Netzwerkschnittstelle für den angegebenen Host, also der angegebenen Rechneradresse, lauschen. Vorgegeben ist, Verbindungen mit jeder Schnittstelle zu akzeptieren.

--user=Benutzer
-u Benutzer

So früh wie möglich alle über die Berechtigungen des Benutzers hinausgehenden Berechtigungen ablegen — d.h. sobald der Server-Socket geöffnet und der Signierschlüssel gelesen wurde.

--compression[=Methode[:Stufe]]
-C [Methode[:Stufe]]

Daten auf der angegebenen Kompressions-Stufe mit der angegebenen Methode komprimieren. Als Methode kann entweder lzip oder gzip angegeben werden. Wird keine Methode angegeben, wird gzip benutzt.

Daten auf der angegebenen Kompressions-Stufe komprimieren. Wird als Stufe null angegeben, wird Kompression deaktiviert. Der Bereich von 1 bis 9 entspricht unterschiedlichen Kompressionsstufen: 1 ist am schnellsten, während 9 am besten komprimiert (aber den Prozessor mehr auslastet). Der Vorgabewert ist 3.

Normalerweise ist die Kompression mit lzip wesentlich besser als bei gzip, dafür wird der Prozessor geringfügig stärker ausgelastet; siehe Vergleichswerte auf dem Webauftritt von lzip.

Wenn --cache nicht übergeben wird, werden Daten dynamisch immer erst dann komprimiert, wenn sie abgeschickt werden; komprimierte Datenströme landen in keinem Zwischenspeicher. Um also die Auslastung der Maschine, auf der guix publish läuft, zu reduzieren, kann es eine gute Idee sein, eine niedrige Kompressionsstufe zu wählen, guix publish einen Proxy mit Zwischenspeicher (einen „Caching Proxy“) voranzuschalten, oder --cache zu benutzen. --cache zu benutzen, hat den Vorteil, dass guix publish damit eine Content-Length-HTTP-Kopfzeile seinen Antworten beifügen kann.

Wenn diese Befehlszeilenoption mehrfach angegeben wird, wird jedes Substitut mit allen ausgewählten Methoden komprimiert und jede davon wird bei Anfragen mitgeteilt. Das ist nützlich, weil Benutzer, bei denen nicht alle Kompressionsmethoden unterstützt werden, die passende wählen können.

--cache=Verzeichnis
-c Verzeichnis

Archive und Metadaten (.narinfo-URLs) in das Verzeichnis zwischenspeichern und nur solche Archive versenden, die im Zwischenspeicher vorliegen.

Wird diese Befehlszeilenoption weggelassen, dann werden Archive und Metadaten „dynamisch“ erst auf eine Anfrage hin erzeugt. Dadurch kann die verfügbare Bandbreite reduziert werden, besonders wenn Kompression aktiviert ist, weil die Operation dann durch die Prozessorleistung beschränkt sein kann. Noch ein Nachteil des voreingestellten Modus ist, dass die Länge der Archive nicht im Voraus bekannt ist, guix publish also keine Content-Length-HTTP-Kopfzeile an seine Antworten anfügt, wodurch Clients nicht wissen können, welche Datenmenge noch heruntergeladen werden muss.

Im Gegensatz dazu löst, wenn --cache benutzt wird, die erste Anfrage nach einem Store-Objekt (über dessen .narinfo-URL) den Start eines Hintergrundprozesses aus, der das Archiv in den Zwischenspeicher einlagert (auf Englisch sagen wir „bake the archive“), d.h. seine .narinfo wird berechnet und das Archiv, falls nötig, komprimiert. Sobald das Archiv im Verzeichnis zwischengespeichert wurde, werden nachfolgende Anfragen erfolgreich sein und direkt aus dem Zwischenspeicher bedient, der garantiert, dass Clients optimale Bandbreite genießen.

Die erste Anfrage nach einer .narinfo wird trotzdem 200 zurückliefern, wenn das angefragte Store-Objekt „klein genug“ ist, also kleiner als der Schwellwert für die Zwischenspeicherumgehung, siehe --cache-bypass-threshold unten. So müssen Clients nicht darauf warten, dass das Archiv eingelagert wurde. Bei größeren Store-Objekten liefert die erste .narinfo-Anfrage 404 zurück, was bedeutet, dass Clients warten müssen, bis das Archiv eingelagert wurde.

Der Prozess zum Einlagern wird durch Worker-Threads umgesetzt. Der Vorgabe entsprechend wird dazu pro Prozessorkern ein Thread erzeugt, aber dieses Verhalten kann angepasst werden. Siehe --workers weiter unten.

Wird --ttl verwendet, werden zwischengespeicherte Einträge automatisch gelöscht, sobald die dabei angegebene Zeit abgelaufen ist.

--workers=N

Wird --cache benutzt, wird die Reservierung von N Worker-Threads angefragt, um Archive einzulagern.

--ttl=ttl

Cache-Control-HTTP-Kopfzeilen erzeugen, die eine Time-to-live (TTL) von ttl signalisieren. Für ttl muss eine Dauer (mit dem Anfangsbuchstaben der Maßeinheit der Dauer im Englischen) angegeben werden: 5d bedeutet 5 Tage, 1m bedeutet 1 Monat und so weiter.

Das ermöglicht es Guix, Substitutinformationen ttl lang zwischenzuspeichern. Beachten Sie allerdings, dass guix publish selbst nicht garantiert, dass die davon angebotenen Store-Objekte so lange verfügbar bleiben, wie es die ttl vorsieht.

Des Weiteren können bei Nutzung von --cache die zwischengespeicherten Einträge gelöscht werden, wenn auf sie ttl lang nicht zugegriffen wurde und kein ihnen entsprechendes Objekt mehr im Store existiert.

--cache-bypass-threshold=Größe

Wird dies in Verbindung mit --cache angegeben, werden Store-Objekte kleiner als die Größe sofort verfügbar sein, obwohl sie noch nicht in den Zwischenspeicher eingelagert wurden. Die Größe gibt die Größe in Bytes an oder ist mit einem Suffix M für Megabyte und so weiter versehen. Die Vorgabe ist 10M.

Durch diese „Zwischenspeicherumgehung“ lässt sich die Verzögerung bis zur Veröffentlichung an Clients reduzieren, auf Kosten zusätzlicher Ein-/Ausgaben und CPU-Auslastung für den Server. Je nachdem, welche Zugriffsmuster Clients haben, werden diese Store-Objekte vielleicht mehrfach zur Einlagerung vorbereitet, ehe eine Kopie davon im Zwischenspeicher verfügbar wird.

Wenn ein Anbieter nur wenige Nutzer unterhält, kann es helfen, den Schwellwert zu erhöhen, oder auch wenn garantiert werden soll, dass es auch für wenig beliebte Store-Objekte Substitute gibt.

--nar-path=Pfad

Den Pfad als Präfix für die URLs von „nar“-Dateien benutzen (siehe Normalisierte Archive).

Vorgegeben ist, dass Nars unter einer URL mit /nar/gzip/…-coreutils-8.25 angeboten werden. Mit dieser Befehlszeilenoption können Sie den /nar-Teil durch den angegebenen Pfad ersetzen.

--public-key=Datei
--private-key=Datei

Die angegebenen Dateien als das Paar aus öffentlichem und privatem Schlüssel zum Signieren veröffentlichter Store-Objekte benutzen.

Die Dateien müssen demselben Schlüsselpaar entsprechen (der private Schlüssel wird zum Signieren benutzt, der öffentliche Schlüssel wird lediglich in den Metadaten der Signatur aufgeführt). Die Dateien müssen Schlüssel im kanonischen („canonical“) S-Ausdruck-Format enthalten, wie es von guix archive --generate-key erzeugt wird (siehe Aufruf von guix archive). Vorgegeben ist, dass /etc/guix/signing-key.pub und /etc/guix/signing-key.sec benutzt werden.

--repl[=Port]
-r [Port]

Einen Guile-REPL-Server (siehe REPL Servers in Referenzhandbuch zu GNU Guile) auf diesem Port starten (37146 ist voreingestellt). Dies kann zur Fehlersuche auf einem laufenden „guix publish“-Server benutzt werden.

guix publish auf einem „Guix System“-System zu aktivieren ist ein Einzeiler: Instanziieren Sie einfach einen guix-publish-service-type-Dienst im services-Feld Ihres operating-system-Objekts zur Betriebssystemdeklaration (siehe guix-publish-service-type).

Falls Sie Guix aber auf einer „Fremddistribution“ laufen lassen, folgen Sie folgenden Anweisungen:


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.11 guix challenge aufrufen

Entsprechen die von diesem Server gelieferten Binärdateien tatsächlich dem Quellcode, aus dem sie angeblich erzeugt wurden? Ist ein Paketerstellungsprozess deterministisch? Diese Fragen versucht guix challenge zu beantworten.

Die erste Frage ist offensichtlich wichtig: Bevor man einen Substitutserver benutzt (siehe Substitute), verifiziert man besser, dass er die richtigen Binärdateien liefert, d.h. man fechtet sie an. Die letzte Frage macht die erste möglich: Wenn Paketerstellungen deterministisch sind, müssten voneinander unabhängige Erstellungen genau dasselbe Ergebnis liefern, Bit für Bit; wenn ein Server mit einer anderen Binärdatei als der lokal erstellten Binärdatei antwortet, ist diese entweder beschädigt oder bösartig.

Wir wissen, dass die in /gnu/store-Dateinamen auftauchende Hash-Prüfsumme der Hash aller Eingaben des Prozesses ist, mit dem die Datei oder das Verzeichnis erstellt wurde — Compiler, Bibliotheken, Erstellungsskripts und so weiter (siehe Einführung). Wenn wir von deterministischen Erstellungen ausgehen, sollte ein Store-Dateiname also auf genau eine Erstellungsausgabe abgebildet werden. Mit guix challenge prüft man, ob es tatsächlich eine eindeutige Abbildung gibt, indem die Erstellungsausgaben mehrerer unabhängiger Erstellungen jedes angegebenen Store-Objekts verglichen werden.

Die Ausgabe des Befehls sieht so aus:

$ guix challenge --substitute-urls="https://ci.guix.gnu.org https://guix.example.org"
Liste der Substitute von „https://ci.guix.gnu.org“ wird aktualisiert … 100.0%
Liste der Substitute von „https://guix.example.org“ wird aktualisiert … 100.0%
Inhalt von /gnu/store/…-openssl-1.0.2d verschieden:
  lokale Prüfsumme: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://ci.guix.gnu.org/nar/…-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://guix.example.org/nar/…-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
  Diese Dateien unterscheiden sich:
    /lib/libcrypto.so.1.1
    /lib/libssl.so.1.1

Inhalt von /gnu/store/…-git-2.5.0 verschieden:
  lokale Prüfsumme: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
  https://ci.guix.gnu.org/nar/…-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
  https://guix.example.org/nar/…-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
  Diese Datei unterscheidet sich:
    /libexec/git-core/git-fsck

Inhalt von /gnu/store/…-pius-2.1.1 verschieden:
  lokale Prüfsumme: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://ci.guix.gnu.org/nar/…-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://guix.example.org/nar/…-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
  Diese Datei unterscheidet sich:
    /share/man/man1/pius.1.gz

…

6,406 Store-Objekte wurden analysiert:
  — 4,749 (74.1%) waren identisch
  — 525 (8.2%) unterscheiden sich
  — 1,132 (17.7%) blieben ergebnislos

In diesem Beispiel wird mit guix challenge zuerst die Menge lokal erstellter Ableitungen im Store ermittelt — im Gegensatz zu von einem Substitserver heruntergeladenen Store-Objekten — und dann werden alle Substitutserver angefragt. Diejenigen Store-Objekte, bei denen der Server ein anderes Ergebnis berechnet hat als die lokale Erstellung, werden gemeldet.

Nehmen wir zum Beispiel an, guix.example.org gibt uns immer eine verschiedene Antwort, aber ci.guix.gnu.org stimmt mit lokalen Erstellungen überein, außer im Fall von Git. Das könnte ein Hinweis sein, dass der Erstellungsprozess von Git nichtdeterministisch ist; das bedeutet, seine Ausgabe variiert abhängig von verschiedenen Umständen, die Guix nicht vollends kontrollieren kann, obwohl es Pakete in isolierten Umgebungen erstellt (siehe Funktionalitäten). Zu den häufigsten Quellen von Nichtdeterminismus gehören das Einsetzen von Zeitstempeln innerhalb der Erstellungsgebnisse, das Einsetzen von Zufallszahlen und von Auflistungen eines Verzeichnisinhalts sortiert nach der Inode-Nummer. Siehe https://reproducible-builds.org/docs/ für mehr Informationen.

Um herauszufinden, was mit dieser Git-Binärdatei nicht stimmt, ist es am leichtesten, einfach diesen Befehl auszuführen:

guix challenge git \
  --diff=diffoscope \
  --substitute-urls="https://ci.guix.gnu.org https://guix.example.org"

Dadurch wird diffoscope automatisch aufgerufen, um detaillierte Informationen über sich unterscheidende Dateien anzuzeigen.

Alternativ können wir so etwas machen (siehe Aufruf von guix archive):

$ wget -q -O - https://ci.guix.gnu.org/nar/lzip/…-git-2.5.0 \
   | lzip -d | guix archive -x /tmp/git
$ diff -ur --no-dereference /gnu/store/…-git.2.5.0 /tmp/git

Dieser Befehl zeigt die Unterschiede zwischen den Dateien, die sich aus der lokalen Erstellung ergeben, und den Dateien, die sich aus der Erstellung auf ci.guix.gnu.org ergeben (siehe Dateien vergleichen und zusammenführen in Comparing and Merging Files). Der Befehl diff funktioniert großartig für Textdateien. Wenn sich Binärdateien unterscheiden, ist Diffoscope die bessere Wahl: Es ist ein hilfreiches Werkzeug, das Unterschiede in allen Arten von Dateien visualisiert.

Sobald Sie mit dieser Arbeit fertig sind, können Sie erkennen, ob die Unterschiede aufgrund eines nichtdeterministischen Erstellungsprozesses oder wegen einem bösartigen Server zustande kommen. Wir geben uns Mühe, Quellen von Nichtdeterminismus in Paketen zu entfernen, damit Substitute leichter verifiziert werden können, aber natürlich ist an diesem Prozess nicht nur Guix, sondern ein großer Teil der Freie-Software-Gemeinschaft beteiligt. In der Zwischenzeit ist guix challenge eines der Werkzeuge, die das Problem anzugehen helfen.

Wenn Sie ein Paket für Guix schreiben, ermutigen wir Sie, zu überprüfen, ob ci.guix.gnu.org und andere Substitutserver dasselbe Erstellungsergebnis bekommen, das Sie bekommen haben. Das geht so:

$ guix challenge Paket

Dabei wird mit Paket eine Paketspezifikation wie guile@2.0 oder glibc:debug bezeichnet.

Die allgemeine Syntax lautet:

guix challenge Optionen [Pakete…]

Wird ein Unterschied zwischen der Hash-Prüfsumme des lokal erstellten Objekts und dem vom Server gelieferten Substitut festgestellt, oder zwischen den Substituten von unterschiedlichen Servern, dann wird der Befehl dies wie im obigen Beispiel anzeigen und mit dem Exit-Code 2 terminieren (andere Exit-Codes außer null stehen für andere Arten von Fehlern).

Die eine, wichtige Befehlszeilenoption ist:

--substitute-urls=URLs

Die URLs als durch Leerraumzeichen getrennte Liste von Substitut-Quell-URLs benutzen. mit denen verglichen wird.

--diff=Modus

Wenn sich Dateien unterscheiden, diese Unterschiede entsprechend dem Modus anzeigen. Dieser kann einer der folgenden sein:

simple (die Vorgabe)

Zeige die Liste sich unterscheidender Dateien.

diffoscope
Befehl

Diffoscope aufrufen und ihm zwei Verzeichnisse mit verschiedenem Inhalt übergeben.

Wenn der Befehl ein absoluter Dateiname ist, wird der Befehl anstelle von Diffoscope ausgeführt.

none

Keine näheren Details zu Unterschieden anzeigen.

Solange kein --diff=none angegeben wird, werden durch guix challenge also Store-Objekte von den festgelegten Substitutservern heruntergeladen, damit diese verglichen werden können.

--verbose
-v

Details auch zu Übereinstimmungen (deren Inhalt identisch ist) ausgeben, zusätzlich zu Informationen über Unterschiede.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.12 guix copy aufrufen

Der Befehl guix copy kopiert Objekte aus dem Store einer Maschine in den Store einer anderen Maschine mittels einer Secure-Shell-Verbindung (kurz SSH-Verbindung)22. Zum Beispiel kopiert der folgende Befehl das Paket coreutils, das Profil des Benutzers und all deren Abhängigkeiten auf den anderen Rechner, dazu meldet sich Guix als Benutzer an:

guix copy --to=Benutzer@Rechner \
          coreutils `readlink -f ~/.guix-profile`

Wenn manche der zu kopierenden Objekte schon auf dem anderen Rechner vorliegen, werden sie tatsächlich nicht übertragen.

Der folgende Befehl bezieht libreoffice und gimp von dem Rechner, vorausgesetzt sie sind dort verfügbar:

guix copy --from=host libreoffice gimp

Die SSH-Verbindung wird mit dem Guile-SSH-Client hergestellt, der mit OpenSSH kompatibel ist: Er berücksichtigt ~/.ssh/known_hosts und ~/.ssh/config und verwendet den SSH-Agenten zur Authentifizierung.

Der Schlüssel, mit dem gesendete Objekte signiert sind, muss von der entfernten Maschine akzeptiert werden. Ebenso muss der Schlüssel, mit dem die Objekte signiert sind, die Sie von der entfernten Maschine empfangen, in Ihrer Datei /etc/guix/acl eingetragen sein, damit Ihr Daemon sie akzeptiert. Siehe Aufruf von guix archive für mehr Informationen über die Authentifizierung von Store-Objekten.

Die allgemeine Syntax lautet:

guix copy [--to=Spezifikation|--from=Spezifikation] Objekte

Sie müssen immer eine der folgenden Befehlszeilenoptionen angeben:

--to=Spezifikation
--from=Spezifikation

Gibt den Rechner (den „Host“) an, an den oder von dem gesendet bzw. empfangen wird. Die Spezifikation muss eine SSH-Spezifikation sein wie example.org, charlie@example.org oder charlie@example.org:2222.

Die Objekte können entweder Paketnamen wie gimp oder Store-Objekte wie /gnu/store/…-idutils-4.6 sein.

Wenn ein zu sendendes Paket mit Namen angegeben wird, wird es erst erstellt, falls es nicht im Store vorliegt, außer --dry-run wurde angegeben wurde. Alle gemeinsamen Erstellungsoptionen werden unterstützt (siehe Gemeinsame Erstellungsoptionen).


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.13 guix container aufrufen

Anmerkung: Dieses Werkzeug ist noch experimentell, Stand Version 1.2.0. Die Schnittstelle wird sich in Zukunft grundlegend verändern.

Der Zweck von guix container ist, in einer isolierten Umgebung (gemeinhin als „Container“ bezeichnet) laufende Prozesse zu manipulieren, die typischerweise durch die Befehle guix environment (siehe Aufruf von guix environment) und guix system container (siehe Aufruf von guix system) erzeugt werden.

Die allgemeine Syntax lautet:

guix container Aktion Optionen

Mit Aktion wird die Operation angegeben, die in der isolierten Umgebung durchgeführt werden soll, und mit Optionen werden die kontextabhängigen Argumente an die Aktion angegeben.

Folgende Aktionen sind verfügbar:

exec

Führt einen Befehl im Kontext der laufenden isolierten Umgebung aus.

Die Syntax ist:

guix container exec PID Programm Argumente

PID gibt die Prozess-ID der laufenden isolierten Umgebung an. Als Programm muss eine ausführbare Datei im Wurzeldateisystem der isolierten Umgebung angegeben werden. Die Argumente sind die zusätzlichen Befehlszeilenoptionen, die an das Programm übergeben werden.

Der folgende Befehl startet eine interaktive Anmelde-Shell innerhalb einer isolierten Guix-Systemumgebung, gestartet durch guix system container, dessen Prozess-ID 9001 ist:

guix container exec 9001 /run/current-system/profile/bin/bash --login

Beachten Sie, dass die PID nicht der Elternprozess der isolierten Umgebung sein darf, sondern PID 1 in der isolierten Umgebung oder einer seiner Kindprozesse sein muss.


Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.14 guix weather aufrufen

Manchmal werden Sie schlecht gelaunt sein, weil es zu wenige Substitute gibt und die Pakete bei Ihnen selbst erstellt werden müssen (siehe Substitute). Der Befehl guix weather zeigt einen Bericht über die Verfügbarkeit von Substituten auf den angegebenen Servern an, damit Sie sich eine Vorstellung davon machen können, wie es heute um Ihre Laune bestellt sein wird. Manchmal bekommt man als Nutzer so hilfreiche Informationen, aber in erster Linie nützt der Befehl den Leuten, die guix publish benutzen (siehe Aufruf von guix publish).

Hier ist ein Beispiel für einen Aufruf davon:

$ guix weather --substitute-urls=https://guix.example.org
5.872 Paketableitungen für x86_64-linux berechnen …
Nach 6.128 Store-Objekten von https://guix.example.org suchen …
updating list of substitutes from 'https://guix.example.org'... 100.0%
https://guix.example.org
  43,4% Substitute verfügbar (2.658 von 6.128)
  7.032,5 MiB an Nars (komprimiert)
  19.824,2 MiB auf der Platte (unkomprimiert)
  0,030 Sekunden pro Anfrage (182,9 Sekunden insgesamt)
  33,5 Anfragen pro Sekunde

  9,8% (342 von 3.470) der fehlenden Objekte sind in der Warteschlange
  Mindestens 867 Erstellungen in der Warteschlange
      x86_64-linux: 518 (59,7%)
      i686-linux: 221 (25,5%)
      aarch64-linux: 128 (14,8%)
  Erstellungsgeschwindigkeit: 23,41 Erstellungen pro Stunde
      x86_64-linux: 11,16 Erstellungen pro Stunde
      i686-linux: 6,03 Erstellungen pro Stunde
      aarch64-linux: 6,41 Erstellungen pro Stunde

Wie Sie sehen können, wird der Anteil unter allen Paketen angezeigt, für die auf dem Server Substitute verfügbar sind — unabhängig davon, ob Substitute aktiviert sind, und unabhängig davon, ob der Signierschlüssel des Servers autorisiert ist. Es wird auch über die Größe der komprimierten Archive (die „Nars“) berichtet, die vom Server angeboten werden, sowie über die Größe, die die zugehörigen Store-Objekte im Store belegen würden (unter der Annahme, dass Deduplizierung abgeschaltet ist) und über den Durchsatz des Servers. Der zweite Teil sind Statistiken zur Kontinuierlichen Integration (englisch „Continuous Integration“, kurz CI), wenn der Server dies unterstützt. Des Weiteren kann guix weather, wenn es mit der Befehlszeilenoption --coverage aufgerufen wird, „wichtige“ Paketsubstitute, die auf dem Server fehlen, auflisten (siehe unten).

Dazu werden mit guix weather Anfragen über HTTP(S) zu Metadaten (Narinfos) für alle relevanten Store-Objekte gestellt. Wie guix challenge werden die Signaturen auf den Substituten ignoriert, was harmlos ist, weil der Befehl nur Statistiken sammelt und keine Substitute installieren kann.

Die allgemeine Syntax lautet:

guix weather Optionen… [Pakete…]

Wenn keine Pakete angegeben werden, prüft guix weather für alle Pakete bzw. für die Pakete mit --manifest angegebenen Manifest, ob Substitute zur Verfügung stehen. Ansonsten wird es nur für die angegebenen Pakete geprüft. Es ist auch möglich, die Suche mit --system auf bestimmte Systemtypen einzuschränken. Der Rückgabewert von guix weather ist nicht null, wenn weniger als 100% Substitute verfügbar sind.

Die verfügbaren Befehlszeilenoptionen folgen.

--substitute-urls=URLs

URLs ist eine leerzeichengetrennte Liste anzufragender Substitutserver-URLs. Wird diese Befehlszeilenoption weggelassen, wird die vorgegebene Menge an Substitutservern angefragt.

--system=System
-s System

Substitute für das System anfragen — z.B. für aarch64-linux. Diese Befehlszeilenoption kann mehrmals angegeben werden, wodurch guix weather die Substitute für mehrere Systemtypen anfragt.

--manifest=Datei

Anstatt die Substitute für alle Pakete anzufragen, werden nur die in der Datei angegebenen Pakete erfragt. Die Datei muss ein Manifest enthalten, wie bei der Befehlszeilenoption -m von guix package (siehe Aufruf von guix package).

Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.

--coverage[=Anzahl]
-c [Anzahl]

Einen Bericht über die Substitutabdeckung für Pakete ausgeben, d.h. Pakete mit mindestens Anzahl-vielen Abhängigen (voreingestellt mindestens null) anzeigen, für die keine Substitute verfügbar sind. Die abhängigen Pakete werden selbst nicht aufgeführt: Wenn b von a abhängt und Substitute für a fehlen, wird nur a aufgeführt, obwohl dann in der Regel auch die Substitute für b fehlen. Das Ergebnis sieht so aus:

$ guix weather --substitute-urls=https://ci.guix.gnu.org -c 10
8.983 Paketableitungen für x86_64-linux berechnen …
Nach 9.343 Store-Objekten von https://ci.guix.gnu.org suchen …
Liste der Substitute von „https://ci.guix.gnu.org“ wird aktualisiert … 100.0%
https://ci.guix.gnu.org
  64.7% Substitute verfügbar (6.047 von 9.343)
…
2502 Pakete fehlen auf „https://ci.guix.info“ für „x86_64-linux“, darunter sind:
    58  kcoreaddons@5.49.0      /gnu/store/…-kcoreaddons-5.49.0
    46  qgpgme@1.11.1           /gnu/store/…-qgpgme-1.11.1
    37  perl-http-cookiejar@0.008  /gnu/store/…-perl-http-cookiejar-0.008
    …

Was man hier in diesem Beispiel sehen kann, ist, dass es für kcoreaddons und vermutlich die 58 Pakete, die davon abhängen, auf ci.guix.info keine Substitute gibt; Gleiches gilt für qgpgme und die 46 Pakete, die davon abhängen.

Wenn Sie ein Guix-Entwickler sind oder sich um diese Erstellungsfarm kümmern, wollen Sie sich diese Pakete vielleicht genauer anschauen. Es kann sein, dass sie schlicht nie erfolgreich erstellt werden können.

--display-missing

Eine Liste derjenigen Store-Objekte anzeigen, für die keine Substitute verfügbar sind.


Vorige: , Nach oben: Zubehör   [Inhalt][Index]

9.15 guix processes aufrufen

Der Befehl guix processes kann sich für Entwickler und Systemadministratoren als nützlich erweisen, besonders auf Maschinen mit mehreren Nutzern und auf Erstellungsfarmen. Damit werden die aktuellen Sitzungen (also Verbindungen zum Daemon) sowie Informationen über die beteiligten Prozesse aufgelistet23. Hier ist ein Beispiel für die davon gelieferten Informationen:

$ sudo guix processes
SessionPID: 19002
ClientPID: 19090
ClientCommand: guix environment --ad-hoc python

SessionPID: 19402
ClientPID: 19367
ClientCommand: guix publish -u guix-publish -p 3000 -C 9 …

SessionPID: 19444
ClientPID: 19419
ClientCommand: cuirass --cache-directory /var/cache/cuirass …
LockHeld: /gnu/store/…-perl-ipc-cmd-0.96.lock
LockHeld: /gnu/store/…-python-six-bootstrap-1.11.0.lock
LockHeld: /gnu/store/…-libjpeg-turbo-2.0.0.lock
ChildProcess: 20495: guix offload x86_64-linux 7200 1 28800
ChildProcess: 27733: guix offload x86_64-linux 7200 1 28800
ChildProcess: 27793: guix offload x86_64-linux 7200 1 28800

In diesem Beispiel sehen wir, dass guix-daemon drei Clients hat: guix environment, guix publish und das Werkzeug Cuirass zur Kontinuierlichen Integration. Deren Prozesskennung (PID) ist jeweils im ClientPID-Feld zu sehen. Das Feld SessionPID zeigt die PID des guix-daemon-Unterprozesses dieser bestimmten Sitzung.

Das Feld LockHeld zeigt an, welche Store-Objekte derzeit durch die Sitzung gesperrt sind, d.h. welche Store-Objekte zurzeit erstellt oder substituiert werden (das LockHeld-Feld wird nicht angezeigt, wenn guix processes nicht als Administratornutzer root ausgeführt wird). Letztlich sehen wir am ChildProcess-Feld oben, dass diese drei Erstellungen hier ausgelagert (englisch „offloaded“) werden (siehe Auslagern des Daemons einrichten).

Die Ausgabe ist im Recutils-Format, damit wir den praktischen recsel-Befehl benutzen können, um uns interessierende Sitzungen auszuwählen (siehe Selection Expressions in GNU recutils manual). Zum Beispiel zeigt dieser Befehl die Befehlszeile und PID des Clients an, der die Erstellung des Perl-Pakets ausgelöst hat:

$ sudo guix processes | \
    recsel -p ClientPID,ClientCommand -e 'LockHeld ~ "perl"'
ClientPID: 19419
ClientCommand: cuirass --cache-directory /var/cache/cuirass …

Nächste: , Vorige: , Nach oben: Top   [Inhalt][Index]

10 Systemkonfiguration

Guix System unterstützt einen Mechanismus zur konsistenten Konfiguration des gesamten Systems. Damit meinen wir, dass alle Aspekte der globalen Systemkonfiguration an einem Ort stehen, d.h. die zur Verfügung gestellten Systemdienste, die Zeitzone und Einstellungen zur Locale (also die Anpassung an regionale Gepflogenheiten und Sprachen) sowie Benutzerkonten. Sie alle werden an derselben Stelle deklariert. So eine Systemkonfiguration kann instanziiert, also umgesetzt, werden.

Einer der Vorteile, die ganze Systemkonfiguration unter die Kontrolle von Guix zu stellen, ist, dass so transaktionelle Systemaktualisierungen möglich werden und dass diese rückgängig gemacht werden können, wenn das aktualisierte System nicht richtig funktioniert (siehe Funktionalitäten). Ein anderer Vorteil ist, dass dieselbe Systemkonfiguration leicht auf einer anderen Maschine oder zu einem späteren Zeitpunkt benutzt werden kann, ohne dazu eine weitere Schicht administrativer Werkzeuge über den systemeigenen Werkzeugen einsetzen zu müssen.

In diesem Abschnitt wird dieser Mechanismus beschrieben. Zunächst betrachten wir ihn aus der Perspektive eines Administrators. Dabei wird erklärt, wie das System konfiguriert und instanziiert werden kann. Dann folgt eine Demonstration, wie der Mechanismus erweitert werden kann, etwa um neue Systemdienste zu unterstützen.


Nächste: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.1 Das Konfigurationssystem nutzen

Das Betriebssystem können Sie konfigurieren, indem Sie eine operating-system-Deklaration in einer Datei speichern, die Sie dann dem Befehl guix system übergeben (siehe Aufruf von guix system). Eine einfache Konfiguration mit den vorgegebenen Systemdiensten und dem vorgegebenen Linux-Libre als Kernel und mit einer initialen RAM-Disk und einem Bootloader sieht so aus:

;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh)

(operating-system
  (host-name "komputilo")
  (timezone "Europe/Berlin")
  (locale "en_US.utf8")

  ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
  ;; target hard disk, and "my-root" is the label of the target
  ;; root file system.
  (bootloader (bootloader-configuration
                (bootloader grub-bootloader)
                (target "/dev/sdX")))
  (file-systems (cons (file-system
                        (device (file-system-label "my-root"))
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons (user-account
                (name "alice")
                (comment "Bob's sister")
                (group "users")

                ;; Adding the account to the "wheel" group
                ;; makes it a sudoer.  Adding it to "audio"
                ;; and "video" allows the user to play sound
                ;; and access the webcam.
                (supplementary-groups '("wheel"
                                        "audio" "video")))
               %base-user-accounts))

  ;; Globally-installed packages.
  (packages (cons screen %base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (append (list (service dhcp-client-service-type)
                          (service openssh-service-type
                                   (openssh-configuration
                                    (openssh openssh-sans-x)
                                    (port-number 2222))))
                    %base-services)))

Dieses Beispiel sollte selbsterklärend sein. Manche der Felder oben, wie etwa host-name und bootloader, müssen angegeben werden. Andere sind optional, wie etwa packages und services, sind optional; werden sie nicht angegeben, nehmen sie einen Vorgabewert an.

Im Folgenden werden die Effekte von einigen der wichtigsten Feldern erläutert (siehe „operating-system“-Referenz für Details zu allen verfügbaren Feldern), dann wird beschrieben, wie man das Betriebssystem mit guix system instanziieren kann.

Bootloader

Das bootloader-Feld beschreibt, mit welcher Methode Ihr System „gebootet“ werden soll. Maschinen, die auf Intel-Prozessoren basieren, können im alten „Legacy“-BIOS-Modus gebootet werden, wie es im obigen Beispiel der Fall wäre. Neuere Maschinen benutzen stattdessen das Unified Extensible Firmware Interface (UEFI) zum Booten. In diesem Fall sollte das bootloader-Feld in etwa so aussehen:

(bootloader-configuration
  (bootloader grub-efi-bootloader)
  (target "/boot/efi"))

Siehe den Abschnitt Bootloader-Konfiguration für weitere Informationen zu den verfügbaren Konfigurationsoptionen.

global sichtbare Pakete

Im Feld packages werden Pakete aufgeführt, die auf dem System für alle Benutzerkonten global sichtbar sein sollen, d.h. in der PATH-Umgebungsvariablen jedes Nutzers, zusätzlich zu den nutzereigenen Profilen (siehe Aufruf von guix package). Die Variable %base-packages bietet alle Werkzeuge, die man für grundlegende Nutzer- und Administratortätigkeiten erwarten würde, einschließlich der GNU Core Utilities, der GNU Networking Utilities, des leichtgewichtigen Texteditors GNU Zile, find, grep und so weiter. Obiges Beispiel fügt zu diesen noch das Programm GNU Screen hinzu, welches aus dem Modul (gnu packages screen) genommen wird (siehe Paketmodule). Die Syntax (list package output) kann benutzt werden, um eine bestimmte Ausgabe eines Pakets auszuwählen:

(use-modules (gnu packages))
(use-modules (gnu packages dns))

(operating-system
  ;; …
  (packages (cons (list bind "utils")
                  %base-packages)))

Sich auf Pakete anhand ihres Variablennamens zu beziehen, wie oben bei bind, hat den Vorteil, dass der Name eindeutig ist; Tippfehler werden direkt als „unbound variables“ gemeldet. Der Nachteil ist, dass man wissen muss, in welchem Modul ein Paket definiert wird, um die Zeile mit use-package-modules entsprechend zu ergänzen. Um dies zu vermeiden, kann man auch die Prozedur specification->package aus dem Modul (gnu packages) aufrufen, welche das einem angegebenen Namen oder Name-Versions-Paar zu Grunde liegende Paket liefert:

(use-modules (gnu packages))

(operating-system
  ;; …
  (packages (append (map specification->package
                         '("tcpdump" "htop" "gnupg@2.0"))
                    %base-packages)))

Systemdienste

Das Feld services listet Systemdienste auf, die zur Verfügung stehen sollen, wenn das System startet (siehe Dienste). Die operating-system-Deklaration oben legt fest, dass wir neben den grundlegenden Basis-Diensten auch wollen, dass der OpenSSH-Secure-Shell-Daemon auf Port 2222 lauscht (siehe openssh-service-type). Intern sorgt der openssh-service-type dafür, dass sshd mit den richtigen Befehlszeilenoptionen aufgerufen wird, je nach Systemkonfiguration werden auch für dessen Betrieb nötige Konfigurationsdateien erstellt (siehe Dienste definieren).

Gelegentlich werden Sie die Basis-Dienste nicht einfach so, wie sie sind, benutzen, sondern anpassen wollen. Benutzen Sie modify-services (siehe modify-services), um die Liste der Basis-Dienste zu modifizieren.

Wenn Sie zum Beispiel guix-daemon und Mingetty (das Programm, womit Sie sich auf der Konsole anmelden) in der %base-services-Liste modifizieren möchten (siehe %base-services), schreiben Sie das Folgende in Ihre Betriebssystemdeklaration:

(define %my-services
  ;; Meine ganz eigene Liste von Diensten.
  (modify-services %base-services
    (guix-service-type config =>
                       (guix-configuration
                        (inherit config)
                        ;; Substitute von example.org herunterladen.
                        (substitute-urls
                          (list "https://example.org/guix"
                                "https://ci.guix.gnu.org"))))
    (mingetty-service-type config =>
                           (mingetty-configuration
                            (inherit config)
                            ;; Automatisch als "gast" anmelden.
                            (auto-login "gast")))))

(operating-system
  ;; …
  (services %my-services))

Dadurch ändert sich die Konfiguration — d.h. die Dienst-Parameter — der guix-service-type-Instanz und die aller mingetty-service-type-Instanzen in der %base-services-Liste. Das funktioniert so: Zunächst arrangieren wir, dass die ursprüngliche Konfiguration an den Bezeichner config im Rumpf gebunden wird, dann schreiben wir den Rumpf, damit er zur gewünschten Konfiguration ausgewertet wird. Beachten Sie insbesondere, wie wir mit inherit eine neue Konfiguration erzeugen, die dieselben Werte wie die alte Konfiguration hat, aber mit ein paar Modifikationen.

Die Konfiguration für typische Nutzung auf Heim- und Arbeitsrechnern, mit einer verschlüsselten Partition für das Wurzeldateisystem, einem X11-Anzeigeserver, GNOME und Xfce (Benutzer können im Anmeldebildschirm auswählen, welche dieser Arbeitsumgebungen sie möchten, indem sie die Taste F1 drücken), Netzwerkverwaltung, Verwaltungswerkzeugen für den Energieverbrauch, und Weiteres, würde so aussehen:

;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gnome)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")

  ;; Choose US English keyboard layout.  The "altgr-intl"
  ;; variant provides dead keys for accented characters.
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))

  ;; Use the UEFI variant of GRUB with the EFI System
  ;; Partition mounted on /boot/efi.
  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (target "/boot/efi")
                (keyboard-layout keyboard-layout)))

  ;; Specify a mapped device for the encrypted root partition.
  ;; The UUID is that returned by 'cryptsetup luksUUID'.
  (mapped-devices
   (list (mapped-device
          (source (uuid "12345678-1234-1234-1234-123456789abc"))
          (target "my-root")
          (type luks-device-mapping))))

  (file-systems (append
                 (list (file-system
                         (device (file-system-label "my-root"))
                         (mount-point "/")
                         (type "ext4")
                         (dependencies mapped-devices))
                       (file-system
                         (device (uuid "1234-ABCD" 'fat))
                         (mount-point "/boot/efi")
                         (type "vfat")))
                 %base-file-systems))

  ;; Create user `bob' with `alice' as its initial password.
  (users (cons (user-account
                (name "bob")
                (comment "Alice's brother")
                (password (crypt "alice" "$6$abc"))
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video")))
               %base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (append (list
                     ;; for HTTPS access
                     nss-certs
                     ;; for user mounts
                     gvfs)
                    %base-packages))

  ;; Add GNOME and Xfce---we can choose at the log-in screen
  ;; by clicking the gear.  Use the "desktop" services, which
  ;; include the X11 log-in service, networking with
  ;; NetworkManager, and more.
  (services (append (list (service gnome-desktop-service-type)
                          (service xfce-desktop-service-type)
                          (set-xorg-configuration
                           (xorg-configuration
                            (keyboard-layout keyboard-layout))))
                    %desktop-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Ein grafisches System mit einer Auswahl an leichtgewichtigen Fenster-Managern statt voll ausgestatteten Arbeitsumgebungen würde so aussehen:

;; This is an operating system configuration template
;; for a "desktop" setup without full-blown desktop
;; environments.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules bootloaders certs emacs emacs-xyz ratpoison suckless wm
                     xorg)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")

  ;; Use the UEFI variant of GRUB with the EFI System
  ;; Partition mounted on /boot/efi.
  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (target "/boot/efi")))

  ;; Assume the target root file system is labelled "my-root",
  ;; and the EFI System Partition has UUID 1234-ABCD.
  (file-systems (append
                 (list (file-system
                         (device (file-system-label "my-root"))
                         (mount-point "/")
                         (type "ext4"))
                       (file-system
                         (device (uuid "1234-ABCD" 'fat))
                         (mount-point "/boot/efi")
                         (type "vfat")))
                 %base-file-systems))

  (users (cons (user-account
                (name "alice")
                (comment "Bob's sister")
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video")))
               %base-user-accounts))

  ;; Add a bunch of window managers; we can choose one at
  ;; the log-in screen with F1.
  (packages (append (list
                     ;; window managers
                     ratpoison i3-wm i3status dmenu
                     emacs emacs-exwm emacs-desktop-environment
                     ;; terminal emulator
                     xterm
                     ;; for HTTPS access
                     nss-certs)
                    %base-packages))

  ;; Use the "desktop" services, which include the X11
  ;; log-in service, networking with NetworkManager, and more.
  (services %desktop-services)

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Dieses Beispiel bezieht sich auf das Dateisystem hinter /boot/efi über dessen UUID, 1234-ABCD. Schreiben Sie statt dieser UUID die richtige UUID für Ihr System, wie sie der Befehl blkid liefert.

Im Abschnitt Desktop-Dienste finden Sie eine genaue Liste der unter %desktop-services angebotenen Dienste. Der Abschnitt X.509-Zertifikate hat Hintergrundinformationen über das nss-certs-Paket, das hier benutzt wird.

Beachten Sie, dass %desktop-services nur eine Liste von die Dienste repräsentierenden service-Objekten ist. Wenn Sie Dienste daraus entfernen möchten, können Sie dazu die Prozeduren zum Filtern von Listen benutzen (siehe SRFI-1 Filtering and Partitioning in Referenzhandbuch zu GNU Guile). Beispielsweise liefert der folgende Ausdruck eine Liste mit allen Diensten von %desktop-services außer dem Avahi-Dienst.

(remove (lambda (service)
          (eq? (service-kind service) avahi-service-type))
        %desktop-services)

Das System instanziieren

Angenommen, Sie haben die operating-system-Deklaration in einer Datei my-system-config.scm gespeichert, dann instanziiert der Befehl guix system reconfigure my-system-config.scm diese Konfiguration und macht sie zum voreingestellten GRUB-Boot-Eintrag (siehe Aufruf von guix system).

Der normale Weg, die Systemkonfiguration nachträglich zu ändern, ist, die Datei zu aktualisieren und guix system reconfigure erneut auszuführen. Man sollte nie die Dateien in /etc bearbeiten oder den Systemzustand mit Befehlen wie useradd oder grub-install verändern. Tatsächlich müssen Sie das ausdrücklich vermeiden, sonst verfällt nicht nur Ihre Garantie, sondern Sie können Ihr System auch nicht mehr auf eine alte Version des Systems zurücksetzen, falls das jemals notwendig wird.

Zurücksetzen bezieht sich hierbei darauf, dass jedes Mal, wenn Sie guix system reconfigure ausführen, eine neue Generation des Systems erzeugt wird — ohne vorherige Generationen zu verändern. Alte Systemgenerationen bekommen einen Eintrag im Boot-Menü des Bootloaders, womit Sie alte Generationen beim Starten des Rechners auswählen können, wenn mit der neuesten Generation etwas nicht stimmt. Eine beruhigende Vorstellung, oder? Der Befehl guix system list-generations führt die auf der Platte verfügbaren Systemgenerationen auf. Es ist auch möglich, das System mit den Befehlen guix system roll-back und guix system switch-generation zurückzusetzen.

Obwohl der Befehl guix system reconfigure vorherige Generationen nicht verändern wird, müssen Sie Acht geben, dass wenn die momentan aktuelle Generation nicht die neueste ist (z.B. nach einem Aufruf von guix system roll-back), weil guix system reconfigure alle neueren Generationen überschreibt (siehe Aufruf von guix system).

Die Programmierschnittstelle

Auf der Ebene von Scheme wird der Großteil der operating-system-Deklaration mit der folgenden monadischen Prozedur instanziiert (siehe Die Store-Monade):

Monadische Prozedur: operating-system-derivation os

Liefert eine Ableitung, mit der ein operating-system-Objekt os erstellt wird (siehe Ableitungen).

Die Ausgabe der Ableitung ist ein einzelnes Verzeichnis mit Verweisen auf alle Pakete, Konfigurationsdateien und andere unterstützenden Dateien, die nötig sind, um os zu instanziieren.

Diese Prozedur wird vom Modul (gnu system) angeboten. Zusammen mit (gnu services) (siehe Dienste) deckt dieses Modul den Kern von „Guix System“ ab. Schauen Sie es sich mal an!


Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.2 operating-system-Referenz

Dieser Abschnitt fasst alle Optionen zusammen, die für operating-system-Deklarationen zur Verfügung stehen (siehe Das Konfigurationssystem nutzen).

Datentyp: operating-system

Der die Betriebssystemkonfiguration repräsentierende Datentyp. Damit meinen wir die globale Konfiguration des Systems und nicht die, die sich nur auf einzelne Nutzer bezieht (siehe Das Konfigurationssystem nutzen).

kernel (Vorgabe: linux-libre)

Das Paket für den zu nutzenden Betriebssystem-Kernel als „package“-Objekt24.

hurd (Vorgabe: #f)

Das Paketobjekt derjenigen Hurd, die der Kernel starten soll. Wenn dieses Feld gesetzt ist, wird ein GNU/Hurd-Betriebssystem erzeugt. In diesem Fall muss als kernel das gnumach-Paket (das ist der Microkernel, auf dem Hurd läuft) ausgewählt sein.

Warnung: Diese Funktionalität ist experimentell und wird nur für Disk-Images unterstützt.

kernel-loadable-modules (Vorgabe: ’())

Eine Liste von Objekten (normalerweise Pakete), aus denen Kernel-Module geladen werden können, zum Beispiel (list ddcci-driver-linux).

kernel-arguments (Vorgabe: %default-kernel-arguments)

Eine Liste aus Zeichenketten oder G-Ausdrücken, die für zusätzliche Argumente an den Kernel stehen, die ihm auf seiner Befehlszeile übergeben werden — wie z.B. ("console=ttyS0").

bootloader

Das Konfigurationsobjekt für den Bootloader, mit dem das System gestartet wird. Siehe Bootloader-Konfiguration.

label

Diese Bezeichnung (eine Zeichenkette) wird für den Menüeintrag im Bootloader verwendet. Die Vorgabe ist eine Bezeichnung, die den Namen des Kernels und seine Version enthält.

keyboard-layout (Vorgabe: #f)

Dieses Feld gibt an, welche Tastaturbelegung auf der Konsole benutzt werden soll. Es kann entweder auf #f gesetzt sein, damit die voreingestellte Tastaturbelegung benutzt wird (in der Regel ist diese „US English“), oder ein <keyboard-layout>-Verbundsobjekt sein.

Diese Tastaturbelegung wird benutzt, sobald der Kernel gebootet wurde. Diese Tastaturbelegung wird zum Beispiel auch verwendet, wenn Sie eine Passphrase eintippen, falls sich Ihr Wurzeldateisystem auf einem mit luks-device-mapping zugeordneten Gerät befindet (siehe Zugeordnete Geräte).

Anmerkung: Damit wird nicht angegeben, welche Tastaturbelegung der Bootloader benutzt, und auch nicht, welche der grafische Anzeigeserver verwendet. Siehe Bootloader-Konfiguration für Informationen darüber, wie Sie die Tastaturbelegung des Bootloaders angeben können. Siehe X Window für Informationen darüber, wie Sie die Tastaturbelegung angeben können, die das X-Fenstersystem verwendet.

initrd-modules (Vorgabe: %base-initrd-modules)

Die Liste der Linux-Kernel-Module, die in der initialen RAM-Disk zur Verfügung stehen sollen. Siehe Initiale RAM-Disk.

initrd (Vorgabe: base-initrd)

Eine Prozedur, die eine initiale RAM-Disk für den Linux-Kernel liefert. Dieses Feld gibt es, damit auch sehr systemnahe Anpassungen vorgenommen werden können, aber für die normale Nutzung sollten Sie es kaum brauchen. Siehe Initiale RAM-Disk.

firmware (Vorgabe: %base-firmware)

Eine Liste der Firmware-Pakete, die vom Betriebssystem-Kernel geladen werden können.

Vorgegeben ist, dass für Atheros- und Broadcom-basierte WLAN-Geräte nötige Firmware geladen werden kann (genauer jeweils die Linux-libre-Module ath9k und b43-open). Siehe den Abschnitt Hardware-Überlegungen für mehr Informationen zu unterstützter Hardware.

host-name

Der Hostname

hosts-file

Ein dateiartiges Objekt (siehe dateiartige Objekte), das für /etc/hosts benutzt werden soll (siehe Host Names in Referenzhandbuch der GNU-C-Bibliothek). Der Vorgabewert ist eine Datei mit Einträgen für localhost und host-name.

mapped-devices (Vorgabe: '())

Eine Liste zugeordneter Geräte („mapped devices“). Siehe Zugeordnete Geräte.

file-systems

Eine Liste von Dateisystemen. Siehe Dateisysteme.

swap-devices (Vorgabe: '())

Eine Liste von UUIDs, Dateisystembezeichnungen oder Zeichenketten, die als Swap-Speicher zu nutzende Geräte bzw. Dateien identifizieren (siehe Memory Concepts in Referenzhandbuch der GNU-C-Bibliothek). Hier sind einige Beispiele:

(list (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb"))

Die Swap-Partition mit der angegebenen UUID verwenden. Sie können die UUID einer Linux-Swap-Partition erfahren, indem Sie swaplabel Gerät ausführen, wobei Gerät der Dateiname unter /dev für die Partition ist.

(list (file-system-label "swap"))

Die Swap-Partition mit der Bezeichnung swap verwenden. Auch hier können Sie mittels swaplabel-Befehls die Bezeichnung einer Linux-Swap-Partition einsehen und ändern.

(list "/swapfile")

Die Datei /swapfile als Swap-Speicher benutzen.

(list "/dev/sda3" "/dev/sdb2")

Die Partitionen /dev/sda3 und /dev/sdb2 als Swap-Speicher benutzen. Wir raten davon ab und empfehlen, auf die Swap-Geräte stattdessen wie oben gezeigt über UUIDs oder über Bezeichnungen zu verweisen.

Es ist möglich, eine Swap-Datei auf einem Dateisystem eines zugeordneten Geräts anzugeben, sofern auch die Gerätezuordnung und das Dateisystem mit angegeben werden. Siehe Zugeordnete Geräte und Dateisysteme.

users (Vorgabe: %base-user-accounts)
groups (Vorgabe: %base-groups)

Liste der Benutzerkonten und Benutzergruppen. Siehe Benutzerkonten.

Wenn in der users-Liste kein Benutzerkonto mit der UID-Kennung 0 aufgeführt wird, wird automatisch für den Administrator ein „root“-Benutzerkonto mit UID-Kennung 0 hinzugefügt.

skeletons (Vorgabe: (default-skeletons))

Eine Liste von Tupeln aus je einem Ziel-Dateinamen und einem dateiähnlichen Objekt (siehe dateiartige Objekte). Diese Objekte werden als Skeleton-Dateien im Persönlichen Verzeichnis („Home“-Verzeichnis) jedes neuen Benutzerkontos angelegt.

Ein gültiger Wert könnte zum Beispiel so aussehen:

`((".bashrc" ,(plain-file "bashrc" "echo Hallo\n"))
  (".guile" ,(plain-file "guile"
                         "(use-modules (ice-9 readline))
                          (activate-readline)")))
issue (Vorgabe: %default-issue)

Eine Zeichenkette, die als Inhalt der Datei /etc/issue verwendet werden soll, der jedes Mal angezeigt wird, wenn sich ein Nutzer auf einer Textkonsole anmeldet.

packages (Vorgabe: %base-packages)

Eine Liste von Paketen, die ins globale Profil installiert werden sollen, welches unter /run/current-system/profile zu finden ist. Jedes Element ist entweder eine Paketvariable oder ein Tupel aus einem Paket und dessen gewünschter Ausgabe. Hier ist ein Beispiel:

(cons* git                     ; die Standardausgabe "out"
       (list git "send-email") ; eine andere Ausgabe von git
       %base-packages)         ; die normale Paketmenge

Die vorgegebene Paketmenge umfasst zum Kern des Systems gehörende Werkzeuge („core utilities“). Es ist empfehlenswert, nicht zum Kern gehörende Werkzeuge („non-core“) stattdessen in Nutzerprofile zu installieren (siehe Aufruf von guix package).

timezone

Eine Zeichenkette, die die Zeitzone bezeichnet, wie z.B. "Europe/Berlin".

Mit dem Befehl tzselect können Sie herausfinden, welche Zeichenkette der Zeitzone Ihrer Region entspricht. Wenn Sie eine ungültige Zeichenkette angeben, schlägt guix system fehl.

locale (Vorgabe: "en_US.utf8")

Der Name der als Voreinstellung zu verwendenden Locale (siehe Locale Names in Referenzhandbuch der GNU-C-Bibliothek). Siehe Locales für weitere Informationen.

locale-definitions (Vorgabe: %default-locale-definitions)

Die Liste der Locale-Definitionen, die kompiliert werden sollen und dann im laufenden System benutzt werden können. Siehe Locales.

locale-libcs (Vorgabe: (list glibc))

Die Liste der GNU-libc-Pakete, deren Locale-Daten und -Werkzeuge zum Erzeugen der Locale-Definitionen verwendet werden sollen. Siehe Locales für eine Erläuterung der Kompatibilitätsauswirkungen, deretwegen man diese Option benutzen wollen könnte.

name-service-switch (Vorgabe: %default-nss)

Die Konfiguration des Name Service Switch (NSS) der libc — ein <name-service-switch>-Objekt. Siehe Name Service Switch für Details.

services (Vorgabe: %base-services)

Eine Liste von „service“-Objekten, die die Systemdienste repräsentieren. Siehe Dienste.

essential-services (Vorgabe: …)

Die Liste „essenzieller Dienste“ — d.h. Dinge wie Instanzen von system-service-type und host-name-service-type (siehe Service-Referenz), die aus der Betriebssystemdefinition an sich abgeleitet werden. Als normaler Benutzer sollten Sie dieses Feld niemals ändern müssen.

pam-services (Vorgabe: (base-pam-services))

Dienste für Pluggable Authentication Modules (PAM) von Linux.

setuid-programs (Vorgabe: %setuid-programs)

Eine Liste von Zeichenketten liefernden G-Ausdrücken, die setuid-Programme bezeichnen. Siehe Setuid-Programme.

sudoers-file (Vorgabe: %sudoers-specification)

Der Inhalt der Datei /etc/sudoers als ein dateiähnliches Objekt (siehe local-file und plain-file).

Diese Datei gibt an, welche Nutzer den Befehl sudo benutzen dürfen, was sie damit tun und welche Berechtigungen sie so erhalten können. Die Vorgabe ist, dass nur der Administratornutzer root und Mitglieder der Benutzergruppe wheel den sudo-Befehl verwenden dürfen.

Scheme-Syntax: this-operating-system

Wenn dies im lexikalischen Geltungsbereich der Definition eines Feldes im Betriebssystem steht, bezieht sich dieser Bezeichner auf das Betriebssystem, das gerade definiert wird.

Das folgende Beispiel zeigt, wie man auf das Betriebssystem, das gerade definiert wird, verweist, während man die Definition des label-Felds schreibt:

(use-modules (gnu) (guix))

(operating-system
  ;; …
  (label (package-full-name
          (operating-system-kernel this-operating-system))))

Es ist ein Fehler, außerhalb einer Betriebssystemdefinition auf this-operating-system zu verweisen.


Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.3 Dateisysteme

Die Liste der Dateisysteme, die eingebunden werden sollen, steht im file-systems-Feld der Betriebssystemdeklaration (siehe Das Konfigurationssystem nutzen). Jedes Dateisystem wird mit der file-system-Form deklariert, etwa so:

(file-system
  (mount-point "/home")
  (device "/dev/sda3")
  (type "ext4"))

Wie immer müssen manche Felder angegeben werden — die, die im Beispiel oben stehen —, während andere optional sind. Die Felder werden nun beschrieben.

Datentyp: file-system

Objekte dieses Typs repräsentieren einzubindende Dateisysteme. Sie weisen folgende Komponenten auf:

type

Eine Zeichenkette, die den Typ des Dateisystems spezifiziert, z.B. "ext4".

mount-point

Der Einhängepunkt, d.h. der Pfad, an dem das Dateisystem eingebunden werden soll.

device

Hiermit wird die „Quelle“ des Dateisystems bezeichnet. Sie kann eines von drei Dingen sein: die Bezeichnung („Labels“) eines Dateisystems, die UUID-Kennung des Dateisystems oder der Name eines /dev-Knotens. Mit Bezeichnungen und UUIDs können Sie Dateisysteme benennen, ohne den Gerätenamen festzuschreiben25.

Dateisystem-Bezeichnungen („Labels“) werden mit der Prozedur file-system-label erzeugt und UUID-Kennungen werden mit uuid erzeugt, während Knoten in /dev mit ihrem Pfad als einfache Zeichenketten aufgeführt werden. Hier ist ein Beispiel, wie wir ein Dateisystem anhand seiner Bezeichnung aufführen, wie sie vom Befehl e2label angezeigt wird:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (file-system-label "my-home")))

UUID-Kennungen werden mit der uuid-Form von ihrer Darstellung als Zeichenkette (wie sie vom Befehl tune2fs -l angezeigt wird) konvertiert26 wie hier:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))

Wenn die Quelle eines Dateisystems ein zugeordnetes Gerät (siehe Zugeordnete Geräte) ist, muss sich das device-Feld auf den zugeordneten Gerätenamen beziehen — z.B. "/dev/mapper/root-partition". Das ist nötig, damit das System weiß, dass das Einbinden des Dateisystems davon abhängt, die entsprechende Gerätezuordnung hergestellt zu haben.

flags (Vorgabe: '())

Eine Liste von Symbolen, die Einbinde-Flags („mount flags“) bezeichnen. Erkannt werden unter anderem read-only, bind-mount, no-dev (Zugang zu besonderen Dateien verweigern), no-suid (setuid- und setgid-Bits ignorieren), no-atime (Dateizugriffs-Zeitstempel nicht aktualisieren), strict-atime (Dateizugriffs-Zeitstempel immer aktualisieren), lazy-time (Zeitstempel nur auf zwischengespeicherten Datei-Inodes im Arbeitsspeicher aktualisieren) und no-exec (Programmausführungen verweigern). Siehe Mount-Unmount-Remount in Referenzhandbuch der GNU-C-Bibliothek für mehr Informationen zu diesen Einbinde-Optionen.

options (Vorgabe: #f)

Entweder #f oder eine Zeichenkette mit Einbinde-Optionen („mount options“), die an den Dateisystemtreiber übergeben werden. Siehe Mount-Unmount-Remount in Referenzhandbuch der GNU-C-Bibliothek für Details; führen Sie man 8 mount aus, um die Einbinde-Optionen verschiedener Dateisysteme zu sehen. Beachten Sie, dass die Prozeduren file-system-options->alist und alist->file-system-options aus (gnu system file-systems) benutzt werden können, um als assoziative Liste dargestellte Dateisystemoptionen in eine Darstellung als Zeichenkette umzuwandeln und umgekehrt.

mount? (Vorgabe: #t)

Dieser Wert zeigt an, ob das Dateisystem automatisch eingebunden werden soll, wenn das System gestartet wird. Ist der Wert #f, dann erhält das Dateisystem nur einen Eintrag in der Datei /etc/fstab (welche vom mount-Befehl zum Einbinden gelesen wird), es wird aber nicht automatisch eingebunden.

needed-for-boot? (Vorgabe: #f)

Dieser boolesche Wert gibt an, ob das Dateisystem zum Hochfahren des Systems notwendig ist. In diesem Fall wird das Dateisystem eingebunden, wenn die initiale RAM-Disk (initrd) geladen wird. Für zum Beispiel das Wurzeldateisystem ist dies ohnehin immer der Fall.

check? (Vorgabe: #t)

Dieser boolesche Wert sagt aus, ob das Dateisystem vor dem Einbinden auf Fehler hin geprüft werden soll.

create-mount-point? (Vorgabe: #f)

Steht dies auf wahr, wird der Einhängepunkt vor dem Einbinden erstellt, wenn er noch nicht existiert.

mount-may-fail? (Vorgabe: #f)

Wenn dies auf wahr steht, bedeutet es, dass das Einbinden dieses Dateisystems scheitern kann, dies aber nicht als Fehler aufgefasst werden soll. Das braucht man in besonderen Fällen, zum Beispiel wird es für efivarfs benutzt, einem Dateisystem, das nur auf EFI-/UEFI-Systemen eingebunden werden kann.

dependencies (Vorgabe: '())

Dies ist eine Liste von <file-system>- oder <mapped-device>-Objekten, die Dateisysteme repräsentieren, die vor diesem Dateisystem eingebunden oder zugeordnet werden müssen (und nach diesem ausgehängt oder geschlossen werden müssen).

Betrachten Sie zum Beispiel eine Hierarchie von Einbindungen: /sys/fs/cgroup ist eine Abhängigkeit von /sys/fs/cgroup/cpu und /sys/fs/cgroup/memory.

Ein weiteres Beispiel ist ein Dateisystem, was von einem zugeordneten Gerät abhängt, zum Beispiel zur Verschlüsselung einer Partition (siehe Zugeordnete Geräte).

Scheme-Prozedur: file-system-label Zeichenkette

Diese Prozedur kapselt die Zeichenkette in einer opaken Dateisystembezeichnung:

(file-system-label "home")
 #<file-system-label "home">

Mit Dateisystembezeichnungen werden Dateisysteme anhand ihrer Bezeichnung („Label“) statt ihres Gerätenamens („Device Name“) identifiziert. Siehe die Beispiele oben.

Das Modul (gnu system file-systems) exportiert die folgenden nützlichen Variablen.

Scheme-Variable: %base-file-systems

Hiermit werden essenzielle Dateisysteme bezeichnet, die für normale Systeme unverzichtbar sind, wie zum Beispiel %pseudo-terminal-file-system und %immutable-store (siehe unten). Betriebssystemdeklaration sollten auf jeden Fall mindestens diese enthalten.

Scheme-Variable: %pseudo-terminal-file-system

Das als /dev/pts einzubindende Dateisystem. Es unterstützt über openpty und ähnliche Funktionen erstellte Pseudo-Terminals (siehe Pseudo-Terminals in Referenzhandbuch der GNU-C-Bibliothek). Pseudo-Terminals werden von Terminal-Emulatoren wie xterm benutzt.

Scheme-Variable: %shared-memory-file-system

Dieses Dateisystem wird als /dev/shm eingebunden, um Speicher zwischen Prozessen teilen zu können (siehe shm_open in Referenzhandbuch der GNU-C-Bibliothek).

Scheme-Variable: %immutable-store

Dieses Dateisystem vollzieht einen „bind mount“ des /gnu/store, um ihn für alle Nutzer einschließlich des Administratornutzers root nur lesbar zu machen, d.h. Schreibrechte zu entziehen. Dadurch kann als root ausgeführte Software, oder der Systemadministrator, nicht aus Versehen den Store modifizieren.

Der Daemon kann weiterhin in den Store schreiben, indem er ihn selbst mit Schreibrechten in seinem eigenen „Namensraum“ einbindet.

Scheme-Variable: %binary-format-file-system

Das binfmt_misc-Dateisystem, durch das beliebige Dateitypen als ausführbare Dateien auf der Anwendungsebene (dem User Space) zugänglich gemacht werden können. Es setzt voraus, dass das Kernel-Modul binfmt.ko geladen wurde.

Scheme-Variable: %fuse-control-file-system

Das fusectl-Dateisystem, womit „unprivilegierte“ Nutzer ohne besondere Berechtigungen im User Space FUSE-Dateisysteme einbinden und aushängen können. Dazu muss das Kernel-Modul fuse.ko geladen sein.

Das Modul (gnu system uuid) stellt Werkzeug zur Verfügung, um mit eindeutigen Identifikatoren für Dateisysteme umzugehen (sogenannten „Unique Identifiers“, UUIDs).

Scheme-Prozedur: uuid Zeichenkette [Typ]

Liefert eine eindeutige UUID (Unique Identifier) als opakes Objekt des angegebenen Typs (ein Symbol), indem die Zeichenkette verarbeitet wird:

(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")
 #<<uuid> type: dce bv: …>

(uuid "1234-ABCD" 'fat)
 #<<uuid> type: fat bv: …>

Als Typ kann entweder dce, iso9660, fat, ntfs oder eines der üblichen Synonyme dafür angegeben werden.

UUIDs bieten eine andere Möglichkeit, sich in der Betriebssystemkonfiguration ohne Mehrdeutigkeiten auf eines der Dateisysteme zu beziehen. Siehe die Beispiele oben.


Nach oben: Dateisysteme   [Inhalt][Index]

10.3.1 Btrfs-Dateisystem

Das Btrfs-Dateisystem bietet besondere Funktionalitäten, wie z.B. Unterlaufwerke („Subvolumes“), die eine detailliertere Erklärung verdienen. Im folgenden Abschnitt wird versucht, grundlegende sowie komplexe Anwendungsmöglichkeiten eines Btrfs-Dateisystem für Guix System abzudecken.

Im einfachsten Fall kann ein Btrfs-Dateisystem durch einen Ausdruck wie hier beschrieben werden:

(file-system
  (mount-point "/home")
  (type "btrfs")
  (device (file-system-label "my-home")))

Nun folgt ein komplexeres Beispiel, bei dem ein Btrfs-Unterlaufwerk namens rootfs benutzt wird. Dessen Eltern-Btrfs-Dateisystem wird mit my-btrfs-pool bezeichnet und befindet sich auf einem verschlüsselten Gerät (daher die Abhängigkeit von mapped-devices):

(file-system
  (device (file-system-label "my-btrfs-pool"))
  (mount-point "/")
  (type "btrfs")
  (options "subvol=rootfs")
  (dependencies mapped-devices))

Manche Bootloader, wie zum Beispiel GRUB, binden von einer Btrfs-Partition zuerst beim frühen Boot („early boot“) nur die oberste Ebene ein und verlassen sich darauf, dass ihre Konfiguration den korrekten Pfad samt Unterlaufwerk innerhalb dieser obersten Ebene enthält. Auf diese Weise arbeitende Bootloader erzeugen ihre Konfiguration normalerweise auf einem laufenden System, auf dem die Btrfs-Partitionen bereits eingebunden sind und die Informationen über die Unterlaufwerke zur Verfügung stehen. Zum Beispiel liest grub-mkconfig, der bei GRUB mitgelieferte Befehl zur Erzeugung von Konfigurationsdateien, aus /proc/self/mountinfo, um festzustellen, was auf oberster Ebene der Pfad zum Unterlaufwerk ist.

Guix System hingegen erzeugt eine Bootloader-Konfiguration mit der Betriebssystemkonfiguration als einzige Eingabe. Daher muss der Name des Unterlaufwerks, auf dem sich /gnu/store befindet (falls Sie eines benutzen) aus derselben Betriebssystemkonfiguration kommen. Um das besser zu veranschaulichen, betrachten Sie ein Unterlaufwerk namens „rootfs“, das die Daten des Wurzeldateisystems speichert. In einer solchen Situation würde der GRUB-Bootloader nur die oberste Ebene der Wurzel-Btrfs-Partition sehen, z.B.:

/                   (oberste Ebene)
├── rootfs          (Unterlaufwerk als Verzeichnis)
    ├── gnu         (normales Verzeichnis)
        ├── store   (normales Verzeichnis)
[…]

Deswegen muss der Name des Unterlaufwerks dem /gnu/store-Pfad des Kernels, der initrd und jeder anderen Datei vorangestellt werden, die die GRUB-Konfiguration referenziert und während des frühen Boots gefunden werden können muss.

Das nächste Beispiel zeigt eine verschachtelte Hierarchie aus Unterlaufwerken und Verzeichnissen:

/                   (oberste Ebene)
├── rootfs          (Unterlaufwerk)
    ├── gnu         (normales Verzeichnis)
        ├── store   (Unterlaufwerk)
[…]

Dieses Szenario würde ohne Einbinden des „store“-Unterlaufwerks funktionieren. „rootfs“ genügt, weil der Name des Unterlaufwerks dem dafür vorgesehenen Einhängepunkt in der Dateisystemhierarchie entspricht. Alternativ könnte man das „store“-Unterlaufwerk durch Festlegen der subvol-Option auf entweder /rootfs/gnu/store oder rootfs/gnu/store verwenden.

Abschließend folgt ein ausgeklügelteres Beispiel verschachtelter Unterlaufwerke:

/                           (oberste Ebene)
├── root-snapshots          (Unterlaufwerk)
    ├── root-current        (Unterlaufwerk)
        ├── guix-store      (Unterlaufwerk)
[…]

Hier stimmt das „guix-store“-Unterlaufwerk nicht mit dem vorgesehenen Einhängepunkt überein, daher muss es eingebunden werden. Das Unterlaufwerk muss vollständig spezifiziert werden, indem sein Dateiname an die subvol-Option übergeben wird. Eine Möglichkeit wäre, das „guix-store“-Unterlaufwerk als /gnu/store über eine solche Dateisystemdeklaration einzubinden:

(file-system
  (device (file-system-label "btrfs-pool-1"))
  (mount-point "/gnu/store")
  (type "btrfs")
  (options "subvol=root-snapshots/root-current/guix-store,\
compress-force=zstd,space_cache=v2"))

Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.4 Zugeordnete Geräte

Der Linux-Kernel unterstützt das Konzept der Gerätezuordnung: Ein blockorientiertes Gerät wie eine Festplattenpartition kann einem neuen Gerät zugeordnet werden, gewöhnlich unter /dev/mapper/, wobei das neue Gerät durchlaufende Daten zusätzlicher Verarbeitung unterzogen werden27. Ein typisches Beispiel ist eine Gerätezuordnung zur Verschlüsselung: Jeder Schreibzugriff auf das zugeordnete Gerät wird transparent verschlüsselt und jeder Lesezugriff ebenso entschlüsselt. Guix erweitert dieses Konzept, indem es darunter jedes Gerät und jede Menge von Geräten versteht, die auf irgendeine Weise umgewandelt wird, um ein neues Gerät zu bilden; zum Beispiel entstehen auch RAID-Geräte aus einem Verbund mehrerer anderer Geräte, wie etwa Festplatten oder Partition zu einem einzelnen Gerät, das sich wie eine Partition verhält. Ein weiteres Beispiel, das noch nicht in Guix implementiert wurde, sind „LVM logical volumes“.

Zugeordnete Geräte werden mittels einer mapped-device-Form deklariert, die wie folgt definiert ist; Beispiele folgen weiter unten.

Datentyp: mapped-device

Objekte dieses Typs repräsentieren Gerätezuordnungen, die gemacht werden, wenn das System hochfährt.

source

Es handelt sich entweder um eine Zeichenkette, die den Namen eines zuzuordnenden blockorientierten Geräts angibt, wie "/dev/sda3", oder um eine Liste solcher Zeichenketten, sofern mehrere Geräts zu einem neuen Gerät verbunden werden.

target

Diese Zeichenkette gibt den Namen des neuen zugeordneten Geräts an. Bei Kernel-Zuordnern, wie verschlüsselten Geräten vom Typ luks-device-mapping, wird durch Angabe von "my-partition" ein Gerät "/dev/mapper/my-partition" erzeugt. Bei RAID-Geräten vom Typ raid-device-mapping muss der Gerätename als voller Pfad wie zum Beispiel "/dev/md0" angegeben werden.

type

Dies muss ein mapped-device-kind-Objekt sein, das angibt, wie die Quelle source dem Ziel target zugeordnet wird.

Scheme-Variable: luks-device-mapping

Hiermit wird ein blockorientiertes Gerät mit LUKS verschlüsselt, mit Hilfe des Befehls cryptsetup aus dem gleichnamigen Paket. Dazu wird das Linux-Kernel-Modul dm-crypt vorausgesetzt.

Scheme-Variable: raid-device-mapping

Dies definiert ein RAID-Gerät, das mit dem Befehl mdadm aus dem gleichnamigen Paket als Verbund zusammengestellt wird. Es setzt voraus, dass das Linux-Kernel-Modul für das entsprechende RAID-Level geladen ist, z.B. raid456 für RAID-4, RAID-5 oder RAID-6, oder raid10 für RAID-10.

Das folgende Beispiel gibt eine Zuordnung von /dev/sda3 auf /dev/mapper/home mit LUKS an — dem Linux Unified Key Setup, einem Standardmechanismus zur Plattenverschlüsselung. Das Gerät /dev/mapper/home kann dann als device einer file-system-Deklaration benutzt werden (siehe Dateisysteme).

(mapped-device
  (source "/dev/sda3")
  (target "home")
  (type luks-device-mapping))

Um nicht davon abhängig zu sein, wie Ihre Geräte nummeriert werden, können Sie auch die LUKS-UUID (unique identifier, d.h. den eindeutigen Bezeichner) des Quellgeräts auf der Befehlszeile ermitteln:

cryptsetup luksUUID /dev/sda3

und wie folgt benutzen:

(mapped-device
  (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
  (target "home")
  (type luks-device-mapping))

Es ist auch wünschenswert, Swap-Speicher zu verschlüsseln, da in den Swap-Speicher sensible Daten ausgelagert werden können. Eine Möglichkeit ist, eine Swap-Datei auf einem mit LUKS-Verschlüsselung zugeordneten Dateisystem zu verwenden. Dann wird die Swap-Datei verschlüsselt, weil das ganze Gerät verschlüsselt wird. Ein Beispiel finden Sie im Abschnitt Disk Partitioning.

Ein RAID-Gerät als Verbund der Partitionen /dev/sda1 und /dev/sdb1 kann wie folgt deklariert werden:

(mapped-device
  (source (list "/dev/sda1" "/dev/sdb1"))
  (target "/dev/md0")
  (type raid-device-mapping))

Das Gerät /dev/md0 kann als device in einer file-system-Deklaration dienen (siehe Dateisysteme). Beachten Sie, dass das RAID-Level dabei nicht angegeben werden muss; es wird während der initialen Erstellung und Formatierung des RAID-Geräts festgelegt und später automatisch bestimmt.


Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.5 Benutzerkonten

Benutzerkonten und Gruppen werden allein durch die operating-system-Deklaration des Betriebssystems verwaltet. Sie werden mit den user-account- und user-group-Formen angegeben:

(user-account
  (name "alice")
  (group "users")
  (supplementary-groups '("wheel"   ;zur sudo-Nutzung usw. berechtigen
                          "audio"   ;Soundkarte
                          "video"   ;Videogeräte wie Webcams
                          "cdrom")) ;die gute alte CD-ROM
  (comment "Bobs Schwester"))

Hier sehen Sie ein Benutzerkonto, das eine andere Shell und ein geändertes Persönliches Verzeichnis benutzt (die Vorgabe wäre "/home/bob"):

(user-account
  (name "bob")
  (group "users")
  (comment "Alices Bruder")
  (shell (file-append zsh "/bin/zsh"))
  (home-directory "/home/robert"))

Beim Hochfahren oder nach Abschluss von guix system reconfigure stellt das System sicher, dass nur die in der operating-system-Deklaration angegebenen Benutzerkonten und Gruppen existieren, mit genau den angegebenen Eigenschaften. Daher gehen durch direkten Aufruf von Befehlen wie useradd erwirkte Erstellungen oder Modifikationen von Konten oder Gruppen verloren, sobald rekonfiguriert oder neugestartet wird. So wird sichergestellt, dass das System genau so funktioniert, wie es deklariert wurde.

Datentyp: user-account

Objekte dieses Typs repräsentieren Benutzerkonten. Darin können folgende Komponenten aufgeführt werden:

name

Der Name des Benutzerkontos.

group

Dies ist der Name (als Zeichenkette) oder die Bezeichnung (als Zahl) der Benutzergruppe, zu der dieses Konto gehört.

supplementary-groups (Vorgabe: '())

Dies kann optional als Liste von Gruppennamen angegeben werden, zu denen dieses Konto auch gehört.

uid (Vorgabe: #f)

Dies ist entweder der Benutzeridentifikator dieses Kontos (seine „User ID“) als Zahl oder #f. Bei Letzterem wird vom System automatisch eine Zahl gewählt, wenn das Benutzerkonto erstellt wird.

comment (Vorgabe: "")

Ein Kommentar zu dem Konto, wie etwa der vollständige Name des Kontoinhabers.

home-directory

Der Name des Persönlichen Verzeichnisses („Home“-Verzeichnis) für dieses Konto.

create-home-directory? (Vorgabe: #t)

Zeigt an, ob das Persönliche Verzeichnis für das Konto automatisch erstellt werden soll, falls es noch nicht existiert.

shell (Vorgabe: Bash)

Ein G-Ausdruck, der den Dateinamen des Programms angibt, das dem Benutzer als Shell dienen soll (siehe G-Ausdrücke). Auf die Programmdatei der Bash-Shell würden Sie zum Beispiel so verweisen:

(file-append bash "/bin/bash")

… und so auf die Programmdatei von Zsh:

(file-append zsh "/bin/zsh")
system? (Vorgabe: #f)

Dieser boolesche Wert zeigt an, ob das Konto ein „System“-Benutzerkonto ist. Systemkonten werden manchmal anders behandelt, zum Beispiel werden sie auf grafischen Anmeldebildschirmen nicht aufgeführt.

password (Vorgabe: #f)

Normalerweise lassen Sie dieses Feld auf #f und initialisieren Benutzerpasswörter als root mit dem passwd-Befehl. Die Benutzer lässt man ihr eigenes Passwort dann mit passwd ändern. Mit passwd festgelegte Passwörter bleiben natürlich beim Neustarten und beim Rekonfigurieren erhalten.

Wenn Sie aber doch ein anfängliches Passwort für ein Konto voreinstellen möchten, muss dieses Feld hier das verschlüsselte Passwort als Zeichenkette enthalten. Sie können dazu die Prozedur crypt benutzen.

(user-account
  (name "charlie")
  (group "users")

  ;; Ein mit SHA-512 gehashtes initiales Passwort.
  (password (crypt "InitialPassword!" "$6$abc")))

Anmerkung: Der Hash dieses initialen Passworts wird in einer Datei im /gnu/store abgelegt, auf die alle Benutzer Lesezugriff haben, daher ist Vorsicht geboten, wenn Sie diese Methode verwenden.

Siehe Passphrase Storage in Referenzhandbuch der GNU-C-Bibliothek für weitere Informationen über Passwortverschlüsselung und Encryption in Referenzhandbuch zu GNU Guile für Informationen über die Prozedur crypt in Guile.

Benutzergruppen-Deklarationen sind noch einfacher aufgebaut:

(user-group (name "students"))
Datentyp: user-group

Dieser Typ gibt, nun ja, eine Benutzergruppe an. Es gibt darin nur ein paar Felder:

name

Der Name der Gruppe.

id (Vorgabe: #f)

Der Gruppenbezeichner (eine Zahl). Wird er als #f angegeben, wird automatisch eine neue Zahl reserviert, wenn die Gruppe erstellt wird.

system? (Vorgabe: #f)

Dieser boolesche Wert gibt an, ob es sich um eine „System“-Gruppe handelt. Systemgruppen sind solche mit einer kleinen Zahl als Bezeichner.

password (Vorgabe: #f)

Wie, Benutzergruppen können ein Passwort haben? Nun ja, anscheinend schon. Wenn es nicht auf #f steht, gibt dieses Feld das Passwort der Gruppe an.

Um Ihnen das Leben zu erleichtern, gibt es eine Variable, worin alle grundlegenden Benutzergruppen aufgeführt sind, die man erwarten könnte:

Scheme-Variable: %base-groups

Die Liste von Basis-Benutzergruppen, von denen Benutzer und/oder Pakete erwarten könnten, dass sie auf dem System existieren. Dazu gehören Gruppen wie „root“, „wheel“ und „users“, sowie Gruppen, um den Zugriff auf bestimmte Geräte einzuschränken, wie „audio“, „disk“ und „cdrom“.

Scheme-Variable: %base-user-accounts

Diese Liste enthält Basis-Systembenutzerkonten, von denen Programme erwarten können, dass sie auf einem GNU/Linux-System existieren, wie das Konto „nobody“.

Beachten Sie, dass das Konto „root“ für den Administratornutzer nicht dazugehört. Es ist ein Sonderfall und wird automatisch erzeugt, egal ob es spezifiziert wurde oder nicht.


Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.6 Tastaturbelegung

Um anzugeben, was jede Taste auf Ihrer Tastatur tut, müssen Sie angeben, welche Tastaturbelegung das Betriebssystem benutzen soll. Wenn nichts angegeben wird, ist die „US English“-QWERTY-Tastaturbelegung für PC-Tastaturen mit 105 Tasten voreingestellt. Allerdings bevorzugen Deutsch sprechende Nutzer meistens die deutsche QWERTZ-Tastaturbelegung, Französisch sprechende haben lieber die AZERTY-Belegung und so weiter; Hacker wollen vielleicht Dvorak oder Bépo als Tastaturbelegung benutzen oder sogar eigene Anpassungen bei manchen Tasten vornehmen. Dieser Abschnitt erklärt, wie das geht.

Die Informationen über Ihre Tastaturbelegung werden an drei Stellen gebraucht:

Mit Guix können Sie alle drei Komponenten separat konfigurieren, aber zum Glück können Sie damit auch dieselbe Konfiguration der Tastaturbelegung für alle drei benutzen.

Tastaturbelegungen werden durch Verbundsobjekte repräsentiert, die mit der Prozedur keyboard-layout aus dem Modul (gnu system keyboard) angelegt werden. Entsprechend der „X-Keyboard“-Erweiterung (XKB) verfügt jede Tastaturbelegung über vier Attribute: einen Namen (oft ist das ein Sprachkürzel wie „fi“ für Finnisch oder „jp“ für Japanisch), ein optionaler Variantenname, ein optionaler Tastaturmodellname und eine möglicherweise leere Liste zusätzlicher Optionen. In den meisten Fällen interessiert Sie nur der Name der Tastaturbelegung.

Scheme-Prozedur: keyboard-layout Name [Variante] [#:model] [#:options '()] Liefert eine neue Tastaturbelegung mit dem

angegebenen Namen in der Variante.

Der Name muss eine Zeichenkette wie "fr" sein und die Variante eine Zeichenkette wie "bepo" oder "nodeadkeys". Siehe das Paket xkeyboard-config für Informationen, welche Optionen gültig sind.

Hier sind ein paar Beispiele:

;; Die deutsche QWERTZ-Belegung. Hierbei nehmen wir
;; ein Standard-"pc105"-Tastaturmodell an.
(keyboard-layout "de")

;; Die Bépo-Variante der französischen Belegung.
(keyboard-layout "fr" "bepo")

;; Die katalanische Tastaturbelegung.
(keyboard-layout "es" "cat")

;; Arabische Tastaturbelegung. "Alt-Umschalt" wechselt auf US-Amerikanisch.
(keyboard-layout "ar,us" #:options '("grp:alt_shift_toggle"))

;; Die lateinamerikanisch-spanische Tastaturbelegung. Des Weiteren
;; wird die Feststelltaste (auf Englisch "Caps Lock") als eine
;; weitere Steuerungstaste (auf Englisch "Ctrl") festgelegt und
;; die Menütaste soll als eine "Compose"-Taste herhalten, mit der
;; Buchstaben mit Diakritika geschrieben werden können.
(keyboard-layout "latam"
                 #:options '("ctrl:nocaps" "compose:menu"))

;; Die russische Tastaturbelegung für eine ThinkPad-Tastatur.
(keyboard-layout "ru" #:model "thinkpad")

;; Die Tastaturbelegung "US international", d.h. die US-Belegung
;; mit Tottasten zur Eingabe von Buchstaben mit Diakritika. Hier
;; wird die Belegung für eine Apple-MacBook-Tastatur gewählt.
(keyboard-layout "us" "intl" #:model "macbook78")

Im Verzeichnis share/X11/xkb des xkeyboard-config-Pakets finden Sie eine vollständige Liste der unterstützten Tastaturbelegungen, Varianten und Modelle.

Sagen wir, Sie würden gerne die türkische Tastaturbelegung für Ihr gesamtes System — Bootloader, Konsole und Xorg — verwenden. Dann würde Ihre Systemkonfiguration so aussehen:

;; Die türkische Tastaturbelegung für Bootloader, Konsole und Xorg
;; benutzen.

(operating-system
  ;; …
  (keyboard-layout (keyboard-layout "tr"))  ;für die Konsole
  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (target "/boot/efi")
                (keyboard-layout keyboard-layout))) ;für GRUB
  (services (cons (set-xorg-configuration
                    (xorg-configuration             ;für Xorg
                      (keyboard-layout keyboard-layout)))
                  %desktop-services)))

Im obigen Beispiel beziehen wir uns für GRUB und Xorg einfach auf das keyboard-layout-Feld, was wir darüber definiert haben, wir könnten aber auch eine andere Tastaturbelegung angeben. Die Prozedur set-xorg-configuration kommuniziert an die grafische Anmeldeverwaltung (d.h. nach Vorgabe an GDM), welche Xorg-Konfiguration verwendet werden soll.

Wir haben uns bisher damit auseinandergesetzt, wie die Voreinstellung für die Tastaturbelegung ausgewählt werden kann, die das System annimmt, wenn es startet, aber zur Laufzeit kann sie geändert werden:


Nächste: , Vorige: , Nach oben: Systemkonfiguration   [Inhalt][Index]

10.7 Locales

Eine Locale legt die kulturellen Konventionen einer bestimmten Sprache und Region auf der Welt fest (siehe Locales in Referenzhandbuch der GNU-C-Bibliothek). Jede Locale hat einen Namen, der typischerweise von der Form Sprache_Gebiet.Kodierung — z.B. benennt fr_LU.utf8 die Locale für französische Sprache mit den kulturellen Konventionen aus Luxemburg unter Verwendung der UTF-8-Kodierung.

Normalerweise werden Sie eine standardmäßig zu verwendende Locale für die Maschine vorgeben wollen, indem Sie das locale-Feld der operating-system-Deklaration verwenden (siehe locale).

Die ausgewählte Locale wird automatisch zu den dem System bekannten Locale-Definitionen hinzugefügt, falls nötig, und ihre Kodierung wird aus dem Namen hergeleitet — z.B. wird angenommen, dass bo_CN.utf8 als Kodierung UTF-8 verwendet. Zusätzliche Locale-Definitionen können im Feld locale-definitions vom operating-system festgelegt werden — das ist zum Beispiel dann nützlich, wenn die Kodierung nicht aus dem Locale-Namen hergeleitet werden konnte. Die vorgegebene Menge an Locale-Definitionen enthält manche weit verbreiteten Locales, aber um Platz zu sparen, nicht alle verfügbaren Locales.

Um zum Beispiel die nordfriesische Locale für Deutschland hinzuzufügen, könnte der Wert des Feldes wie folgt aussehen:

(cons (locale-definition
        (name "fy_DE.utf8") (source "fy_DE"))
      %default-locale-definitions)

Um Platz zu sparen, könnte man auch wollen, dass locale-definitions nur die tatsächlich benutzen Locales aufführt, wie etwa:

(list (locale-definition
        (name "ja_JP.eucjp") (