Nächste: Einführung, Nach oben: (dir) [Inhalt][Index]
Dieses Dokument beschreibt GNU Guix, Version 123b722, 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), auf Brasilianischem Portugiesisch (siehe Manual de referência do GNU Guix) und auf Russisch verfügbar (siehe Руководство GNU Guix). Wenn Sie es in Ihre eigene Sprache übersetzen möchten, dann sind Sie bei Weblate herzlich willkommen (siehe Guix übersetzen).
guix repl
aufrufenguix build
guix edit
aufrufenguix download
aufrufenguix hash
aufrufenguix import
aufrufenguix refresh
aufrufenguix style
aufrufenguix lint
aufrufenguix size
aufrufenguix graph
aufrufenguix publish
aufrufenguix challenge
aufrufenguix copy
aufrufenguix container
aufrufenguix weather
aufrufenguix processes
aufrufenoperating-system
-Referenzguix system
aufrufenguix deploy
aufrufenguix home
aufrufenNächste: Installation, Vorige: GNU Guix, Nach oben: GNU Guix [Inhalt][Index]
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: GNU-Distribution, Nach oben: Einführung [Inhalt][Index]
Guix bietet eine befehlszeilenbasierte Paketverwaltungsschnittstelle (siehe
guix package
aufrufen), Werkzeuge als Hilfestellung bei der
Software-Entwicklung (siehe Entwicklung), Befehlszeilenwerkzeuge für
fortgeschrittenere Nutzung (siehe Zubehör) sowie Schnittstellen zur
Programmierung in Scheme (siehe Programmierschnittstelle).
Der Erstellungs-Daemon ist für das Erstellen von Paketen im Auftrag
von Nutzern verantwortlich (siehe Den Daemon einrichten) und für das
Herunterladen vorerstellter Binärdateien aus autorisierten Quellen (siehe
Substitute).
Guix enthält Paketdefinitionen für viele Pakete, manche aus GNU und andere nicht aus GNU, die alle die Freiheit des Computernutzers respektieren. Es ist erweiterbar: Nutzer können ihre eigenen Paketdefinitionen schreiben (siehe Pakete definieren) und sie als unabhängige Paketmodule verfügbar machen (siehe Paketmodule). Es ist auch anpassbar: Nutzer können spezialisierte Paketdefinitionen aus bestehenden ableiten, auch von der Befehlszeile (siehe Paketumwandlungsoptionen).
Intern implementiert Guix die Disziplin der funktionalen Paketverwaltung, zu der Nix schon die Pionierarbeit geleistet hat (siehe Danksagungen). In Guix wird der Prozess, ein Paket zu erstellen und zu installieren, als eine Funktion im mathematischen Sinn aufgefasst. Diese Funktion hat Eingaben, wie zum Beispiel Erstellungs-Skripts, einen Compiler und Bibliotheken, und liefert ein installiertes Paket. Als eine reine Funktion hängt sein Ergebnis allein von seinen Eingaben ab – zum Beispiel kann er nicht auf Software oder Skripts Bezug nehmen, die nicht ausdrücklich als Eingaben übergeben wurden. Eine Erstellungsfunktion führt immer zum selben Ergebnis, wenn ihr die gleiche Menge an Eingaben übergeben wurde. Sie kann die Umgebung des laufenden Systems auf keine Weise beeinflussen, zum Beispiel kann sie keine Dateien außerhalb ihrer Erstellungs- und Installationsverzeichnisse verändern. Um dies zu erreichen, laufen Erstellungsprozesse in isolierten Umgebungen (sogenannte Container), wo nur ausdrückliche Eingaben sichtbar sind.
Das Ergebnis von Paketerstellungsfunktionen wird im Dateisystem zwischengespeichert in einem besonderen Verzeichnis, was als der Store bezeichnet wird (siehe Der Store). Jedes Paket wird in sein eigenes Verzeichnis im Store installiert – standardmäßig ist er unter /gnu/store zu finden. Der Verzeichnisname enthält einen Hash aller Eingaben, anhand derer das Paket erzeugt wurde, somit hat das Ändern einer Eingabe einen völlig anderen Verzeichnisnamen zur Folge.
Dieses Vorgehen ist die Grundlage für die Guix auszeichnenden Funktionalitäten: Unterstützung transaktionsbasierter Paketaktualisierungen und -rücksetzungen, Installation von Paketen für jeden Nutzer sowie Garbage Collection für Pakete (siehe Funktionalitäten).
Vorige: Auf Guix-Art Software verwalten, Nach oben: Einführung [Inhalt][Index]
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
guix package
aufrufen):
guix package --list-available
Unser Ziel ist, eine zu 100% freie Software-Distribution von Linux-basierten und von anderen GNU-Varianten anzubieten, mit dem Fokus darauf, das GNU-Projekt und die enge Zusammenarbeit seiner Bestandteile zu befördern, sowie die Programme und Werkzeuge hervorzuheben, die die Nutzer dabei unterstützen, von dieser Freiheit Gebrauch zu machen.
Pakete sind zurzeit auf folgenden Plattformen verfügbar:
x86_64-linux
Intel/AMD-x86_64
-Architektur, Linux-Libre als Kernel.
i686-linux
Intel-32-Bit-Architektur (IA-32), Linux-Libre als Kernel.
armhf-linux
ARMv7-A-Architektur mit „hard float“, Thumb-2 und NEON, für die EABI „hard-float application binary interface“, mit Linux-Libre als Kernel.
aarch64-linux
64-Bit-ARMv8-A-Prozessoren, little-endian, mit Linux-Libre als Kernel.
i586-gnu
GNU/Hurd auf der Intel-32-Bit-Architektur (IA32).
Diese Konfiguration ist experimentell und befindet sich noch in der
Entwicklung. Wenn Sie sie ausprobieren möchten, ist es am einfachsten, eine
Instanz des Diensttyps hurd-vm-service-type
auf Ihrer
GNU/Linux-Maschine einzurichten (siehe hurd-vm-service-type
). Siehe auch Mitwirken für
Informationen, wie Sie helfen können!
mips64el-linux (eingeschränkte Unterstützung)
64-Bit-MIPS-Prozessoren, little-endian, speziell die Loongson-Reihe, n32-ABI, mit Linux-Libre als Kernel. Diese Konfiguration wird nicht länger in vollem Umfang unterstützt; insbesondere gibt es keine laufenden Bemühungen, die Funktionsfähigkeit dieser Architektur sicherzustellen. Wenn sich jemand findet, der diese Architektur wiederbeleben will, dann ist der Code dafür noch verfügbar.
powerpc-linux (eingeschränkte Unterstützung)
32-Bit-PowerPC-Prozessoren, big-endian, speziell der PowerPC G4 mit AltiVec, mit Linux-Libre als Kernel. Diese Konfiguration wird nicht in vollem Umfang unterstützt und es gibt keine laufenden Bemühungen, die Funktionsfähigkeit dieser Architektur sicherzustellen.
powerpc64le-linux
64-Bit-Prozessoren mit Power-Befehlssatz, little-endian, mit Linux-Libre als Kernel. Dazu gehören POWER9-Systeme wie die RYF-zertifizierte Talos-II-Hauptplatine. Bei der Plattform handelt es sich um eine „Technologievorschau“; obwohl sie unterstützt wird, gibt es noch keine Substitute von der Erstellungsfarm (siehe Substitute) und bei manchen Paketen könnte die Erstellung fehlschlagen (siehe Überblick über gemeldete Fehler und Änderungen). Dennoch arbeitet die Guix-Gemeinde aktiv daran, diese Unterstützung auszubauen, und jetzt ist eine gute Gelegenheit, sie auszuprobieren und mitzumachen!
riscv64-linux
64-Bit-Prozessoren mit RISC-V-Befehlssatz, little-endian, speziell der RV64GC, mit Linux-Libre als Kernel. Bei der Plattform handelt es sich um eine „Technologievorschau“; obwohl sie unterstützt wird, gibt es noch keine Substitute von der Erstellungsfarm (siehe Substitute) und bei manchen Paketen könnte die Erstellung fehlschlagen (siehe Überblick über gemeldete Fehler und Änderungen). Dennoch arbeitet die Guix-Gemeinde aktiv daran, diese Unterstützung auszubauen, und jetzt ist eine gute Gelegenheit, sie auszuprobieren und mitzumachen!
Mit Guix System deklarieren Sie alle Aspekte der Betriebssystemkonfiguration und Guix kümmert sich darum, die Konfiguration auf transaktionsbasierte, reproduzierbare und zustandslose Weise zu instanziieren (siehe Systemkonfiguration). Guix System benutzt den Kernel Linux-libre, das Shepherd-Initialisierungssystem (siehe Introduction in The GNU Shepherd Manual), die wohlbekannten GNU-Werkzeuge mit der zugehörigen Werkzeugkette sowie die grafische Umgebung und Systemdienste Ihrer Wahl.
Guix System ist auf allen oben genannten Plattformen außer
mips64el-linux
, powerpc-linux
, powerpc64le-linux
und
riscv64-linux
verfügbar.
Informationen, wie auf andere Architekturen oder Kernels portiert werden kann, finden Sie im Abschnitt Auf eine neue Plattform portieren.
Diese Distribution aufzubauen basiert auf Kooperation, und Sie sind herzlich eingeladen, dabei mitzumachen! Im Abschnitt Mitwirken stehen weitere Informationen, wie Sie uns helfen können.
Nächste: Systeminstallation, Vorige: Einführung, Nach oben: GNU Guix [Inhalt][Index]
Sie können das Paketverwaltungswerkzeug Guix auf einem bestehenden GNU/Linux- oder GNU/Hurd-System installieren4, welche wir als eine Fremddistribution bezeichnen. Wenn Sie stattdessen die vollständige, eigenständige GNU-Systemdistribution namens Guix System installieren möchten, siehe Systeminstallation. In diesem Abschnitt behandeln wir nur die Installation von Guix auf einer Fremddistribution.
Wichtig: Dieser Abschnitt gilt nur für Systeme ohne Guix. Wenn Sie eine bestehende Guix-Installation haben, würden wichtige Systemdateien überschrieben, wenn Sie der Anleitung folgten.
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 guix pull
aufrufen).
guix-daemon
Nächste: Den Daemon einrichten, Nach oben: Installation [Inhalt][Index]
Dieser Abschnitt beschreibt, wie Sie Guix aus einem alle Komponenten umfassenden Tarball installieren, der Binärdateien für Guix und all seine Abhängigkeiten liefert. Dies geht in der Regel schneller, als Guix aus seinen Quelldateien zu installieren, was später beschrieben wird.
Wichtig: Dieser Abschnitt gilt nur für Systeme ohne Guix. Wenn Sie eine bestehende Guix-Installation haben, würden wichtige Systemdateien überschrieben, wenn Sie der Anleitung folgten.
Auf einigen GNU/Linux-Distributionen, wie Debian, Ubuntu und openSUSE, wird Guix über deren Paketverwaltung angeboten. Vielleicht bringen sie eine ältere Version als 123b722 mit, aber Sie können Guix anschließend über den Befehl ‘guix pull’ aktualisieren.
Wir empfehlen Systemadministratoren, die Guix installieren, egal ob über das
Installations-Skript oder über die Paketverwaltung ihrer Fremddistribution,
regelmäßig die Sicherheitshinweise zu lesen und zu befolgen, die
guix pull
anzeigt.
Wenn Sie Debian oder ein Debian-Derivat wie Ubuntu oder Trisquel verwenden, rufen Sie auf:
sudo apt install guix
Das Gleiche gilt auf openSUSE:
sudo zypper install guix
Wenn bei Ihnen Parabola läuft, können Sie, nachdem Sie das Repository pcr (Parabola Community Repo) aktiviert haben, mit diesem Befehl Guix installieren:
sudo pacman -S guix
Das Guix-Projekt stellt außerdem ein Shell-Skript bereit, guix-install.sh, mit dem der Installationsvorgang aus Binärdateien ohne ein Paketverwaltungsprogramm der Fremddistribution automatisiert wird5. Um guix-install.sh benutzen zu können, werden Bash, GnuPG, GNU tar, wget und Xz vorausgesetzt.
Das Skript führt Sie durch Folgendes:
Führen Sie als Administratornutzer „root“ aus:
# cd /tmp # wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh # chmod +x guix-install.sh # ./guix-install.sh
Das Skript, um Guix zu installieren, können Sie auf Parabola auch als Paket bekommen (im Repository pcr). So können Sie es installieren und ausführen:
sudo pacman -S guix-installer sudo guix-install.sh
Anmerkung: Nach Voreinstellung richtet guix-install.sh Guix so ein, dass vorerstellte Binärdateien, die wir als Substitute bezeichnen, von den Erstellungsfarmen des Projekts heruntergeladen werden (siehe Substitute). Wenn Sie keine Zustimmung zu Substituten geben, muss Guix alles auf Ihrem Rechner aus dem Quellcode heraus erstellen, wodurch jede Installation und jede Aktualisierung sehr aufwendig wird. Siehe Vom Vertrauen gegenüber Binärdateien für eine Erörterung, aus welchen Gründen man Pakete aus dem Quellcode heraus erstellen wollen könnte.
Um Substitute von
bordeaux.guix.gnu.org
,ci.guix.gnu.org
oder einem Spiegelserver davon zu benutzen (siehe Substitute), müssen Sie sie erst autorisieren. Zum Beispiel:# guix archive --authorize < \ ~root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
Wenn Sie die Installation von Guix erledigt haben, werfen Sie einen Blick auf Anwendungen einrichten für weitere Einstellungen, die Sie vielleicht vornehmen möchten, und lesen Sie die ersten Schritte im Einstieg, um loszulegen!
Anmerkung: Der Tarball zur Installation aus einer Binärdatei kann einfach durch Ausführung des folgenden Befehls im Guix-Quellbaum (re-)produziert und verifiziert werden:
make guix-binary.System.tar.xz… was wiederum dies ausführt:
guix pack -s System --localstatedir \ --profile-name=current-guix guixSiehe
guix pack
aufrufen für weitere Informationen zu diesem praktischen Werkzeug.
Falls Sie Guix irgendwann deinstallieren möchten, führen Sie dasselbe Skript mit der Befehlszeilenoption --uninstall aus:
./guix-install.sh --uninstall
Durch --uninstall wird das Skript alle Dateien, Konfigurationen und Dienste von Guix unwiederbringlich löschen.
Nächste: Aufruf von guix-daemon
, Vorige: Aus Binärdatei installieren, Nach oben: Installation [Inhalt][Index]
Bei der Installation wurde der Erstellungs-Daemon, der laufen muss,
damit man Guix benutzen kann, bereits eingerichtet und Sie können Befehle
mit guix
in Ihrem Terminalprogramm ausführen, siehe Einstieg:
guix build hello
Wenn dies ohne Fehler durchläuft, können Sie diesen Abschnitt auch überspringen. Ihre nächste Station wäre der nachfolgende Abschnitt, Anwendungen einrichten.
Allerdings ist jetzt ein guter Zeitpunkt, um alte Versionen des Daemons
auszutauschen, Anpassungen vorzunehmen, Erstellungen auf andere Maschinen
auszulagern (siehe Nutzung der Auslagerungsfunktionalität) oder ihn in speziellen
Umgebungen manuell zu starten, z.B. in „chroots“ (siehe Chroot ins vorliegende System) oder WSL (nicht nötig bei mit Guix erzeugten
WSL-Abbildern, siehe wsl2-image-type
). Wenn Sie
mehr wissen möchten oder vorhaben, Ihr System zu optimieren, lohnt es sich,
diesen Abschnitt zu lesen.
Operationen wie das Erstellen eines Pakets oder Laufenlassen des
Müllsammlers werden alle durch einen spezialisierten Prozess durchgeführt,
den Erstellungs-Daemon, im Auftrag seiner Kunden (den Clients). Nur der
Daemon darf auf den Store und seine zugehörige Datenbank zugreifen. Daher
wird jede den Store verändernde Operation durch den Daemon durchgeführt. Zum
Beispiel kommunizieren Befehlszeilenwerkzeuge wie guix package
und
guix build
mit dem Daemon (mittels entfernter Prozeduraufrufe), um
ihm Anweisungen zu geben, was er tun soll.
Folgende Abschnitte beschreiben, wie Sie die Umgebung des Erstellungs-Daemons ausstatten sollten. Siehe Substitute für Informationen darüber, wie Sie es dem Daemon ermöglichen, vorerstellte Binärdateien herunterzuladen.
Nächste: Nutzung der Auslagerungsfunktionalität, Nach oben: Den Daemon einrichten [Inhalt][Index]
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 guix system
aufrufen).
Das Programm guix-daemon
kann mit dem folgenden Befehl als
root
gestartet werden6:
# 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:
/dev
-Verzeichnis, was größtenteils vom /dev
des Wirtssystems unabhängig erstellt wurde7,
/proc
-Verzeichnis, es zeigt nur die Prozesse des Containers, weil
ein separater Namensraum für Prozess-IDs (PIDs) benutzt wird,
localhost
auf
127.0.0.1
abbildet,
Im chroot ist kein /home-Verzeichnis enthalten und die
Umgebungsvariable HOME
ist auf das nicht existierende
Verzeichnis /homeless-shelter festgelegt. Dadurch fallen
unangemessene Verwendungen von HOME
in den Erstellungs-Skripts von
Paketen auf.
Durch diese Maßnahmen ist in der Regel gewährleistet, dass Details aus Ihrer Umgebung keinen Einfluss auf Erstellungsprozesse haben. In manchen besonderen Fällen bedarf es mehr Kontrolle – typischerweise über Datum, Kernel oder Prozessor – und dazu können Sie auf eine virtuelle Erstellungsmaschine zurückgreifen (siehe virtuelle Erstellungsmaschinen).
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: SELinux-Unterstützung, Vorige: Einrichten der Erstellungsumgebung, Nach oben: Den Daemon einrichten [Inhalt][Index]
Wenn erwünscht, kann der Erstellungs-Daemon Ableitungserstellungen auf
andere Maschinen auslagern, auf denen Guix läuft, mit Hilfe des
offload
-Build-Hooks8. 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:
parallel-builds
-Feldes des
build-machine
-Objekts entspricht.
speed
-Feld ihres build-machine
-Objekts.
overload-threshold
-Feld ihres build-machine
-Objekts
einstellbar.
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")
;; Weil 'guix offload' vom 'guix-daemon' als
;; Administratornutzer root gestartet wird.
(private-key "/root/.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.
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 auf der entfernten Maschine, mit dem eine Verbindung ü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-Rechnerschlüssel („Host Key“) 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
Rechnerschlü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 Rechnerschlü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.8
)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.
Anmerkung: Auf Guix System können Sie statt sich um eine zusätzliche Datei /etc/guix/machines.scm zu kümmern auch die Erstellungsmaschinen als Teil der Betriebssystemdeklaration in
operating-system
im Feldbuild-machines
vonguix-configuration
angeben. Siehe dasbuild-machines
-Feld vonguix-configuration
.
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 guix archive
aufrufen):
# guix archive --generate-key
Anmerkung: Dieses Schlüsselpaar hat mit dem SSH-Schlüsselpaar, das zuvor in der Beschreibung des Datentyps
build-machine
vorkam, nichts zu tun.
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 Guix nutzbar ist, und jeweils versucht, etwas auf die Erstellungsmaschine zu exportieren und von dort zu importieren. 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: Nutzung der Auslagerungsfunktionalität, Nach oben: Den Daemon einrichten [Inhalt][Index]
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.
Anmerkung: Wenn Sie mit dem Skript
guix-install.sh
die Installation aus einer Binärdatei durchführen, wird Ihnen angeboten, die folgenden Schritte automatisch durchzuführen (siehe Aus Binärdatei installieren).
Um die Richtlinie (Policy) zu installieren, führen Sie folgenden Befehl mit Administratorrechten aus:
semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil
Dann kennzeichnen Sie als Administratornutzer das Dateisystem neu. Womöglich müssen Sie sich zuerst Schreibrechte darauf verschaffen:
mount -o remount,rw /gnu/store restorecon -R /gnu /var/guix
Nun ist die Zeit gekommen, guix-daemon
zu starten oder neu zu
starten. Wenn Ihre Distribution systemd zur Diensteverwaltung benutzt, dann
geht das so:
systemctl restart guix-daemon
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.
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.
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.
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 für 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.
/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon
passt, die
Kennzeichnung guix_daemon_exec_t
zugewiesen, wodurch jeder
beliebigen 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.
Nach jeder Aktualisierung des guix-daemon, z.B. nachdem Sie
guix pull
ausgeführt haben, müssen Sie das Store-Verzeichnis neu
kennzeichnen. Angenommen, der Store befindet sich unter /gnu, dann
können Sie das mit restorecon -vR /gnu
bewerkstelligen oder durch
andere Mittel, die Ihr Betriebssystem Ihnen zur Verfügung stellt.
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: Anwendungen einrichten, Vorige: Den Daemon einrichten, Nach oben: Installation [Inhalt][Index]
guix-daemon
Das Programm guix-daemon
implementiert alle Funktionalitäten, um
auf den Store zuzugreifen. Dazu gehört das Starten von Erstellungsprozessen,
das Ausführen des Müllsammlers, das Abfragen, ob ein Erstellungsergebnis
verfügbar ist, etc. Normalerweise wird er so als Administratornutzer
(root
) gestartet:
# guix-daemon --build-users-group=guixbuild
Sie können den Daemon auch über das systemd-Protokoll zur
„Socket-Aktivierung“ starten (siehe make-systemd-constructor
in The GNU Shepherd Manual).
Details, wie Sie ihn einrichten, finden Sie im Abschnitt Den Daemon einrichten.
Standardmäßig führt guix-daemon
Erstellungsprozesse mit
unterschiedlichen UIDs aus, die aus der Erstellungsgruppe stammen, deren
Name mit --build-users-group übergeben wurde. Außerdem läuft jeder
Erstellungsprozess in einer chroot-Umgebung, die nur die Teilmenge des
Stores enthält, von der der Erstellungsprozess abhängt, entsprechend seiner
Ableitung (siehe Ableitungen), und ein paar
bestimmte Systemverzeichnisse, darunter standardmäßig auch /dev und
/dev/pts. Zudem ist die Erstellungsumgebung auf GNU/Linux eine
isolierte Umgebung, d.h. ein Container: Nicht nur hat sie ihren
eigenen Dateisystembaum, sie hat auch einen separaten Namensraum zum
Einhängen von Dateisystemen, ihren eigenen Namensraum für PIDs, für
Netzwerke, etc. Dies hilft dabei, reproduzierbare Erstellungen zu
garantieren (siehe Funktionalitäten).
Wenn der Daemon im Auftrag des Nutzers eine Erstellung durchführt, erzeugt
er ein Erstellungsverzeichnis, entweder in /tmp oder im Verzeichnis,
das durch die Umgebungsvariable TMPDIR
angegeben wurde. Dieses
Verzeichnis wird mit dem Container geteilt, solange die Erstellung noch
läuft, allerdings trägt es im Container stattdessen immer den Namen
„/tmp/guix-build-NAME.drv-0“.
Nach Abschluss der Erstellung wird das Erstellungsverzeichnis automatisch entfernt, außer wenn die Erstellung fehlgeschlagen ist und der Client --keep-failed angegeben hat (siehe --keep-failed).
Der Daemon lauscht auf Verbindungen und erstellt jeweils einen Unterprozess
für jede von einem Client begonnene Sitzung (d.h. von einem der
guix
-Unterbefehle). Der Befehl guix processes
zeigt
Ihnen eine Übersicht solcher Systemaktivitäten; damit werden Ihnen alle
aktiven Sitzungen und Clients gezeigt. Weitere Informationen finden Sie
unter guix processes
aufrufen.
Die folgenden Befehlszeilenoptionen werden unterstützt:
--build-users-group=Gruppe
Verwende die Benutzerkonten aus der Gruppe, um Erstellungsprozesse auszuführen (siehe Erstellungsbenutzer).
--no-substitutes
¶Benutze keine Substitute für Erstellungsergebnisse. Das heißt, dass alle Objekte lokal erstellt werden müssen, und kein Herunterladen von vorab erstellten Binärdateien erlaubt ist (siehe Substitute).
Wenn der Daemon mit --no-substitutes ausgeführt wird, können
Clients trotzdem Substitute explizit aktivieren über den entfernten
Prozeduraufruf set-build-options
(siehe Der Store).
--substitute-urls=URLs
URLs als standardmäßige, leerzeichengetrennte Liste der Quell-URLs für
Substitute benutzen. Wenn diese Befehlszeilenoption nicht angegeben
wird, wird ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org
’ verwendet.
Das hat zur Folge, dass Substitute von den URLs heruntergeladen werden können, solange sie mit einer Signatur versehen sind, der vertraut wird (siehe Substitute).
Siehe Substitute von anderen Servern holen für weitere Informationen, wie der Daemon konfiguriert werden kann, um Substitute von anderen Servern zu beziehen.
--no-offload
Nicht versuchen, an andere Maschinen ausgelagerte Erstellungen zu benutzen (siehe Nutzung der Auslagerungsfunktionalität). Somit wird lokal erstellt, statt Erstellungen auf entfernte Maschinen auszulagern.
--cache-failures
Fehler bei der Erstellung zwischenspeichern. Normalerweise werden nur erfolgreiche Erstellungen gespeichert.
Wenn diese Befehlszeilenoption benutzt wird, kann guix gc
--list-failures
benutzt werden, um die Menge an Store-Objekten abzufragen,
die als Fehlschläge markiert sind; guix gc --clear-failures
entfernt Store-Objekte aus der Menge zwischengespeicherter
Fehlschläge. Siehe guix gc
aufrufen.
--cores=n
-c n
n CPU-Kerne zum Erstellen jeder Ableitung benutzen; 0
heißt, so
viele wie verfügbar sind.
Der Vorgabewert ist 0
, jeder Client kann jedoch eine abweichende
Anzahl vorgeben, zum Beispiel mit der Befehlszeilenoption --cores
von guix build
(siehe Aufruf von guix build
).
Dadurch wird die Umgebungsvariable NIX_BUILD_CORES
im
Erstellungsprozess definiert, welcher sie benutzen kann, um intern parallele
Ausführungen zuzulassen – zum Beispiel durch Nutzung von make
-j$NIX_BUILD_CORES
.
--max-jobs=n
-M n
Höchstenss n Erstellungsaufträge parallel bearbeiten. Der Vorgabewert
liegt bei 1
. Wird er auf 0
gesetzt, werden keine Erstellungen
lokal durchgeführt, stattdessen lagert der Daemon sie nur aus (siehe
Nutzung der Auslagerungsfunktionalität) oder sie schlagen einfach fehl.
--max-silent-time=Sekunden
Wenn der Erstellungs- oder Substitutionsprozess länger als Sekunden-lang keine Ausgabe erzeugt, wird er abgebrochen und ein Fehler beim Erstellen gemeldet.
Der Vorgabewert ist 3600
(eine Stunde).
Clients können einen anderen Wert als den hier angegebenen verwenden lassen (siehe --max-silent-time).
--timeout=Sekunden
Entsprechend wird hier der Erstellungs- oder Substitutionsprozess abgebrochen und als Fehlschlag gemeldet, wenn er mehr als Sekunden-lang dauert.
Vorgegeben sind 24 Stunden.
Clients können einen anderen Wert verwenden lassen (siehe --timeout).
--rounds=N
Jede Ableitung n-mal hintereinander erstellen und einen Fehler melden,
wenn nacheinander ausgewertete Erstellungsergebnisse nicht Bit für Bit
identisch sind. Beachten Sie, dass Clients wie guix build
einen
anderen Wert verwenden lassen können (siehe Aufruf von guix build
).
Wenn dies zusammen mit --keep-failed benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen /gnu/store/…-check. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden.
--debug
Informationen zur Fehlersuche ausgeben.
Dies ist nützlich, um Probleme beim Starten des Daemons nachzuvollziehen;
Clients könn aber auch ein abweichenden Wert verwenden lassen, zum Beispiel
mit der Befehlszeilenoption --verbosity von guix build
(siehe Aufruf von guix build
).
--chroot-directory=Verzeichnis
Füge das Verzeichnis zum chroot von Erstellungen hinzu.
Dadurch kann sich das Ergebnis von Erstellungsprozessen ändern – zum Beispiel, wenn diese optionale Abhängigkeiten aus dem Verzeichnis verwenden, wenn sie verfügbar sind, und nicht, wenn es fehlt. Deshalb ist es nicht empfohlen, dass Sie diese Befehlszeilenoption verwenden, besser sollten Sie dafür sorgen, dass jede Ableitung alle von ihr benötigten Eingabgen deklariert.
--disable-chroot
Erstellungen ohne chroot durchführen.
Diese Befehlszeilenoption zu benutzen, wird nicht empfohlen, denn auch
dadurch bekämen Erstellungsprozesse Zugriff auf nicht deklarierte
Abhängigkeiten. Sie ist allerdings unvermeidlich, wenn guix-daemon
auf einem Benutzerkonto ohne ausreichende Berechtigungen ausgeführt wird.
--log-compression=Typ
Erstellungsprotokolle werden entsprechend dem Typ komprimiert, der
entweder gzip
, bzip2
oder none
(für keine Kompression)
sein muss.
Sofern nicht --lose-logs angegeben wurde, werden alle Erstellungsprotokolle in der localstatedir gespeichert. Um Platz zu sparen, komprimiert sie der Daemon standardmäßig automatisch mit gzip.
--discover[=yes|no]
Ob im lokalen Netzwerk laufende Substitutserver mit mDNS und DNS-SD ermittelt werden sollen oder nicht.
Diese Funktionalität ist noch experimentell. Trotzdem sollten Sie bedenken:
guix publish
in Ihrem LAN mitteilt,
kann er Ihnen keine bösartigen Programmdateien unterjubeln, aber er kann
lernen, welche Software Sie installieren.
Das Erkennen von Substitutservern können Sie auch nachträglich zur Laufzeit an- oder abschalten („on“ oder „off“), indem Sie dies ausführen:
herd discover guix-daemon on herd discover guix-daemon off
--disable-deduplication
¶Automatische Dateien-„Deduplizierung“ im Store ausschalten.
Standardmäßig werden zum Store hinzugefügte Objekte automatisch „dedupliziert“: Wenn eine neue Datei mit einer anderen im Store übereinstimmt, wird die neue Datei stattdessen als harte Verknüpfung auf die andere Datei angelegt. Dies reduziert den Speicherverbrauch auf der Platte merklich, jedoch steigt andererseits die Auslastung bei der Ein-/Ausgabe im Erstellungsprozess geringfügig. Durch diese Option wird keine solche Optimierung durchgeführt.
--gc-keep-outputs[=yes|no]
Gibt an, ob der Müllsammler (Garbage Collector, GC) die Ausgaben lebendiger Ableitungen behalten muss („yes“) oder nicht („no“).
Für yes
behält der Müllsammler die Ausgaben aller lebendigen
Ableitungen im Store – die .drv-Dateien. Der Vorgabewert ist
aber no
, so dass Ableitungsausgaben nur vorgehalten werden, wenn sie
von einer Müllsammlerwurzel aus erreichbar sind. Siehe den Abschnitt
guix gc
aufrufen für weitere Informationen zu Müllsammlerwurzeln.
--gc-keep-derivations[=yes|no]
Gibt an, ob der Müllsammler (GC) Ableitungen behalten muss („yes“), wenn sie lebendige Ausgaben haben, oder nicht („no“).
Für yes
, den Vorgabewert, behält der Müllsammler Ableitungen –
z.B. .drv-Dateien –, solange zumindest eine ihrer Ausgaben
lebendig ist. Dadurch können Nutzer den Ursprung der Dateien in ihrem Store
nachvollziehen. Setzt man den Wert auf no
, wird ein bisschen weniger
Speicher auf der Platte verbraucht.
Auf diese Weise überträgt sich, wenn --gc-keep-derivations auf
yes
steht, die Lebendigkeit von Ausgaben auf Ableitungen, und wenn
--gc-keep-outputs auf yes
steht, die Lebendigkeit von
Ableitungen auf Ausgaben. Stehen beide auf yes
, bleiben so alle
Erstellungsvoraussetzungen wie Quelldateien, Compiler, Bibliotheken und
andere Erstellungswerkzeuge lebendiger Objekte im Store erhalten, ob sie von
einer Müllsammlerwurzel aus erreichbar sind oder nicht. Entwickler können
sich so erneute Erstellungen oder erneutes Herunterladen sparen.
--impersonate-linux-2.6
Auf Linux-basierten Systemen wird hiermit vorgetäuscht, dass es sich um
Linux 2.6 handeln würde, indem der Kernel für einen
uname
-Systemaufruf als Version der Veröffentlichung mit 2.6
antwortet.
Dies kann hilfreich sein, um Programme zu erstellen, die (normalerweise zu Unrecht) von der Kernel-Versionsnummer abhängen.
--lose-logs
Keine Protokolle der Erstellungen vorhalten. Normalerweise würden solche in localstatedir/guix/log gespeichert.
--system=System
Verwende System als aktuellen Systemtyp. Standardmäßig ist dies das
Paar aus Befehlssatz und Kernel, welches beim Aufruf von configure
erkannt wurde, wie zum Beispiel x86_64-linux
.
--listen=Endpunkt
Lausche am Endpunkt auf Verbindungen. Dabei wird der Endpunkt
als Dateiname eines Unix-Sockets verstanden, wenn er mit einem /
(Schrägstrich) beginnt. Andernfalls wird der Endpunkt als Rechnername
(d.h. Hostname) oder als Rechnername-Port-Paar verstanden, auf dem
gelauscht wird. Hier sind ein paar Beispiele:
--listen=/gnu/var/daemon
Lausche auf Verbindungen am Unix-Socket /gnu/var/daemon, falls nötig wird er dazu erstellt.
--listen=localhost
¶Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die
localhost
entspricht, auf Port 44146.
--listen=128.0.0.42:1234
Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die
128.0.0.42
entspricht, auf Port 1234.
Diese Befehlszeilenoption kann mehrmals wiederholt werden. In diesem Fall
akzeptiert guix-daemon
Verbindungen auf allen angegebenen
Endpunkten. Benutzer können bei Client-Befehlen angeben, mit welchem
Endpunkt sie sich verbinden möchten, indem sie die Umgebungsvariable
GUIX_DAEMON_SOCKET
festlegen (siehe GUIX_DAEMON_SOCKET
).
Anmerkung: Das Daemon-Protokoll ist weder authentifiziert noch verschlüsselt. Die Benutzung von --listen=Rechner eignet sich für lokale Netzwerke, wie z.B. in Rechen-Clustern, wo sich nur solche Knoten mit dem Daemon verbinden, denen man vertraut. In Situationen, wo ein Fernzugriff auf den Daemon durchgeführt wird, empfehlen wir, über Unix-Sockets in Verbindung mit SSH zuzugreifen.
Wird --listen nicht angegeben, lauscht guix-daemon
auf
Verbindungen auf dem Unix-Socket, der sich unter
localstatedir/guix/daemon-socket/socket befindet.
Nächste: Aktualisieren von Guix, Vorige: Aufruf von guix-daemon
, Nach oben: Installation [Inhalt][Index]
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.
Ü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 930 MiB
wiegt9. Wenn alles,
was Sie brauchen, einige wenige Locales sind, können Sie Ihr eigenes
Locale-Paket mit der Prozedur make-glibc-utf8-locales
aus dem Modul
(gnu packages base)
definieren. Folgendes Beispiel definiert ein
Paket mit den verschiedenen kanadischen UTF-8-Locales, die der GNU libc
bekannt sind, das nur um die 14 MiB schwer ist:
(use-modules (gnu packages base)) (define my-glibc-locales (make-glibc-utf8-locales glibc #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA") #:name "glibc-kanadische-utf8-locales"))
Die Variable GUIX_LOCPATH
spielt eine ähnliche Rolle wie LOCPATH
(siehe LOCPATH
in Referenzhandbuch der
GNU-C-Bibliothek). Es gibt jedoch zwei wichtige Unterschiede:
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.
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.
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.
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 font-ghostscript
, 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.
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.
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. Sie können diese Prozedur selbst interaktiv aufrufen, damit neu
installierte Emacs-Pakete erkannt werden, ohne Emacs neu zu starten. 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).
Anmerkung: Die meisten Varianten von Emacs sind mittlerweile in der Lage, Code nativ zu kompilieren. Allerdings verhält sich Guix’ Emacs merklich anders als die Voreinstellungen der Emacs-Macher.
Deren Emacs kompiliert Pakete bei Bedarf („just-in-time“) und legt die Objektdateien („Shared Objects“) in einem eigenen Verzeichnis innerhalb Ihres
user-emacs-directory
-Verzeichnisses an. Die Objektdateien darin sind in einer flachen Hierarchie angeordnet und tragen Dateinamen mit zwei Hashes, mit denen der ursprüngliche Dateiname und der Inhalt des Quellcodes verifiziert werden.Guix’ Emacs dagegen kompiliert seine Pakete bevorzugt im Voraus. Objektdateien tragen im Wesentlichen den ursprünglichen Dateinamen ohne zusätzliche Hashes, mit denen Name oder Inhalt verifiziert würde. Das ermöglicht es, für Guix’ Emacs erstellte Pakete zu veredeln (siehe Veredelungen) und obwohl Guix’ Emacs so auch die hashbasierte Verifizierung des Quellcodes wie im Original-Emacs fehlt, kann eine solche Benennung als Sicherheitsmaßnahme ohnehin leicht umgangen werden. Daher schalten wir Just-in-time-Kompilieren ab.
Darüber hinaus sei erwähnt, dass
emacs-minimal
– die Emacs-Variante, mit der normalerweise Emacs-Pakete erstellt werden – weiterhin keine nativen Befehle generiert. Um native Befehle für Ihre Emacs-Pakete schon im Voraus zu erzeugen, nutzen Sie eine Transformation, z.B. --with-input=emacs-minimal=emacs.
Vorige: Anwendungen einrichten, Nach oben: Installation [Inhalt][Index]
Um Guix zu aktualisieren, führen Sie aus:
guix pull
Siehe guix pull
aufrufen für weitere Informationen.
Auf einer Fremddistribution können Sie den Erstellungsdaemon aktualisieren, indem Sie diesen Befehl:
sudo -i guix pull
gefolgt von diesem ausführen (unter der Annahme, dass Ihre Distribution zur Dienstverwaltung das systemd-Werkzeug benutzt):
systemctl restart guix-daemon.service
Auf Guix System wird der Daemon aktualisiert, indem Sie das System
rekonfigurieren (siehe guix system
reconfigure
).
Nächste: Einstieg, Vorige: Installation, Nach oben: GNU Guix [Inhalt][Index]
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: Hardware-Überlegungen, Nach oben: Systeminstallation [Inhalt][Index]
Wir denken, dass Guix System für viele Anwendungszwecke von Heim- und Bürorechnern bis hin zu Servern geeignet ist. Die Verlässlichkeitsgarantien, die es einem bietet – transaktionelle Aktualisierungen und Rücksetzungen, Reproduzierbarkeit – machen es zu einer soliden Grundlage.
Immer mehr Systemdienste sind verfügbar (siehe Dienste).
Bevor Sie mit der Installation fortfahren, denken Sie daran, dass in der Version 123b722 vielleicht von Ihnen benötigte Dienste fehlen.
Dies soll allerdings nicht nur ein Hinweis sein, sondern auch als Einladung aufgefasst werden, uns Fehler (und Erfolgsgeschichten!) zu melden und bei uns mitzumachen, um Guix zu verbessern. Siehe den Abschnitt Mitwirken.
Nächste: Installation von USB-Stick oder DVD, Vorige: Einschränkungen, Nach oben: Systeminstallation [Inhalt][Index]
GNU Guix legt den Fokus darauf, die Freiheit des Nutzers auf seinem Rechner zu respektieren. Es baut auf Linux-libre als Kernel auf, wodurch nur Hardware unterstützt wird, für die Treiber und Firmware existieren, die freie Software sind. Heutzutage wird ein großer Teil der handelsüblichen Hardware von GNU/Linux-libre unterstützt – von Tastaturen bis hin zu Grafikkarten, Scannern und Ethernet-Adaptern. Leider gibt es noch Bereiche, wo die Hardwareanbieter ihren Nutzern die Kontrolle über ihren eigenen Rechner verweigern. Solche Hardware wird von Guix System nicht unterstützt.
Einer der wichtigsten Bereiche, wo es an freien Treibern und freier Firmware
mangelt, sind WLAN-Geräte. WLAN-Geräte, von denen wir wissen, dass sie
funktionieren, sind unter anderem solche, die die Atheros-Chips AR9271 und
AR7010 verbauen, welche der Linux-libre-Treiber ath9k
unterstützt,
und die, die Broadcom/AirForce-Chips BCM43xx (mit Wireless-Core Revision 5)
verbauen, welche der Linux-libre-Treiber b43-open
unterstützt. Freie
Firmware gibt es für beide und sie wird von Haus aus mit Guix System als ein
Teil von %base-firmware
mitgeliefert (siehe firmware
).
Das Installationsprogramm zeigt zu Beginn eine Warnung an, wenn es Geräte erkennt, die bekanntlich nicht funktionieren, weil es keine freie Firmware oder keine freien Treiber dafür gibt.
Die Free Software Foundation betreibt Respects Your Freedom (RYF), ein Zertifizierungsprogramm für Hardware-Produkte, die Ihre Freiheit respektieren, Datenschutz gewährleisten und sicherstellen, dass Sie die Kontrolle über Ihr Gerät haben. Wir ermutigen Sie dazu, die Liste RYF-zertifizierter Geräte zu beachten.
Eine weitere nützliche Ressource ist die Website H-Node. Dort steht ein Katalog von Hardware-Geräten mit Informationen darüber, wie gut sie von GNU/Linux unterstützt werden.
Nächste: Vor der Installation, Vorige: Hardware-Überlegungen, Nach oben: Systeminstallation [Inhalt][Index]
Sie können ein ISO-9660-Installationsabbild von
‘https://ftp.gnu.org/gnu/guix/guix-system-install-123b722.x86_64-linux.iso
’
herunterladen, dass Sie auf einen USB-Stick aufspielen oder auf eine DVD
brennen können, wobei Sie anstelle von x86_64-linux
eines der
folgenden schreiben können:
x86_64-linux
für ein GNU/Linux-System auf Intel/AMD-kompatiblen 64-Bit-Prozessoren,
i686-linux
für ein 32-Bit-GNU/Linux-System auf Intel-kompatiblen Prozessoren.
Laden Sie auch die entsprechende .sig-Datei herunter und verifizieren Sie damit die Authentizität Ihres Abbilds, indem Sie diese Befehle eingeben:
$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-123b722.x86_64-linux.iso.sig $ gpg --verify guix-system-install-123b722.x86_64-linux.iso.sig
Falls dieser Befehl fehlschlägt, weil Sie nicht über den nötigen öffentlichen Schlüssel verfügen, können Sie ihn mit diesem Befehl importieren:
$ wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 \ -qO - | gpg --import -
und den Befehl gpg --verify
erneut ausführen.
Beachten Sie, dass eine Warnung wie „Dieser Schlüssel trägt keine vertrauenswürdige Signatur!“ normal ist.
Dieses Abbild enthält die Werkzeuge, die Sie zur Installation brauchen. Es ist dafür gedacht, so wie es ist auf einen hinreichend großen USB-Stick oder eine DVD kopiert zu werden.
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-123b722.x86_64-linux.iso of=/dev/sdX status=progress sync
Sie benötigen in der Regel Administratorrechte, um auf /dev/sdX zuzugreifen.
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-123b722.x86_64-linux.iso
Der Zugriff auf /dev/srX setzt in der Regel Administratorrechte voraus.
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.
Leider scheitert auf manchen Maschinen der Bootvorgang und Sie bekommen nach dem Booten nur einen schwarzen Bildschirm zu sehen, selbst nachdem Sie zehn Minuten lang gewartet haben. Das kann bedeuten, dass Ihre Maschine Guix System nicht ausführen kann; vielleicht möchten Sie stattdessen Guix auf einer Fremddistribution installieren (siehe Aus Binärdatei installieren). Aber es ist noch zu früh, um aufzugeben; womöglich lässt sich der schwarze Bildschirm umgehen, indem Sie in GRUBs Bootmenü die Taste e drücken und die Option nomodeset an die Linux-Bootzeile anhängen. In manchen Fällen kann das Problem mit dem schwarzen Bildschirm auch gelöst werden, indem Sie einen anderen Bildschirm anschließen.
Lesen Sie den Abschnitt Guix in einer virtuellen Maschine installieren, wenn Sie Guix System stattdessen in einer virtuellen Maschine (VM) installieren möchten.
Nächste: Geführte grafische Installation, Vorige: Installation von USB-Stick oder DVD, Nach oben: Systeminstallation [Inhalt][Index]
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: Manuelle Installation, Vorige: Vor der Installation, Nach oben: Systeminstallation [Inhalt][Index]
Das grafische Installationsprogramm ist mit einer textbasierten Benutzeroberfläche ausgestattet. Es kann Sie mit Dialogfeldern durch die Schritte führen, mit denen Sie GNU Guix System installieren.
Die ersten Dialogfelder ermöglichen es Ihnen, das System aufzusetzen, wie Sie es bei der Installation benutzen: Sie können die Sprache und Tastaturbelegung festlegen und die Netzwerkanbindung einrichten, die während der Installation benutzt wird. Das folgende Bild zeigt den Dialog zur Einrichtung der Netzwerkanbindung.
Mit den danach kommenden Schritten können Sie Ihre Festplatte partitionieren, wie im folgenden Bild gezeigt, und auswählen, ob Ihre Dateisysteme verschlüsselt werden sollen oder nicht. Sie können Ihren Rechnernamen und das Administratorpasswort (das „root“-Passwort) festlegen und ein Benutzerkonto einrichten, und noch mehr.
Beachten Sie, dass Sie mit dem Installationsprogramm jederzeit den aktuellen Installationsschritt verlassen und zu einem vorherigen Schritt zurückkehren können, wie Sie im folgenden Bild sehen können.
Sobald Sie fertig sind, erzeugt das Installationsprogramm eine Betriebssystemkonfiguration und zeigt sie an (siehe Das Konfigurationssystem nutzen). Zu diesem Zeitpunkt können Sie auf „OK“ drücken und die Installation wird losgehen. Ist sie erfolgreich, können Sie neu starten und Ihr neues System genießen. Siehe Nach der Systeminstallation für Informationen, wie es weitergeht!
Nächste: Nach der Systeminstallation, Vorige: Geführte grafische Installation, Nach oben: Systeminstallation [Inhalt][Index]
Dieser Abschnitt beschreibt, wie Sie GNU Guix System auf manuelle Weise auf Ihrer Maschine installieren. Diese Alternative setzt voraus, dass Sie bereits mit GNU/Linux, der Shell und üblichen Administrationswerkzeugen vertraut sind. Wenn Sie glauben, dass das nichts für Sie ist, dann möchten Sie vielleicht das geführte grafische Installationsprogramm benutzen (siehe Geführte grafische Installation).
Das Installationssystem macht Eingabeaufforderungen auf den TTYs 3 bis 6
zugänglich, auf denen Sie als Administratornutzer Befehle eingeben können;
Sie erreichen diese, indem Sie die Tastenkombinationen strg-alt-f3,
strg-alt-f4 und so weiter benutzen. Es enthält viele übliche
Werkzeuge, mit denen Sie diese Aufgabe bewältigen können. Da es sich auch um
ein vollständiges „Guix System“-System handelt, können Sie aber auch andere
Pakete mit dem Befehl guix package
nachinstallieren, wenn Sie sie
brauchen (siehe guix package
aufrufen).
Nächste: Fortfahren mit der Installation, Nach oben: Manuelle Installation [Inhalt][Index]
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.
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.
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’.
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
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.
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 mitgrub-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) erzeugen10. 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, um sie als LUKS-Partition zu formatieren:
cryptsetup luksFormat /dev/sda2 cryptsetup open /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), 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ühren11:
# 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: Tastaturbelegung, Netzwerkanbindung und Partitionierung, Nach oben: Manuelle Installation [Inhalt][Index]
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 mg
(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:
bootloader-configuration
-Form muss sich auf die Ziele beziehen,
auf die Sie GRUB installieren möchten. Sie sollte genau dann
grub-bootloader
nennen, wenn Sie GRUB im alten BIOS-Modus
installieren, und für neuere UEFI-Systeme sollten Sie
grub-efi-bootloader
nennen. Bei Altsystemen bezeichnet das
targets
-Feld die Geräte wie (list "/dev/sda")
, bei
UEFI-Systemen bezeichnet es die Pfade zu eingebundenen EFI-Partitionen (ESP)
wie (list "/boot/efi")
; stellen Sie sicher, dass die Pfade
tatsächlich dort eingebunden sind und ein file-system
-Eintrag dafür
in Ihrer Konfiguration festgelegt wurde.
device
-Feldern in
Ihrer file-system
-Konfiguration übereinstimmen, sofern Sie in Ihrer
file-system
-Konfiguration die Prozedur file-system-label
für
ihre device
-Felder benutzen.
mapped-devices
-Feld genannt werden (siehe Zugeordnete Geräte).
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 guix system
aufrufen. 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: Guix in einer virtuellen Maschine installieren, Vorige: Manuelle Installation, Nach oben: Systeminstallation [Inhalt][Index]
Sie haben es geschafft: Sie haben Guix System erfolgreich gebootet! Sie können Guix System aktualisieren, wann Sie möchten, indem Sie das hier ausführen:
guix pull sudo guix system reconfigure /etc/config.scm
Dadurch wird eine neue Systemgeneration aus den neuesten Paketen und Diensten erstellt.
Werfen Sie nun einen Blick auf Einstieg und
besuchen Sie uns auf #guix
auf dem Libera.Chat-IRC-Netzwerk oder auf
der Mailing-Liste guix-devel@gnu.org, um uns Rückmeldung zu geben!
Nächste: Ein Abbild zur Installation erstellen, Vorige: Nach der Systeminstallation, Nach oben: Systeminstallation [Inhalt][Index]
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:
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.
qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \ -nic user,model=virtio-net-pci -boot menu=on,order=d \ -drive file=guix-system.img \ -drive media=cdrom,readonly=on,file=guix-system-install-123b722.System.iso
-enable-kvm
ist optional, verbessert die Rechenleistung aber
erheblich, siehe Guix in einer virtuellen Maschine betreiben.
root
angemeldet und können mit der Installation wie gewohnt fortfahren. Folgen
Sie der Anleitung im Abschnitt Vor der Installation.
Wurde die Installation abgeschlossen, können Sie das System starten, das sich nun als Abbild in der Datei guix-system.img befindet. Der Abschnitt Guix in einer virtuellen Maschine betreiben erklärt, wie Sie das tun können.
Vorige: Guix in einer virtuellen Maschine installieren, Nach oben: Systeminstallation [Inhalt][Index]
Das oben beschriebene Installationsabbild wurde mit dem Befehl guix
system
erstellt, genauer gesagt mit:
guix system image -t iso9660 gnu/system/install.scm
Die Datei gnu/system/install.scm finden Sie im Quellbaum von
Guix. Schauen Sie sich die Datei und auch den Abschnitt guix system
aufrufen an, um mehr Informationen über das Installationsabbild zu erhalten.
Viele ARM-Chips funktionieren nur mit ihrer eigenen speziellen Variante des U-Boot-Bootloaders.
Wenn Sie ein Disk-Image erstellen und der Bootloader nicht anderweitig schon installiert ist (auf einem anderen Laufwerk), ist es ratsam, ein Disk-Image zu erstellen, was den Bootloader enthält, mit dem Befehl:
guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'
A20-OLinuXino-Lime2
ist der Name des Chips. Wenn Sie einen ungültigen
Namen eingeben, wird eine Liste möglicher Chip-Namen ausgegeben.
Nächste: Paketverwaltung, Vorige: Systeminstallation, Nach oben: GNU Guix [Inhalt][Index]
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! Das Paket ist nun Teil Ihres voreingestellten Profils in $HOME/.guix-profile – ein Profil ist ein Verzeichnis, das installierte Pakete enthält. 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
GUIX_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.Es ist sogar möglich, die Konfiguration Ihrer gesamten Persönlichen Umgebung mit Guix zu erledigen – die „Dotfiles“, die in Ihrem Persönlichen Verzeichnis einen Namen tragen, der mit einem Punkt beginnt, außerdem eigene Dienste und Pakete für das Benutzerkonto. Diese Funktion heißt Guix Home. Siehe Persönliche Konfiguration, um mehr darüber zu erfahren!
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" . "$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
guix pull
aufrufen 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 dietime-machine
-Funktion (sieheguix time-machine
aufrufen).
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. Genau wie bei Paketen können Sie jederzeit das gesamte System auf eine vorherige Generation zurücksetzen. Siehe Einstieg, um zu erfahren, wie Sie das System pflegen.
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:
- Siehe das GNU-Guix-Kochbuch für eine Liste von anleitungsartigen Rezepten zu einer Vielzahl von Anwendungszwecken.
- In der GNU Guix Reference Card sind in zwei Seiten die meisten Befehle und Befehlszeilenoptionen aufgeführt, die Sie jemals brauchen werden.
- Auf dem Webauftritt gibt es Lehrvideos zu Themen wie der alltäglichen Nutzung von Guix, wo man Hilfe bekommt und wie man mitmachen kann.
- Siehe Dokumentation, um zu erfahren, wie Sie von Ihrem Rechner aus auf Dokumentation von Software zugreifen können.
Wir hoffen, dass Ihnen Guix genauso viel Spaß bereitet wie der Guix-Gemeinde bei seiner Entwicklung!
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
guix package
aufrufenguix locate
aufrufenguix gc
aufrufenguix pull
aufrufenguix time-machine
aufrufenguix describe
aufrufenguix archive
aufrufen
Nächste: guix package
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
Wir nehmen hier an, dass Sie schon Ihre ersten Erfahrungen mit Guix gemacht haben (siehe Einstieg) und gerne einen Überblick darüber bekommen würden, wie Guix im Detail funktioniert.
Wenn Sie Guix benutzen, landet jedes Paket schließlich im Paket-Store
in seinem eigenen Verzeichnis – der Name ist ähnlich wie
/gnu/store/xxx-package-1.2, wobei xxx
eine Zeichenkette in
Base32-Darstellung ist.
Statt diese Verzeichnisse direkt anzugeben, haben Nutzer ihr eigenes
Profil, welches auf diejenigen Pakete zeigt, die sie tatsächlich
benutzen wollen. Diese Profile sind im Persönlichen Verzeichnis des
jeweiligen Nutzers gespeichert als $HOME/.guix-profile
.
Zum Beispiel installiert alice
GCC 4.7.2. Dadurch zeigt dann
/home/alice/.guix-profile/bin/gcc auf
/gnu/store/…-gcc-4.7.2/bin/gcc. Auf demselben Rechner hat bob
bereits GCC 4.8.0 installiert. Das Profil von bob
zeigt dann einfach
weiterhin auf /gnu/store/…-gcc-4.8.0/bin/gcc – d.h. beide
Versionen von GCC koexistieren auf demselben System, ohne sich zu stören.
Der Befehl guix package
ist das zentrale Werkzeug, um Pakete zu
verwalten (siehe guix package
aufrufen). Es arbeitet auf dem eigenen
Profil jedes Nutzers und kann mit normalen Benutzerrechten ausgeführt
werden.
Der Befehl stellt die offensichtlichen Installations-, Entfernungs- und
Aktualisierungsoperationen zur Verfügung. Jeder Aufruf ist tatsächlich eine
eigene Transaktion: Entweder die angegebene Operation wird
erfolgreich durchgeführt, oder gar nichts passiert. Wenn also der Prozess
von guix package
während der Transaktion beendet wird, oder es zum
Stromausfall während der Transaktion kommt, dann bleibt der alte, nutzbare
Zustands des Nutzerprofils erhalten.
Zudem kann jede Pakettransaktion zurückgesetzt werden (Rollback). Wird also zum Beispiel durch eine Aktualisierung eine neue Version eines Pakets installiert, die einen schwerwiegenden Fehler zur Folge hat, können Nutzer ihr Profil einfach auf die vorherige Profilinstanz zurücksetzen, von der sie wissen, dass sie gut lief. Ebenso unterliegt bei Guix auch die globale Systemkonfiguration transaktionellen Aktualisierungen und Rücksetzungen (siehe Einstieg).
Alle Pakete im Paket-Store können vom Müllsammler (Garbage Collector)
gelöscht werden. Guix ist in der Lage, festzustellen, welche Pakete noch
durch Benutzerprofile referenziert werden, und entfernt nur diese, die
nachweislich nicht mehr referenziert werden (siehe guix gc
aufrufen). Benutzer können auch ausdrücklich alte Generationen ihres Profils
löschen, damit die zugehörigen Pakete vom Müllsammler gelöscht werden
können.
Guix verfolgt einen rein funktionalen Ansatz bei der Paketverwaltung, wie er in der Einleitung beschrieben wurde (siehe Einführung). Jedes Paketverzeichnis im /gnu/store hat einen Hash all seiner bei der Erstellung benutzten Eingaben im Namen – Compiler, Bibliotheken, Erstellungs-Skripts etc. Diese direkte Entsprechung ermöglicht es Benutzern, eine Paketinstallation zu benutzen, die sicher dem aktuellen Stand ihrer Distribution entspricht. Sie hilft auch dabei, die Reproduzierbarkeit der Erstellungen zu maximieren: Dank den isolierten Erstellungsumgebungen, die benutzt werden, resultiert eine Erstellung wahrscheinlich in bitweise identischen Dateien, auch wenn sie auf unterschiedlichen Maschinen durchgeführt wird (siehe Container).
Auf dieser Grundlage kann Guix transparent Binär- oder Quelldateien
ausliefern. Wenn eine vorerstellte Binärdatei für ein
/gnu/store-Objekt von einer externen Quelle verfügbar ist – ein
Substitut –, lädt Guix sie einfach herunter und entpackt sie,
andernfalls erstellt Guix das Paket lokal aus seinem Quellcode (siehe
Substitute). Weil Erstellungsergebnisse normalerweise Bit für Bit
reproduzierbar sind, müssen die Nutzer den Servern, die Substitute anbieten,
nicht blind vertrauen; sie können eine lokale Erstellung erzwingen und
Substitute anfechten (siehe guix challenge
aufrufen).
Kontrolle über die Erstellungsumgebung ist eine auch für Entwickler
nützliche Funktionalität. Der Befehl guix shell
ermöglicht es
Entwicklern eines Pakets, schnell die richtige Entwicklungsumgebung für ihr
Paket einzurichten, ohne manuell die Abhängigkeiten des Pakets in ihr Profil
installieren zu müssen (siehe guix shell
aufrufen).
Ganz Guix und all seine Paketdefinitionen stehen unter Versionskontrolle und
guix pull
macht es möglich, auf dem Verlauf der Entwicklung von
Guix selbst „in der Zeit zu reisen“ (siehe guix pull
aufrufen). Dadurch kann eine Instanz von Guix auf einer anderen Maschine oder
zu einem späteren Zeitpunkt genau nachgebildet werden, wodurch auch
vollständige Software-Umgebungen gänzlich nachgebildet werden können,
mit genauer Provenienzverfolgung, wo diese Software herkommt.
Nächste: Substitute, Vorige: Funktionalitäten, Nach oben: Paketverwaltung [Inhalt][Index]
guix package
aufrufenDer Befehl guix package
ist ein Werkzeug, womit Nutzer Pakete
installieren, aktualisieren, entfernen und auf vorherige Konfigurationen
zurücksetzen können. Diese Operationen arbeiten auf einem
Benutzerprofil, d.h. einem Verzeichnis, das installierte Pakete
enthält. Jeder Benutzer verfügt über ein Standardprofil in
$HOME/.guix-profile. Dabei wird nur das eigene Profil des Nutzers
verwendet, und es funktioniert mit normalen Benutzerrechten, ohne
Administratorrechte (siehe Funktionalitäten). Die Syntax ist:
guix package Optionen
In erster Linie geben die Optionen an, welche Operationen in der Transaktion durchgeführt werden sollen. Nach Abschluss wird ein neues Profil erzeugt, aber vorherige Generationen des Profils bleiben verfügbar, falls der Benutzer auf sie zurückwechseln will.
Um zum Beispiel lua
zu entfernen und guile
und
guile-cairo
in einer einzigen Transaktion zu installieren:
guix package -r lua -i guile guile-cairo
Um es Ihnen einfacher zu machen, bieten wir auch die folgenden Alias-Namen an:
guix search
ist eine andere Schreibweise für guix package
-s
,
guix install
ist eine andere Schreibweise für guix
package -i
,
guix remove
ist eine andere Schreibweise für guix package
-r
,
guix upgrade
ist eine andere Schreibweise für guix
package -u
guix show
ist eine andere Schreibweise für guix
package --show=
.
Diese Alias-Namen sind weniger ausdrucksstark als guix package
und
stellen weniger Befehlszeilenoptionen bereit, deswegen werden Sie vermutlich
manchmal guix package
direkt benutzen wollen.
guix package
unterstützt auch ein deklaratives Vorgehen,
wobei der Nutzer die genaue Menge an Paketen, die verfügbar sein sollen,
festlegt und über die Befehlszeilenoption --manifest übergibt
(siehe --manifest).
Für jeden Benutzer wird automatisch eine symbolische Verknüpfung zu seinem
Standardprofil angelegt als $HOME/.guix-profile. Diese symbolische
Verknüpfung zeigt immer auf die aktuelle Generation des Standardprofils des
Benutzers. Somit können Nutzer $HOME/.guix-profile/bin z.B. zu
ihrer Umgebungsvariablen PATH
hinzufügen.
Wenn Sie nicht Guix System benutzen, sollten Sie in Betracht ziehen,
folgende Zeilen zu Ihrem ~/.bash_profile hinzuzufügen (siehe
Bash Startup Files in Referenzhandbuch von GNU Bash), damit in
neu erzeugten Shells alle Umgebungsvariablen richtig definiert werden:
GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$GUIX_PROFILE/etc/profile"
Ist Ihr System für mehrere Nutzer eingerichtet, werden Nutzerprofile an
einem Ort gespeichert, der als Müllsammlerwurzel registriert ist, auf
die $HOME/.guix-profile zeigt (siehe guix gc
aufrufen). Dieses
Verzeichnis ist normalerweise
localstatedir/guix/profiles/per-user/Benutzer
, wobei
localstatedir der an configure
als --localstatedir
übergebene Wert ist und Benutzer für den jeweiligen Benutzernamen
steht. Das per-user-Verzeichnis wird erstellt, wenn
guix-daemon
gestartet wird, und das Unterverzeichnis
Benutzer wird durch guix package
erstellt.
Als Optionen kann vorkommen:
--install=Paket …
-i Paket …
Die angegebenen Pakete installieren.
Jedes Paket kann einfach durch seinen Paketnamen aufgeführt werden,
wie guile
, optional gefolgt von einem At-Zeichen @ und einer
Versionsnummer, wie guile@3.0.7
oder auch nur guile@3.0
. In
letzterem Fall wird die neueste Version mit Präfix 3.0
ausgewählt.
Wird keine Versionsnummer angegeben, wird die neueste verfügbare Version
ausgewählt. Zudem kann in der Spezifikation von Paket ein Doppelpunkt
auftauchen, gefolgt vom Namen einer der Ausgaben des Pakets, wie
gcc:doc
oder binutils@2.22:lib
(siehe Pakete mit mehreren Ausgaben.).
Pakete mit zugehörigem Namen (und optional der Version) werden unter den Modulen der GNU-Distribution gesucht (siehe Paketmodule).
Alternativ können Sie für Paket auch einen Dateinamen aus dem Store
direkt angeben, etwa /gnu/store/…-guile-3.0.7. Den Dateinamen
erfahren Sie zum Beispiel mit guix build
.
Manchmal haben Pakete propagierte Eingaben: Als solche werden
Abhängigkeiten bezeichnet, die automatisch zusammen mit dem angeforderten
Paket installiert werden (im Abschnitt propagated-inputs
in package
-Objekten sind weitere
Informationen über propagierte Eingaben in Paketdefinitionen zu finden).
Ein Beispiel ist die GNU-MPC-Bibliothek: Ihre C-Headerdateien verweisen auf die der GNU-MPFR-Bibliothek, welche wiederum auf die der GMP-Bibliothek verweisen. Wenn also MPC installiert wird, werden auch die MPFR- und GMP-Bibliotheken in das Profil installiert; entfernt man MPC, werden auch MPFR und GMP entfernt – außer sie wurden noch auf andere Art ausdrücklich vom Nutzer installiert.
Abgesehen davon setzen Pakete manchmal die Definition von Umgebungsvariablen für ihre Suchpfade voraus (siehe die Erklärung von --search-paths weiter unten). Alle fehlenden oder womöglich falschen Definitionen von Umgebungsvariablen werden hierbei gemeldet.
--install-from-expression=Ausdruck
-e Ausdruck
Das Paket installieren, zu dem der Ausdruck ausgewertet wird.
Beim Ausdruck muss es sich um einen Scheme-Ausdruck handeln, der zu
einem <package>
-Objekt ausgewertet wird. Diese Option ist besonders
nützlich, um zwischen gleichnamigen Varianten eines Pakets zu unterscheiden,
durch Ausdrücke wie (@ (gnu packages commencement) guile-final)
.
Beachten Sie, dass mit dieser Option die erste Ausgabe des angegebenen Pakets installiert wird, was unzureichend sein kann, wenn eine bestimmte Ausgabe eines Pakets mit mehreren Ausgaben gewünscht ist.
--install-from-file=Datei
-f Datei
Das Paket installieren, zu dem der Code in der Datei ausgewertet wird.
Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):
(use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+))
Entwickler könnten es für nützlich erachten, eine solche
guix.scm-Datei im Quellbaum ihres Projekts abzulegen, mit der
Zwischenstände der Entwicklung getestet und reproduzierbare
Erstellungsumgebungen aufgebaut werden können (siehe guix shell
aufrufen).
Es ist auch möglich, eine Datei mit einer JSON-Repräsentation von
einer oder mehr Paketdefinitionen anzugeben. Wenn Sie guix package -f
auf hello.json mit folgendem Inhalt ausführen würden, würde das Paket
greeter
installiert, nachdem myhello
erstellt wurde:
[ { "name": "myhello", "version": "2.10", "source": "mirror://gnu/hello/hello-2.10.tar.gz", "build-system": "gnu", "arguments": { "tests?": false }, "home-page": "https://www.gnu.org/software/hello/", "synopsis": "Hello, GNU world: An example GNU package", "description": "GNU Hello prints a greeting.", "license": "GPL-3.0+", "native-inputs": ["gettext"] }, { "name": "greeter", "version": "1.0", "source": "mirror://gnu/hello/hello-2.10.tar.gz", "build-system": "gnu", "arguments": { "test-target": "foo", "parallel-build?": false }, "home-page": "https://example.com/", "synopsis": "Greeter using GNU Hello", "description": "This is a wrapper around GNU Hello.", "license": "GPL-3.0+", "inputs": ["myhello", "hello"] } ]
--remove=Paket …
-r Paket …
Die angegebenen Pakete entfernen.
Wie auch bei --install kann jedes Paket neben dem Paketnamen
auch eine Versionsnummer und/oder eine Ausgabe benennen. Zum Beispiel würde
‘-r glibc:debug’ die debug
-Ausgabe von glibc
aus dem
Profil entfernen.
--upgrade[=Regexp …]
¶-u [Regexp …]
Alle installierten Pakete aktualisieren. Wenn einer oder mehr reguläre Ausdrücke (Regexps) angegeben wurden, werden nur diejenigen installierten Pakete aktualisiert, deren Name zu einer der Regexps passt. Siehe auch weiter unten die Befehlszeilenoption --do-not-upgrade.
Beachten Sie, dass das Paket so auf die neueste Version unter den Paketen
gebracht wird, die in der aktuell installierten Distribution vorliegen. Um
jedoch Ihre Distribution zu aktualisieren, sollten Sie regelmäßig
guix pull
ausführen (siehe guix pull
aufrufen).
Wenn Sie Ihre Pakete aktualisieren, werden die bei der Erstellung des vorherigen Profils angewandten Paketumwandlungen automatisch erneut angwandt (siehe Paketumwandlungsoptionen). Nehmen wir zum Beispiel an, Sie haben zuerst Emacs von der Spitze seines Entwicklungs-Branches installiert:
guix install emacs-next --with-branch=emacs-next=master
Wenn Sie das nächste Mal guix upgrade
ausführen, lädt Guix von
neuem die Spitze des Emacs-Entwicklungsbranches, um aus diesem Checkout
emacs-next
zu erstellen.
Beachten Sie, dass Umwandlungsoptionen wie --with-branch und --with-source von externem Zustand abhängen. Es liegt an Ihnen, sicherzustellen, dass sie wie erwartet funktionieren. Sie können auf Pakete angewandte Umwandlungen auch weglassen, indem Sie das ausführen:
guix install Paket
--do-not-upgrade[=Regexp …]
In Verbindung mit der Befehlszeilenoption --upgrade, führe keine Aktualisierung von Paketen durch, deren Name zum regulären Ausdruck Regexp passt. Um zum Beispiel alle Pakete im aktuellen Profil zu aktualisieren mit Ausnahme derer, die „emacs“ im Namen haben:
$ guix package --upgrade . --do-not-upgrade emacs
--manifest=Datei
¶-m Datei
Erstellt eine neue Generation des Profils aus dem vom Scheme-Code in Datei gelieferten Manifest-Objekt. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.
Dadurch könnrn Sie den Inhalt des Profils deklarieren, statt ihn durch eine Folge von Befehlen wie --install u.Ä. zu generieren. Der Vorteil ist, dass die Datei unter Versionskontrolle gestellt werden kann, auf andere Maschinen zum Reproduzieren desselben Profils kopiert werden kann und Ähnliches.
Der Code in der Datei muss ein Manifest-Objekt liefern, was ungefähr einer Liste von Paketen entspricht:
(use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Eine bestimmte Paketausgabe nutzen. (list guile-2.0 "debug")))
Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest schreibt. Siehe --export-manifest, um zu erfahren, wie Sie aus einem bestehenden Profil eine Manifestdatei erzeugen können.
--roll-back
¶Wechselt zur vorherigen Generation des Profils zurück – d.h. macht die letzte Transaktion rückgängig.
In Verbindung mit Befehlszeilenoptionen wie --install wird zuerst zurückgesetzt, bevor andere Aktionen durchgeführt werden.
Ein Rücksetzen der ersten Generation, die installierte Pakete enthält, wechselt das Profil zur nullten Generation, die keinerlei Dateien enthält, abgesehen von Metadaten über sich selbst.
Nach dem Zurücksetzen überschreibt das Installieren, Entfernen oder Aktualisieren von Paketen vormals zukünftige Generationen, d.h. der Verlauf der Generationen eines Profils ist immer linear.
--switch-generation=Muster
¶-S Muster
Wechselt zu der bestimmten Generation, die durch das Muster bezeichnet wird.
Als Muster kann entweder die Nummer einer Generation oder eine Nummer mit vorangestelltem „+“ oder „-“ dienen. Letzteres springt die angegebene Anzahl an Generationen vor oder zurück. Zum Beispiel kehrt --switch-generation=+1 nach einem Zurücksetzen wieder zur neueren Generation zurück.
Der Unterschied zwischen --roll-back und --switch-generation=-1 ist, dass --switch-generation keine nullte Generation erzeugen wird; existiert die angegebene Generation nicht, bleibt schlicht die aktuelle Generation erhalten.
--search-paths[=Art]
¶Führe die Definitionen von Umgebungsvariablen auf, in Bash-Syntax, die nötig sein könnten, um alle installierten Pakete nutzen zu können. Diese Umgebungsvariablen werden benutzt, um die Suchpfade für Dateien festzulegen, die von einigen installierten Paketen benutzt werden.
Zum Beispiel braucht GCC die Umgebungsvariablen CPATH
und
LIBRARY_PATH
, um zu wissen, wo sich im Benutzerprofil Header und
Bibliotheken befinden (siehe Environment Variables in Using the
GNU Compiler Collection (GCC)). Wenn GCC und, sagen wir, die C-Bibliothek
im Profil installiert sind, schlägt --search-paths also vor, diese
Variablen jeweils auf profile/include und
profile/lib verweisen zu lassen (siehe Suchpfade für
Informationen, wie Paketen Suchpfadspezifikationen zugeordnet werden).
Die typische Nutzung ist, in der Shell diese Variablen zu definieren:
$ eval $(guix package --search-paths)
Als Art kann entweder exact
, prefix
oder suffix
gewählt werden, wodurch die gelieferten Definitionen der Umgebungsvariablen
entweder exakt die Einstellungen für Guix meldet, oder sie als Präfix oder
Suffix an den aktuellen Wert dieser Variablen anhängt. Gibt man keine
Art an, wird der Vorgabewert exact
verwendet.
Diese Befehlszeilenoption kann auch benutzt werden, um die kombinierten Suchpfade mehrerer Profile zu berechnen. Betrachten Sie dieses Beispiel:
$ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths
Der letzte Befehl oben meldet auch die Definition der Umgebungsvariablen
GUILE_LOAD_PATH
, obwohl für sich genommen weder foo noch
bar zu dieser Empfehlung führen würden.
--profile=Profil
-p Profil
Auf Profil anstelle des Standardprofils des Benutzers arbeiten.
Als Profil muss der Name einer Datei angegeben werden, die dann nach Abschluss der Transaktion erzeugt wird. Konkret wird Profil nur zu einer symbolischen Verknüpfung („Symlink“) auf das eigentliche Profil gemacht, in das Pakete installiert werden.
$ guix install hello -p ~/code/mein-profil … $ ~/code/mein-profil/bin/hello Hallo, Welt!
Um das Profil loszuwerden, genügt es, die symbolische Verknüpfung und damit einhergehende Verknüpfungen, die auf bestimmte Generationen verweisen, zu entfernen:
$ rm ~/code/mein-profil ~/code/mein-profil-*-link
--list-profiles
Alle Profile des Benutzers auflisten:
$ guix package --list-profiles /home/charlie/.guix-profile /home/charlie/code/my-profile /home/charlie/code/devel-profile /home/charlie/tmp/test
Wird es als Administratornutzer „root“ ausgeführt, werden die Profile aller Benutzer aufgelistet.
--allow-collisions
Kollidierende Pakete im neuen Profil zulassen. Benutzung auf eigene Gefahr!
Standardmäßig wird guix package
Kollisionen als Fehler
auffassen und melden. Zu Kollisionen kommt es, wenn zwei oder mehr
verschiedene Versionen oder Varianten desselben Pakets im Profil landen.
--bootstrap
Erstellt das Profil mit dem Bootstrap-Guile. Diese Option ist nur für Entwickler der Distribution nützlich.
Zusätzlich zu diesen Aktionen unterstützt guix package
folgende
Befehlszeilenoptionen, um den momentanen Zustand eines Profils oder die
Verfügbarkeit von Paketen nachzulesen:
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
.
Zeigt Details über das Paket aus der Liste verfügbarer Pakete, im
recutils
-Format (siehe GNU-recutils-Datenbanken in GNU recutils manual).
$ guix package --show=guile | recsel -p name,version name: guile version: 3.0.5 name: guile version: 3.0.2 name: guile version: 2.2.7 …
Sie können auch den vollständigen Namen eines Pakets angeben, um Details nur
über diese Version angezeigt zu bekommen (diesmal benutzen wir die andere
Schreibweise guix show
):
$ guix show guile@3.0.5 | recsel -p name,version name: guile version: 3.0.5
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.
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.
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:
Durch --list-generations=1,8,2 werden drei Generationen in der angegebenen Reihenfolge angezeigt. Weder Leerzeichen noch ein Komma am Schluss der Liste ist erlaubt.
Sie können auch kein Bereichsende angeben, zum Beispiel liefert --list-generations=2.. alle Generationen ab der zweiten.
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.
Auf die Standardausgabe ein Manifest ausgeben, das mit --manifest genutzt werden kann und dem/den gewählten Profil(en) entspricht.
Diese Befehlszeilenoption erleichtert Ihnen den Wechsel vom „imperativen“
Betriebsmodus, wo Sie immer wieder guix install
, guix
upgrade
etc. ausführen, zum deklarativen Modus, der mit
--manifest zur Verfügung steht.
Seien Sie sich bewusst, dass das erzeugte Manifest nur eine Annäherung des Inhalts Ihres Profils ist. Je nachdem, wie Ihr Profil erzeugt wurde, kann es auf andere Pakete oder Paketversionen verweisen.
Beachten Sie, dass ein Manifest rein symbolisch ist; es enthält nur die Namen und vielleicht Versionen der Pakete, aber die Bedeutung davon wandelt sich mit der Zeit. Wenn Sie wollen, dass die Pakete aus immer derselben Kanalversion stammen, mit der das Profil oder die Profile erstellt wurden, siehe --export-channels unten.
Auf die Standardausgabe die Liste der Kanäle schreiben, die das gewählte
Profil benutzt bzw. die die gewählten Profile benutzen. Das Format der
Kanalspezifikation ist für guix pull --channels
und guix
time-machine --channels
geeignet (siehe Kanäle).
Zusammen mit --export-manifest macht diese Befehlszeilenoption Informationen verfügbar, um das aktuelle Profil nachzubilden (siehe Guix nachbilden).
Beachten Sie jedoch, dass die Ausgabe dieses Befehls nur eine Annäherung dessen ist, woraus ein Profil tatsächlich erstellt wurde. Insbesondere kann ein Profil aus mehreren Versionen desselben Kanals aufgebaut worden sein. In diesem Fall wählt --export-manifest die neueste aus und schreibt die anderen Versionen in einem Kommentar dazu. Wenn Sie wirklich Pakete aus unterschiedlichen Kanalversionen zu nehmen brauchen, können Sie dazu in Ihrem Manifest Untergeordnete angeben (siehe Untergeordnete).
Dies stellt zusammen mit --export-manifest eine gute Gelegenheit dar, wenn Sie bereit sind, vom „imperativen“ Modell auf das vollständig deklarative Modell zu wechseln, wo Sie eine Manifestdatei zusammen mit einer Kanaldatei benutzen, die ganz genau festlegt, welche Kanalversion(en) Sie wollen.
Zu guter Letzt können Sie, da guix package
Erstellungsprozesse zu
starten vermag, auch alle gemeinsamen Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen) verwenden. Auch Paketumwandlungsoptionen wie
--with-source sind möglich und bleiben über Aktualisierungen hinweg
erhalten (siehe Paketumwandlungsoptionen).
Nächste: Pakete mit mehreren Ausgaben., Vorige: guix package
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
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: Substitut-Server autorisieren, Nach oben: Substitute [Inhalt][Index]
bordeaux.guix.gnu.org
und ci.guix.gnu.org
sind jeweils Fassaden für offizielle Erstellungsfarmen („Build Farms“), die
kontinuierlich Guix-Pakete für einige Prozessorarchitekturen erstellen und
sie als Substitute zur Verfügung stellen. Sie sind 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 den offiziellen Erstellungsfarmen 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: Substitute von anderen Servern holen, Vorige: Offizielle Substitut-Server, Nach oben: Substitute [Inhalt][Index]
Um es Guix zu gestatten, Substitute von bordeaux.guix.gnu.org
,
ci.guix.gnu.org
oder einem Spiegelserver herunterzuladen,
müssen Sie die zugehörigen öffentlichen Schlüssel zur Access Control List
(ACL, Zugriffssteuerungsliste) für Archivimporte hinzufügen, mit Hilfe des
Befehls guix archive
(siehe guix archive
aufrufen). Dies
impliziert, dass Sie darauf vertrauen, dass der Substitutserver 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
bordeaux.guix.gnu.org
undci.guix.gnu.org
zu autorisieren.
Der öffentliche Schlüssel für jeden vom Guix-Projekt verwalteten
Substitutserver wird zusammen mit Guix installiert, in das Verzeichnis
prefix/share/guix/
, 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-123b722.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/bordeaux.guix.gnu.org.pub # 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 den festgelegten Substitutservern 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 von guix-daemon
). Er
kann auch temporär ausgeschaltet werden, indem Sie --no-substitutes
an guix package
, guix build
und andere
Befehlszeilenwerkzeuge übergeben.
Nächste: Substitutauthentifizierung, Vorige: Substitut-Server autorisieren, Nach oben: Substitute [Inhalt][Index]
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 zu den
vorgegebenen bordeaux.guix.gnu.org
und
ci.guix.gnu.org
auch 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:
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://bordeaux.guix.gnu.org https://ci.guix.gnu.org'
systemctl daemon-reload systemctl restart guix-daemon.service
guix archive
aufrufen):
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
bordeaux.guix.gnu.org
und dann
ci.guix.gnu.org
bleiben 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.
Problembehandlung: Der Befehl
guix weather
hilft Ihnen bei der Fehlerdiagnose. Wenn Sie zum Beispiel das ausführen:guix weather coreutilswird Ihnen nicht nur mitgeteilt, welcher der aktuell eingerichteten Server Substitute für das Paket
coreutils
bereitstellt, sondern auch ob einer der Server nicht autorisiert ist. Sieheguix weather
aufrufen für mehr Informationen.
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: Proxy-Einstellungen, Vorige: Substitute von anderen Servern holen, Nach oben: Substitute [Inhalt][Index]
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.org’ exakt 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-reproduzierbaren 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: Fehler bei der Substitution, Vorige: Substitutauthentifizierung, Nach oben: Substitute [Inhalt][Index]
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: Vom Vertrauen gegenüber Binärdateien, Vorige: Proxy-Einstellungen, Nach oben: Substitute [Inhalt][Index]
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 Substitutserver könnten offline sein, das Substitut könnte kürzlich gelöscht worden sein, die Netzwerkverbindung 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 guix weather
aufrufen). Dieser Befehl zeigt Statistiken darüber an, wie es um die
von einem Server verfügbaren Substitute steht.
Vorige: Fehler bei der Substitution, Nach oben: Substitute [Inhalt][Index]
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 zu
benutzen, ermuntern wir Nutzer, auch selbst Erstellungen durchzuführen oder
gar ihre eigene Erstellungsfarm zu betreiben, damit die vom Guix-Projekt
betriebenen Substitutserver ein weniger interessantes Ziel werden. 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
guix publish
aufrufen).
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 guix challenge
aufrufen). 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: guix locate
aufrufen, Vorige: Substitute, Nach oben: Paketverwaltung [Inhalt][Index]
Oft haben in Guix definierte Pakete eine einzige Ausgabe – d.h.
aus dem Quellpaket entsteht genau ein Verzeichnis im Store. Wenn Sie
guix install glibc
ausführen, wird die Standard-Paketausgabe des
GNU-libc-Pakets installiert; die Standardausgabe wird out
genannt,
aber ihr Name kann weggelassen werden, wie Sie am obigen Befehl sehen. In
diesem speziellen Fall enthält die Standard-Paketausgabe von glibc
alle C-Headerdateien, gemeinsamen Bibliotheken („Shared Libraries“),
statischen Bibliotheken („Static Libraries“), Dokumentation für Info sowie
andere zusätzliche Dateien.
Manchmal ist es besser, die verschiedenen Arten von Dateien, die aus einem
einzelnen Quellpaket hervorgehen, in getrennte Ausgaben zu unterteilen. Zum
Beispiel installiert die GLib-C-Bibliothek (die von GTK und damit
zusammenhängenden Paketen benutzt wird) mehr als 20 MiB an HTML-Seiten mit
Referenzdokumentation. Um den Nutzern, die das nicht brauchen, Platz zu
sparen, wird die Dokumentation in einer separaten Ausgabe abgelegt, genannt
doc
. Um also die Hauptausgabe von GLib zu installieren, zu der alles
außer der Dokumentation gehört, ist der Befehl:
guix install glib
Der Befehl, um die Dokumentation zu installieren, ist:
guix install glib:doc
Jedoch ist die Schreibweise mit Doppelpunkt nur richtig bei der
Spezifikation von Paketausgaben auf der Befehlszeile. Sie ist falsch, wenn
Sie eine Paket-Variable in Scheme-Code angeben. Um zum Beispiel die
Dokumentation von glib
zu den global installierten Paketen eines
operating-system
-Objekts hinzuzufügen (siehe operating-system
-Referenz), muss stattdessen eine Liste von zwei Einträgen verwendet
werden, als Erstes die Paket-Variable und als Zweites der Name der
gewählten Ausgabe:
(use-modules (gnu packages glib)) ;; glib-with-documentation ist das Guile-Symbol für das glib-Paket (operating-system … (packages (append (list (list glib-with-documentation "doc")) %base-packages)))
Manche Pakete installieren Programme mit unterschiedlich großem
„Abhängigkeiten-Fußabdruck“. Zum Beispiel installiert das Paket WordNet
sowohl Befehlszeilenwerkzeuge als auch grafische Benutzerschnittstellen
(GUIs). Erstere hängen nur von der C-Bibliothek ab, während Letztere auch
von Tcl/Tk und den zu Grunde liegenden X-Bibliotheken abhängen. Jedenfalls
belassen wir deshalb die Befehlszeilenwerkzeuge in der
Standard-Paketausgabe, während sich die GUIs in einer separaten Ausgabe
befinden. So können Benutzer, die die GUIs nicht brauchen, Platz sparen. Der
Befehl guix size
kann dabei helfen, solche Situationen zu erkennen
(siehe guix size
aufrufen). guix graph
kann auch helfen
(siehe guix graph
aufrufen).
In der GNU-Distribution gibt es viele solche Pakete mit mehreren
Ausgaben. Andere Konventionen für Ausgabenamen sind zum Beispiel lib
für Bibliotheken und eventuell auch ihre Header-Dateien, bin
für
eigenständige Programme und debug
für Informationen zur
Fehlerbehandlung (siehe Dateien zur Fehlersuche installieren). Die Ausgaben
eines Pakets stehen in der dritten Spalte der Anzeige von guix
package --list-available
(siehe guix package
aufrufen).
Nächste: guix gc
aufrufen, Vorige: Pakete mit mehreren Ausgaben., Nach oben: Paketverwaltung [Inhalt][Index]
guix locate
aufrufenUns steht solch eine Fülle an freier Software zur Verfügung, dass wir früher
oder später suchen müssen, welches Paket wir benötigen. Mit dem Befehl
guix search
, den wir bereits kennengelernt haben (siehe
guix package
aufrufen), können wir anhand von Schlüsselwörtern suchen:
guix search video editor
Manchmal möchte man eher wissen, in welchem Paket eine bestimmte Datei
angeboten wird. Hierfür ist guix locate
das Richtige. So können
Sie z.B. herausfinden, welches Paket den Befehl ls
verfügbar
macht:
$ guix locate ls coreutils@9.1 /gnu/store/…-coreutils-9.1/bin/ls
Natürlich funktioniert es auch mit anderen Dateien, nicht nur für Befehle:
$ guix locate unistr.h icu4c@71.1 /gnu/store/…/include/unicode/unistr.h libunistring@1.0 /gnu/store/…/include/unistr.h
Sie können auch glob-Muster mit Platzhaltern verwenden. Zum Beispiel würden Sie so nach Paketen suchen, die .service-Dateien verfügbar machen:
$ guix locate -g '*.service' man-db@2.11.1 …/lib/systemd/system/man-db.service wpa-supplicant@2.10 …/system-services/fi.w1.wpa_supplicant1.service
Der Befehl guix locate
braucht eine Datenbank, die Dateinamen zu
Paketnamen zuordnet. Nach den Vorgabeeinstellungen wird diese Datenbank
automatisch angelegt, wenn sie noch nicht existiert, wozu die lokal
verfügbaren Pakete betrachtet werden, was ein paar Minuten dauern kann (je
nachdem wie groß Ihr Store und wie schnell Ihr Speichermedium ist).
Anmerkung: Im Moment kann
guix locate
seine Datenbank nur auf lokalem Wissen aufbauen – Pakete außerhalb Ihres Stores werden nicht aufgenommen. Das soll sich noch ändern und dann wird es eine vorerstellte Datenbank herunterladen können, mit der sie auch andere Pakete finden können.
Vorgegeben ist, dass guix locate
zunächst schaut, ob eine
systemweite Datenbank vorhanden ist, in der Regel in
/var/cache/guix/locate. Wenn Sie nicht existiert oder zu alt
ist, wird stattdessen auf eine nutzereigene Datenbank zurückgegriffen,
vorgegeben ist ~/.cache/guix/locate. In einem Mehrbenutzersystem
können Administratoren die Aufgabe übernehmen, regelmäßig die systemweite
Datenbank zu aktualisieren, damit alle Benutzer etwas davon haben, zum
Beispiel mit Hilfe des package-database-service-type
(siehe package-database-service-type
).
Die allgemeine Syntax lautet:
guix locate [Optionen…] Datei…
Dabei ist Datei der Name einer aufzufindenden Datei (genauer gesagt ihr „Basisname“: Dateien, die ein Elternverzeichnis namens Datei haben, landen nicht im Ergebnis).
Folgende Optionen gibt es:
--glob
-g
Datei… werden als glob-Muster aufgefasst – also Muster, die auch Platzhalterzeichen enthalten können wie ‘*.scm’, was alle Dateien aufgreift, die in ‘.scm’ enden.
--stats
Statistiken über die Datenbank zeigen.
--update
-u
Die Datenbank mit den Dateien auf den neuesten Stand bringen.
Nach den Vorgabeeinstellungen wird die Datenbank dann aktualisiert, wenn sie zu alt ist.
--clear
Die Datenbank leeren und neu befüllen.
Mit dieser Befehlszeilenoption können sie von vorn anfangen, so dass alte
Daten nicht mehr in der Datenbank auftauchen. So stellen Sie sicher,
dass die Datenbank nicht endlos anwächst. Nach den Vorgabeeinstellungen für
guix locate
geschieht das regelmäßig automatisch, wenn auch nicht
oft.
--database=Datei
Die Datei als Datenbank benutzen. Wenn nötig, wird sie erzeugt.
Nach den Vorgabeeinstellungen benutzt guix locate
die Datenbank
unter ~/.cache/guix oder /var/cache/guix, je nachdem, welche
neuer ist.
--method=Methode
-m Methode
Nach der Methode auswählen, welche Pakete in den Index aufgenommn werden. Mögliche Werte sind:
manifests
Dies ist die vorgegebene Methode: Für sie werden die Profile auf der Maschine betrachtet und die darin vorkommenden Pakete ermittelt – das sind die Pakete, die Sie oder andere Benutzer derselben Maschine direkt oder indirekt installiert haben. Das geht schnell, aber Pakete, die aus anderem Grund im Store sind, fehlen, wenn kein Profil darauf verweist.
store
Diese Methode ist langsamer, aber gründlicher: Alle Pakete, die im Store vorhanden sind, werden in die Datenbank aufgenommen.
Nächste: guix pull
aufrufen, Vorige: guix locate
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
guix gc
aufrufenPakete, die zwar installiert sind, aber nicht benutzt werden, können vom
Müllsammler entfernt werden. Mit dem Befehl guix gc
können
Benutzer den Müllsammler ausdrücklich aufrufen, um Speicher im Verzeichnis
/gnu/store freizugeben. Dies ist der einzige Weg, Dateien aus
/gnu/store zu entfernen – das manuelle Entfernen von Dateien
kann den Store irreparabel beschädigen!
Der Müllsammler kennt eine Reihe von Wurzeln: Jede Datei in
/gnu/store, die von einer Wurzel aus erreichbar ist, gilt als
lebendig und kann nicht entfernt werden; jede andere Datei gilt als
tot und ist ein Kandidat, gelöscht zu werden. Die Menge der
Müllsammlerwurzeln (kurz auch „GC-Wurzeln“, von englisch „Garbage
Collector“) umfasst Standard-Benutzerprofile; standardmäßig werden diese
Müllsammlerwurzeln durch symbolische Verknüpfungen in
/var/guix/gcroots dargestellt. Neue Müllsammlerwurzeln können zum
Beispiel mit guix build --root
festgelegt werden (siehe
Aufruf von guix build
). Der Befehl guix gc --list-roots
listet
sie auf.
Bevor Sie mit guix gc --collect-garbage
Speicher freimachen, wollen
Sie vielleicht alte Generationen von Benutzerprofilen löschen, damit alte
Paketerstellungen von diesen Generationen entfernt werden können. Führen Sie
dazu guix package --delete-generations
aus (siehe guix package
aufrufen).
Unsere Empfehlung ist, dass Sie den Müllsammler regelmäßig laufen lassen und wenn Sie wenig freien Speicherplatz zur Verfügung haben. Um zum Beispiel sicherzustellen, dass Sie mindestens 5 GB auf Ihrer Platte zur Verfügung haben, benutzen Sie einfach:
guix gc -F 5G
Es ist völlig sicher, dafür eine nicht interaktive, regelmäßige
Auftragsausführung vorzugeben (siehe Geplante Auftragsausführung für eine
Erklärung, wie man das tun kann). guix gc
ohne
Befehlszeilenargumente auszuführen, lässt so viel Müll wie möglich sammeln,
aber das ist oft nicht, was man will, denn so muss man unter Umständen
Software erneut erstellen oder erneut herunterladen, weil der Müllsammler
sie als „tot“ ansieht, sie aber zur Erstellung anderer Software wieder
gebraucht wird – das trifft zum Beispiel auf die Compiler-Toolchain zu.
Der Befehl guix gc
hat drei Arbeitsmodi: Er kann benutzt werden,
um als Müllsammler tote Dateien zu entfernen (das Standardverhalten), um
ganz bestimmte, angegebene Datein zu löschen (mit der Befehlszeilenoption
--delete), um Müllsammlerinformationen auszugeben oder
fortgeschrittenere Anfragen zu verarbeiten. Die
Müllsammler-Befehlszeilenoptionen sind wie folgt:
--collect-garbage[=Minimum]
-C [Minimum]
Lässt Müll sammeln – z.B. nicht erreichbare Dateien in /gnu/store und seinen Unterverzeichnissen. Wird keine andere Befehlszeilenoption angegeben, wird standardmäßig diese durchgeführt.
Wenn ein Minimum angegeben wurde, hört der Müllsammler auf, sobald
Minimum Bytes gesammelt wurden. Das Minimum kann die Anzahl der
Bytes bezeichnen oder mit einer Einheit als Suffix versehen sein, wie etwa
MiB
für Mebibytes und GB
für Gigabytes (siehe Größenangaben in GNU Coreutils).
Wird kein Minimum angegeben, sammelt der Müllsammler allen Müll.
--free-space=Menge
-F Menge
Sammelt Müll, bis die angegebene Menge an freiem Speicher in
/gnu/store zur Verfügung steht, falls möglich; die Menge ist
eine Speichergröße wie 500MiB
, wie oben beschrieben.
Wenn die angegebene Menge oder mehr bereits in /gnu/store frei verfügbar ist, passiert nichts.
--delete-generations[=Dauer]
-d [Dauer]
Bevor der Müllsammelvorgang beginnt, werden hiermit alle Generationen von allen Benutzerprofilen und von allen Persönlichen Umgebungen gelöscht, die älter sind als die angegebene Dauer; wird es als Administratornutzer „root“ ausgeführt, geschieht dies mit den Profilen von allen Benutzern.
Zum Beispiel löscht der folgende Befehl alle Generationen Ihrer Profile, die älter als zwei Monate sind (ausgenommen die momentanen Generationen), und schmeißt dann den Müllsammler an, um Platz freizuräumen, bis mindestens 10 GiB verfügbar sind:
guix gc -d 2m -F 10G
--delete
-D
Versucht, alle als Argumente angegebenen Dateien oder Verzeichnisse im Store zu löschen. Dies schlägt fehl, wenn manche der Dateien oder Verzeichnisse nicht im Store oder noch immer lebendig sind.
--list-failures
Store-Objekte auflisten, die zwischengespeicherten Erstellungsfehlern entsprechen.
Hierbei wird nichts ausgegeben, sofern der Daemon nicht mit --cache-failures gestartet wurde (siehe --cache-failures).
--list-roots
Die Müllsammlerwurzeln auflisten, die dem Nutzer gehören. Wird der Befehl als Administratornutzer ausgeführt, werden alle Müllsammlerwurzeln aufgelistet.
--list-busy
Solche Store-Objekte auflisten, die von aktuell laufenden Prozessen benutzt werden. Diese Store-Objekte werden praktisch wie Müllsammlerwurzeln behandelt; sie können nicht gelöscht werden.
--clear-failures
Die angegebenen Store-Objekte aus dem Zwischenspeicher für fehlgeschlagene Erstellungen entfernen.
Auch diese Option macht nur Sinn, wenn der Daemon mit --cache-failures gestartet wurde. Andernfalls passiert nichts.
--list-dead
Zeigt die Liste toter Dateien und Verzeichnisse an, die sich noch im Store befinden – das heißt, Dateien, die von keiner Wurzel mehr erreichbar sind.
--list-live
Zeige die Liste lebendiger Store-Dateien und -Verzeichnisse.
Außerdem können Referenzen unter bestehenden Store-Dateien gefunden werden:
--references
¶--referrers
Listet die referenzierten bzw. sie referenzierenden Objekte der angegebenen Store-Dateien auf.
--requisites
¶-R
Listet alle Voraussetzungen der als Argumente übergebenen Store-Dateien auf. Voraussetzungen sind die Store-Dateien selbst, ihre Referenzen sowie die Referenzen davon, rekursiv. Mit anderen Worten, die zurückgelieferte Liste ist der transitive Abschluss dieser Store-Dateien.
Der Abschnitt guix size
aufrufen erklärt ein Werkzeug, um den
Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe
guix graph
aufrufen für ein Werkzeug, um den Referenzgraphen zu
veranschaulichen.
--derivers
¶Liefert die Ableitung(en), die zu den angegebenen Store-Objekten führen (siehe Ableitungen).
Zum Beispiel liefert dieser Befehl:
guix gc --derivers $(guix package -I ^emacs$ | cut -f4)
die .drv-Datei(en), die zum in Ihrem Profil installierten
emacs
-Paket führen.
Beachten Sie, dass es auch sein kann, dass keine passenden .drv-Dateien existieren, zum Beispiel wenn diese Dateien bereits dem Müllsammler zum Opfer gefallen sind. Es kann auch passieren, dass es mehr als eine passende .drv gibt, bei Ableitungen mit fester Ausgabe.
Zuletzt können Sie mit folgenden Befehlszeilenoptionen die Integrität des Stores prüfen und den Plattenspeicherverbrauch im Zaum halten.
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
).
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.
Für Guix wird eine SQLite-Datenbank verwendet, um über die Objekte im Store
Buch zu führen (siehe Der Store). Mit der Zeit kann die Datenbank
jedoch eine gigantische Größe erreichen und fragmentieren. Deshalb kann es
sich lohnen, den freien Speicher aufzuräumen und nur teilweise genutzte
Datenbankseiten, die beim Löschen von Paketen bzw. nach dem Müllsammeln
entstanden sind, zusammenzulegen. Führen Sie sudo guix gc
--vacuum-database
aus, und die Datenbank wird gesperrt und eine
VACUUM
-Operation auf dem Store durchgeführt, welche die Datenbank
defragmentiert und leere Seiten wegschafft. Wenn alles fertig ist, wird die
Datenbank entsperrt.
Nächste: guix time-machine
aufrufen, Vorige: guix gc
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
guix pull
aufrufenNach 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:
channels
von
guix-configuration
),
%default-channels
festgelegt sind.
Danach wird guix package
Pakete und ihre Versionen entsprechend
der gerade heruntergeladenen Kopie von Guix benutzen. Nicht nur das, auch
alle Guix-Befehle und Scheme-Module werden aus der neuesten Version von Guix
kommen. Neue guix
-Unterbefehle, die durch die Aktualisierung
hinzugekommen sind, werden also auch verfügbar.
Jeder Nutzer kann seine Kopie von Guix mittels guix pull
aktualisieren, wodurch sich nur für den Nutzer etwas verändert, der
guix pull
ausgeführt hat. Wenn also zum Beispiel der
Administratornutzer root
den Befehl guix pull
ausführt, hat
das keine Auswirkungen auf die für den Benutzer alice
sichtbare
Guix-Version, und umgekehrt.
Das Ergebnis von guix pull
ist ein als
~/.config/guix/current verfügbares Profil mit dem neuesten
Guix.
Die Befehlszeilenoption --list-generations oder kurz -l
listet ältere von guix pull
erzeugte Generationen auf, zusammen
mit Informationen zu deren Provenienz.
$ guix pull -l Generation 1 10. Juni 2018 00:18:18 guix 65956ad Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: origin/master Commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe Generation 2 11. Juni 2018 11:02:49 guix e0cc7f6 Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: origin/master Commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d Generation 3 13. Juni 2018 23:31:07 (aktuell) guix 844cc1c Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: origin/master Commit: 844cc1c8f394f03b404c5bb3aee086922373490c
Im Abschnitt guix describe
werden
andere Möglichkeiten erklärt, sich den momentanen Zustand von Guix
beschreiben zu lassen.
Das Profil ~/.config/guix/current
verhält sich genau wie die durch
guix package
erzeugten Profile (siehe guix package
aufrufen). Das bedeutet, Sie können seine Generationen auflisten und es auf
die vorherige Generation – also das vorherige Guix – zurücksetzen
und so weiter:
$ guix pull --roll-back Von Generation „3“ zu „2“ gewechselt $ guix pull --delete-generations=1 /var/guix/profiles/per-user/charlie/current-guix-1-link wird gelöscht
Sie können auch guix package
benutzen (siehe guix package
aufrufen), um das Profil zu verwalten, indem Sie es explizit angeben.:
$ guix package -p ~/.config/guix/current --roll-back switched from generation 3 to 2 $ guix package -p ~/.config/guix/current --delete-generations=1 deleting /var/guix/profiles/per-user/charlie/current-guix-1-link
Der Befehl guix pull
wird in der Regel ohne Befehlszeilenargumente
aufgerufen, aber er versteht auch folgende Befehlszeilenoptionen:
--url=URL
--commit=Commit
--branch=Branch
Code wird für den guix
-Kanal von der angegebenen URL für den
angegebenen Commit (eine gültige Commit-ID, dargestellt als
hexadezimale Zeichenkette oder Namen eines Git-Tags) oder Branch
heruntergeladen.
Diese Befehlszeilenoptionen sind manchmal bequemer, aber Sie können Ihre Konfiguration auch in der Datei ~/.config/guix/channels.scm oder über die Option --channels angeben (siehe unten).
--channels=Datei
-C Datei
Die Liste der Kanäle aus der angegebenen Datei statt aus ~/.config/guix/channels.scm oder aus /etc/guix/channels.scm auslesen. Die Datei muss Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet wird. Siehe Kanäle für nähere Informationen.
--no-channel-files
-q
Unterdrückt das Laden der Kanaldatei des Benutzers ~/.config/guix/channels.scm und der systemweiten Kanaldatei /etc/guix/channels.scm.
--news
-N
Neuigkeiten anzeigen, die Kanalautoren für ihre Nutzer geschrieben haben, um sie über Veränderungen seit der vorigen Generation in Kenntnis zu setzen (siehe Kanalneuigkeiten verfassen). Wenn Sie --details übergeben, werden auch neue und aktualisierte Pakete gezeigt.
Sie können sich mit guix pull -l
diese Informationen für vorherige
Generationen ansehen.
--list-generations[=Muster]
-l [Muster]
Alle Generationen von ~/.config/guix/current bzw., wenn ein
Muster angegeben wird, die dazu passenden Generationen auflisten. Die
Syntax für das Muster ist dieselbe wie bei guix package
--list-generations
(siehe guix package
aufrufen).
Nach Voreinstellung werden Informationen über die benutzten Kanäle in der jeweiligen Version sowie die zugehörigen Neuigkeiten ausgegeben. Wenn Sie --details übergeben, wird außerdem die Liste der neu hinzugefügten oder aktualisierten Pakete in jeder Generation verglichen mit der vorigen angezeigt.
--details
Bei --list-generations oder --news wird Guix angewiesen, mehr Informationen über die Unterschiede zwischen aufeinanderfolgenden Generationen anzuzeigen – siehe oben.
--roll-back
¶Zur vorherigen Generation von ~/.config/guix/current zurückwechseln – d.h. die letzte Transaktion rückgängig machen.
--switch-generation=Muster
¶-S Muster
Wechselt zu der bestimmten Generation, die durch das Muster bezeichnet wird.
Als Muster kann entweder die Nummer einer Generation oder eine Nummer mit vorangestelltem „+“ oder „-“ dienen. Letzteres springt die angegebene Anzahl an Generationen vor oder zurück. Zum Beispiel kehrt --switch-generation=+1 nach einem Zurücksetzen wieder zur neueren Generation zurück.
--delete-generations[=Muster]
-d [Muster]
Wird kein Muster angegeben, werden alle Generationen außer der aktuellen entfernt.
Dieser Befehl akzeptiert dieselben Muster wie --list-generations. Wenn ein Muster angegeben wird, werden die passenden Generationen gelöscht. Wenn das Muster für eine Zeitdauer steht, werden diejenigen Generationen gelöscht, die älter als die angegebene Dauer sind. Zum Beispiel löscht --delete-generations=1m die Generationen, die mehr als einen Monat alt sind.
Falls die aktuelle Generation zum Muster passt, wird sie nicht gelöscht.
Beachten Sie, dass Sie auf gelöschte Generationen nicht zurückwechseln können. Dieser Befehl sollte also nur mit Vorsicht benutzt werden.
Im Abschnitt guix describe
wird eine
Möglichkeit erklärt, sich Informationen nur über die aktuelle Generation
anzeigen zu lassen.
--profile=Profil
-p Profil
Auf Profil anstelle von ~/.config/guix/current arbeiten.
--dry-run
-n
Anzeigen, welche(r) Commit(s) für die Kanäle benutzt würde(n) und was jeweils erstellt oder substituiert würde, ohne es tatsächlich durchzuführen.
--allow-downgrades
Beziehen einer älteren oder mit der bisheriger Version eines Kanals nicht zusammenhängenden Version zulassen.
Nach Voreinstellung schützt guix pull
den Nutzer vor
Herabstufungsangriffen („Downgrade Attacks“). Damit werden Versuche
bezeichnet, jemanden eine frühere oder unzusammenhängende Version des
Git-Repositorys eines Kanals benutzen zu lassen, wodurch diese Person dazu
gebracht werden kann, ältere Versionen von Softwarepaketen mit bekannten
Schwachstellen zu installieren.
Anmerkung: Sie sollten verstehen, was es für die Sicherheit Ihres Rechners bedeutet, ehe Sie --allow-downgrades benutzen.
--disable-authentication
Beziehen von Kanalcode ohne Authentifizierung zulassen.
Nach Voreinstellung wird durch guix pull
von Kanälen
heruntergeladener Code darauf überprüft, dass deren Commits durch
autorisierte Entwickler signiert worden sind; andernfalls wird ein Fehler
gemeldet. Mit dieser Befehlszeilenoption können Sie anweisen, keine solche
Verifikation durchzuführen.
Anmerkung: Sie sollten verstehen, was es für die Sicherheit Ihres Rechners bedeutet, ehe Sie --disable-authentication benutzen.
--system=System
-s System
Versuchen, für die angegebene Art von System geeignete Binärdateien zu
erstellen – z.B. i686-linux
– statt für die Art von
System, das die Erstellung durchführt.
--bootstrap
Das neueste Guix mit dem Bootstrap-Guile erstellen. Diese Befehlszeilenoption ist nur für Guix-Entwickler von Nutzen.
Mit Hilfe von Kanälen können Sie guix pull
anweisen, von
welchem Repository und welchem Branch Guix aktualisiert werden soll, sowie
von welchen weiteren Repositorys Paketmodule bezogen werden
sollen. Im Abschnitt Kanäle finden Sie nähere Informationen.
Außerdem unterstützt guix pull
alle gemeinsamen
Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen).
Nächste: Untergeordnete, Vorige: guix pull
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
guix time-machine
aufrufenDer Befehl guix time-machine
erleichtert den Zugang zu anderen
Versionen von Guix. Damit können ältere Versionen von Paketen installiert
werden oder eine Berechnung in einer identischen Umgebung reproduziert
werden. Die zu benutzende Guix-Version wird über eine Commit-Angabe oder
eine Kanalbeschreibungsdatei, wie sie durch guix describe
erzeugt
werden kann, festgelegt (siehe guix describe
aufrufen).
Sagen wir, Sie würden gerne in der Zeit zurückreisen zu den Tagen um
November 2020, als die Version 1.2.0 von Guix veröffentlicht worden ist, und
außerdem möchten Sie nach Ihrer Ankunft den damaligen guile
-Befehl
ausführen:
guix time-machine --commit=v1.2.0 -- \ environment -C --ad-hoc guile -- guile
Mit obigem Befehl wird Guix 1.2.0 geladen (möglicherweise auch andere
Kanäle, die in Ihren channels.scm genannten Konfigurationsdateien
festgelegt sind – siehe unten) und daraufhin dessen Befehl
guix environment
ausgeführt, um eine Umgebung, in einen Container
verpackt, zu betreten, wo dann guile
gestartet wird (guix
environment
ist mittlerweile Teil von guix shell
, siehe
guix shell
aufrufen). Es ist so, als würden Sie einen DeLorean
fahren12! Der erste Aufruf von guix time-machine
kann lange
dauern, weil vielleicht viele Pakete heruntergeladen oder sogar erstellt
werden müssen, aber das Ergebnis bleibt in einem Zwischenspeicher und danach
geschehen Befehle für denselben Commit fast sofort.
Wie auch bei guix pull
werden, wenn keine abweichenden
Befehlszeilenoptionen angegeben wurden, mit time-machine
die
neuesten Commits derjenigen Kanäle geladen, die in
~/.config/guix/channels.scm, /etc/guix/channels.scm oder den
vorgegebenen Kanälen festgelegt sind. Die Konfigurationsdateien können Sie
mit der Befehlszeilenoption -q ignorieren lassen. Mit dem Befehl:
guix time-machine -q -- build hello
wird dementsprechend das Paket hello
erstellt, so wie es auf Guix’
Haupt-Branch ohne zusätzliche Kanäle definiert ist, was in der Regel einer
neueren Guix-Version entspricht als der, die Sie installiert
haben. Zeitreisen funktionieren also in beide Richtungen!
Anmerkung: Vergangene Commits zu Guix sind unveränderlich und
guix time-machine
bietet genau dieselbe Software, wie sie in einer damaligen Guix-Version bestanden hat. Demzufolge werden auch keine Sicherheitspatches für alte Versionen von Guix oder dessen Kanäle nachgeliefert. Unbedachter Gebrauch derguix time-machine
lässt Sicherheitsschwachstellen freien Raum. Siehe --allow-downgrades.
Einen Fehler meldet guix time-machine
, wenn Sie eine Zeitreise zu
einem älteren Commit als „v0.16.0“ (Commit ‘4a0b87f0’) vom Dezember
2018 versuchen. Es handelt sich um einen der frühesten Commits, der den
Kanalmechanismus unterstützt hat, durch den „Zeitreisen“ möglich werden.
Anmerkung: Technisch gesehen sollte es zwar möglich sein, so einen alten Commit von Guix zu besuchen, aber Sie müssen unter Umständen einige Hürden überwinden, falls keine Substitute der Binärdateien mehr angeboten werden. Wenn Sie in die ferne Vergangenheit reisen, können manche Pakete vielleicht nicht mehr so einfach aus ihrem Quellcode erstellt werden. Ein Beispiel dafür sind alte Versionen von OpenSSL, dessen Tests fehlschlagen, wenn ein bestimmtes Datum vergangen ist. Dieses spezielle Problem lässt sich umgehen, indem Sie eine virtuelle Erstellungsmaschine einrichten, deren Uhr Sie auf einen passenden Zeitpunkt zurückdrehen (siehe Virtuelle Erstellungsmaschinen).
Die allgemeine Syntax lautet:
guix time-machine Optionen… -- Befehl Argument…
Dabei werden der Befehl und jedes Argument… unverändert an den
guix
-Befehl der angegebenen Version übergeben. Die Optionen,
die die Version definieren, sind dieselben wie bei guix pull
(siehe guix pull
aufrufen):
--url=URL
--commit=Commit
--branch=Branch
Den guix
-Kanal von der angegebenen URL benutzen, für den
angegebenen Commit (eine gültige Commit-ID, dargestellt als
hexadezimale Zeichenkette oder Namen eines Git-Tags) oder Branch.
--channels=Datei
-C Datei
Die Liste der Kanäle aus der angegebenen Datei auslesen. Die Datei muss Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet wird. Siehe Kanäle für nähere Informationen.
--no-channel-files
-q
Unterdrückt das Laden der Kanaldatei des Benutzers ~/.config/guix/channels.scm und der systemweiten Kanaldatei /etc/guix/channels.scm.
Anstelle von guix time-machine -q
können Sie daher auch den
folgenden Bash-Befehl verwenden, der die Syntax für „Prozesssubstitutionen“
verwendet (siehe Process Substitution in Referenzhandbuch zu GNU
Bash):
guix time-machine -C <(echo %default-channels) …
Beachten Sie, dass durch guix time-machine
Erstellungen von
Kanälen und deren Abhängigkeiten ausgelöst werden können, welche durch die
gemeinsamen Erstellungsoptionen gesteuert werden können (siehe Gemeinsame Erstellungsoptionen).
Nächste: guix describe
aufrufen, Vorige: guix time-machine
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
Anmerkung: Die hier beschriebenen Funktionalitäten sind in der Version 123b722 bloß eine „Technologie-Vorschau“, daher kann sich die Schnittstelle in Zukunft noch ändern.
Manchmal könnten Sie Pakete aus der gerade laufenden Fassung von Guix mit denen mischen wollen, die in einer anderen Guix-Version verfügbar sind. Guix-Untergeordnete ermöglichen dies, indem Sie verschiedene Guix-Versionen beliebig mischen können.
Aus technischer Sicht ist ein „Untergeordneter“ im Kern ein separater
Guix-Prozess, der über eine REPL (siehe guix repl
aufrufen) mit Ihrem
Haupt-Guix-Prozess verbunden ist. Das Modul (guix inferior)
ermöglicht es Ihnen, Untergeordnete zu erstellen und mit ihnen zu
kommunizieren. Dadurch steht Ihnen auch eine hochsprachliche Schnittstelle
zur Verfügung, um die von einem Untergeordneten angebotenen Pakete zu
durchsuchen und zu verändern – untergeordnete Pakete.
In Kombination mit Kanälen (siehe Kanäle) bieten Untergeordnete eine
einfache Möglichkeit, mit einer anderen Version von Guix zu
interagieren. Nehmen wir zum Beispiel an, Sie wollen das aktuelle
guile
-Paket in Ihr Profil installieren, zusammen mit dem
guile-json
, wie es in einer früheren Guix-Version existiert
hat – vielleicht weil das neuere guile-json
eine inkompatible
API hat und Sie daher Ihren Code mit der alten API benutzen möchten. Dazu
könnten Sie ein Manifest für guix package --manifest
schreiben (siehe
Manifeste verfassen); in diesem Manifest würden Sie einen
Untergeordneten für diese alte Guix-Version erzeugen, für die Sie sich
interessieren, und aus diesem Untergeordneten das guile-json
-Paket
holen:
(use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;für die Prozedur 'first' (define channels ;; Dies ist die alte Version, aus der wir ;; guile-json extrahieren möchten. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; Ein Untergeordneter, der obige Version repräsentiert. (inferior-for-channels channels)) ;; Daraus erzeugen wir jetzt ein Manifest mit dem aktuellen ;; „guile“-Paket und dem alten „guile-json“-Paket. (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile")))
Bei seiner ersten Ausführung könnte für guix package --manifest
erst der angegebene Kanal erstellt werden müssen, bevor der Untergeordnete
erstellt werden kann; nachfolgende Durchläufe sind wesentlich schneller,
weil diese Guix-Version bereits zwischengespeichert ist.
Folgende Prozeduren werden im Modul (guix inferior)
angeboten, um
einen Untergeordneten zu öffnen:
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.
Ö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.
Liefert die Liste der Pakete in Untergeordneter.
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.
Liefert wahr, wenn das Objekt ein Untergeordneter ist.
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: guix archive
aufrufen, Vorige: Untergeordnete, Nach oben: Paketverwaltung [Inhalt][Index]
guix describe
aufrufenSie könnten sich des Öfteren Fragen stellen wie: „Welche Version von Guix
benutze ich gerade?“ oder „Welche Kanäle benutze ich?“ Diese Informationen
sind in vielen Situationen nützlich: wenn Sie eine Umgebung auf einer
anderen Maschine oder mit einem anderen Benutzerkonto nachbilden
möchten, wenn Sie einen Fehler melden möchten, wenn Sie festzustellen
versuchen, welche Änderung an den von Ihnen verwendeten Kanälen diesen
Fehler verursacht hat, oder wenn Sie Ihren Systemzustand zum Zweck der
Reproduzierbarkeit festhalten möchten. Der Befehl guix describe
gibt Ihnen Antwort auf diese Fragen.
Wenn Sie ihn aus einem mit guix pull
bezogenen guix
heraus ausführen, zeigt Ihnen guix describe
die Kanäle an, aus
denen es erstellt wurde, jeweils mitsamt ihrer Repository-URL und Commit-ID
(siehe Kanäle):
$ guix describe Generation 10 03. September 2018 17:32:44 (aktuell) guix e0fa68c Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: master Commit: e0fa68c7718fffd33d81af415279d6ddb518f727
Wenn Sie mit dem Versionskontrollsystem Git vertraut sind, erkennen Sie
vielleicht die Ähnlichkeit zu git describe
; die Ausgabe ähnelt
auch der von guix pull --list-generations
eingeschränkt auf die
aktuelle Generation (siehe die Befehlszeilenoption
--list-generations). Weil die oben gezeigte Git-Commit-ID
eindeutig eine bestimmte Version von Guix bezeichnet, genügt diese
Information, um die von Ihnen benutzte Version von Guix zu beschreiben, und
auch, um sie nachzubilden.
Damit es leichter ist, Guix nachzubilden, kann Ihnen guix describe
auch eine Liste der Kanäle statt einer menschenlesbaren Beschreibung wie
oben liefern:
$ guix describe -f channels (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "e0fa68c7718fffd33d81af415279d6ddb518f727") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))))
Sie können die Ausgabe in einer Datei speichern, die Sie an guix
pull -C
auf einer anderen Maschine oder zu einem späteren Zeitpunkt
übergeben, wodurch dann eine Instanz von genau derselben Guix-Version
installiert wird (siehe die Befehlszeilenoption
-C). Daraufhin können Sie, weil Sie jederzeit dieselbe Version von
Guix installieren können, auch gleich eine vollständige
Softwareumgebung genau nachbilden. Wir halten das trotz aller
Bescheidenheit für klasse und hoffen, dass Ihnen das auch gefällt!
Die genauen Befehlszeilenoptionen, die guix describe
unterstützt,
lauten wie folgt:
--format=Format
-f Format
Die Ausgabe im angegebenen Format generieren, was eines der Folgenden sein muss:
human
für menschenlesbare Ausgabe,
channels
eine Liste von Kanalspezifikationen erzeugen, die an guix pull -C
übergeben werden oder als ~/.config/guix/channels.scm eingesetzt
werden können (siehe guix pull
aufrufen),
channels-sans-intro
verhält sich wie channels
, aber ohne das introduction
-Feld;
benutzen Sie es, um eine Kanalspezifikation zu erzeugen, die für die
Guix-Version 1.1.0 oder früher geeignet ist – das
introduction
-Feld ist für Kanalauthentifizierung gedacht (siehe
Kanalauthentifizierung), die von diesen älteren Versionen
nicht unterstützt wird,
json
¶generiert eine Liste von Kanalspezifikationen im JSON-Format,
recutils
generiert eine Liste von Kanalspezifikationen im Recutils-Format.
--list-formats
Verfügbare Formate für die Befehlszeilenoption --format anzeigen.
--profile=Profil
-p Profil
Informationen über das Profil anzeigen.
Vorige: guix describe
aufrufen, Nach oben: Paketverwaltung [Inhalt][Index]
guix archive
aufrufenDer Befehl guix archive
ermöglicht es Nutzern, Dateien im Store in
eine einzelne Archivdatei zu exportieren und diese später auf einer
Maschine, auf der Guix läuft, zu importieren. Insbesondere können so
Store-Objekte von einer Maschine in den Store einer anderen Maschine
übertragen werden.
Anmerkung: Wenn Sie nach einer Möglichkeit suchen, Archivdateien für andere Werkzeuge als Guix zu erstellen, finden Sie Informationen dazu im Abschnitt
guix pack
aufrufen.
Führen Sie Folgendes aus, um Store-Dateien als ein Archiv auf die Standardausgabe zu exportieren:
guix archive --export Optionen Spezifikationen…
Spezifikationen sind dabei entweder die Namen von Store-Dateien oder
Paketspezifikationen wie bei guix package
(siehe guix package
aufrufen). Zum Beispiel erzeugt der folgende Befehl ein Archiv der
gui
-Ausgabe des Pakets git
sowie die Hauptausgabe von
emacs
:
guix archive --export git:gui /gnu/store/…-emacs-24.3 > groß.nar
Wenn die angegebenen Pakete noch nicht erstellt worden sind, werden sie
durch guix archive
automatisch erstellt. Der Erstellungsprozess
kann durch die gemeinsamen Erstellungsoptionen gesteuert werden (siehe
Gemeinsame Erstellungsoptionen).
Um das emacs
-Paket auf eine über SSH verbundene Maschine zu
übertragen, würde man dies ausführen:
guix archive --export -r emacs | ssh die-maschine guix archive --import
Auf gleiche Art kann auch ein vollständiges Benutzerprofil von einer Maschine auf eine andere übertragen werden:
guix archive --export -r $(readlink -f ~/.guix-profile) | \ ssh die-maschine guix archive --import
Jedoch sollten Sie in beiden Beispielen beachten, dass alles, was zu
emacs
, dem Profil oder deren Abhängigkeiten (wegen -r)
gehört, übertragen wird, egal ob es schon im Store der Zielmaschine
vorhanden ist oder nicht. Mit der Befehlszeilenoption --missing
lässt sich herausfinden, welche Objekte im Ziel-Store noch fehlen. Der
Befehl guix copy
vereinfacht und optimiert diesen gesamten
Prozess, ist also, was Sie in diesem Fall wahrscheinlich eher benutzen
wollten (siehe guix copy
aufrufen).
Dabei wird jedes Store-Objekt als „normalisiertes Archiv“, kurz „Nar“,
formatiert (was im Folgenden beschrieben wird) und die Ausgabe von
guix archive --export
(bzw. die Eingabe von guix
archive --import
) ist ein Nar-Bündel.
Das Nar-Format folgt einem ähnlichen Gedanken wie beim „tar“-Format, unterscheidet sich aber auf eine für unsere Zwecke geeignetere Weise. Erstens werden im Nar-Format nicht sämtliche Unix-Metadaten aller Dateien aufgenommen, sondern nur der Dateityp (ob es sich um eine reguläre Datei, ein Verzeichnis oder eine symbolische Verknüpfung handelt). Unix-Dateiberechtigungen sowie Besitzer und Gruppe werden nicht gespeichert. Zweitens entspricht die Reihenfolge, in der der Inhalt von Verzeichnissen abgelegt wird, immer der Reihenfolge, in der die Dateinamen gemäß der C-Locale sortiert würden. Dadurch wird die Erstellung von Archivdateien völlig deterministisch.
Das Nar-Bündel-Format setzt sich im Prinzip aus null oder mehr aneinandergehängten Nars zusammen mit Metadaten für jedes enthaltene Store-Objekt, nämlich dessen Dateinamen, Referenzen, der zugehörigen Ableitung sowie einer digitalen Signatur.
Beim Exportieren versieht der Daemon den Inhalt des Archivs mit einer digitalen Signatur, auch Beglaubigung genannt. Diese digitale Signatur wird an das Archiv angehängt. Beim Importieren verifiziert der Daemon die Signatur und lehnt den Import ab, falls die Signatur ungültig oder der Signierschlüssel nicht autorisiert ist.
Die wichtigsten Befehlszeilenoptionen sind:
--export
Exportiert die angegebenen Store-Dateien oder Pakete (siehe unten) und schreibt das resultierende Archiv auf die Standardausgabe.
Abhängigkeiten fehlen in der Ausgabe, außer wenn --recursive angegeben wurde.
-r
--recursive
Zusammen mit --export wird guix archive
hiermit
angewiesen, Abhängigkeiten der angegebenen Objekte auch ins Archiv
aufzunehmen. Das resultierende Archiv ist somit eigenständig; es enthält den
Abschluss der exportierten Store-Objekte.
--import
Ein Archiv von der Standardeingabe lesen und darin enthaltende Dateien in den Store importieren. Der Import bricht ab, wenn das Archiv keine gültige digitale Signatur hat oder wenn es von einem öffentlichen Schlüssel signiert wurde, der keiner der autorisierten Schlüssel ist (siehe --authorize weiter unten).
--missing
Eine Liste der Store-Dateinamen von der Standardeingabe lesen, je ein Name pro Zeile, und auf die Standardausgabe die Teilmenge dieser Dateien schreiben, die noch nicht im Store vorliegt.
--generate-key[=Parameter]
¶Ein neues Schlüsselpaar für den Daemon erzeugen. Dies ist erforderlich,
damit Archive mit --export exportiert werden können. Normalerweise
wird diese Option sofort umgesetzt, jedoch kann sie, wenn erst der
Entropie-Pool neu gefüllt werden muss, einige Zeit in Anspruch nehmen. Auf
Guix System kümmert sich der guix-service-type
darum, dass beim
ersten Systemstart das Schlüsselpaar erzeugt wird.
Das erzeugte Schlüsselpaar wird typischerweise unter /etc/guix
gespeichert, in den Dateien signing-key.pub (für den öffentlichen
Schlüssel) und signing-key.sec (für den privaten Schlüssel, der
geheim gehalten werden muss). Wurden keine Parameters angegeben, wird
ein ECDSA-Schlüssel unter Verwendung der Kurve Ed25519 erzeugt, oder, falls
die Libgcrypt-Version älter als 1.6.0 ist, ein 4096-Bit-RSA-Schlüssel. Sonst
geben die Parameter für Libgcrypt geeignete Parameter für
genkey
an (siehe gcry_pk_genkey
in Referenzhandbuch von Libgcrypt).
--authorize
¶Mit dem auf der Standardeingabe übergebenen öffentlichen Schlüssel signierte Importe autorisieren. Der öffentliche Schlüssel muss als „advanced“-formatierter S-Ausdruck gespeichert sein, d.h. im selben Format wie die Datei signing-key.pub.
Die Liste autorisierter Schlüssel wird in der Datei /etc/guix/acl gespeichert, die auch von Hand bearbeitet werden kann. Die Datei enthält „advanced“-formatierte S-Ausdrücke und ist als eine Access Control List für die Simple Public-Key Infrastructure (SPKI) aufgebaut.
--extract=Verzeichnis
-x Verzeichnis
Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern geliefert wird (siehe Substitute), und ins Verzeichnis entpacken. Dies ist eine systemnahe Operation, die man nur selten direkt benutzt; siehe unten.
Zum Beispiel entpackt folgender Befehl das Substitut für Emacs, wie es von
bordeaux.guix.gnu.org
geliefert wird, nach /tmp/emacs:
$ wget -O - \ https://bordeaux.guix.gnu.org/nar/gzip/…-emacs-24.5 \ | gunzip | guix archive -x /tmp/emacs
Archive mit nur einem einzelnen Objekt unterscheiden sich von Archiven für
mehrere Dateien, wie sie guix archive --export
erzeugt; sie
enthalten nur ein einzelnes Store-Objekt und keine eingebettete
Signatur. Beim Entpacken findet also keine Signaturprüfung statt und
ihrer Ausgabe sollte so erst einmal nicht vertraut werden.
Der eigentliche Zweck dieser Operation ist, die Inspektion von
Archivinhalten von Substitutservern möglich zu machen, auch wenn diesen
unter Umständen nicht vertraut wird (siehe guix challenge
aufrufen).
--list
-t
Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern geliefert wird (siehe Substitute), und die Dateien darin ausgeben, wie in diesem Beispiel:
$ wget -O - \ https://bordeaux.guix.gnu.org/nar/lzip/…-emacs-26.3 \ | lzip -d | guix archive -t
Nächste: Entwicklung, Vorige: Paketverwaltung, Nach oben: GNU Guix [Inhalt][Index]
Guix und die Sammlung darin verfügbarer Pakete können Sie durch Ausführen
von guix pull
aktualisieren. 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 eine Datei mit
den Kanälen angeben, die Sie möchten (siehe guix pull
aufrufen). Ein Kanal enthält eine Angabe der 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: Eigenen Guix-Kanal benutzen, Nach oben: Kanäle [Inhalt][Index]
Sie können auch weitere Kanäle als Bezugsquelle angeben. Um einen
Kanal zu benutzen, tragen Sie ihn in ~/.config/guix/channels.scm
ein,
damit guix pull
diesen Kanal zusätzlich zu den
standardmäßigen Guix-Kanälen als Paketquelle verwendet:
;; Paketvarianten zu denen von Guix dazunehmen. (cons (channel (name 'paketvarianten) (url "https://example.org/variant-packages.git")) %default-channels)
Beachten Sie, dass der obige Schnipsel (wie immer!) Scheme-Code ist; mit
cons
fügen wir einen Kanal zur Liste der Kanäle hinzu, an die die
Variable %default-channels
gebunden ist (siehe cons
and lists in Referenzhandbuch zu GNU Guile). Mit diesem
Dateiinhalt wird guix pull
nun nicht mehr nur Guix, sondern auch
die Paketmodule aus Ihrem Repository erstellen. Das Ergebnis in
~/.config/guix/current ist so die Vereinigung von Guix und Ihren
eigenen Paketmodulen.
$ guix describe Generation 19 27. August 2018 16:20:48 guix d894ab8 Repository-URL: https://git.savannah.gnu.org/git/guix.git Branch: master Commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300 paketvarianten dd3df5e Repository-URL: https://example.org/variant-packages.git Branch: master Commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
Obige Ausgabe von guix describe
zeigt an, dass jetzt
Generation 19 läuft und diese sowohl Guix als auch Pakete aus dem Kanal
paketvarianten
enthält (siehe guix describe
aufrufen).
Nächste: Guix nachbilden, Vorige: Weitere Kanäle angeben, Nach oben: Kanäle [Inhalt][Index]
Der Kanal namens guix
gibt an, wovon Guix selbst – seine
Befehlszeilenwerkzeuge und seine Paketsammlung – heruntergeladen werden
sollen. Wenn Sie zum Beispiel mit einer anderen Kopie des Guix-Repositorys
arbeiten möchten und diese auf example.org
zu finden ist, und zwar im
Branch namens super-hacks
, dann schreiben Sie folgende Spezifikation
in ~/.config/guix/channels.scm
:
;; 'guix pull' ein anderes Repository benutzen lassen. (list (channel (name 'guix) (url "https://example.org/anderes-guix.git") (branch "super-hacks")))
Ab dann wird guix pull
seinen Code vom Branch super-hacks
des Repositorys auf example.org
beziehen. Wie man dessen
Autorisierung bewerkstelligt, können Sie im Folgenden lesen (siehe
Kanalauthentifizierung).
Wir weisen darauf hin, dass Sie oben im url
-Feld den Namen eines
lokalen Verzeichnisses angeben können, wenn sich der Kanal, den Sie benutzen
möchten, auf einem lokalen Dateisystem befindet. Allerdings wird
guix
dabei überprüfen, ob das besagte Verzeichnis auch Ihrem
Benutzer gehört, bevor es mit der Verarbeitung fortfährt. Das bedeutet, dass
Benutzer, die ein Verzeichnis standardmäßig beziehen möchten, das ihnen
nicht gehört, einen Eintrag in deren globaler Git-Konfigurationsdatei
machen müssen, um das Verzeichnis ausdrücklich als sicher
einzustufen. Andernfalls wird sich guix
weigern, es auch nur zu
lesen. Wenn wir annehmen, dass ein systemweites lokales Verzeichnis unter
/src/guix.git
benutzt werden soll, müsste dafür eine
Git-Konfigurationsdatei namens ~/.gitconfig
mit folgendem Inhalt
angelegt werden:
[safe] directory = /src/guix.git
Dies gilt auch für den Administratorbenutzer root
, außer wenn
der Besitzer des Verzeichnisses einen Aufruf mit sudo
macht.
Nächste: Anpassung des systemweiten Guix, Vorige: Eigenen Guix-Kanal benutzen, Nach oben: Kanäle [Inhalt][Index]
Der Befehl guix describe
zeigt genau, aus welchen Commits die
Guix-Instanz erstellt wurde, die Sie benutzen (siehe guix describe
aufrufen). Sie können diese Instanz auf einer anderen Maschine oder zu
einem späteren Zeitpunkt nachbilden, indem Sie eine Kanalspezifikation
angeben, die auf diese Commits „festgesetzt“ ist.
;; Ganz bestimmte Commits der relevanten Kanäle installieren. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "6298c3ffd9654d3231a6f25390b056483e8f407c")) (channel (name 'paketvarianten) (url "https://example.org/variant-packages.git") (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))
Um so eine festgesetzte Kanalspezifikation zu bekommen, ist es am
einfachsten, guix describe
auszuführen und seine Ausgabe in
channels
-Formatierung in einer Datei zu speichern. Das geht so:
guix describe -f channels > channels.scm
Die erzeugte Datei channels.scm kann mit der Befehlszeilenoption
-C von guix pull
(siehe guix pull
aufrufen) oder
von guix time-machine
(siehe guix time-machine
aufrufen)
übergeben werden. Ein Beispiel:
guix time-machine -C channels.scm -- shell python -- python3
Anhand der Datei channels.scm ist festgelegt, dass der obige Befehl
immer genau dieselbe Guix-Instanz lädt und dann mit dieser Instanz
genau dasselbe Python startet (siehe guix shell
aufrufen). So werden
auf jeder beliebigen Maschine zu jedem beliebigen Zeitpunkt genau dieselben
Binärdateien ausgeführt, Bit für Bit.
Das Problem, das solche festgesetzten Kanäle lösen, ist ähnlich zu dem, wofür andere Werkzeuge zur Softwareauslieferung „Lockfiles“ einsetzen – ein Satz von Paketen wird reproduzierbar auf eine bestimmte Version festgesetzt. Im Fall von Guix werden allerdings sämtliche mit Guix ausgelieferte Pakete auf die angegebenen Commits fixiert; tatsächlich sogar der ganze Rest von Guix mitsamt seinen Kernmodulen und Programmen für die Befehlszeile. Dazu wird sicher garantiert, dass Sie wirklich genau dieselbe Software vorfinden werden.
Das verleiht Ihnen Superkräfte, mit denen Sie die Provenienz binärer Artefakte sehr feinkörnig nachverfolgen können und Software-Umgebungen nach Belieben nachbilden können. Sie können es als eine Art Fähigkeit zur „Meta-Reproduzierbarkeit“ auffassen, wenn Sie möchten. Der Abschnitt Untergeordnete beschreibt eine weitere Möglichkeit, diese Superkräfte zu nutzen.
Nächste: Kanalauthentifizierung, Vorige: Guix nachbilden, Nach oben: Kanäle [Inhalt][Index]
Wenn bei Ihnen Guix System läuft oder Sie Guix System benutzen, um Abbilder
(„Images“) zu erstellen, möchten Sie vielleicht Anpassungen vornehmen,
welches guix
darin systemweit verfügbar ist – um genau zu
sein, an /run/current-system/profile/bin/guix. Zum Beispiel könnten
Sie zusätzliche Kanäle vorsehen oder genau festschreiben, welche Version es
verwendet.
Dazu verwenden Sie die Prozedur guix-for-channels
, die ein Paket für
die angegebenen Pakete zurückliefert, welche sie in Ihrer
Betriebssystemkonfiguration so benutzen wie in diesem Beispiel:
(use-modules (gnu packages package-management) (guix channels)) (define meine-kanäle ;; Die Kanäle, die in /run/current-system/profile/bin/guix ;; verfügbar sein sollen. (append (list (channel (name 'guix-science) (url "https://github.com/guix-science/guix-science") (branch "master"))) %default-channels)) (operating-system ;; … (services ;; Ändern, welches Paket 'guix-service-type' verwendet. (modify-services %base-services (guix-service-type config => (guix-configuration (inherit config) (channels meine-kanäle) (guix (guix-for-channels meine-kanäle)))))))
Das Ergebnis ist ein Betriebssystem, in dem sowohl der guix
-Kanal als
auch der Kanal guix-science
als Voreinstellung sichtbar sind. Das
Feld channels
in der obigen guix-configuration
bewirkt zudem,
dass die Datei /etc/guix/channels.scm, die von guix pull
benutzt wird, dieselben Kanäle angibt (siehe
das Feld channels
in
guix-configuration
).
Das Modul (gnu packages package-management)
exportiert die Prozedur
guix-for-channels
, die im Folgenden beschrieben wird.
Liefert ein Paket mit jedem der Kanäle.
Das Ergebnis ist ein „normales“ Paket, das für die Nutzung in
guix-configuration
geeignet ist, wie oben gezeigt, aber auch überall
sonst wo ein Paket erwartet wird.
Nächste: Kanäle mit Substituten, Vorige: Anpassung des systemweiten Guix, Nach oben: Kanäle [Inhalt][Index]
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: Einen Kanal erstellen, Vorige: Kanalauthentifizierung, Nach oben: Kanäle [Inhalt][Index]
Wenn Sie guix pull
ausführen, wird Guix als Erstes die Definition
jedes verfügbaren Pakets kompilieren. Das ist eine teure Operation, für die
es aber Substitute geben könnte (siehe Substitute). Mit dem folgenden
Schnipsel in channels.scm wird sichergestellt, dass guix
pull
den neuesten Commit benutzt, für den bereits Substitute für die
Paketdefinitionen vorliegen. Dazu wird der Server für Kontinuierliche
Integration auf https://ci.guix.gnu.org angefragt.
(use-modules (guix ci)) (list (channel-with-substitutes-available %default-guix-channel "https://ci.guix.gnu.org"))
Beachten Sie: Das heißt nicht, dass für alle Pakete, die Sie
installieren werden, nachdem Sie guix pull
durchgeführt haben,
bereits Substitute vorliegen. Es wird nur sichergestellt, dass guix
pull
keine Paketdefinitionen zu kompilieren versucht. Das hilft besonders
auf Maschinen mit eingeschränkten Rechenressourcen.
Nächste: Paketmodule in einem Unterverzeichnis, Vorige: Kanäle mit Substituten, Nach oben: Kanäle [Inhalt][Index]
Sagen wir, Sie haben ein paar eigene Paketvarianten oder persönliche Pakete, von denen Sie meinen, dass sie nicht geeignet sind, ins Guix-Projekt selbst aufgenommen zu werden, die Ihnen aber dennoch wie andere Pakete auf der Befehlszeile zur Verfügung stehen sollen. Indem Sie einen Kanal damit anlegen, wird Ihre Sammlung von Paketen nutzbar und Sie können sie mit anderen teilen. Dazu sind folgende Schritte nötig:
mkdir my-channel cd my-channel git init
Ein Beispiel: Alice könnte ein Modul mit dem Namen (alice packages
greetings)
bereitstellen für ihre
Lieblings-Hallo-Welt-Implementierungen. Zu diesem Zweck würde Alice ein
Verzeichnis entsprechend dem Modulnamen erzeugen.
mkdir -p alice/packages $EDITOR alice/packages/greetings.scm git add alice/packages/greetings.scm
Welchen Namen Sie einem Paketmodul geben möchten, bleibt Ihnen
überlassen. Behalten Sie nur die Einschränkung im Kopf, dass sich der Name
von anderen Paketsammlungen unterscheiden muss, deshalb trifft Alice aus
unserem Beispiel die weise Entscheidung für (alice packages …)
als
Namensraum.
Es sei erwähnt, dass Sie Paketmodule auch in einem Unterverzeichnis innerhalb des Repositorys ablegen können; siehe dazu Paketmodule in einem Unterverzeichnis.
guix build
verwenden, wobei Sie mitteilen, dass es die Module aus dem Git-Checkout
verwenden soll. Nehmen wir zum Beispiel an, in (alice packages
greetings)
wird ein Paket namens hi-from-alice
angeboten. Dann führt
Alice aus dem Git-Checkout diesen Befehl aus:
guix build -L. hi-from-alice
Hier wird mit -L.
das aktuelle Verzeichnis zu Guiles Ladepfad
hinzugefügt (siehe Load Paths in Referenzhandbuch zu GNU
Guile).
git commit
Als Kanalautor möchten Sie vielleicht Materialien mitliefern, damit dessen Nutzer ihn authentifizieren können. Siehe Kanalauthentifizierung und Kanalautorisierungen angeben für Informationen, wie das geht.
guix pull
ausführen
(siehe guix pull
aufrufen):
$EDITOR ~/.config/guix/channels.scm guix pull
Von nun an verhält sich Guix so, als hätte man das Wurzelverzeichnis des
Git-Repositorys jenes Kanals dauerhaft zu Guiles Ladepfad hinzugefügt. In
Alice’ Fall wird also (alice packages greetings)
automatisch durch
den guix
-Befehl gefunden.
Erledigt!
Warnung: Ehe Sie Ihren Kanal der Welt zur Verfügung stellen, möchten wir Ihnen auch ein paar Worte der Warnung mit auf den Weg geben:
- Bevor Sie einen Kanal veröffentlichen, überlegen Sie sich bitte erst, ob Sie die Pakete nicht besser zum eigentlichen Guix-Projekt beisteuern (siehe Mitwirken). Das Guix-Projekt ist gegenüber allen Arten freier Software offen und zum eigentlichen Guix gehörende Pakete stehen allen Guix-Nutzern zur Verfügung, außerdem profitieren sie von Guix’ Qualitätssicherungsprozess.
- Bedenken Sie, dass Paketmodule und Paketdefinitionen Scheme-Code sind, der verschiedene Programmierschnittstellen (APIs) benutzt. Wir, die Entwickler von Guix, ändern APIs nie einfach so, versprechen aber auch nicht, APIs nicht zu verändern. Wenn Sie Paketdefinitionen außerhalb von Guix betreuen, sehen wir es als Ihre Aufgabe an, deren Kompatibilität sicherzustellen.
- Das bedeutet auch, dass Sie, wenn Sie einen externen Kanal verwenden und dieser kaputt geht, Sie dies bitte den Autoren des Kanals und nicht dem Guix-Projekt melden.
Wir haben Sie gewarnt! Allerdings denken wir auch, dass externe Kanäle eine praktische Möglichkeit sind, die Paketsammlung von Guix zu ergänzen und Ihre Verbesserungen mit anderen zu teilen, wie es dem Grundgedanken freier Software entspricht. Bitte schicken Sie eine E-Mail an guix-devel@gnu.org, wenn Sie dies diskutieren möchten.
Nächste: Kanalabhängigkeiten deklarieren, Vorige: Einen Kanal erstellen, Nach oben: Kanäle [Inhalt][Index]
Als Kanalautor möchten Sie vielleicht Ihre Kanalmodule in einem Unterverzeichnis anlegen. Wenn sich Ihre Module im Unterverzeichnis guix befinden, müssen Sie eine Datei .guix-channel mit Metadaten einfügen:
(channel
(version 0)
(directory "guix"))
Die Module müssen sich unterhalb des als directory
angegebenen
Verzeichnisses befinden, weil directory
Guiles Einstellung für
load-path
verändert. Zum Beispiel muss sich, wenn in
.guix-channel (directory "base")
eingetragen ist, ein Modul,
was als (define-module (gnu packages fun))
definiert ist, in
base/gnu/packages/fun.scm
befinden.
Dadurch ist es möglich, nur einen Teil eines Repositorys als Kanal zu
benutzen, was nützlich ist, weil Guix verlangt, dass beim Beziehen von
Kanälen alle Guile-Module darin auch gültig sind. Zum Beispiel handelt es
sich bei Konfigurationsdateien der Maschinen für guix deploy
nicht um gültige Guile-Module und sie zu beziehen würde guix
pull
fehlschlagen lassen.
Nächste: Kanalautorisierungen angeben, Vorige: Paketmodule in einem Unterverzeichnis, Nach oben: Kanäle [Inhalt][Index]
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: Primäre URL, Vorige: Kanalabhängigkeiten deklarieren, Nach oben: Kanäle [Inhalt][Index]
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 steht13 Die Datei .guix-authorizations sieht so aus:
;; Beispiel für eine '.guix-authorizations'-Datei. (authorizations (version 0) ;aktuelle Version des Dateiformats (("AD17 A21E F8AE D8F1 CC02 DBD9 F8AE D8F1 765C 61E3" (name "alice")) ("2A39 3FFF 68F4 EF7A 3D29 12AF 68F4 EF7A 22FB B2D5" (name "bob")) ("CABB A931 C0FF EEC6 900D 0CFB 090B 1199 3D9A EBB5" (name "charlie"))))
Auf jeden Fingerabdruck folgen optional Schlüssel-/Wert-Paare wie im obigen Beispiel. Derzeit werden diese Schlüssel-/Wert-Paare ignoriert.
Diese Authentifizierungsregel hat ein Henne-Ei-Problem zur Folge: Wie authentifizieren wir den ersten Commit? Und damit zusammenhängend: Was tun wir, wenn die Historie eines Kanal-Repositorys nicht signierte Commits enthält und eine .guix-authorizations-Datei fehlt? Und wie legen wir eine Abspaltung („Fork“) existierender Kanäle an?
Kanaleinführungen beantworten diese Fragen, indem sie den ersten Commit
eines Kanals angeben, der authentifiziert werden soll. Das erste Mal, wenn
ein Kanal durch guix pull
oder guix time-machine
geladen
wird, wird nachgeschaut, was der einführende Commit ist und ob er mit dem
angegebenen OpenPGP-Schlüssel signiert wurde. Von da an werden Commits gemäß
obiger Regel authentifiziert. Damit die Authentifizierung erfolgreich ist,
muss der Ziel-Commit entweder Nachkomme oder Vorgänger des einführenden
Commits sein.
Außerdem muss Ihr Kanal alle OpenPGP-Schlüssel zur Verfügung stellen, die
jemals in .guix-authorizations erwähnt wurden, gespeichert in Form
von .key-Dateien, entweder als Binärdateien oder mit
„ASCII-Hülle“. Nach Vorgabe wird nach diesen .key-Dateien im Branch
namens keyring
gesucht, aber Sie können wie hier einen anderen
Branchnamen in .guix-channel
angeben:
(channel
(version 0)
(keyring-reference "my-keyring-branch"))
Zusammenfassen haben Kanalautoren drei Dinge zu tun, damit Nutzer deren Code authentifizieren können:
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).
Bevor Sie auf Ihr öffentliches Git-Repository pushen, können Sie
guix git authenticate
ausführen, um zu überprüfen, dass Sie alle
Commits, die Sie pushen würden, mit einem autorisierten Schlüssel signiert
haben:
guix git authenticate Commit Unterzeichner
Dabei sind Commit und Unterzeichner Ihre Kanaleinführung. Siehe
guix git authenticate
aufrufen für die Details.
Um einen signierten Kanal anzubieten, ist Disziplin vonnöten: Jeder Fehler, wie z.B. ein unsignierter Commit oder ein mit einem unautorisierten Schlüssel signierter Commit, verhindert, das Nutzer den Kanal benutzen können – naja, das ist ja auch der Zweck der Authentifizierung! Passen Sie besonders bei Merges auf: Merge-Commits werden dann und nur dann als authentisch angesehen, wenn sie mit einem Schlüssel aus der .guix-authorizations-Datei beider Branches signiert wurden.
Nächste: Kanalneuigkeiten verfassen, Vorige: Kanalautorisierungen angeben, Nach oben: Kanäle [Inhalt][Index]
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: Primäre URL, Nach oben: Kanäle [Inhalt][Index]
Kanalautoren möchten ihren Nutzern vielleicht manchmal Informationen über wichtige Änderungen im Kanal zukommen lassen. Man könnte allen eine E-Mail schicken, aber das wäre unbequem.
Stattdessen können Kanäle eine Datei mit Neuigkeiten („News File“) anbieten:
Wenn die Kanalnutzer guix pull
ausführen, wird diese Datei
automatisch ausgelesen. Mit guix pull --news
kann man sich die
Ankündigungen anzeigen lassen, die den neu gepullten Commits entsprechen,
falls es welche gibt.
Dazu müssen Kanalautoren zunächst den Namen der Datei mit Neuigkeiten in der Datei .guix-channel nennen:
(channel
(version 0)
(news-file "etc/news.txt"))
Die Datei mit Neuigkeiten, etc/news.txt in diesem Beispiel, muss selbst etwa so aussehen:
(channel-news
(version 0)
(entry (tag "the-bug-fix")
(title (en "Fixed terrible bug")
(fr "Oh la la"))
(body (en "@emph{Good news}! It's fixed!")
(eo "Certe ĝi pli bone funkcias nun!")))
(entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
(title (en "Added a great package")
(ca "Què vol dir guix?"))
(body (en "Don't miss the @code{hello} package!"))))
Obwohl die Datei für Neuigkeiten Scheme-Syntax verwendet, sollten Sie ihr keinen Dateinamen mit der Endung .scm geben, sonst wird sie bei der Erstellung des Kanals miteinbezogen und dann zu einem Fehler führen, weil es sich bei ihr um kein gültiges Modul handelt. Alternativ können Sie auch das Kanalmodul in einem Unterverzeichnis platzieren und die Datei für Neuigkeiten in einem Verzeichnis außerhalb platzieren.
Die Datei setzt sich aus einer Liste von Einträgen mit Neuigkeiten („News Entries“) zusammen. Jeder Eintrag ist mit einem Commit oder einem Git-Tag assoziiert und beschreibt die Änderungen, die in diesem oder auch vorangehenden Commits gemacht wurden. Benutzer sehen die Einträge nur beim erstmaligen Übernehmen des Commits, auf den sich der jeweilige Eintrag bezieht.
Das title
-Feld sollte eine einzeilige Zusammenfassung sein, während
body
beliebig lang sein kann. Beide können Texinfo-Auszeichnungen
enthalten (siehe Overview in GNU Texinfo). Sowohl
title
als auch body
sind dabei eine Liste aus Tupeln mit
jeweils Sprachcode und Mitteilung, wodurch guix pull
Neuigkeiten
in derjenigen Sprache anzeigen kann, die der vom Nutzer eingestellten Locale
entspricht.
Wenn Sie Neuigkeiten mit einem gettext-basierten Arbeitsablauf übersetzen
möchten, können Sie übersetzbare Zeichenketten mit xgettext
extrahieren (siehe xgettext Invocation in GNU Gettext
Utilities). Unter der Annahme, dass Sie Einträge zu Neuigkeiten zunächst
auf Englisch verfassen, können Sie mit diesem Befehl eine PO-Datei erzeugen,
die die zu übersetzenden Zeichenketten enthält:
xgettext -o news.po -l scheme -ken etc/news.txt
Kurz gesagt, ja, Sie können Ihren Kanal sogar als Blog missbrauchen. Aber das ist nicht ganz, was Ihre Nutzer erwarten dürften.
Nächste: Programmierschnittstelle, Vorige: Kanäle, Nach oben: GNU Guix [Inhalt][Index]
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 shell
stellt eine bequeme Möglichkeit dar,
Umgebungen für einmalige Nutzungen zu erschaffen, etwa zur Entwicklung an
einem Programm oder um einen Befehl auszuführen, den Sie nicht in Ihr Profil
installieren möchten. 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.
guix shell
aufrufenguix environment
aufrufenguix pack
aufrufenguix git authenticate
aufrufen
Nächste: guix environment
aufrufen, Nach oben: Entwicklung [Inhalt][Index]
guix shell
aufrufenDer Zweck von guix shell
ist, dass Sie Software-Umgebungen für
außergewöhnliche Fälle einfach aufsetzen können, ohne dass Sie Ihr Profil
ändern müssen. Normalerweise braucht man so etwas für
Entwicklungsumgebungen, aber auch wenn Sie Anwendungen ausführen wollen,
ohne Ihr Profil mit ihnen zu verunreinigen.
Anmerkung: Der Befehl
guix shell
wurde erst kürzlich eingeführt als Neuauflage vonguix environment
(sieheguix environment
aufrufen). Wenn Sie mitguix environment
vertraut sind, werden Sie die Ähnlichkeit bemerken, aber wir hoffen, der neue Befehl erweist sich als praktischer.
Die allgemeine Syntax lautet:
guix shell [Optionen] [Pakete…]
Folgendes Beispiel zeigt, wie Sie eine Umgebung erzeugen lassen, die Python
und NumPy enthält, – jedes dazu fehlende Paket wird erstellt oder
heruntergeladen –, und in der Umgebung dann python3
ausführen.
guix shell python python-numpy -- python3
Wir betonen, dass Sie auch das zu Grunde liegende python
-Paket in dem
Befehl angeben müssen, sogar wenn Python schon in Ihre Umgebung installiert
ist. Das bewirkt, dass in der Shell-Umgebung PYTHONPATH
und andere
zugehörige Variable gesetzt werden können. Die Shell-Umgebung kann dafür
nicht darauf zurückgreifen, was vorher in der Umgebung installiert war, weil
es nichtdeterministisch wäre. Das gilt für die meisten Bibliotheken: Auch
das zu deren Programmiersprache gehörige Paket muss im Shell-Aufruf
angegeben werden.
Anmerkung:
guix shell
kann auch als Skript-Interpretierer dienen; man spricht auch von einem Shebang. Hier ist ein Beispiel, wie es in einem eigenständigen Python-Skript benutzt werden kann:#!/usr/bin/env -S guix shell python python-numpy -- python3 import numpy print("Hier spricht numpy", numpy.version.version)Sie können beliebige Befehlszeilenoptionen auf diese Weise an
guix shell
übergeben, doch beachten Sie: Der Linux-Kernel beschränkt die Länge eines Shebangs auf maximal 127 Bytes.
Entwicklungsumgebungen erzeugen Sie wie im folgenden Beispiel, wo eine interaktive Shell gestartet wird, in der alle Abhängigkeiten und Variable vorliegen, die zur Arbeit an Inkscape nötig sind:
guix shell --development inkscape
Sobald er die Shell beendet, findet sich der Benutzer in der ursprünglichen
Umgebung wieder, in der er sich vor dem Aufruf von guix shell
befand. Beim nächsten Durchlauf des Müllsammlers (siehe guix gc
aufrufen) dürfen Pakete von der Platte gelöscht werden, die innerhalb der
Umgebung installiert worden sind und außerhalb nicht länger benutzt werden.
Um die Nutzung zu vereinfachen, wird guix shell
, wenn Sie es
interaktiv ohne Befehlszeilenargumente aufrufen, das bewirken, was es dann
vermutlich soll. Also:
guix shell
Wenn im aktuellen Arbeitsverzeichnis oder irgendeinem übergeordneten
Verzeichnis eine Datei manifest.scm vorkommt, wird sie so behandelt,
als hätten Sie sie mit --manifest
übergeben. Ebenso wird mit einer
Datei guix.scm, wenn sie in selbigen Verzeichnissen enthalten ist,
eine Entwicklungsumgebung hergestellt, als wären --development
und
--file
beide angegeben worden. So oder so wird die jeweilige Datei
nur dann geladen, wenn das Verzeichnis, in dem sie steckt, in
~/.config/guix/shell-authorized-directories aufgeführt ist. Damit
lassen sich Entwicklungsumgebungen leicht definieren, teilen und betreten.
Vorgegeben ist, dass für die Shell-Sitzung bzw. den Befehl eine
ergänzte Umgebung aufgebaut wird, in der die neuen Pakete zu
Suchpfad-Umgebungsvariablen wie PATH
hinzugefügt werden. Sie können
stattdessen auch beschließen, eine isolierte Umgebung anzufordern mit
nichts als den Paketen, die Sie angegeben haben. Wenn Sie die
Befehlszeilenoption --pure angeben, werden alle Definitionen von
Umgebungsvariablen aus der Elternumgebung gelöscht14. Wenn Sie --container angeben, wird die Shell
darüber hinaus in einem Container vom restlichen System isoliert:
guix shell --container emacs gcc-toolchain
Dieser Befehl startet eine interaktive Shell in einem Container, der den
Zugriff auf alles außer emacs
, gcc-toolchain
und deren
Abhängigkeiten unterbindet. Im Container haben Sie keinen Netzwerkzugriff
und es werden außer dem aktuellen Arbeitsverzeichnis keine Dateien mit der
äußeren Umgebung geteilt. Das dient dazu, den Zugriff auf systemweite
Ressourcen zu verhindern, wie /usr/bin auf Fremddistributionen.
Diese --container-Befehlszeilenoption kann sich aber auch als nützlich erweisen, um Anwendungen mit hohem Sicherheitsrisiko wie z.B. Webbrowser in eine isolierte Umgebung eingesperrt auszuführen. Folgender Befehl startet zum Beispiel Ungoogled-Chromium in einer isolierten Umgebung, für die gilt:
DISPLAY
und XAUTHORITY
bleiben erhalten
XAUTHORITY
file
guix shell --container --network --no-cwd ungoogled-chromium \ --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \ --preserve='^DISPLAY$' -- chromium
guix shell
definiert die Variable GUIX_ENVIRONMENT
in der
neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen
Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere
Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer
.bashrc festzulegen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash):
if [ -n "$GUIX_ENVIRONMENT" ] then export PS1="\u@\h \w [dev]\$ " fi
… oder um ihr Profil durchzusehen:
$ ls "$GUIX_ENVIRONMENT/bin"
Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.
--check
Hiermit wird die Umgebung angelegt und gemeldet, ob die Shell
Umgebungsvariable überschreiben würde. Es ist eine gute Idee, diese
Befehlszeilenoption anzugeben, wenn Sie zum ersten Mal guix shell
zum Starten einer interaktiven Sitzung einsetzen, um sicherzugehen, dass
Ihre Shell richtig eingestellt ist.
Wenn die Shell zum Beispiel den Wert der Umgebungsvariablen PATH
ändert, meldet dies --check, weil Sie dadurch nicht die Umgebung
bekämen, die Sie angefordert haben.
In der Regel sind solche Probleme ein Zeichen dafür, dass Dateien, die beim Start der Shell geladen werden, die Umgebungsvariablen unerwartet verändern. Wenn Sie zum Beispiel Bash benutzen, vergewissern Sie sich, dass Umgebungsvariable in ~/.bash_profile festgelegt oder geändert werden, nicht in ~/.bashrc – erstere Datei wird nur von Login-Shells mit „source“ geladen. Siehe Bash Startup Files in Referenzhandbuch zu GNU Bash für Details über beim Starten von Bash gelesene Dateien.
--development
-D
Lässt guix shell
die Abhängigkeiten des danach angegebenen Pakets
anstelle des Pakets in die Umgebung aufnehmen. Es kann mit anderen Paketen
kombiniert werden. Zum Beispiel wird mit folgendem Befehl eine interaktive
Shell gestartet, die die zum Erstellen nötigen Abhängigkeiten von
GNU Guile sowie Autoconf, Automake und Libtool enthält:
guix shell -D guile autoconf automake libtool
--expression=Ausdruck
-e Ausdruck
Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der Ausdruck ausgewertet wird.
Zum Beispiel startet dies:
guix shell -D -e '(@ (gnu packages maths) petsc-openmpi)'
eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc.
Wenn man dies ausführt:
guix shell -e '(@ (gnu) %base-packages)'
bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind.
Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden:
guix shell -e '(list (@ (gnu packages bash) bash) "include")'
Siehe package->development-manifest
, für Informationen, wie Sie die
Entwicklungsumgebung für ein Paket in einem Manifest wiedergeben.
--file=Datei
-f Datei
Eine Umgebung erstellen mit dem Paket oder der Liste von Paketen, zu der der Code in der Datei ausgewertet wird.
Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):
(use-modules (guix) (gnu packages gdb) (gnu packages autotools) (gnu packages texinfo)) ;; Augment the package definition of GDB with the build tools ;; needed when developing GDB (and which are not needed when ;; simply installing it.) (package (inherit gdb) (native-inputs (modify-inputs (package-native-inputs gdb) (prepend autoconf-2.69 automake texinfo))))
Mit so einer Datei können Sie eine Entwicklungsumgebung für GDB betreten, indem Sie dies ausführen:
guix shell -D -f gdb-devel.scm
--manifest=Datei
-m Datei
Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.
Dies verhält sich ähnlich wie die gleichnamige Option des Befehls
guix package
(siehe --manifest)
und benutzt auch dieselben Manifestdateien.
Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest schreibt. Siehe --export-manifest im folgenden Text, um zu erfahren, wie Sie ein erstes Manifest erhalten.
--export-manifest
Auf die Standardausgabe ein Manifest ausgeben, das mit --manifest genutzt werden kann und den angegebenen Befehlszeilenoptionen entspricht.
Auf diese Weise können Sie die Argumente der Befehlszeile in eine Manifestdatei verwandeln. Nehmen wir an, Sie wären es leid, lange Befehlszeilen abzutippen, und hätten stattdessen lieber ein gleichbedeutendes Manifest:
guix shell -D guile git emacs emacs-geiser emacs-geiser-guile
Fügen Sie einfach --export-manifest zu der obigen Befehlszeile hinzu:
guix shell --export-manifest \ -D guile git emacs emacs-geiser emacs-geiser-guile
… und schon sehen Sie ein Manifest, was so ähnlich aussieht:
(concatenate-manifests
(list (specifications->manifest
(list "git"
"emacs"
"emacs-geiser"
"emacs-geiser-guile"))
(package->development-manifest
(specification->package "guile"))))
Diese Ausgabe können Sie in einer Datei speichern, nennen wir sie
manifest.scm, die Sie dann an guix shell
oder so ziemlich
jeden beliebigen guix
-Befehl übergeben:
guix shell -m manifest.scm
Na bitte. Aus der langen Befehlszeile ist ein Manifest geworden! Beim Verwandlungsvorgang werden Paketumwandlungsoptionen berücksichtigt (siehe Paketumwandlungsoptionen), d.h. er sollte verlustfrei sein.
--profile=Profil
-p Profil
Eine Umgebung mit den Paketen erzeugen, die im Profil installiert
sind. Benutzen Sie guix package
(siehe guix package
aufrufen), um Profile anzulegen und zu verwalten.
--pure
Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit --preserve angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts.
--preserve=Regexp
-E Regexp
Wenn das hier zusammen mit --pure angegeben wird, bleiben die zum regulären Ausdruck Regexp passenden Umgebungsvariablen erhalten – mit anderen Worten werden sie auf eine „weiße Liste“ von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden.
guix shell --pure --preserve=^SLURM openmpi … \ -- mpirun …
In diesem Beispiel wird mpirun
in einem Kontext ausgeführt, in dem
die einzig definierten Umgebungsvariablen PATH
und solche sind, deren
Name mit ‘SLURM’ beginnt, sowie die üblichen besonders „kostbaren“
Variablen (HOME
, USER
, etc.).
--search-paths
Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.
--system=System
-s System
Versuchen, für das angegebene System zu erstellen – z.B.
i686-linux
.
--container
¶-C
Den Befehl in einer isolierten Umgebung (einem sogenannten „Container“) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption --user nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei /etc/passwd.
Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption --user wird übergeben (siehe unten).
--network
-N
Bei isolierten Umgebungen („Containern“) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät.
--link-profile
-P
Bei isolierten Umgebungen („Containern“) wird das Umgebungsprofil im
Container als ~/.guix-profile verknüpft und ~/.guix-profile
dann in GUIX_ENVIRONMENT
gespeichert. Das ist äquivalent dazu,
~/.guix-profile im Container zu einer symbolischen Verknüpfung auf
das tatsächliche Profil zu machen. Wenn das Verzeichnis bereits existiert,
schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser
Fehler wird immer eintreten, wenn guix shell
im persönlichen
Verzeichnis des Benutzers aufgerufen wurde.
Bestimmte Pakete sind so eingerichtet, dass sie in ~/.guix-profile nach Konfigurationsdateien und Daten suchen,15 weshalb --link-profile benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten.
--user=Benutzer
-u Benutzer
Bei isolierten Umgebungen („Containern“) wird der Benutzername Benutzer anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in /etc/passwd im Container wird also den Namen Benutzer enthalten und das persönliche Verzeichnis wird den Namen /home/BENUTZER tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. Benutzer muss auf dem System nicht existieren.
Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils --share und --expose), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu /home/BENUTZER erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses.
# wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren cd $HOME/wd guix shell --container --user=foo \ --expose=$HOME/test \ --expose=/tmp/target=$HOME/target
Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Datenschutz und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden.
--no-cwd
In isolierten Umgebungen („Containern“) ist das vorgegebene Verhalten, das aktuelle Arbeitsverzeichnis mit dem isolierten Container zu teilen und in der Umgebung sofort in dieses Verzeichnis zu wechseln. Wenn das nicht gewünscht wird, kann das Angeben von --no-cwd dafür sorgen, dass das Arbeitsverzeichnis nicht automatisch geteilt wird und stattdessen in das Persönliche Verzeichnis („Home“-Verzeichnis) gewechselt wird. Siehe auch --user.
--expose=Quelle[=Ziel]
--share=Quelle[=Ziel]
Bei isolierten Umgebungen („Containern“) wird das Dateisystem unter Quelle vom Wirtssystem als Nur-Lese-Dateisystem Ziel (bzw. für --share auch mit Schreibrechten) im Container zugänglich gemacht. Wenn kein Ziel angegeben wurde, wird die Quelle auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt.
Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis /austausch nur für Lesezugriffe zugänglich gemacht wurde:
guix shell --container --expose=$HOME=/austausch guile -- guile
--symlink=Spezifikation
-S Spezifikation
Für Container werden hiermit die in der Spezifikation angegebenen symbolischen Verknüpfungen hergestellt. Siehe die Dokumentation in pack-symlink-option.
--emulate-fhs
-F
Wenn Sie dies zusammen mit --container angeben, wird im Container eine Konfiguration emuliert, die dem Filesystem Hierarchy Standard (FHS) folgt, so dass es /bin, /lib und weitere Verzeichnisse gibt, wie es der FHS vorschreibt.
Obwohl Guix vom FHS-Standard abweicht, kann das System in Ihrem Container mit dieser Befehlszeilenoption zu anderen GNU/Linux-Distributionen ähnlicher werden. Dadurch lassen sich dortige Entwicklungsumgebungen reproduzieren und Sie können Programme testen und benutzen, die das Befolgen des FHS-Standards voraussetzen. Wenn die Option angegeben wird, enthält der Container eine Version von glibc, die die im Container befindliche /etc/ld.so.cache als Zwischenspeicher gemeinsamer Bibliotheken ausliest (anders als glibc im normalen Gebrauch von Guix), und die im FHS verlangten Verzeichnisse /bin, /etc, /lib und /usr werden aus dem Profil des Containers übernommen.
--nesting
-W
Wenn Sie dies zusammen mit --container angeben, wird Guix im Container verfügbar gemacht, so dass man sich von innerhalb mit dem Erstellungs-Daemon verbinden kann, der außerhalb des Containers läuft. Das können Sie gebrauchen, wenn Sie vom isolierten Container aus wiederum andere Container erzeugen lassen können wollen wie in dieser Beispielsitzung:
$ guix shell -CW coreutils [env]$ guix shell -C guile -- guile -c '(display "Hallo!\n")' Hallo! [env]$ exit
In der Sitzung wird ein Container gestartet, in dem die
coreutils
-Programme in PATH
zur Verfügung stehen. Von da aus
legen wir mit guix shell
einen inneren, verschachtelten
Container an, der außer Guile nichts verfügbar macht.
Ein weiteres Anwendungsbeispiel ist, wenn Sie eine guix.scm auswerten möchten, der Sie nicht vertrauen, wie hier:
guix shell -CW -- guix build -f guix.scm
Durch einen so durchgeführten Befehl guix build
sind nur Zugriffe
auf Ihr aktuelles Arbeitsverzeichnis möglich.
Intern werden für die Befehlszeilenoption -W mehrere Einstellungen vorgenommen:
guix
-Aufrufen zugegriffen werden kann.
guix
-Befehl wird zum Profil innerhalb des
Containers hinzugefügt, so dass guix describe
innerhalb und
außerhalb des Containers den gleichen Zustand ausgibt.
guix time-machine
und
guix shell
effizient ablaufen.
--rebuild-cache
¶In der Regel wird guix shell
die Umgebung zwischenspeichern, damit
weitere Aufrufe sie ohne Verzögerung verwenden können. Am längsten
nicht verwendete („least recently used“) Einträge im Zwischenspeicher
werden bei guix shell
regelmäßig entfernt. Auch wenn Sie
--file oder --manifest nutzen, wird der Zwischenspeicher
ungültig, sobald die entsprechende Datei geändert wurde.
Mit der Befehlszeilenoption --rebuild-cache wird die
zwischengespeicherte Umgebung erneuert. Sie können --rebuild-cache
verwenden, wenn Sie --file oder --manifest nutzen und die
Datei guix.scm
oder manifest.scm
auf externe
Abhängigkeiten verweist oder eine andere Umgebung ergeben sollte, wenn sich
zum Beispiel Umgebungsvariable geändert haben.
--root=Datei
¶-r Datei
Die Datei zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren.
Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie „persistent“ zu machen.
Wenn diese Option weggelassen wird, wird das Profil von guix shell
zwischengespeichert, damit weitere Aufrufe es ohne Verzögerung verwenden
können. Das ist vergleichbar damit, wenn Sie --root angeben, jedoch
wird guix shell
die am längsten nicht verwendeten
Müllsammlerwurzeln („least recently used“) regelmäßig entfernt.
In manchen Fällen wird guix shell
keinen Zwischenspeicher für die
Profile anlegen, z.B. wenn Umwandlungsoptionen wie --with-latest
angegeben wurde. Das bedeutet, die Umgebung ist nur, solange die Sitzung von
guix shell
besteht, vor dem Müllsammler sicher. Dann müssen Sie,
wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, vielleicht Pakete
neu erstellen oder neu herunterladen.
guix gc
aufrufen hat mehr Informationen über Müllsammlerwurzeln.
guix shell
unterstützt auch alle gemeinsamen Erstellungsoptionen,
die von guix build
unterstützt werden (siehe Gemeinsame Erstellungsoptionen), und die Paketumwandlungsoptionen (siehe Paketumwandlungsoptionen).
Nächste: guix pack
aufrufen, Vorige: guix shell
aufrufen, Nach oben: Entwicklung [Inhalt][Index]
guix environment
aufrufenDer Zweck von guix environment
ist es, dass Sie
Entwicklungsumgebungen leicht anlegen können.
Diese Funktionalität wird demnächst verschwinden: Der Befehl
guix environment
gilt als veraltet. Stattdessen sollten Sieguix shell
benutzen, was einen ähnlichen Zweck erfüllt, aber leichter zu benutzen ist. Sieheguix shell
aufrufen.Veraltet heißt,
guix environment
wird letztendlich entfernt, aber das Guix-Projekt wird gewährleisten, dassguix environment
bis zum 1. Mai 2023 verfügbar bleibt. Reden Sie mit uns unter guix-devel@gnu.org, wenn Sie dabei mitdiskutieren möchten!
Die allgemeine Syntax lautet:
guix environment Optionen Paket…
Folgendes Beispiel zeigt, wie eine neue Shell gestartet wird, auf der alles für die Entwicklung von GNU Guile eingerichtet ist:
guix environment guile
Wenn benötigte Abhängigkeiten noch nicht erstellt worden sind, wird
guix environment
sie automatisch erstellen lassen. Die Umgebung
der neuen Shell ist eine ergänzte Version der Umgebung, in der guix
environment
ausgeführt wurde. Sie enthält neben den existierenden
Umgebungsvariablen auch die nötigen Suchpfade, um das angegebene Paket
erstellen zu können. Um eine „reine“ Umgebung zu erstellen, in der die
ursprünglichen Umgebungsvariablen nicht mehr vorkommen, kann die
Befehlszeilenoption --pure benutzt werden16.
Eine Guix-Umgebung zu verlassen ist gleichbedeutend mit dem Verlassen der
Shell; danach findet sich der Benutzer in der alten Umgebung wieder, in der
er sich vor dem Aufruf von guix environment
befand. Beim nächsten
Durchlauf des Müllsammlers (siehe guix gc
aufrufen) werden Pakete von
der Platte gelöscht, die innerhalb der Umgebung installiert worden sind und
außerhalb nicht länger benutzt werden.
guix environment
definiert die Variable GUIX_ENVIRONMENT
in
der neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen
Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere
Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer
.bashrc festzulegen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash):
if [ -n "$GUIX_ENVIRONMENT" ] then export PS1="\u@\h \w [dev]\$ " fi
… oder um ihr Profil durchzusehen:
$ ls "$GUIX_ENVIRONMENT/bin"
Des Weiteren kann mehr als ein Paket angegeben werden. In diesem Fall wird die Vereinigung der Eingaben der jeweiligen Pakete zugänglich gemacht. Zum Beispiel erzeugt der folgende Befehl eine Shell, in der alle Abhängigkeiten von sowohl Guile als auch Emacs verfügbar sind:
guix environment guile emacs
Manchmal will man keine interaktive Shell-Sitzung. Ein beliebiger Befehl
kann aufgerufen werden, indem Sie nach Angabe der Pakete noch --
vor
den gewünschten Befehl schreiben, um ihn von den übrigen Argumenten
abzutrennen:
guix environment guile -- make -j4
In anderen Situationen ist es bequemer, aufzulisten, welche Pakete in der
Umgebung benötigt werden. Zum Beispiel führt der folgende Befehl
python
aus einer Umgebung heraus aus, in der Python 3 und
NumPy enthalten sind:
guix environment --ad-hoc python-numpy python -- python3
Man kann auch sowohl die Abhängigkeiten eines Pakets haben wollen als auch ein paar zusätzliche Pakete, die nicht Erstellungs- oder Laufzeitabhängigkeiten davon sind, aber trotzdem bei der Entwicklung nützlich sind. Deshalb hängt die Wirkung von der Position der Befehlszeilenoption --ad-hoc ab. Pakete, die links von --ad-hoc stehen, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden. Pakete, die rechts stehen, werden selbst zur Umgebung hinzugefügt. Zum Beispiel erzeugt der folgende Befehl eine Guix-Entwicklungsumgebung, die zusätzlich Git und strace umfasst:
guix environment --pure guix --ad-hoc git strace
Manchmal ist es wünschenswert, die Umgebung so viel wie möglich zu isolieren, um maximale Reinheit und Reproduzierbarkeit zu bekommen. Insbesondere ist es wünschenswert, den Zugriff auf /usr/bin und andere Systemressourcen aus der Entwicklungsumgebung heraus zu verhindern, wenn man Guix auf einer fremden Wirtsdistribution benutzt, die nicht Guix System ist. Zum Beispiel startet der folgende Befehl eine Guile-REPL in einer isolierten Umgebung, einem sogenannten „Container“, in der nur der Store und das aktuelle Arbeitsverzeichnis eingebunden sind:
guix environment --ad-hoc --container guile -- guile
Anmerkung: Die Befehlszeilenoption --container funktioniert nur mit Linux-libre 3.19 oder neuer.
Ein weiterer typischer Anwendungsfall für Container ist, gegenüber
Sicherheitslücken anfällige Anwendungen auszuführen, z.B. Webbrowser. Um
Eolie auszuführen, müssen wir den Zugriff auf manche Dateien und
Verzeichnisse über --expose und --share gewähren. Wir
lassen nss-certs
bereitstellen und machen /etc/ssl/certs/ für
die HTTPS-Authentifizierung sichtbar. Zu guter Letzt behalten wir die
DISPLAY
-Umgebungsvariable bei, weil isolierte grafische Anwendungen
ohne sie nicht angezeigt werden können.
guix environment --preserve='^DISPLAY$' --container --network \ --expose=/etc/machine-id \ --expose=/etc/ssl/certs/ \ --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \ --ad-hoc eolie nss-certs dbus -- eolie
Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.
--check
Hiermit wird die Umgebung angelegt und gemeldet, ob die Shell Umgebungsvariable überschreiben würde. Siehe --check für weitere Informationen.
--root=Datei
¶-r Datei
Die Datei zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren.
Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie „persistent“ zu machen.
Wird diese Option weggelassen, ist die Umgebung nur, solange die Sitzung von
guix environment
besteht, vor dem Müllsammler sicher. Das
bedeutet, wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, müssen
Sie vielleicht Pakete neu erstellen oder neu herunterladen. guix gc
aufrufen hat mehr Informationen über Müllsammlerwurzeln.
--expression=Ausdruck
-e Ausdruck
Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der Ausdruck ausgewertet wird.
Zum Beispiel startet dies:
guix environment -e '(@ (gnu packages maths) petsc-openmpi)'
eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc.
Wenn man dies ausführt:
guix environment --ad-hoc -e '(@ (gnu) %base-packages)'
bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind.
Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden:
guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'
--load=Datei
-l Datei
Eine Umgebung erstellen für das Paket oder die Liste von Paketen, zu der der Code in der Datei ausgewertet wird.
Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):
(use-modules (guix) (gnu packages gdb) (gnu packages autotools) (gnu packages texinfo)) ;; Augment the package definition of GDB with the build tools ;; needed when developing GDB (and which are not needed when ;; simply installing it.) (package (inherit gdb) (native-inputs (modify-inputs (package-native-inputs gdb) (prepend autoconf-2.69 automake texinfo))))
--manifest=Datei
-m Datei
Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.
Dies verhält sich ähnlich wie die gleichnamige Option des Befehls
guix package
(siehe --manifest)
und benutzt auch dieselben Manifestdateien.
Siehe guix shell --export-manifest
für Informationen, wie Sie Befehlszeilenoptionen in ein Manifest
„verwandeln“ können.
--ad-hoc
Alle angegebenen Pakete in der resultierenden Umgebung einschließen, als wären sie Eingaben eines ad hoc definierten Pakets. Diese Befehlszeilenoption ist nützlich, um schnell Umgebungen aufzusetzen, ohne dafür einen Paketausdruck schreiben zu müssen, der die gewünschten Eingaben enthält.
Zum Beispiel wird mit diesem Befehl:
guix environment --ad-hoc guile guile-sdl -- guile
guile
in einer Umgebung ausgeführt, in der sowohl Guile als auch
Guile-SDL zur Verfügung stehen.
Beachten Sie, dass in diesem Beispiel implizit die vorgegebene Ausgabe von
guile
und guile-sdl
verwendet wird, es aber auch möglich ist,
eine bestimmte Ausgabe auszuwählen – z.B. wird mit glib:bin
die Ausgabe bin
von glib
gewählt (siehe Pakete mit mehreren Ausgaben.).
Diese Befehlszeilenoption kann mit dem standardmäßigen Verhalten von
guix environment
verbunden werden. Pakete, die vor
--ad-hoc aufgeführt werden, werden als Pakete interpretiert, deren
Abhängigkeiten zur Umgebung hinzugefügt werden, was dem standardmäßigen
Verhalten entspricht. Pakete, die danach aufgeführt werden, werden selbst
zur Umgebung hinzugefügt.
--profile=Profil
-p Profil
Eine Umgebung mit den Paketen erzeugen, die im Profil installiert
sind. Benutzen Sie guix package
(siehe guix package
aufrufen), um Profile anzulegen und zu verwalten.
--pure
Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit --preserve angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts.
--preserve=Regexp
-E Regexp
Wenn das hier zusammen mit --pure angegeben wird, bleiben die zum regulären Ausdruck Regexp passenden Umgebungsvariablen erhalten – mit anderen Worten werden sie auf eine „weiße Liste“ von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden.
guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \ -- mpirun …
In diesem Beispiel wird mpirun
in einem Kontext ausgeführt, in dem
die einzig definierten Umgebungsvariablen PATH
und solche sind, deren
Name mit ‘SLURM’ beginnt, sowie die üblichen besonders „kostbaren“
Variablen (HOME
, USER
, etc.).
--search-paths
Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.
--system=System
-s System
Versuchen, für das angegebene System zu erstellen – z.B.
i686-linux
.
--container
¶-C
Den Befehl in einer isolierten Umgebung (einem sogenannten „Container“) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption --user nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei /etc/passwd.
Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption --user wird übergeben (siehe unten).
--network
-N
Bei isolierten Umgebungen („Containern“) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät.
--link-profile
-P
Bei isolierten Umgebungen („Containern“) wird das Umgebungsprofil im
Container als ~/.guix-profile verknüpft und ~/.guix-profile
dann in GUIX_ENVIRONMENT
gespeichert. Das ist äquivalent dazu,
~/.guix-profile im Container zu einer symbolischen Verknüpfung auf
das tatsächliche Profil zu machen. Wenn das Verzeichnis bereits existiert,
schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser
Fehler wird immer eintreten, wenn guix environment
im persönlichen
Verzeichnis des Benutzers aufgerufen wurde.
Bestimmte Pakete sind so eingerichtet, dass sie in ~/.guix-profile nach Konfigurationsdateien und Daten suchen,17 weshalb --link-profile benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten.
--user=Benutzer
-u Benutzer
Bei isolierten Umgebungen („Containern“) wird der Benutzername Benutzer anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in /etc/passwd im Container wird also den Namen Benutzer enthalten und das persönliche Verzeichnis wird den Namen /home/BENUTZER tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. Benutzer muss auf dem System nicht existieren.
Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils --share und --expose), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu /home/BENUTZER erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses.
# wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren cd $HOME/wd guix environment --container --user=foo \ --expose=$HOME/test \ --expose=/tmp/target=$HOME/target
Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Datenschutz und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden.
--no-cwd
In isolierten Umgebungen („Containern“) ist das vorgegebene Verhalten, das aktuelle Arbeitsverzeichnis mit dem isolierten Container zu teilen und in der Umgebung sofort in dieses Verzeichnis zu wechseln. Wenn das nicht gewünscht wird, kann das Angeben von --no-cwd dafür sorgen, dass das Arbeitsverzeichnis nicht automatisch geteilt wird und stattdessen in das Persönliche Verzeichnis („Home“-Verzeichnis) gewechselt wird. Siehe auch --user.
--expose=Quelle[=Ziel]
--share=Quelle[=Ziel]
Bei isolierten Umgebungen („Containern“) wird das Dateisystem unter Quelle vom Wirtssystem als Nur-Lese-Dateisystem Ziel (bzw. für --share auch mit Schreibrechten) im Container zugänglich gemacht. Wenn kein Ziel angegeben wurde, wird die Quelle auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt.
Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis /austausch nur für Lesezugriffe zugänglich gemacht wurde:
guix environment --container --expose=$HOME=/austausch --ad-hoc guile -- guile
--emulate-fhs
-F
In Containern wird eine Konfiguration emuliert, die dem Filesystem Hierarchy Standard (FHS) folgt, siehe dessen offizielle Spezifikation. Obwohl Guix vom FHS-Standard abweicht, kann das System in Ihrem Container mit dieser Befehlszeilenoption zu anderen GNU/Linux-Distributionen ähnlicher werden. Dadurch lassen sich dortige Entwicklungsumgebungen reproduzieren und Sie können Programme testen und benutzen, die das Befolgen des FHS-Standards voraussetzen. Wenn die Option angegeben wird, enthält der Container eine Version von glibc, die die im Container befindliche /etc/ld.so.cache als Zwischenspeicher gemeinsamer Bibliotheken ausliest (anders als glibc im normalen Gebrauch von Guix), und die im FHS verlangten Verzeichnisse /bin, /etc, /lib und /usr werden aus dem Profil des Containers übernommen.
guix environment
unterstützt auch alle gemeinsamen
Erstellungsoptionen, die von guix build
unterstützt werden (siehe
Gemeinsame Erstellungsoptionen), und die Paketumwandlungsoptionen (siehe
Paketumwandlungsoptionen).
Nächste: GCC-Toolchain, Vorige: guix environment
aufrufen, Nach oben: Entwicklung [Inhalt][Index]
guix pack
aufrufenManchmal möchten Sie Software an Leute weitergeben, die (noch!) nicht das
Glück haben, Guix zu benutzen. Mit Guix würden sie nur guix package
-i irgendetwas
einzutippen brauchen, aber wenn sie kein Guix haben,
muss es anders gehen. Hier kommt guix pack
ins Spiel.
Anmerkung: Wenn Sie aber nach einer Möglichkeit suchen, Binärdateien unter Maschinen auszutauschen, auf denen Guix bereits läuft, sollten Sie einen Blick auf die Abschnitte
guix copy
aufrufen,guix publish
aufrufen undguix archive
aufrufen werfen.
Der Befehl guix pack
erzeugt ein gut verpacktes
Software-Bündel: Konkret wird dadurch ein Tarball oder eine andere Art
von Archiv mit den Binärdateien der Software erzeugt, die Sie sich gewünscht
haben, zusammen mit all ihren Abhängigkeiten. Der resultierende Archiv kann
auch auf jeder Maschine genutzt werden, die kein Guix hat, und jeder kann
damit genau dieselben Binärdateien benutzen, die Ihnen unter Guix zur
Verfügung stehen. Das Bündel wird dabei auf eine Bit für Bit reproduzierbare
Art erzeugt, damit auch jeder nachprüfen kann, dass darin wirklich
diejenigen Binärdateien enthalten sind, von denen Sie es behaupten.
Um zum Beispiel ein Bündel mit Guile, Emacs, Geiser und all ihren Abhängigkeiten zu erzeugen, führen Sie diesen Befehl aus:
$ guix pack guile emacs emacs-geiser … /gnu/store/…-pack.tar.gz
Als Ergebnis erhalten Sie einen Tarball mit einem Verzeichnis
/gnu/store, worin sich alles relevanten Pakete befinden. Der
resultierende Tarball enthält auch ein Profil mit den drei angegebenen
Paketen; es ist dieselbe Art von Profil, die auch guix package -i
erzeugen würde. Mit diesem Mechanismus wird auch der binäre Tarball zur
Installation von Guix erzeugt (siehe Aus Binärdatei installieren).
Benutzer des Bündels müssten dann aber zum Beispiel /gnu/store/…-profile/bin/guile eintippen, um Guile auszuführen, was Ihnen zu unbequem sein könnte. Ein Ausweg wäre, dass Sie etwa eine symbolische Verknüpfung /opt/gnu/bin auf das Profil anlegen:
guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser
Benutzer müssten dann nur noch /opt/gnu/bin/guile eintippen, um Guile zu genießen.
Doch was ist, wenn die Empfängerin Ihres Bündels keine Administratorrechte auf ihrer Maschine hat, das Bündel also nicht ins Wurzelverzeichnis ihres Dateisystems entpacken kann? Dann möchten Sie vielleicht die Befehlszeilenoption --relocatable benutzen (siehe weiter unten). Mit dieser Option werden verschiebliche Binärdateien erzeugt, die auch in einem beliebigen anderen Verzeichnis in der Dateisystemhierarchie abgelegt und von dort ausgeführt werden können. Man könnte sagen, sie sind pfad-agnostisch. In obigem Beispiel würden Benutzer Ihren Tarball in ihr Persönliches Verzeichnis (das „Home“-Verzeichnis) entpacken und von dort den Befehl ./opt/gnu/bin/guile ausführen.
Eine weitere Möglichkeit ist, das Bündel im Format eines Docker-Abbilds (englisch Docker-Image) zu erzeugen. Das geht mit dem folgenden Befehl:
guix pack -f docker -S /bin=bin guile guile-readline
Das Ergebnis ist ein Tarball, der dem Befehl docker load
übergeben
werden kann, gefolgt von docker run
:
docker load < Datei docker run -ti guile-guile-readline /bin/guile
Dabei steht Datei für das durch guix pack
gelieferte Abbild
und guile-guile-readline
für den „Image-Tag“, der diesem zugewiesen
wurde. In der
Dokumentation von Docker finden Sie nähere Informationen.
Und noch eine weitere Möglichkeit ist, dass Sie ein SquashFS-Abbild mit folgendem Befehl erzeugen:
guix pack -f squashfs bash guile emacs emacs-geiser
Das Ergebnis ist ein SquashFS-Dateisystemabbild, dass entweder als
Dateisystem eingebunden oder mit Hilfe der
Singularity-Container-Ausführungsumgebung als Dateisystemcontainer benutzt
werden kann, mit Befehlen wie singularity shell
oder
singularity exec
.
Es gibt mehrere Befehlszeilenoptionen, mit denen Sie Ihr Bündel anpassen können:
--format=Format
-f Format
Generiert ein Bündel im angegebenen Format.
Die verfügbaren Formate sind:
tarball
Das standardmäßig benutzte Format. Damit wird ein Tarball generiert, der alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält.
docker
Generiert einen Tarball gemäß des
Standards für Docker-Abbilder. Der „Repository-Name“, wie er in der Ausgabe
des Befehls docker images
erscheint, wird in der
Vorgabeeinstellung anhand der Paketnamen berechnet, die auf der Befehlszeile
oder in der Manifest-Datei angegeben wurden. Sie können den Repository-Namen
auch über die Befehlszeilenoption --image-tag festlegen. Siehe die
Ausgabe mit --help-docker-format für mehr Details zu solchen
weitergehenden Optionen.
squashfs
Generiert ein SquashFS-Abbild, das alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält, sowie leere Einhängepunkte für virtuelle Dateisysteme wie procfs.
Anmerkung: Für Singularity müssen Sie eine /bin/sh in das Abbild aufnehmen. Aus diesem Grund gilt für
guix pack -f squashfs
implizit immer auch-S /bin=bin
. Daher muss Ihr Aufruf vonguix pack
immer ungefähr so beginnen:guix pack -f squashfs bash …Wenn Sie vergessen, das
bash
-Paket (oder etwas Ähnliches) zu bündeln, werdensingularity run
undsingularity exec
mit der wenig hilfreichen Meldung „Datei oder Verzeichnis nicht gefunden“ scheitern.
deb
¶Hiermit wird ein Debian-Archiv erzeugt (ein Paket mit der
Dateinamenserweiterung „.deb
“), in dem alle angegebenen Binärdateien
und symbolischen Verknüpfungen enthalten sind. Es kann auf jeder
dpkg-basierten GNU(/Linux)-Distribution installiert werden. Fortgeschrittene
Optionen werden Ihnen angezeigt, wenn Sie die Befehlszeilenoption
--help-deb-format angeben. Mit jenen können Control-Dateien
hinzugefügt werden für eine genaue Steuerung z.B. welche bestimmten
Trigger aktiviert werden oder um mit einem Betreuerskript beliebigen
Konfigurations-Code einzufügen, der bei Installation ausgeführt werden soll.
guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello
Anmerkung: Weil in den mit
guix pack
erzeugten Archiven eine Ansammlung von Store-Objekten enthalten ist und weil in jedemdpkg
-Paket keine im Konflikt stehenden Dateien enthalten sein dürfen, können Sie de facto wahrscheinlich nur ein einziges mitguix pack
erzeugtes „.deb
“-Archiv je System installieren. Allerdings dürfen beliebig viele Guix-Pakete Teil dieses einen Archivs sein.
Warnung:
dpkg
übernimmt die Zuständigkeit für alle Dateien, die im Bündel enthalten sind, auch wenn es die Dateien nicht kennt. Es ist unklug, mit Guix erzeugte „.deb
“-Dateien auf einem System zu installieren, auf dem /gnu/store bereits von anderer Software verwendet wird, also wenn z.B. Guix bereits installiert ist oder andere Nicht-deb
-Bündel installiert sind.
rpm
¶Hiermit wird ein RPM-Archiv erzeugt (ein Paket mit der
Dateinamenserweiterung „.rpm
“), in dem alle angegebenen Binärdateien
und symbolischen Verknüpfungen enthalten sind. Es kann auf jeder
RPM-basierten GNU/Linux-Distribution installiert werden. Beim RPM-Format
werden Prüfsummen zu jeder enthaltenen Datei eingebettet, welche der
rpm
-Befehl benutzt, um die Integrität des Archivs zu
gewährleisten.
Fortgeschrittene RPM-bezogene Befehlszeilenoptionen werden Ihnen angezeigt, wenn Sie die Befehlszeilenoption --help-rpm-format angeben. Mit diesen Befehlszeilenoptionen können Paketbetreuer Skripte einbinden, die zum Beispiel vor oder nach der Installation des RPM-Archivs ablaufen sollen.
Das RPM-Format kennt verschiebbare Pakete. Mit der Befehlszeilenoption
--prefix des rpm
-Befehls ist es Ihnen möglich, ein
RPM-Paket unter ein angegebenes Präfix zu installieren.
guix pack -f rpm -R -C xz -S /usr/bin/hello=bin/hello hello
sudo rpm --install --prefix=/opt /gnu/store/…-hello.rpm
Anmerkung: Anders als bei Debian-Paketen dürfen mehrere RPM-Pakete gleichzeitig installiert werden, wenn Dateien darin im Konflikt stehen, aber identisch sind. Es ist daher in der Regel problemlos möglich, mehrere mit
guix pack
erzeugte RPM-Pakete nebeneinander zu installieren.
Warnung:
rpm
übernimmt die Zuständigkeit für alle Dateien, die im Bündel enthalten sind. Folglich wirdrpm
das Verzeichnis /gnu/store einfach löschen, sobald Sie ein mit Guix erzeugtes RPM-Paket deinstallieren, wenn Sie bei der Installation nicht die Befehlszeilenoption --prefix desrpm
-Befehls benutzt haben. Es ist unklug, mit Guix erzeugte „.rpm
“-Dateien auf einem System zu installieren, auf dem /gnu/store bereits von anderer Software verwendet wird, also wenn z.B. Guix bereits installiert ist oder andere Nicht-rpm
-Bündel installiert sind.
--relocatable
-R
Erzeugt verschiebliche Binärdateien – also pfad-agnostische, „portable“ Binärdateien, die an einer beliebigen Stelle in der Dateisystemhierarchie platziert und von dort ausgeführt werden können.
Wenn diese Befehlszeilenoption einmal übergeben wird, funktionieren die erzeugten Binärdateien nur dann, wenn Benutzernamensräume des Linux-Kernels unterstützt werden. Wenn sie zweimal18 übergeben wird, laufen die Binärdateien notfalls mit anderen Methoden, wenn keine Benutzernamensräume zur Verfügung stehen, funktionieren also ziemlich überall – siehe unten für die Auswirkungen.
Zum Beispiel können Sie ein Bash enthalltendes Bündel erzeugen mit:
guix pack -RR -S /meine-bin=bin bash
… Sie können dieses dann auf eine Maschine ohne Guix kopieren und als normaler Nutzer aus Ihrem Persönlichen Verzeichnis (auch „Home“-Verzeichnis genannt) dann ausführen mit:
tar xf pack.tar.gz ./meine-bin/sh
Wenn Sie in der so gestarteten Shell dann ls /gnu/store
eintippen,
sehen Sie, dass Ihnen angezeigt wird, in /gnu/store befänden sich
alle Abhängigkeiten von bash
, obwohl auf der Maschine überhaupt kein
Verzeichnis /gnu/store existiert! Dies ist vermutlich die einfachste
Art, mit Guix erstellte Software für eine Maschine ohne Guix auszuliefern.
Anmerkung: Wenn die Voreinstellung verwendet wird, funktionieren verschiebliche Binärdateien nur mit Benutzernamensräumen (englisch User namespaces), einer Funktionalität des Linux-Kernels, mit der Benutzer ohne besondere Berechtigungen Dateisysteme einbinden (englisch „mount“) oder die Wurzel des Dateisystems wechseln können („change root“, kurz „chroot“). Alte Versionen von Linux haben diese Funktionalität noch nicht unterstützt und manche Distributionen von GNU/Linux schalten sie ab.
Um verschiebliche Binärdateien zu erzeugen, die auch ohne Benutzernamensräume funktionieren, können Sie die Befehlszeilenoption --relocatable oder -R zweimal angeben. In diesem Fall werden die Binärdateien zuerst überprüfen, ob Benutzernamensräume unterstützt werden, und sonst notfalls einen anderen Ausführungstreiber benutzen, um das Programm auszuführen, wenn Benutzernamensräume nicht unterstützt werden. Folgende Ausführungstreiber werden unterstützt:
default
Es wird versucht, Benutzernamensräume zu verwenden. Sind Benutzernamensräume nicht verfügbar (siehe unten), wird auf PRoot zurückgegriffen.
performance
Es wird versucht, Benutzernamensräume zu verwenden. Sind Benutzernamensräume nicht verfügbar (siehe unten), wird auf Fakechroot zurückgegriffen.
userns
Das Programm wird mit Hilfe von Benutzernamensräumen ausgeführt. Wenn sie nicht unterstützt werden, bricht das Programm ab.
proot
Durch PRoot ausführen. Das Programm PRoot bietet auch Unterstützung für Dateisystemvirtualisierung, indem der Systemaufruf
ptrace
auf das laufende Programm angewendet wird. Dieser Ansatz funktioniert auch ohne besondere Kernel-Unterstützung, aber das Programm braucht mehr Zeit, um selbst Systemaufrufe durchzuführen.fakechroot
Durch Fakechroot laufen lassen. Fakechroot virtualisiert Dateisystemzugriffe, indem Aufrufe von Funktionen der C-Bibliothek wie
open
,stat
,exec
und so weiter abgefangen werden. Anders als bei PRoot entsteht dabei kaum Mehraufwand. Jedoch funktioniert das nicht immer, zum Beispiel werden manche Dateisystemzugriffe aus der C-Bibliothek heraus nicht abgefangen, ebenso wenig wie Dateisystemaufrufe über direkte Systemaufrufe, was zu fehlerbehaftetem Verhalten führt.Wenn Sie ein verpacktes Programm ausführen, können Sie einen der oben angeführten Ausführungstreiber ausdrücklich anfordern, indem Sie die Umgebungsvariable
GUIX_EXECUTION_ENGINE
entsprechend festlegen.
--entry-point=Befehl
Den Befehl als den Einsprungpunkt des erzeugten Bündels
verwenden, wenn das Bündelformat einen solchen unterstützt – derzeit
tun das docker
und squashfs
(Singularity). Der Befehl
wird relativ zum Profil ausgeführt, das sich im Bündel befindet.
Der Einsprungpunkt gibt den Befehl an, der mit docker run
oder
singularity run
beim Start nach Voreinstellung automatisch ausgeführt
wird. Zum Beispiel können Sie das hier benutzen:
guix pack -f docker --entry-point=bin/guile guile
Dann kann das erzeugte Bündel mit z.B. docker run
ohne weitere
Befehlszeilenargumente einfach geladen und ausgeführt werden, um
bin/guile
zu starten:
docker load -i pack.tar.gz docker run Abbild-ID
--entry-point-argument=Befehl
-A Befehl
Befehl als Argument zum Einsprungpunkt des erzeugten Bündels
mitgeben. Diese Befehlszeilenoption wirkt sich nur in Verbindung mit
--entry-point
aus und sie darf auf der Befehlszeile mehrmals
angegeben werden.
guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile
--max-layers=n
Gibt an, auf wie viele Schichten ein Docker-Abbild höchstens aufgeteilt werden soll, wenn das Abbild erzeugt wird.
guix pack -f docker --max-layers=100 guile
Mit dieser Befehlszeilenoption können Sie begrenzen, wie kleinteilig ein Docker-Abbild geschichtet werden soll. Docker-Abbilder können auf mehrere Schichten aufgeteilt werden, wobei das Abbild mit jeder Schicht größer und komplexer wird. Indem Sie die Anzahl Schichten begrenzen, bestimmen Sie, inwieweit folgende Wirkungen erzielt werden sollen:
--expression=Ausdruck
-e Ausdruck
Als Paket benutzen, wozu der Ausdruck ausgewertet wird.
Der Zweck hiervon ist derselbe wie bei der gleichnamigen Befehlszeilenoption
in guix build
(siehe --expression in guix build
).
--manifest=Datei
-m Datei
Die Pakete benutzen, die im Manifest-Objekt aufgeführt sind, das vom Scheme-Code in der angegebenen Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.
Dies hat einen ähnlichen Zweck wie die gleichnamige Befehlszeilenoption in
guix package
(siehe --manifest)
und benutzt dieselben Regeln für Manifest-Dateien. Damit können Sie eine
Reihe von Paketen einmal definieren und dann sowohl zum Erzeugen von
Profilesn als auch zum Erzeugen von Archiven benutzen, letztere für
Maschinen, auf denen Guix nicht installiert ist. Beachten Sie, dass Sie
entweder eine Manifest-Datei oder eine Liste von Paketen
angeben können, aber nicht beides.
Siehe Manifeste verfassen für Informationen dazu, wie man ein Manifest
schreibt. Siehe guix shell
--export-manifest
für Informationen, wie Sie Befehlszeilenoptionen in ein
Manifest „verwandeln“ können.
--system=System
-s System
Versuchen, für die angegebene Art von System geeignete Binärdateien zu
erstellen – z.B. i686-linux
– statt für die Art von
System, das die Erstellung durchführt.
--target=Tripel
¶Lässt für das angegebene Tripel cross-erstellen, dieses muss ein
gültiges GNU-Tripel wie z.B. "aarch64-linux-gnu"
sein (siehe
GNU-Tripel für configure in Autoconf).
--compression=Werkzeug
-C Werkzeug
Komprimiert den resultierenden Tarball mit dem angegebenen
Werkzeug – dieses kann gzip
, zstd
, bzip2
,
xz
, lzip
oder none
für keine Kompression sein.
--symlink=Spezifikation
-S Spezifikation
Fügt die in der Spezifikation festgelegten symbolischen Verknüpfungen zum Bündel hinzu. Diese Befehlszeilenoption darf mehrmals vorkommen.
Die Spezifikation muss von der Form
Quellort=Zielort
sein, wobei der Quellort der Ort
der symbolischen Verknüpfung, die erstellt wird, und Zielort das Ziel
der symbolischen Verknüpfung ist.
Zum Beispiel wird mit -S /opt/gnu/bin=bin
eine symbolische
Verknüpfung /opt/gnu/bin auf das Unterverzeichnis bin im
Profil erzeugt.
--save-provenance
Provenienzinformationen für die auf der Befehlszeile übergebenen Pakete speichern. Zu den Provenienzinformationen gehören die URL und der Commit jedes benutzten Kanals (siehe Kanäle).
Provenienzinformationen werden in der Datei /gnu/store/…-profile/manifest im Bündel zusammen mit den üblichen Paketmetadaten abgespeichert – also Name und Version jedes Pakets, welche Eingaben dabei propagiert werden und so weiter. Die Informationen nützen den Empfängern des Bündels, weil sie dann wissen, woraus das Bündel (angeblich) besteht.
Der Vorgabe nach wird diese Befehlszeilenoption nicht verwendet, weil Provenienzinformationen genau wie Zeitstempel nichts zum Erstellungsprozess beitragen. Mit anderen Worten gibt es unendlich viele Kanal-URLs und Commit-IDs, aus denen dasselbe Bündel stammen könnte. Wenn solche „stillen“ Metadaten Teil des Ausgabe sind, dann wird also die bitweise Reproduzierbarkeit von Quellcode zu Binärdateien eingeschränkt.
--root=Datei
¶-r Datei
Die Datei zu einer symbolischen Verknüpfung auf das erzeugte Bündel machen und als Müllsammlerwurzel registrieren.
--localstatedir
--profile-name=Name
Das „lokale Zustandsverzeichnis“ /var/guix ins resultierende Bündel
aufnehmen, speziell auch das Profil
/var/guix/profiles/per-user/root/Name – der vorgegebene
Name ist guix-profile
, was ~root/.guix-profile
entspricht.
/var/guix enthält die Store-Datenbank (siehe Der Store) sowie
die Müllsammlerwurzeln (siehe guix gc
aufrufen). Es ins Bündel
aufzunehmen, bedeutet, dass der enthaltene Store „vollständig“ ist und von
Guix verwaltet werden kann, andernfalls wäre der Store im Bündel „tot“ und
nach dem Auspacken des Bündels könnte Guix keine Objekte mehr dort
hinzufügen oder entfernen.
Ein Anwendungsfall hierfür ist der eigenständige, alle Komponenten umfassende binäre Tarball von Guix (siehe Aus Binärdatei installieren).
--derivation
-d
Den Namen der Ableitung ausgeben, die das Bündel erstellt.
--bootstrap
Mit den Bootstrap-Binärdateien das Bündel erstellen. Diese Option ist nur für Guix-Entwickler nützlich.
Außerdem unterstützt guix pack
alle gemeinsamen
Erstellungsoptionen (siehe Gemeinsame Erstellungsoptionen) und alle
Paketumwandlungsoptionen (siehe Paketumwandlungsoptionen).
Nächste: guix git authenticate
aufrufen, Vorige: guix pack
aufrufen, Nach oben: Entwicklung [Inhalt][Index]
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: GCC-Toolchain, Nach oben: Entwicklung [Inhalt][Index]
guix git authenticate
aufrufenDer Befehl guix git authenticate
authentifiziert ein Git-Checkout
nach derselben Regel wie für Kanäle (siehe Kanalauthentifizierung). Das bedeutet, dass angefangen beim angegebenen
Commit sichergestellt wird, dass alle nachfolgenden Commits mit einem
OpenPGP-Schlüssel signiert worden sind, dessen Fingerabdruck in der
.guix-authorizations-Datei seines bzw. seiner jeweiligen
Elterncommits aufgeführt ist.
Sie werden diesen Befehl zu schätzen wissen, wenn Sie einen Kanal betreuen. Tatsächlich ist dieser Authentifizierungsmechanismus aber auch bei weiteren Dingen nützlich; vielleicht möchten Sie ihn für Git-Repositorys einsetzen, die gar nichts mit Guix zu tun haben?
Die allgemeine Syntax lautet:
guix git authenticate Commit Unterzeichner [Optionen…]
Nach Vorgabe wird mit diesem Befehl das Git-Checkout im aktuellen Arbeitsverzeichnis authentifiziert. Es wird bei Erfolg nichts ausgegeben und der Exit-Status null zurückgeliefert; bei einem Fehler wird ein von null verschiedener Exit-Status zurückgeliefert. Commit gibt den ersten Commit an, der authentifiziert wird, und Unterzeichner ist der OpenPGP-Fingerabdruck des öffentlichen Schlüssels, mit dem der Commit signiert wurde. Zusammen bilden sie eine „Kanaleinführung“ (siehe Kanaleinführung). Bei Ihrer ersten erfolgreichen Ausführung wird die Einführung in der Datei .git/config in Ihrem Checkout gespeichert, so dass Sie sie bei späteren Aufrufen nicht mehr anzugeben brauchen:
guix git authenticate [Optionen…]
Should you have branches that require different introductions, you can
specify them directly in .git/config. For example, if the branch
called personal-fork
has a different introduction than other
branches, you can extend .git/config along these lines:
[guix "authentication-personal-fork"] introduction-commit = cabba936fd807b096b48283debdcddccfea3900d introduction-signer = C0FF EECA BBA9 E6A8 0D1D E643 A2A0 6DF2 A33A 54FA keyring = keyring
The first run also attempts to install pre-push and post-merge hooks, such
that guix git authenticate
is invoked as soon as you run
git push
, git pull
, and related commands; it does not
overwrite preexisting hooks though.
The command-line options described below allow you to fine-tune the process.
--repository=Verzeichnis
-r Verzeichnis
Das Git-Repository im Verzeichnis statt im aktuellen Verzeichnis öffnen.
--keyring=Referenz
-k Referenz
Den OpenPGP-Schlüsselbund („Keyring“) von der angegebenen Referenz
laden, einem Verweis auf einen Branch wie origin/keyring
oder
my-keyring
. Der Branch muss öffentliche Schlüssel im OpenPGP-Format
in .key-Dateien enthalten, entweder als Binärdateien oder mit
„ASCII-Hülle“. Nach Vorgabe wird der Schlüsselbund von einem Branch namens
keyring
geladen.
--end=Commit
Revisionen bis Commit authentifizieren.
--stats
Nach Abschluss Statistiken über die signierten Commits anzeigen.
--cache-key=Schlüssel
Bereits authentifizierte Commits werden in einer Datei unter ~/.cache/guix/authentication zwischengespeichert. Diese Option erzwingt, dass der Speicher innerhalb dieses Verzeichnisses in der Datei Schlüssel angelegt wird.
--historical-authorizations=Datei
Nach Vorgabe wird jeder Commit, dessen Elterncommit(s) die Datei .guix-authorizations fehlt, als gefälscht angesehen. Mit dieser Option werden dagegen die Autorisierungen in der Datei für jeden Commit ohne .guix-authorizations verwendet. Das Format der Datei ist dasselbe wie bei .guix-authorizations (siehe Format von .guix-authorizations).
Nächste: Zubehör, Vorige: Entwicklung, Nach oben: GNU Guix [Inhalt][Index]
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. Siehe Aufbau des Quellbaums für einen Gesamtüberblick über den Quellcode.
guix repl
aufrufenNächste: Pakete definieren, Nach oben: Programmierschnittstelle [Inhalt][Index]
Aus Programmierersicht werden die Paketdefinitionen der GNU-Distribution als
Guile-Module in Namensräumen wie (gnu packages …)
sichtbar
gemacht19 (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)
20. Es gibt zwei Arten,
solche Paketdefinitionen für die Benutzungsschnittstelle sichtbar zu machen:
-L
von guix package
und anderen
Befehlen (siehe Gemeinsame Erstellungsoptionen) oder durch Setzen der unten
beschriebenen Umgebungsvariablen GUIX_PACKAGE_PATH
zum Suchpfad
hinzuzufügen.
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:
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: Paketvarianten definieren, Vorige: Paketmodule, Nach oben: Programmierschnittstelle [Inhalt][Index]
Mit den Modulen (guix packages)
und (guix build-system)
können
Paketdefinitionen auf einer hohen Abstraktionsebene geschrieben werden. Zum
Beispiel sieht die Paketdefinition bzw. das Rezept für das Paket von
GNU Hello so aus:
(define-module (gnu packages hello) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) #:use-module (guix licenses) #:use-module (gnu packages gawk)) (define-public hello (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (arguments '(#:configure-flags '("--enable-silent-rules"))) (inputs (list gawk)) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "https://www.gnu.org/software/hello/") (license gpl3+)))
Auch ohne ein Experte in Scheme zu sein, könnten Leser erraten haben, was
die verschiedenen Felder dabei bedeuten. Dieser Ausdruck bindet die Variable
hello
an ein <package>
-Objekt, was an sich nur ein Verbund
(Record) ist (siehe Scheme-Verbünde in Referenzhandbuch
zu GNU Guile). Die Felder dieses Paket-Objekts lassen sich mit den
Prozeduren aus dem Modul (guix packages)
auslesen, zum Beispiel
liefert (package-name hello)
– Überraschung! –
"hello"
.
Mit etwas Glück können Sie die Definition vielleicht teilweise oder sogar
ganz aus einer anderen Paketsammlung importieren, indem Sie den Befehl
guix import
verwenden (siehe guix import
aufrufen).
In obigem Beispiel wurde hello
in einem eigenen Modul ganz für sich
alleine definiert, und zwar (gnu packages hello)
. Technisch gesehen
muss es nicht unbedingt in einem solchen Modul definiert werden, aber es ist
bequem, denn alle Module unter (gnu packages …)
werden automatisch
von den Befehlszeilenwerkzeugen gefunden (siehe Paketmodule).
Ein paar Dinge sind noch erwähnenswert in der obigen Paketdefinition:
source
-Feld für die Quelle des Pakets ist ein
<origin>
-Objekt, was den Paketursprung angibt (siehe origin
-Referenz für eine vollständige Referenz). Hier wird dafür die Methode
url-fetch
aus dem Modul (guix download)
benutzt, d.h. die
Quelle ist eine Datei, die über FTP oder HTTP heruntergeladen werden soll.
Das Präfix mirror://gnu
lässt url-fetch
einen der
GNU-Spiegelserver benutzen, die in (guix download)
definiert sind.
Das Feld sha256
legt den erwarteten SHA256-Hashwert der
herunterzuladenden Datei fest. Ihn anzugeben ist Pflicht und er ermöglicht
es Guix, die Integrität der Datei zu überprüfen. Die Form (base32 …)
geht der base32-Darstellung des Hash-Wertes voraus. Sie finden die
base32-Darstellung mit Hilfe der Befehle guix download
(siehe
guix download
aufrufen) und guix hash
(siehe guix hash
aufrufen).
Wenn nötig kann in der origin
-Form auch ein patches
-Feld
stehen, wo anzuwendende Patches aufgeführt werden, sowie ein
snippet
-Feld mit einem Scheme-Ausdruck mit den Anweisungen, wie der
Quellcode zu modifizieren ist.
build-system
legt fest, mit welcher Prozedur das Paket
erstellt werden soll (siehe Erstellungssysteme). In diesem Beispiel steht
gnu-build-system
für das wohlbekannte GNU-Erstellungssystem, wo
Pakete mit der üblichen Befehlsfolge ./configure && make && make check
&& make install
konfiguriert, erstellt und installiert werden.
Sobald Sie anfangen, Pakete für nichttriviale Software zu schreiben, könnten Sie Werkzeuge benötigen, um jene Erstellungsphasen abzuändern, Dateien zu verändern oder Ähnliches. Siehe Werkzeuge zur Erstellung für mehr Informationen dazu.
arguments
gibt an, welche Optionen dem Erstellungssystem
mitgegeben werden sollen (siehe Erstellungssysteme). In diesem Fall
interpretiert gnu-build-system
diese als Auftrag, configure
mit der Befehlszeilenoption --enable-silent-rules auszuführen.
Was hat es mit diesen einfachen Anführungszeichen ('
) auf sich? Sie
gehören zur Syntax von Scheme und führen eine wörtlich zu interpretierende
Datenliste ein; dies nennt sich Maskierung oder Quotierung. '
ist
synonym mit quote
. Ihnen könnte auch `
begegnen (ein
Backquote, stattdessen kann man auch das längere Synonym quasiquote
schreiben); damit können wir eine wörtlich als Daten interpretierte Liste
einführen, aber bei dieser „Quasimaskierung“ kann ,
(ein Komma, oder
dessen Synonym unquote
) benutzt werden, um den ausgewerteten Wert
eines Ausdrucks in diese Liste einzufügen. Quotierung in Referenzhandbuch zu GNU Guile enthält weitere
Details. Hierbei ist also der Wert des arguments
-Feldes eine Liste
von Argumenten, die an das Erstellungssystem weitergereicht werden, wie bei
apply
(siehe apply
in Referenzhandbuch zu GNU Guile).
Ein Doppelkreuz gefolgt von einem Doppelpunkt (#:
) definiert ein
Scheme-Schlüsselwort (siehe Keywords in Referenzhandbuch
zu GNU Guile) und #:configure-flags
ist ein Schlüsselwort, um eine
Befehlszeilenoption an das Erstellungssystem mitzugeben (siehe Coding
With Keywords in Referenzhandbuch zu GNU Guile).
inputs
legt Eingaben an den Erstellungsprozess fest –
d.h. Abhängigkeiten des Pakets zur Erstellungs- oder Laufzeit. Hier fügen
wir eine Eingabe hinzu, eine Referenz auf die Variable gawk
;
gawk ist auch selbst wiederum an ein <package>
-Objekt als
Variablenwert gebunden.
Beachten Sie, dass GCC, Coreutils, Bash und andere essenzielle Werkzeuge
hier nicht als Eingaben aufgeführt werden müssen. Stattdessen sorgt schon
gnu-build-system
dafür, dass diese vorhanden sein müssen (siehe
Erstellungssysteme).
Sämtliche anderen Abhängigkeiten müssen aber im inputs
-Feld
aufgezählt werden. Jede hier nicht angegebene Abhängigkeit wird während des
Erstellungsprozesses schlicht nicht verfügbar sein, woraus ein
Erstellungsfehler resultieren kann.
Siehe package
-Referenz für eine umfassende Beschreibung aller
erlaubten Felder.
Vertiefung: Fühlen Sie sich eingeschüchtert von der Scheme-Sprache oder wurde Ihre Neugier geweckt? Im Kochbuch gibt es einen kurzen Abschnitt, wie man anfängt. Dort werden einige der oben gezeigten Dinge wiederholt und die Grundlagen erklärt. Siehe Ein Schnellkurs in Scheme in GNU-Guix-Kochbuch für weitere Informationen.
Sobald eine Paketdefinition eingesetzt wurde, können Sie das Paket mit Hilfe
des Befehlszeilenwerkzeugs guix build
dann auch tatsächlich erstellen
(siehe Aufruf von guix build
) und dabei jegliche Erstellungsfehler, auf
die Sie stoßen, beseitigen (siehe Fehlschläge beim Erstellen untersuchen). Sie
können den Befehl guix edit
benutzen, um leicht zur
Paketdefinition zurückzuspringen (siehe guix edit
aufrufen). Unter
Paketrichtlinien finden Sie mehr Informationen darüber, wie Sie
Paketdefinitionen testen, und unter guix lint
aufrufen finden Sie
Informationen, wie Sie prüfen, ob eine Definition alle Stilkonventionen
einhält.
Zuletzt finden Sie unter Kanäle Informationen, wie Sie die
Distribution um Ihre eigenen Pakete in einem „Kanal“ erweitern.
Zu all dem sei auch erwähnt, dass Sie das Aktualisieren einer
Paketdefinition auf eine vom Anbieter neu veröffentlichte Version mit dem
Befehl guix refresh
teilweise automatisieren können (siehe
guix refresh
aufrufen).
Hinter den Kulissen wird die einem <package>
-Objekt entsprechende
Ableitung zuerst durch package-derivation
berechnet. Diese Ableitung
wird in der .drv-Datei unter /gnu/store gespeichert. Die von
ihr vorgeschriebenen Erstellungsaktionen können dann durch die Prozedur
build-derivations
umgesetzt werden (siehe Der Store).
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.
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: origin
-Referenz, Nach oben: Pakete definieren [Inhalt][Index]
package
-ReferenzDieser Abschnitt fasst alle in package
-Deklarationen zur Verfügung
stehenden Optionen zusammen (siehe Pakete definieren).
Dieser Datentyp steht für ein Paketrezept.
name
Der Name des Pakets als Zeichenkette.
version
Die Version des Pakets als Zeichenkette. Siehe Versionsnummern, wo erklärt wird, worauf Sie achten müssen.
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 (siehe Erstellungssysteme). Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren wie in diesem Beispiel:
(package
(name "beispiel")
;; hier würden noch ein paar Felder stehen
(arguments
(list #:tests? #f ;Tests überspringen
#:make-flags #~'("VERBOSE=1") ;Optionen für 'make'
#:configure-flags #~'("--enable-frobbing"))))
Welche Schlüsselwortargumente genau unterstützt werden, hängt vom jeweiligen
Erstellungssystem ab (siehe Erstellungssysteme), doch werden Sie
feststellen, dass fast alle #:configure-flags
, #:make-flags
,
#:tests?
und #:phases
berücksichtigen. Insbesondere können Sie
mit dem Schlüsselwort #:phases
den Satz von Erstellungsphasen, der
für Ihr Paket zum Einsatz kommt, ändern (siehe Erstellungsphasen).
Auf der REPL können Sie sich mit speziellen Befehlen interaktiv anzeigen lassen, welchen Wert einige dieser Argumente haben, um Ihnen bei der Fehlersuche zu helfen (siehe Interaktiv mit Guix arbeiten).
Anmerkung zur Kompatibilität: Bis Version 1.3.0 hat man im
arguments
-Feld üblicherweisequote
('
) oderquasiquote
(`
) geschrieben, statt G-Ausdrücke zu verwenden, etwa so:(package ;; hier würden noch ein paar Felder stehen (arguments ;quotierte Argumente, die im alten Stil benutzt wurden '(#:tests? #f #:configure-flags '("--enable-frobbing"))))
Um ein Paket vom diesem Stil in den darüber umzuwandeln, können Sie
guix style -S arguments Paket
ausführen (sieheguix style
aufrufen).
inputs
(Vorgabe: '()
) ¶native-inputs
(Vorgabe: '()
)propagated-inputs
(Vorgabe: '()
)In diesen Feldern wird eine Liste der Abhängigkeiten des Pakets aufgeführt. Dabei ist jedes Listenelement ein „package“-, „origin“- oder sonstiges dateiartiges Objekt (siehe G-Ausdrücke). Um die zu benutzende Ausgabe zu benennen, übergeben Sie eine zweielementige Liste mit der Ausgabe als zweitem Element (siehe Pakete mit mehreren Ausgaben. für mehr Informationen zu Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:
(list libffi libunistring `(,glib "bin")) ;Ausgabe "bin" von GLib
Im obigen Beispiel wird die Ausgabe "out"
für libffi
und
libunistring
benutzt.
Anmerkung zur Kompatibilität: Bis Version 1.3.0 waren Eingabelisten noch Listen 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 umfasste; letztere hatte als Vorgabewert
"out"
. Im folgenden Beispiel wird dasselbe wie oben angegeben, aber im alten Stil für Eingaben:;; Alter Eingabenstil (veraltet). `(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;Ausgabe "bin" von GLibDieser Stil gilt als veraltet. Er wird bislang unterstützt, aber er wird in einer zukünftigen Version entfernt werden. Man sollte ihn nicht für neue Paketdefinitionen gebrauchen. Siehe
guix style
aufrufen für eine Erklärung, wie Sie zum neuen Stil migrieren.
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 guix lint
aufrufen).
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. Siehe Suchpfade, wenn Sie mehr über
Suchpfadspezifikationen erfahren möchten.
Wie auch bei Eingaben wird zwischen native-search-paths
und
search-paths
nur dann ein Unterschied gemacht, wenn Sie
cross-kompilieren. Beim Cross-Kompilieren bezieht sich
native-search-paths
ausschließlich auf native Eingaben, wohingegen
sich die search-paths
ausschließlich auf Eingaben für den „Host“
genannten Rechner beziehen.
Für Pakete wie z.B. Cross-Compiler sind die Ziel-Eingaben wichtig, z.B.
hat unser (angepasster) GCC-Cross-Compiler einen Eintrag für
CROSS_C_INCLUDE_PATH
in search-paths
, damit er
.h-Dateien für das Zielsystem auswählt und nicht die aus
nativen Eingaben. Für die meisten Pakete ist aber einzig
native-search-paths
von Bedeutung.
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, als eine Zeichenkette in Texinfo-Syntax.
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.
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)
(list this-package)
'())))
Es ist ein Fehler, außerhalb einer Paketdefinition auf this-package
zu verweisen.
Die folgenden Hilfsprozeduren sind für den Umgang mit Paketeingaben gedacht.
Name unter den (nativen, propagierten, direkten) Eingaben von
Paket suchen und die Eingabe zurückliefern, wenn sie gefunden wird,
ansonsten #f
.
Name ist der Name eines Pakets, von dem eine Abhängigkeit besteht. So benutzen Sie die Prozeduren:
(use-modules (guix packages) (gnu packages base)) (lookup-package-direct-input coreutils "gmp") ⇒ #<package gmp@6.2.1 …>
In diesem Beispiel erhalten wir das gmp
-Paket, das zu den direkten
Eingaben von coreutils
gehört.
Manchmal werden Sie die Liste der zur Entwicklung an einem Paket nötigen
Eingaben brauchen, d.h. alle Eingaben, die beim Kompilieren des Pakets
sichtbar gemacht werden. Diese Liste wird von der Prozedur
package-development-inputs
geliefert.
Liefert die Liste derjenigen Eingaben, die das Paket zu
Entwicklungszwecken für System braucht. Wenn target wahr ist,
muss dafür ein Ziel wie das GNU-Tripel "aarch64-linux-gnu"
übergeben
werden, damit die Eingaben zum Cross-Kompilieren von Paket
zurückgeliefert werden.
Beachten Sie, dass dazu sowohl explizite als auch implizite Eingaben
gehören. Mit impliziten Eingaben meinen wir solche, die vom
Erstellungssystem automatisch hinzugefügt werden (siehe Erstellungssysteme). Nehmen wir das Paket hello
zur Illustration:
(use-modules (gnu packages base) (guix packages)) hello ⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790> (package-direct-inputs hello) ⇒ () (package-development-inputs hello) ⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)
Für dieses Beispiel liefert package-direct-inputs
die leere Liste
zurück, weil hello
keinerlei explizite Abhängigkeiten hat. Zu
package-development-inputs
gehören auch durch gnu-build-system
implizit hinzugefügte Eingaben, die für die Erstellung von hello
gebraucht werden, nämlich tar, gzip, GCC, libc, Bash und weitere. Wenn Sie
sich das anschauen wollen, zeigt Ihnen guix graph hello
die
expliziten Eingaben, dagegen zeigt guix graph -t bag hello
auch
die impliziten Eingaben (siehe guix graph
aufrufen).
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.
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: package
-Referenz, Nach oben: Pakete definieren [Inhalt][Index]
origin
-ReferenzIn 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.
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
guix download
aufrufen) oder guix hash
(siehe guix hash
aufrufen).
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.
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.
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.
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.
Dies ist eine Variante der Prozedur git-fetch
, die die
Git-Erweiterung LFS (Large File Storage) unterstützt. Sie kann zum
Beispiel dabei helfen, binäre Testdaten herunterzuladen, die im Testkatalog
eines Pakets gebraucht werden.
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 (als Zeichenkette
aus Hexadezimalzeichen) oder sie entspricht dem zu ladenden Tag. Sie können
auch eine „kurze“ Commit-Zeichenkette oder einen Bezeichner wie von
git describe
, z.B. v1.0.1-10-g58d7909c97
, verwenden.
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"))
Bei Mercurial-Repositorys finden Sie im Modul (guix hg-download)
Definitionen für die Methode hg-fetch
für Paketursprünge sowie den
Datentyp hg-reference
. Mit ihnen wird das Versionskontrollsystem
Mercurial unterstützt.
Liefert eine Ableitung mit fester Ausgabe, die Ref lädt, ein
<hg-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.
Dieser Datentyp steht für eine Mercurial-Referenz, die hg-fetch
laden
soll.
url
Die URL des zu klonenden Mercurial-Repositorys.
changeset
This string denotes changeset to fetch.
Bei Subversion-Repositorys finden Sie im Modul (guix svn-download)
Definitionen für die Methode svn-fetch
für Paketursprünge sowie den
Datentyp svn-reference
. Mit ihnen wird das Versionskontrollsystem
Subversion unterstützt.
Liefert eine Ableitung mit fester Ausgabe, die Ref lädt, ein
<svn-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.
Dieser Datentyp steht für eine Subversion-Referenz, die svn-fetch
laden soll.
url
Die URL des zu klonenden Subversion-Repositorys.
revision
Diese Zeichenkette gibt die zu ladende Revision als Zahl an.
recursive?
(Vorgabe: #f
)Dieser boolesche Wert gibt an, ob Subversions „externe Verweise“ rekursiv geladen werden sollen.
user-name
(Vorgabe: #f
)Der Name eines Kontos mit Lesezugriff auf das Repository, wenn das Repository nicht öffentlich ist.
password
(Vorgabe: #f
)Das Passwort zum Zugriff auf das Subversion-Repository, wenn nötig.
Bei Bazaar-Repositorys finden Sie im Modul (guix bzr-download)
Definitionen für die Methode bzr-fetch
für Paketursprünge sowie den
Datentyp bzr-reference
. Mit ihnen wird das Versionskontrollsystem
Bazaar unterstützt.
Liefert eine Ableitung mit fester Ausgabe, die Ref lädt, ein
<bzr-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.
Dieser Datentyp steht für eine Bazaar-Referenz, die bzr-fetch
laden
soll.
url
Die URL des zu klonenden Bazaar-Repositorys.
revision
Diese Zeichenkette gibt die zu ladende Revision als Zahl an.
For CVS repositories, the module (guix cvs-download)
defines the
cvs-fetch
origin method and cvs-reference
data type for
support of the Concurrent Versions System (CVS).
Liefert eine Ableitung mit fester Ausgabe, die Ref lädt, ein
<cvs-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.
Dieser Datentyp steht für eine CVS-Referenz, die cvs-fetch
laden
soll.
root-directory
The CVS root directory.
Modul
Module to fetch.
revision
Revision to fetch.
The example below denotes a version of gnu-standards to fetch:
(cvs-reference
(root-directory ":pserver:anonymous@cvs.savannah.gnu.org:/sources/gnustandards")
(module "gnustandards")
(revision "2020-11-25"))
Nächste: Manifeste verfassen, Vorige: Pakete definieren, Nach oben: Programmierschnittstelle [Inhalt][Index]
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 Manifeste verfassen) 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 den Paketumwandlungsoptionen
--with-version oder --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“ (define gdb-sans-guile (package (inherit gdb) (inputs (modify-inputs (package-inputs gdb) (delete "guile")))))
Mit obiger modify-inputs
-Form wird das "guile"
-Paket aus den
Eingaben im inputs
-Feld von gdb
entfernt. Das
modify-inputs
-Makro hilft Ihnen, wann immer Sie etwas aus den
Paketeingaben entfernen, hinzufügen oder ersetzen möchten.
Ändert die übergebenen Paketeingaben, die package-inputs
& Co.
liefern können, entsprechend der angegebenen Klauseln. Jede Klausel muss
eine der folgenden Formen aufweisen:
(delete Name…)
Die Pakete mit den angegebenen Namen (als Zeichenketten) aus den Eingaben entfernen.
(prepend Paket…)
Jedes Paket vorne an die Eingabenliste anstellen.
(append Paket…)
Jedes Paket am Ende der Eingabenliste anhängen.
(replace Name Ersatz)
Das Paket namens Name durch Ersatz ersetzen.
Mit folgendem Beispiel werden die Eingaben GMP und ACL unter denen von Coreutils weggelassen und libcap wird an dem Anfang hinzugefügt:
(modify-inputs (package-inputs coreutils)
(delete "gmp" "acl")
(prepend libcap))
Mit folgendem Beispiel wird das guile
-Paket unter den Eingaben von
guile-redis
weggelassen und stattdessen wird guile-2.2
verwendet:
(modify-inputs (package-inputs guile-redis)
(replace "guile" guile-2.2))
Die letzte Art Klausel ist append
, was bedeutet, dass Eingaben hinten
an die Liste angehängt werden.
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 (list 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):
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.
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.
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. Wenn
ein Paket passend ist, aber die Eigenschaft hidden?
gesetzt ist, wird
es nicht ersetzt.
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.
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.
Tipps: Es kann kompliziert werden, zu verstehen, was für eine Variante sich nach Behandlung mit einem Gemisch aus obigen Werkzeugen ergibt. Abhilfe leisten Mittel, mit denen Sie die Pakete untersuchen können:
- Sie können das Paket interaktiv auf der REPL untersuchen, um sich zum Beispiel die benutzten Eingaben, den Code in Erstellungsphasen oder die an configure übergebenen Befehlszeilenoptionen anzuschauen (siehe Interaktiv mit Guix arbeiten).
- Wenn Sie die Abhängigkeiten umschreiben, können Sie mit
guix graph
oftmals leichter visualisiert bekommen, welche Änderungen passieren (sieheguix graph
aufrufen).
Nächste: Erstellungssysteme, Vorige: Paketvarianten definieren, Nach oben: Programmierschnittstelle [Inhalt][Index]
Sie können die Paketlisten für guix
-Befehle auf der Befehlszeile
angeben. Das ist bequem, bis die Paketlisten länger und weniger trivial
werden. Dann nämlich wird es bald bequemer, die Paketliste in einer Form zu
haben, die wir ein Manifest nennen. Neudeutsch kann man ein Manifest
wie eine „Bill of Materials“, eine Stückliste oder Güterliste auffassen,
womit ein Satz von Paketen festgelegt wird. Im Normalfall denken Sie sich
ein Code-Schnipsel aus, mit dem das Manifest erstellt wird, bringen den Code
in einer Datei unter, sagen wir manifest.scm, und übergeben diese
Datei mit der Befehlszeilenoption -m (oder --manifest),
die von vielen guix
-Befehlen unterstützt wird. Zum Beispiel könnte
so ein Manifest für einen einfachen Satz Pakete aussehen:
;; Manifest dreier Pakete. (specifications->manifest '("gcc-toolchain" "make" "git"))
Sobald Sie das Manifest haben, können Sie es an z.B. guix
package
übergeben, was dann nur genau diese drei Pakete in Ihr Profil
installiert (siehe die Befehlszeilenoption
-m von guix package
):
guix package -m manifest.scm
… oder Sie übergeben das Manifest an guix shell
(siehe
die Befehlszeilenoption -m von guix
shell
) und richten sich so eine vergängliche Umgebung ein:
guix shell -m manifest.scm
… oder Sie übergeben das Manifest an guix pack
, was ziemlich
genauso geht (siehe die Befehlszeilenoption -m
von guix pack
). Ein Manifest können Sie unter Versionskontrolle
stellen oder es mit anderen Teilen, um deren System schnell auf den gleichen
Stand zu bringen, und vieles mehr.
Doch wie schreibt man eigentlich sein erstes Manifest? Für den Anfang
möchten Sie vielleicht ein Manifest, das dem nachempfunden ist, was Sie
schon in einem Ihrer Profile haben. Statt bei null anzufangen, können Sie
sich mit guix package
ein Manifest generieren lassen (siehe
guix package --export-manifest
):
# Wir schreiben in 'manifest.scm' ein Manifest, das dem # Standardprofil ~/.guix-profile entspricht. guix package --export-manifest > manifest.scm
Oder vielleicht möchten Sie die Argumente von der Befehlszeile in ein
Manifest übertragen. Dabei kann guix shell
helfen (siehe
guix shell --export-manifest
):
# Wir schreiben ein Manifest für die auf der Befehlszeile # angegebenen Pakete. guix shell --export-manifest gcc-toolchain make git > manifest.scm
In beiden Fällen werden bei der Befehlszeilenoption --export-manifest etliche Feinheiten berücksichtigt, um ein originalgetreues Manifest zu erzeugen. Insbesondere werden Paketumwandlungsoptionen wiedergegeben (siehe Paketumwandlungsoptionen).
Anmerkung: Manifeste sind symbolisch: Sie beziehen sich auf die Pakete, die in den aktuell verwendeten Kanälen enthalten sind (siehe Kanäle). Im obigen Beispiel bezieht sich
gcc-toolchain
heute vielleicht auf Version 11, aber in zwei Jahren kann es Version 13 heißen.Wenn Sie wollen, dass immer dieselben Paketversionen und -varianten in Ihre Software-Umgebung aufgenommen werden, sind mehr Informationen nötig, nämlich welche Kanalversionen zur Zeit in Benutzung sind. Das sagt uns
guix describe
. Siehe Guix nachbilden für weitere Informationen.
Sobald Sie sich Ihr erstes Manifest beschafft haben, möchten Sie vielleicht Anpassungen daran vornehmen. Da es sich beim Manifest um Code handelt, stehen Ihnen alle Guix-Programmierschnittstellen zur Verfügung!
Nehmen wir an, Sie hätten gerne ein Manifest, um eine angepasste Variante von GDB, dem GNU-Debugger, einzusetzen, die von Guile nicht abhängt, zusammen mit noch einem anderen Paket. Um auf dem Beispiel aus dem vorigen Abschnitt aufzubauen (siehe Paketvarianten definieren), können Sie das Manifest z.B. folgendermaßen schreiben:
(use-modules (guix packages) (gnu packages gdb) ;für 'gdb' (gnu packages version-control)) ;für 'git' ;; Eine Variante von GDB ohne Abhängigkeit von Guile definieren. (define gdb-sans-guile (package (inherit gdb) (inputs (modify-inputs (package-inputs gdb) (delete "guile"))))) ;; Liefert ein Manifest mit diesem Paket und außerdem Git. (packages->manifest (list gdb-sans-guile git))
Beachten Sie, in diesem Beispiel nimmt das Manifest direkt Bezug auf die
Variablen gdb
und git
, die an je ein Paketobjekt vom Typ
package
gebunden sind (siehe package
-Referenz), statt wie
zuvor specifications->manifest
aufzurufen und damit die Pakete anhand
deren Namens zu finden. Die use-modules
-Form am Dateianfang gibt uns
Zugriff auf den Kern der Paketschnittstelle (siehe Pakete definieren)
und die Module, in denen gdb
und git
definiert sind (siehe
Paketmodule). Nahtlos können wir all dies miteinander
verknüpfen – grenzenlose Möglichkeiten eröffnen sich; lassen Sie Ihrer
Kreativität freien Lauf!
Der Datentyp für Manifeste sowie Prozeduren, um mit ihm umzugehen, sind
definiert im Modul (guix profiles)
. In Code, den Sie mit -m
übergeben, wird es automatisch verfügbar gemacht. Nun folgt die Referenz
dazu.
Der Datentyp, der ein Manifest repräsentiert.
Zurzeit gibt es darin ein Feld:
entries
Dies muss eine Liste von manifest-entry
-Verbundsobjekten sein, wie
hier beschrieben.
Der Datentyp steht für einen Eintrag im Manifest. Zu so einem Manifesteintrag gehören im Wesentlichen Metadaten: der Name und die Version als Zeichenkette, das Objekt selbst (meistens ein Paket), welche Ausgabe man davon haben will (siehe Pakete mit mehreren Ausgaben.) und noch ein paar optionale Informationen, wie wir im Folgenden näher ausführen.
Die meiste Zeit basteln Sie sich die Manifesteinträge nicht selber zusammen,
sondern Sie übergeben ein Paket an package->manifest-entry
, siehe
unten. Aber es könnte Ihnen ein außergewöhnlicher Fall unterkommen, wo Sie
einen Manifesteintrag für etwas erzeugen wollen, das kein Paket ist,
wie in diesem Beispiel:
;; Für ein Nicht-Paketobjekt einen einzelnen Manifesteintrag von Hand schreiben. (let ((hello (program-file "hello" #~(display "Hi!")))) (manifest-entry (name "foo") (version "42") (item (computed-file "verzeichnis-mit-hello" #~(let ((bin (string-append #$output "/bin"))) (mkdir #$output) (mkdir bin) (symlink #$hello (string-append bin "/hello")))))))
Diese Felder stehen zur Verfügung:
name
version
Name und Version für diesen Eintrag als Zeichenkette.
item
Ein Paket oder anderes dateiartiges Objekt (siehe dateiartige Objekte).
output
(Vorgabe: "out"
)Welche der Ausgaben von item
genommen werden soll, sofern item
mehrere Ausgaben umfasst (siehe Pakete mit mehreren Ausgaben.).
dependencies
(Vorgabe: '()
)Die Liste der Manifesteinträge, von denen dieser Eintrag abhängt. Wenn ein Profil erstellt wird, werden die aufgeführten Abhängigkeiten zum Profil hinzugefügt.
In der Regel landen die propagierten Eingaben eines Pakets (siehe
propagated-inputs
) in je einem
Manifesteintrag unter den Abhängigkeiten des Manifesteintrags des Pakets.
search-paths
(Vorgabe: '()
)Die Liste der Suchpfadspezifikationen, die für diesen Eintrag beachtet werden (siehe Suchpfade).
properties
(Vorgabe: '()
)Eine Liste von Paaren aus jeweils einem Symbol und dem Wert dazu. Beim Erstellen eines Profils werden die Eigenschaften serialisiert.
So kann man den Paketen zusätzliche Metadaten aufschnallen wie z.B. welche Umwandlungsoptionen darauf angewendet wurden (siehe Paketumwandlungsoptionen).
parent
(Vorgabe: (delay #f)
)Ein Versprechen (unter englischsprechenden Schemern bekannt als „Promise“), das auf den übergeordneten Manifesteintrag zeigt.
Es wird benutzt, um in auf Manifesteinträge in dependencies
bezogenen
Fehlermeldungen Hinweise auf den Kontext zu geben.
Fasst die Manifeste in der Liste zu einem zusammen und liefert es zurück.
Liefert einen Manifesteintrag für die Ausgabe von Paket, wobei
Ausgabe als Vorgabewert "out"
hat. Als Eigenschaften werden die
properties benutzt; vorgegeben ist die leere Liste oder, wenn eine
oder mehrere Paketumwandlungen auf das Paket angewendet wurden, eine
assoziative Liste mit diesen Umwandlungen, die als Argument an
options->transformation
gegeben werden kann (siehe options->transformation
).
Mit folgendem Code-Schnipsel wird ein Manifest mit einem Eintrag für die
Standardausgabe sowie die Ausgabe namens send-email
des Pakets
git
erstellt:
(use-modules (gnu packages version-control)) (manifest (list (package->manifest-entry git) (package->manifest-entry git "send-email")))
Liefert eine Liste von Manifesteinträgen, jeweils einer für jedes Listenelement in Pakete. In Pakete können Paketobjekte oder Tupel aus Paket und Zeichenkette stehen, wobei die Zeichenkette die Paketausgabe angibt.
Mithilfe dieser Prozedur kann man das obige Manifest auch kürzer aufschreiben:
(use-modules (gnu packages version-control)) (packages->manifest (list git `(,git "send-email")))
Liefert ein Manifest mit den Entwicklungseingaben des Pakets für System. Optional kann mit target das Zielsystem zum Cross-Kompilieren angegeben werden. Zu den Entwicklungseingaben gehören die expliziten und impliziten Eingaben vom Paket.
Genau wie bei der Option -D für guix shell
(siehe
guix shell -D
) beschreibt das sich
daraus ergebende Manifest die Umgebung, um am Paket als Entwickler
mitzuarbeiten. Wenn Sie zum Beispiel eine Entwicklungsumgebung für Inkscape
aufsetzen wollen und darin auch Git für die Versionskontrolle zur Verfügung
haben möchten, geben Sie diese Bestandteilliste mit folgendem Manifest
wieder:
(use-modules (gnu packages inkscape) ;für 'inkscape' (gnu packages version-control)) ;für 'git' (concatenate-manifests (list (package->development-manifest inkscape) (packages->manifest (list git))))
Dieses Beispiel zeigt, wie package->development-manifest
ein
Entwicklungsmanifest mit einem Compiler (GCC), den vielen benutzten
Bibliotheken (Boost, GLib, GTK, etc.) und noch ein paar zusätzlichen
Entwicklungswerkzeugen liefert – das sagen uns die von guix
show inkscape
aufgeführten Abhängigkeiten.
Zum Schluss sind im Modul (gnu packages)
noch Abstraktionen
enthalten, um Manifeste anzufertigen. Dazu gehört, Pakete anhand ihres
Namens zu finden – siehe unten.
Liefert ein Manifest für die Spezifikationen, einer Liste von
Spezifikationen wie "emacs@25.2"
oder "guile:debug"
. Das
Format für die Spezifikationen ist dasselbe wie bei den
Befehlszeilenwerkzeugen guix install
, guix package
und
so weiter (siehe guix package
aufrufen).
Ein Beispiel wäre diese Möglichkeit, das zuvor gezeigte Git-Manifest anders zu formulieren wie hier:
(specifications->manifest '("git" "git:send-email"))
Man bemerke, dass wir uns nicht um use-modules
kümmern müssen, um die
richtige Auswahl von Modulen zu importieren und die richtigen Variablen zu
referenzieren. Stattdessen nehmen wir auf Pakete direkt auf die Weise Bezug,
die wir von der Befehlszeile kennen. Wie praktisch!
Nächste: Erstellungsphasen, Vorige: Manifeste verfassen, Nach oben: Programmierschnittstelle [Inhalt][Index]
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.
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. Siehe Erstellungsphasen für mehr Informationen zu
Erstellungsphasen und wie man sie anpassen kann.
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.
Dieses Erstellungssystem unterstützt eine Reihe von Schlüsselwortargumenten,
die über das arguments
-Feld eines Pakets übergeben werden
können. Hier sind einige der wichtigen Parameter:
#:phases
Mit diesem Argument wird erstellungsseitiger Code angegeben, der zu einer assoziativen Liste von Erstellungsphasen ausgewertet wird. Siehe Erstellungsphasen für nähere Informationen.
#:configure-flags
Diese Liste von Befehlszeilenoptionen (als Zeichenketten) werden dem
configure
-Skript übergeben. Siehe Pakete definieren für ein
Beispiel.
#:make-flags
Diese Zeichenkettenliste enthält Befehlszeilenoptionen, die als Argumente an
make
-Aufrufe in den Phasen build
, check
und
install
übergeben werden.
#:out-of-source?
Dieser Boolesche Ausdruck, nach Vorgabe steht er auf #f
, zeigt an, ob
Erstellungen in einem gesonderten Erstellungsverzeichnis abseits des
Quellbaums ausgeführt werden sollen.
Wenn es auf wahr steht, wird in der configure
-Phase eigens ein
Erstellungsverzeichnis angelegt, dorthin gewechselt und das
configure
-Skript von dort ausgeführt. Das ist nützlich bei Paketen,
die so etwas voraussetzen, wie glibc
.
#:tests?
Dieser Boolesche Ausdruck, nach Vorgabe steht er auf #t
, zeigt an, ob
in der check
-Phase der Testkatalog des Pakets ausgeführt werden soll.
#:test-target
In dieser Zeichenkette, nach Vorgabe "check"
, wird der Name des
Makefile-Ziels angegeben, das die check
-Phase benutzt.
#:parallel-build?
#:parallel-tests?
Mit diesen Booleschen Werten wird festgelegt, ob die Erstellung respektive
der Testkatalog parallel ausgeführt werden soll, indem die
Befehlszeilenoption -j
an make
übergeben wird. Wenn die
Werte wahr sind, wird an make
die Option -jn
übergeben,
wobei n die Zahl ist, die in der --cores-Befehlszeilenoption
an guix-daemon
oder an den guix
-Clientbefehl übergeben
wurde (siehe --cores).
#:validate-runpath?
Dieser Boolesche Ausdruck, nach Vorgabe #t
, bestimmt, ob der in
ELF-Binärdateien, die in der install
-Phase installiert worden sind,
eingetragene RUNPATH
„validiert“ werden soll. ELF-Binärdateien sind
gemeinsame Bibliotheken („Shared Libraries“ mit Dateiendung .so
)
sowie ausführbare Dateien. Siehe die Phase
validate-runpath
für die Details.
#:substitutable?
Dieser Boolesche Ausdruck, nach Vorgabe #t
, sagt aus, ob
Paketausgaben substituierbar sein sollen, d.h. ob Benutzer Substitute
dafür beziehen können sollen, statt sie lokal erstellen zu müssen (siehe
Substitute).
#:allowed-references
#:disallowed-references
Wenn für diese Argumente ein wahrer Wert angegeben wird, muss er einer Liste von Abhängigkeiten entsprechen, die nicht unter den Referenzen der Erstellungsergebnisse vorkommen dürfen. Wenn nach dem Ende der Erstellung eine solche Referenz noch vorhanden ist, schlägt der Erstellungsvorgang fehl.
Sie eignen sich, um zu garantieren, dass ein Paket nicht fälschlich seine Abhängigkeiten aus der Erstellungszeit weiter referenziert, wenn das, zum Beispiel, die Größe unnötig in die Höhe treiben würde.
Auch die meisten anderen Erstellungssysteme unterstützen diese Schlüsselwortargumente.
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.
Diese Variable wird vom Modul (guix build-system agda)
exportiert. Sie implementiert eine Erstellungsprozedur für
Agda-Bibliotheken.
Das Erstellungssystem fügt agda
zu den Eingaben hinzu. Ein anderes
Agda-Paket kann mit dem Schlüssel #:agda
angegeben werden.
Für den Schlüssel #:plan
wird eine Liste von Cons-Zellen der Form
(Regexp . Parameterliste)
angegeben, wobei Regexp
ein regulärer Ausdruck ist, der auf die zu erstellenden .agda
-Dateien
passt, und Parameterliste eine Liste von Parametern sein kann, die an
agda
bei dessen Typprüfung übergeben werden.
Wenn die Bibliothek Haskell benutzt, um eine Datei zu erzeugen, in der alle
importierten Module stehen, können Sie #:gnu-and-haskell?
auf
#t
setzen, damit automatisch ghc
und die Standardeingaben des
gnu-build-system
zur Liste der Eingaben hinzugefügt werden. Sie
werden trotzdem von Hand eine Phase hinzufügen oder die 'build
-Phase
anpassen müssen, wie es in der Definition von agda-stdlib
gemacht
worden ist.
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.
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.
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.
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-asdf-configuration
-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.
Vorgegeben ist, alle .asd-Dateien im Quellverzeichnis zu lesen, um zu
ermitteln, welche Systeme definiert sind. Mit dem Parameter
#:asd-files
kann die Liste zu lesender .asd-Dateien festgelegt
werden. 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 oder wenn mehrere Systeme kompiliert werden, kann der Parameter
#:asd-systems
benutzt werden, um die Liste der Systemnamen anzugeben.
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 so wie bei anderen Paketen in die
Paketdefinition eingetragen werden; wenn sie nur zur Erstellungszeit
gebraucht werden, gehören sie in native-inputs
, sonst in
inputs
. Wenn die Abhängigkeiten Crates sind, die nur als Quellcode
vorliegen, sollten sie zusätzlich über den Parameter #:cargo-inputs
als eine Liste von Paaren aus Name und Spezifikation hinzugefügt, 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
package
-Phase führt cargo package
aus, um eine Quellcode-Crate
zur späteren Nutzung zu erzeugen. Die install
-Phase installiert die
in der Crate definierten Binärdateien. Wenn nicht
install-source? #f
definiert ist, werden auch ein Verzeichnis mit dem
eigenen Quellcode in einer Crate und auch der unverpackte Quellcode
installiert, damit es leichter ist, später an Rust-Paketen zu hacken.
Diese Variable wird von (guix build-system chicken)
exportiert. Mit
ihr werden Module von CHICKEN Scheme
kompiliert. Sie sind auch bekannt als „Eggs“ oder als
„Erweiterungen“. CHICKEN erzeugt C-Quellcode, der dann von einem C-Compiler
kompiliert wird; in diesem Fall vom GCC.
Dieses Erstellungssystem fügt chicken
neben den Paketen des
gnu-build-system
zu den Paketeingaben hinzu.
Das Erstellungssystem kann den Namen des Eggs (noch) nicht automatisch
herausfinden, also müssen Sie, ähnlich wie beim #:import-path
des
go-build-system
, im arguments
-Feld des Pakets den
#:egg-name
festlegen.
Zum Beispiel würden Sie so vorgehen, um ein Paket für das Egg srfi-1
zu schreiben:
(arguments '(#:egg-name "srfi-1"))
Abhängigkeiten von Eggs müssen in propagated-inputs
genannt werden
und nicht in inputs
, weil CHICKEN keine absoluten Referenzen
in kompilierte Eggs einbettet. Abhängigkeiten für Tests sollten wie üblich
in native-inputs
stehen.
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.
#:include
, #:include-regexp
, #:exclude
oder #:exclude-regexp
aufgeführt, werden je nach Filter nur die
ausgewählten Dateien installiert. Jeder Filter wird als Liste von
Zeichenketten angegeben.
#:include
werden all die Dateien installiert, deren Pfad als Suffix
zu mindestens einem der Elemente der angegebenen Liste passt.
#:include-regexp
werden all die Dateien installiert, deren
Unterpfad zu mindestens einem der regulären Ausdrücke in der angegebenen
Liste passt.
#:exclude
und #:exclude-regexp
bewirken das Gegenteil ihrer Include-Entsprechungen. Ohne
#:include
-Angaben werden alle Dateien außer den zu den
Exclude-Filtern passenden installiert. Werden sowohl #:include
als
auch #:exclude
angegeben, werden zuerst die #:include
-Angaben
beachtet und danach wird durch #:exclude
gefiltert.
#:output
argument
can be used to specify which output label the files should be installed to.
In jedem Fall bleiben die Pfade relativ zur Quelle innerhalb des Ziels erhalten.
Beispiele:
("foo/bar" "share/my-app/")
: Installiert bar nach share/my-app/bar.
("foo/bar" "share/my-app/baz")
: Installiert bar nach share/my-app/baz.
("foo/" "share/my-app")
: Installiert den Inhalt von foo innerhalb von share/my-app.
Zum Beispiel wird foo/sub/datei nach share/my-app/sub/datei
installiert.
("foo/" "share/my-app" #:include ("sub/datei"))
: Installiert nur foo/sub/datei
nach share/my-app/sub/datei.
("foo/sub" "share/my-app" #:include ("datei"))
: Installiert foo/sub/datei
nach share/my-app/datei.
("foo/doc" "share/my-app/doc" #:output "doc")
: Install
"foo/doc" to "share/my-app/doc" within the "doc"
output.
Diese Variable wird vom Modul (guix build-system vim)
exportiert. Sie
ist eine Erweiterung des copy-build-system
, mit der Plugins für Vim
und Neovim an die Stelle installiert werden, die von den beiden Texteditoren
als „packpaths“ erwartet wird.
Pakete, die mit dem Präfix vim-
beginnen, werden in den Packpath von
Vim installiert und die, die mit dem Präfix neovim-
beginnen, werden
in den Packpath von Neovim installiert. Wenn ein Verzeichnis doc
beim
Plugin enthalten ist, werden automatisch Helptags generiert.
Für vim-build-system
stehen ein paar mehr Schlüsselwörter zur
Verfügung:
plugin-name
ist es möglich, den Namen des Plugins anzugeben.
Vorgegeben ist hierfür der Name und die Version des Pakets, aber hilfreicher
ist, den Namen anzugeben, der vom Autor beim Anbieter für das Plugin
hinterlegt wurde. Dieser Name ist der, den Sie in Vim für :packadd
benutzen.
install-plan
it is possible to augment the built-in
install-plan of the vim-build-system
. This is particularly helpful
if you have files which should be installed in other locations. For more
information about using the install-plan
, see the
copy-build-system
(siehe copy-build-system
).
#:vim
it is possible to add this package to Vim’s packpath,
in addition to if it is added automatically because of the vim-
prefix in the package’s name.
#:neovim
it is possible to add this package to Neovim’s
packpath, in addition to if it is added automatically because of the
neovim-
prefix in the package’s name.
#:mode
it is possible to adjust the path which the plugin is
installed into. By default the plugin is installed into start
and
other options are available, including opt
. Adding a plugin into
opt
will mean you will need to run, for example, :packadd
foo
to load the foo
plugin from inside of Vim.
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.
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 Produktivumgebung und
Informationen zur Fehlerbehebung liegen bei, was ungefähr -O2 -g
entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.
Diese Variable wird von (guix build-system composer)
exportiert. Sie
implementiert die Erstellungsprozedur für Pakete, die auf die
PHP-Paketverwaltung Composer zugeschnitten
sind.
Das Erstellungssystem fügt automatisch das Paket php
zu den Eingaben
hinzu. Welches Paket benutzt wird, kann mit dem Parameter #:php
geändert werden.
Mit dem Parameter #:test-target
stellen Sie ein, welcher Skript die
Tests laufen lässt. Vorgegeben ist, den Skript test
zu starten, wenn
er existiert. Wenn der Skript nicht existiert, wird durch das
Erstellungssystem phpunit
im Quellverzeichnis ausgeführt, sofern eine
Datei phpunit.xml existiert.
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.
Diese Variable wird von (guix build-system elm)
exportiert. Sie
implementiert eine Erstellungsprozedur für Elm-Pakete ähnlich wie ‘elm install’.
Mit dem Erstellungssystem wird ein Elm-Compiler-Paket zu der Menge der
Eingaben hinzugefügt. Anstelle des vorgegebenen Compiler-Pakets (derzeit ist
es elm-sans-reactor
) kann das stattdessen zu verwendende
Compiler-Paket im Argument #:elm
angegeben werden. Zudem werden
Elm-Pakete, die vom Erstellungssystem selbst vorausgesetzt werden, als
implizite Eingaben hinzugefügt, wenn sie noch keine sind; wenn Sie das
verhindern möchten, übergeben Sie das Argument
#:implicit-elm-package-inputs?
, was in erster Linie zum Bootstrapping
gebraucht wird.
Die Einträge für "dependencies"
und "test-dependencies"
in der
Datei elm.json eines Elm-Pakets werden jeweils mit
propagated-inputs
bzw. inputs
wiedergegeben.
In Elm wird von Paketnamen eine bestimmte Struktur verlangt. Siehe Elm-Pakete für mehr Details auch zu den Werkzeugen in (guix
build-system elm)
, um damit umzugehen.
Derzeit gelten für elm-build-system
ein paar nennenswerte
Einschränkungen:
{ "type":
"package" }
in deren elm.json-Dateien deklariert wurde. Wenn jemand
mit elm-build-system
Elm-Anwendungen erstellen möchte (für die
{ "type": "application" }
deklariert wurde), ist das möglich, aber
es müssen eigens Änderungen an den Erstellungsphasen vorgenommen
werden. Beispiele sind in den Definitionen der Beispielanwendung
elm-todomvc
und im elm
-Paket selbst zu finden (weil die
Web-Oberfläche des Befehls ‘elm reactor’ eine Elm-Anwendung ist).
ELM_HOME
vorkommen, aber mit elm-build-system
klappt das noch
nicht so gut. Diese Einschränkung gilt vor allem für Elm-Anwendungen, weil
dort die Versionen ihrer Abhängigkeiten genau festgelegt werden, während
Elm-Pakete mit einem Bereich von Versionen umgehen können. Ein Ausweg wird
in der oben genannten Beispielanwendung genommen, nämlich benutzt sie die
Prozedur patch-application-dependencies
aus (guix build
elm-build-system)
, um die elm.json-Dateien umzuschreiben, damit sie
sich stattdessen auf die Paketversionen beziehen, die es in der
Erstellungsumgebung tatsächlich gibt. Alternativ könnte man auch auf
Guix-Paketumwandlungen zurückgreifen (siehe Paketvarianten definieren), um den gesamten Abhängigkeitsgraphen einer Anwendung
umzuschreiben.
elm-test-rs
noch
für den Node.js-basierten
elm-test
gibt, um Testläufe durchzuführen.
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.
Cross-Erstellungen von Paketen sind möglich. Wenn für eine bestimmte
Architektur oder ein bestimmtes Betriebssystem erstellt werden muss, kann
man mit den Schlüsselwörtern #:goarch
und #:goos
erzwingen,
dass das Paket für diese Architektur und dieses Betriebssystem erstellt
wird. Die für Go nutzbaren Kombinationen sind
in der
Go-Dokumentation nachlesbar.
Nach dem Schlüsselwort #:go
kann festgelegt werden, mit welchem
Go-Compiler-Paket das Paket erstellt werden soll.
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.
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.
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 durch Aufruf von /test/runtests.jl
ausgeführt.
Der Name des Julia-Pakets und seine UUID werden aus der Datei
Project.toml ausgelesen. Durch Angabe des Arguments
#:julia-package-name
(die Groß-/Kleinschreibung muss stimmen) bzw.
durch #:julia-package-uuid
können andere Werte verwendet werden.
Julia-Pakete verwalten ihre Abhängigkeiten zu Binärdateien für gewöhnlich
mittels JLLWrappers.jl
, einem Julia-Paket, das ein Modul erzeugt
(benannt nach der Bibliothek, die zugänglich gemacht wird, gefolgt von
_jll.jl
).
Um die _jll.jl
-Pakete mit den Pfaden zu Binärdateien hinzuzufügen,
müssen Sie die Dateien in src/wrappers/ patchen, um dem Aufruf an das
Makro JLLWrappers.@generate_wrapper_header
noch ein zweites Argument
mit dem Store-Pfad der Binärdatei mitzugeben.
Zum Beispiel fügen wir für das MbedTLS-Julia-Paket eine Erstellungsphase hinzu (siehe Erstellungsphasen), in der der absolute Dateiname des zugänglich gemachten MbedTLS-Pakets hinzugefügt wird:
(add-after 'unpack 'override-binary-path
(lambda* (#:key inputs #:allow-other-keys)
(for-each (lambda (wrapper)
(substitute* wrapper
(("generate_wrapper_header.*")
(string-append
"generate_wrapper_header(\"MbedTLS\", \""
(assoc-ref inputs "mbedtls") "\")\n"))))
;; Es gibt eine Julia-Datei für jede Plattform,
;; wir ändern sie alle.
(find-files "src/wrappers/" "\\.jl$"))))
Für manche ältere Pakete, die noch keine Project.toml benutzen, muss
auch diese Datei erstellt werden. Das geht intern vonstatten, sofern die
Argumente #:julia-package-name
und #:julia-package-uuid
übergeben werden.
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.
Diese Variable wird vom Modul (guix build-system minetest)
exportiert. Mit ihr ist ein Erstellungssystem für Mods für
Minetest implementiert, was bedeutet,
Lua-Code, Bilder und andere Ressourcen an den Ort zu kopieren, wo Minetest
nach Mods sucht. Das Erstellungssystem verkleinert auch PNG-Bilder und
prüft, dass Minetest die Mod fehlerfrei laden kann.
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.
Diese Variable wird vom Modul (guix build-system mozilla)
exportiert. Durch Sie werden die configure-Befehlszeilenoptionen
--target
und --host
so verwendet, wie es bei von Mozilla
entwickelter Software erwartet wird – aus historischen Gründen wird bei
Mozilla-Software für --host
das System verlangt, von dem aus
cross-kompiliert wird, und für --target
das System, für das
cross-kompiliert wird, entgegen der bei Autotools üblichen Konvention.
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.
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 GUIX_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.
Wenn eine der Ausgaben "python"
heißt, wird das Paket dort hinein
installiert und nicht in die vorgegebene Ausgabe "out"
. Das
ist für Pakete gedacht, bei denen ein Python-Paket nur einen Teil der
Software ausmacht, man also die Phasen des python-build-system
mit
einem anderen Erstellungssystem zusammen verwenden wollen könnte. Oft kann
man das bei Anbindungen für Python gebrauchen.
Diese Variable wird vom Modul guix build-system pyproject
exportiert. Es basiert auf python-build-system und fügt Unterstützung
für pyproject.toml und PEP
517 hinzu. Auch kommt Unterstützung für verschiedene Build Backends und
Testrahmen hinzu.
Die Programmierschnittstelle unterscheidet sich leicht von python-build-system:
#:use-setuptools?
und #:test-target
wurden entfernt.
#:build-backend
ist neu. Die Vorgabe dafür ist #false
, so dass
das richtige Backend wenn möglich aufgrund von pyproject.toml
bestimmt wird.
#:test-backend
ist neu. Die Vorgabe dafür ist #false
, so dass
das richtige Test-Backend wenn möglich aufgrund der Paketeingaben gewählt
wird.
#:test-flags
ist neu. Vorgegeben ist '()
. Die Optionen darin
werden als Befehlszeilenargumente an den Test-Befehl übermittelt. Beachten
Sie, dass ausführliche Ausgaben immer aktiviert werden, falls dies für das
Backend implementiert ist.
Wir stufen es als „experimentell“ ein, weil die Details der Implementierung noch nicht in Stein gemeißelt sind. Dennoch würden wir es begrüßen, wenn Sie es für neue Python-Projekte verwenden (auch für solche, die setup.py haben). Die Programmierschnittstelle wird sich noch ändern, aber wir werden uns um im Guix-Kanal aufkommende Probleme kümmern.
Schlussendlich wird dieses Erstellungssystem für veraltet erklärt werden und in python-build-system aufgehen, wahrscheinlich irgendwann im Jahr 2024.
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.
Diese Variable wird vom Modul (guix build-system renpy)
exportiert. Sie implementiert mehr oder weniger die herkömmliche
Erstellungsprozedur, die für Ren’py-Spiele benutzt wird. Das bedeutet, das
#:game
wird einmal geladen, wodurch Bytecode dafür erzeugt wird.
Des Weiteren wird ein Wrapper-Skript in bin/
und eine *.desktop-Datei
in share/applications
erzeugt. Mit beiden davon kann man das Spiel
starten.
Welches Ren’py-Paket benutzt wird, gibt man mit #:renpy
an. Spiele
können auch in andere Ausgaben als in „out“ installiert werden, indem man
#:output
benutzt.
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.
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.
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.
Diese Variable wird von (guix build-system rebar)
exportiert. Sie
implementiert eine Erstellungsprozedur, die auf
rebar3 aufbaut, einem Erstellungssystem für
Programme, die in der Sprache Erlang geschrieben sind.
Das Erstellungssystem fügt sowohl rebar3
als auch erlang
zu
den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können
diese jeweils mit den Parametern #:rebar
und #:erlang
spezifiziert werden.
Dieses Erstellungssystem basiert auf gnu-build-system
, bei dem aber
die folgenden Phasen geändert wurden:
unpack
Diese Phase entpackt die Quelle wie es auch das gnu-build-system
tut,
schaut nach einer Datei contents.tar.gz
auf der obersten Ebene des
Quellbaumes und wenn diese existiert, wird auch sie entpackt. Das
erleichtert den Umgang mit Paketen, die auf https://hex.pm/, der
Paketsammlung für Erlang und Elixir, angeboten werden.
bootstrap
configure
Die Phasen bootstrap
und configure
fehlen, weil Erlang-Pakete
normalerweise nicht konfiguriert werden müssen.
build
In dieser Phase wird rebar3 compile
mit den Befehlszeilenoptionen aus
#:rebar-flags
ausgeführt.
check
Sofern nicht #:tests? #f
übergeben wird, wird in dieser Phase
rebar3 eunit
ausgeführt oder das Gleiche auf ein anderes bei
#:test-target
angegebenes Ziel. Dabei werden die
Befehlszeilenoptionen aus #:rebar-flags
übergeben.
install
Hier werden die im standardmäßigen Profil default erzeugten Dateien
installiert oder die aus einem mit #:install-profile
angegebenen
anderen Profil.
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 versucht, luatex
auf allen Dateien mit der
Dateiendung .ins auszuführen, und wenn keine gefunden werden, wird es
auf allen .dtx-Dateien ausgeführt. Eine andere Engine oder ein
anderes Format kann mit dem Argument #:tex-engine
bzw.
#:tex-format
angegeben werden. Verschiedene Erstellungsziele können
mit dem Argument #:build-targets
festgelegt werden, das eine Liste
von Dateinamen erwartet.
Es werden außerdem Font-Metriken (d.h. .tfm-Dateien) aus
Metafont-Dateien erzeugt, wenn möglich. Auch können formatierte Dateien für
TeX (d.h. .fmt-Dateien) erzeugt werden, die im Argument
#:create-formats
aufzulisten sind, und es wird je eine symbolische
Verknüpfung im bin/-Verzeichnis zu in texmf-dist/scripts/
befindlichen Skripts angelegt, wenn der Name der Datei im Argument
#:link-scripts
aufgelistet ist.
Das Erstellungssystem fügt texlive-bin
aus dem Modul (gnu
packages tex)
zu den nativen Eingaben hinzu. Das zu benutzende Paket kann
mit dem Argument #:texlive-bin
geändert werden.
Das Paket texlive-latex-bin
aus demselben Modul enthält den Großteil
der Werkzeuge zum Erstellen von TeX-Live-Paketen; weil es praktisch ist,
wird es auch in der Vorgabeeinstellung zu den nativen Eingaben
hinzugefügt. Das kann jedoch störend sein, wenn eine Abhängigkeit von
texlive-latex-bin
selbst erstellt wird. In diesem speziellen Fall
sollten Sie das Argument #:texlive-latex-bin?
auf #f
setzen.
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.
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.
Diese Variable wird von (guix build-system zig)
exportiert. Sie
implementiert die Erstellungsprozeduren für Pakete, die das für
Zig vorgesehene Erstellungssystem (den Befehl
zig build
) benutzen.
Dieses Erstellungssystem fügt zig
neben den Paketen des
gnu-build-system
zu den Paketeingaben hinzu.
Es gibt keine configure
-Phase, weil Zig-Pakete typischerweise nicht
konfiguriert werden müssen. Für den Parameter #:zig-build-flags
geben
Sie eine Liste von Befehlszeilenoptionen an, die zur Erstellung an den
Befehl zig
übergeben werden. Für den Parameter
#:zig-test-flags
geben Sie eine Liste von Befehlszeilenoptionen an,
die während der check
-Phase an den Befehl zig test
übergeben
werden. Sie können einen anderen Compiler als vorgegeben verwenden, indem
Sie das Argument #:zig
angeben.
Mit dem optionalen Parameter zig-release-type
deklarieren Sie, für
welche Art von Release optimiert wird. Diese Werte sind möglich: safe
(sicher), fast
(schnell) oder small
(klein). Vorgegeben ist
der Wert #f
, durch den kein Release als Befehlszeilenoption an den
zig
-Befehl übergeben wird. Dadurch wird eine debug
-Version zur
Fehlersuche erstellt.
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.
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
.
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.
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
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.
Paket
-autoloads.el
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.
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.
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
Die Phase führt ‘meson test’ mit einer unveränderlichen Grundmenge von
Optionen aus. Diese Grundmenge können Sie mit dem Argument
#:test-options
erweitern, um zum Beispiel einen bestimmten
Testkatalog auszuwählen oder zu überspringen.
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
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.
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).
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
.
Diese Variable wird vom Modul (guix build-system tree-sitter)
exportiert. Sie implementiert, wie Grammatiken für
Tree-sitter, einer
Bibliothek zur Syntaxanalyse, kompiliert werden. Dazu wird hauptsächlich
tree-sitter generate
ausgeführt, um Grammatiken in
grammar.js
-Dateien nach JSON und anschließend nach C zu
übersetzen. Daraus wird dann Maschinencode kompiliert.
Tree-sitter-Pakete können mehrere Grammatiken enthalten. Deswegen ermöglicht
es dieses Erstellungssystem, mit einem Schlüsselwort
#:grammar-directories
eine Liste von Orten anzugeben, wo je eine
grammar.js
zu finden ist.
In manchen Fällen hängt die eine Grammatik von der anderen ab, etwa wenn C++
von C abhängt oder TypeScript von JavaScript. Solche Abhängigkeiten können
Sie als Eingaben unter #:inputs
angeben.
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.
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
).
Diese Variable wird vom Modul (guix build-system channel)
exportiert.
Dieses Erstellungssystem ist in erster Linie auf interne Nutzung
ausgelegt. Ein Paket mit diesem Erstellungssystem muss im source
-Feld
eine Kanalspezifikation stehen haben (siehe Kanäle); alternativ kann
für source
der Name eines Verzeichnisses angegeben werden, dann muss
aber ein Argument #:commit
mit dem gewünschten Commit (einer
hexadezimalen Zeichenkette) übergeben werden, so dass dieser erstellt wird.
Optional kann ein #:channels
-Argument mit zusätzlichen Kanälen
angegeben werden.
Damit ergit sich ein Paket mit einer Guix-Instanz der angegebenen Kanäle,
ähnlich der, die guix time-machine
erstellen würde.
Nächste: Werkzeuge zur Erstellung, Vorige: Erstellungssysteme, Nach oben: Programmierschnittstelle [Inhalt][Index]
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
sind dies die hauptsächlichen Erstellungsphasen:
set-paths
Suchpfade in Umgebungsvariablen definieren. Dies geschieht für alle
Eingabepakete. PATH
wird so auch festgelegt. Siehe Suchpfade.
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).
validate-runpath
Den RUNPATH
von ELF-Binärdateien validieren, sofern
#:validate-runpath?
falsch ist (siehe Erstellungssysteme).
Die Validierung besteht darin, sicherzustellen, dass jede gemeinsame
Bibliothek, die von einer ELF-Binärdatei gebraucht wird (sie sind in
DT_NEEDED
-Einträgen im PT_DYNAMIC
-Segment der ELF-Datei
aufgeführt), im DT_RUNPATH
-Eintrag der Datei gefunden wird. Mit
anderen Worten wird gewährleistet, dass es beim Ausführen oder Benutzen
einer solchen Binärdatei nicht zur Laufzeit zu einem Fehler kommt, eine
Datei würde nicht gefunden. Siehe -rpath in The
GNU Linker für mehr Informationen zum RUNPATH
.
Andere Erstellungssysteme haben ähnliche, aber etwas unterschiedliche
Phasen. Zum Beispiel hat das cmake-build-system
gleichnamige 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 von 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
definiert21:
;; 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
(list
#:phases
#~(modify-phases %standard-phases
(delete 'configure)
(add-before 'build 'set-prefix-in-makefile
(lambda* (#:key inputs #:allow-other-keys)
;; Makefile anpassen, damit die 'PREFIX'-
;; Variable auf #$output verweist und
;; 'XMLLINT' auf den richtigen Pfad verweist.
(substitute* "Makefile"
(("PREFIX =.*")
(string-append "PREFIX = " #$output "\n"))
(("XMLLINT =.*")
(string-append "XMLLINT = "
(search-input-file inputs "/bin/xmllint")
"\n"))))))))))
Die neu eingefügte Phase wurde als anonyme Prozedur geschrieben. Solche
namenlosen Prozeduren schreibt man mit lambda*
. Durch sie wird nach
der ausführbaren Datei xmllint in jedem Verzeichnis /bin aller
Paketeingaben gesucht (siehe package
-Referenz). 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
.
Tipp: Sie können den Code, der sich für das
#:phases
-Argument ergibt, interaktiv auf der REPL untersuchen (siehe Interaktiv mit Guix arbeiten).
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: Suchpfade, Vorige: Erstellungsphasen, Nach oben: Programmierschnittstelle [Inhalt][Index]
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.
Dieser Abschnitt dokumentiert Prozeduren, die sich mit Dateinamen von Store-Objekten befassen.
Liefert den Verzeichnisnamen des Stores.
Liefert wahr zurück, wenn sich Datei innerhalb des Stores befindet.
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"
.
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.
Bei den folgenden Prozeduren geht es um Dateien und Dateitypen.
Liefert #t
, wenn das Verzeichnis existiert und ein Verzeichnis
ist.
Liefert #t
, wenn die Datei existiert und ausführbar ist.
Liefert #t
, wenn die Datei eine symbolische Verknüpfung ist
(auch bekannt als „Symlink“).
Liefert #t
, wenn die Datei jeweils eine ELF-Datei, ein
ar
-Archiv (etwa eine statische Bibliothek mit .a) oder eine
gzip-Datei ist.
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.
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).
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.
Das Verzeichnis und all seine Vorgänger erstellen.
Verzeichnis erstellen, wenn es noch nicht existiert, und die Datei mit ihrem Namen dorthin kopieren.
Dem Besitzer der Datei Schreibberechtigung darauf erteilen.
copy-file] [#:keep-mtime? #f] [#:keep-permissions? #t] [#:select? (const
#t)] Copy source directory to destination. Follow symlinks if
follow-symlinks? is true; otherwise, just preserve them. Call
copy-file to copy regular files. Call select?, taking two
arguments, file and stat, for each entry in source, where
file is the entry’s absolute file name and stat is the result of
lstat
(or stat
if follow-symlinks? is true); exclude
entries for which select? does not return true. When
keep-mtime? is true, keep the modification time of the files in
source on those of destination. When keep-permissions? is
true, preserve file permissions. Write verbose output to the log
port.
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.
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. Wenn es zum Beispiel zu einer ganzen Zeile passen soll,
an deren Ende ein Backslash steht, kann der benötigte reguläre Ausdruck etwa
"(.*)\\\\\n$"
lauten.
Dieser Abschnitt beschreibt Prozeduren, um Dateien zu suchen und zu filtern.
Liefert ein Prädikat, das gegeben einen Dateinamen, dessen Basisnamen auf Regexp passt, wahr liefert.
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" …)
Liefert den vollständigen Dateinamen für das Programm, der in
$PATH
gesucht wird, oder #f
, wenn das Programm nicht
gefunden werden konnte.
Liefert den vollständigen Dateinamen von Name, das in allen
Eingaben gesucht wird. search-input-file
sucht nach einer
regulären Datei, während search-input-directory
nach einem
Verzeichnis sucht. Wenn der Name nicht vorkommt, wird eine Ausnahme
ausgelöst.
Hierbei muss für Eingaben eine assoziative Liste wie inputs
oder native-inputs
übergeben werden, die für Erstellungsphasen zur
Verfügung steht (siehe Erstellungsphasen).
Hier ist ein (vereinfachtes) Beispiel, wie search-input-file
in einer
Erstellungsphase des wireguard-tools
-Pakets benutzt wird:
(add-after 'install 'wrap-wg-quick
(lambda* (#:key inputs outputs #:allow-other-keys)
(let ((coreutils (string-append (assoc-ref inputs "coreutils")
"/bin")))
(wrap-program (search-input-file outputs "bin/wg-quick")
#:sh (search-input-file inputs "bin/bash")
`("PATH" ":" prefix ,(list coreutils))))))
Im Modul finden Sie Prozeduren, die geeignet sind, Prozesse zu
erzeugen. Hauptsächlich handelt es sich um praktische Wrapper für Guiles
system*
(siehe system*
in Referenzhandbuch zu GNU Guile).
Programm mit Argumente aufrufen. Es wird eine
&invoke-error
-Ausnahme ausgelöst, wenn der Exit-Code ungleich null
ist, ansonsten wird #t
zurückgeliefert.
Der Vorteil gegenüber system*
ist, dass Sie den Rückgabewert nicht zu
überprüfen brauchen. So vermeiden Sie umständlichen Code in
Shell-Skript-haften Schnipseln etwa in Erstellungsphasen von Paketen.
Liefert wahr, wenn c ein &invoke-error
-Zustand ist.
Auf bestimmte Felder von c zugreifen, einem
&invoke-error
-Zustand.
Auf Port (nach Vorgabe der current-error-port
) eine Meldung für
c, einem &invoke-error
-Zustand, menschenlesbar ausgeben.
Normalerweise würden Sie das so benutzen:
(use-modules (srfi srfi-34) ;für 'guard' (guix build utils)) (guard (c ((invoke-error? c) (report-invoke-error c))) (invoke "date" "--imaginary-option")) -| command "date" "--imaginary-option" failed with status 1
Programm mit Argumente aufrufen und dabei die Standardausgabe
und Standardfehlerausgabe von Programm einfangen. Wenn Programm
erfolgreich ausgeführt wird, wird nichts ausgegeben und der
unbestimmte Wert *unspecified*
zurückgeliefert. Andernfalls wird ein
&message
-Fehlerzustand ausgelöst, der den Status-Code und die Ausgabe
von Programm enthält.
Hier ist ein Beispiel:
(use-modules (srfi srfi-34) ;für 'guard' (srfi srfi-35) ;für 'message-condition?' (guix build utils)) (guard (c ((message-condition? c) (display (condition-message c)))) (invoke/quiet "date") ;alles in Ordnung (invoke/quiet "date" "--imaginary-option")) -| 'date --imaginary-option' exited with status 1; output follows: date: Unbekannte Option »--imaginary-option« „date --help“ liefert weitere Informationen.
(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.
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")))))))
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)))))
Es kommt vor, dass Befehle nur richtig funktionieren, wenn bestimmte Umgebungsvariable festgelegt sind. Meistens geht es dabei um Suchpfade (siehe Suchpfade). Wenn man sie nicht zuweist, finden die Programme vielleicht benötigte Dateien oder andere Befehle nicht oder sie nehmen die „falschen“, je nachdem, in welcher Umgebung man sie ausführt. Einige Beispiele:
PATH
zu finden sind,
GUILE_LOAD_PATH
und GUILE_LOAD_COMPILED_PATH
liegen,
QT_PLUGIN_PATH
erwartet werden.
Das Ziel einer Paketautorin ist, dass Befehle immer auf gleiche Weise
funktionieren statt von externen Einstellungen abhängig zu sein. Eine
Möglichkeit, das zu bewerkstelligen, ist, Befehle in ein dünnes
Wrapper-Skript einzukleiden, welches diese Umgebungsvariablen festlegt
und so dafür sorgt, dass solche Laufzeitabhängigkeiten sicherlich gefunden
werden. Der Wrapper würde in den obigen Beispielen also benutzt, um
PATH
, GUILE_LOAD_PATH
oder QT_PLUGIN_PATH
festzulegen.
Das Wrappen wird erleichtert durch ein paar Hilfsprozeduren im Modul
(guix build utils)
, mit denen Sie Befehle wrappen können.
Einen Wrapper für Programm anlegen. Die Liste Variable sollte so aussehen:
'(Variable Trennzeichen Position Liste-von-Verzeichnissen)
Das Trennzeichen ist optional. Wenn Sie keines angeben, wird :
genommen.
Zum Beispiel kopiert dieser Aufruf:
(wrap-program "foo"
'("PATH" ":" = ("/gnu/…/bar/bin"))
'("CERT_PATH" suffix ("/gnu/…/baz/certs"
"/qux/certs")))
foo nach .foo-real und erzeugt die Datei foo mit folgendem Inhalt:
#!ort/mit/bin/bash export PATH="/gnu/…/bar/bin" export CERT_PATH="$CERT_PATH${CERT_PATH:+:}/gnu/…/baz/certs:/qux/certs" exec -a $0 ort/mit/.foo-real "$@"
Wenn Programm bereits mit wrap-program
gewrappt wurde, wird
sein bestehender Wrapper um die Definitionen jeder Variable in der
Variable-Liste ergänzt. Ansonsten wird ein Wrapper mit sh als
Interpretierer angelegt.
Das Skript Programm in einen Wrapper wickeln, damit Variable
vorher festgelegt werden. Das Format für Variable ist genau wie bei
der Prozedur wrap-program
. Der Unterschied zu wrap-program
ist, dass kein getrenntes Shell-Skript erzeugt wird, sondern das
Programm selbst abgeändert wird, indem zu Beginn von Programm
ein Guile-Skript platziert wird. In der Sprache des Skripts wird das
Guile-Skript als Kommentar interpretiert.
Besondere Kommentare zur Kodierung der Datei, wie es sie bei Python geben kann, werden auf der zweiten Zeile neu erzeugt.
Beachten Sie, dass diese Prozedur auf dieselbe Datei nur einmal angewandt werden kann, denn sie auf Guile-Skripts loszulassen wird nicht unterstützt.
Nächste: Der Store, Vorige: Werkzeuge zur Erstellung, Nach oben: Programmierschnittstelle [Inhalt][Index]
Zahlreiche Programme und Bibliotheken suchen nach Eingabedaten in einem Suchpfad, d.h. einer Liste von Verzeichnissen: Shells wie Bash suchen ausführbare Dateien im Befehls-Suchpfad, ein C-Compiler sucht .h-Dateien in seinem Header-Suchpfad, der Python-Interpretierer sucht .py-Dateien in seinem Suchpfad, der Rechtschreibprüfer hat einen Suchpfad für Wörterbücher und so weiter.
Suchpfade kann man für gewöhnlich über Umgebungsvariable festlegen (siehe
Environment Variables in Referenzhandbuch der
GNU-C-Bibliothek). Zum Beispiel ändern Sie die oben genannten Suchpfade,
indem Sie den Wert der Umgebungsvariablen PATH
, C_INCLUDE_PATH
,
PYTHONPATH
(oder GUIX_PYTHONPATH
) und DICPATH
festlegen – Sie wissen schon, diese Variablen, die auf PATH
enden
und wenn Sie etwas daran falsch machen, werden Dinge „nicht gefunden“.
Vielleicht ist Ihnen auf der Befehlszeile aufgefallen, dass Guix Bescheid
weiß, welche Umgebungsvariablen definiert sein müssen und wie. Wenn Sie
Pakete in Ihr Standardprofil installieren, wird die Datei
~/.guix-profile/etc/profile angelegt, die Sie mit source
in
Ihre Shell übernehmen können, damit die Variablen richtig festgelegt
sind. Genauso werden Ihnen, wenn Sie mit guix shell
eine Umgebung
mit Python und der Python-Bibliothek NumPy erzeugen lassen und die
Befehlszeilenoption --search-paths angeben, die Variablen
PATH
und GUIX_PYTHONPATH
gezeigt (siehe guix shell
aufrufen):
$ guix shell python python-numpy --pure --search-paths export PATH="/gnu/store/…-profile/bin" export GUIX_PYTHONPATH="/gnu/store/…-profile/lib/python3.9/site-packages"
Wenn Sie --search-paths weglassen, werden diese Umgebungsvariablen direkt festgelegt, so dass Python NumPy vorfinden kann:
$ guix shell python python-numpy -- python3 Python 3.9.6 (default, Jan 1 1970, 00:00:01) [GCC 10.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.version.version '1.20.3'
Damit das funktioniert, wurden in der Definition des python
-Pakets
der dafür nötige Suchpfad und die zugehörige Umgebungsvariable
GUIX_PYTHONPATH
deklariert. Das sieht so aus:
(package
(name "python")
(version "3.9.9")
;; davor stehen andere Felder …
(native-search-paths
(list (search-path-specification
(variable "GUIX_PYTHONPATH")
(files (list "lib/python/3.9/site-packages"))))))
Die Aussage hinter dem native-search-paths
-Feld ist, dass wenn das
python
-Paket benutzt wird, die Umgebungsvariable
GUIX_PYTHONPATH
so definiert wird, dass alle Unterverzeichnisse
lib/python/3.9/site-packages in seiner Umgebung enthalten sind. (Mit
native-
meinen wir, dass in einer Umgebung zur Cross-Kompilierung nur
native Eingaben zum Suchpfad hinzugefügt werden dürfen; siehe search-paths
.) In unserem NumPy-Beispiel oben enthält das
Profil, in dem python
auftaucht, genau ein solches Unterverzeichnis,
auf das GUIX_PYTHONPATH
festgelegt wird. Wenn es mehrere
lib/python/3.9/site-packages gibt – etwa wenn wir über
Erstellungsumgebungen reden –, dann werden alle durch Doppelpunkte
(:
) getrennt zu GUIX_PYTHONPATH
hinzugefügt.
Anmerkung: Wir weisen darauf hin, dass
GUIX_PYTHONPATH
als Teil der Definition despython
-Pakets spezifiziert wird und nicht als Teil vonpython-numpy
. Der Grund ist, dass diese Umgebungsvariable zu Python „gehört“ und nicht zu NumPy: Python ist es, das den Wert der Variablen ausliest und befolgt.Daraus folgt, dass wenn Sie ein Profil ohne
python
erzeugen,GUIX_PYTHONPATH
nicht definiert wird, selbst wenn .py-Dateien zum Profil gehören:$ guix shell python-numpy --search-paths --pure export PATH="/gnu/store/…-profile/bin"Das ist logisch, wenn wir das Profil alleine betrachten: Keine Software im Profil würde
GUIX_PYTHONPATH
auslesen.
Selbstverständlich gibt es mehr als nur eine Sorte Suchpfad: Es gibt Pakete,
die mehrere Suchpfade berücksichtigen, solche mit anderen Trennzeichen als
dem Doppelpunkt, solche, die im Suchpfad gleich mehrere Verzeichnisse
aufnehmen, und so weiter. Ein weiterführendes Beispiel ist der Suchpfad von
libxml2: Der Wert der Umgebungsvariablen XML_CATALOG_FILES
wird durch
Leerzeichen getrennt, er muss eine Liste von catalog.xml-Dateien
(keinen Verzeichnissen) fassen und diese sind in
xml-Unterverzeichnissen zu finden – ganz schön
anspruchsvoll. Die Suchpfadspezifikation dazu sieht so aus:
(search-path-specification
(variable "XML_CATALOG_FILES")
(separator " ")
(files '("xml"))
(file-pattern "^catalog\\.xml$")
(file-type 'regular))
Keine Angst; die meisten Suchpfadspezifikationen sind einfacher.
Im Modul (guix search-paths)
wird der Datentyp für
Suchpfadspezifikationen definiert sowie eine Reihe von Hilfsprozeduren. Es
folgt nun die Referenz der Suchpfadspezifikationen.
Der Datentyp für Suchpfadspezifikationen.
variable
Welchen Namen die Umgebungsvariable für diesen Suchpfad trägt (als Zeichenkette).
files
Eine Liste der Unterverzeichnisse, die zum Suchpfad hinzugefügt werden sollen.
separator
(Vorgabe: ":"
)Die Zeichenkette, wodurch Komponenten des Suchpfads voneinander getrennt werden.
Für den Sonderfall, dass für separator
der Wert #f
gewählt
wird, handelt es sich um einen „Suchpfad mit nur einer Komponente“, mit
anderen Worten einen Suchpfad, der höchstens ein Element enthalten darf. Das
ist für Fälle gedacht wie die SSL_CERT_DIR
-Variable (die OpenSSL,
cURL und ein paar andere Pakete beachten) oder die
ASPELL_DICT_DIR
-Variable (auf die das Rechtschreibprüfprogramm
GNU Aspell achtet), welche beide auf ein einzelnes Verzeichnis zeigen
müssen.
file-type
(Vorgabe: 'directory
)Welche Art von Datei passt – hier kann 'directory
(für
Verzeichnisse) oder 'regular
(für reguläre Dateien) angegeben werden,
aber auch jedes andere Symbol, was stat:type
zurückliefern kann
(siehe stat
in Referenzhandbuch zu GNU
Guile).
In the XML_CATALOG_FILES
example above, we would match regular files;
in the Python example, we would match directories.
file-pattern
(Vorgabe: #f
)Das hier muss entweder #f
oder ein regulärer Ausdruck sein, der
angibt, welche Dateien innerhalb der mit dem Feld files
angegebenen Unterverzeichnisse darauf passen.
Again, the XML_CATALOG_FILES
example shows a situation where this is
needed.
Manche Suchpfade sind an mehr als ein Paket gekoppelt. Um sie nicht doppelt
und dreifach zu spezifizieren, sind manche davon vordefiniert in (guix
search-paths)
.
These two search paths indicate where the TR9401 catalog22 or XML catalog files can be found.
Mit diesen beiden Suchpfaden wird angegeben, wo X.509-Zertifikate zu finden sind (siehe X.509-Zertifikate).
Diese vordefinierten Suchpfade kann man wie im folgenden Beispiel benutzen:
(package
(name "curl")
;; eigentlich stehen hier noch ein paar Felder …
(native-search-paths (list $SSL_CERT_DIR $SSL_CERT_FILE)))
Wie macht man aus Suchpfadspezifikationen einerseits und einem Haufen
Verzeichnisse andererseits nun eine Menge von Definitionen für
Umgebungsvariable? Das ist die Aufgabe von evaluate-search-paths
.
Die Suchpfade auswerten. Sie werden als Liste von Suchpfadspezifikationen übergeben und untersucht werden Verzeichnisse, eine Liste von Verzeichnisnamen. Das Ergebnis wird als Liste von Paaren aus Spezifikation und Wert zurückgeliefert. Wenn Sie getenv angeben, werden darüber die momentanen Festlegungen erfasst und nur die nicht bereits gültigen gemeldet.
Das Modul (guix profiles)
enthält eine zugeschnittenere Hilfsprozedur
load-profile
, mit der Umgebungsvariable eines Profils festgelegt
werden.
Nächste: Ableitungen, Vorige: Suchpfade, Nach oben: Programmierschnittstelle [Inhalt][Index]
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 von 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.
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 Portnummer 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 guix copy
aufrufen).
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 123b722. Bitte diskutieren Sie mit uns jegliche Probleme oder Vorschläge, die Sie haben könnten (siehe Mitwirken).
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.
Die Verbindung zum Server trennen.
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.
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).
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.
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: Die Store-Monade, Vorige: Der Store, Nach oben: Programmierschnittstelle [Inhalt][Index]
Systemnahe Erstellungsaktionen sowie die Umgebung, in der selbige durchzuführen sind, werden durch Ableitungen dargestellt. Eine Ableitung enthält folgende Informationen:
x86_64-linux
.
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 guix gc
aufrufen). 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
:
[#: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 Nutzung der Auslagerungsfunktionalität). 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.
#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: G-Ausdrücke, Vorige: Ableitungen, Nach oben: Programmierschnittstelle [Inhalt][Index]
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 „Befehle“ erweitert, mit denen es leichter ist, mit
monadischen Prozeduren umzugehen: run-in-store
und
enter-store-monad
(siehe Interaktiv mit Guix arbeiten). 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.
Es gibt noch andere Meta-Befehle auf der REPL, so etwa ,build
, womit
ein dateiartiges Objekt erstellt wird (siehe Interaktiv mit Guix arbeiten).
Die wichtigsten syntaktischen Formen, um mit Monaden im Allgemeinen
umzugehen, werden im Modul (guix monads)
bereitgestellt und sind im
Folgenden beschrieben.
Alle >>=
- oder return
-Formen im Rumpf in der
Monade auswerten.
Einen monadischen Wert liefern, der den übergebenen Wert kapselt.
Den monadischen Wert mWert binden, wobei sein „Inhalt“ an die monadischen Prozeduren mProz… übergeben wird23. 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
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).
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.
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.
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.
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.
Liefert den momentanen Zustand als einen monadischen Wert.
Setzt den momentanen Zustand auf Wert und liefert den vorherigen Zustand als einen monadischen Wert.
Hängt den Wert vorne an den momentanen Zustand an, der eine Liste sein muss. Liefert den vorherigen Zustand als monadischen Wert.
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.
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:
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).
monadischen Wert in der Store-Monade, in der offenen Verbindung Store laufen lassen.
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.
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.
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:
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.
package-derivation
und package-cross-derivation
(siehe Pakete definieren).
Nächste: guix repl
aufrufen, Vorige: Die Store-Monade, Nach oben: Programmierschnittstelle [Inhalt][Index]
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 von 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-Code24: 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 image))) (gexp->derivation "etwas-mit-vm" #~(begin (use-modules (guix build utils) (gnu build image)) …)))
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.
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.).
Manchmal wird in einem G-Ausdruck grundsätzlich auf die Ausgabe "out"
von etwas verwiesen, aber man möchte ihn eigentlich mit einem Verweis auf
eine andere Ausgabe einfügen. Für solche Fälle gibt es die Prozedur
gexp-input
. Siehe gexp-input.
#+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).
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.
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.
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).
[#: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 Objekt) (Dateiname Objekt Ausgabe) (Dateiname Gexp-Input) (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.
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.
file can be wrapped in the assume-valid-file-name
syntactic
keyword. When this is done, there will not be a warning when
local-file
is used with a non-literal path. The path is still looked
up relative to the current working directory at run time. Wrapping is done
like this:
(define alice-key-file-path "alice.pub") ;; ... (local-file (assume-valid-file-name alice-key-file-path))
file can be wrapped in the assume-source-relative-file-name
syntactic keyword. When this is done, the file name will be looked up
relative to the source file where it appears even when it is not a string
literal.
Dies ist das deklarative Gegenstück zur monadischen Prozedur
interned-file
(siehe interned-file
).
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
.
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
.
(%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")
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
.
(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.
Name mit dem G-Ausdruck als Inhalt repräsentiert. guile ist das zu verwendende Guile-Paket, mit dem die Datei angelegt wird.
Dies ist das deklarative Gegenstück zu gexp->file
.
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.
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*
.
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.
Liefert ein Verzeichnis, was die Vereinigung 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.
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.
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)
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.
Liefert ein gexp-input-Verbundsobjekt, das für die Ausgabe des
dateiartigen Objekts Objekt steht. Dabei legt man mit #:native?
fest, ob eine native Erstellung referenziert wird (wie bei
ungexp-native
) oder nicht.
Diese Prozedur verwendet man, um eine Referenz auf eine bestimmte Ausgabe eines Objekts an eine Prozedur zu übergeben, in der keine Ausgabe ausgewählt wird. Zum Beispiel, wenn Sie diese Prozedur vorliegen haben, die ein dateiartiges Objekt entgegennimmt:
(define (make-symlink Ziel)
(computed-file "eine-symbolische-verknüpfung"
#~(symlink #$Ziel #$output)))
Mit make-symlink
wird hier für sich alleine immer auf die
Standardausgabe von Ziel verwiesen – also auf die Ausgabe
"out"
(siehe Pakete mit mehreren Ausgaben.). Um die Prozedur
auf z.B. die Ausgabe "lib"
des Pakets hwloc
verweisen zu
lassen, ruft man sie so auf:
(make-symlink (gexp-input hwloc "lib"))
Auch eine Komposition mit Funktionen für dateiartige Objekte ist möglich:
(make-symlink
(file-append (gexp-input hwloc "lib") "/lib/libhwloc.so"))
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.
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>
.
Es kann gelegentlich nützlich sein, einen G-Ausdruck in einen S-Ausdruck
umzuwandeln, weil zum Beispiel manche Prüfer (siehe guix lint
aufrufen) einen Blick auf die Erstellungsphasen eines Pakets werfen, um
mögliche Fehler zu finden. Diese Umwandlung können Sie mit dieser Prozedur
bewerkstelligen. Allerdings kann dabei manche Information verloren
gehen. Genauer gesagt werden herunterbrechbare Objekte stillschweigend durch
ein beliebiges Objekt ersetzt. Zurzeit ist dieses beliebige Objekt die Liste
(*approximate*)
, aber verlassen Sie sich nicht darauf, dass es so
bleibt.
Nächste: Interaktiv mit Guix arbeiten, Vorige: G-Ausdrücke, Nach oben: Programmierschnittstelle [Inhalt][Index]
guix repl
aufrufenDer 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 --
!#
Wenn ein Skript in einer interaktiven REPL direkt aus der Shell heraus
ausgeführt werden soll, verwenden Sie die Befehlszeilenoption
--interactive
:
#!/usr/bin/env -S guix repl --interactive
!#
Ohne einen Dateinamen als Argument wird eine Guile-REPL gestartet, so dass man Guix interaktiv benutzen kann (siehe Interaktiv mit Guix arbeiten):
$ 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:
--list-types
Zeigt an, welche Möglichkeiten Sie für Typ angeben können, wenn Sie
guix repl --type=TYP
benutzen, und terminiert.
--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.
--interactive
-i
Im Anschluss, nachdem Datei ausgeführt wurde, die interaktive REPL starten.
--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.
Vorige: guix repl
aufrufen, Nach oben: Programmierschnittstelle [Inhalt][Index]
Mit dem Befehl guix repl
finden Sie sich in einer netten und
freundlichen REPL wieder (das steht für Read-Eval-Print Loop, deutsch
Lese-Auswerten-Schreiben-Schleife) (siehe guix repl
aufrufen). Wenn
Sie mit Guix programmieren möchten – also eigene Pakete definieren,
Manifeste schreiben, Dienste für Guix System oder Guix Home definieren und
so –, dann wird Ihnen sicher gefallen, dass Sie Ihre Ideen auf der REPL
ausprobieren können.
Wenn Sie Emacs benutzen, eignet sich dafür Geiser am meisten (siehe Perfekt eingerichtet), aber Emacs zu benutzen ist nicht unbedingt erforderlich, um
Spaß an der REPL zu haben. Beim Verwenden von guix repl
oder
guile
auf dem Terminal raten wir dazu, dass Sie Readline
aktivieren, um Autovervollständigung zu genießen, und Colorized aktivieren
für farbige Ausgaben. Führen Sie dazu dies aus:
guix install guile guile-readline guile-colorized
… und legen Sie dann eine Datei .guile in Ihrem Persönlichen Verzeichnis („Home“-Verzeichnis) an mit diesem Inhalt:
(use-modules (ice-9 readline) (ice-9 colorized)) (activate-readline) (activate-colorized)
Auf der REPL können Sie Scheme-Code auswerten lassen. Sie tippen also einen Scheme-Ausdruck nach der Eingabeaufforderung und schon zeigt die REPL, zu was er ausgewertet wird:
$ guix repl scheme@(guix-user)> (+ 2 3) $1 = 5 scheme@(guix-user)> (string-append "a" "b") $2 = "ab"
Interessant wird es, wenn Sie auf der REPL anfangen, mit Guix
herumzubasteln. Dazu „importieren“ Sie zunächst das Modul (guix)
,
damit Sie Zugriff auf den Hauptteil der Programmierschnittstelle haben, und
vielleicht wollen Sie auch noch andere nützliche Guix-Module
importieren. Sie könnten (use-modules (guix))
eintippen, denn es ist
gültiger Scheme-Code zum Importieren eines Moduls (siehe Using Guile
Modules in Referenzhandbuch zu GNU Guile), aber auf der REPL können
Sie den Befehl use
als Kurzschreibweise einsetzen (siehe
REPL Commands in Referenzhandbuch zu GNU Guile):
scheme@(guix-user)> ,use (guix) scheme@(guix-user)> ,use (gnu packages base)
Beachten Sie, dass am Anfang jedes REPL-Befehls ein führendes Komma stehen
muss. Der Grund ist, dass ein REPL-Befehl wie use
eben kein
gültiger Scheme-Code ist; er wird von der REPL gesondert interpretiert.
Durch Guix wird die Guile-REPL um zusätzliche Befehle erweitert, die dort
praktisch sind. Einer davon, der Befehl build
, ist hier nützlich: Mit
ihm wird sichergestellt, dass das angegebene dateiartige Objekt erstellt
wurde; wenn nicht, wird es erstellt. In jedem Fall wird der Dateiname jeder
Ausgabe der Erstellung zurückgeliefert. Im folgenden Beispiel erstellen wir
die Pakete coreutils
und grep
sowie eine als
computed-file
angegebene Datei (siehe computed-file
), um sogleich mit der Prozedur scandir
aufzulisten, was für Dateien in Grep im Verzeichnis /bin
enthalten
sind:
scheme@(guix-user)> ,build coreutils $1 = "/gnu/store/…-coreutils-8.32-debug" $2 = "/gnu/store/…-coreutils-8.32" scheme@(guix-user)> ,build grep $3 = "/gnu/store/…-grep-3.6" scheme@(guix-user)> ,build (computed-file "x" #~(mkdir #$output)) /gnu/store/…-x.drv wird erstellt … $4 = "/gnu/store/…-x" scheme@(guix-user)> ,use(ice-9 ftw) scheme@(guix-user)> (scandir (string-append $3 "/bin")) $5 = ("." ".." "egrep" "fgrep" "grep")
Paketautoren kann es gefallen, die Erstellungsphasen oder -optionen für ein
bestimmtes Paket zu untersuchen. Dessen bedarf es vor allem, wenn Sie viel
mit Vererbung von Paketen (inherit
) arbeiten, um Paketvarianten zu
definieren (siehe Paketvarianten definieren) oder wenn Paketargumente
im arguments
-Feld das Ergebnis einer Berechnung sind. In beiden
Fällen kommt man leicht durcheinander, was am Ende die Paketargumente
sind. Mit diesen Befehlen können Sie diese Paketargumente inspizieren:
scheme@(guix-user)> ,phases grep $1 = (modify-phases %standard-phases (add-after 'install 'fix-egrep-and-fgrep (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"))))))) scheme@(guix-user)> ,configure-flags findutils $2 = (list "--localstatedir=/var") scheme@(guix-user)> ,make-flags binutils $3 = '("MAKEINFO=true")
Will man die einzelnen Schritte von Guix nachvollziehen, eignet sich der
Befehl lower
: Er nimmt ein dateiartiges Objekt, um es zu einer
Ableitung oder einem Store-Objekt „herunterzubrechen“ (siehe
Ableitungen):
scheme@(guix-user)> ,lower grep $6 = #<derivation /gnu/store/…-grep-3.6.drv => /gnu/store/…-grep-3.6 7f0e639115f0> scheme@(guix-user)> ,lower (plain-file "x" "Hallo!") $7 = "/gnu/store/…-x"
Die vollständige Liste der REPL-Befehle bekommen Sie zu sehen, wenn Sie
,help guix
eingeben. Hier eine Referenz:
Das Objekt herunterbrechen und erstellen, wenn es noch nicht erstellt ist. Als Ergebnis zurückgeliefert wird der Dateiname jeder Ausgabe.
Das Objekt zu einer Ausgabe oder einem Dateinamen im Store herunterbrechen und diesen zurückliefern.
Legt Stufe als die Ausführlichkeitsstufe für Erstellungen fest.
Das ist das Gleiche wie die Befehlszeilenoption --verbosity (siehe Gemeinsame Erstellungsoptionen): Stufe 0 zeigt gar nichts an, Stufe 1 nur Ereignisse bei der Erstellung und auf höheren Stufen bekommen Sie Erstellungsprotokolle angezeigt.
Diese REPL-Befehle liefern den Wert eines Bestandteils des
arguments
-Feldes von Paket zurück (siehe package
-Referenz): Ersterer zeigt den „staged code“, der mit #:phases
assoziiert ist (siehe Erstellungsphasen), der zweite Befehl zeigt den Code
für #:configure-flags
und mit ,make-flags
wird einem der Code
für #:make-flags
geliefert.
Den Ausdruck, einen monadischen Ausdruck, durch die Store-Monade laufen lassen. Siehe Die Store-Monade für mehr Erklärungen.
Damit betreten Sie eine neue REPL, die monadische Ausdrücke auswerten kann
(siehe Die Store-Monade). Sie können diese „innere“ REPL verlassen,
indem Sie ,q
eintippen.
Nächste: Fremde Architekturen, Vorige: Programmierschnittstelle, Nach oben: GNU Guix [Inhalt][Index]
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.
guix build
guix edit
aufrufenguix download
aufrufenguix hash
aufrufenguix import
aufrufenguix refresh
aufrufenguix style
aufrufenguix lint
aufrufenguix size
aufrufenguix graph
aufrufenguix publish
aufrufenguix challenge
aufrufenguix copy
aufrufenguix container
aufrufenguix weather
aufrufenguix processes
aufrufen
Nächste: guix edit
aufrufen, Nach oben: Zubehör [Inhalt][Index]
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 guix package
aufrufen). 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 | awk '{ print $1 "@" $2 }')
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: Paketumwandlungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]
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 guix challenge
aufrufen 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 Nutzung der Auslagerungsfunktionalität). 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, 2 ist wie 1, aber zeigt zusätzlich an, von welcher URL heruntergeladen wird, und 3 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
.
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: Zusätzliche Erstellungsoptionen, Vorige: Gemeinsame Erstellungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]
Eine weitere Gruppe von Befehlszeilenoptionen, die guix build
und
auch guix package
unterstützen, sind
Paketumwandlungsoptionen. Diese Optionen ermöglichen es,
Paketvarianten zu definieren – zum Beispiel können Pakete aus
einem anderen Quellcode als normalerweise erstellt werden. Damit ist es
leicht, angepasste Pakete schnell zu erstellen, ohne die vollständigen
Definitionen von Paketvarianten einzutippen (siehe Pakete definieren).
Paketumwandlungsoptionen bleiben über Aktualisierungen hinweg erhalten:
guix upgrade
versucht, Umwandlungsoptionen, die vorher zur
Erstellung des Profils benutzt wurden, auf die aktualisierten Pakete
anzuwenden.
Im Folgenden finden Sie die verfügbaren Befehlszeilenoptionen. Die meisten Befehle unterstützen sie ebenso wie eine Option --help-transform, mit der all die verfügbaren Optionen und je eine Kurzbeschreibung dazu angezeigt werden. (Diese Optionen werden der Kürze wegen nicht in der Ausgabe von --help aufgeführt.)
--tune[=CPU]
Die optimierte Version als „tunebar“ markierter Pakete benutzen. CPU
gibt die Prozessorarchitektur an, für die optimiert werden soll. Wenn als
CPU die Bezeichnung native
angegeben wird oder nichts angegeben
wird, wird für den Prozessor optimiert, auf dem der Befehl guix
läuft.
Gültige Namen für CPU sind genau die, die vom zugrunde liegenden
Compiler erkannt werden. Vorgegeben ist, dass als Compiler die GNU Compiler
Collection benutzt wird. Auf x86_64-Prozessoren gehören nehalem
,
haswell
, und skylake
zu den CPU-Namen (siehe -march
in Using the GNU Compiler Collection (GCC)).
Mit dem Erscheinen neuer Generationen von Prozessoren wächst der Standardbefehlssatz (die „Instruction Set Architecture“, ISA) um neue Befehle an, insbesondere wenn es um Befehle zur Parallelverarbeitung geht („Single-Instruction/Multiple-Data“, SIMD). Zum Beispiel implementieren sowohl die Core2- als auch die Skylake-Prozessoren den x86_64-Befehlssatz, jedoch können nur letztere AVX2-SIMD-Befehle ausführen.
Der Mehrwert, den --tune bringt, besteht in erster Linie bei
Programmen, für die SIMD-Fähigkeiten geeignet wären und die über
keinen Mechanismus verfügen, zur Laufzeit die geeigneten Codeoptimierungen
zuzuschalten. Pakete, bei denen die Eigenschaft tunable?
angegeben
wurde, werden bei der Befehlszeilenoption --tune als tunebare
Pakete optimiert. Eine Paketdefinition, bei der diese Eigenschaft
hinterlegt wurde, sieht so aus:
(package
(name "hello-simd")
;; …
;; Dieses Paket kann von SIMD-Erweiterungen profitieren,
;; deshalb markieren wir es als "tunebar".
(properties '((tunable? . #t))))
Andere Pakete werden als nicht tunebar aufgefasst. Dadurch kann Guix allgemeine Binärdateien verwenden, wenn sich die Optimierung für einen bestimmten Prozessor wahrscheinlich nicht lohnt.
Bei der Erstellung tunebarer Pakete wird -march=CPU
übergeben. Intern wird die Befehlszeilenoption -march durch einen
Compiler-Wrapper an den eigentlichen Wrapper übergeben. Weil die
Erstellungsmaschine den Code für die Mikroarchitektur vielleicht gar nicht
ausführen kann, wird der Testkatalog bei der Erstellung tunebarer Pakete
übersprungen.
Damit weniger Neuerstellungen erforderlich sind, werden die von tunebaren Paketen abhängigen Pakete mit den optimierten Paketen veredelt (siehe Veredelungen). Wenn Sie --no-grafts übergeben, wirkt --tune deshalb nicht mehr.
Wir geben dieser Technik den Namen Paket-Multiversionierung: Mehrere Varianten des tunebaren Pakets können erstellt werden; eine für jede Prozessorvariante. Das ist die grobkörnige Entsprechung der Funktions-Multiversionierung, die in der GNU-Toolchain zu finden ist (siehe Function Multiversioning in Using the GNU Compiler Collection (GCC)).
--with-source=Quelle
--with-source=Paket=Quelle
--with-source=Paket@Version=Quelle
Den Paketquellcode für das Paket von der angegebenen Quelle
holen und die Version als seine Versionsnummer verwenden. Die
Quelle muss ein Dateiname oder eine URL sein wie bei guix
download
(siehe guix download
aufrufen).
Wird kein Paket angegeben, wird als Paketname derjenige auf der
Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende der
Quelle passt – wenn z.B. als Quelle die Datei
/src/guile-2.0.10.tar.gz
angegeben wurde, entspricht das dem
guile
-Paket.
Ebenso wird, wenn keine Version angegeben wurde, die Version als
Zeichenkette aus der Quelle abgeleitet; im vorherigen Beispiel wäre
sie 2.0.10
.
Mit dieser Option können Nutzer versuchen, eine andere Version ihres Pakets
auszuprobieren, als die in der Distribution enthaltene Version. Folgendes
Beispiel lädt ed-1.7.tar.gz von einem GNU-Spiegelserver herunter und
benutzt es als Quelle für das ed
-Paket:
guix build ed --with-source=mirror://gnu/ed/ed-1.4.tar.gz
Für Entwickler wird es einem durch --with-source leicht gemacht, „Release Candidates“, also Vorabversionen, zu testen, oder sogar welchen Einfluss diese auf abhängige Pakete haben:
guix build elogind --with-source=…/shepherd-0.9.0rc1.tar.gz
… oder ein Checkout eines versionskontrollierten Repositorys in einer isolierten Umgebung zu erstellen:
$ git clone git://git.sv.gnu.org/guix.git $ guix build guix --with-source=guix@1.0=./guix
--with-input=Paket=Ersatz
Abhängigkeiten vom Paket durch eine Abhängigkeit vom
Ersatz-Paket ersetzen. Als Paket muss ein Paketname angegeben
werden und als Ersatz eine Paketspezifikation wie guile
oder
guile@1.8
.
Mit folgendem Befehl wird zum Beispiel Guix erstellt, aber statt der
aktuellen stabilen Guile-Version hängt es von der alten Guile-Version
guile@2.2
ab:
guix build --with-input=guile=guile@2.2 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.2
neu erstellt.
Implementiert wird das alles mit der Scheme-Prozedur
package-input-rewriting/spec
(siehe package-input-rewriting/spec
).
--with-graft=Paket=Ersatz
Dies verhält sich ähnlich wie mit --with-input, aber mit dem wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette neu erstellt wird, sondern das Ersatz-Paket erstellt und die ursprünglichen Binärdateien, die auf das Paket verwiesen haben, damit veredelt werden. Im Abschnitt Sicherheitsaktualisierungen finden Sie weitere Informationen über Veredelungen.
Zum Beispiel veredelt folgender Befehl Wget und alle Abhängigkeiten davon mit der Version 3.5.4 von GnuTLS, indem Verweise auf die ursprünglich verwendete GnuTLS-Version ersetzt werden:
guix build --with-graft=gnutls=gnutls@3.5.4 wget
Das hat den Vorteil, dass es viel schneller geht, als alles neu zu erstellen. Die Sache hat aber einen Haken: Veredelung funktioniert nur, wenn das Paket und sein Ersatz miteinander streng kompatibel sind – zum Beispiel muss, wenn diese eine Programmbibliothek zur Verfügung stellen, deren Binärschnittstelle („Application Binary Interface“, kurz ABI) kompatibel sein. Wenn das Ersatz-Paket auf irgendeine Art inkompatibel mit dem Paket ist, könnte das Ergebnispaket unbrauchbar sein. Vorsicht ist also geboten!
--with-debug-info=Paket
Das Paket auf eine Weise erstellen, die Informationen zur Fehlersuche
enthält, und von ihm abhängige Pakete damit veredeln. Das ist nützlich, wenn
das Paket noch keine Fehlersuchinformationen als installierbare
debug
-Ausgabe enthält (siehe Dateien zur Fehlersuche installieren).
Als Beispiel nehmen wir an, Inkscape stürzt bei Ihnen ab und Sie möchten
wissen, was dabei in GLib passiert. Die GLib-Bibliothek liegt tief im
Abhängigkeitsgraphen von Inkscape und verfügt nicht über eine
debug
-Ausgabe; das erschwert die Fehlersuche. Glücklicherweise können
Sie GLib mit Informationen zur Fehlersuche neu erstellen und an Inkscape
anheften:
guix install inkscape --with-debug-info=glib
Nur GLib muss neu kompiliert werden, was in vernünftiger Zeit möglich ist. Siehe Dateien zur Fehlersuche installieren für mehr Informationen.
Anmerkung: Intern funktioniert diese Option, indem ‘#:strip-binaries? #f’ an das Erstellungssystem des betreffenden Pakets übergeben wird (siehe Erstellungssysteme). Die meisten Erstellungssysteme unterstützen diese Option, manche aber nicht. In diesem Fall wird ein Fehler gemeldet.
Auch wenn ein in C/C++ geschriebenes Paket ohne
-g
erstellt wird (was selten der Fall ist), werden Informationen zur Fehlersuche weiterhin fehlen, obwohl#:strip-binaries?
auf falsch steht.
--with-c-toolchain=Paket=Toolchain
Mit dieser Befehlszeilenoption wird die Kompilierung des Pakets und aller davon abhängigen Objekte angepasst, so dass mit der Toolchain statt der vorgegebenen GNU-Toolchain für C/C++ erstellt wird.
Betrachten Sie dieses Beispiel:
guix build octave-cli \ --with-c-toolchain=fftw=gcc-toolchain@10 \ --with-c-toolchain=fftwf=gcc-toolchain@10
Mit dem obigen Befehl wird eine Variante der Pakete fftw
und
fftwf
mit Version 10 der gcc-toolchain
anstelle der
vorgegebenen Toolchain erstellt, um damit anschließend eine diese benutzende
Variante des GNU-Octave-Befehlszeilenprogramms zu erstellen. Auch
GNU Octave selbst wird mit gcc-toolchain@10
erstellt.
Das zweite Beispiel bewirkt eine Erstellung der „Hardware
Locality“-Bibliothek (hwloc
) sowie ihrer abhängigen Objekte bis
einschließlich intel-mpi-benchmarks
mit dem Clang-C-Compiler:
guix build --with-c-toolchain=hwloc=clang-toolchain \ intel-mpi-benchmarks
Anmerkung: Es kann vorkommen, dass die Anwendungsbinärschnittstellen („Application Binary Interfaces“, kurz ABIs) der Toolchains inkompatibel sind. Das tritt vor allem bei der C++-Standardbibliothek und Bibliotheken zur Laufzeitunterstützung wie denen von OpenMP auf. Indem alle abhängigen Objekte mit derselben Toolchain erstellt werden, minimiert --with-c-toolchain das Risiko, dass es zu Inkompatibilitäten kommt, aber es kann nicht ganz ausgeschlossen werden. Bedenken Sie, für welches Paket Sie dies benutzen.
--with-git-url=Paket=URL
¶Das Paket aus dem neuesten Commit im master
-Branch des unter
der URL befindlichen Git-Repositorys erstellen. Git-Submodule des
Repositorys werden dabei rekursiv geladen.
Zum Beispiel erstellt der folgende Befehl die NumPy-Python-Bibliothek unter Verwendung des neuesten Commits von Python auf dessen „master“-Branch.
guix build python-numpy \ --with-git-url=python=https://github.com/python/cpython
Diese Befehlszeilenoption kann auch mit --with-branch oder --with-commit kombiniert werden (siehe unten).
Da es den neuesten Commit auf dem verwendeten Branch benutzt, ändert sich das Ergebnis natürlich mit der Zeit. Nichtsdestoweniger ist es eine bequeme Möglichkeit, ganze Softwarestapel auf dem neuesten Commit von einem oder mehr Paketen aufbauen zu lassen. Es ist besonders nützlich im Kontext Kontinuierlicher Integration (englisch „Continuous Integration“, kurz CI).
Checkouts bleiben zwischengespeichert als ~/.cache/guix/checkouts, damit danach schneller auf dasselbe Repository zugegriffen werden kann. Eventuell möchten Sie das Verzeichnis ab und zu bereinigen, um Plattenplatz zu sparen.
--with-branch=Paket=Branch
Das Paket aus dem neuesten Commit auf dem Branch erstellen. Wenn
das source
-Feld des Pakets ein origin-Objekt mit der Methode
git-fetch
(siehe origin
-Referenz) oder ein
git-checkout
-Objekt ist, wird die URL des Repositorys vom
source
-Feld genommen. Andernfalls müssen Sie die Befehlszeilenoption
--with-git-url benutzen, um die URL des Git-Repositorys anzugeben.
Zum Beispiel wird mit dem folgenden Befehl guile-sqlite3
aus dem
neuesten Commit seines master
-Branches erstellt und anschließend
guix
(was von guile-sqlite3
abhängt) und cuirass
(was
von guix
abhängt) unter Nutzung genau dieser
guile-sqlite3
-Erstellung erstellt:
guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=Paket=Commit
Dies verhält sich ähnlich wie --with-branch, außer dass es den
angegebenen Commit benutzt statt die Spitze eines angegebenen
Branches. Als Commit muss ein gültiger SHA1-Bezeichner, ein Tag oder
ein Bezeichner wie von git describe
(wie 1.0-3-gabc123
) für
einen Git-Commit angegeben werden.
--with-patch=Paket=Datei
Die Datei zur Liste der auf das Paket anzuwendenden Patches
hinzufügen. Als Paket muss eine Spezifikation wie python@3.8
oder glibc
benutzt werden. In der Datei muss ein Patch
enthalten sein; er wird mit den im Ursprung (origin
) des Pakets
angegebenen Befehlszeilenoptionen angewandt (siehe origin
-Referenz). Die vorgegebenen Optionen enthalten -p1
(siehe
patch Directories in Comparing and Merging Files).
Zum Beispiel wird mit dem folgenden Befehl für die Neuerstellung von Coreutils die GNU-C-Bibliothek (glibc) wie angegeben gepatcht:
guix build coreutils --with-patch=glibc=./glibc-frob.patch
In diesem Beispiel wird glibc selbst und alles, was im Abhängigkeitsgraphen auf dem Weg zu Coreutils liegt, neu erstellt.
--with-configure-flag=Paket=Befehlszeilenoption
Hängt die Befehlszeilenoption an die Befehlszeilenoptionen an, die zur
Erstellung von Paket an den Aufruf von configure übergeben
werden. Paket wird als Paketspezifikation angegeben, etwa
guile@3.0
oder glibc
. Das Erstellungssystem von Paket
muss dafür das Argument #:configure-flags
unterstützen.
Zum Beispiel können Sie mit folgendem Befehl GNU Hello mit der
configure-Option --disable-nls
erstellen:
guix build hello --with-configure-flag=hello=--disable-nls
Folgender Befehl gibt cmake
eine zusätzliche Option beim Erstellen
von lapack
mit:
guix build lapack \ --with-configure-flag=lapack=-DBUILD_SHARED_LIBS=OFF
Anmerkung: Intern funktioniert diese Option, indem das Argument ‘#:configure-flags’ 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.
--with-latest=Paket
--with-version=Paket=Version
Sie hätten gerne das Neueste vom Neuen? Dann ist die Befehlszeilenoption
--with-latest das Richtige für Sie! Damit wird jedes Vorkommen von
Paket im Abhängigkeitsgraphen durch dessen neueste angebotene Version
ersetzt, wie sie auch von guix refresh
gemeldet würde (siehe
guix refresh
aufrufen).
Dazu wird die neueste angebotene Version des Pakets ermittelt (wenn möglich), heruntergeladen und, wenn eine OpenPGP-Signatur mit dabei ist, es damit authentifiziert.
Zum Beispiel wird durch folgenden Befehl Guix mit der neuesten Version von Guile-JSON erstellt:
guix build guix --with-latest=guile-json
Die Paketumwandlungsoption --with-version funktioniert ähnlich, nur können Sie damit genau festlegen, welche Version benutzt werden soll, sofern diese Version vom Anbieter heruntergeladen werden kann. Um zum Beispiel eine Entwicklungsumgebung zur Arbeit mit SciPy, erstellt für die NumPy-Version 1.22.4, herzustellen (wobei wir den Testkatalog davon überspringen, weil wir nicht warten wollen), lautet der Befehl:
guix shell python python-scipy --with-version=python-numpy=1.22.4
Warnung: Hier wird aus dem beim Anbieter zu einer bestimmten Zeit veröffentlichten Quellcode eine Abhängigkeit. Deswegen ist mit --with-latest und --with-version bereitgestellte Software unter Umständen nicht reproduzierbar, weil der Quellcode auf Anbieter-Servern verschwindet oder für die gleiche Versionsnummer anderer Quellcode angeboten wird.
Wenn Sie alte Software-Versionen auf reproduzierbare Weise nachbilden können wollen, siehe
guix time-machine
.
Es gibt jedoch Einschränkungen. Erstens gehen Sie in dem Fall, dass das Werkzeug nicht in der Lage ist oder nicht weiß, wie es den Quellcode authentifiziert, das Risiko ein, dass bösartiger Code ausgeführt wird; Ihnen wird dann eine Warnung angezeigt. Zweitens wird mit dieser Option einfach der Quellcode ausgetauscht und die übrige Paketdefinition bleibt erhalten. Manchmal reicht das nicht; es könnte sein, dass neue Abhängigkeiten hinzugefügt oder neue Patches angewandt werden müssen oder dass ganz allgemein Arbeiten zur Qualitätssicherung, die Guix-Entwickler normalerweise leisten, fehlen werden.
Sie sind gewarnt worden! Wenn die Einschränkungen unbedenklich sind, können Sie das Paket zackig auf den neuesten Stand bringen. Wir ermutigen Sie dazu, Patches einzureichen, die die eigentliche Paketdefinition aktualisieren, sobald Sie die neue Version mit der Befehlszeilenoption --with-latest erfolgreich getestet haben (siehe Mitwirken).
--without-tests=Paket
Das Paket erstellen, ohne seine Tests zu durchlaufen. Das erweist sich als nützlich, wenn Sie Testkataloge überspringen möchten, die viel Zeit in Anspruch nehmen, oder wenn der Testkatalog eines Pakets nichtdeterministisch fehlschlägt. Dies sollte mit Bedacht eingesetzt werden, denn das Ausführen des Testkatalogs sichert zu, dass ein Paket wie gewollt funktioniert.
Wenn die Tests abgeschaltet werden, ergibt sich ein anderes Store-Objekt. Dadurch muss, wenn diese Option benutzt wird, auch alles, was vom Paket abhängt, neu erstellt werden, wie Sie in diesem Beispiel sehen können:
guix install --without-tests=python python-notebook
Mit obigem Befehl wird python-notebook
für ein python
installiert, dessen Testkatalog nicht ausgeführt wurde. Dazu wird auch alles
neu erstellt, was von python
abhängt, einschließlich
python-notebook
.
Intern funktioniert --without-tests, indem es die Option
#:tests?
der check
-Phase eines Pakets abändert (siehe
Erstellungssysteme). Beachten Sie, dass manche Pakete eine angepasste
check
-Phase benutzen, die eine Einstellung wie #:tests? #f
nicht berücksichtigt. Deshalb wirkt sich --without-tests auf diese
Pakete nicht aus.
Sie fragen sich sicher, wie Sie dieselbe Wirkung mit Scheme-Code erzielen können, zum Beispiel wenn Sie Ihr Manifest oder eine eigene Paketumwandlung schreiben? Siehe Paketvarianten definieren für eine Übersicht über verfügbare Programmierschnittstellen.
Nächste: Fehlschläge beim Erstellen untersuchen, Vorige: Paketumwandlungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]
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": "mirror://gnu/hello/hello-2.10.tar.gz", "build-system": "gnu", "arguments": { "test-target": "foo", "parallel-build?": false }, "home-page": "https://example.com/", "synopsis": "Greeter using GNU Hello", "description": "This is a wrapper around GNU Hello.", "license": "GPL-3.0+", "inputs": ["myhello", "hello"] } ]
--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).
Wie andere Arten von Ableitung kann auch das Ergebnis einer Quellcode-Ableitung mit der Befehlszeilenoption --check geprüft werden (siehe build-check). Das ist nützlich, um zu überprüfen, ob ein (vielleicht bereits erstellter oder substituierter, also zwischengespeicherter) Paketquellcode zu ihrer deklarierten Hash-Prüfsumme passt.
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 allenaarch64-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 Nutzung der Auslagerungsfunktionalität 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).
--list-systems
Listet alle unterstützten Systeme auf, die als Argument an --system gegeben werden können.
--list-targets
Listet alle unterstützten Ziele auf, die als Argument an --target gegeben werden können.
--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 guix challenge
aufrufen 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
guix gc
aufrufen 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)'
If a log is unavailable locally, and unless --no-substitutes is passed, the command looks for a corresponding log on one of the substitute servers.
Stellen Sie sich zum Beispiel vor, sie wollten das Erstellungsprotokoll von
GDB auf einem aarch64
-System sehen, benutzen aber selbst eine
x86_64
-Maschine:
$ guix build --log-file gdb -s aarch64-linux https://bordeaux.guix.gnu.org/log/…-gdb-7.10
So haben Sie umsonst Zugriff auf eine riesige Bibliothek von Erstellungsprotokollen!
Vorige: Zusätzliche Erstellungsoptionen, Nach oben: Aufruf von guix build
[Inhalt][Index]
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 shell --no-grafts -C -D foo strace gdb [env]# source ./environment-variables [env]# cd foo-1.2
Hierbei erzeugt guix shell -C
eine isolierte Umgebung und öffnet
darin eine Shell (siehe guix shell
aufrufen). Der Teil mit
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 shell
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: guix download
aufrufen, Vorige: Aufruf von guix build
, Nach oben: Zubehör [Inhalt][Index]
guix edit
aufrufenSo 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: guix hash
aufrufen, Vorige: guix edit
aufrufen, Nach oben: Zubehör [Inhalt][Index]
guix download
aufrufenWenn 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 guix gc
aufrufen).
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 die
Installationsanleitung der GnuTLS-Anbindungen für
Guile in GnuTLS-Guile für 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.
Alternativ können Sie guix download
auch benutzen, um ein
Git-Repository herunterzuladen, insbesondere auch einen bestimmten Commit,
Tag oder Branch.
Folgende Befehlszeilenoptionen stehen zur Verfügung:
--hash=Algorithmus
-H Algorithmus
Einen Hash mit dem angegebenen Algorithmus berechnen. Siehe
guix hash
aufrufen 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
guix hash
aufrufen.
--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.
--git
-g
Ein Checkout des neuesten Commits des angegebenen Git-Repositorys für dessen Standard-Branch herunterladen.
--commit=Commit-oder-Tag
Das Checkout des Git-Repositorys bei Commit-oder-Tag herunterladen.
Für Commit-oder-Tag können Sie entweder einen Git-Tag oder einen Commit angeben, der im Git-Repository definiert ist.
--branch=Branch
Das Checkout des Git-Repositorys für Branch herunterladen.
Vom Repository wird ein Checkout des neuesten Commits auf Branch heruntergeladen. Der Name des Branchs muss für das Git-Repository gültig sein.
--recursive
-r
Das Git-Repository rekursiv klonen.
Nächste: guix import
aufrufen, Vorige: guix download
aufrufen, Nach oben: Zubehör [Inhalt][Index]
guix hash
aufrufenDer 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 Befehlszeilenoption --recursive ist veraltet. Benutzen Sie --serializer=nar (siehe unten). -r bleibt als bequeme Kurzschreibweise erhalten.
--serializer=Typ
-S Typ
Die Prüfsumme der Datei auf die durch Typ angegebene Art berechnen.
Als Typ können Sie einen hiervon benutzen:
none
Dies entspricht der Vorgabe: Die Prüfsumme des Inhalts der Datei wird berechnet.
nar
In diesem Fall wird die Prüfsumme eines Normalisierten Archivs (kurz „Nar“)
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 guix archive
aufrufen, für mehr
Informationen über das Nar-Format).
git
Die Prüfsumme der Datei oder des Verzeichnisses als Git-Baumstruktur berechnen, nach derselben Methode wie beim Git-Versionskontrollsystem.
--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 -x --serializer=nar .
Nächste: guix refresh
aufrufen, Vorige: guix hash
aufrufen, Nach oben: Zubehör [Inhalt][Index]
guix import
aufrufenDer 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 [Globale-Optionen…] Importer Paket [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. guix import
verfügt selbst über
folgende Globale-Optionen:
--insert=Datei
-i Datei
Die vom Importer erzeugten Paketdefinitionen in die angegebene Datei schreiben, entweder in alphabetischer Reihenfolge unter bestehenden Paketdefinitionen oder andernfalls am Dateiende.
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 die neueste Version des
Python-Pakets namens itsdangerous
:
guix import pypi itsdangerous
Sie können auch um eine bestimmte Version bitten:
guix import pypi itsdangerous@1.1.0
--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
Sie können auch um eine bestimmte Version bitten:
guix import gem rails@7.0.4
--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.
minetest
¶Importiert Metadaten aus der ContentDB. Informationen werden aus den JSON-formatierten Metadaten genommen, die über die Programmierschnittstelle („API“) von ContentDB angeboten werden, und enthalten die relevantesten Informationen wie zum Beispiel Abhängigkeiten. Allerdings passt das Ergebnis nicht ganz. Lizenzinformationen sind oft unvollständig. Der Commit-Hash fehlt manchmal. Die importierten Beschreibungen sind in Markdown formatiert, aber Guix braucht stattdessen Texinfo-Auszeichnungen. Texturpakete und Teilspiele werden nicht unterstützt.
Der folgende Befehl importiert Metadaten für die Mesecons-Mod von Jeija:
guix import minetest Jeija/mesecons
Man muss den Autorennamen nicht angeben:
guix import minetest mesecons
--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
Sie können auch um eine bestimmte Version bitten:
guix import cran rasterVis@0.50.3
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 --style=specification angegeben, wird der Importer Paketdefinitionen erzeugen, deren Eingaben als Paketspezifikationen statt als Referenzen auf Paketvariable vorliegen. Das ist nützlich, wenn die erzeugten Paketdefinitionen in bestehende, nutzereigene Module eingefügt werden, weil dann die Liste der benutzten Paketmodule nicht angepasst werden muss. Die Vorgabe ist --style=variable.
Wird --prefix=license: angegeben, stellt der Importer jedem für
eine Lizenz stehenden Atom das Präfix license:
voran, damit
(guix licenses)
mit diesem Präfix importiert werden kann.
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
¶Informationen über TeX-Pakete, die Teil der TeX-Live-Distribution sind, aus der Datenbank von TeX Live importieren.
Paketinformationen werden der Paketdatenbank von TeX Live entnommen. Bei ihr
handelt es sich um eine reine Textdatei, die im texlive-scripts
-Paket
enthalten ist. Der Quellcode wird von unter Umständen mehreren Stellen im
SVN-Repository des TeX-Live-Projekts heruntergeladen. Beachten Sie, dass
deswegen SVN installiert und in $PATH
zu finden sein muss; führen Sie
dazu gegebenenfalls guix install subversion
aus.
Der folgende Befehl importiert Metadaten für das TeX-Paket fontspec
:
guix import texlive fontspec
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.
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
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
. 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).
nongnu
.
melpa-stable
.
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 crates.io importieren, 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.
--recursive-dev-dependencies
Wenn Sie --recursive-dev-dependencies angeben, werden zudem auch die „dev-dependencies“ (Development Dependencies) von rekursiv importierten Paketen benutzt und importiert.
--allow-yanked
Wenn es keine nicht zurückgenommene („yanked“) Version einer Crate gibt, wird die neueste zurückgenommene benutzt statt abzubrechen.
elm
¶Metadaten aus der Paketsammlung package.elm-lang.org für Elm importieren, wie Sie in diesem Beispiel sehen:
guix import elm elm-explorations/webgl
Mit dem Elm-Importer können Sie auch eine Version als Zeichenkette angeben:
guix import elm elm-explorations/webgl@1.1.3
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.
npm-binary
¶Import metadata from the npm Registry, as in this example:
guix import npm-binary buffer-crc32
The npm-binary importer also allows you to specify a version string:
guix import npm-binary buffer-crc32@1.0.0
Anmerkung: Generated package expressions skip the build step of the
node-build-system
. As such, generated package expressions often refer to transpiled or generated files, instead of being built from source.
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.
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.
composer
¶Metadaten aus dem Paketarchiv Composer, das die PHP-Gemeinschaft verwendet, importieren.
guix import composer phpunit/phpunit
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.
--repo
Vorgegeben ist, nach Paketen im offiziellen OPAM-Repository zu suchen. Mit dieser Befehlszeilenoption, die mehr als einmal angegeben werden kann, können Sie andere Repositorys hinzufügen, in denen nach Paketen gesucht wird. Als gültige Argumente akzeptiert werden:
opam
,
coq
(äquivalent zu coq-released
), coq-core-dev
,
coq-extra-dev
oder grew
.
opam repository add
erfordert (zum Beispiel wäre
https://opam.ocaml.org die URL, die dem Namen opam
oben
entspricht).
Die an diese Befehlszeilenoption übergebenen Repositorys sind in der
Reihenfolge Ihrer Präferenz anzugeben. Die zusätzlich angegebenen
Repositorys ersetzen nicht das voreingestellte Repository
opam
; es bleibt immer als letzte Möglichkeit stehen.
Beachten Sie ebenso, dass Versionsnummern mehrerer Repositorys nicht verglichen werden, sondern einfach das Paket aus dem ersten Repository (von links nach rechts), das mindestens eine Version des angeforderten Pakets enthält, genommen wird und die importierte Version der neuesten aus nur diesem Repository entspricht.
go
¶Metadaten für ein Go-Modul von proxy.golang.org importieren.
guix import go gopkg.in/yaml.v2
Es ist möglich, bei der Paketspezifikation ein Suffix @VERSION
anzugeben, um diese bestimmte Version zu importieren.
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.
--pin-versions
Wenn Sie diese Option verwenden, behält der Importer genau diese Version der Go-Modul-Abhängigkeiten bei, statt die neuesten verfügbaren Versionen zu benutzen. Das kann hilfreich sein, wenn Sie versuchen, Pakete zu importieren, die für deren Erstellung rekursiv von alten Versionen ihrer selbst abhängen. Wenn Sie diesen Modus nutzen, wird das Symbol für das Paket durch Anhängen der Versionsnummer an seinen Namen gebildet, damit mehrere Versionen desselben Pakets gleichzeitig existieren können.
egg
¶Metadaten für CHICKEN-Eggs
importieren. Die Informationen werden aus den PAKET.egg-Dateien
genommen, die im Git-Repository eggs-5-all stehen. Jedoch gibt es dort nicht alle Informationen, die wir
brauchen: Ein Feld für die Beschreibung (description
) fehlt und die
benutzten Lizenzen sind ungenau (oft wird BSD angegeben statt BSD-N).
guix import egg sourcehut
Sie können auch um eine bestimmte Version bitten:
guix import egg arrays@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.
hexpm
¶Metadaten aus der Paketsammlung hex.pm für Erlang und Elixir hex.pm importieren, wie Sie in diesem Beispiel sehen:
guix import hexpm stun
Der Importer versucht, das richtige Erstellungssystem für das Paket zu erkennen.
Mit dem hexpm-Importer können Sie auch eine Version als Zeichenkette angeben:
guix import hexpm cf@0.3.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.
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: guix style
aufrufen, Vorige: guix import
aufrufen, Nach oben: Zubehör [Inhalt][Index]
guix refresh
aufrufenDie Zielgruppe des Befehls guix refresh
zum Auffrischen von
Paketen sind in erster Linie Paketautoren. Als Nutzer könnten Sie an der
Befehlszeilenoption --with-latest Interesse haben, die auf
guix refresh
aufbaut, um Ihnen Superkräfte bei der
Paketaktualisierung zu verleihen (siehe --with-latest). Nach Vorgabe werden mit guix refresh
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:40:13: acl würde von 2.2.53 auf 2.3.1 aktualisiert gnu/packages/m4.scm:30:12: 1.4.18 ist bereits die neuste Version von m4 gnu/packages/xml.scm:68:2: Warnung: Kein Aktualisierungsprogramm für expat gnu/packages/multiprecision.scm:40:12: 6.1.2 ist bereits die neuste Version von gmp …
Wenn Sie aus irgendeinem Grund auf eine ältere Version aktualisieren möchten, geht das auch, indem Sie nach der Paketspezifikation ein Gleichheitszeichen und die gewünschte Versionsnummer schreiben. Allerdings können nicht alle Aktualisierungsprogramme damit umgehen; wenn es das Aktualisieren auf die bestimmte Version nicht unterstützt, meldet das Aktualisierungsprogramm einen Fehler.
$ guix refresh trytond-party gnu/packages/guile.scm:392:2: guile würde von 3.0.3 auf 3.0.5 aktualisiert $ guix refresh -u guile=3.0.4 … gnu/packages/guile.scm:392:2: guile: Aktualisiere von Version 3.0.3 auf Version 3.0.4 … … $ guix refresh -u guile@2.0=2.0.12 … gnu/packages/guile.scm:147:2: guile: Aktualisiere von Version 2.0.10 auf Version 2.0.12 … …
In bestimmten Fällen möchte man viele Pakete, die man über ein Manifest oder eine Modulauswahl angibt, alle zusammen aktualisieren. Für so etwas gibt es die Befehlszeilenoption --target-version, mit der alle auf die gleiche Version gebracht werden können, wie in diesen Beispielen hier:
$ guix refresh qtbase qtdeclarative --target-version=6.5.2 gnu/packages/qt.scm:1248:13: qtdeclarative würde von 6.3.2 auf 6.5.2 aktualisiert gnu/packages/qt.scm:584:2: qtbase würde von 6.3.2 auf 6.5.2 aktualisiert
$ guix refresh --manifest=qt5-manifest.scm --target-version=5.15.10 gnu/packages/qt.scm:1173:13: qtxmlpatterns würde von 5.15.8 auf 5.15.10 aktualisiert gnu/packages/qt.scm:1202:13: qtdeclarative würde von 5.15.8 auf 5.15.10 aktualisiert gnu/packages/qt.scm:1762:13: qtserialbus würde von 5.15.8 auf 5.15.10 aktualisiert gnu/packages/qt.scm:2070:13: qtquickcontrols2 würde von 5.15.8 auf 5.15.10 aktualisiert …
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 Paketdefinitionen und, wenn
möglich, für deren Eingaben die aktuelle Version und die aktuelle
Hash-Prüfsumme des Quellcodes 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 Paketdefinitionen) 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. Sie können es auch auf Paketen eines Drittanbieterkanals ausführen.
guix refresh -L /pfad/zum/kanal -u Paket
Siehe Einen Kanal erstellen für Informationen, wie Sie einen Kanal anlegen.
Mit diesem Befehl bringen Sie die Version und die Hash-Prüfsumme des Quellcodes in dem Paket auf den neuesten Stand. Je nachdem, welches Aktualisierungsprogramm dafür eingesetzt wird, kann es sogar die Eingaben im Feld ‘inputs’ des Pakets aktualisieren. Es kommt vor, dass sich dabei Fehler in die Eingaben einschleichen – vielleicht fehlt eine zusätzliche notwendige Eingabe oder es wird eine hinzugefügt, die nicht erwünscht ist.
Um damit leichter umzugehen, können Paketautoren die Eingaben, die außer den
vom Aktualisierungsprogramm gefundenen Eingaben in Guix noch zusätzlich
nötig sind, oder solche, die ignoriert werden sollen, in den Eigenschaften
des Pakets hinterlegen: Es gibt die Eigenschaften
updater-extra-inputs
und updater-ignored-inputs
, wenn es um
„normale“ Abhängigkeiten geht, und entsprechende Eigenschaften für
native-inputs
und propagated-inputs
. Folgendes Beispiel zeigt,
wie das Aktualisierungsprogramm auf ‘openmpi’ als eine zusätzliche
Eingabe hingewiesen wird:
(define-public python-mpi4py
(package
(name "python-mpi4py")
;; …
(inputs (list openmpi))
(properties
'((updater-extra-inputs . ("openmpi"))))))
So wird bei guix refresh -u python-mpi4py
die Eingabe
‘openmpi’ nicht mehr entfernt, obwohl es keine der Eingaben ist, die
von sich aus hinzugefügt würden.
--select=[Teilmenge]
-s Teilmenge
Wählt alle Pakete aus der Teilmenge aus, die entweder core
,
non-core
oder module:Name
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.
Wenn als Teilmenge module:Name
angegeben wird, werden alle
Pakete in dem angegebenen Guile-Modul ausgewählt. Das Modul kann als z.B.
module:guile
oder module:(gnu packages guile)
angegeben
werden, erstere ist die Kurzform für die andere.
--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,
sourceforge
Aktualisierungsprogramm auf SourceForge angebotener Pakete,
gnome
Aktualisierungsprogramm für GNOME-Pakete,
kde
Aktualisierungsprogramm für KDE-Pakete,
xorg