1 files changed, 0 insertions, 26536 deletions
diff --git a/doc/guix.de.texi b/doc/guix.de.texi
deleted file mode 100644
index 419d40379e6..00000000000
--- a/doc/guix.de.texi
+++ /dev/null
@@ -1,26536 +0,0 @@
-\input texinfo
-@c ===========================================================================
-@c
-@c This file was generated with po4a. Translate the source file.
-@c
-@c ===========================================================================
-@c -*-texinfo-*-
-@c %**start of header
-@setfilename guix.de.info
-@documentencoding UTF-8
-@documentlanguage de
-@frenchspacing on
-@settitle Referenzhandbuch zu GNU Guix
-@c %**end of header
-@include version-de.texi
-@c Identifier of the OpenPGP key used to sign tarballs and such.
-@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
-@set KEY-SERVER pool.sks-keyservers.net
-@c The official substitute server used by default.
-@set SUBSTITUTE-SERVER ci.guix.de.info
-@copying
-Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019
-Ludovic Courtès@* Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@*
-Copyright @copyright{} 2013 Nikita Karetnikov@* Copyright @copyright{} 2014,
-2015, 2016 Alex Kost@* Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
-Copyright @copyright{} 2014 Pierre-Antoine Rault@* Copyright @copyright{}
-2015 Taylan Ulrich Bayırlı/Kammer@* Copyright @copyright{} 2015, 2016, 2017
-Leo Famulari@* Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo
-Wurmus@* Copyright @copyright{} 2016 Ben Woodcroft@* Copyright @copyright{}
-2016, 2017, 2018 Chris Marusich@* Copyright @copyright{} 2016, 2017, 2018,
-2019 Efraim Flashner@* Copyright @copyright{} 2016 John Darrington@*
-Copyright @copyright{} 2016, 2017 ng0@* Copyright @copyright{} 2016, 2017,
-2018, 2019 Jan Nieuwenhuizen@* Copyright @copyright{} 2016 Julien Lepiller@*
-Copyright @copyright{} 2016 Alex ter Weele@* Copyright @copyright{} 2016,
-2017, 2018, 2019 Christopher Baines@* Copyright @copyright{} 2017, 2018
-Clément Lassieur@* Copyright @copyright{} 2017, 2018 Mathieu Othacehe@*
-Copyright @copyright{} 2017 Federico Beffa@* Copyright @copyright{} 2017,
-2018 Carlo Zancanaro@* Copyright @copyright{} 2017 Thomas Danckaert@*
-Copyright @copyright{} 2017 humanitiesNerd@* Copyright @copyright{} 2017
-Christopher Allan Webber@* Copyright @copyright{} 2017, 2018 Marius Bakke@*
-Copyright @copyright{} 2017 Hartmut Goebel@* Copyright @copyright{} 2017
-Maxim Cournoyer@* Copyright @copyright{} 2017, 2018 Tobias Geerinckx-Rice@*
-Copyright @copyright{} 2017 George Clemmer@* Copyright @copyright{} 2017
-Andy Wingo@* Copyright @copyright{} 2017, 2018, 2019 Arun Isaac@* Copyright
-@copyright{} 2017 nee@* Copyright @copyright{} 2018 Rutger Helling@*
-Copyright @copyright{} 2018 Oleg Pykhalov@* Copyright @copyright{} 2018 Mike
-Gerwitz@* Copyright @copyright{} 2018 Pierre-Antoine Rouby@* Copyright
-@copyright{} 2018 Gábor Boskovits@* Copyright @copyright{} 2018 Florian
-Pelz@* Copyright @copyright{} 2018 Laura Lazzati@* Copyright @copyright{}
-2018 Alex Vong@*
-Es ist Ihnen gestattet, dieses Dokument zu vervielfältigen, weiterzugeben
-und/oder zu verändern, unter den Bedingungen der GNU Free Documentation
-License, entweder gemäß Version 1.3 der Lizenz oder (nach Ihrer Option)
-einer späteren Version, die von der Free Software Foundation veröffentlicht
-wurde, ohne unveränderliche Abschnitte, ohne vorderen Umschlagtext und ohne
-hinteren Umschlagtext. Eine Kopie der Lizenz finden Sie im Abschnitt mit dem
-Titel »GNU Free Documentation License«.
-@end copying
-@dircategory Systemadministration
-@direntry
-* Guix: (guix.de).           Installierte Software und Systemkonfigurationen 
-                               verwalten.
-* guix package: (guix.de)guix package aufrufen.  Pakete installieren, 
-                                                   entfernen und 
-                                                   aktualisieren.
-* guix gc: (guix.de)guix gc aufrufen.  Unbenutzten Plattenspeicher wieder 
-                                         freigeben.
-* guix pull: (guix.de)guix pull aufrufen.  Die Liste verfügbarer Pakete 
-                                             aktualisieren.
-* guix system: (guix.de)guix system aufrufen.  Die 
-                                                 Betriebssystemkonfiguration 
-                                                 verwalten.
-@end direntry
-@dircategory Softwareentwicklung
-@direntry
-* guix environment: (guix.de)guix environment aufrufen.  Umgebungen für 
-                                                           Entwickler 
-                                                           erstellen
-* guix build: (guix.de)guix build aufrufen.  Erstellen von Paketen.
-* guix pack: (guix.de)guix pack aufrufen.  Bündel aus Binärdateien 
-                                             erstellen.
-@end direntry
-@titlepage
-@title Referenzhandbuch zu GNU Guix
-@subtitle Den funktionalen Paketmanager GNU Guix benutzen
-@author Die GNU-Guix-Entwickler
-@page
-@vskip 0pt plus 1filll
-Edition @value{EDITION} @* @value{UPDATED} @*
-@insertcopying
-@end titlepage
-@contents
-@c *********************************************************************
-@node Top
-@top GNU Guix
-Dieses Dokument beschreibt GNU Guix, Version @value{VERSION}, ein Werkzeug
-zur funktionalen Verwaltung von Softwarepaketen, das für das GNU-System
-geschrieben wurde.
-@c TRANSLATORS: You can replace the following paragraph with information on
-@c how to join your own translation team and how to report issues with the
-@c translation.
-Dieses Handbuch ist auch auf Englisch (siehe @ref{Top,,, guix, GNU Guix
-Reference Manual}) und Französisch verfügbar (siehe @ref{Top,,, guix.fr,
-Manuel de référence de GNU Guix}). Wenn Sie es in Ihre eigene Sprache
-übersetzen möchten, dann sind Sie beim
-@uref{https://translationproject.org/domain/guix-manual.html, Translation
-Project} herzlich willkommen.
-@menu
-* Einführung::              Was ist Guix überhaupt?
-* Installation::             Guix installieren.
-* Systeminstallation::       Das ganze Betriebssystem installieren.
-* Paketverwaltung::          Pakete installieren, aktualisieren usw.
-* Entwicklung::              Von Guix unterstützte Softwareentwicklung.
-* Programmierschnittstelle::  Guix in Scheme verwenden.
-* Zubehör::                 Befehle zur Paketverwaltung.
-* Systemkonfiguration::      Das Betriebssystem konfigurieren.
-* Dokumentation::            Wie man Nutzerhandbücher von Software liest.
-* Dateien zur Fehlersuche installieren::  Womit man seinen Debugger 
-                                            füttert.
-* Sicherheitsaktualisierungen::  Sicherheits-Patches schnell einspielen.
-* Bootstrapping::            GNU/Linux von Grund auf selbst erstellen.
-* Portierung::               Guix auf andere Plattformen und Kernels 
-                               bringen.
-* Mitwirken::                Ihre Hilfe ist nötig!
-* Danksagungen::             Danke!
-* GNU-Lizenz für freie Dokumentation::  Die Lizenz dieses Handbuchs.
-* Konzeptverzeichnis::       Konzepte.
-* Programmierverzeichnis::   Datentypen, Funktionen und Variable.
-@detailmenu
- --- Detaillierte Liste der Knoten ---
-Einführung
-* Auf Guix-Art Software verwalten::  Was Guix besonders macht.
-* GNU-Distribution::         Die Pakete und Werkzeuge.
-Installation
-* Aus Binärdatei installieren::  Guix installieren, ohne Zeit zu verlieren!
-* Voraussetzungen::          Zum Erstellen und Benutzen von Guix nötige 
-                               Software.
-* Den Testkatalog laufen lassen::  Guix testen.
-* Den Daemon einrichten::    Wie man die Umgebung des Erstellungs-Daemons 
-                               einrichtet.
-* Aufruf des guix-daemon::   Den Erstellungs-Daemon laufen lassen.
-* Anwendungen einrichten::   Anwendungsspezifische Einstellungen.
-Den Daemon einrichten
-* Einrichten der Erstellungsumgebung::  Die isolierte Umgebung zum Erstellen 
-                                          vorbereiten.
-* Auslagern des Daemons einrichten::  Erstellungen auf entfernte Maschinen 
-                                        auslagern.
-* SELinux-Unterstützung::   Wie man eine SELinux-Richtlinie für den Daemon 
-                               einrichtet.
-Systeminstallation
-* Einschränkungen::         Was Sie erwarten dürfen.
-* Hardware-Überlegungen::   Unterstützte Hardware.
-* Installation von USB-Stick oder DVD::  Das Installationsmedium 
-                                           vorbereiten.
-* Vor der Installation::     Netzwerkanbindung, Partitionierung etc.
-* Geführte grafische Installation::  Leichte grafische Installation.
-* Manuelle Installation::    Manuelle Installation für Zauberer.
-* Nach der Systeminstallation::  Wenn die Installation erfolgreich war.
-* Guix in einer VM installieren::  Ein »Guix System«-Spielplatz.
-* Ein Abbild zur Installation erstellen::  Wie ein solches entsteht.
-Manuelle Installation
-* Tastaturbelegung und Netzwerkanbindung und Partitionierung::  Erstes 
-                                                                  Einrichten.
-* Fortfahren mit der Installation::  Installieren.
-Paketverwaltung
-* Funktionalitäten::        Wie Guix Ihr Leben schöner machen wird.
-* Aufruf von guix package::  Pakete installieren, entfernen usw.
-* Substitute::               Vorerstelle Binärdateien herunterladen.
-* Pakete mit mehreren Ausgaben.::  Ein Quellpaket, mehrere Ausgaben.
-* Aufruf von guix gc::       Den Müllsammler laufen lassen.
-* Aufruf von guix pull::     Das neueste Guix samt Distribution laden.
-* Kanäle::                  Die Paketsammlung anpassen.
-* Untergeordnete::           Mit einer anderen Version von Guix 
-                               interagieren.
-* Aufruf von guix describe::  Informationen über Ihre Guix-Version 
-                                anzeigen.
-* Aufruf von guix archive::  Import und Export von Store-Dateien.
-Substitute
-* Offizieller Substitut-Server::  Eine besondere Quelle von Substituten.
-* Substitut-Server autorisieren::  Wie man Substitute an- und abschaltet.
-* Substitutauthentifizierung::  Wie Guix Substitute verifiziert.
-* Proxy-Einstellungen::      Wie Sie Substitute über einen Proxy beziehen.
-* Fehler bei der Substitution::  Was passiert, wenn die Substitution 
-                                   fehlschlägt.
-* Vom Vertrauen gegenüber Binärdateien::  Wie können Sie diesem binären 
-                                              Blob trauen?
-Entwicklung
-* Aufruf von guix environment::  Entwicklungsumgebungen einrichten.
-* Aufruf von guix pack::     Software-Bündel erstellen.
-Programmierschnittstelle
-* Paketmodule::              Pakete aus Sicht des Programmierers.
-* Pakete definieren::        Wie Sie neue Pakete definieren.
-* Erstellungssysteme::       Angeben, wie Pakete erstellt werden.
-* Der Store::                Den Paket-Store verändern.
-* Ableitungen::              Systemnahe Schnittstelle für Paketableitungen.
-* Die Store-Monade::         Rein funktionale Schnittstelle zum Store.
-* G-Ausdrücke::             Erstellungsausdrücke verarbeiten.
-* Aufruf von guix repl::     Interaktiv an Guix herumbasteln.
-Pakete definieren
-* »package«-Referenz::     Der Datentyp für Pakete.
-* »origin«-Referenz::      Datentyp für Paketursprünge.
-Zubehör
-* Aufruf von guix build::    Pakete aus der Befehlszeile heraus erstellen.
-* Aufruf von guix edit::     Paketdefinitionen bearbeiten.
-* Aufruf von guix download::  Herunterladen einer Datei und Ausgabe ihres 
-                                Hashes.
-* Aufruf von guix hash::     Den kryptografischen Hash einer Datei 
-                               berechnen.
-* Aufruf von guix import::   Paketdefinitionen importieren.
-* Aufruf von guix refresh::  Paketdefinitionen aktualisieren.
-* Aufruf von guix lint::     Fehler in Paketdefinitionen finden.
-* Aufruf von guix size::     Plattenplatzverbrauch profilieren.
-* Aufruf von guix graph::    Den Paketgraphen visualisieren.
-* Aufruf von guix publish::  Substitute teilen.
-* Aufruf von guix challenge::  Die Substitut-Server anfechten.
-* Aufruf von guix copy::     Mit einem entfernten Store Dateien austauschen.
-* Aufruf von guix container::  Prozesse isolieren.
-* Aufruf von guix weather::  Die Verfügbarkeit von Substituten 
-                               einschätzen.
-* Aufruf von guix processes::  Auflisten der Client-Prozesse
-Aufruf von @command{guix build}
-* Gemeinsame Erstellungsoptionen::  Erstellungsoptionen für die meisten 
-                                      Befehle.
-* Paketumwandlungsoptionen::  Varianten von Paketen erzeugen.
-* Zusätzliche Erstellungsoptionen::  Optionen spezifisch für »guix 
-                                        build«.
-* Fehlschläge beim Erstellen untersuchen::  Praxiserfahrung bei der 
-                                               Paketerstellung.
-Systemkonfiguration
-* Das Konfigurationssystem nutzen::  Ihr GNU-System anpassen.
-* »operating-system«-Referenz::  Details der Betriebssystem-Deklarationen.
-* Dateisysteme::             Die Dateisystemeinbindungen konfigurieren.
-* Zugeordnete Geräte::      Näheres zu blockorientierten Speichermedien.
-* Benutzerkonten::           Benutzerkonten festlegen.
-* Tastaturbelegung::         Wie das System Tastendrücke interpretiert.
-* Locales::                  Sprache und kulturelle Konventionen.
-* Dienste::                  Systemdienste festlegen.
-* Setuid-Programme::         Mit Administratorrechten startende Programme.
-* X.509-Zertifikate::        HTTPS-Server authentifizieren.
-* Name Service Switch::      Den Name Service Switch von libc konfigurieren.
-* Initiale RAM-Disk::        Linux-libre hochfahren.
-* Bootloader-Konfiguration::  Den Bootloader konfigurieren.
-* Aufruf von guix system::   Instanziierung einer Systemkonfiguration.
-* Guix in einer VM starten::  Wie man »Guix System« in einer virtuellen 
-                                Maschine startet.
-* Dienste definieren::       Neue Dienstdefinitionen hinzufügen.
-Dienste
-* Basisdienste::             Essenzielle Systemdienste.
-* Geplante Auftragsausführung::  Der mcron-Dienst.
-* Log-Rotation::             Der rottlog-Dienst.
-* Netzwerkdienste::          Netzwerkeinrichtung, SSH-Daemon etc.
-* X Window::                 Grafische Anzeige.
-* Druckdienste::             Unterstützung für lokale und entfernte 
-                               Drucker.
-* Desktop-Dienste::          D-Bus- und Desktop-Dienste.
-* Tondienste::               Dienste für ALSA und Pulseaudio.
-* Datenbankdienste::         SQL-Datenbanken, Schlüssel-Wert-Speicher etc.
-* Mail-Dienste::             IMAP, POP3, SMTP und so weiter.
-* Kurznachrichtendienste::   Dienste für Kurznachrichten.
-* Telefondienste::           Telefoniedienste.
-* Überwachungsdienste::     Dienste zur Systemüberwachung.
-* Kerberos-Dienste::         Kerberos-Dienste.
-* Web-Dienste::              Web-Server.
-* Zertifikatsdienste::       TLS-Zertifikate via Let’s Encrypt.
-* DNS-Dienste::              DNS-Daemons.
-* VPN-Dienste::              VPN-Daemons.
-* Network File System::      Dienste mit Bezug zum Netzwerkdateisystem.
-* Kontinuierliche Integration::  Der Cuirass-Dienst.
-* Dienste zur Stromverbrauchsverwaltung::  Den Akku schonen.
-* Audio-Dienste::            Der MPD.
-* Virtualisierungsdienste::  Dienste für virtuelle Maschinen.
-* Versionskontrolldienste::  Entfernten Zugang zu Git-Repositorys bieten.
-* Spieldienste::             Spielserver.
-* Verschiedene Dienste::     Andere Dienste.
-Dienste definieren
-* Dienstkompositionen::      Wie Dienste zusammengestellt werden.
-* Diensttypen und Dienste::  Typen und Dienste.
-* Service-Referenz::         Referenz zur Programmierschnittstelle.
-* Shepherd-Dienste::         Eine spezielle Art von Dienst.
-@end detailmenu
-@end menu
-@c *********************************************************************
-@node Einführung
-@chapter Einführung
-@cindex Zweck
-GNU Guix@footnote{»Guix« wird wie »geeks« ausgesprochen, also als »ɡiːks« in
-der Notation des Internationalen Phonetischen Alphabets (IPA).} ist ein
-Werkzeug zur Verwaltung von Softwarepaketen für das GNU-System und eine
-Distribution desselbigen GNU-Systems. Guix macht es @emph{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.
-@cindex Guix System
-@cindex GuixSD, was jetzt Guix System heißt
-@cindex Guix System Distribution, welche jetzt Guix System heißt
-Sie können GNU@tie{}Guix auf ein bestehendes GNU/Linux-System aufsetzen, wo
-es die bereits verfügbaren Werkzeuge ergänzt, ohne zu stören (siehe
-@ref{Installation}), oder Sie können es als eine eigenständige
-Betriebssystem-Distribution namens @dfn{Guix@tie{}System}
-verwenden@footnote{Der Name @dfn{Guix@tie{}System} wird auf englische Weise
-ausgesprochen. Früher hatten wir »Guix System« als »Guix System
-Distribution« bezeichnet und mit »GuixSD« abgekürzt. Wir denken mittlerweile
-aber, dass es sinnvoller ist, alles unter der Fahne von Guix zu gruppieren,
-weil schließlich »Guix System« auch über den Befehl @command{guix system}
-verfügbar ist, selbst wenn Sie Guix auf einer fremden Distribution
-benutzen!}. Siehe @ref{GNU-Distribution}.
-@menu
-* Auf Guix-Art Software verwalten::  Was Guix besonders macht.
-* GNU-Distribution::         Die Pakete und Werkzeuge.
-@end menu
-@node Auf Guix-Art Software verwalten
-@section Auf Guix-Art Software verwalten
-@cindex Benutzeroberflächen
-Guix bietet eine befehlszeilenbasierte Paketverwaltungsschnittstelle (siehe
-@ref{Aufruf von guix package}), Werkzeuge als Hilfestellung bei der
-Software-Entwicklung (siehe @ref{Entwicklung}), Befehlszeilenwerkzeuge für
-fortgeschrittenere Nutzung (siehe @ref{Zubehör}) sowie Schnittstellen zur
-Programmierung in Scheme (siehe @ref{Programmierschnittstelle}).
-@cindex Erstellungs-Daemon
-Der @dfn{Erstellungs-Daemon} ist für das Erstellen von Paketen im Auftrag
-von Nutzern verantwortlich (siehe @ref{Den Daemon einrichten}) und für das
-Herunterladen vorerstellter Binärdateien aus autorisierten Quellen (siehe
-@ref{Substitute}).
-@cindex Erweiterbarkeit der Distribution
-@cindex Anpassung, von Paketen
-Guix enthält Paketdefinitionen für viele Pakete, von GNU und nicht von GNU,
-die alle @uref{https://www.gnu.org/philosophy/free-sw.html, die Freiheit des
-Computernutzers respektieren}. Es ist @emph{erweiterbar}: Nutzer können ihre
-eigenen Paketdefinitionen schreiben (siehe @ref{Pakete definieren}) und sie
-als unabhängige Paketmodule verfügbar machen (siehe @ref{Paketmodule}). Es ist auch @emph{anpassbar}: Nutzer können spezialisierte
-Paketdefinitionen aus bestehenden @emph{ableiten}, auch von der Befehlszeile
-(siehe @ref{Paketumwandlungsoptionen}).
-@cindex funktionale Paketverwaltung
-@cindex Isolierung
-Intern implementiert Guix die Disziplin der @dfn{funktionalen
-Paketverwaltung}, zu der Nix schon die Pionierarbeit geleistet hat (siehe
-@ref{Danksagungen}). In Guix wird der Prozess, ein Paket zu erstellen und
-zu installieren, als eine @emph{Funktion} im mathematischen Sinn
-aufgefasst. Diese Funktion hat Eingaben, wie zum Beispiel
-Erstellungs-Skripts, einen Compiler und Bibliotheken, und liefert ein
-installiertes Paket. Als eine reine Funktion hängt sein Ergebnis allein von
-seinen Eingaben ab — zum Beispiel kann er nicht auf Software oder Skripts
-Bezug nehmen, die nicht ausdrücklich als Eingaben übergeben wurden. Eine
-Erstellungsfunktion führt immer zum selben Ergebnis, wenn ihr die gleiche
-Menge an Eingaben übergeben wurde. Sie kann die Umgebung des laufenden
-Systems auf keine Weise beeinflussen, zum Beispiel kann sie keine Dateien
-außerhalb ihrer Erstellungs- und Installationsverzeichnisse verändern. Um
-dies zu erreichen, laufen Erstellungsprozesse in isolieren Umgebungen
-(sogenannte @dfn{Container}), wo nur ausdrückliche Eingaben sichtbar sind.
-@cindex Store
-Das Ergebnis von Paketerstellungsfunktionen wird im Dateisystem
-@dfn{zwischengespeichert} in einem besonderen Verzeichnis, was als @dfn{der
-Store} bezeichnet wird (siehe @ref{Der Store}). Jedes Paket wird in sein
-eigenes Verzeichnis im Store installiert — standardmäßig ist er unter
-@file{/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 als einfacher Nutzer sowie
-Garbage Collection für Pakete (siehe @ref{Funktionalitäten}).
-@node GNU-Distribution
-@section GNU-Distribution
-@cindex Guix System
-Mit Guix kommt eine Distribution des GNU-Systems, die nur aus freier
-Software@footnote{Die Bezeichnung »frei« steht hier für die
-@url{http://www.gnu.org/philosophy/free-sw.html,Freiheiten, die Nutzern der
-Software geboten werden}.} besteht. Die Distribution kann für sich allein
-installiert werden (siehe @ref{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@tie{}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 @url{http://www.gnu.org/software/guix/packages,online}
-einsehen, oder indem Sie @command{guix package} ausführen (siehe
-@ref{Aufruf von guix package}):
-@example
-guix package --list-available
-@end example
-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 zur Zeit auf folgenden Plattformen verfügbar:
-@table @code
-@item x86_64-linux
-Intel/AMD-@code{x86_64}-Architektur, Linux-Libre als Kernel,
-@item i686-linux
-Intel-32-Bit-Architektur (IA-32), Linux-Libre als Kernel,
-@item 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.
-@item aarch64-linux
-64-Bit-ARMv8-A-Prozessoren, little-endian, Linux-Libre als Kernel. Derzeit
-ist dies noch in der Erprobungsphase mit begrenzter Unterstützung. Unter
-@ref{Mitwirken} steht, wie Sie dabei helfen können!
-@item mips64el-linux
-64-Bit-MIPS-Prozessoren, little-endian, insbesondere die Loongson-Reihe,
-n32-ABI, mit Linux-Libre als Kernel.
-@end table
-Mit Guix@tie{}System @emph{deklarieren} Sie alle Aspekte der
-Betriebssystemkonfiguration und Guix kümmert sich darum, die Konfiguration
-auf transaktionsbasierte, reproduzierbare und zustandslose Weise zu
-instanziieren (siehe @ref{Systemkonfiguration}). Guix System benutzt den
-Kernel Linux-libre, das Shepherd-Initialisierungssystem (siehe
-@ref{Einführung,,, shepherd, 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
-@code{mips64el-linux} verfügbar.
-@noindent
-Informationen, wie auf andere Architekturen oder Kernels portiert werden
-kann, finden Sie im Abschnitt @ref{Portierung}.
-Diese Distribution aufzubauen basiert auf Kooperation, und Sie sind herzlich
-eingeladen, dabei mitzumachen! Im Abschnitt @ref{Mitwirken} stehen
-weitere Informationen, wie Sie uns helfen können.
-@c *********************************************************************
-@node Installation
-@chapter Installation
-@cindex Guix installieren
-@quotation Anmerkung
-Wir empfehlen, dieses
-@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
-Shell-basierte Installationsskript} zu benutzen, um Guix auf ein bestehendes
-GNU/Linux-System zu installieren — im Folgenden als @dfn{Fremddistribution}
-bezeichnet.@footnote{Dieser Abschnitt bezieht sich auf die Installation des
-Paketverwaltungswerkzeugs, das auf ein bestehendes GNU/Linux-System
-aufsetzend installiert werden kann. Wenn Sie stattdessen das vollständige
-GNU-Betriebssystem installieren möchten, lesen Sie @ref{Systeminstallation}.} Das Skript automatisiert das Herunterladen, das Installieren
-und die anfängliche Konfiguration von Guix. Es sollte als der
-Administratornutzer »root« ausgeführt werden.
-@end quotation
-@cindex Fremddistribution
-@cindex Verzeichnisse auf einer Fremddistribution
-Wenn es auf einer Fremddistribution installiert wird, ergänzt GNU@tie{}Guix
-die verfügbaren Werkzeuge, ohne dass sie sich gegenseitig stören. Guix’
-Daten befinden sich ausschließlich in zwei Verzeichnissen, üblicherweise
-@file{/gnu/store} und @file{/var/guix}; andere Dateien auf Ihrem System wie
-@file{/etc} bleiben unberührt.
-Sobald es installiert ist, kann Guix durch Ausführen von @command{guix pull}
-aktualisiert werden (siehe @ref{Aufruf von guix pull}).
-Sollten Sie es vorziehen, die Installationsschritte manuell durchzuführen,
-oder falls Sie Anpassungen daran vornehmen möchten, könnten sich die
-folgenden Unterabschnitte als nützlich erweisen. Diese beschreiben die
-Software-Voraussetzungen von Guix und wie man es manuell installiert, so
-dass man es benutzen kann.
-@menu
-* Aus Binärdatei installieren::  Guix installieren, ohne Zeit zu verlieren!
-* Voraussetzungen::          Zum Erstellen und Benutzen von Guix nötige 
-                               Software.
-* Den Testkatalog laufen lassen::  Guix testen.
-* Den Daemon einrichten::    Wie man die Umgebung des Erstellungs-Daemons 
-                               einrichtet.
-* Aufruf des guix-daemon::   Den Erstellungs-Daemon laufen lassen.
-* Anwendungen einrichten::   Anwendungsspezifische Einstellungen.
-@end menu
-@node Aus Binärdatei installieren
-@section Aus Binärdatei installieren
-@cindex Guix aus Binärdateien installieren
-@cindex Installations-Skript
-Dieser Abschnitt beschreibt, wie sich Guix auf einem beliebigen System aus
-einem alle Komponenten umfassenden Tarball installieren lässt, der
-Binärdateien für Guix und all seine Abhängigkeiten liefert. Dies geht in der
-Regel schneller, als Guix aus seinen Quelldateien zu installieren, was in
-den nächsten Abschnitten beschrieben wird. Vorausgesetzt wird hier
-lediglich, dass GNU@tie{}tar und Xz verfügbar sind.
-Die Installation läuft so ab:
-@enumerate
-@item
-@cindex Guix-Binärdatei herunterladen
-Laden Sie den binären Tarball von
-@indicateurl{https://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{System}.tar.xz}
-herunter, wobei @var{System} für @code{x86_64-linux} steht, falls Sie es auf
-einer Maschine mit @code{x86_64}-Architektur einrichten, auf der bereits der
-Linux-Kernel läuft, oder entsprechend für andere Maschinen.
-@c The following is somewhat duplicated in ``System Installation''.
-Achten Sie darauf, auch die zugehörige @file{.sig}-Datei herunterzuladen und
-verifizieren Sie damit die Authentizität des Tarballs, ungefähr so:
-@example
-$ wget https://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{System}.tar.xz.sig
-$ gpg --verify guix-binary-@value{VERSION}.@var{System}.tar.xz.sig
-@end example
-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:
-@example
-$ gpg --keyserver @value{KEY-SERVER} \
-      --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
-@end example
-@noindent
-@c end authentication part
-und den Befehl @code{gpg --verify} erneut ausführen.
-@item
-Nun müssen Sie zum Administratornutzer @code{root} wechseln. Abhängig von
-Ihrer Distribution müssen Sie dazu etwa @code{su -} oder @code{sudo -i}
-ausführen. Danach führen Sie als @code{root}-Nutzer aus:
-@example
-# cd /tmp
-# tar --warning=no-timestamp -xf \
-     guix-binary-@value{VERSION}.@var{System}.tar.xz
-# mv var/guix /var/ && mv gnu /
-@end example
-Dadurch wird @file{/gnu/store} (siehe @ref{Der Store}) und @file{/var/guix}
-erzeugt. Letzteres enthält ein fertiges Guix-Profil für den
-Administratornutzer @code{root} (wie im nächsten Schritt beschrieben).
-Entpacken Sie den Tarball @emph{nicht} auf einem schon funktionierenden
-Guix-System, denn es würde seine eigenen essenziellen Dateien überschreiben.
-Die Befehlszeilenoption @code{--warning=no-timestamp} stellt sicher, dass
-GNU@tie{}tar nicht vor »unplausibel alten Zeitstempeln« warnt (solche
-Warnungen traten bei GNU@tie{}tar 1.26 und älter auf, neue Versionen machen
-keine Probleme). Sie treten auf, weil alle Dateien im Archiv als
-Änderungszeitpunkt null eingetragen bekommen haben (das bezeichnet den
-1. Januar 1970). Das ist Absicht, damit der Inhalt des Archivs nicht davon
-abhängt, wann es erstellt wurde, und es somit reproduzierbar wird.
-@item
-Machen Sie das Profil als @file{~root/.config/guix/current} verfügbar, wo
-@command{guix pull} es aktualisieren kann (siehe @ref{Aufruf von guix pull}):
-@example
-# mkdir -p ~root/.config/guix
-# ln -sf /var/guix/profiles/per-user/root/current-guix \
-         ~root/.config/guix/current
-@end example
-»Sourcen« Sie @file{etc/profile}, um @code{PATH} und andere relevante
-Umgebungsvariable zu ergänzen:
-@example
-# GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
-  source $GUIX_PROFILE/etc/profile
-@end example
-@item
-Erzeugen Sie Nutzergruppe und Nutzerkonten für die Erstellungs-Benutzer wie
-folgt (siehe @ref{Einrichten der Erstellungsumgebung}).
-@item
-Führen Sie den Daemon aus, und lassen Sie ihn automatisch bei jedem
-Hochfahren starten.
-Wenn Ihre Wirts-Distribution systemd als »init«-System verwendet, können Sie
-das mit folgenden Befehlen veranlassen:
-@c Versions of systemd that supported symlinked service files are not
-@c yet widely deployed, so we should suggest that users copy the service
-@c files into place.
-@c
-@c See this thread for more information:
-@c http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html
-@example
-# cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
-     /etc/systemd/system/
-# systemctl start guix-daemon && systemctl enable guix-daemon
-@end example
-Wenn Ihre Wirts-Distribution als »init«-System Upstart verwendet:
-@example
-# initctl reload-configuration
-# cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
-     /etc/init/
-# start guix-daemon
-@end example
-Andernfalls können Sie den Daemon immer noch manuell starten, mit:
-@example
-# ~root/.config/guix/current/bin/guix-daemon \
-       --build-users-group=guixbuild
-@end example
-@item
-Stellen Sie den @command{guix}-Befehl auch anderen Nutzern Ihrer Maschine
-zur Verfügung, zum Beispiel so:
-@example
-# mkdir -p /usr/local/bin
-# cd /usr/local/bin
-# ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
-@end example
-Es ist auch eine gute Idee, die Info-Version dieses Handbuchs ebenso
-verfügbar zu machen:
-@example
-# mkdir -p /usr/local/share/info
-# cd /usr/local/share/info
-# for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
-  do ln -s $i ; done
-@end example
-Auf diese Art wird, unter der Annahme, dass bei Ihnen
-@file{/usr/local/share/info} im Suchpfad eingetragen ist, das Ausführen von
-@command{info guix.de} dieses Handbuch öffnen (siehe @ref{Other Info
-Directories,,, texinfo, GNU Texinfo} hat weitere Details, wie Sie den
-Info-Suchpfad ändern können).
-@item
-@cindex Substitute, deren Autorisierung
-Um Substitute von @code{@value{SUBSTITUTE-SERVER}} oder einem Spiegelserver
-davon zu benutzen (siehe @ref{Substitute}), müssen sie erst autorisiert
-werden:
-@example
-# guix archive --authorize < \
-     ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER}.pub
-@end example
-@item
-Alle Nutzer müssen womöglich ein paar zusätzliche Schritte ausführen, damit
-ihre Guix-Umgebung genutzt werden kann, siehe @ref{Anwendungen einrichten}.
-@end enumerate
-Voilà, die Installation ist fertig!
-Sie können nachprüfen, dass Guix funktioniert, indem Sie ein Beispielpaket
-in das root-Profil installieren:
-@example
-# guix package -i hello
-@end example
-Das @code{guix}-Paket muss im Profil von @code{root} installiert bleiben,
-damit es nicht vom Müllsammler geholt wird, denn ohne den
-@command{guix}-Befehl wären Sie lahmgelegt. Anders gesagt, entfernen Sie
-@code{guix} @emph{nicht} mit @code{guix package -r guix}.
-Der Tarball zur Installation aus einer Binärdatei kann einfach durch
-Ausführung des folgenden Befehls im Guix-Quellbaum (re-)produziert und
-verifiziert werden:
-@example
-make guix-binary.@var{System}.tar.xz
-@end example
-@noindent
-…@: was wiederum dies ausführt:
-@example
-guix pack -s @var{System} --localstatedir \
-  --profile-name=current-guix guix
-@end example
-Siehe @ref{Aufruf von guix pack} für weitere Informationen zu diesem
-praktischen Werkzeug.
-@node Voraussetzungen
-@section Voraussetzungen
-Dieser Abschnitt listet Voraussetzungen auf, um Guix aus seinem Quellcode zu
-erstellen. Der Erstellungsprozess für Guix ist derselbe wie für andere
-GNU-Software und wird hier nicht beschrieben. Bitte lesen Sie die Dateien
-@file{README} und @file{INSTALL} im Guix-Quellbaum, um weitere Details zu
-erfahren.
-@cindex Offizielle Webpräsenz
-GNU Guix kann von seiner Webpräsenz unter
-@url{http://www.gnu.org/software/guix/} heruntergeladen werden.
-GNU Guix hat folgende Pakete als Abhängigkeiten:
-@itemize
-@item @url{http://gnu.org/software/guile/, GNU Guile}, Version 2.2.x,
-@item @url{https://notabug.org/cwebber/guile-gcrypt, Guile-Gcrypt}, Version
-0.1.0 oder neuer,
-@item
-@uref{http://gnutls.org/, GnuTLS}, im Speziellen dessen Anbindungen für
-Guile (siehe @ref{Guile Preparations, how to install the GnuTLS bindings for
-Guile,, gnutls-guile, GnuTLS-Guile}),
-@item
-@uref{https://notabug.org/guile-sqlite3/guile-sqlite3, Guile-SQLite3},
-Version 0.1.0 oder neuer,
-@item
-@c FIXME: Specify a version number once a release has been made.
-@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, vom August 2017
-oder neuer,
-@item @uref{https://savannah.nongnu.org/projects/guile-json/, Guile-JSON},
-@item @url{http://zlib.net, zlib},
-@item @url{http://www.gnu.org/software/make/, GNU Make}.
-@end itemize
-Folgende Abhängigkeiten sind optional:
-@itemize
-@item
-@c Note: We need at least 0.10.2 for 'channel-send-eof'.
-Unterstützung für das Auslagern von Erstellungen (siehe @ref{Auslagern des Daemons einrichten}) und @command{guix copy} (siehe @ref{Aufruf von guix copy}) hängt von
-@uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH}, Version
-0.10.2 oder neuer, ab.
-@item
-Wenn @url{http://www.bzip.org, libbz2} verfügbar ist, kann
-@command{guix-daemon} damit Erstellungsprotokolle komprimieren.
-@end itemize
-Sofern nicht @code{--disable-daemon} beim Aufruf von @command{configure}
-übergeben wurde, benötigen Sie auch folgende Pakete:
-@itemize
-@item @url{http://gnupg.org/, GNU libgcrypt},
-@item @url{http://sqlite.org, SQLite 3},
-@item @url{http://gcc.gnu.org, GCC's g++} mit Unterstützung für den
-C++11-Standard.
-@end itemize
-@cindex Zustandsverzeichnis
-Sollten Sie Guix auf einem System konfigurieren, auf dem Guix bereits
-installiert ist, dann stellen Sie sicher, dasselbe Zustandsverzeichnis wie
-für die bestehende Installation zu verwenden. Benutzen Sie dazu die
-Befehlszeilenoption @code{--localstatedir} des @command{configure}-Skripts
-(siehe @ref{Directory Variables, @code{localstatedir},, standards, GNU
-Coding Standards}). Das @command{configure}-Skript schützt vor ungewollter
-Fehlkonfiguration der @var{localstatedir}, damit sie nicht versehentlich
-Ihren Store verfälschen (siehe @ref{Der Store}).
-@cindex Nix, Kompatibilität
-Wenn eine funktionierende Installation of @url{http://nixos.org/nix/, the
-Nix package manager} verfügbar ist, können Sie Guix stattdessen mit
-@code{--disable-daemon} konfigurieren. In diesem Fall ersetzt Nix die drei
-oben genannten Abhängigkeiten.
-Guix ist mit Nix kompatibel, daher ist es möglich, denselben Store für beide
-zu verwenden. Dazu müssen Sie an @command{configure} nicht nur denselben
-Wert für @code{--with-store-dir} übergeben, sondern auch denselben Wert für
-@code{--localstatedir}. Letzterer ist deswegen essenziell, weil er unter
-anderem angibt, wo die Datenbank liegt, in der sich die Metainformationen
-über den Store befinden. Für Nix sind die Werte standardmäßig
-@code{--with-store-dir=/nix/store} und
-@code{--localstatedir=/nix/var}. Beachten Sie, dass @code{--disable-daemon}
-nicht erforderlich ist, wenn Sie die Absicht haben, den Store mit Nix zu
-teilen.
-@node Den Testkatalog laufen lassen
-@section Den Testkatalog laufen lassen
-@cindex Testkatalog
-Nachdem @command{configure} und @code{make} erfolgreich durchgelaufen sind,
-ist es ratsam, den Testkatalog auszuführen. Er kann dabei helfen, Probleme
-mit der Einrichtung oder Systemumgebung zu finden, oder auch Probleme in
-Guix selbst — und Testfehler zu melden ist eine wirklich gute Art und Weise,
-bei der Verbesserung von Guix mitzuhelfen. Um den Testkatalog auszuführen,
-geben Sie Folgendes ein:
-@example
-make check
-@end example
-Testfälle können parallel ausgeführt werden. Sie können die
-Befehlszeiltenoption @code{-j} von GNU@tie{}make benutzen, damit es
-schneller geht. Der erste Durchlauf kann auf neuen Maschinen ein paar
-Minuten dauern, nachfolgende Ausführungen werden schneller sein, weil der
-für die Tests erstellte Store schon einige Dinge zwischengespeichert haben
-wird.
-Es ist auch möglich, eine Teilmenge der Tests laufen zu lassen, indem Sie
-die @code{TESTS}-Variable des Makefiles ähnlich wie in diesem Beispiel
-definieren:
-@example
-make check TESTS="tests/store.scm tests/cpio.scm"
-@end example
-Standardmäßig werden Testergebnisse pro Datei angezeigt. Um die Details
-jedes einzelnen Testfalls zu sehen, können Sie wie in diesem Beispiel die
-@code{SCM_LOG_DRIVER_FLAGS}-Variable des Makefiles definieren:
-@example
-make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
-@end example
-Kommt es zum Fehlschlag, senden Sie bitte eine E-Mail an
-@email{bug-guix@@gnu.org} und fügen Sie die Datei @file{test-suite.log} als
-Anhang bei. Bitte geben Sie dabei in Ihrer Nachricht die benutzte Version
-von Guix an sowie die Versionsnummern der Abhängigkeiten (siehe
-@ref{Voraussetzungen}).
-Guix wird auch mit einem Testkatalog für das ganze System ausgeliefert, der
-vollständige Instanzen des »Guix System«-Betriebssystems testet. Er kann nur
-auf Systemen benutzt werden, auf denen Guix bereits installiert ist, mit
-folgendem Befehl:
-@example
-make check-system
-@end example
-@noindent
-Oder, auch hier, indem Sie @code{TESTS} definieren, um eine Teilmenge der
-auszuführenden Tests anzugeben:
-@example
-make check-system TESTS="basic mcron"
-@end example
-Diese Systemtests sind in den @code{(gnu tests @dots{})}-Modulen
-definiert. Sie funktionieren, indem Sie das getestete Betriebssystem mitsamt
-schlichter Instrumentierung in einer virtuellen Maschine (VM) ausführen. Die
-Tests können aufwendige Berechnungen durchführen oder sie günstig umgehen,
-je nachdem, ob für ihre Abhängigkeiten Substitute zur Verfügung stehen
-(siehe @ref{Substitute}). Manche von ihnen nehmen viel Speicherplatz in
-Anspruch, um die VM-Abbilder zu speichern.
-Auch hier gilt: Falls Testfehler auftreten, senden Sie bitte alle Details an
-@email{bug-guix@@gnu.org}.
-@node Den Daemon einrichten
-@section Den Daemon einrichten
-@cindex Daemon
-Operationen wie das Erstellen eines Pakets oder Laufenlassen des
-Müllsammlers werden alle durch einen spezialisierten Prozess durchgeführt,
-den @dfn{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
-@command{guix package} und @command{guix build} mit dem Daemon (mittels
-entfernter Prozeduraufrufe), um ihm Anweisungen zu geben, was er tun soll.
-Folgende Abschnitte beschreiben, wie Sie die Umgebung des
-Erstellungs-Daemons ausstatten sollten. Siehe auch @ref{Substitute} für
-Informationen darüber, wie Sie es dem Daemon ermöglichen, vorerstellte
-Binärdateien herunterzuladen.
-@menu
-* Einrichten der Erstellungsumgebung::  Die isolierte Umgebung zum Erstellen 
-                                          vorbereiten.
-* Auslagern des Daemons einrichten::  Erstellungen auf entfernte Maschinen 
-                                        auslagern.
-* SELinux-Unterstützung::   Wie man eine SELinux-Richtlinie für den Daemon 
-                               einrichtet.
-@end menu
-@node Einrichten der Erstellungsumgebung
-@subsection Einrichten der Erstellungsumgebung
-@cindex Erstellungsumgebung
-In einem normalen Mehrbenutzersystem werden Guix und sein Daemon — das
-Programm @command{guix-daemon} — vom Systemadministrator installiert;
-@file{/gnu/store} gehört @code{root} und @command{guix-daemon} läuft als
-@code{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.
-@cindex Erstellungsbenutzer
-Wenn @command{guix-daemon} als Administratornutzer @code{root} läuft, wollen
-Sie aber vielleicht dennoch nicht, dass Paketerstellungsprozesse auch als
-@code{root} ablaufen, aus offensichtlichen Sicherheitsgründen. Um dies zu
-vermeiden, sollte ein besonderer Pool aus @dfn{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 @code{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
-@ref{Einführung}).
-Auf einem GNU/Linux-System kann ein Pool von Erstellungsbenutzern wie folgt
-erzeugt werden (mit Bash-Syntax und den Befehlen von @code{shadow}):
-@c See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html
-@c for why `-G' is needed.
-@example
-# 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
-@end example
-@noindent
-Die Anzahl der Erstellungsbenutzer entscheidet, wieviele Erstellungsaufträge
-parallel ausgeführt werden können, wie es mit der Befehlszeilenoption
-@option{--max-jobs} vorgegeben werden kann (siehe @ref{Aufruf des guix-daemon,
-@option{--max-jobs}}). Um @command{guix system vm} und ähnliche Befehle
-nutzen zu können, müssen Sie die Erstellungsbenutzer unter Umständen zur
-@code{kvm}-Benutzergruppe hinzufügen, damit sie Zugriff auf @file{/dev/kvm}
-haben, mit @code{-G guixbuild,kvm} statt @code{-G guixbuild} (siehe
-@ref{Aufruf von guix system}).
-Das Programm @code{guix-daemon} kann mit dem folgenden Befehl als
-@code{root} gestartet werden@footnote{Wenn Ihre Maschine systemd als
-»init«-System verwendet, genügt es, die Datei
-@file{@var{prefix}/lib/systemd/system/guix-daemon.service} in
-@file{/etc/systemd/system} zu platzieren, damit @command{guix-daemon}
-automatisch gestartet wird. Ebenso können Sie, wenn Ihre Maschine Upstart
-als »init«-System benutzt, die Datei
-@file{@var{prefix}/lib/upstart/system/guix-daemon.conf} in @file{/etc/init}
-platzieren.}:
-@example
-# guix-daemon --build-users-group=guixbuild
-@end example
-@cindex chroot
-@noindent
-Auf diese Weise startet der Daemon Erstellungsprozesse in einem chroot als
-einer der @code{guixbuilder}-Benutzer. Auf GNU/Linux enthält die
-chroot-Umgebung standardmäßig nichts außer:
-@c Keep this list in sync with libstore/build.cc! -----------------------
-@itemize
-@item
-einem minimalen @code{/dev}-Verzeichnis, was größtenteils vom @code{/dev}
-des Wirtssystems unabhängig erstellt wurde@footnote{»Größtenteils«, denn
-obwohl die Menge an Dateien, die im @code{/dev} des chroots vorkommen, fest
-ist, können die meisten dieser Dateien nur dann erstellt werden, wenn das
-Wirtssystem sie auch hat.},
-@item
-dem @code{/proc}-Verzeichnis, es zeigt nur die Prozesse des Containers, weil
-ein separater Namensraum für Prozess-IDs (PIDs) benutzt wird,
-@item
-@file{/etc/passwd} mit einem Eintrag für den aktuellen Benutzer und einem
-Eintrag für den Benutzer @file{nobody},
-@item
-@file{/etc/group} mit einem Eintrag für die Gruppe des Benutzers,
-@item
-@file{/etc/hosts} mit einem Eintrag, der @code{localhost} auf
-@code{127.0.0.1} abbildet,
-@item
-einem @file{/tmp}-Verzeichnis mit Schreibrechten.
-@end itemize
-Sie können beeinflussen, in welchem Verzeichnis der Daemon Verzeichnisbäume
-zur Erstellung unterbringt, indem sie den Wert der Umgebungsvariablen
-@code{TMPDIR} ändern. Allerdings heißt innerhalb des chroots der
-Erstellungsbaum immer @file{/tmp/guix-build-@var{Name}.drv-0}, wobei
-@var{Name} der Ableitungsname ist — z.B.@: @code{coreutils-8.24}. Dadurch
-hat der Wert von @code{TMPDIR} keinen Einfluss auf die Erstellungsumgebung,
-wodurch Unterschiede vermieden werden, falls Erstellungsprozesse den Namen
-ihres Erstellungsbaumes einfangen.
-@vindex http_proxy
-Der Daemon befolgt außerdem den Wert der Umgebungsvariablen
-@code{http_proxy} für von ihm durchgeführte HTTP-Downloads, sei es für
-Ableitungen mit fester Ausgabe (siehe @ref{Ableitungen}) oder für Substitute
-(siehe @ref{Substitute}).
-Wenn Sie Guix als ein Benutzer ohne erweiterte Rechte installieren, ist es
-dennoch möglich, @command{guix-daemon} auszuführen, sofern Sie
-@code{--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 @emph{reine}
-Funktionen aufzufassen.
-@node Auslagern des Daemons einrichten
-@subsection Nutzung der Auslagerungsfunktionalität
-@cindex auslagern
-@cindex Build-Hook
-Wenn erwünscht, kann der Erstellungs-Daemon Ableitungserstellungen auf
-andere Maschinen @dfn{auslagern}, auf denen Guix läuft, mit Hilfe des
-@code{offload}-@dfn{Build-Hooks}@footnote{Diese Funktionalität ist nur
-verfügbar, wenn @uref{https://github.com/artyom-poptsov/guile-ssh,
-Guile-SSH} vorhanden ist.}. Wenn diese Funktionalität aktiviert ist, wird
-eine nutzerspezifizierte Liste von Erstellungsmaschinen aus
-@file{/etc/guix/machines.scm} gelesen. Wann immer eine Erstellung angefragt
-wird, zum Beispiel durch @code{guix build}, versucht der Daemon, sie an eine
-der Erstellungsmaschinen auszulagern, die die Einschränkungen der Ableitung
-erfüllen, insbesondere ihren Systemtyp — z.B.@:
-@file{x86_64-linux}. 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 Datei @file{/etc/guix/machines.scm} sieht normalerweise so aus:
-@example
-(list (build-machine
-        (name "eightysix.example.org")
-        (system "x86_64-linux")
-        (host-key "ssh-ed25519 AAAAC3Nza@dots{}")
-        (user "bob")
-        (speed 2.))     ;unglaublich schnell!
-      (build-machine
-        (name "meeps.example.org")
-        (system "mips64el-linux")
-        (host-key "ssh-rsa AAAAB3Nza@dots{}")
-        (user "alice")
-        (private-key
-         (string-append (getenv "HOME")
-                        "/.ssh/identität-für-guix"))))
-@end example
-@noindent
-Im obigen Beispiel geben wir eine Liste mit zwei Erstellungsmaschinen vor,
-eine für die @code{x86_64}-Architektur und eine für die
-@code{mips64el}-Architektur.
-Tatsächlich ist diese Datei — wenig überraschend! — eine Scheme-Datei, die
-ausgewertet wird, wenn der @code{offload}-Hook gestartet wird. Der Wert, den
-sie zurückliefert, muss eine Liste von @code{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 @ref{Einführung, Guile-Avahi,, guile-avahi, Using Avahi in Guile
-Scheme Programs}). Der Datentyp @code{build-machine} wird im Folgenden
-weiter ausgeführt.
-@deftp {Datentyp} build-machine
-Dieser Datentyp repräsentiert Erstellungsmaschinen, an die der Daemon
-Erstellungen auslagern darf. Die wichtigen Felder sind:
-@table @code
-@item name
-Der Hostname (d.h.@: der Rechnername) der entfernten Maschine.
-@item system
-Der Systemtyp der entfernten Maschine — z.B.@: @code{"x86_64-linux"}.
-@item user
-Das Benutzerkonto, mit dem eine Verbindung zur entfernten Maschine über SSH
-aufgebaut werden soll. Beachten Sie, dass das SSH-Schlüsselpaar @emph{nicht}
-durch eine Passphrase geschützt sein darf, damit nicht-interaktive
-Anmeldungen möglich sind.
-@item host-key
-Dies muss der @dfn{öffentliche SSH-Host-Schlüssel} der Maschine im
-OpenSSH-Format sein. Er wird benutzt, um die Identität der Maschine zu
-prüfen, wenn wir uns mit ihr verbinden. Er ist eine lange Zeichenkette, die
-ungefähr so aussieht:
-@example
-ssh-ed25519 AAAAC3NzaC@dots{}mde+UhL hint@@example.org
-@end example
-Wenn auf der Maschine der OpenSSH-Daemon, @command{sshd}, läuft, ist der
-Host-Schlüssel in einer Datei wie @file{/etc/ssh/ssh_host_ed25519_key.pub}
-zu finden.
-Wenn auf der Maschine der SSH-Daemon von GNU@tie{}lsh, nämlich
-@command{lshd}, läuft, befindet sich der Host-Schlüssel in
-@file{/etc/lsh/host-key.pub} oder einer ähnlichen Datei. Er kann ins
-OpenSSH-Format umgewandelt werden durch @command{lsh-export-key} (siehe
-@ref{Converting keys,,, lsh, LSH Manual}):
-@example
-$ lsh-export-key --openssh < /etc/lsh/host-key.pub 
-ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV@dots{}
-@end example
-@end table
-Eine Reihe optionaler Felder kann festgelegt werden:
-@table @asis
-@item @code{port} (Vorgabe: @code{22})
-Portnummer des SSH-Servers auf der Maschine.
-@item @code{private-key} (Vorgabe: @file{~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 @emph{des
-root-Benutzers} genommen wird. Vergewissern Sie sich, dass er existiert,
-wenn Sie die Standardeinstellung verwenden.
-@item @code{compression} (Vorgabe: @code{"zlib@@openssh.com,zlib"})
-@itemx @code{compression-level} (Vorgabe: @code{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.
-@item @code{daemon-socket} (Vorgabe: @code{"/var/guix/daemon-socket/socket"})
-Dateiname des Unix-Sockets, auf dem @command{guix-daemon} auf der Maschine
-lauscht.
-@item @code{parallel-builds} (Vorgabe: @code{1})
-Die Anzahl der Erstellungen, die auf der Maschine parallel ausgeführt werden
-können.
-@item @code{speed} (Vorgabe: @code{1.0})
-Ein »relativer Geschwindigkeitsfaktor«. Der Auslagerungsplaner gibt
-tendenziell Maschinen mit höherem Geschwindigkeitsfaktor den Vorrang.
-@item @code{features} (Vorgabe: @code{'()})
-Eine Liste von Zeichenketten, die besondere von der Maschine unterstützte
-Funktionalitäten bezeichnen. Ein Beispiel ist @code{"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.
-@end table
-@end deftp
-Der Befehl @code{guix} muss sich im Suchpfad der Erstellungsmaschinen
-befinden. Um dies nachzuprüfen, können Sie Folgendes ausführen:
-@example
-ssh build-machine guix repl --version
-@end example
-Es gibt noch eine weitere Sache zu tun, sobald @file{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 @ref{Aufruf von guix archive}):
-@example
-# guix archive --generate-key
-@end example
-@noindent
-Jede Erstellungsmaschine muss den Schlüssel der Hauptmaschine autorisieren,
-damit diese Store-Objekte von der Hauptmaschine empfangen kann:
-@example
-# guix archive --authorize < öffentlicher-schlüssel-hauptmaschine.txt
-@end example
-@noindent
-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 Echtheit von den
-Erstellungsmaschinen empfangener Dateien gewährleisten (und umgekehrt), und
-auch dass sie nicht sabotiert wurden und mit einem autorisierten Schlüssel
-signiert wurden.
-@cindex Auslagerung testen
-Um zu testen, ob Ihr System funktioniert, führen Sie diesen Befehl auf der
-Hauptmaschine aus:
-@example
-# guix offload test
-@end example
-Dadurch wird versucht, zu jeder Erstellungsmaschine eine Verbindung
-herzustellen, die in @file{/etc/guix/machines.scm} angegeben wurde,
-sichergestellt, dass auf jeder Guile und die Guix-Module nutzbar sind, und
-jeweils versucht, etwas auf die Erstellungsmaschine zu exportieren und von
-dort zu imporieren. Dabei auftretende Fehler werden gemeldet.
-Wenn Sie stattdessen eine andere Maschinendatei verwenden möchten, geben Sie
-diese einfach auf der Befehlszeile an:
-@example
-# guix offload test maschinen-qualif.scm
-@end example
-Letztendlich können Sie hiermit nur die Teilmenge der Maschinen testen,
-deren Name zu einem regulären Ausdruck passt:
-@example
-# guix offload test maschinen.scm '\.gnu\.org$'
-@end example
-@cindex Auslagerungs-Lagebericht
-Um die momentane Auslastung aller Erstellungs-Hosts anzuzeigen, führen Sie
-diesen Befehl auf dem Hauptknoten aus:
-@example
-# guix offload status
-@end example
-@node SELinux-Unterstützung
-@subsection SELinux-Unterstützung
-@cindex SELinux, Policy für den Daemon
-@cindex Mandatory Access Control, SELinux
-@cindex Sicherheit, des guix-daemon
-Guix enthält eine SELinux-Richtliniendatei (»Policy«) unter
-@file{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.
-@subsubsection Installieren der SELinux-Policy
-@cindex SELinux, Policy installieren
-Um die Richtlinie (Policy) zu installieren, führen Sie folgenden Befehl mit
-Administratorrechten aus:
-@example
-semodule -i etc/guix-daemon.cil
-@end example
-Kennzeichnen Sie dann das Dateisystem neu mit @code{restorecon} oder einem
-anderen, von Ihrem System angebotenen Mechanismus.
-Sobald die Richtlinie installiert ist, das Dateisystem neu gekennzeichnet
-wurde und der Daemon neugestartet wurde, sollte er im Kontext
-@code{guix_daemon_t} laufen. Sie können dies mit dem folgenden Befehl
-nachprüfen:
-@example
-ps -Zax | grep guix-daemon
-@end example
-Beobachten Sie die Protokolldateien von SELinux, wenn Sie einen Befehl wie
-@code{guix build hello} ausführen, um sich zu überzeugen, dass SELinux alle
-notwendigen Operationen gestattet.
-@subsubsection Einschränkungen
-@cindex SELinux, Einschränkungen
-Diese Richtlinie ist nicht perfekt. Im Folgenden finden Sie eine Liste von
-Einschränkungen oder merkwürdigen Verhaltensweisen, die bedacht werden
-sollten, wenn man die mitgelieferte SELinux-Richtlinie für den Guix-Daemon
-einspielt.
-@enumerate
-@item
-@code{guix_daemon_socket_t} wird nicht wirklich benutzt. Keine der
-Socket-Operationen benutzt Kontexte, die irgendetwas mit
-@code{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.
-@item
-@code{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 @code{user_home_t}, aber Verknüpfungen aus
-dem Persönlichen Verzeichnis des Administratornutzers, oder @file{/tmp},
-oder das Arbeitsverzeichnis des HTTP-Servers, etc., funktioniert das
-nicht. @code{guix gc} würde es nicht gestattet, diese Verknüpfungen
-auszulesen oder zu verfolgen.
-@item
-Die vom Daemon gebotene Funktionalität, auf TCP-Verbindungen zu lauschen,
-könnte nicht mehr funktionieren. Dies könnte zusätzliche Regeln brauchen,
-weil SELinux Netzwerk-Sockets anders behandelt als Dateien.
-@item
-Derzeit wird allen Dateien mit einem Namen, der zum regulären Ausdruck
-@code{/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon} passt, die
-Kennzeichnung @code{guix_daemon_exec_t} zugewiesen, wodurch @emph{jede
-beliebige} Datei mit diesem Namen in irgendeinem Profil gestattet wäre, in
-der Domäne @code{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 @code{guix_daemon_t}. Ab diesem
-Punkt könnte SELinux nicht mehr verhindern, dass es auf Dateien zugreift,
-auf die Prozesse in dieser Domäne zugreifen dürfen.
-Wir könnten zum Zeitpunkt der Installation eine wesentlich restriktivere
-Richtlinie generieren, für die nur @emph{genau derselbe} Dateiname des
-gerade installierten @code{guix-daemon}-Programms als
-@code{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
-@code{guix-daemon}-Programm enthält.
-@end enumerate
-@node Aufruf des guix-daemon
-@section Aufruf von @command{guix-daemon}
-Das Programm @command{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
-(@code{root}) gestartet:
-@example
-# guix-daemon --build-users-group=guixbuild
-@end example
-@noindent
-Details, wie Sie ihn einrichten, finden Sie im Abschnitt @ref{Den Daemon einrichten}.
-@cindex chroot
-@cindex Container, Erstellungsumgebung
-@cindex Erstellungsumgebung
-@cindex Reproduzierbare Erstellungen
-Standardmäßig führt @command{guix-daemon} Erstellungsprozesse mit
-unterschiedlichen UIDs aus, die aus der Erstellungsgruppe stammen, deren
-Name mit @code{--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 @ref{Programmierschnittstelle, derivation}), und ein paar
-bestimmte Systemverzeichnisse, darunter standardmäßig auch @file{/dev} und
-@file{/dev/pts}. Zudem ist die Erstellungsumgebung auf GNU/Linux ein
-@dfn{Container}: Nicht nur hat er seinen eigenen Dateisystembaum, er hat
-auch einen separaten Namensraum zum Einhängen von Dateisystemen, seinen
-eigenen Namensraum für PIDs, für Netzwerke, etc. Dies hilft dabei,
-reproduzierbare Erstellungen zu garantieren (siehe @ref{Funktionalitäten}).
-Wenn der Daemon im Auftrag des Nutzers eine Erstellung durchführt, erzeugt
-er ein Erstellungsverzeichnis, entweder in @file{/tmp} oder im Verzeichnis,
-das durch die Umgebungsvariable @code{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
-@option{--keep-failed} angegeben hat (siehe @ref{Aufruf von guix build,
-@option{--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
-@command{guix}-Unterbefehle). Der Befehl @command{guix processes} zeigt
-Ihnen eine Übersicht solcher Systemaktivitäten; damit werden Ihnen alle
-aktiven Sitzungen und Clients gezeigt. Weitere Informationen finden Sie
-unter @ref{Aufruf von guix processes}.
-Die folgenden Befehlszeilenoptionen werden unterstützt:
-@table @code
-@item --build-users-group=@var{Gruppe}
-Verwende die Benutzerkonten aus der @var{Gruppe}, um Erstellungsprozesse
-auszuführen (siehe @ref{Den Daemon einrichten, build users}).
-@item --no-substitutes
-@cindex Substitute
-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 @ref{Substitute}).
-Wenn der Daemon mit @code{--no-substitutes} ausgeführt wird, können Clients
-trotzdem Substitute explizit aktivieren über den entfernten Prozeduraufruf
-@code{set-build-options} (siehe @ref{Der Store}).
-@item --substitute-urls=@var{URLs}
-@anchor{daemon-substitute-urls}
-@var{URLs} als standardmäßige, leerzeichengetrennte Liste der Quell-URLs für
-Substitute benutzen. Wenn diese Befehlszeilenoption @emph{nicht} angegeben
-wird, wird @indicateurl{https://@value{SUBSTITUTE-SERVER}} verwendet.
-Das hat zur Folge, dass Substitute von den @var{URLs} heruntergeladen werden
-können, solange sie mit einer Signatur versehen sind, der vertraut wird
-(siehe @ref{Substitute}).
-@cindex Build-Hook
-@item --no-build-hook
-Den @dfn{Build-Hook} nicht benutzen.
-»Build-Hook« ist der Name eines Hilfsprogramms, das der Daemon starten kann
-und an das er Erstellungsanfragen übermittelt. Durch diesen Mechanismus
-können Erstellungen an andere Maschinen ausgelagert werden (siehe
-@ref{Auslagern des Daemons einrichten}).
-@item --cache-failures
-Fehler bei der Erstellung zwischenspeichern. Normalerweise werden nur
-erfolgreiche Erstellungen gespeichert.
-Wenn diese Befehlszeilenoption benutzt wird, kann @command{guix gc
--list-failures} benutzt werden, um die Menge an Store-Objekten abzufragen,
-die als Fehlschläge markiert sind; @command{guix gc --clear-failures}
-entfernt Store-Objekte aus der Menge zwischengespeicherter
-Fehlschläge. Siehe @ref{Aufruf von guix gc}.
-@item --cores=@var{n}
-@itemx -c @var{n}
-@var{n} CPU-Kerne zum Erstellen jeder Ableitung benutzen; @code{0} heißt, so
-viele wie verfügbar sind.
-Der Vorgabewert ist @code{0}, jeder Client kann jedoch eine abweichende
-Anzahl vorgeben, zum Beispiel mit der Befehlszeilenoption @code{--cores} von
-@command{guix build} (siehe @ref{Aufruf von guix build}).
-Dadurch wird die Umgebungsvariable @code{NIX_BUILD_CORES} im
-Erstellungsprozess definiert, welcher sie benutzen kann, um intern parallele
-Ausführungen zuzulassen — zum Beispiel durch Nutzung von @code{make
-j$NIX_BUILD_CORES}.
-@item --max-jobs=@var{n}
-@itemx -M @var{n}
-Höchstenss @var{n} Erstellungsaufträge parallel bearbeiten. Der Vorgabewert
-liegt bei @code{1}. Wird er auf @code{0} gesetzt, werden keine Erstellungen
-lokal durchgeführt, stattdessen lagert der Daemon sie nur aus (siehe
-@ref{Auslagern des Daemons einrichten}) oder sie schlagen einfach fehl.
-@item --max-silent-time=@var{Sekunden}
-Wenn der Erstellungs- oder Substitutionsprozess länger als
-@var{Sekunden}-lang keine Ausgabe erzeugt, wird er abgebrochen und ein
-Fehler beim Erstellen gemeldet.
-Der Vorgabewert ist @code{0}, was bedeutet, dass es keine Zeitbeschränkung
-gibt.
-Clients können einen anderen Wert als den hier angegebenen verwenden lassen
-(siehe @ref{Gemeinsame Erstellungsoptionen, @code{--max-silent-time}}).
-@item --timeout=@var{Sekunden}
-Entsprechend wird hier der Erstellungs- oder Substitutionsprozess
-abgebrochen und als Fehlschlag gemeldet, wenn er mehr als
-@var{Sekunden}-lang dauert.
-Der Vorgabewert ist @code{0}, was bedeutet, dass es keine Zeitbeschränkung
-gibt.
-Clients können einen anderen Wert verwenden lassen (siehe @ref{Gemeinsame Erstellungsoptionen, @code{--timeout}}).
-@item --rounds=@var{N}
-Jede Ableitung @var{n}-mal hintereinander erstellen und einen Fehler melden,
-wenn nacheinander ausgewertete Erstellungsergebnisse nicht Bit für Bit
-identisch sind. Beachten Sie, dass Clients wie @command{guix build} einen
-anderen Wert verwenden lassen können (siehe @ref{Aufruf von guix build}).
-Wenn dies zusammen mit @option{--keep-failed} benutzt wird, bleiben die sich
-unterscheidenden Ausgaben im Store unter dem Namen
-@file{/gnu/store/@dots{}-check}. Dadurch können Unterschiede zwischen den
-beiden Ergebnissen leicht erkannt werden.
-@item --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 @code{--verbosity} von @command{guix build}
-(siehe @ref{Aufruf von guix build}).
-@item --chroot-directory=@var{Verzeichnis}
-Füge das @var{Verzeichnis} zum chroot von Erstellungen hinzu.
-Dadurch kann sich das Ergebnis von Erstellungsprozessen ändern — zum
-Beispiel, wenn diese optionale Abhängigkeiten aus dem @var{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.
-@item --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 @command{guix-daemon}
-auf einem Benutzerkonto ohne ausreichende Berechtigungen ausgeführt wird.
-@item --log-compression=@var{Typ}
-Erstellungsprotokolle werden entsprechend dem @var{Typ} komprimiert, der
-entweder @code{gzip}, @code{bzip2} oder @code{none} (für keine Kompression)
-sein muss.
-Sofern nicht @code{--lose-logs} angegeben wurde, werden alle
-Erstellungsprotokolle in der @var{localstatedir} gespeichert. Um Platz zu
-sparen, komprimiert sie der Daemon standardmäßig automatisch mit bzip2.
-@item --disable-deduplication
-@cindex Deduplizieren
-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.
-@item --gc-keep-outputs[=yes|no]
-Gibt an, ob der Müllsammler (Garbage Collector, GC) die Ausgaben lebendiger
-Ableitungen behalten muss (»yes«) oder nicht (»no«).
-@cindex GC-Wurzeln
-@cindex Müllsammlerwurzeln
-Für »yes« behält der Müllsammler die Ausgaben aller lebendigen Ableitungen
-im Store — die @code{.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 @ref{Aufruf von guix gc} für weitere Informationen zu Müllsammlerwurzeln.
-@item --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.@:
-@code{.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 @code{--gc-keep-derivations} auf »yes«
-steht, die Lebendigkeit von Ausgaben auf Ableitungen, und wenn
-@code{--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.
-@item --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
-@code{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.
-@item --lose-logs
-Keine Protokolle der Erstellungen vorhalten. Normalerweise würden solche in
-@code{@var{localstatedir}/guix/log} gespeichert.
-@item --system=@var{System}
-Verwende @var{System} als aktuellen Systemtyp. Standardmäßig ist dies das
-Paar aus Befehlssatz und Kernel, welches beim Aufruf von @code{configure}
-erkannt wurde, wie zum Beispiel @code{x86_64-linux}.
-@item --listen=@var{Endpunkt}
-Lausche am @var{Endpunkt} auf Verbindungen. Dabei wird der @var{Endpunkt}
-als Dateiname eines Unix-Sockets verstanden, wenn er mit einem @code{/}
-(Schrägstrich) beginnt. Andernfalls wird der @var{Endpunkt} als Hostname
-(d.h.@: Rechnername) oder als Hostname-Port-Paar verstanden, auf dem
-gelauscht wird. Hier sind ein paar Beispiele:
-@table @code
-@item --listen=/gnu/var/daemon
-Lausche auf Verbindungen am Unix-Socket @file{/gnu/var/daemon}, falls nötig
-wird er dazu erstellt.
-@item --listen=localhost
-@cindex Daemon, Fernzugriff
-@cindex Fernzugriff auf den Daemon
-@cindex Daemon, Einrichten auf Clustern
-@cindex Cluster, Einrichtung des Daemons
-Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die
-@code{localhost} entspricht, auf Port 44146.
-@item --listen=128.0.0.42:1234
-Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die
-@code{128.0.0.42} entspricht, auf Port 1234.
-@end table
-Diese Befehlszeilenoption kann mehrmals wiederholt werden. In diesem Fall
-akzeptiert @command{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
-@code{GUIX_DAEMON_SOCKET} festlegen (siehe @ref{Der Store,
-@code{GUIX_DAEMON_SOCKET}}).
-@quotation Anmerkung
-Das Daemon-Protokoll ist @emph{weder authentifiziert noch
-verschlüsselt}. Die Benutzung von @code{--listen=@var{Host}} 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.
-@end quotation
-Wird @code{--listen} nicht angegeben, lauscht @command{guix-daemon} auf
-Verbindungen auf dem Unix-Socket, der sich unter
-@file{@var{localstatedir}/guix/daemon-socket/socket} befindet.
-@end table
-@node Anwendungen einrichten
-@section Anwendungen einrichten
-@cindex Fremddistribution
-Läuft Guix aufgesetzt auf einer GNU/Linux-Distribution außer Guix System —
-einer sogenannten @dfn{Fremddistribution} —, so sind ein paar zusätzliche
-Schritte bei der Einrichtung nötig. Hier finden Sie manche davon.
-@subsection Locales
-@anchor{locales-and-locpath}
-@cindex Locales, nicht auf Guix System
-@vindex LOCPATH
-@vindex GUIX_LOCPATH
-Ü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 @code{GUIX_LOCPATH} passend festlegen:
-@example
-$ guix package -i glibc-locales
-$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
-@end example
-Beachten Sie, dass das Paket @code{glibc-locales} Daten für alle von
-GNU@tie{}libc unterstützten Locales enthält und deswegen um die 110@tie{}MiB
-wiegt. Alternativ gibt es auch @code{glibc-utf8-locales}, was kleiner, aber
-auf ein paar UTF-8-Locales beschränkt ist.
-Die Variable @code{GUIX_LOCPATH} spielt eine ähnliche Rolle wie
-@code{LOCPATH} (siehe @ref{Locale Names, @code{LOCPATH},, libc, The GNU C
-Library Reference Manual}). Es gibt jedoch zwei wichtige Unterschiede:
-@enumerate
-@item
-@code{GUIX_LOCPATH} wird nur von der libc in Guix beachtet und nicht der von
-Fremddistributionen bereitgestellten libc. Mit @code{GUIX_LOCPATH} können
-Sie daher sicherstellen, dass die Programme der Fremddistribution keine
-inkompatiblen Locale-Daten von Guix laden.
-@item
-libc hängt an jeden @code{GUIX_LOCPATH}-Eintrag @code{/X.Y} an, wobei
-@code{X.Y} die Version von libc ist — z.B.@: @code{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.
-@end enumerate
-Das ist wichtig, weil das Locale-Datenformat verschiedener libc-Versionen
-inkompatibel sein könnte.
-@subsection Name Service Switch
-@cindex Name Service Switch, glibc
-@cindex NSS (Name Service Switch), glibc
-@cindex nscd (Name Service Caching Daemon)
-@cindex Name Service Caching Daemon (nscd)
-Wenn Sie Guix auf einer Fremddistribution verwenden, @emph{empfehlen wir
-stärkstens}, dass Sie den @dfn{Name Service Cache Daemon} der
-GNU-C-Bibliothek, @command{nscd}, laufen lassen, welcher auf dem Socket
-@file{/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.
-@cindex @file{nsswitch.conf}
-Die GNU-C-Bibliothek implementiert einen @dfn{Name Service Switch} (NSS),
-welcher einen erweiterbaren Mechanismus zur allgemeinen »Namensauflösung«
-darstellt: Hostnamensauflösung, Benutzerkonten und weiteres (siehe @ref{Name Service Switch,,, libc, The GNU C Library Reference Manual}).
-@cindex Network Information Service (NIS)
-@cindex NIS (Network Information Service)
-Für die Erweiterbarkeit unterstützt der NSS @dfn{Plugins}, welche neue
-Implementierungen zur Namensauflösung bieten: Zum Beispiel ermöglicht das
-Plugin @code{nss-mdns} die Namensauflösung für @code{.local}-Hostnamen, das
-Plugin @code{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
-@file{/etc/nsswitch.conf} und alle auf dem System laufenden Programme halten
-sich an diese Einstellungen (siehe @ref{NSS Configuration File,,, libc, The
-GNU C Reference Manual}).
-Wenn sie eine Namensauflösung durchführen — zum Beispiel, indem sie die
-@code{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 @file{libnss_*.so}-Dateien — werden mit @code{dlopen} geladen, aber
-sie kommen von der C-Bibliothek des Wirtssystems und nicht von der
-C-Bibliothek, mit der die Anwendung gebunden wurde (also der C-Bibliothek
-von Guix).
-Und hier kommt es zum Problem: Wenn die Anwendung mit der C-Bibliothek von
-Guix (etwa glibc 2.24) gebunden wurde und die NSS-Plugins von einer anderen
-C-Bibliothek (etwa @code{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 @command{nscd} auf dem System wird, neben anderen
-Vorteilen, dieses Problem der binären Inkompatibilität vermieden, weil diese
-@code{libnss_*.so}-Dateien vom @command{nscd}-Prozess geladen werden, nicht
-in den Anwendungen selbst.
-@subsection X11-Schriftarten
-@cindex Schriftarten
-Die Mehrheit der grafischen Anwendungen benutzen Fontconfig zum Finden und
-Laden von Schriftarten und für die Darstellung im X11-Client. Im Paket
-@code{fontconfig} in Guix werden Schriftarten standardmäßig in
-@file{$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 @code{gs-fonts}, @code{font-dejavu} und
-@code{font-gnu-freefont-ttf}.
-Um auf Chinesisch, Japanisch oder Koreanisch verfassten Text in grafischen
-Anwendungen anzeigen zu können, möchten Sie vielleicht
-@code{font-adobe-source-han-sans} oder @code{font-wqy-zenhei}
-installieren. Ersteres hat mehrere Ausgaben, für jede Sprachfamilie eine
-(siehe @ref{Pakete mit mehreren Ausgaben.}). Zum Beispiel installiert
-folgender Befehl Schriftarten für chinesische Sprachen:
-@example
-guix package -i font-adobe-source-han-sans:cn
-@end example
-@cindex @code{xterm}
-Ältere Programme wie @command{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:
-@example
-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1
-@end example
-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:
-@c Note: 'xset' does not accept symlinks so the trick below arranges to
-@c get at the real directory.  See <https://bugs.gnu.org/30655>.
-@example
-xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))
-@end example
-@cindex @code{xlsfonts}
-Danach können Sie den Befehl @code{xlsfonts} ausführen (aus dem Paket
-@code{xlsfonts}), um sicherzustellen, dass dort Ihre TrueType-Schriftarten
-aufgeführt sind.
-@cindex @code{fc-cache}
-@cindex Font-Cache
-Nach der Installation der Schriftarten müssen Sie unter Umständen den
-Schriftarten-Zwischenspeicher (Font-Cache) erneuern, um diese in Anwendungen
-benutzen zu können. Gleiches gilt, wenn mit Guix installierte Anwendungen
-anscheinend keine Schriftarten finden können. Um das Erneuern des
-Font-Caches zu erzwingen, führen Sie @code{fc-cache -f} aus. Der Befehl
-@code{fc-cache} wird vom Paket @code{fontconfig} angeboten.
-@subsection X.509-Zertifikate
-@cindex @code{nss-certs}
-Das Paket @code{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 @ref{X.509-Zertifikate} stehen
-genaue Informationen.
-@subsection Emacs-Pakete
-@cindex @code{emacs}
-Wenn Sie mit Guix Pakete für Emacs installieren, werden deren elisp-Dateien
-entweder in @file{$HOME/.guix-profile/share/emacs/site-lisp/} oder in
-Unterverzeichnissen von
-@file{$HOME/.guix-profile/share/emacs/site-lisp/guix.d/}
-gespeichert. Letzteres Verzeichnis gibt es, weil es Tausende von
-Emacs-Paketen gibt und sie alle im selben Verzeichnis zu speichern
-vielleicht nicht verlässlich funktioniert (wegen Namenskonflikten). Daher
-halten wir es für richtig, für jedes Paket ein anderes Verzeichnis zu
-benutzen. Das Emacs-Paketsystem organisiert die Dateistruktur ähnlich (siehe
-@ref{Package Files,,, emacs, The GNU Emacs Manual}).
-Standardmäßig »weiß« Emacs (wenn er mit Guix installiert wurde), wo diese
-Pakete liegen, Sie müssen also nichts selbst konfigurieren. Wenn Sie aber
-aus irgendeinem Grund mit Guix installierte Pakete nicht automatisch laden
-lassen möchten, können Sie Emacs mit der Befehlszeilenoption
-@code{--no-site-file} starten (siehe @ref{Init File,,, emacs, The GNU Emacs
-Manual}).
-@subsection GCC-Toolchain
-@cindex GCC
-@cindex ld-wrapper
-Guix bietet individuelle Compiler-Pakete wie etwa @code{gcc}, aber wenn Sie
-einen vollständigen Satz an Werkzeugen zum Kompilieren und Binden von
-Quellcode brauchen, werden Sie eigentlich das Paket @code{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 @code{debug}-Ausgabe), Binutils und einen Wrapper für den Binder/Linker.
-Der Zweck des Wrappers ist, die an den Binder übergebenen
-Befehlszeilenoptionen mit @code{-L} und @code{-l} zu überprüfen und jeweils
-passende Argumente mit @code{-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
-@code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} setzen.
-@c TODO What else?
-@c *********************************************************************
-@node Systeminstallation
-@chapter Systeminstallation
-@cindex Installieren von Guix System
-@cindex Guix System, Installation
-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
-@ref{Installation}.
-@ifinfo
-@quotation Anmerkung
-@c This paragraph is for people reading this from tty2 of the
-@c installation image.
-Sie lesen diese Dokumentation mit einem Info-Betrachter. Details, wie Sie
-ihn bedienen, erfahren Sie, indem Sie die Eingabetaste (auch »Return« oder
-»Enter« genannt) auf folgender Verknüpfung drücken: @ref{Top, Info reader,,
-info-stnd, Stand-alone GNU Info}. Drücken Sie danach @kbd{l}, um hierher
-zurückzukommen.
-Führen Sie alternativ @command{info info} auf einer anderen Konsole (tty)
-aus, um dieses Handbuch offen zu lassen.
-@end quotation
-@end ifinfo
-@menu
-* Einschränkungen::         Was Sie erwarten dürfen.
-* Hardware-Überlegungen::   Unterstützte Hardware.
-* Installation von USB-Stick oder DVD::  Das Installationsmedium 
-                                           vorbereiten.
-* Vor der Installation::     Netzwerkanbindung, Partitionierung etc.
-* Geführte grafische Installation::  Leichte grafische Installation.
-* Manuelle Installation::    Manuelle Installation für Zauberer.
-* Nach der Systeminstallation::  Wenn die Installation erfolgreich war.
-* Guix in einer VM installieren::  Ein »Guix System«-Spielplatz.
-* Ein Abbild zur Installation erstellen::  Wie ein solches entsteht.
-@end menu
-@node Einschränkungen
-@section Einschränkungen
-We consider Guix System to be ready for a wide range of ``desktop'' and
-server use cases.  The reliability guarantees it provides---transactional
-upgrades and rollbacks, reproducibility---make it a solid foundation.
-Nevertheless, before you proceed with the installation, be aware of the
-following noteworthy limitations applicable to version @value{VERSION}:
-@itemize
-@item
-Der Logical Volume Manager (LVM) wird nicht unterstützt.
-@item
-Immer mehr Systemdienste sind verfügbar (siehe @ref{Dienste}), aber manche
-könnten noch fehlen.
-@item
-GNOME, Xfce, LXDE, and Enlightenment are available (@pxref{Desktop-Dienste}), as well as a number of X11 window managers.  However, KDE is
-currently missing.
-@end itemize
-More than a disclaimer, this is an invitation to report issues (and success
-stories!), and to join us in improving it.  @xref{Mitwirken}, for more
-info.
-@node Hardware-Überlegungen
-@section Hardware-Überlegungen
-@cindex Hardwareunterstützung von Guix System
-GNU@tie{}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.
-@cindex WLAN, Hardware-Unterstützung
-One of the main areas where free drivers or firmware are lacking is WiFi
-devices.  WiFi devices known to work include those using Atheros chips
-(AR9271 and AR7010), which corresponds to the @code{ath9k} Linux-libre
-driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core
-Revision 5), which corresponds to the @code{b43-open} Linux-libre driver.
-Free firmware exists for both and is available out-of-the-box on Guix
-System, as part of @code{%base-firmware} (@pxref{»operating-system«-Referenz,
-@code{firmware}}).
-@cindex RYF, Respects Your Freedom
-Die @uref{https://www.fsf.org/, Free Software Foundation} betreibt
-@uref{https://www.fsf.org/ryf, @dfn{Respects Your Freedom}} (RYF), ein
-Zertifizierungsprogramm für Hardware-Produkte, die Ihre Freiheit und
-Privatsphäre respektieren 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
-@uref{https://www.h-node.org/, H-Node}. Dort steht ein Katalog von
-Hardware-Geräten mit Informationen darüber, wie gut sie von GNU/Linux
-unterstützt werden.
-@node Installation von USB-Stick oder DVD
-@section Installation von USB-Stick oder DVD
-Sie können ein ISO-9660-Installationsabbild von
-@indicateurl{https://alpha.gnu.org/gnu/guix/guix-system-install-@value{VERSION}.@var{System}.iso.xz}
-herunterladen, dass Sie auf einen USB-Stick aufspielen oder auf eine DVD
-brennen können, wobei Sie für @var{System} eines der folgenden schreiben
-müssen:
-@table @code
-@item x86_64-linux
-für ein GNU/Linux-System auf Intel/AMD-kompatiblen 64-Bit-Prozessoren,
-@item i686-linux
-für ein 32-Bit-GNU/Linux-System auf Intel-kompatiblen Prozessoren.
-@end table
-@c start duplication of authentication part from ``Binary Installation''
-Laden Sie auch die entsprechende @file{.sig}-Datei herunter und verifizieren
-Sie damit die Authentizität Ihres Abbilds, indem Sie diese Befehle eingeben:
-@example
-$ wget https://alpha.gnu.org/gnu/guix/guix-system-install-@value{VERSION}.@var{System}.iso.xz.sig
-$ gpg --verify guix-system-install-@value{VERSION}.@var{System}.iso.xz.sig
-@end example
-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:
-@example
-$ gpg --keyserver @value{KEY-SERVER} \
-      --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
-@end example
-@noindent
-@c end duplication
-und den Befehl @code{gpg --verify} erneut ausführen.
-Dieses Abbild enthält die Werkzeuge, die Sie zur Installation brauchen. Es
-ist dafür gedacht,  @emph{so wie es ist} auf einen hinreichend großen
-USB-Stick oder eine DVD kopiert zu werden.
-@unnumberedsubsec Kopieren auf einen USB-Stick
-Um das Abbild auf einen USB-Stick zu kopieren, führen Sie folgende Schritte
-durch:
-@enumerate
-@item
-Entpacken Sie das Abbild mit dem @command{xz}-Befehl:
-@example
-xz -d guix-system-install-@value{VERSION}.@var{System}.iso.xz
-@end example
-@item
-Stecken Sie einen USB-Stick in Ihren Rechner ein, der mindestens 1@tie{}GiB
-groß ist, und bestimmen Sie seinen Gerätenamen. Ist der Gerätename des
-USB-Sticks @file{/dev/sdX}, dann kopieren Sie das Abbild mit dem Befehl:
-@example
-dd if=guix-system-install-@value{VERSION}.@var{System}.iso of=/dev/sdX
-sync
-@end example
-Sie benötigen in der Regel Administratorrechte, um auf @file{/dev/sdX}
-zuzugreifen.
-@end enumerate
-@unnumberedsubsec Auf eine DVD brennen
-Um das Abbild auf eine DVD zu kopieren, führen Sie diese Schritte durch:
-@enumerate
-@item
-Entpacken Sie das Abbild mit dem @command{xz}-Befehl:
-@example
-xz -d guix-system-install-@value{VERSION}.@var{System}.iso.xz
-@end example
-@item
-Legen Sie eine unbespielte DVD in Ihren Rechner ein und bestimmen Sie ihren
-Gerätenamen. Angenommen der Name des DVD-Laufwerks ist @file{/dev/srX},
-kopieren Sie das Abbild mit:
-@example
-growisofs -dvd-compat -Z /dev/srX=guix-system-install-@value{VERSION}.@var{System}.iso
-@end example
-Der Zugriff auf @file{/dev/srX} setzt in der Regel Administratorrechte
-voraus.
-@end enumerate
-@unnumberedsubsec Das System starten
-Sobald das erledigt ist, sollten Sie Ihr System neu starten und es vom
-USB-Stick oder der DVD hochfahren (»booten«) können. Dazu müssen Sie
-wahrscheinlich beim Starten des Rechners in das BIOS- oder UEFI-Boot-Menü
-gehen, von wo aus Sie auswählen können, dass vom USB-Stick gebootet werden
-soll.
-Lesen Sie den Abschnitt @ref{Guix in einer VM installieren}, wenn Sie Guix System
-stattdessen in einer virtuellen Maschine (VM) installieren möchten.
-@node Vor der Installation
-@section Vor der Installation
-Wenn Sie Ihren Rechner gebootet haben, können Sie sich vom grafischen
-Installationsprogramm durch den Installationsvorgang führen lassen, was den
-Einstieg leicht macht (siehe @ref{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 @ref{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 @kbd{strg-alt-f3},
-@kbd{strg-alt-f4} usw.@: gedrückt haben. TTY2 zeigt Ihnen dieses Handbuch,
-das Sie über die Tastenkombination @kbd{strg-alt-f2} erreichen. In dieser
-Dokumentation können Sie mit den Steuerungsbefehlen Ihres Info-Betrachters
-blättern (siehe @ref{Top,,, info-stnd, 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.
-@quotation 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.
-@end quotation
-@node Geführte grafische Installation
-@section Geführte grafische Installation
-Das grafische Installationsprogramm ist mit einer textbasierten
-Benutzeroberfläche ausgestattet. Es kann Sie mit Dialogfeldern durch die
-Schritte führen, mit denen Sie GNU@tie{}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.
-@image{images/installer-network,5in,, Netzwerkanbindung einrichten mit dem
-grafischen Installationsprogramm}
-Mit den danach kommenden Schritten können Sie Ihre Festplatte
-partitionieren, wie im folgenden Bild gezeigt, und auswählen, ob Ihre
-Dateisysteme verschlüsselt werden sollen oder nicht. Sie können Ihren
-Rechnernamen und das Administratorpasswort (das »root«-Passwort) festlegen
-und ein Benutzerkonto einrichten, und noch mehr.
-@image{images/installer-partitions,5in,, Partitionieren mit dem grafischen
-Installationsprogramm}
-Beachten Sie, dass Sie mit dem Installationsprogramm jederzeit den aktuellen
-Installationsschritt verlassen und zu einem vorherigen Schritt zurückkehren
-können, wie Sie im folgenden Bild sehen können.
-@image{images/installer-resume,5in,, Mit einem Installationsschritt
-fortfahren}
-Sobald Sie fertig sind, erzeugt das Installationsprogramm eine
-Betriebssystemkonfiguration und zeigt sie an (siehe @ref{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 @ref{Nach der Systeminstallation} für
-Informationen, wie es weitergeht!
-@node Manuelle Installation
-@section Manuelle Installation
-Dieser Abschnitt beschreibt, wie Sie GNU@tie{}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
-@ref{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 @kbd{strg-alt-f3},
-@kbd{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 @command{guix package} nachinstallieren, wenn Sie sie
-brauchen (siehe @ref{Aufruf von guix package}).
-@menu
-* Tastaturbelegung und Netzwerkanbindung und Partitionierung::  Erstes 
-                                                                  Einrichten.
-* Fortfahren mit der Installation::  Installieren.
-@end menu
-@node Tastaturbelegung und Netzwerkanbindung und Partitionierung
-@subsection Tastaturbelegung, Netzwerkanbindung und Partitionierung
-Bevor Sie das System installieren können, wollen Sie vielleicht die
-Tastaturbelegung ändern, eine Netzwerkverbindung herstellen und die
-Zielfestplatte partitionieren. Dieser Abschnitt wird Sie durch diese
-Schritte führen.
-@subsubsection Tastaturbelegung
-@cindex Tastaturbelegung
-Das Installationsabbild verwendet die US-amerikanische
-QWERTY-Tastaturbelegung. Wenn Sie dies ändern möchten, können Sie den
-@command{loadkeys}-Befehl benutzen. Mit folgendem Befehl würden Sie zum
-Beispiel die Dvorak-Tastaturbelegung auswählen:
-@example
-loadkeys dvorak
-@end example
-Schauen Sie sich an, welche Dateien im Verzeichnis
-@file{/run/current-system/profile/share/keymaps} stehen, um eine Liste
-verfügbarer Tastaturbelegungen zu sehen. Wenn Sie mehr Informationen
-brauchen, führen Sie @command{man loadkeys} aus.
-@subsubsection Netzwerkkonfiguration
-Führen Sie folgenden Befehl aus, um zu sehen, wie Ihre
-Netzwerkschnittstellen benannt sind:
-@example
-ifconfig -a
-@end example
-@noindent
-@dots{} oder mit dem GNU/Linux-eigenen @command{ip}-Befehl:
-@example
-ip a
-@end example
-@c http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
-Der Name kabelgebundener Schnittstellen (engl. Interfaces) beginnt mit dem
-Buchstaben @samp{e}, zum Beispiel heißt die dem ersten fest eingebauten
-Ethernet-Adapter entsprechende Schnittstelle @samp{eno1}. Drahtlose
-Schnittstellen werden mit einem Namen bezeichnet, der mit dem Buchstaben
-@samp{w} beginnt, etwa @samp{w1p2s0}.
-@table @asis
-@item Kabelverbindung
-Um ein kabelgebundenes Netzwerk einzurichten, führen Sie den folgenden
-Befehl aus, wobei Sie statt @var{Schnittstelle} den Namen der
-kabelgebundenen Schnittstelle eintippen, die Sie benutzen möchten.
-@example
-ifconfig @var{Schnittstelle} up
-@end example
-@item Drahtlose Verbindung
-@cindex WLAN
-@cindex WiFi
-Um Drahtlosnetzwerke einzurichten, können Sie eine Konfigurationsdatei für
-das Konfigurationswerkzeug des @command{wpa_supplicant} schreiben (wo Sie
-sie speichern, ist nicht wichtig), indem Sie eines der verfügbaren
-Textbearbeitungsprogramme wie etwa @command{nano} benutzen:
-@example
-nano wpa_supplicant.conf
-@end example
-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:
-@example
-network=@{
-  ssid="@var{meine-ssid}"
-  key_mgmt=WPA-PSK
-  psk="geheime Passphrase des Netzwerks"
-@}
-@end example
-Starten Sie den Dienst für Drahtlosnetzwerke und lassen Sie ihn im
-Hintergrund laufen, indem Sie folgenden Befehl eintippen (ersetzen Sie dabei
-@var{Schnittstelle} durch den Namen der Netzwerkschnittstelle, die Sie
-benutzen möchten):
-@example
-wpa_supplicant -c wpa_supplicant.conf -i @var{Schnittstelle} -B
-@end example
-Führen Sie @command{man wpa_supplicant} aus, um mehr Informationen zu
-erhalten.
-@end table
-@cindex DHCP
-Zu diesem Zeitpunkt müssen Sie sich eine IP-Adresse beschaffen. Auf einem
-Netzwerk, wo IP-Adressen automatisch @i{via} DHCP zugewiesen werden, können
-Sie das hier ausführen:
-@example
-dhclient -v @var{Schnittstelle}
-@end example
-Versuchen Sie, einen Server zu pingen, um zu prüfen, ob sie mit dem Internet
-verbunden sind und alles richtig funktioniert:
-@example
-ping -c 3 gnu.org
-@end example
-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.
-@cindex Über SSH installieren
-Wenn Sie möchten, können Sie die weitere Installation auch per Fernwartung
-durchführen, indem Sie einen SSH-Server starten:
-@example
-herd start ssh-daemon
-@end example
-Vergewissern Sie sich vorher, dass Sie entweder ein Passwort mit
-@command{passwd} festgelegt haben, oder dass Sie für OpenSSH eine
-Authentifizierung über öffentliche Schlüssel eingerichtet haben, bevor Sie
-sich anmelden.
-@subsubsection Plattenpartitionierung
-Sofern nicht bereits geschehen, ist der nächste Schritt, zu partitionieren
-und dann die Zielpartition zu formatieren.
-Auf dem Installationsabbild sind mehrere Partitionierungswerkzeuge zu
-finden, einschließlich (siehe @ref{Overview,,, parted, GNU Parted User
-Manual}), @command{fdisk} und @command{cfdisk}. Starten Sie eines davon und
-partitionieren Sie Ihre Festplatte oder sonstigen Massenspeicher:
-@example
-cfdisk
-@end example
-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 @ref{BIOS
-installation,,, grub, GNU GRUB manual}).
-@cindex EFI, Installation
-@cindex UEFI, Installation
-@cindex ESP, EFI-Systempartition
-Falls Sie stattdessen einen EFI-basierten GRUB installieren möchten, muss
-auf der Platte eine FAT32-formatierte @dfn{EFI-Systempartition} (ESP)
-vorhanden sein. Diese Partition kann unter dem Pfad @file{/boot/efi}
-eingebunden (»gemountet«) werden und die @code{esp}-Flag der Partition muss
-gesetzt sein. Dazu würden Sie beispielsweise in @command{parted} eintippen:
-@example
-parted /dev/sda set 1 esp on
-@end example
-@quotation Anmerkung
-@vindex grub-bootloader
-@vindex grub-efi-bootloader
-Falls Sie nicht wissen, ob Sie einen EFI- oder BIOS-basierten GRUB
-installieren möchten: Wenn bei Ihnen das Verzeichnis
-@file{/sys/firmware/efi} im Dateisystem existiert, möchten Sie vermutlich
-eine EFI-Installation durchführen, wozu Sie in Ihrer Konfiguration
-@code{grub-efi-bootloader} benutzen. Ansonsten sollten Sie den
-BIOS-basierten GRUB benutzen, der mit @code{grub-bootloader} bezeichnet
-wird.  Siehe @ref{Bootloader-Konfiguration}, wenn Sie mehr Informationen
-über Bootloader brauchen.
-@end quotation
-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) erzeugen@footnote{Derzeit unterstützt Guix System
-nur die Dateisystemtypen ext4 und btrfs. Insbesondere funktioniert
-Guix-Code, der Dateisystem-UUIDs und -Labels ausliest, nur auf diesen
-Dateisystemtypen.}. Wenn Sie eine ESP brauchen und dafür die Partition
-@file{/dev/sda1} vorgesehen haben, müssen Sie diesen Befehl ausführen:
-@example
-mkfs.fat -F32 /dev/sda1
-@end example
-Geben Sie Ihren Dateisystemen auch besser eine Bezeichnung (»Label«), damit
-Sie sie zuverlässig wiedererkennen und später in den
-@code{file-system}-Deklarationen darauf Bezug nehmen können (siehe @ref{Dateisysteme}). Dazu benutzen Sie typischerweise die Befehlszeilenoption
-@code{-L} des Befehls @command{mkfs.ext4} oder entsprechende Optionen für
-andere Befehle. Wenn wir also annehmen, dass @file{/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 @code{my-root}
-erstellen:
-@example
-mkfs.ext4 -L my-root /dev/sda2
-@end example
-@cindex verschlüsselte Partition
-Falls Sie aber vorhaben, die Partition mit dem Wurzeldateisystem zu
-verschlüsseln, können Sie dazu die Cryptsetup-/LUKS-Werkzeuge verwenden
-(siehe @inlinefmtifelse{html, @uref{https://linux.die.net/man/8/cryptsetup,
-@code{man cryptsetup}}, @code{man cryptsetup}}, um mehr darüber zu
-erfahren). Angenommen Sie wollen die Partition für das Wurzeldateisystem
-verschlüsselt auf @file{/dev/sda2} installieren, dann brauchen Sie eine
-Befehlsfolge ähnlich wie diese:
-@example
-cryptsetup luksFormat /dev/sda2
-cryptsetup open --type luks /dev/sda2 my-partition
-mkfs.ext4 -L my-root /dev/mapper/my-partition
-@end example
-Sobald das erledigt ist, binden Sie dieses Dateisystem als Installationsziel
-mit dem Einhängepunkt @file{/mnt} ein, wozu Sie einen Befehl wie hier
-eintippen (auch hier unter der Annahme, dass @code{my-root} die Bezeichnung
-des künftigen Wurzeldateisystems ist):
-@example
-mount LABEL=my-root /mnt
-@end example
-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 @file{/boot/efi} für die
-EFI-Systempartition entschieden haben, binden Sie sie jetzt als
-@file{/mnt/boot/efi} ein, damit @code{guix system init} sie später findet.
-Wenn Sie zudem auch vorhaben, eine oder mehrere Swap-Partitionen zu benutzen
-(siehe @ref{Memory Concepts, swap space,, libc, The GNU C Library Reference
-Manual}), initialisieren Sie diese nun mit @command{mkswap}. Angenommen Sie
-haben eine Swap-Partition auf @file{/dev/sda3}, dann würde der Befehl so
-lauten:
-@example
-mkswap /dev/sda3
-swapon /dev/sda3
-@end example
-Alternativ können Sie eine Swap-Datei benutzen. Angenommen, Sie wollten die
-Datei @file{/swapdatei} im neuen System als eine Swapdatei benutzen, dann
-müssten Sie Folgendes ausführen@footnote{Dieses Beispiel wird auf vielen
-Arten von Dateisystemen funktionieren (z.B.@: auf ext4). Auf Dateisystemen
-mit Copy-on-Write (wie z.B.@: btrfs) können sich die nötigen Schritte
-unterscheiden. Details finden Sie in der Dokumentation auf den
-Handbuchseiten von @command{mkswap} und @command{swapon}.}:
-@example
-# 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
-@end example
-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.
-@node Fortfahren mit der Installation
-@subsection Fortfahren mit der Installation
-Wenn die Partitionen des Installationsziels bereit sind und dessen
-Wurzeldateisystem unter @file{/mnt} eingebunden wurde, kann es losgehen mit
-der Installation. Führen Sie zuerst aus:
-@example
-herd start cow-store /mnt
-@end example
-Dadurch wird @file{/gnu/store} copy-on-write, d.h.@: dorthin von Guix
-erstellte Pakete werden in ihrer Installationsphase auf dem unter
-@file{/mnt} befindlichen Zieldateisystem gespeichert, statt den
-Arbeitsspeicher auszulasten. Das ist nötig, weil die erste Phase des Befehls
-@command{guix system init} (siehe unten) viele Dateien nach
-@file{/gnu/store} herunterlädt oder sie erstellt, Änderungen am
-@file{/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 @ref{Top,,, nano, GNU nano
-Manual}), welcher Syntax und zueinander gehörende Klammern hervorheben
-kann. Andere mitgelieferte Texteditoren, die Sie benutzen können, sind GNU
-Zile (ein Emacs-Klon) und nvi (ein Klon des ursprünglichen
-@command{vi}-Editors von BSD). Wir empfehlen sehr, dass Sie diese Datei im
-Zieldateisystem der Installation speichern, etwa als
-@file{/mnt/etc/config.scm}, weil Sie Ihre Konfigurationsdatei im frisch
-installierten System noch brauchen werden.
-Der Abschnitt @ref{Das Konfigurationssystem nutzen} gibt einen Überblick über
-die Konfigurationsdatei. Die in dem Abschnitt diskutierten
-Beispielkonfigurationen sind im Installationsabbild im Verzeichnis
-@file{/etc/configuration} zu finden. Um also mit einer Systemkonfiguration
-anzufangen, die einen grafischen »Display-Server« (eine
-»Desktop«-Arbeitsumgebung) bietet, könnten Sie so etwas ausführen:
-@example
-# mkdir /mnt/etc
-# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
-# nano /mnt/etc/config.scm
-@end example
-Achten Sie darauf, was in Ihrer Konfigurationsdatei steht, und besonders auf
-Folgendes:
-@itemize
-@item
-Ihre @code{bootloader-configuration}-Form muss sich auf dasjenige Ziel
-beziehen, auf das Sie GRUB installieren möchten. Sie sollte genau dann
-@code{grub-bootloader} nennen, wenn Sie GRUB im alten BIOS-Modus
-installieren, und für neuere UEFI-Systeme sollten Sie
-@code{grub-efi-bootloader} nennen. Bei Altsystemen bezeichnet das
-@code{target}-Feld ein Gerät wie @code{/dev/sda}, bei UEFI-Systemen
-bezeichnet es den Pfad zu einer eingebundenen EFI-Partition wie
-@code{/boot/efi}; stellen Sie sicher, dass die ESP tatsächlich dort
-eingebunden ist und ein @code{file-system}-Eintrag dafür in Ihrer
-Konfiguration festgelegt wurde.
-@item
-Dateisystembezeichnungen müssen mit den jeweiligen @code{device}-Feldern in
-Ihrer @code{file-system}-Konfiguration übereinstimmen, sofern Sie in Ihrer
-@code{file-system}-Konfiguration die Prozedur @code{file-system-label} für
-ihre @code{device}-Felder benutzen.
-@item
-Gibt es verschlüsselte Partitionen oder RAID-Partitionen, dann müssen sie im
-@code{mapped-devices}-Feld genannt werden (siehe @ref{Zugeordnete Geräte}).
-@end itemize
-Wenn Sie damit fertig sind, Ihre Konfigurationsdatei vorzubereiten, können
-Sie das neue System initialisieren (denken Sie daran, dass zukünftige
-Wurzeldateisystem muss unter @file{/mnt} wie bereits beschrieben eingebunden
-sein):
-@example
-guix system init /mnt/etc/config.scm /mnt
-@end example
-@noindent
-Dies kopiert alle notwendigen Dateien und installiert GRUB auf
-@file{/dev/sdX}, sofern Sie nicht noch die Befehlszeilenoption
-@option{--no-bootloader} benutzen. Weitere Informationen finden Sie im
-Abschnitt @ref{Aufruf von guix system}. Der Befehl kann das Herunterladen oder
-Erstellen fehlender Softwarepakete auslösen, was einige Zeit in Anspruch
-nehmen kann.
-Sobald der Befehl erfolgreich — hoffentlich! — durchgelaufen ist, können Sie
-mit dem Befehl @command{reboot} das neue System booten lassen. Der
-Administratornutzer @code{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 @command{passwd} als @code{root} ausführen, außer Ihre
-Konfiguration enthält schon Passwörter (siehe @ref{user-account-password,
-user account passwords}). Siehe @ref{Nach der Systeminstallation} für
-Informationen, wie es weiter geht!
-@node Nach der Systeminstallation
-@section Nach der Systeminstallation
-Sie haben es geschafft: Sie haben Guix System erfolgreich gebootet! Von
-jetzt an können Sie Guix System aktualisieren, wann Sie möchten, indem Sie
-zum Beispiel das hier ausführen:
-@example
-guix pull
-sudo guix system reconfigure /etc/config.scm
-@end example
-@noindent
-Dadurch wird eine neue Systemgeneration aus den neuesten Paketen und
-Diensten erstellt (siehe @ref{Aufruf von guix system}). Wir empfehlen, diese
-Schritte regelmäßig zu wiederholen, damit Ihr System die aktuellen
-Sicherheitsaktualisierungen benutzt (siehe @ref{Sicherheitsaktualisierungen}).
-@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
-@quotation Anmerkung
-@cindex sudo, Wirkung auf @command{guix pull}
-Beachten Sie, dass bei Nutzung von @command{sudo guix} der
-@command{guix}-Befehl des aktiven Benutzers ausgeführt wird und @emph{nicht}
-der des Administratornutzers »root«, weil @command{sudo} die
-Umgebungsvariable @code{PATH} unverändert lässt. Um ausdrücklich das
-@command{guix}-Programm des Administrators aufzurufen, müssen Sie
-@command{sudo -i guix @dots{}} eintippen.
-@end quotation
-Besuchen Sie uns auf @code{#guix} auf dem Freenode-IRC-Netzwerk oder auf der
-Mailing-Liste @file{guix-devel@@gnu.org}, um uns Rückmeldung zu geben!
-@node Guix in einer VM installieren
-@section Guix in einer virtuellen Maschine installieren
-@cindex virtuelle Maschine, Guix System installieren
-@cindex Virtual Private Server (VPS)
-@cindex VPS (Virtual Private Server)
-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 @uref{http://qemu.org/,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:
-@enumerate
-@item
-Zunächst laden Sie das Installationsabbild des Guix-Systems wie zuvor
-beschrieben herunter und entpacken es (siehe @ref{Installation von USB-Stick oder DVD}).
-@item
-Legen Sie nun ein Disk-Image an, das das System nach der Installation
-enthalten soll. Um ein qcow2-formatiertes Disk-Image zu erstellen, benutzen
-Sie den Befehl @command{qemu-img}:
-@example
-qemu-img create -f qcow2 guixsd.img 50G
-@end example
-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.
-@item
-Starten Sie das USB-Installationsabbild auf einer virtuellen Maschine:
-@example
-qemu-system-x86_64 -m 1024 -smp 1 \
-  -net user -net nic,model=virtio -boot menu=on \
-  -drive file=guix-system-install-@value{VERSION}.@var{System}.iso \
-  -drive file=guixsd.img
-@end example
-Halten Sie obige Reihenfolge der @option{-drive}-Befehlszeilenoptionen für
-die Laufwerke ein.
-Drücken Sie auf der Konsole der virtuellen Maschine schnell die
-@kbd{F12}-Taste, um ins Boot-Menü zu gelangen. Drücken Sie dort erst die
-Taste @kbd{2} und dann die Eingabetaste @kbd{RET}, um Ihre Auswahl zu
-bestätigen.
-@item
-Sie sind nun in der virtuellen Maschine als Administratornutzer @code{root}
-angemeldet und können mit der Installation wie gewohnt fortfahren. Folgen
-Sie der Anleitung im Abschnitt @ref{Vor der Installation}.
-@end enumerate
-Wurde die Installation abgeschlossen, können Sie das System starten, das
-sich nun als Abbild in der Datei @file{guixsd.img} befindet. Der Abschnitt
-@ref{Guix in einer VM starten} erklärt, wie Sie das tun können.
-@node Ein Abbild zur Installation erstellen
-@section Ein Abbild zur Installation erstellen
-@cindex Installationsabbild
-Das oben beschriebene Installationsabbild wurde mit dem Befehl @command{guix
-system} erstellt, genauer gesagt mit:
-@example
-guix system disk-image --file-system-type=iso9660 \
-  gnu/system/install.scm
-@end example
-Die Datei @file{gnu/system/install.scm} finden Sie im Quellbaum von
-Guix. Schauen Sie sich die Datei und auch den Abschnitt @ref{Aufruf von guix system} an, um mehr Informationen über das Installationsabbild zu erhalten.
-@section Abbild zur Installation für ARM-Rechner erstellen
-Viele ARM-Chips funktionieren nur mit ihrer eigenen speziellen Variante des
-@uref{http://www.denx.de/wiki/U-Boot/, 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:
-@example
-guix system disk-image --system=armhf-linux -e '((@@ (gnu system install) os-with-u-boot) (@@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'
-@end example
-@code{A20-OLinuXino-Lime2} ist der Name des Chips. Wenn Sie einen ungültigen
-Namen eingeben, wird eine Liste möglicher Chip-Namen ausgegeben.
-@c *********************************************************************
-@node Paketverwaltung
-@chapter Paketverwaltung
-@cindex Pakete
-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 von den im Folgenden
-beschriebenen Befehlszeilen-Benutzerschnittstellen (siehe @ref{Aufruf von guix package, @code{guix package}}) können Sie auch mit der
-Emacs-Guix-Schnittstelle (siehe @ref{Top,,, emacs-guix, The Emacs-Guix
-Reference Manual}) arbeiten, nachdem Sie das Paket @code{emacs-guix}
-installiert haben (führen Sie zum Einstieg in Emacs-Guix den Emacs-Befehl
-@kbd{M-x guix-help} aus):
-@example
-guix package -i emacs-guix
-@end example
-@menu
-* Funktionalitäten::        Wie Guix Ihr Leben schöner machen wird.
-* Aufruf von guix package::  Pakete installieren, entfernen usw.
-* Substitute::               Vorerstelle Binärdateien herunterladen.
-* Pakete mit mehreren Ausgaben.::  Ein Quellpaket, mehrere Ausgaben.
-* Aufruf von guix gc::       Den Müllsammler laufen lassen.
-* Aufruf von guix pull::     Das neueste Guix samt Distribution laden.
-* Kanäle::                  Die Paketsammlung anpassen.
-* Untergeordnete::           Mit einer anderen Version von Guix 
-                               interagieren.
-* Aufruf von guix describe::  Informationen über Ihre Guix-Version 
-                                anzeigen.
-* Aufruf von guix archive::  Import und Export von Store-Dateien.
-@end menu
-@node Funktionalitäten
-@section Funktionalitäten
-Wenn Sie Guix benutzen, landet jedes Paket schließlich im @dfn{Paket-Store}
-in seinem eigenen Verzeichnis — der Name ist ähnlich wie
-@file{/gnu/store/xxx-package-1.2}, wobei @code{xxx} eine Zeichenkette in
-Base32-Darstellung ist.
-Statt diese Verzeichnisse direkt anzugeben, haben Nutzer ihr eigenes
-@dfn{Profil}, welches auf diejenigen Pakete zeigt, die sie tatsächlich
-benutzen wollen. Diese Profile sind im Persönlichen Verzeichnis des
-jeweiligen Nutzers gespeichert als @code{$HOME/.guix-profile}.
-Zum Beispiel installiert @code{alice} GCC 4.7.2. Dadurch zeigt dann
-@file{/home/alice/.guix-profile/bin/gcc} auf
-@file{/gnu/store/@dots{}-gcc-4.7.2/bin/gcc}. Auf demselben Rechner hat
-@code{bob} bereits GCC 4.8.0 installiert. Das Profil von @code{bob} zeigt
-dann einfach weiterhin auf @file{/gnu/store/@dots{}-gcc-4.8.0/bin/gcc} —
-d.h.@: beide Versionen von GCC koexistieren auf demselben System, ohne sich
-zu stören.
-Der Befehl @command{guix package} ist das zentrale Werkzeug, um Pakete zu
-verwalten (siehe @ref{Aufruf von guix package}). Es arbeitet auf dem eigenen
-Profil jedes Nutzers und kann @emph{mit normalen Benutzerrechten} ausgeführt
-werden.
-@cindex Transaktionen
-Der Befehl stellt die offensichtlichen Installations-, Entfernungs- und
-Aktualisierungsoperationen zur Verfügung. Jeder Aufruf ist tatsächlich eine
-eigene @emph{Transaktion}: Entweder die angegebene Operation wird
-erfolgreich durchgeführt, oder gar nichts passiert. Wenn also der Prozess
-von @command{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 @emph{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 @ref{Das Konfigurationssystem nutzen}).
-Alle Pakete im Paket-Store können vom @emph{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 @ref{Aufruf von guix gc}). Benutzer können auch ausdrücklich alte Generationen ihres Profils
-löschen, damit die zugehörigen Pakete vom Müllsammler gelöscht werden
-können.
-@cindex Reproduzierbarkeit
-@cindex Reproduzierbare Erstellungen
-Guix verfolgt einen @dfn{rein funktionalen} Ansatz bei der Paketverwaltung,
-wie er in der Einleitung beschrieben wurde (siehe @ref{Einführung}). Jedes
-Paketverzeichnis im @file{/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 maximiert auch die @dfn{Reproduzierbarkeit der
-Erstellungen} zu maximieren: Dank der isolierten Erstellungsumgebungen, die
-benutzt werden, resultiert eine Erstellung wahrscheinlich in bitweise
-identischen Dateien, auch wenn sie auf unterschiedlichen Maschinen
-durchgeführt wird (siehe @ref{Aufruf des guix-daemon, container}).
-@cindex Substitute
-Auf dieser Grundlage kann Guix @dfn{transparent Binär- oder Quelldateien
-ausliefern}. Wenn eine vorerstellte Binärdatei für ein
-@file{/gnu/store}-Objekt von einer externen Quelle verfügbar ist — ein
-@dfn{Substitut} —, lädt Guix sie einfach herunter und entpackt sie,
-andernfalls erstellt Guix das Paket lokal aus seinem Quellcode (siehe
-@ref{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 @emph{anfechten} (siehe @ref{Aufruf von guix challenge}).
-Kontrolle über die Erstellungsumgebung ist eine auch für Entwickler
-nützliche Funktionalität. Der Befehl @command{guix environment} ermöglicht
-es Entwicklern eines Pakets, schnell die richtige Entwicklungsumgebung für
-ihr Paket einzurichten, ohne manuell die Abhängigkeiten des Pakets in ihr
-Profil installieren zu müssen (siehe @ref{Aufruf von guix environment}).
-@cindex Nachbildung, von Software-Umgebungen
-@cindex Provenienzverfolgung, von Software-Artefakten
-Ganz Guix und all seine Paketdefinitionen stehen unter Versionskontrolle und
-@command{guix pull} macht es möglich, auf dem Verlauf der Entwicklung von
-Guix selbst »in der Zeit zu reisen« (siehe @ref{Aufruf von guix pull}). Dadurch kann eine Instanz von Guix auf einer anderen Maschine oder
-zu einem späteren Zeitpunkt genau nachgebildet werden, wodurch auch
-@emph{vollständige Software-Umgebungen gänzlich nachgebildet} werden können,
-mit genauer @dfn{Provenienzverfolgung}, wo diese Software herkommt.
-@node Aufruf von guix package
-@section Invoking @command{guix package}
-@cindex Installieren von Paketen
-@cindex Entfernen von Paketen
-@cindex Paketinstallation
-@cindex Paketentfernung
-Der Befehl @command{guix package} ist ein Werkzeug, womit Nutzer Pakete
-installieren, aktualisieren, entfernen und auf vorherige Konfigurationen
-zurücksetzen können. Dabei wird nur das eigene Profil des Nutzers verwendet,
-und es funktioniert mit normalen Benutzerrechten, ohne Administratorrechte
-(siehe @ref{Funktionalitäten}). Die Syntax ist:
-@example
-guix package @var{Optionen}
-@end example
-@cindex Transaktionen
-In erster Linie geben die @var{Optionen} an, welche Operationen in der
-Transaktion durchgeführt werden sollen. Nach Abschluss wird ein neues Profil
-erzeugt, aber vorherige @dfn{Generationen} des Profils bleiben verfügbar,
-falls der Benutzer auf sie zurückwechseln will.
-Um zum Beispiel @code{lua} zu entfernen und @code{guile} und
-@code{guile-cairo} in einer einzigen Transaktion zu installieren:
-@example
-guix package -r lua -i guile guile-cairo
-@end example
-@command{guix package} unterstützt auch ein @dfn{deklaratives Vorgehen},
-wobei der Nutzer die genaue Menge an Paketen, die verfügbar sein sollen,
-festlegt und über die Befehlszeilenoption @option{--manifest} übergibt
-(siehe @ref{profile-manifest, @option{--manifest}}).
-@cindex Profil
-Für jeden Benutzer wird automatisch eine symbolische Verknüpfung zu seinem
-Standardprofil angelegt als @file{$HOME/.guix-profile}. Diese symbolische
-Verknüpfung zeigt immer auf die aktuelle Generation des Standardprofils des
-Benutzers. Somit können Nutzer @file{$HOME/.guix-profile/bin} z.B.@: zu
-ihrer Umgebungsvariablen @code{PATH} hinzufügen.
-@cindex Suchpfade
-Wenn Sie nicht die Guix System Distribution benutzen, sollten Sie in
-Betracht ziehen, folgende Zeilen zu Ihrem @file{~/.bash_profile}
-hinzuzufügen (siehe @ref{Bash Startup Files,,, bash, The GNU Bash Reference
-Manual}), damit in neu erzeugten Shells alle Umgebungsvariablen richtig
-definiert werden:
-@example
-GUIX_PROFILE="$HOME/.guix-profile" ; \
-source "$HOME/.guix-profile/etc/profile"
-@end example
-Ist Ihr System für mehrere Nutzer eingerichtet, werden Nutzerprofile an
-einem Ort gespeichert, der als @dfn{Müllsammlerwurzel} registriert ist, auf
-die @file{$HOME/.guix-profile} zeigt (siehe @ref{Aufruf von guix gc}). Dieses
-Verzeichnis ist normalerweise
-@code{@var{localstatedir}/guix/profiles/per-user/@var{Benutzer}}, wobei
-@var{localstatedir} der an @code{configure} als @code{--localstatedir}
-übergebene Wert ist und @var{Benutzer} für den jeweiligen Benutzernamen
-steht. Das @file{per-user}-Verzeichnis wird erstellt, wenn
-@command{guix-daemon} gestartet wird, und das Unterverzeichnis
-@var{Benutzer} wird durch @command{guix package} erstellt.
-Als @var{Optionen} kann vorkommen:
-@table @code
-@item --install=@var{Paket} @dots{}
-@itemx -i @var{Paket} @dots{}
-Die angegebenen @var{Paket}e installieren.
-Jedes @var{Paket} kann entweder einfach durch seinen Paketnamen aufgeführt
-werden, wie @code{guile}, oder als Paketname gefolgt von einem At-Zeichen @@
-und einer Versionsnummer, wie @code{guile@@1.8.8} oder auch nur
-@code{guile@@1.8} (in letzterem Fall wird die neueste Version mit Präfix
-@code{1.8} ausgewählt.)
-Wird keine Versionsnummer angegeben, wird die neueste verfügbare Version
-ausgewählt. Zudem kann im @var{Paket} ein Doppelpunkt auftauchen, gefolgt
-vom Namen einer der Ausgaben des Pakets, wie @code{gcc:doc} oder
-@code{binutils@@2.22:lib} (siehe @ref{Pakete mit mehreren Ausgaben.}). Pakete mit zugehörigem Namen (und optional der Version) werden
-unter den Modulen der GNU-Distribution gesucht (siehe @ref{Paketmodule}).
-@cindex propagierte Eingaben
-Manchmal haben Pakete @dfn{propagierte Eingaben}: Als solche werden
-Abhängigkeiten bezeichnet, die automatisch zusammen mit dem angeforderten
-Paket installiert werden (im Abschnitt @ref{package-propagated-inputs,
-@code{propagated-inputs} in @code{package} objects} sind weitere
-Informationen über propagierte Eingaben in Paketdefinitionen zu finden).
-@anchor{package-cmd-propagated-inputs}
-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 @code{--search-paths}
-weiter unten). Alle fehlenden oder womöglich falschen Definitionen von
-Umgebungsvariablen werden hierbei gemeldet.
-@item --install-from-expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Das Paket installieren, zu dem der @var{Ausdruck} ausgewertet wird.
-Beim @var{Ausdruck} muss es sich um einen Scheme-Ausdruck handeln, der zu
-einem @code{<package>}-Objekt ausgewertet wird. Diese Option ist besonders
-nützlich, um zwischen gleichnamigen Varianten eines Pakets zu unterscheiden,
-durch Ausdrücke wie @code{(@@ (gnu packages base) guile-final)}.
-Beachten Sie, dass mit dieser Option die erste Ausgabe des angegebenen
-Pakets installiert wird, was unzureichend sein kann, wenn eine bestimmte
-Ausgabe eines Pakets mit mehreren Ausgaben gewünscht ist.
-@item --install-from-file=@var{Datei}
-@itemx -f @var{Datei}
-Das Paket installieren, zu dem der Code in der @var{Datei} ausgewertet wird.
-Zum Beispiel könnte die @var{Datei} eine Definition wie diese enthalten
-(siehe @ref{Pakete definieren}):
-@example
-@verbatiminclude package-hello.scm
-@end example
-Entwickler könnten es für nützlich erachten, eine solche
-@file{guix.scm}-Datei im Quellbaum ihres Projekts abzulegen, mit der
-Zwischenstände der Entwicklung getestet und reproduzierbare
-Erstellungsumgebungen aufgebaut werden können (siehe @ref{Aufruf von guix environment}).
-@item --remove=@var{Paket} @dots{}
-@itemx -r @var{Paket} @dots{}
-Die angegebenen @var{Paket}e entfernen.
-Wie auch bei @code{--install} kann jedes @var{Paket} neben dem Paketnamen
-auch eine Versionsnummer und/oder eine Ausgabe benennen. Zum Beispiel würde
-@code{-r glibc:debug} die @code{debug}-Ausgabe von @code{glibc} aus dem
-Profil entfernen.
-@item --upgrade[=@var{Regexp} @dots{}]
-@itemx -u [@var{Regexp} @dots{}]
-@cindex Pakete aktualisieren
-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 @var{Regexp}s passt. Siehe auch
-weiter unten die Befehlszeilenoption @code{--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
-@command{guix pull} ausführen (siehe @ref{Aufruf von guix pull}).
-@item --do-not-upgrade[=@var{Regexp} @dots{}]
-In Verbindung mit der Befehlszeilenoption @code{--upgrade}, führe
-@emph{keine} Aktualisierung von Paketen durch, deren Name zum regulären
-Ausdruck @var{Regexp} passt. Um zum Beispiel alle Pakete im aktuellen Profil
-zu aktualisieren mit Ausnahme derer, die »emacs« im Namen haben:
-@example
-$ guix package --upgrade . --do-not-upgrade emacs
-@end example
-@item @anchor{profile-manifest}--manifest=@var{Datei}
-@itemx -m @var{Datei}
-@cindex Profildeklaration
-@cindex Profilmanifest
-Erstellt eine neue Generation des Profils aus dem vom Scheme-Code in
-@var{Datei} gelieferten Manifest-Objekt.
-Dadurch könnrn Sie den Inhalt des Profils @emph{deklarieren}, statt ihn
-durch eine Folge von Befehlen wie @code{--install} u.Ä. zu generieren. Der
-Vorteil ist, dass die @var{Datei} unter Versionskontrolle gestellt werden
-kann, auf andere Maschinen zum Reproduzieren desselben Profils kopiert
-werden kann und Ähnliches.
-@c FIXME: Add reference to (guix profile) documentation when available.
-Der Code in der @var{Datei} muss ein @dfn{Manifest}-Objekt liefern, was
-ungefähr einer Liste von Paketen entspricht:
-@findex packages->manifest
-@example
-(use-package-modules guile emacs)
-(packages->manifest
- (list emacs
-       guile-2.0
-       ;; Eine bestimmte Paketausgabe nutzen.
-       (list guile-2.0 "debug")))
-@end example
-@findex specifications->manifest
-In diesem Beispiel müssen wir wissen, welche Module die Variablen
-@code{emacs} und @code{guile-2.0} definieren, um die richtige Angabe mit
-@code{use-package-modules} machen zu können, was umständlich sein kann. Wir
-können auch normale Paketnamen angeben und sie durch
-@code{specifications->manifest} zu den entsprechenden Paketobjekten
-auflösen, zum Beispiel so:
-@example
-(specifications->manifest
- '("emacs" "guile@@2.2" "guile@@2.2:debug"))
-@end example
-@item --roll-back
-@cindex rücksetzen
-@cindex Zurücksetzen von Transaktionen
-@cindex Transaktionen, zurücksetzen
-Wechselt zur vorherigen @dfn{Generation} des Profils zurück — d.h.@: macht
-die letzte Transaktion rückgängig.
-In Verbindung mit Befehlszeilenoptionen wie @code{--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 @dfn{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.
-@item --switch-generation=@var{Muster}
-@itemx -S @var{Muster}
-@cindex Generationen
-Wechselt zu der bestimmten Generation, die durch das @var{Muster} bezeichnet
-wird.
-Als @var{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
-@code{--switch-generation=+1} nach einem Zurücksetzen wieder zur neueren
-Generation zurück.
-Der Unterschied zwischen @code{--roll-back} und
-@code{--switch-generation=-1} ist, dass @code{--switch-generation} keine
-nullte Generation erzeugen wird; existiert die angegebene Generation nicht,
-bleibt schlicht die aktuelle Generation erhalten.
-@item --search-paths[=@var{Art}]
-@cindex Suchpfade
-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 @dfn{Suchpfade} für Dateien
-festzulegen, die von einigen installierten Paketen benutzt werden.
-Zum Beispiel braucht GCC die Umgebungsvariablen @code{CPATH} und
-@code{LIBRARY_PATH}, um zu wissen, wo sich im Benutzerprofil Header und
-Bibliotheken befinden (siehe @ref{Environment Variables,,, gcc, Using the
-GNU Compiler Collection (GCC)}). Wenn GCC und, sagen wir, die C-Bibliothek
-im Profil installiert sind, schlägt @code{--search-paths} also vor, diese
-Variablen jeweils auf @code{@var{profile}/include} und
-@code{@var{profile}/lib} verweisen zu lassen.
-Die typische Nutzung ist, in der Shell diese Variablen zu definieren:
-@example
-$ eval `guix package --search-paths`
-@end example
-Als @var{Art} kann entweder @code{exact}, @code{prefix} oder @code{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
-@var{Art} an, wird der Vorgabewert @code{exact} verwendet.
-Diese Befehlszeilenoption kann auch benutzt werden, um die
-@emph{kombinierten} Suchpfade mehrerer Profile zu berechnen. Betrachten Sie
-dieses Beispiel:
-@example
-$ guix package -p foo -i guile
-$ guix package -p bar -i guile-json
-$ guix package -p foo -p bar --search-paths
-@end example
-Der letzte Befehl oben meldet auch die Definition der Umgebungsvariablen
-@code{GUILE_LOAD_PATH}, obwohl für sich genommen weder @file{foo} noch
-@file{bar} zu dieser Empfehlung führen würden.
-@item --profile=@var{Profil}
-@itemx -p @var{Profil}
-Auf @var{Profil} anstelle des Standardprofils des Benutzers arbeiten.
-@cindex Kollisionen, in einem Profil
-@cindex Paketkollisionen in Profilen
-@cindex Profilkollisionen
-@item --allow-collisions
-Kollidierende Pakete im neuen Profil zulassen. Benutzung auf eigene Gefahr!
-Standardmäßig wird @command{guix package} @dfn{Kollisionen} als Fehler
-auffassen und melden. Zu Kollisionen kommt es, wenn zwei oder mehr
-verschiedene Versionen oder Varianten desselben Pakets im Profil landen.
-@item --bootstrap
-Erstellt das Profil mit dem Bootstrap-Guile. Diese Option ist nur für
-Entwickler der Distribution nützlich.
-@end table
-Zusätzlich zu diesen Aktionen unterstützt @command{guix package} folgende
-Befehlszeilenoptionen, um den momentanen Zustand eines Profils oder die
-Verfügbarkeit von Paketen nachzulesen:
-@table @option
-@item --search=@var{Regexp}
-@itemx -s @var{Regexp}
-@cindex Suche nach Paketen
-Führt alle verfügbaren Pakete auf, deren Name, Zusammenfassung oder
-Beschreibung zum regulären Ausdruck @var{Regexp} passt, ohne Groß- und
-Kleinschreibung zu unterscheiden und sortiert nach ihrer Relevanz. Alle
-Metadaten passender Pakete werden im @code{recutils}-Format geliefert (siehe
-@ref{Top, GNU recutils databases,, recutils, GNU recutils manual}).
-So können bestimmte Felder mit dem Befehl @command{recsel} extrahiert
-werden, zum Beispiel:
-@example
-$ 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
-@end example
-Ebenso kann der Name aller zu den Bedingungen der GNU@tie{}LGPL, Version 3,
-verfügbaren Pakete ermittelt werden:
-@example
-$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
-name: elfutils
-name: gmp
-@dots{}
-@end example
-Es ist auch möglich, Suchergebnisse näher einzuschränken, indem Sie
-@code{-s} mehrmals übergeben. Zum Beispiel liefert folgender Befehl eines
-Liste von Brettspielen:
-@example
-$ guix package -s '\<board\>' -s game | recsel -p name
-name: gnubg
-@dots{}
-@end example
-Würden wir @code{-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 @code{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:
-@example
-$ guix package -s crypto -s library | \
-    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
-@end example
-@noindent
-Siehe @ref{Selection Expressions,,, recutils, GNU recutils manual}, es
-enthält weitere Informationen über @dfn{Auswahlausdrücke} mit @code{recsel
-e}.
-@item --show=@var{Paket}
-Zeigt Details über das @var{Paket} aus der Liste verfügbarer Pakete, im
-@code{recutils}-Format (siehe @ref{Top, GNU recutils databases,, recutils,
-GNU recutils manual}).
-@example
-$ guix package --show=python | recsel -p name,version
-name: python
-version: 2.7.6
-name: python
-version: 3.3.5
-@end example
-Sie können auch den vollständigen Namen eines Pakets angeben, um Details nur
-über diese Version angezeigt zu bekommen:
-@example
-$ guix package --show=python@@3.4 | recsel -p name,version
-name: python
-version: 3.4.3
-@end example
-@item --list-installed[=@var{Regexp}]
-@itemx -I [@var{Regexp}]
-Listet die derzeit installierten Pakete im angegebenen Profil auf, die
-zuletzt installierten Pakete zuletzt. Wenn ein regulärer Ausdruck
-@var{Regexp} angegeben wird, werden nur installierte Pakete aufgeführt,
-deren Name zu @var{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 @code{out}, wenn die
-Standard-Paketausgabe installiert ist, @code{include}, wenn seine Header
-installiert sind, usw.)@: und an welchem Pfad das Paket im Store zu finden
-ist.
-@item --list-available[=@var{Regexp}]
-@itemx -A [@var{Regexp}]
-Listet Pakete auf, die in der aktuell installierten Distribution dieses
-Systems verfügbar sind (siehe @ref{GNU-Distribution}). Wenn ein regulärer
-Ausdruck @var{Regexp} angegeben wird, werden nur Pakete aufgeführt, deren
-Name zum regulären Ausdruck @var{Regexp} passt.
-Zu jedem Paket werden folgende Informationen getrennt durch Tabulatorzeichen
-ausgegeben: der Name, die Version als Zeichenkette, die Teile des Programms
-(siehe @ref{Pakete mit mehreren Ausgaben.}) und die Stelle im Quellcode, an
-der das Paket definiert ist.
-@item --list-generations[=@var{Muster}]
-@itemx -l [@var{Muster}]
-@cindex Generationen
-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 @ref{Pakete mit mehreren Ausgaben.}) und an welcher Stelle sich das Paket im Store
-befindet.
-Wenn ein @var{Muster} angegeben wird, liefert der Befehl nur dazu passende
-Generationen. Gültige Muster sind zum Beispiel:
-@itemize
-@item @emph{Ganze Zahlen und kommagetrennte ganze Zahlen}. Beide Muster bezeichnen
-Generationsnummern. Zum Beispiel liefert @code{--list-generations=1} die
-erste Generation.
-Durch @code{--list-generations=1,8,2} werden drei Generationen in der
-angegebenen Reihenfolge angezeigt. Weder Leerzeichen noch ein Komma am
-Schluss der Liste ist erlaubt.
-@item @emph{Bereiche}. @code{--list-generations=2..9} gibt die
-angegebenen Generationen und alles dazwischen aus. Beachten Sie, dass der
-Bereichsanfang eine kleinere Zahl als das Bereichsende sein muss.
-Sie können auch kein Bereichsende angeben, zum Beispiel liefert
-@code{--list-generations=2..} alle Generationen ab der zweiten.
-@item @emph{Zeitdauern}. Sie können auch die letzten @emph{N}@tie{}Tage, Wochen
-oder Monate angeben, indem Sie eine ganze Zahl gefolgt von jeweils »d«, »w«
-oder »m« angeben (dem ersten Buchstaben der Maßeinheit der Dauer im
-Englischen). Zum Beispiel listet @code{--list-generations=20d} die
-Generationen auf, die höchstens 20 Tage alt sind.
-@end itemize
-@item --delete-generations[=@var{Muster}]
-@itemx -d [@var{Muster}]
-Wird kein @var{Muster} angegeben, werden alle Generationen außer der
-aktuellen entfernt.
-Dieser Befehl akzeptiert dieselben Muster wie
-@option{--list-generations}. Wenn ein @var{Muster} angegeben wird, werden
-die passenden Generationen gelöscht. Wenn das @var{Muster} für eine
-Zeitdauer steht, werden diejenigen Generationen gelöscht, die @emph{älter}
-als die angegebene Dauer sind. Zum Beispiel löscht
-@code{--delete-generations=1m} die Generationen, die mehr als einen Monat
-alt sind.
-Falls die aktuelle Generation zum Muster passt, wird sie @emph{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.
-@end table
-Zu guter Letzt können Sie, da @command{guix package} Erstellungsprozesse zu
-starten vermag, auch alle gemeinsamen Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}) verwenden. Auch Paketumwandlungsoptionen wie
-@option{--with-source} sind möglich (siehe @ref{Paketumwandlungsoptionen}). Beachten Sie jedoch, dass die verwendeten
-Paketumwandlungsoptionen verloren gehen, nachdem Sie die Pakete aktualisiert
-haben. Damit Paketumwandlungen über Aktualisierungen hinweg erhalten
-bleiben, sollten Sie Ihre eigene Paketvariante in einem Guile-Modul
-definieren und zur Umgebungsvariablen @code{GUIX_PACKAGE_PATH} hinzufügen
-(siehe @ref{Pakete definieren}).
-@node Substitute
-@section Substitute
-@cindex Substitute
-@cindex vorerstellte Binärdateien
-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 @dfn{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 @ref{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.
-@menu
-* Offizieller Substitut-Server::  Eine besondere Quelle von Substituten.
-* Substitut-Server autorisieren::  Wie man Substitute an- und abschaltet.
-* Substitutauthentifizierung::  Wie Guix Substitute verifiziert.
-* Proxy-Einstellungen::      Wie Sie Substitute über einen Proxy beziehen.
-* Fehler bei der Substitution::  Was passiert, wenn die Substitution 
-                                   fehlschlägt.
-* Vom Vertrauen gegenüber Binärdateien::  Wie können Sie diesem binären 
-                                              Blob trauen?
-@end menu
-@node Offizieller Substitut-Server
-@subsection Offizieller Substitut-Server
-@cindex Hydra
-@cindex Build-Farm
-Der Server @code{@value{SUBSTITUTE-SERVER}} ist die Fassade für eine
-offizielle »Build-Farm«, ein Erstellungswerk, das kontinuierlich Guix-Pakete
-für einige Prozessorarchitekturen erstellt und sie als Substitute zur
-Verfügung stellt. Dies ist die standardmäßige Quelle von Substituten; durch
-Übergeben der Befehlszeilenoption @option{--substitute-urls} an entweder den
-@command{guix-daemon} (siehe @ref{daemon-substitute-urls,, @code{guix-daemon
--substitute-urls}}) oder Client-Werkzeuge wie @command{guix package} (siehe
-@ref{client-substitute-urls,, die Befehlszeilenoption
-@option{--substitute-urls} beim Client}) kann eine abweichende Einstellung
-benutzt werden.
-Substitut-URLs können entweder HTTP oder HTTPS sein. HTTPS wird empfohlen,
-weil die Kommunikation verschlüsselt ist; umgekehrt kann bei HTTP die
-Kommunikation belauscht werden, wodurch der Angreifer zum Beispiel erfahren
-könnte, ob Ihr System über noch nicht behobene Sicherheitsschwachstellen
-verfügt.
-Substitute von der offiziellen Build-Farm sind standardmäßig erlaubt, wenn
-Sie die Guix-System-Distribution verwenden (siehe @ref{GNU-Distribution}). Auf Fremddistributionen sind sie allerdings standardmäßig
-ausgeschaltet, solange Sie sie nicht ausdrücklich in einem der empfohlenen
-Installationsschritte erlaubt haben (siehe @ref{Installation}). Die
-folgenden Absätze beschreiben, wie Sie Substitute für die offizielle
-Build-Farm an- oder ausschalten; dieselbe Prozedur kann auch benutzt werden,
-um Substitute für einen beliebigen anderen Substitutsserver zu erlauben.
-@node Substitut-Server autorisieren
-@subsection Substitut-Server autorisieren
-@cindex Sicherheit
-@cindex Substitute, deren Autorisierung
-@cindex Access Control List (ACL), für Substitute
-@cindex ACL (Access Control List), für Substitute
-Um es Guix zu gestatten, Substitute von @code{@value{SUBSTITUTE-SERVER}}
-oder einem Spiegelserver davon herunterzuladen, müssen Sie den zugehörigen
-öffentlichen Schlüssel zur Access Control List (ACL,
-Zugriffssteuerungsliste) für Archivimporte hinzufügen, mit Hilfe des Befehls
-@command{guix archive} (siehe @ref{Aufruf von guix archive}). Dies impliziert,
-dass Sie darauf vertrauen, dass @code{@value{SUBSTITUTE-SERVER}} nicht
-kompromittiert wurde und echte Substitute liefert.
-Der öffentliche Schlüssel für @code{@value{SUBSTITUTE-SERVER}} wird zusammen
-mit Guix installiert, in das Verzeichnis
-@code{@var{prefix}/share/guix/hydra.gnu.org.pub}, wobei @var{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
-@file{guix-@value{VERSION}.tar.gz} prüfen, worin sich dieser öffentliche
-Schlüssel befindet. Dann können Sie so etwas wie hier ausführen:
-@example
-# guix archive --authorize < @var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub
-@end example
-@quotation Anmerkung
-Genauso enthält die Datei @file{hydra.gnu.org.pub} den öffentlichen
-Schlüssel für eine unabhängige Build-Farm, die auch vom Guix-Projekt
-betrieben wird. Sie ist unter @indicateurl{https://mirror.hydra.gnu.org}
-erreichbar ist.
-@end quotation
-Sobald es eingerichtet wurde, sollte sich die Ausgabe eines Befehls wie
-@code{guix build} von so etwas:
-@example
-$ 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
-@dots{}
-@end example
-@noindent
-in so etwas verwandeln:
-@example
-$ 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
-@dots{}
-@end example
-@noindent
-Das zeigt an, dass Substitute von @code{@value{SUBSTITUTE-SERVER}} nutzbar
-sind und für zukünftige Erstellungen heruntergeladen werden, wann immer es
-möglich ist.
-@cindex Substitute, wie man sie ausschaltet
-Der Substitutsmechanismus kann global ausgeschaltet werden, indem Sie dem
-@code{guix-daemon} beim Starten die Befehlszeilenoption
-@code{--no-substitutes} übergeben (siehe @ref{Aufruf des guix-daemon}). Er
-kann auch temporär ausgeschaltet werden, indem Sie @code{--no-substitutes}
-an @command{guix package}, @command{guix build} und andere
-Befehlszeilenwerkzeuge übergeben.
-@node Substitutauthentifizierung
-@subsection Substitutauthentifizierung
-@cindex digitale Signaturen
-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 @emph{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:
-@example
--substitute-urls="https://a.example.org https://b.example.org"
-@end example
-@noindent
-@cindex Reproduzierbare Erstellungen
-Wenn in der ACL nur der Schlüssel für @code{b.example.org} aufgeführt wurde,
-aber @code{a.example.org} @emph{exakt dieselben} Substitute anbietet, wird
-Guix auch Substitute von @code{a.example.org} herunterladen, weil es in der
-Liste zuerst kommt und als Spiegelserver für @code{b.example.org} aufgefasst
-werden kann. In der Praxis haben unabhängige Maschinen bei der Erstellung
-normalerweise dieselben Binärdateien als Ergebnis, dank bit-reproduzierbarer
-Erstellungen (siehe unten).
-Wenn Sie HTTPS benutzen, wird das X.509-Zertifikat des Servers @emph{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).
-@node Proxy-Einstellungen
-@subsection Proxy-Einstellungen
-@vindex http_proxy
-Substitute werden über HTTP oder HTTPS heruntergeladen. Die
-Umgebungsvariable @code{http_proxy} kann in der Umgebung von
-@command{guix-daemon} definiert werden und wirkt sich dann auf das
-Herunterladen von Substituten aus. Beachten Sie, dass der Wert von
-@code{http_proxy} in der Umgebung, in der @command{guix build},
-@command{guix package} und andere Client-Befehle ausgeführt werden,
-@emph{keine Rolle spielt}.
-@node Fehler bei der Substitution
-@subsection Fehler bei der Substitution
-Selbst wenn ein Substitut für eine Ableitung verfügbar ist, schlägt die
-versuchte Substitution manchmal fehl. Das kann aus vielen Gründen geschehen:
-die Substitutsserver könnten offline sein, das Substitut könnte kürzlich
-gelöscht worden sein, die Netzwerkverbindunge könnte unterbrochen worden
-sein, usw.
-Wenn Substitute aktiviert sind und ein Substitut für eine Ableitung zwar
-verfügbar ist, aber die versuchte Substitution fehlschlägt, kann Guix
-versuchen, die Ableitung lokal zu erstellen, je nachdem, ob
-@code{--fallback} übergeben wurde (siehe @ref{fallback-option,, common build
-option @code{--fallback}}). Genauer gesagt, wird keine lokale Erstellung
-durchgeführt, solange kein @code{--fallback} angegeben wurde, und die
-Ableitung wird als Fehlschlag angesehen. Wenn @code{--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, @emph{immer} eine
-lokale Erstellung durchgeführt wird, egal ob @code{--fallback} übergeben
-wurde oder nicht.
-Um eine Vorstellung zu bekommen, wieviele Substitute gerade verfügbar sind,
-können Sie den Befehl @command{guix weather} benutzen (siehe @ref{Aufruf von guix weather}). Dieser Befehl zeigt Statistiken darüber an, wie es um die
-von einem Server verfügbaren Substitute steht.
-@node Vom Vertrauen gegenüber Binärdateien
-@subsection Vom Vertrauen gegenüber Binärdateien
-@cindex Vertrauen, gegenüber vorerstellten Binärdateien
-Derzeit hängt die Kontrolle jedes Individuums über seine Rechner von
-Institutionen, Unternehmen und solchen Gruppierungen ab, die über genug
-Macht und Entschlusskraft verfügen, die Rechnerinfrastruktur zu sabotieren
-und ihre Schwachstellen auszunutzen. Auch wenn es bequem ist, Substitute von
-@code{@value{SUBSTITUTE-SERVER}} zu benutzen, ermuntern wir Nutzer, auch
-selbst Erstellungen durchzuführen oder gar ihre eigene Build-Farm zu
-betreiben, damit @code{@value{SUBSTITUTE-SERVER}} ein weniger interessantes
-Ziel wird. Eine Art, uns zu helfen, ist, die von Ihnen erstellte Software
-mit dem Befehl @command{guix publish} zu veröffentlichen, damit andere eine
-größere Auswahl haben, von welchem Server sie Substitute beziehen möchten
-(siehe @ref{Aufruf von guix publish}).
-Guix hat die richtigen Grundlagen, um die Reproduzierbarkeit von
-Erstellungen zu maximieren (siehe @ref{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 @command{guix challenge}
-hat das Ziel, Nutzern zu ermöglichen, Substitutserver zu beurteilen, und
-Entwickler dabei zu unterstützen, nichtdeterministische Paketerstellungen zu
-finden (siehe @ref{Aufruf von guix challenge}). Ebenso ermöglicht es die
-Befehlszeilenoption @option{--check} von @command{guix build}, dass Nutzer
-bereits installierte Substitute auf Echtheit zu prüfen, indem sie lokal
-nachgebaut werden (siehe @ref{build-check, @command{guix build --check}}).
-In Zukunft wollen wir, dass Guix Binärdateien an und von Nutzern
-peer-to-peer veröffentlichen kann. Wenn Sie mit uns dieses Projekt
-diskutieren möchten, kommen Sie auf unsere Mailing-Liste
-@email{guix-devel@@gnu.org}.
-@node Pakete mit mehreren Ausgaben.
-@section Pakete mit mehreren Ausgaben.
-@cindex mehrere Ausgaben, bei Paketen
-@cindex Paketausgaben
-@cindex Ausgaben
-Oft haben in Guix definierte Pakete eine einzige @dfn{Ausgabe} — d.h.@: aus
-dem Quellpaket entsteht genau ein Verzeichnis im Store. Wenn Sie
-@command{guix package -i glibc} ausführen, wird die Standard-Paketausgabe
-des GNU-libc-Pakets installiert; die Standardausgabe wird @code{out}
-genannt, aber ihr Name kann weggelassen werden, wie sie an obigem Befehl
-sehen. In diesem speziellen Fall enthält die Standard-Paketausgabe von
-@code{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
-@code{doc}. Um also die Hauptausgabe von GLib zu installieren, zu der alles
-außer der Dokumentation gehört, ist der Befehl:
-@example
-guix package -i glib
-@end example
-@cindex Dokumentation
-Der Befehl, um die Dokumentation zu installieren, ist:
-@example
-guix package -i glib:doc
-@end example
-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 @command{guix size} kann dabei helfen, solche Situationen zu erkennen
-(siehe @ref{Aufruf von guix size}). @command{guix graph} kann auch helfen
-(siehe @ref{Aufruf von guix graph}).
-In der GNU-Distribution gibt es viele solche Pakete mit mehreren
-Ausgaben. Andere Konventionen für Ausgabenamen sind zum Beispiel @code{lib}
-für Bibliotheken und eventuell auch ihre Header-Dateien,, @code{bin} für
-eigenständige Programme und @code{debug} für Informationen zur
-Fehlerbehandlung (siehe @ref{Dateien zur Fehlersuche installieren}). Die Ausgaben
-eines Pakets stehen in der dritten Spalte der Anzeige von @command{guix
-package --list-available} (siehe @ref{Aufruf von guix package}).
-@node Aufruf von guix gc
-@section @command{guix gc} aufrufen
-@cindex Müllsammler
-@cindex Plattenspeicher
-Pakete, die zwar installiert sind, aber nicht benutzt werden, können vom
-@dfn{Müllsammler} entfernt werden. Mit dem Befehl @command{guix gc} können
-Benutzer den Müllsammler ausdrücklich aufrufen, um Speicher im Verzeichnis
-@file{/gnu/store} freizugeben. Dies ist der @emph{einzige} Weg, Dateien aus
-@file{/gnu/store} zu entfernen — das manuelle Entfernen von Dateien kann den
-Store irreparabel beschädigen!
-@cindex GC-Wurzeln
-@cindex Müllsammlerwurzeln
-Der Müllsammler kennt eine Reihe von @dfn{Wurzeln}: Jede Datei in
-@file{/gnu/store}, die von einer Wurzel aus erreichbar ist, gilt als
-@dfn{lebendig} und kann nicht entfernt werden; jede andere Datei gilt als
-@dfn{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
-@file{/var/guix/gcroots} dargestellt. Neue Müllsammlerwurzeln können zum
-Beispiel mit @command{guix build --root} festgelegt werden (siehe
-@ref{Aufruf von guix build}). Der Befehl @command{guix gc --list-roots} listet
-sie auf.
-Bevor Sie mit @code{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 @code{guix package --delete-generations} aus (siehe @ref{Aufruf von guix package}).
-Unsere Empfehlung ist, dass Sie den Müllsammler regelmäßig laufen lassen und
-wenn Sie wenig freien Speicherplatz zur Verfügung haben. Um zum Beispiel
-sicherzustellen, dass Sie mindestens 5@tie{}GB auf Ihrer Platte zur
-Verfügung haben, benutzen Sie einfach:
-@example
-guix gc -F 5G
-@end example
-Es ist völlig sicher, dafür eine nicht interaktive, regelmäßige
-Auftragsausführung vorzugeben (siehe @ref{Geplante Auftragsausführung} für eine
-Erklärung, wie man das tun kann). @command{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 @command{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
-@code{--delete}), um Müllsammlerinformationen auszugeben oder
-fortgeschrittenere Anfragen zu verarbeiten. Die
-Müllsammler-Befehlszeilenoptionen sind wie folgt:
-@table @code
-@item --collect-garbage[=@var{Minimum}]
-@itemx -C [@var{Minimum}]
-Lässt Müll sammeln — z.B.@: nicht erreichbare Dateien in @file{/gnu/store}
-und seinen Unterverzeichnissen. Wird keine andere Befehlszeilenoption
-angegeben, wird standardmäßig diese durchgeführt.
-Wenn ein @var{Minimum} angegeben wurde, hört der Müllsammler auf, sobald
-@var{Minimum} Bytes gesammelt wurden. Das @var{Minimum} kann die Anzahl der
-Bytes bezeichnen oder mit einer Einheit als Suffix versehen sein, wie etwa
-@code{MiB} für Mebibytes und @code{GB} für Gigabytes (siehe @ref{Block size,
-size specifications,, coreutils, GNU Coreutils}).
-Wird kein @var{Minimum} angegeben, sammelt der Müllsammler allen Müll.
-@item --free-space=@var{Menge}
-@itemx -F @var{Menge}
-Sammelt Müll, bis die angegebene @var{Menge} an freiem Speicher in
-@file{/gnu/store} zur Verfügung steht, falls möglich; die @var{Menge} ist
-eine Speichergröße wie @code{500MiB}, wie oben beschrieben.
-Wenn die angegebene  @var{Menge} oder mehr bereits in @file{/gnu/store} frei
-verfügbar ist, passiert nichts.
-@item --delete-generations[=@var{Dauer}]
-@itemx -d [@var{Dauer}]
-Bevor der Müllsammelvorgang beginnt, werden hiermit alle Generationen von
-allen Benutzerprofilen gelöscht, die älter sind als die angegebene
-@var{Dauer}; wird es als Administratornutzer »root« ausgeführt, geschieht
-dies mit den Profilen @emph{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:
-@example
-guix gc -d 2m -F 10G
-@end example
-@item --delete
-@itemx -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.
-@item --list-failures
-Store-Objekte auflisten, die zwischengespeicherten Erstellungsfehlern
-entsprechen.
-Hierbei wird nichts ausgegeben, sofern der Daemon nicht mit
-@option{--cache-failures} gestartet wurde (siehe @ref{Aufruf des guix-daemon,
-@option{--cache-failures}}).
-@item --list-roots
-Die Müllsammlerwurzeln auflisten, die dem Nutzer gehören. Wird der Befehl
-als Administratornutzer ausgeführt, werden @emph{alle} Müllsammlerwurzeln
-aufgelistet.
-@item --clear-failures
-Die angegebenen Store-Objekte aus dem Zwischenspeicher für fehlgeschlagene
-Erstellungen entfernen.
-Auch diese Option macht nur Sinn, wenn der Daemon mit
-@option{--cache-failures} gestartet wurde. Andernfalls passiert nichts.
-@item --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.
-@item --list-live
-Zeige die Liste lebendiger Store-Dateien und -Verzeichnisse.
-@end table
-Außerdem können Referenzen unter bestehenden Store-Dateien gefunden werden:
-@table @code
-@item --references
-@itemx --referrers
-@cindex Paketabhängigkeiten
-Listet die referenzierten bzw. sie referenzierenden Objekte der angegebenen
-Store-Dateien auf.
-@item --requisites
-@itemx -R
-@cindex Abschluss
-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 @dfn{transitive Abschluss} dieser Store-Dateien.
-Der Abschnitt @ref{Aufruf von guix size} erklärt ein Werkzeug, um den
-Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe
-@ref{Aufruf von guix graph} für ein Werkzeug, um den Referenzgraphen zu
-veranschaulichen.
-@item --derivers
-@cindex Ableitung
-Liefert die Ableitung(en), die zu den angegebenen Store-Objekten führen
-(siehe @ref{Ableitungen}).
-Zum Beispiel liefert dieser Befehl:
-@example
-guix gc --derivers `guix package -I ^emacs$ | cut -f4`
-@end example
-@noindent
-die @file{.drv}-Datei(en), die zum in Ihrem Profil installierten
-@code{emacs}-Paket führen.
-Beachten Sie, dass es auch sein kann, dass keine passenden
-@file{.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 @file{.drv} gibt, bei Ableitungen mit fester Ausgabe.
-@end table
-Zuletzt können Sie mit folgenden Befehlszeilenoptionen die Integrität des
-Stores prüfen und den Plattenspeicherverbrauch im Zaum halten.
-@table @option
-@item --verify[=@var{Optionen}]
-@cindex Integrität, des Stores
-@cindex Integritätsprüfung
-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
-@file{/gnu/store} existieren.
-Wenn angegeben, müssen die @var{Optionen} eine kommagetrennte Liste aus
-mindestens einem der Worte @code{contents} und @code{repair} sein.
-Wenn Sie @option{--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 @emph{alle Dateien im Store} durchlaufen werden, kann
-der Befehl viel Zeit brauchen, besonders auf Systemen mit langsamer Platte.
-@cindex Store, reparieren
-@cindex Datenbeschädigung, Behebung
-Mit @option{--verify=repair} oder @option{--verify=contents,repair} versucht
-der Daemon, beschädigte Store-Objekte zu reparieren, indem er Substitute für
-selbige herunterlädt (siehe @ref{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, @command{guix build --repair} zu
-benutzen (siehe @ref{Aufruf von guix build}).
-@item --optimize
-@cindex Deduplizieren
-Den Store durch Nutzung harter Verknüpfungen für identische Dateien
-optimieren — mit anderen Worten wird der Store @dfn{dedupliziert}.
-Der Daemon führt Deduplizierung automatisch nach jeder erfolgreichen
-Erstellung und jedem Importieren eines Archivs durch, sofern er nicht mit
-@code{--disable-deduplication} (siehe @ref{Aufruf des guix-daemon,
-@code{--disable-deduplication}}) gestartet wurde. Diese Befehlszeilenoption
-brauchen Sie also in erster Linie dann, wenn der Daemon zuvor mit
-@code{--disable-deduplication} gestartet worden ist.
-@end table
-@node Aufruf von guix pull
-@section @command{guix pull} aufrufen
-@cindex Aktualisieren von Guix
-@cindex Updaten von Guix
-@cindex @command{guix pull}
-@cindex pull
-Nach der Installation oder Aktualisierung wird stets die neueste Version von
-Paketen verwendet, die in der aktuell installierten Distribution verfügbar
-ist. Um die Distribution und die Guix-Werkzeuge zu aktualisieren, führen Sie
-@command{guix pull} aus. Der Befehl lädt den neuesten Guix-Quellcode
-einschließlich Paketbeschreibungen herunter und installiert ihn. Quellcode
-wird aus einem @uref{https://git-scm.com, Git}-Repository geladen,
-standardmäßig dem offiziellen Repository von GNU@tie{}Guix, was Sie aber
-auch ändern können.
-Danach wird @command{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 @command{guix}-Unterbefehle, die durch die Aktualisierung
-hinzugekommen sind, werden also auch verfügbar.
-Jeder Nutzer kann seine Kopie von Guix mittels @command{guix pull}
-aktualisieren, wodurch sich nur für den Nutzer etwas verändert, der
-@command{guix pull} ausgeführt hat. Wenn also zum Beispiel der
-Administratornutzer @code{root} den Befehl @command{guix pull} ausführt, hat
-das keine Auswirkungen auf die für den Benutzer @code{alice} sichtbare
-Guix-Version, und umgekehrt.
-Das Ergebnis von @command{guix pull} ist ein als
-@file{~/.config/guix/current} verfügbares @dfn{Profil} mit dem neuesten
-Guix. Stellen Sie sicher, dass es am Anfang Ihres Suchpfades steht, damit
-Sie auch wirklich das neueste Guix und sein Info-Handbuch sehen (siehe
-@ref{Dokumentation}):
-@example
-export PATH="$HOME/.config/guix/current/bin:$PATH"
-export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
-@end example
-Die Befehlszeilenoption @code{--list-generations} oder kurz @code{-l} listet
-ältere von @command{guix pull} erzeugte Generationen auf, zusammen mit
-Informationen zu deren Provenienz.
-@example
-$ guix pull -l
-Generation 1    Jun 10 2018 00:18:18
-  guix 65956ad
-    repository URL: https://git.savannah.gnu.org/git/guix.git
-    branch: origin/master
-    commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe
-Generation 2    Jun 11 2018 11:02:49
-  guix e0cc7f6
-    repository URL: https://git.savannah.gnu.org/git/guix.git
-    branch: origin/master
-    commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d
-  2 new packages: keepalived, libnfnetlink
-  6 packages upgraded: emacs-nix-mode@@2.0.4,
-    guile2.0-guix@@0.14.0-12.77a1aac, guix@@0.14.0-12.77a1aac,
-    heimdal@@7.5.0, milkytracker@@1.02.00, nix@@2.0.4
-Generation 3    Jun 13 2018 23:31:07    (current)
-  guix 844cc1c
-    repository URL: https://git.savannah.gnu.org/git/guix.git
-    branch: origin/master
-    commit: 844cc1c8f394f03b404c5bb3aee086922373490c
-  28 new packages: emacs-helm-ls-git, emacs-helm-mu, @dots{}
-  69 packages upgraded: borg@@1.1.6, cheese@@3.28.0, @dots{}
-@end example
-Im Abschnitt @ref{Aufruf von guix describe, @command{guix describe}} werden
-andere Möglichkeiten erklärt, sich den momentanen Zustand von Guix
-beschreiben zu lassen.
-Das Profil @code{~/.config/guix/current} verhält sich genau wie jedes andere
-Profil, das von @command{guix package} erzeugt wurde (siehe @ref{Aufruf von guix package}). Das bedeutet, Sie können seine Generationen auflisten und es
-auf die vorherige Generation — also das vorherige Guix — zurücksetzen und so
-weiter:
-@example
-$ 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
-@end example
-Der Befehl @command{guix pull} wird in der Regel ohne Befehlszeilenargumente
-aufgerufen, aber er versteht auch folgende Befehlszeilenoptionen:
-@table @code
-@item --url=@var{URL}
-@itemx --commit=@var{Commit}
-@itemx --branch=@var{Branch}
-Download code for the @code{guix} channel from the specified @var{url}, at
-the given @var{commit} (a valid Git commit ID represented as a hexadecimal
-string), or @var{branch}.
-@cindex @file{channels.scm}, Konfigurationsdatei
-@cindex Konfigurationsdatei für Kanäle
-Diese Befehlszeilenoptionen sind manchmal bequemer, aber Sie können Ihre
-Konfiguration auch in der Datei @file{~/.config/guix/channels.scm} oder über
-die Option @option{--channels} angeben (siehe unten).
-@item --channels=@var{Datei}
-@itemx -C @var{Datei}
-Die Liste der Kanäle aus der angegebenen @var{Datei} statt aus
-@file{~/.config/guix/channels.scm} auslesen. Die @var{Datei} muss
-Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet
-wird. Siehe @ref{Kanäle} für nähere Informationen.
-@item --list-generations[=@var{Muster}]
-@itemx -l [@var{Muster}]
-Alle Generationen von @file{~/.config/guix/current} bzw., wenn ein
-@var{Muster} angegeben wird, die dazu passenden Generationen auflisten. Die
-Syntax für das @var{Muster} ist dieselbe wie bei @code{guix package
--list-generations} (siehe @ref{Aufruf von guix package}).
-Im Abschnitt @ref{Aufruf von guix describe, @command{guix describe}} wird eine
-Möglichkeit erklärt, sich Informationen nur über die aktuelle Generation
-anzeigen zu lassen.
-@item --profile=@var{Profil}
-@itemx -p @var{Profil}
-Auf @var{Profil} anstelle von @file{~/.config/guix/current} arbeiten.
-@item --dry-run
-@itemx -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.
-@item --system=@var{System}
-@itemx -s @var{System}
-Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu
-erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die
-Erstellung durchführt.
-@item --verbose
-Ausführliche Informationen ausgeben und Erstellungsprotokolle auf der
-Standardfehlerausgabe ausgeben.
-@item --bootstrap
-Das neueste Guix mit dem Bootstrap-Guile erstellen. Diese
-Befehlszeilenoption ist nur für Guix-Entwickler von Nutzen.
-@end table
-Mit Hilfe von @dfn{Kanälen} können Sie bei @command{guix pull} anweisen, von
-welchem Repository und welchem Branch Guix aktualisiert werden soll, sowie
-von welchen @emph{weiteren} Repositorys Paketmodule bezogen werden
-sollen. Im Abschnitt @ref{Kanäle} finden Sie nähere Informationen.
-Außerdem unterstützt @command{guix pull} alle gemeinsamen
-Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}).
-@node Kanäle
-@section Kanäle
-@cindex Kanäle
-@cindex @file{channels.scm}, Konfigurationsdatei
-@cindex Konfigurationsdatei für Kanäle
-@cindex @command{guix pull}, Konfigurationsdatei
-@cindex Konfiguration von @command{guix pull}
-Guix und die Sammlung darin verfügbarer Pakete können Sie durch Ausführen
-von @command{guix pull} aktualisieren (siehe @ref{Aufruf von guix pull}). Standardmäßig lädt @command{guix pull} Guix selbst vom offiziellen
-Repository von GNU@tie{}Guix herunter und installiert es. Diesen Vorgang
-können Sie anpassen, indem Sie @dfn{Kanäle} in der Datei
-@file{~/.config/guix/channels.scm} angeben. Ein Kanal enthält eine Angabe
-einer URL und eines Branches eines zu installierenden Git-Repositorys und
-Sie können @command{guix pull} veranlassen, die Aktualisierungen von einem
-oder mehreren Kanälen zu beziehen. Mit anderen Worten können Kanäle benutzt
-werden, um Guix @emph{anzupassen} und zu @emph{erweitern}, wie wir im
-Folgenden sehen werden.
-@subsection Einen eigenen Guix-Kanal benutzen
-Der Kanal namens @code{guix} gibt an, wovon Guix selbst — seine
-Befehlszeilenwerkzeuge und seine Paketsammlung — heruntergeladen werden
-sollten. Wenn Sie zum Beispiel mit Ihrer eigenen Kopie des Guix-Repositorys
-arbeiten möchten und diese auf @code{example.org} zu finden ist, und zwar im
-Branch namens @code{super-hacks}, dann schreiben Sie folgende Spezifikation
-in @code{~/.config/guix/channels.scm}:
-@lisp
-;; 'guix pull' mein eigenes Repository benutzen lassen.
-(list (channel
-        (name 'guix)
-        (url "https://example.org/my-guix.git")
-        (branch "super-hacks")))
-@end lisp
-@noindent
-Ab dann wird @command{guix pull} seinen Code vom Branch @code{super-hacks}
-des Repositorys auf @code{example.org} beziehen.
-@subsection Weitere Kanäle angeben
-@cindex Paketsammlung erweitern (Kanäle)
-@cindex Eigene Pakete (Kanäle)
-@cindex Kanäle, für eigene Pakete
-Sie können auch @emph{weitere Kanäle} als Bezugsquelle angeben. Sagen wir,
-Sie haben ein paar eigene Paketvarianten oder persönliche Pakete, von denen
-Sie meinen, dass sie @emph{nicht} geeignet sind, ins Guix-Projekt selbst
-aufgenommen zu werden, die Ihnen aber dennoch wie andere Pakete auf der
-Befehlszeile zur Verfügung stehen sollen. Dann würden Sie zunächst Module
-mit diesen Paketdefinitionen schreiben (siehe @ref{Paketmodule}) und
-diese dann in einem Git-Repository verwalten, welches Sie selbst oder jeder
-andere dann als zusätzlichen Kanal eintragen können, von dem Pakete geladen
-werden. Klingt gut, oder?
-@c What follows stems from discussions at
-@c <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629#134> as well as
-@c earlier discussions on guix-devel@gnu.org.
-@quotation Warnung
-Bevor Sie, verehrter Nutzer, ausrufen: »Wow, das ist @emph{soooo coool}!«,
-und Ihren eigenen Kanal der Welt zur Verfügung stellen, möchten wir Ihnen
-auch ein paar Worte der Warnung mit auf den Weg geben:
-@itemize
-@item
-Bevor Sie einen Kanal veröffentlichen, überlegen Sie sich bitte erst, ob Sie
-die Pakete nicht besser zum eigentlichen Guix-Projekt beisteuern (siehe
-@ref{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.
-@item
-Wenn Sie Paketdefinitionen außerhalb von Guix betreuen, sehen wir
-Guix-Entwickler es als @emph{Ihre Aufgabe an, deren Kompatibilität
-sicherzstellen}. Bedenken Sie, dass Paketmodule und Paketdefinitionen nur
-Scheme-Code sind, der verschiedene Programmierschnittstellen (APIs)
-benutzt. Wir nehmen uns das Recht heraus, diese APIs jederzeit zu ändern,
-damit wir Guix besser machen können, womöglich auf eine Art, wodurch Ihr
-Kanal nicht mehr funktioniert. Wir ändern APIs nie einfach so, werden aber
-auch @emph{nicht} versprechen, APIs nicht zu verändern.
-@item
-Das bedeutet auch, dass Sie, wenn Sie einen externen Kanal verwenden und
-dieser kaputt geht, Sie dies bitte @emph{den Autoren des Kanals} und nicht
-dem Guix-Projekt melden.
-@end itemize
-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
-@uref{https://www.gnu.org/philosophy/free-sw.html, freier Software}
-entspricht. Bitte schicken Sie eine E-Mail an @email{guix-devel@@gnu.org},
-wenn Sie dies diskutieren möchten.
-@end quotation
-Um einen Kanal zu benutzen, tragen Sie ihn in
-@code{~/.config/guix/channels.scm} ein, damit @command{guix pull} diesen
-Kanal @emph{zusätzlich} zu den standardmäßigen Guix-Kanälen als Paketquelle
-verwendet:
-@vindex %default-channels
-@lisp
-;; Meine persönlichen Pakete zu denen von Guix dazunehmen.
-(cons (channel
-        (name 'meine-persönlichen-pakete)
-        (url "https://example.org/personal-packages.git"))
-      %default-channels)
-@end lisp
-@noindent
-Beachten Sie, dass der obige Schnipsel (wie immer!)@: Scheme-Code ist; mit
-@code{cons} fügen wir einen Kanal zur Liste der Kanäle hinzu, an die die
-Variable @code{%default-channels} gebunden ist (siehe @ref{Pairs,
-@code{cons} and lists,, guile, GNU Guile Reference Manual}). Mit diesem
-Dateiinhalt wird @command{guix pull} nun nicht mehr nur Guix, sondern auch
-die Paketmodule aus Ihrem Repository erstellen. Das Ergebnis in
-@file{~/.config/guix/current} ist so die Vereinigung von Guix und Ihren
-eigenen Paketmodulen.
-@example
-$ guix pull --list-generations
-@dots{}
-Generation 19   Aug 27 2018 16:20:48
-  guix d894ab8
-    repository URL: https://git.savannah.gnu.org/git/guix.git
-    branch: master
-    commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
-  meine-persönlichen-pakete dd3df5e
-    repository URL: https://example.org/personal-packages.git
-    branch: master
-    commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
-  11 new packages: mein-gimp, mein-emacs-mit-coolen-features, @dots{}
-  4 packages upgraded: emacs-racket-mode@@0.0.2-2.1b78827, @dots{}
-@end example
-@noindent
-Obige Ausgabe von @command{guix pull} zeigt an, dass Generation@tie{}19
-sowohl Guix als auch Pakete aus dem Kanal @code{meine-persönlichen-pakete}
-enthält. Unter den aufgeführten neuen und aktualisierten Paketen kommen
-vielleicht manche wie @code{mein-gimp} und
-@code{mein-emacs-mit-coolen-features} aus @code{meine-persönlichen-pakete},
-während andere aus dem Standard-Guix-Kanal kommen.
-Um einen Kanal zu erzeugen, müssen Sie ein Git-Repository mit Ihren eigenen
-Paketmodulen erzeugen und den Zugriff darauf ermöglichen. Das Repository
-kann beliebigen Inhalt haben, aber wenn es ein nützlicher Kanal sein soll,
-muss es Guile-Module enthalten, die Pakete exportieren. Sobald Sie anfangen,
-einen Kanal zu benutzen, verhält sich Guix, als wäre das Wurzelverzeichnis
-des Git-Repositorys des Kanals in Guiles Ladepfad enthalten (siehe @ref{Load
-Paths,,, guile, GNU Guile Reference Manual}). Wenn Ihr Kanal also zum
-Beispiel eine Datei als @file{my-packages/my-tools.scm} enthält, die ein
-Guile-Modul definiert, dann wird das Modul unter dem Namen
-@code{(my-packages my-tools)} verfügbar sein und Sie werden es wie jedes
-andere Modul benutzen können (siehe @ref{Module,,, guile, GNU Guile
-Reference Manual}).
-@cindex Abhängigkeiten, bei Kanälen
-@cindex Metadaten, bei Kanälen
-@subsection Kanalabhängigkeiten deklarieren
-Kanalautoren können auch beschließen, die Paketsammlung von anderen Kanälen
-zu erweitern. Dazu können sie in einer Metadatendatei @file{.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:
-@lisp
-(channel
- (version 0)
- (dependencies
-  (channel
-   (name irgendeine-sammlung)
-   (url "https://example.org/erste-sammlung.git"))
-  (channel
-   (name eine-andere-sammlung)
-   (url "https://example.org/zweite-sammlung.git")
-   (branch "testing"))))
-@end lisp
-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, sollen 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.
-@subsection Guix nachbilden
-@cindex Festsetzen, bei Kanälen
-@cindex Nachbilden von Guix
-@cindex Reproduzierbarkeit von Guix
-Die Ausgabe von @command{guix pull --list-generations} oben zeigt genau, aus
-welchen Commits diese Guix-Instanz erstellt wurde. Wir können Guix so zum
-Beispiel auf einer anderen Maschine nachbilden, indem wir eine
-Kanalspezifikation in @file{~/.config/guix/channels.scm} angeben, die auf
-diese Commits »festgesetzt« ist.
-@lisp
-;; Ganz bestimmte Commits der relevanten Kanäle installieren.
-(list (channel
-       (name 'guix)
-       (url "https://git.savannah.gnu.org/git/guix.git")
-       (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300"))
-      (channel
-       (name 'meine-persönlichen-pakete)
-       (url "https://example.org/personal-packages.git")
-       (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))
-@end lisp
-Der Befehl @command{guix describe --format=channels} kann diese Kanalliste
-sogar direkt erzeugen (siehe @ref{Aufruf von guix describe}).
-Somit läuft auf beiden Maschinen @emph{genau dasselbe Guix} und es hat
-Zugang zu @emph{genau denselben Paketen}. Die Ausgabe von @command{guix
-build gimp} auf der einen Maschine wird Bit für Bit genau dieselbe wie die
-desselben Befehls auf der anderen Maschine sein. Das bedeutet auch, dass
-beide Maschinen Zugang zum gesamten Quellcode von Guix und daher auch
-transitiv Zugang zum Quellcode jedes davon definierten Pakets haben.
-Das verleiht Ihnen Superkräfte, mit denen Sie die Provenienz binärer
-Artefakte sehr feinkörnig nachverfolgen können und Software-Umgebungen nach
-Belieben nachbilden können. Sie können es als eine Art Fähigkeit zur
-»Meta-Reproduzierbarkeit« auffassen, wenn Sie möchten. Der Abschnitt
-@ref{Untergeordnete} beschreibt eine weitere Möglichkeit, diese Superkräfte zu
-nutzen.
-@node Untergeordnete
-@section Untergeordnete
-@c TODO: Remove this once we're more confident about API stability.
-@quotation Anmerkung
-Die hier beschriebenen Funktionalitäten sind in der Version @value{VERSION}
-bloß eine »Technologie-Vorschau«, daher kann sich die Schnittstelle in
-Zukunft noch ändern.
-@end quotation
-@cindex Untergeordnete
-@cindex Mischen von Guix-Versionen
-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-@dfn{Untergeordnete} ermöglichen dies, indem Sie verschiedene
-Guix-Versionen beliebig mischen können.
-@cindex untergeordnete Pakete
-Aus technischer Sicht ist ein »Untergeordneter« im Kern ein separater
-Guix-Prozess, der über eine REPL (siehe @ref{Aufruf von guix repl}) mit Ihrem
-Haupt-Guix-Prozess verbunden ist. Das Modul @code{(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 — @dfn{untergeordnete Pakete}.
-In Kombination mit Kanälen (siehe @ref{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
-@code{guile}-Paket in Ihr Profil installieren, zusammen mit dem
-@code{guile-json}, wie es in einer früheren Guix-Version existiert hat —
-vielleicht weil das neuere @code{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 @code{guix package --manifest} schreiben (siehe
-@ref{Aufruf von guix package}); in diesem Manifest würden Sie einen
-Untergeordneten für diese alte Guix-Version erzeugen, für die Sie sich
-interessieren, und aus diesem Untergeordneten das @code{guile-json}-Paket
-holen:
-@lisp
-(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")))
-@end lisp
-Bei seiner ersten Ausführung könnte für @command{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 @code{(guix inferior)} angeboten, um
-einen Untergeordneten zu öffnen:
-@deffn {Scheme-Prozedur} inferior-for-channels @var{Kanäle} @
-   [#:cache-directory] [#:ttl] Liefert einen Untergeordneten für die
-@var{Kanäle}, einer Liste von Kanälen. Dazu wird der Zwischenspeicher im
-Verzeichnis @var{cache-directory} benutzt, dessen Einträge nach @var{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 @var{Kanäle}, was einige Zeit in Anspruch nehmen kann.
-@end deffn
-@deffn {Scheme-Prozedur} open-inferior @var{Verzeichnis} @
-  [#:command "bin/guix"] Öffnet das untergeordnete Guix mit dem Befehl
-@var{command} im angegebenen @var{Verzeichnis} durch Ausführung von
-@code{@var{Verzeichnis}/@var{command} repl} oder entsprechend. Liefert
-@code{#f}, wenn der Untergeordnete nicht gestartet werden konnte.
-@end deffn
-@cindex untergeordnete Pakete
-Die im Folgenden aufgeführten Prozeduren ermöglichen es Ihnen,
-untergeordnete Pakete abzurufen und zu verändern.
-@deffn {Scheme-Prozedur} inferior-packages @var{Untergeordneter}
-Liefert die Liste der Pakete in @var{Untergeordneter}.
-@end deffn
-@deffn {Scheme-Prozedur} lookup-inferior-packages @var{Untergeordneter} @var{Name} @
-   [@var{Version}] Liefert die sortierte Liste der untergeordneten Pakete in
-@var{Untergeordneter}, die zum Muster @var{Name} in @var{Untergeordneter}
-passen, dabei kommen höhere Versionsnummern zuerst. Wenn @var{Version} auf
-wahr gesetzt ist, werden nur Pakete geliefert, deren Versionsnummer mit dem
-Präfix @var{Version} beginnt.
-@end deffn
-@deffn {Scheme-Prozedur} inferior-package? @var{Objekt}
-Liefert wahr, wenn das @var{obj} ein Untergeordneter ist.
-@end deffn
-@deffn {Scheme-Prozedur} inferior-package-name @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-version @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-synopsis @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-description @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-home-page @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-location @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-inputs @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-native-inputs @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-propagated-inputs @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-transitive-propagated-inputs @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-native-search-paths @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-transitive-native-search-paths @var{Paket}
-@deffnx {Scheme-Prozedur} inferior-package-search-paths @var{Paket}
-Diese Prozeduren sind das Gegenstück zu den Zugriffsmethoden des Verbunds
-»package« für Pakete (siehe @ref{»package«-Referenz}). Die meisten davon
-funktionieren durch eine Abfrage auf dem Untergeordneten, von dem das
-@var{Paket} kommt, weshalb der Untergeordnete noch lebendig sein muss, wenn
-Sie diese Prozeduren aufrufen.
-@end deffn
-Untergeordnete Pakete können transparent wie jedes andere Paket oder
-dateiartige Objekt in G-Ausdrücken verwendet werden (siehe
-@ref{G-Ausdrücke}). Sie werden auch transparent wie reguläre Pakete von
-der Prozedur @code{packages->manifest} behandelt, welche oft in Manifesten
-benutzt wird (siehe @ref{Aufruf von guix package, siehe die
-Befehlszeilenoption @option{--manifest} von @command{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 @code{packages}
-Ihrer @code{operating-system}-Deklaration und so weiter.
-@node Aufruf von guix describe
-@section @command{guix describe} aufrufen
-@cindex Reproduzierbarkeit
-@cindex Nachbilden von Guix
-Sie könnten sich des Öfteren Fragen stellen wie: »Welche Version von Guix
-benutze ich gerade?« oder »Welche Kanäle benutze ich?« Diese Informationen
-sind in vielen Situationen nützlich: wenn Sie eine Umgebung auf einer
-anderen Maschine oder mit einem anderen Benutzerkonto @emph{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 @command{guix describe}
-gibt Ihnen Antwort auf diese Fragen.
-Wenn Sie ihn aus einem mit @command{guix pull} bezogenen @command{guix}
-heraus ausführen, zeigt Ihnen @command{guix describe} die Kanäle an, aus
-denen es erstellt wurde, jeweils mitsamt ihrer Repository-URL und Commit-ID
-(siehe @ref{Kanäle}):
-@example
-$ guix describe
-Generation 10   Sep 03 2018 17:32:44    (current)
-  guix e0fa68c
-    repository URL: https://git.savannah.gnu.org/git/guix.git
-    branch: master
-    commit: e0fa68c7718fffd33d81af415279d6ddb518f727
-@end example
-Wenn Sie mit dem Versionskontrollsystem Git vertraut sind, erkennen Sie
-vielleicht die Ähnlichkeit zu @command{git describe}; die Ausgabe ähnelt
-auch der von @command{guix pull --list-generations} eingeschränkt auf die
-aktuelle Generation (siehe @ref{Aufruf von guix pull, die Befehlszeilenoption
-@option{--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 @command{guix describe}
-auch eine Liste der Kanäle statt einer menschenlesbaren Beschreibung wie
-oben liefern:
-@example
-$ guix describe -f channels
-(list (channel
-        (name 'guix)
-        (url "https://git.savannah.gnu.org/git/guix.git")
-        (commit
-          "e0fa68c7718fffd33d81af415279d6ddb518f727")))
-@end example
-@noindent
-Sie können die Ausgabe in einer Datei speichern, die Sie an @command{guix
-pull -C} auf einer anderen Maschine oder zu einem späteren Zeitpunkt
-übergeben, wodurch dann eine Instanz @emph{von genau derselben Guix-Version}
-installiert wird (siehe @ref{Aufruf von guix pull, die Befehlszeilenoption
-@option{-C}}). Daraufhin können Sie, weil Sie jederzeit dieselbe Version von
-Guix installieren können, auch gleich @emph{eine vollständige
-Softwareumgebung genau nachbilden}. Wir halten das trotz aller
-Bescheidenheit für @emph{klasse} und hoffen, dass Ihnen das auch gefällt!
-Die genauen Befehlszeilenoptionen, die @command{guix describe} unterstützt,
-lauten wie folgt:
-@table @code
-@item --format=@var{Format}
-@itemx -f @var{Format}
-Die Ausgabe im angegebenen @var{Format} generieren, was eines der Folgenden
-sein muss:
-@table @code
-@item human
-für menschenlesbare Ausgabe,
-@item Kanäle
-eine Liste von Kanalspezifikationen erzeugen, die an @command{guix pull -C}
-übergeben werden oder als @file{~/.config/guix/channels.scm} eingesetzt
-werden können (siehe @ref{Aufruf von guix pull}),
-@item json
-@cindex JSON
-generiert eine Liste von Kanalspezifikationen im JSON-Format,
-@item recutils
-generiert eine Liste von Kanalspezifikationen im Recutils-Format.
-@end table
-@item --profile=@var{Profil}
-@itemx -p @var{Profil}
-Informationen über das @var{Profil} anzeigen.
-@end table
-@node Aufruf von guix archive
-@section @command{guix archive} aufrufen
-@cindex @command{guix archive}
-@cindex Archivdateien
-Der Befehl @command{guix archive} ermöglicht es Nutzern, Dateien im Store in
-eine einzelne Archivdatei zu @dfn{exportieren} und diese später auf einer
-Maschine, auf der Guix läuft, zu @dfn{importieren}. Insbesondere können so
-Store-Objekte von einer Maschine in den Store einer anderen Maschine
-übertragen werden.
-@quotation Anmerkung
-Wenn Sie nach einer Möglichkeit suchen, Archivdateien für andere Werkzeuge
-als Guix zu erstellen, finden Sie Informationen dazu im Abschnitt
-@ref{Aufruf von guix pack}.
-@end quotation
-@cindex Store-Objekte exportieren
-Führen Sie Folgendes aus, um Store-Dateien als ein Archiv auf die
-Standardausgabe zu exportieren:
-@example
-guix archive --export @var{Optionen} @var{Spezifikationen}...
-@end example
-@var{Spezifikationen} sind dabei entweder die Namen von Store-Dateien oder
-Paketspezifikationen wie bei @command{guix package} (siehe @ref{Aufruf von guix package}). Zum Beispiel erzeugt der folgende Befehl ein Archiv der
-@code{gui}-Ausgabe des Pakets @code{git} sowie die Hauptausgabe von
-@code{emacs}:
-@example
-guix archive --export git:gui /gnu/store/...-emacs-24.3 > groß.nar
-@end example
-Wenn die angegebenen Pakete noch nicht erstellt worden sind, werden sie
-durch @command{guix archive} automatisch erstellt. Der Erstellungsprozess
-kann durch die gemeinsamen Erstellungsoptionen gesteuert werden (siehe
-@ref{Gemeinsame Erstellungsoptionen}).
-Um das @code{emacs}-Paket auf eine über SSH verbundene Maschine zu
-übertragen, würde man dies ausführen:
-@example
-guix archive --export -r emacs | ssh die-maschine guix archive --import
-@end example
-@noindent
-Auf gleiche Art kann auch ein vollständiges Benutzerprofil von einer
-Maschine auf eine andere übertragen werden:
-@example
-guix archive --export -r $(readlink -f ~/.guix-profile) | \
-  ssh die-maschine guix-archive --import
-@end example
-@noindent
-Jedoch sollten Sie in beiden Beispielen beachten, dass alles, was zu
-@code{emacs}, dem Profil oder deren Abhängigkeiten (wegen @code{-r}) gehört,
-übertragen wird, egal ob es schon im Store der Zielmaschine vorhanden ist
-oder nicht. Mit der Befehlszeilenoption @code{--missing} lässt sich
-herausfinden, welche Objekte im Ziel-Store noch fehlen. Der Befehl
-@command{guix copy} vereinfacht und optimiert diesen gesamten Prozess, ist
-also, was Sie in diesem Fall wahrscheinlich eher benutzen wollten (siehe
-@ref{Aufruf von guix copy}).
-@cindex Nar, Archivformat
-@cindex Normalisiertes Archiv (Nar)
-Archive werden als »Normalisiertes Archiv«, kurz »Nar«, formatiert. Diese
-Technik folgt einem ähnlichen Gedanken wie beim »tar«-Format, unterscheidet
-sich aber auf eine für unsere Zwecke angemessene Art. 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.
-@c FIXME: Add xref to daemon doc about signatures.
-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
-signierende Schlüssel nicht autorisiert ist.
-Die wichtigsten Befehlszeilenoptionen sind:
-@table @code
-@item --export
-Exportiert die angegebenen Store-Dateien oder Pakete (siehe unten) und
-schreibt das resultierende Archiv auf die Standardausgabe.
-Abhängigkeiten @emph{fehlen} in der Ausgabe, außer wenn @code{--recursive}
-angegeben wurde.
-@item -r
-@itemx --recursive
-Zusammen mit @code{--export} wird @command{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.
-@item --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 @code{--authorize}
-weiter unten).
-@item --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.
-@item --generate-key[=@var{Parameter}]
-@cindex Signieren, von Archiven
-Ein neues Schlüsselpaar für den Daemon erzeugen. Dies ist erforderlich,
-damit Archive mit @code{--export} exportiert werden können. Beachten Sie,
-dass diese Option normalerweise einige Zeit in Anspruch nimmt, da erst
-Entropie für die Erzeugung des Schlüsselpaares gesammelt werden muss.
-Das erzeugte Schlüsselpaar wird typischerweise unter @file{/etc/guix}
-gespeichert, in den Dateien @file{signing-key.pub} (für den öffentlichen
-Schlüssel) und @file{signing-key.sec} (für den privaten Schlüssel, der
-geheim gehalten werden muss). Wurden keine @var{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 @var{Parameter} für Libgcrypt geeignete Parameter für
-@code{genkey} an (siehe @ref{General public-key related Functions,
-@code{gcry_pk_genkey},, gcrypt, The Libgcrypt Reference Manual}).
-@item --authorize
-@cindex Autorisieren, von Archiven
-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 @file{signing-key.pub}.
-Die Liste autorisierter Schlüssel wird in der Datei @file{/etc/guix/acl}
-gespeichert, die auch von Hand bearbeitet werden kann. Die Datei enthält
-@url{http://people.csail.mit.edu/rivest/Sexp.txt, »advanced«-formatierte
-S-Ausdrücke} und ist als eine Access Control List für die
-@url{http://theworld.com/~cme/spki.txt, Simple Public-Key Infrastructure
-(SPKI)} aufgebaut.
-@item --extract=@var{Verzeichnis}
-@itemx -x @var{Verzeichnis}
-Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern
-geliefert wird (siehe @ref{Substitute}) und ins @var{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
-@code{@value{SUBSTITUTE-SERVER}} geliefert wird, nach @file{/tmp/emacs}:
-@example
-$ wget -O - \
-  https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-emacs-24.5 \
-  | bunzip2 | guix archive -x /tmp/emacs
-@end example
-Archive mit nur einem einzelnen Objekt unterscheiden sich von Archiven für
-mehrere Dateien, wie sie @command{guix archive --export} erzeugt; sie
-enthalten nur ein einzelnes Store-Objekt und @emph{keine} eingebettete
-Signatur. Beim Entpacken findet also @emph{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.
-@end table
-@c *********************************************************************
-@node Entwicklung
-@chapter Entwicklung
-@cindex Softwareentwicklung
-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 @command{guix environment} stellt eine bequeme Möglichkeit dar,
-wie Sie eine @dfn{Entwicklungsumgebung} aufsetzen können, in der all die
-Abhängigkeiten und Werkzeuge enthalten sind, die Sie brauchen, wenn Sie an
-Ihrem Lieblingssoftwarepaket arbeiten. Der Befehl @command{guix pack} macht
-es Ihnen möglich, @dfn{Anwendungsbündel} zu erstellen, die leicht an Nutzer
-verteilt werden können, die kein Guix benutzen.
-@menu
-* Aufruf von guix environment::  Entwicklungsumgebungen einrichten.
-* Aufruf von guix pack::     Software-Bündel erstellen.
-@end menu
-@node Aufruf von guix environment
-@section @command{guix environment} aufrufen
-@cindex reproduzierbare Erstellungsumgebungen
-@cindex Entwicklungsumgebungen
-@cindex @command{guix environment}
-@cindex Umgebung, Paketerstellungsumgebung
-Der Zweck von @command{guix environment} ist es, Hacker beim Aufbau einer
-reproduzierbaren Entwicklungsumgebung zu unterstützen, ohne dass diese ihr
-Paketprofil verunreinigen müssen. Das Werkzeug @command{guix environment}
-nimmt eines oder mehrere Pakete entgegen und erstellt erst all ihre
-Eingaben, um dann eine Shell-Umgebung herzustellen, in der diese benutzt
-werden können.
-Die allgemeine Syntax lautet:
-@example
-guix environment @var{Optionen} @var{Paket}@dots{}
-@end example
-Folgendes Beispiel zeigt, wie eine neue Shell gestartet wird, auf der alles
-für die Entwicklung von GNU@tie{}Guile eingerichtet ist:
-@example
-guix environment guile
-@end example
-Wenn benötigte Abhängigkeiten noch nicht erstellt worden sind, wird
-@command{guix environment} sie automatisch erstellen lassen. Die Umgebung
-der neuen Shell ist eine ergänzte Version der Umgebung, in der @command{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 @code{--pure} benutzt werden@footnote{Manchmal ergänzen
-Nutzer fälschlicherweise Umgebungsvariable wie @code{PATH} in ihrer
-@file{~/.bashrc}-Datei. Das hat zur Folge, dass wenn @code{guix environment}
-Bash startet, selbige @file{~/.bashrc} von Bash gelesen wird und die neuen
-Umgebungen somit »verunreinigt«. Es ist ein Fehler, solche Umgebungsvariable
-in @file{.bashrc} zu definieren, stattdessen sollten sie in
-@file{.bash_profile} geschrieben werden, was nur von Login-Shells mit
-»source« geladen wird. Siehe @ref{Bash Startup Files,,, bash, The GNU Bash
-Reference Manual} für Details über beim Starten von Bash gelesene Dateien}.
-@vindex GUIX_ENVIRONMENT
-@command{guix environment} definiert die Variable @code{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
-@file{.bashrc} festzulegen (siehe @ref{Bash Startup Files,,, bash, The GNU
-Bash Reference Manual}):
-@example
-if [ -n "$GUIX_ENVIRONMENT" ]
-then
-    export PS1="\u@@\h \w [dev]\$ "
-fi
-@end example
-@noindent
-…@: oder um ihr Profil durchzusehen:
-@example
-$ ls "$GUIX_ENVIRONMENT/bin"
-@end example
-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:
-@example
-guix environment guile emacs
-@end example
-Manchmal will man keine interaktive Shell-Sitzung. Ein beliebiger Befehl
-kann aufgerufen werden, indem man nach Angabe der Pakete noch @code{--} vor
-den gewünschten Befehl schreibt, um ihn von den übrigen Argumenten
-abzutrennen:
-@example
-guix environment guile -- make -j4
-@end example
-In anderen Situationen ist es bequemer, aufzulisten, welche Pakete in der
-Umgebung benötigt werden. Zum Beispiel führt der folgende Befehl
-@command{python} aus einer Umgebung heraus aus, in der Python@tie{}2.7 und
-NumPy enthalten sind:
-@example
-guix environment --ad-hoc python2-numpy python-2.7 -- python
-@end example
-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 @code{--ad-hoc} ab. Pakete, die links von
-@code{--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:
-@example
-guix environment guix --ad-hoc git strace
-@end example
-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 @file{/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:
-@example
-guix environment --ad-hoc --container guile -- guile
-@end example
-@quotation Anmerkung
-Die Befehlszeilenoption @code{--container} funktioniert nur mit Linux-libre
-3.19 oder neuer.
-@end quotation
-Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.
-@table @code
-@item --root=@var{Datei}
-@itemx -r @var{Datei}
-@cindex persistente Umgebung
-@cindex Müllsammlerwurzel, für Umgebungen
-Die @var{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
-@command{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. @ref{Aufruf von guix gc} hat mehr Informationen über Müllsammlerwurzeln.
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der
-@var{Ausdruck} ausgewertet wird.
-Zum Beispiel startet dies:
-@example
-guix environment -e '(@@ (gnu packages maths) petsc-openmpi)'
-@end example
-eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets
-PETSc.
-Wenn man dies ausführt:
-@example
-guix environment --ad-hoc -e '(@@ (gnu) %base-packages)'
-@end example
-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:
-@example
-guix environment --ad-hoc -e '(list (@@ (gnu packages bash) bash) "include")'
-@end example
-@item --load=@var{Datei}
-@itemx -l @var{Datei}
-Eine Umgebung erstellen für das Paket oder die Liste von Paketen, zu der der
-Code in der @var{Datei} ausgewertet wird.
-Zum Beispiel könnte die @var{Datei} eine Definition wie diese enthalten
-(siehe @ref{Pakete definieren}):
-@example
-@verbatiminclude environment-gdb.scm
-@end example
-@item --manifest=@var{Datei}
-@itemx -m @var{Datei}
-Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten
-sind, das vom Scheme-Code in der @var{Datei} geliefert wird.
-Dies verhält sich ähnlich wie die gleichnamige Option des Befehls
-@command{guix package} (siehe @ref{profile-manifest, @option{--manifest}})
-und benutzt auch dieselben Manifestdateien.
-@item --ad-hoc
-Alle angegebenen Pakete in der resultierenden Umgebung einschließen, als
-wären sie Eingaben eines @i{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:
-@example
-guix environment --ad-hoc guile guile-sdl -- guile
-@end example
-@command{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
-@code{guile} und @code{guile-sdl} verwendet wird, es aber auch möglich ist,
-eine bestimmte Ausgabe auszuwählen — z.B.@: wird mit @code{glib:bin} die
-Ausgabe @code{bin} von @code{glib} gewählt (siehe @ref{Pakete mit mehreren Ausgaben.}).
-Diese Befehlszeilenoption kann mit dem standardmäßigen Verhalten von
-@command{guix environment} verbunden werden. Pakete, die vor @code{--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.
-@item --pure
-Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt
-wird, mit Ausnahme der mit @option{--preserve} angegebenen Variablen (siehe
-unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade
-nur Paketeingaben nennen und sonst nichts.
-@item --preserve=@var{Regexp}
-@itemx -E @var{Regexp}
-Wenn das hier zusammen mit @option{--pure} angegeben wird, bleiben die zum
-regulären Ausdruck @var{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.
-@example
-guix environment --pure --preserve=^SLURM --ad-hoc openmpi @dots{} \
-  -- mpirun @dots{}
-@end example
-In diesem Beispiel wird @command{mpirun} in einem Kontext ausgeführt, in dem
-die einzig definierten Umgebungsvariablen @code{PATH} und solche sind, deren
-Name mit @code{SLURM} beginnt, sowie die üblichen besonders »kostbaren«
-Variablen (@code{HOME}, @code{USER}, etc.).
-@item --search-paths
-Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.
-@item --system=@var{System}
-@itemx -s @var{System}
-Versuchen, für das angegebene @var{System} zu erstellen — z.B.@:
-@code{i686-linux}.
-@item --container
-@itemx -C
-@cindex container
-Den @var{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 @code{--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 @file{/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 @option{--user} wird
-übergeben (siehe unten).
-@item --network
-@itemx -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.
-@item --link-profile
-@itemx -P
-Bei isolierten Umgebungen (»Containern«) wird das Umgebungsprofil im
-Container als @file{~/.guix-profile} verknüpft. Das ist äquivalent dazu, den
-Befehl @command{ln -s $GUIX_ENVIRONMENT ~/.guix-profile} im Container
-auszuführen. Wenn das Verzeichnis bereits existiert, schlägt das Verknüpfen
-fehl und die Umgebung wird nicht hergestellt. Dieser Fehler wird immer
-eintreten, wenn @command{guix environment} im persönlichen Verzeichnis des
-Benutzers aufgerufen wurde.
-Bestimmte Pakete sind so eingerichtet, dass sie in @code{~/.guix-profile}
-nach Konfigurationsdateien und Daten suchen,@footnote{Zum Beispiel
-inspiziert das Paket @code{fontconfig} das Verzeichnis
-@file{~/.guix-profile/share/fonts}, um zusätzliche Schriftarten zu finden.}
-weshalb @code{--link-profile} benutzt werden kann, damit sich diese
-Programme auch in der isolierten Umgebung wie erwartet verhalten.
-@item --user=@var{Benutzer}
-@itemx -u @var{Benutzer}
-Bei isolierten Umgebungen (»Containern«) wird der Benutzername
-@var{Benutzer} anstelle des aktuellen Benutzers benutzt. Der erzeugte
-Eintrag in @file{/etc/passwd} im Container wird also den Namen
-@var{Benutzer} enthalten und das persönliche Verzeichnis wird den Namen
-@file{/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. @var{Benutzer} muss auf dem System
-nicht existieren.
-Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils
-@code{--share} und @code{--expose}), deren Ziel innerhalb des persönlichen
-Verzeichnisses des aktuellen Benutzers liegt, relativ zu
-@file{/home/BENUTZER} erscheinen, einschließlich der automatischen Zuordnung
-des aktuellen Arbeitsverzeichnisses.
-@example
-# 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
-@end example
-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 Privatsphäre und Anonymität sinnvoll eingesetzt
-werden. Es sollte nicht für sich allein dazu eingesetzt werden.
-@item --expose=@var{Quelle}[=@var{Ziel}]
-Bei isolierten Umgebungen (»Containern«) wird das Dateisystem unter
-@var{Quelle} vom Wirtssystem als Nur-Lese-Dateisystem @var{Ziel} im
-Container zugänglich gemacht. Wenn kein @var{Ziel} angegeben wurde, wird die
-@var{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
-@file{/austausch} nur für Lesezugriffe zugänglich gemacht wurde:
-@example
-guix environment --container --expose=$HOME=/austausch --ad-hoc guile -- guile
-@end example
-@item --share=@var{Quelle}[=@var{Ziel}]
-Bei isolierten Umgebungen (»Containern«) wird das Dateisystem unter
-@var{Quelle} vom Wirtssystem als beschreibbares Dateisystem @var{Ziel} im
-Container zugänglich gemacht. Wenn kein @var{Ziel} angegeben wurde, wird die
-@var{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
-@file{/austausch} sowohl für Lese- als auch für Schreibzugriffe zugänglich
-gemacht wurde:
-@example
-guix environment --container --share=$HOME=/austausch --ad-hoc guile -- guile
-@end example
-@end table
-@command{guix environment} unterstützt auch alle gemeinsamen
-Erstellungsoptionen, die von @command{guix build} unterstützt werden (siehe
-@ref{Gemeinsame Erstellungsoptionen}), und die Paketumwandlungsoptionen (siehe
-@ref{Paketumwandlungsoptionen}).
-@node Aufruf von guix pack
-@section @command{guix pack} aufrufen
-Manchmal möchten Sie Software an Leute weitergeben, die (noch!) nicht das
-Glück haben, Guix zu benutzen. Mit Guix würden sie nur @command{guix package
-i @var{irgendetwas}} einzutippen brauchen, aber wenn sie kein Guix haben,
-muss es anders gehen. Hier kommt @command{guix pack} ins Spiel.
-@quotation 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 @ref{Aufruf von guix copy}, @ref{Aufruf von guix publish} und
-@ref{Aufruf von guix archive} werfen.
-@end quotation
-@cindex Pack
-@cindex Bündel
-@cindex Anwendungsbündel
-@cindex Software-Bündel
-Der Befehl @command{guix pack} erzeugt ein gut verpacktes
-@dfn{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:
-@example
-$ guix pack guile emacs geiser
-@dots{}
-/gnu/store/@dots{}-pack.tar.gz
-@end example
-Als Ergebnis erhalten Sie einen Tarball mit einem Verzeichnis
-@file{/gnu/store}, worin sich alles relevanten Pakete befinden. Der
-resultierende Tarball enthält auch ein @dfn{Profil} mit den drei angegebenen
-Paketen; es ist dieselbe Art von Profil, die auch @command{guix package -i}
-erzeugen würde. Mit diesem Mechanismus wird auch der binäre Tarball zur
-Installation von Guix erzeugt (siehe @ref{Aus Binärdatei installieren}).
-Benutzer des Bündels müssten dann aber zum Beispiel
-@file{/gnu/store/@dots{}-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 @file{/opt/gnu/bin} auf das Profil anlegen:
-@example
-guix pack -S /opt/gnu/bin=bin guile emacs geiser
-@end example
-@noindent
-Benutzer müssten dann nur noch @file{/opt/gnu/bin/guile} eintippen, um Guile
-zu genießen.
-@cindex pfad-agnostische Binärdateien, mit @command{guix pack}
-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 @code{--relocatable} benutzen (siehe weiter unten). Mit
-dieser Option werden @dfn{pfad-agnostische Binärdateien} erzeugt, die auch
-in einem beliebigen anderen Verzeichnis in der Dateisystemhierarchie
-abgelegt und von dort ausgeführt werden können. In obigem Beispiel würden
-Benutzer Ihren Tarball in ihr Persönliches Verzeichnis (das
-»Home«-Verzeichnis) entpacken und von dort den Befehl
-@file{./opt/gnu/bin/guile} ausführen.
-@cindex Docker, ein Abbild erstellen mit guix pack
-Eine weitere Möglichkeit ist, das Bündel im Format eines Docker-Abbilds
-(englisch Docker-Image) zu erzeugen. Das geht mit dem folgenden Befehl:
-@example
-guix pack -f docker guile emacs geiser
-@end example
-@noindent
-Das Ergebnis ist ein Tarball, der dem Befehl @command{docker load} übergeben
-werden kann. In der
-@uref{https://docs.docker.com/engine/reference/commandline/load/,
-Dokumentation von Docker} finden Sie nähere Informationen.
-@cindex Singularity, ein Abbild erstellen mit guix pack
-@cindex SquashFS, ein Abbild erstellen mit guix pack
-Und noch eine weitere Möglichkeit ist, dass Sie ein SquashFS-Abbild mit
-folgendem Befehl erzeugen:
-@example
-guix pack -f squashfs guile emacs geiser
-@end example
-@noindent
-Das Ergebnis ist ein SquashFS-Dateisystemabbild, dass entweder als
-Dateisystem eingebunden oder mit Hilfe der @uref{http://singularity.lbl.gov,
-Singularity-Container-Ausführungsumgebung} als Dateisystemcontainer benutzt
-werden kann, mit Befehlen wie @command{singularity shell} oder
-@command{singularity exec}.
-Es gibt mehrere Befehlszeilenoptionen, mit denen Sie Ihr Bündel anpassen
-können:
-@table @code
-@item --format=@var{Format}
-@itemx -f @var{Format}
-Generiert ein Bündel im angegebenen @var{Format}.
-Die verfügbaren Formate sind:
-@table @code
-@item tarball
-Das standardmäßig benutzte Format. Damit wird ein Tarball generiert, der
-alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält.
-@item docker
-Generiert einen Tarball gemäß der
-@uref{https://github.com/docker/docker/blob/master/image/spec/v1.2.md,
-Docker Image Specification}, d.h.@: der Spezifikation für Docker-Abbilder.
-@item 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.
-@end table
-@cindex pfad-agnostische Binärdateien
-@item --relocatable
-@itemx -R
-Erzeugt @dfn{pfad-agnostische Binärdateien} — also »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 @dfn{Benutzernamensräume} des
-Linux-Kernels unterstützt werden. Wenn sie @emph{zweimal}@footnote{Es gibt
-einen Trick, wie Sie sich das merken können: @code{-RR}, womit
-PRoot-Unterstützung hinzugefügt wird, kann man sich als Abkürzung für
-»Rundum Relocatable« oder englisch »Really Relocatable« vorstellen. Ist das
-nicht prima?} übergeben wird, laufen die Binärdateien notfalls mit PRoot,
-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:
-@example
-guix pack -RR -S /mybin=bin bash
-@end example
-@noindent
-…@: 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:
-@example
-tar xf pack.tar.gz
-./meine-bin/sh
-@end example
-@noindent
-Wenn Sie in der so gestarteten Shell dann @code{ls /gnu/store} eintippen,
-sehen Sie, dass Ihnen angezeigt wird, in @file{/gnu/store} befänden sich
-alle Abhängigkeiten von @code{bash}, obwohl auf der Maschine überhaupt kein
-Verzeichnis @file{/gnu/store} existiert! Dies ist vermutlich die einfachste
-Art, mit Guix erstellte Software für eine Maschine ohne Guix auszuliefern.
-@quotation Anmerkung
-Wenn die Voreinstellung verwendet wird, funktionieren pfad-agnostische
-Binärdateien nur mit @dfn{Benutzernamensräumen} (englisch @dfn{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 pfad-agnostische Binärdateien zu erzeugen, die auch ohne
-Benutzernamensräume funktionieren, können Sie die Befehlszeilenoption
-@option{--relocatable} oder @option{-R} @emph{zweimal} angeben. In diesem
-Fall werden die Binärdateien zuerst überprüfen, ob Benutzernamensräume
-unterstützt werden, und sonst notfalls PRoot benutzen, um das Programm
-auszuführen, wenn Benutzernamensräume nicht unterstützt werden.
-Das Programm @uref{https://proot-me.github.io/, PRoot} bietet auch
-Unterstützung für Dateisystemvirtualisierung, indem der Systemaufruf
-@code{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.
-@end quotation
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird.
-Der Zweck hiervon ist derselbe wie bei der gleichnamigen Befehlszeilenoption
-in @command{guix build} (siehe @ref{Zusätzliche Erstellungsoptionen,
-@code{--expression} in @command{guix build}}).
-@item --manifest=@var{Datei}
-@itemx -m @var{Datei}
-Die Pakete benutzen, die im Manifest-Objekt aufgeführt sind, das vom
-Scheme-Code in der angegebenen @var{Datei} geliefert wird.
-Dies hat einen ähnlichen Zweck wie die gleichnamige Befehlszeilenoption in
-@command{guix package} (siehe @ref{profile-manifest, @option{--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
-@emph{entweder} eine Manifest-Datei @emph{oder} eine Liste von Paketen
-angeben können, aber nicht beides.
-@item --system=@var{System}
-@itemx -s @var{System}
-Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu
-erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die
-Erstellung durchführt.
-@item --target=@var{Tripel}
-@cindex Cross-Kompilieren
-Lässt für das angegebene @var{Tripel} cross-erstellen, dieses muss ein
-gültiges GNU-Tripel wie z.B.@: @code{"mips64el-linux-gnu"} sein (siehe
-@ref{Specifying target triplets, GNU configuration triplets,, autoconf,
-Autoconf}).
-@item --compression=@var{Werkzeug}
-@itemx -C @var{Werkzeug}
-Komprimiert den resultierenden Tarball mit dem angegebenen @var{Werkzeug} —
-dieses kann @code{gzip}, @code{bzip2}, @code{xz}, @code{lzip} oder
-@code{none} für keine Kompression sein.
-@item --symlink=@var{Spezifikation}
-@itemx -S @var{Spezifikation}
-Fügt die in der @var{Spezifikation} festgelegten symbolischen Verknüpfungen
-zum Bündel hinzu.  Diese Befehlszeilenoption darf mehrmals vorkommen.
-Die @var{Spezifikation} muss von der Form
-@code{@var{Quellort}=@var{Zielort}} sein, wobei der @var{Quellort} der Ort
-der symbolischen Verknüpfung, die erstellt wird, und @var{Zielort} das Ziel
-der symbolischen Verknüpfung ist.
-Zum Beispiel wird mit @code{-S /opt/gnu/bin=bin} eine symbolische
-Verknüpfung @file{/opt/gnu/bin} auf das Unterverzeichnis @file{bin} im
-Profil erzeugt.
-@item --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 @ref{Kanäle}).
-Provenienzinformationen werden in der Datei
-@file{/gnu/store/@dots{}-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 @emph{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.
-@item --localstatedir
-@itemx --profile-name=@var{Name}
-Das »lokale Zustandsverzeichnis« @file{/var/guix} ins resultierende Bündel
-aufnehmen, speziell auch das Profil
-@file{/var/guix/profiles/per-user/root/@var{Name}} — der vorgegebene
-@var{Name} ist @code{guix-profile}, was @file{~root/.guix-profile}
-entspricht.
-@file{/var/guix} enthält die Store-Datenbank (siehe @ref{Der Store}) sowie
-die Müllsammlerwurzeln (siehe @ref{Aufruf von guix gc}). Es ins Bündel
-aufzunehmen, bedeutet, dass der enthaltene Store »vollständig« ist und von
-Guix verwaltet werden kann, andernfalls wäre der Store im Bündel »tot« und
-nach dem Auspacken des Bündels könnte Guix keine Objekte mehr dort
-hinzufügen oder entfernen.
-Ein Anwendungsfall hierfür ist der eigenständige, alle Komponenten
-umfassende binäre Tarball von Guix (siehe @ref{Aus Binärdatei installieren}).
-@item --bootstrap
-Mit den Bootstrap-Binärdateien das Bündel erstellen. Diese Option ist nur
-für Guix-Entwickler nützlich.
-@end table
-Außerdem unterstützt @command{guix pack} alle gemeinsamen
-Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}) und alle
-Paketumwandlungsoptionen (siehe @ref{Paketumwandlungsoptionen}).
-@c *********************************************************************
-@node Programmierschnittstelle
-@chapter Programmierschnittstelle
-GNU Guix bietet mehrere Programmierschnittstellen (APIs) in der
-Programmiersprache Scheme an, mit denen Software-Pakete definiert, erstellt
-und gesucht werden können. Die erste Schnittstelle erlaubt es Nutzern, ihre
-eigenen Paketdefinitionen in einer Hochsprache zu schreiben. Diese
-Definitionen nehmen Bezug auf geläufige Konzepte der Paketverwaltung, wie
-den Namen und die Version eines Pakets, sein Erstellungssystem (Build
-System) und seine Abhängigkeiten (Dependencies). Diese Definitionen können
-dann in konkrete Erstellungsaktionen umgewandelt werden.
-Erstellungsaktionen werden vom Guix-Daemon für dessen Nutzer
-durchgeführt. Bei einer normalen Konfiguration hat der Daemon Schreibzugriff
-auf den Store, also das Verzeichnis @file{/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.
-@cindex Ableitung
-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 @dfn{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 @emph{abgeleitet} werden.
-Dieses Kapitel beschreibt der Reihe nach all diese Programmierschnittstellen
-(APIs), angefangen mit hochsprachlichen Paketdefinitionen.
-@menu
-* Paketmodule::              Pakete aus Sicht des Programmierers.
-* Pakete definieren::        Wie Sie neue Pakete definieren.
-* Erstellungssysteme::       Angeben, wie Pakete erstellt werden.
-* Der Store::                Den Paket-Store verändern.
-* Ableitungen::              Systemnahe Schnittstelle für Paketableitungen.
-* Die Store-Monade::         Rein funktionale Schnittstelle zum Store.
-* G-Ausdrücke::             Erstellungsausdrücke verarbeiten.
-* Aufruf von guix repl::     Interaktiv an Guix herumbasteln.
-@end menu
-@node Paketmodule
-@section Paketmodule
-Aus Programmierersicht werden die Paketdefinitionen der GNU-Distribution als
-Guile-Module in Namensräumen wie @code{(gnu packages @dots{})} sichtbar
-gemacht@footnote{Beachten Sie, dass Pakete unter dem Modulnamensraum
-@code{(gnu packages @dots{})} nicht notwendigerweise auch »GNU-Pakete«
-sind. Dieses Schema für die Benennung von Modulen folgt lediglich den
-üblichen Guile-Konventionen: @code{gnu} bedeutet, dass die Module als Teil
-des GNU-Systems ausgeliefert werden, und @code{packages} gruppiert Module
-mit Paketdefinitionen.} (siehe @ref{Module, Guile modules,, guile, GNU
-Guile Reference Manual}). Zum Beispiel exportiert das Modul @code{(gnu
-packages emacs)} eine Variable namens @code{emacs}, die an ein
-@code{<package>}-Objekt gebunden ist (@pxref{Pakete definieren}).
-The @code{(gnu packages @dots{})} module name space is automatically scanned
-for packages by the command-line tools.  For instance, when running
-@code{guix package -i emacs}, all the @code{(gnu packages @dots{})} modules
-are scanned until one that exports a package object whose name is
-@code{emacs} is found.  This package search facility is implemented in the
-@code{(gnu packages)} module.
-@cindex Anpassung, von Paketen
-@cindex package module search path
-Users can store package definitions in modules with different names---e.g.,
-@code{(my-packages emacs)}@footnote{Note that the file name and module name
-must match.  For instance, the @code{(my-packages emacs)} module must be
-stored in a @file{my-packages/emacs.scm} file relative to the load path
-specified with @option{--load-path} or @code{GUIX_PACKAGE_PATH}.
-@xref{Modules and the File System,,, guile, GNU Guile Reference Manual}, for
-details.}.  There are two ways to make these package definitions visible to
-the user interfaces:
-@enumerate
-@item
-By adding the directory containing your package modules to the search path
-with the @code{-L} flag of @command{guix package} and other commands
-(@pxref{Gemeinsame Erstellungsoptionen}), or by setting the @code{GUIX_PACKAGE_PATH}
-environment variable described below.
-@item
-By defining a @dfn{channel} and configuring @command{guix pull} so that it
-pulls from it.  A channel is essentially a Git repository containing package
-modules.  @xref{Kanäle}, for more information on how to define and use
-channels.
-@end enumerate
-@code{GUIX_PACKAGE_PATH} works similarly to other search path variables:
-@defvr {Environment Variable} GUIX_PACKAGE_PATH
-This is a colon-separated list of directories to search for additional
-package modules.  Directories listed in this variable take precedence over
-the own modules of the distribution.
-@end defvr
-The distribution is fully @dfn{bootstrapped} and @dfn{self-contained}: each
-package is built based solely on other packages in the distribution.  The
-root of this dependency graph is a small set of @dfn{bootstrap binaries},
-provided by the @code{(gnu packages bootstrap)} module.  For more
-information on bootstrapping, @pxref{Bootstrapping}.
-@node Pakete definieren
-@section Pakete definieren
-Mit den Modulen @code{(guix packages)} und @code{(guix build-system)} können
-Paketdefinitionen auf einer hohen Abstraktionsebene geschrieben werden. Zum
-Beispiel sieht die Paketdefinition bzw. das @dfn{Rezept} für das Paket von
-GNU Hello so aus:
-@example
-(define-module (gnu packages hello)
-  #:use-module (guix packages)
-  #:use-module (guix download)
-  #:use-module (guix build-system gnu)
-  #:use-module (guix licenses)
-  #:use-module (gnu packages gawk))
-(define-public hello
-  (package
-    (name "hello")
-    (version "2.10")
-    (source (origin
-              (method url-fetch)
-              (uri (string-append "mirror://gnu/hello/hello-" version
-                                  ".tar.gz"))
-              (sha256
-               (base32
-                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
-    (build-system gnu-build-system)
-    (arguments '(#:configure-flags '("--enable-silent-rules")))
-    (inputs `(("gawk" ,gawk)))
-    (synopsis "Hello, GNU world: An example GNU package")
-    (description "Guess what GNU Hello prints!")
-    (home-page "http://www.gnu.org/software/hello/")
-    (license gpl3+)))
-@end example
-@noindent
-Auch ohne ein Experte in Scheme zu sein, könnten Leser erraten haben, was
-die verschiedenen Felder dabei bedeuten. Dieser Ausdruck bindet die Variable
-@code{hello} an ein @code{<package>}-Objekt, was an sich nur ein Verbund
-(Record) ist (siehe @ref{SRFI-9, Scheme records,, guile, GNU Guile Reference
-Manual}). Die Felder dieses Paket-Objekts lassen sich mit den Prozeduren aus
-dem Modul @code{(guix packages)} auslesen, zum Beispiel liefert
-@code{(package-name hello)} — Überraschung! — @code{"hello"}.
-Mit etwas Glück können Sie die Definition vielleicht teilweise oder sogar
-ganz aus einer anderen Paketsammlung importieren, indem Sie den Befehl
-@code{guix import} verwenden (siehe @ref{Aufruf von guix import}).
-In obigem Beispiel wurde @var{hello} in einem eigenen Modul ganz für sich
-alleine definiert, und zwar @code{(gnu packages hello)}. Technisch gesehen
-muss es nicht unbedingt in einem solchen Modul definiert werden, aber es ist
-bequem, denn alle Module unter @code{(gnu packages @dots{})} werden
-automatisch von den Befehlszeilenwerkzeugen gefunden (siehe @ref{Paketmodule}).
-Ein paar Dinge sind noch erwähnenswert in der obigen Paketdefinition:
-@itemize
-@item
-Das @code{source}-Feld für die Quelle des Pakets ist ein
-@code{<origin>}-Objekt, was den Paketursprung angibt (siehe @ref{»origin«-Referenz} für eine vollständige Referenz). Hier wird dafür die Methode
-@code{url-fetch} aus dem Modul @code{(guix download)} benutzt, d.h.@: die
-Quelle ist eine Datei, die über FTP oder HTTP heruntergeladen werden soll.
-Das Präfix @code{mirror://gnu} lässt @code{url-fetch} einen der
-GNU-Spiegelserver benutzen, die in @code{(guix download)} definiert sind.
-Das Feld @code{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 @code{(base32
-@dots{})} geht der base32-Darstellung des Hash-Wertes voraus. Sie finden die
-base32-Darstellung mit Hilfe der Befehle @code{guix download} (siehe
-@ref{Aufruf von guix download}) und @code{guix hash} (siehe @ref{Aufruf von guix hash}).
-@cindex Patches
-Wenn nötig kann in der @code{origin}-Form auch ein @code{patches}-Feld
-stehen, wo anzuwendende Patches aufgeführt werden, sowie ein
-@code{snippet}-Feld mit einem Scheme-Ausdruck mit den Anweisungen, wie der
-Quellcode zu modifizieren ist.
-@item
-@cindex GNU-Erstellungssystem
-Das Feld @code{build-system} legt fest, mit welcher Prozedur das Paket
-erstellt werden soll (siehe @ref{Erstellungssysteme}). In diesem Beispiel steht
-@var{gnu-build-system} für das wohlbekannte GNU-Erstellungssystem, wo Pakete
-mit der üblichen Befehlsfolge @code{./configure && make && make check &&
-make install} konfiguriert, erstellt und installiert werden.
-@item
-Das Feld @code{arguments} gibt an, welche Optionen dem Erstellungssystem
-mitgegeben werden sollen (siehe @ref{Erstellungssysteme}). In diesem Fall
-interpretiert @var{gnu-build-system} diese als Auftrag, @file{configure} mit
-der Befehlszeilenoption @code{--enable-silent-rules} auszuführen.
-@cindex quote
-@cindex Maskierung
-@findex '
-@findex quote
-Was hat es mit diesen einfachen Anführungszeichen (@code{'}) auf sich? Sie
-gehören zur Syntax von Scheme und führen eine wörtlich zu interpretierende
-Datenlisten ein; dies nennt sich Maskierung oder Quotierung. @code{'} ist
-synonym mit @code{quote}. @ref{Expression Syntax, quoting,, guile, GNU Guile
-Reference Manual} enthält weitere Details. Hierbei ist also der Wert des
-@code{arguments}-Feldes eine Liste von Argumenten, die an das
-Erstellungssystem weitergereicht werden, wie bei @code{apply} (siehe
-@ref{Fly Evaluation, @code{apply},, guile, GNU Guile Reference Manual}).
-Ein Doppelkreuz gefolgt von einem Doppelpunkt (@code{#:}) definiert ein
-Scheme-@dfn{Schlüsselwort} (siehe @ref{Keywords,,, guile, GNU Guile
-Reference Manual}) und @code{#:configure-flags} ist ein Schlüsselwort, um
-eine Befehlszeilenoption an das Erstellungssystem mitzugeben (siehe
-@ref{Coding With Keywords,,, guile, GNU Guile Reference Manual}).
-@item
-Das Feld @code{inputs} legt Eingaben an den Erstellungsprozess fest — d.h.@:
-Abhängigkeiten des Pakets zur Erstellungs- oder Laufzeit. Hier definieren
-wir eine Eingabe namens @code{"gawk"}, deren Wert wir auf den Wert der
-@var{gawk}-Variablen festlegen; @var{gawk} ist auch selbst wiederum an ein
-@code{<package>}-Objekt als Variablenwert gebunden.
-@cindex Backquote (Quasimaskierung)
-@findex `
-@findex quasiquote
-@cindex Komma (Demaskierung)
-@findex ,
-@findex unquote
-@findex ,@@
-@findex unquote-splicing
-Auch mit @code{`} (einem Backquote, stattdessen kann man auch das längere
-Synonym @code{quasiquote} schreiben) können wir eine wörtlich als Daten
-interpretierte Liste im @code{inputs}-Feld einführen, aber bei dieser
-»Quasimaskierung« kann @code{,} (ein Komma, oder dessen Synonym
-@code{unquote}) benutzt werden, um den ausgewerteten Wert eines Ausdrucks in
-diese Liste einzufügen (siehe @ref{Expression Syntax, unquote,, guile, GNU
-Guile Reference Manual}).
-Beachten Sie, dass GCC, Coreutils, Bash und andere essenzielle Werkzeuge
-hier nicht als Eingaben aufgeführt werden müssen. Stattdessen sorgt schon
-@var{gnu-build-system} dafür, dass diese vorhanden sein müssen (siehe
-@ref{Erstellungssysteme}).
-Sämtliche anderen Abhängigkeiten müssen aber im @code{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.
-@end itemize
-Siehe @ref{»package«-Referenz} für eine umfassende Beschreibung aller
-erlaubten Felder.
-Sobald eine Paketdefinition eingesetzt wurde, können Sie das Paket mit Hilfe
-des Befehlszeilenwerkzeugs @code{guix build} dann auch tatsächlich erstellen
-(siehe @ref{Aufruf von guix build}) und dabei jegliche Erstellungsfehler, auf
-die Sie stoßen, beseitigen (siehe @ref{Fehlschläge beim Erstellen untersuchen}). Sie
-können den Befehl @command{guix edit} benutzen, um leicht zur
-Paketdefinition zurückzuspringen (siehe @ref{Aufruf von guix edit}). Unter
-@ref{Paketrichtlinien} finden Sie mehr Informationen darüber, wie Sie
-Paketdefinitionen testen, und unter @ref{Aufruf von guix lint} finden Sie
-Informationen, wie Sie prüfen, ob eine Definition alle Stilkonventionen
-einhält.
-@vindex GUIX_PACKAGE_PATH
-Zuletzt finden Sie unter @ref{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 @command{guix refresh} teilweise automatisieren können (siehe
-@ref{Aufruf von guix refresh}).
-Hinter den Kulissen wird die einem @code{<package>}-Objekt entsprechende
-Ableitung zuerst durch @code{package-derivation} berechnet. Diese Ableitung
-wird in der @code{.drv}-Datei unter @file{/gnu/store} gespeichert. Die von
-ihr vorgeschriebenen Erstellungsaktionen können dann durch die Prozedur
-@code{build-derivations} umgesetzt werden (siehe @ref{Der Store}).
-@deffn {Scheme-Prozedur} package-derivation @var{Store} @var{Paket} [@var{System}]
-Das @code{<derivation>}-Objekt zum @var{Paket} für das angegebene
-@var{System} liefern (siehe @ref{Ableitungen}).
-Als @var{Paket} muss ein gültiges @code{<package>}-Objekt angegeben werden
-und das @var{System} muss eine Zeichenkette sein, die das Zielsystem angibt
-— z.B.@: @code{"x86_64-linux"} für ein auf x86_64 laufendes, Linux-basiertes
-GNU-System. @var{Store} muss eine Verbindung zum Daemon sein, der die
-Operationen auf dem Store durchführt (siehe @ref{Der Store}).
-@end deffn
-@noindent
-@cindex Cross-Kompilieren
-Auf ähnliche Weise kann eine Ableitung berechnet werden, die ein Paket für
-ein anderes System cross-erstellt.
-@deffn {Scheme-Prozedur} package-cross-derivation @var{Store} @
-            @var{Paket} @var{Ziel} [@var{System}] Liefert das
-@code{<derivation>}-Objekt, um das @var{Paket} zu cross-erstellen vom
-@var{System} aus für das @var{Ziel}-System.
-Als @var{Ziel} muss ein gültiges GNU-Tripel angegeben werden, was die
-Ziel-Hardware und das zugehörige Betriebssystem beschreibt, wie z.B.@:
-@code{"mips64el-linux-gnu"} (siehe @ref{Configuration Names, GNU
-configuration triplets,, configure, GNU Configure and Build System}).
-@end deffn
-@cindex Paketumwandlungen
-@cindex Eingaben umschreiben
-@cindex Abhängigkeitsbaum umschreiben
-Pakete können auf beliebige Art verändert werden. Ein Beispiel für eine
-nützliche Veränderung ist das @dfn{Umschreiben von Eingaben}, womit der
-Abhängigkeitsbaum eines Pakets umgeschrieben wird, indem bestimmte Eingaben
-durch andere ersetzt werden:
-@deffn {Scheme-Prozedur} package-input-rewriting @var{Ersetzungen} @
-           [@var{umgeschriebener-Name}] Eine Prozedur liefern, die für ein ihr
-übergebenes Paket dessen direkte und indirekte Abhängigkeit (aber nicht
-dessen implizite Eingaben) gemäß den @var{Ersetzungen}
-umschreibt. @var{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 @var{umgeschriebener-Name} eine ein Argument nehmende
-Prozedur angegeben werden, die einen Paketnamen nimmt und den Namen nach dem
-Umschreiben zurückliefert.
-@end deffn
-@noindent
-Betrachten Sie dieses Beispiel:
-@example
-(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))
-@end example
-@noindent
-Hier definieren wir zuerst eine Umschreibeprozedur, die @var{openssl} durch
-@var{libressl} ersetzt. Dann definieren wir damit eine @dfn{Variante} des
-@var{git}-Pakets, die @var{libressl} statt @var{openssl} benutzt. Das ist
-genau, was auch die Befehlszeilenoption @option{--with-input} tut (siehe
-@ref{Paketumwandlungsoptionen, @option{--with-input}}).
-The following variant of @code{package-input-rewriting} can match packages
-to be replaced by name rather than by identity.
-@deffn {Scheme-Prozedur} package-input-rewriting/spec @var{Ersetzungen}
-Return a procedure that, given a package, applies the given
-@var{replacements} to all the package graph (excluding implicit inputs).
-@var{replacements} is a list of spec/procedures pair; each spec is a package
-specification such as @code{"gcc"} or @code{"guile@@2"}, and each procedure
-takes a matching package and returns a replacement for that package.
-@end deffn
-The example above could be rewritten this way:
-@example
-(define libressl-statt-openssl
-  ;; Rekursiv alle Pakete namens "openssl" durch LibreSSL ersetzen.
-  (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))
-@end example
-The key difference here is that, this time, packages are matched by spec and
-not by identity.  In other words, any package in the graph that is called
-@code{openssl} will be replaced.
-Eine allgemeiner anwendbare Prozedur, um den Abhängigkeitsgraphen eines
-Pakets umzuschreiben, ist @code{package-mapping}. Sie unterstützt beliebige
-Änderungen an den Knoten des Graphen.
-@deffn {Scheme-Prozedur} package-mapping @var{Prozedur} [@var{Schnitt?}]
-Liefert eine Prozedur, die, wenn ihr ein Paket übergeben wird, die an
-@code{package-mapping} übergebene @var{Prozedur} auf alle vom Paket
-abhängigen Pakete anwendet. Die Prozedur liefert das resultierende
-Paket. Wenn @var{Schnitt?} für ein Paket davon einen wahren Wert liefert,
-findet kein rekursiver Abstieg in dessen Abhängigkeiten statt.
-@end deffn
-@menu
-* »package«-Referenz::     Der Datentyp für Pakete.
-* »origin«-Referenz::      Datentyp für Paketursprünge.
-@end menu
-@node »package«-Referenz
-@subsection @code{package}-Referenz
-Dieser Abschnitt fasst alle in @code{package}-Deklarationen zur Verfügung
-stehenden Optionen zusammen (siehe @ref{Pakete definieren}).
-@deftp {Datentyp} package
-Dieser Datentyp steht für ein Paketrezept.
-@table @asis
-@item @code{name}
-Der Name des Pakets als Zeichenkette.
-@item @code{version}
-Die Version des Pakets als Zeichenkette.
-@item @code{source}
-Ein Objekt, das beschreibt, wie der Quellcode des Pakets bezogen werden
-soll. Meistens ist es ein @code{origin}-Objekt, welches für eine aus dem
-Internet heruntergeladene Datei steht (siehe @ref{»origin«-Referenz}). Es
-kann aber auch ein beliebiges anderes »dateiähnliches« Objekt sein, wie
-z.B.@: ein @code{local-file}, was eine Datei im lokalen Dateisystem
-bezeichnet (siehe @ref{G-Ausdrücke, @code{local-file}}).
-@item @code{build-system}
-Das Erstellungssystem, mit dem das Paket erstellt werden soll (siehe
-@ref{Erstellungssysteme}).
-@item @code{arguments} (Vorgabe: @code{'()})
-Die Argumente, die an das Erstellungssystem übergeben werden sollen. Dies
-ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren.
-@item @code{inputs} (Vorgabe: @code{'()})
-@itemx @code{native-inputs} (Vorgabe: @code{'()})
-@itemx @code{propagated-inputs} (Vorgabe: @code{'()})
-@cindex Eingaben, von Paketen
-In diesen Feldern werden die Abhängigkeiten des Pakets aufgeführt. Jedes
-dieser Felder enthält eine Liste von Tupeln, wobei jedes Tupel eine
-Bezeichnung für die Eingabe (als Zeichenkette) als erstes Element, dann ein
-»package«-, »origin«- oder »derivation«-Objekt (Paket, Ursprung oder
-Ableitung) als zweites Element und optional die Benennung der davon zu
-benutzenden Ausgabe umfasst; letztere hat als Vorgabewert @code{"out"}
-(siehe @ref{Pakete mit mehreren Ausgaben.} für mehr Informationen zu
-Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:
-@example
-`(("libffi" ,libffi)
-  ("libunistring" ,libunistring)
-  ("glib:bin" ,glib "bin"))  ;Ausgabe "bin" von Glib
-@end example
-@cindex Cross-Kompilieren, Paketabhängigkeiten
-Die Unterscheidung zwischen @code{native-inputs} und @code{inputs} ist
-wichtig, damit Cross-Kompilieren möglich ist. Beim Cross-Kompilieren werden
-als @code{inputs} aufgeführte Abhängigkeiten für die
-Ziel-Prozessorarchitektur (@emph{target}) erstellt, andersherum werden als
-@code{native-inputs} aufgeführte Abhängigkeiten für die Prozessorarchitektur
-der erstellenden Maschine (@emph{build}) erstellt.
-@code{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. @command{guix lint} kann melden, ob wahrscheinlich Fehler in der
-Auflistung sind (siehe @ref{Aufruf von guix lint}).
-@anchor{package-propagated-inputs}
-Schließlich ist @code{propagated-inputs} ähnlich wie @code{inputs}, aber die
-angegebenen Pakete werden automatisch mit ins Profil installiert, wenn das
-Paket installiert wird, zu dem sie gehören (siehe
-@ref{package-cmd-propagated-inputs, @command{guix package}} für
-Informationen darüber, wie @command{guix package} mit propagierten Eingaben
-umgeht).
-Dies ist zum Beispiel nötig, wenn eine C-/C++-Bibliothek 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
-@code{Requires}-Eintrag bezieht.
-Noch ein Beispiel, wo @code{propagated-inputs} nützlich ist, sind Sprachen,
-die den Laufzeit-Suchpfad @emph{nicht} zusammen mit dem Programm abspeichern
-(@emph{nicht} wie etwa im @code{RUNPATH} bei ELF-Dateien), also Sprachen wie
-Guile, Python, Perl und weitere. Damit auch in solchen Sprachen geschriebene
-Bibliotheken zur Laufzeit den von ihnen benötigten Code finden können,
-müssen deren Laufzeit-Abhängigkeiten in @code{propagated-inputs} statt in
-@code{inputs} aufgeführt werden.
-@item @code{outputs} (Vorgabe: @code{'("out")})
-Die Liste der Benennungen der Ausgaben des Pakets. Der Abschnitt
-@ref{Pakete mit mehreren Ausgaben.} beschreibt übliche Nutzungen
-zusätzlicher Ausgaben.
-@item @code{native-search-paths} (Vorgabe: @code{'()})
-@itemx @code{search-paths} (Vorgabe: @code{'()})
-Eine Liste von @code{search-path-specification}-Objekten, die
-Umgebungsvariable für von diesem Paket beachtete Suchpfade (»search paths«)
-beschreiben.
-@item @code{replacement} (Vorgabe: @code{#f})
-Dies muss entweder @code{#f} oder ein package-Objekt sein, das als Ersatz
-(@dfn{replacement}) dieses Pakets benutzt werden soll. Im Abschnitt
-@ref{Sicherheitsaktualisierungen, grafts} wird dies erklärt.
-@item @code{synopsis}
-Eine einzeilige Beschreibung des Pakets.
-@item @code{description}
-Eine ausführlichere Beschreibung des Pakets.
-@item @code{license}
-@cindex Lizenz, von Paketen
-Die Lizenz des Pakets; benutzt werden kann ein Wert aus dem Modul
-@code{(guix licenses)} oder eine Liste solcher Werte.
-@item @code{home-page}
-Die URL, die die Homepage des Pakets angibt, als Zeichenkette.
-@item @code{supported-systems} (Vorgabe: @var{%supported-systems})
-Die Liste der vom Paket unterstützten Systeme als Zeichenketten der Form
-@code{Architektur-Kernel}, zum Beispiel @code{"x86_64-linux"}.
-@item @code{maintainers} (Vorgabe: @code{'()})
-Die Liste der Betreuer (Maintainer) des Pakets als
-@code{maintainer}-Objekte.
-@item @code{location} (Vorgabe: die Stelle im Quellcode, wo die @code{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.
-@end table
-@end deftp
-@deffn {Scheme Syntax} this-package
-When used in the @emph{lexical scope} of a package field definition, this
-identifier resolves to the package being defined.
-The example below shows how to add a package as a native input of itself
-when cross-compiling:
-@example
-(package
-  (name "guile")
-  ;; ...
-  ;; When cross-compiled, Guile, for example, depends on
-  ;; a native version of itself.  Add it here.
-  (native-inputs (if (%current-target-system)
-                     `(("self" ,this-package))
-                     '())))
-@end example
-It is an error to refer to @code{this-package} outside a package definition.
-@end deffn
-@node »origin«-Referenz
-@subsection @code{origin}-Referenz
-Dieser Abschnitt fasst alle Optionen zusammen, die in
-@code{origin}-Deklarationen zur Verfügung stehen (siehe @ref{Pakete definieren}).
-@deftp {Datentyp} origin
-Mit diesem Datentyp wird ein Ursprung, von dem Quellcode geladen werden
-kann, beschrieben.
-@table @asis
-@item @code{uri}
-Ein Objekt, was die URI des Quellcodes enthält. Der Objekttyp hängt von der
-@code{Methode} ab (siehe unten). Zum Beispiel sind, wenn die
-@var{url-fetch}-Methode aus @code{(guix download)} benutzt wird, die
-gültigen Werte für @code{uri}: eine URL dargestellt als Zeichenkette oder
-eine Liste solcher URLs.
-@item @code{method}
-Eine Prozedur, die die URI verwertet.
-Beispiele sind unter anderem:
-@table @asis
-@item @var{url-fetch} aus @code{(guix download)}
-Herunterladen einer Datei von einer HTTP-, HTTPS- oder FTP-URL, die im
-@code{uri}-Feld angegeben wurde.
-@vindex git-fetch
-@item @var{git-fetch} aus @code{(guix git-download)}
-Das im @code{uri}-Feld spezifizierte Repository des
-Git-Versionskontrollsystems klonen und davon den im @code{uri}-Feld als ein
-@code{git-reference}-Objekt angegebenen Commit benutzen; eine
-@code{git-reference} sieht so aus:
-@example
-(git-reference
-  (url "git://git.debian.org/git/pkg-shadow/shadow")
-  (commit "v4.1.5.1"))
-@end example
-@end table
-@item @code{sha256}
-Ein Bytevektor, der den SHA-256-Hash der Quelldateien
-enthält. Typischerweise wird hier mit der @code{base32}-Form der Bytevektor
-aus einer Base-32-Zeichenkette generiert.
-Diese Informationen liefert Ihnen der Befehl @code{guix download} (siehe
-@ref{Aufruf von guix download}) oder @code{guix hash} (siehe @ref{Aufruf von guix hash}).
-@item @code{file-name} (Vorgabe: @code{#f})
-Der Dateiname, unter dem der Quellcode abgespeichert werden sollte. Wenn er
-auf @code{#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.
-@item @code{patches} (Vorgabe: @code{'()})
-Eine Liste von Dateinamen, Ursprüngen oder dateiähnlichen Objekten (siehe
-@ref{G-Ausdrücke, file-like objects}) 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 @code{%current-system}
-oder @code{%current-target-system} abḧängen.
-@item @code{snippet} (Vorgabe: @code{#f})
-Ein im Quellcode-Verzeichnis auszuführender G-Ausdruck (siehe
-@ref{G-Ausdrücke}) oder S-Ausdruck. Hiermit kann der Quellcode bequem
-modifiziert werden, manchmal ist dies bequemer als mit einem Patch.
-@item @code{patch-flags} (Vorgabe: @code{'("-p1")})
-Eine Liste der Befehlszeilenoptionen, die dem @code{patch}-Befehl übergeben
-werden sollen.
-@item @code{patch-inputs} (Vorgabe: @code{#f})
-Eingabepakete oder -ableitungen für den Patch-Prozess. Bei @code{#f} werden
-die üblichen Patcheingaben wie GNU@tie{}Patch bereitgestellt.
-@item @code{modules} (Vorgabe: @code{'()})
-Eine Liste von Guile-Modulen, die während des Patch-Prozesses und während
-der Ausführung des @code{snippet}-Felds geladen werden sollten.
-@item @code{patch-guile} (Vorgabe: @code{#f})
-Welches Guile-Paket für den Patch-Prozess benutzt werden sollte. Bei
-@code{#f} wird ein vernünftiger Vorgabewert angenommen.
-@end table
-@end deftp
-@node Erstellungssysteme
-@section Erstellungssysteme
-@cindex Erstellungssystem
-Jede Paketdefinition legt ein @dfn{Erstellungssystem} (»build system«) sowie
-dessen Argumente fest (siehe @ref{Pakete definieren}). Das
-@code{build-system}-Feld steht für die Erstellungsprozedur des Pakets sowie
-für weitere implizite Eingaben für die Erstellungsprozedur.
-Erstellungssysteme sind @code{<build-system>}-Objekte. Die Schnittstelle, um
-solche zu erzeugen und zu verändern, ist im Modul @code{(guix build-system)}
-zu finden, und die eigentlichen Erstellungssysteme werden jeweils von ihren
-eigenen Modulen exportiert.
-@cindex Bag (systemnahe Paketrepräsentation)
-Intern funktionieren Erstellungssysteme, indem erst Paketobjekte zu
-@dfn{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
-@ref{Ableitungen}).
-Erstellungssysteme akzeptieren optional eine Liste von @dfn{Argumenten}. In
-Paketdefinitionen werden diese über das @code{arguments}-Feld übergeben
-(siehe @ref{Pakete definieren}). Sie sind in der Regel
-Schlüsselwort-Argumente (siehe @ref{Optional Arguments, keyword arguments in
-Guile,, guile, GNU Guile Reference Manual}). Der Wert dieser Argumente wird
-normalerweise vom Erstellungssystem in der @dfn{Erstellungsschicht}
-ausgewertet, d.h.@: von einem durch den Daemon gestarteten Guile-Prozess
-(siehe @ref{Ableitungen}).
-Das häufigste Erstellungssystem ist @var{gnu-build-system}, was die übliche
-Erstellungsprozedur für GNU-Pakete und viele andere Pakete darstellt. Es
-wird vom Modul @code{(guix build-system gnu)} bereitgestellt.
-@defvr {Scheme-Variable} gnu-build-system
-@var{gnu-build-system} steht für das GNU-Erstellungssystem und Varianten
-desselben (siehe @ref{Configuration, configuration and makefile
-conventions,, standards, GNU Coding Standards}).
-@cindex Erstellungsphasen
-Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt und
-installiert mit der üblichen Befehlsfolge @code{./configure && make && make
-check && make install}. In der Praxis braucht man oft noch ein paar weitere
-Schritte. Alle Schritte sind in voneinander getrennte @dfn{Phasen}
-unterteilt. Erwähnt werden sollten@footnote{Bitte schauen Sie in den Modulen
-unter @code{(guix build gnu-build-system)}, wenn Sie mehr Details zu
-Erstellungsphasen brauchen.}:
-@table @code
-@item 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.
-@item patch-source-shebangs
-»Shebangs« in Quelldateien beheben, damit Sie sich auf die richtigen
-Store-Dateipfade beziehen. Zum Beispiel könnte @code{#!/bin/sh} zu
-@code{#!/gnu/store/@dots{}-bash-4.3/bin/sh} geändert werden.
-@item configure
-Das Skript @file{configure} mit einigen vorgegebenen Befehlszeilenoptionen
-ausführen, wie z.B.@: mit @code{--prefix=/gnu/store/@dots{}}, sowie mit den
-im @code{#:configure-flags}-Argument angegebenen Optionen.
-@item build
-@code{make} ausführen mit den Optionen aus der Liste in
-@code{#:make-flags}. Wenn das Argument @code{#:parallel-build?} auf wahr
-gesetzt ist (was der Vorgabewert ist), wird @code{make -j} zum Erstellen
-ausgeführt.
-@item check
-@code{make check} (oder statt @code{check} ein anderes bei
-@code{#:test-target} angegebenes Ziel) ausführen, außer falls @code{#:tests?
-#f} gesetzt ist. Wenn das Argument @code{#:parallel-tests?} auf wahr gesetzt
-ist (der Vorgabewert), führe @code{make check -j} aus.
-@item install
-@code{make install} mit den in @code{#:make-flags} aufgelisteten Optionen
-ausführen.
-@item patch-shebangs
-Shebangs in den installierten ausführbaren Dateien beheben.
-@item strip
-Symbole zur Fehlerbehebung aus ELF-Dateien entfernen (außer
-@code{#:strip-binaries?} ist auf falsch gesetzt) und in die
-@code{debug}-Ausgabe kopieren, falls diese verfügbar ist (siehe
-@ref{Dateien zur Fehlersuche installieren}).
-@end table
-@vindex %standard-phases
-Das erstellungsseitige Modul @code{(guix build gnu-build-system)} definiert
-@var{%standard-phases} als die vorgegebene Liste der
-Erstellungsphasen. @var{%standard-phases} ist eine Liste von Paaren aus je
-einem Symbol und einer Prozedur. Letztere implementiert die eigentliche
-Phase.
-Die Liste der Phasen, die für ein bestimmtes Paket verwendet werden sollen,
-kann vom Parameter @code{#:phases} überschrieben werden. Zum Beispiel werden
-bei Übergabe von:
-@example
-#:phases (modify-phases %standard-phases (delete 'configure))
-@end example
-alle oben beschriebenen Phasen benutzt außer der @code{configure}-Phase.
-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 @code{(guix build-system gnu)} für eine vollständige
-Liste). Wir bezeichnen sie als @dfn{implizite Eingaben} eines Pakets, weil
-Paketdefinitionen sie nicht aufführen müssen.
-@end defvr
-Andere @code{<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
-@var{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.
-@defvr {Scheme-Variable} ant-build-system
-Diese Variable wird vom Modul @code{(guix build-system ant)} exportiert. Sie
-implementiert die Erstellungsprozedur für Java-Pakete, die mit dem
-@url{http://ant.apache.org/, Ant build tool} erstellt werden können.
-Sowohl @code{ant} als auch der @dfn{Java Development Kit} (JDK), wie er vom
-Paket @code{icedtea} bereitgestellt wird, werden zu den Eingaben
-hinzugefügt. Wenn andere Pakete dafür benutzt werden sollen, können sie
-jeweils mit den Parametern @code{#:ant} und @code{#:jdk} festgelegt werden.
-Falls das ursprüngliche Paket über keine nutzbare Ant-Erstellungsdatei
-(»Ant-Buildfile«) verfügt, kann aus der Angabe im Parameter
-@code{#:jar-name} eine minimale Ant-Erstellungsdatei @file{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 @code{#:source-dir} benutzt werden, um das
-Unterverzeichnis mit dem Quellcode anzugeben; sein Vorgabewert ist »src«.
-Der Parameter @code{#: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 @code{#:test-include} kann eine Liste angegeben
-werden, welche Junit-Tests auszuführen sind. Der Vorgabewert ist @code{(list
-"**/*Test.java")}. Mit @code{#:test-exclude} kann ein Teil der Testdateien
-ignoriert werden. Der Vorgabewert ist @code{(list "**/Abstract*.java")},
-weil abstrakte Klassen keine ausführbaren Tests enthalten können.
-Der Parameter @code{#:build-target} kann benutzt werden, um die Ant-Aufgabe
-(Task) anzugeben, die während der @code{build}-Phase ausgeführt werden
-soll. Vorgabe ist, dass die Aufgabe (Task) »jar« ausgeführt wird.
-@end defvr
-@defvr {Scheme-Variable} android-ndk-build-system
-@cindex Android-Distribution
-@cindex Android-NDK-Erstellungssystem
-Diese Variable wird von @code{(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.
-@end defvr
-@defvr {Scheme-Variable} asdf-build-system/source
-@defvrx {Scheme-Variable} asdf-build-system/sbcl
-@defvrx {Scheme-Variable} asdf-build-system/ecl
-Diese Variablen, die vom Modul @code{(guix build-system asdf)} exportiert
-werden, implementieren Erstellungsprozeduren für Common-Lisp-Pakete, welche
-@url{https://common-lisp.net/project/asdf/, »ASDF«} benutzen. ASDF dient der
-Systemdefinition für Common-Lisp-Programme und -Bibliotheken.
-Das Erstellungssystem @code{asdf-build-system/source} installiert die Pakete
-in Quellcode-Form und kann @i{via} ASDF mit jeder
-Common-Lisp-Implementierung geladen werden. Die anderen Erstellungssysteme
-wie @code{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.@:
-@code{sbcl-} für @code{asdf-build-system/sbcl}.
-Zudem sollte das entsprechende Quellcode-Paket mit der Konvention wie bei
-Python-Paketen (siehe @ref{Python-Module}) ein @code{cl-} als Präfix
-bekommen.
-Für Binärpakete sollte für jedes System ein Guix-Paket definiert
-werden. Wenn für einen Ursprung im @code{origin} mehrere Systeme enthalten
-sind, können Paketvarianten geschrieben werden, mit denen alle Systeme
-erstellt werden. Quellpakete, die @code{asdf-build-system/source} benutzen,
-können mehrere Systeme enthalten.
-Um ausführbare Programme und Abbilder zu erzeugen, können die
-erstellungsseitigen Prozeduren @code{build-program} und @code{build-image}
-benutzt werden. Sie sollten in einer Erstellungsphase nach der
-@code{create-symlinks}-Phase aufgerufen werden, damit das gerade erstellte
-System Teil des resultierenden Abbilds sein kann. An @code{build-program}
-muss eine Liste von Common-Lisp-Ausdrücken über das Argument
-@code{#:entry-program} übergeben werden.
-Wenn das System nicht in seiner eigenen gleichnamigen @code{.asd}-Datei
-definiert ist, sollte der Parameter @code{#:asd-file} benutzt werden, um
-anzugeben, in welcher Datei das System definiert ist. Außerdem wird bei
-Paketen, für deren Tests ein System in einer separaten Datei definiert
-wurde, dieses System geladen, bevor die Tests ablaufen, wenn es im Parameter
-@code{#:test-asd-file} steht. Ist dafür kein Wert gesetzt, werden die
-Dateien @code{<system>-tests.asd}, @code{<system>-test.asd},
-@code{tests.asd} und @code{test.asd} durchsucht, wenn sie existieren.
-Wenn aus irgendeinem Grund der Paketname nicht den Namenskonventionen folgen
-kann, kann der Parameter @code{#:asd-system-name} benutzt werden, um den
-Namen des Systems anzugeben.
-@end defvr
-@defvr {Scheme-Variable} cargo-build-system
-@cindex Rust-Programmiersprache
-@cindex Cargo (Rust-Erstellungssystem)
-Diese Variable wird vom Modul @code{(guix build-system cargo)}
-exportiert. Damit können Pakete mit Cargo erstellt werden, dem
-Erstellungswerkzeug der @uref{https://www.rust-lang.org,
-Rust-Programmiersprache}.
-In seiner @code{configure}-Phase ersetzt dieses Erstellungssystem in der
-Datei @file{Carto.toml} angegebene Abhängigkeiten durch Eingaben im
-Guix-Paket. Die Phase @code{install} installiert die Binärdateien und auch
-den Quellcode und die @file{Cargo.toml}-Datei.
-@end defvr
-@cindex Clojure (Programmiersprache)
-@cindex einfaches Clojure-Erstellungssystem
-@defvr {Scheme-Variable} clojure-build-system
-Diese Variable wird durch das Modul @code{(guix build-system clojure)}
-exportiert. Sie implementiert eine einfache Erstellungsprozedur für in
-@uref{https://clojure.org/, Clojure} geschriebene Pakete mit dem guten alten
-@code{compile} in Clojure. Cross-Kompilieren wird noch nicht unterstützt.
-Das Erstellungssystem fügt @code{clojure}, @code{icedtea} und @code{zip} zu
-den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können
-diese jeweils mit den Parametern @code{#:clojure}, @code{#:jdk} und
-@code{#:zip} spezifiziert werden.
-Eine Liste der Quellcode-Verzeichnisse, Test-Verzeichnisse und Namen der
-Jar-Dateien können jeweils über die Parameter @code{#:source-dirs},
-@code{#:test-dirs} und @code{#:jar-names} angegeben werden. Das Verzeichnis,
-in das kompiliert wird, sowie die Hauptklasse können jeweils mit den
-Parametern @code{#:compile-dir} und @code{#:main-class} angegeben
-werden. Andere Parameter sind im Folgenden dokumentiert.
-Dieses Erstellungssystem ist eine Erweiterung des @var{ant-build-system},
-bei der aber die folgenden Phasen geändert wurden:
-@table @code
-@item build
-Diese Phase ruft @code{compile} in Clojure auf, um Quelldateien zu
-kompilieren, und führt @command{jar} aus, um Jar-Dateien aus sowohl
-Quelldateien als auch kompilierten Dateien zu erzeugen, entsprechend der
-jeweils in @code{#:aot-include} und @code{#: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 @code{#:all} entsprechen, was für alle im
-Quellverzeichis gefundenen Clojure-Bibliotheken steht. Der Parameter
-@code{#:omit-source?} entscheidet, ob Quelldateien in die Jar-Archive
-aufgenommen werden sollten.
-@item check
-In dieser Phase werden Tests auf die durch Einschluss- und Ausschlussliste
-@code{#:test-include} bzw. @code{#:test-exclude} angegebenen Dateien
-ausgeführt. Deren Bedeutung ist analog zu @code{#:aot-include} und
-@code{#:aot-exclude}, außer dass das besondere Schlüsselwort @code{#:all}
-jetzt für alle Clojure-Bibliotheken in den Test-Verzeichnissen steht. Der
-Parameter @code{#:tests?} entscheidet, ob Tests ausgeführt werden sollen.
-@item install
-In dieser Phase werden alle zuvor erstellten Jar-Dateien installiert.
-@end table
-Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch
-eine weitere Phase.
-@table @code
-@item install-doc
-Diese Phase installiert alle Dateien auf oberster Ebene, deren Basisnamen
-ohne Verzeichnisangabe zu @var{%doc-regex} passen. Ein anderer regulärer
-Ausdruck kann mit dem Parameter @code{#:doc-regex} verwendet werden. All die
-so gefundenen oder (rekursiv) in den mit @code{#:doc-dirs} angegebenen
-Dokumentationsverzeichnissen liegenden Dateien werden installiert.
-@end table
-@end defvr
-@defvr {Scheme-Variable} cmake-build-system
-Diese Variable wird von @code{(guix build-system cmake)} exportiert. Sie
-implementiert die Erstellungsprozedur für Pakete, die das
-@url{http://www.cmake.org, CMake-Erstellungswerkzeug} benutzen.
-Das Erstellungssystem fügt automatisch das Paket @code{cmake} zu den
-Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter
-@code{#:cmake} geändert werden.
-Der Parameter @code{#:configure-flags} wird als Liste von
-Befehlszeilenoptionen aufgefasst, die an den Befehl @command{cmake}
-übergeben werden. Der Parameter @code{#:build-type} abstrahiert, welche
-Befehlszeilenoptionen dem Compiler übergeben werden; der Vorgabewert ist
-@code{"RelWithDebInfo"} (kurz für »release mode with debugging
-information«), d.h.@: kompiliert wird für eine Produktionsumgebung und
-Informationen zur Fehlerbehebung liegen bei, was ungefähr @code{-O2 -g}
-entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete.
-@end defvr
-@defvr {Scheme-Variable} dune-build-system
-Diese Variable wird vom Modul @code{(guix build-system dune)}
-exportiert. Sie unterstützt es, Pakete mit @uref{https://dune.build/, Dune}
-zu erstellen, einem Erstellungswerkzeug für die Programmiersprache OCaml,
-und ist als Erweiterung des unten beschriebenen OCaml-Erstellungssystems
-@code{ocaml-build-system} implementiert. Als solche können auch die
-Parameter @code{#:ocaml} und @code{#:findlib} an dieses Erstellungssystem
-übergeben werden.
-Das Erstellungssystem fügt automatisch das Paket @code{dune} zu den Eingaben
-hinzu. Welches Paket benutzt wird, kann mit dem Parameter @code{#:dune}
-geändert werden.
-There is no @code{configure} phase because dune packages typically don't
-need to be configured.  The @code{#:build-flags} parameter is taken as a
-list of flags passed to the @code{dune} command during the build.
-The @code{#:jbuild?} parameter can be passed to use the @code{jbuild}
-command instead of the more recent @code{dune} command while building a
-package.  Its default value is @code{#f}.
-The @code{#:package} parameter can be passed to specify a package name,
-which is useful when a package contains multiple packages and you want to
-build only one of them.  This is equivalent to passing the @code{-p}
-argument to @code{dune}.
-@end defvr
-@defvr {Scheme-Variable} go-build-system
-Diese Variable wird vom Modul @code{(guix build-system go)} exportiert. Mit
-ihr ist eine Erstellungsprozedur für Go-Pakete implementiert, die dem
-normalen
-@url{https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies,
-Go-Erstellungsmechanismus} entspricht.
-Beim Aufruf wird ein Wert für den Schlüssel @code{#:import-path} und
-manchmal auch für @code{#:unpack-path} erwartet.  Der
-@url{https://golang.org/doc/code.html#ImportPaths, »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 @code{#:unpack-path} angegeben werden.
-Pakete, die Go-Bibliotheken zur Verfügung stellen, sollten ihren Quellcode
-auch in die Erstellungsausgabe installieren. Der Schlüssel
-@code{#:install-source?}, sein Vorgabewert ist @code{#t}, steuert, ob
-Quellcode installiert wird. Bei Paketen, die nur ausführbare Dateien
-liefern, kann der Wert auf @code{#f} gesetzt werden.
-@end defvr
-@defvr {Scheme-Variable} glib-or-gtk-build-system
-Diese Variable wird vom Modul @code{(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
-@var{gnu-build-system} hinzu:
-@table @code
-@item glib-or-gtk-wrap
-Die Phase @code{glib-or-gtk-wrap} stellt sicher, dass Programme in
-@file{bin/} in der Lage sind, GLib-»Schemata« und
-@uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, 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
-@code{XDG_DATA_DIRS} und @code{GTK_PATH} aufruft.
-Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess
-auszunehmen, indem Sie eine Liste ihrer Namen im Parameter
-@code{#: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.
-@item glib-or-gtk-compile-schemas
-Mit der Phase @code{glib-or-gtk-compile-schemas} wird sichergestellt, dass
-alle @uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html,
-GSettings-Schemata} für GLib kompiliert werden. Dazu wird das Programm
-@command{glib-compile-schemas} ausgeführt. Es kommt aus dem Paket
-@code{glib:bin}, was automatisch vom Erstellungssystem importiert
-wird. Welches @code{glib}-Paket dieses @command{glib-compile-schemas}
-bereitstellt, kann mit dem Parameter @code{#:glib} spezifiziert werden.
-@end table
-Beide Phasen finden nach der @code{install}-Phase statt.
-@end defvr
-@defvr {Scheme-Variable} guile-build-system
-Dieses Erstellungssystem ist für Guile-Pakete gedacht, die nur aus
-Scheme-Code bestehen und so schlicht sind, dass sie nicht einmal ein
-Makefile und erst recht keinen @file{configure}-Skript enthalten. Hierzu
-wird Scheme-Code mit @command{guild compile} kompiliert (siehe
-@ref{Compilation,,, guile, GNU Guile Reference Manual}) und die @file{.scm}-
-und @file{.go}-Dateien an den richtigen Pfad installiert. Auch Dokumentation
-wird installiert.
-Das Erstellungssystem unterstützt Cross-Kompilieren durch die
-Befehlszeilenoption @code{--target} für @command{guild compile}.
-Mit @code{guile-build-system} erstellte Pakete müssen ein Guile-Paket in
-ihrem @code{native-inputs}-Feld aufführen.
-@end defvr
-@defvr {Scheme-Variable} minify-build-system
-Diese Variable wird vom Modul @code{(guix build-system minify)}
-exportiert. Sie implementiert eine Prozedur zur Minifikation einfacher
-JavaScript-Pakete.
-Es fügt @code{uglify-js} zur Menge der Eingaben hinzu und komprimiert damit
-alle JavaScript-Dateien im @file{src}-Verzeichnis. Ein anderes Programm zur
-Minifikation kann verwendet werden, indem es mit dem Parameter
-@code{#: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 @file{src}-Verzeichnis
-liegen, kann mit dem Parameter @code{#:javascript-files} eine Liste der
-Dateinamen übergeben werden, auf die das Minifikationsprogramm aufgerufen
-wird.
-@end defvr
-@defvr {Scheme-Variable} ocaml-build-system
-Diese Variable wird vom Modul @code{(guix build-system ocaml)}
-exportiert. Mit ihr ist ein Erstellungssystem für @uref{https://ocaml.org,
-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 @file{setup.ml} auf oberster Ebene vorhanden ist,
-wird @code{ocaml setup.ml -configure}, @code{ocaml setup.ml -build} und
-@code{ocaml setup.ml -install} ausgeführt. Das Erstellungssystem wird
-annehmen, dass die Datei durch @uref{http://oasis.forge.ocamlcore.org/,
-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 @code{#:configure-flags} und
-@code{#:build-flags} übergeben. Der Schlüssel @code{#:test-flags} kann
-übergeben werden, um die Befehlszeilenoptionen zu ändern, mit denen die
-Tests aktiviert werden. Mit dem Parameter @code{#:use-make?} kann dieses
-Erstellungssystem für die build- und install-Phasen abgeschaltet werden.
-Verfügt das Paket über eine @file{configure}-Datei, wird angenommen, dass
-diese von Hand geschrieben wurde mit einem anderen Format für Argumente als
-bei einem Skript des @code{gnu-build-system}. Sie können weitere
-Befehlszeilenoptionen mit dem Schlüssel @code{#:configure-flags} hinzufügen.
-Falls dem Paket ein @file{Makefile} beiliegt (oder @code{#:use-make?} auf
-@code{#t} gesetzt wurde), wird dieses benutzt und weitere
-Befehlszeilenoptionen können mit dem Schlüssel @code{#: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 @code{ocaml
-pkg/pkg.ml} oder @code{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 @code{#:build-flags}
-übergeben werden. Um die Installation kümmert sich
-@command{opam-installer}. In diesem Fall muss das @code{opam}-Paket im
-@code{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
-@file{.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 @code{CAML_LD_LIBRARY_PATH}. Diese Umgebungsvariable
-zeigt auf @file{lib/ocaml/site-lib/stubslibs} und dorthin sollten
-@file{.so}-Bibliotheken installiert werden.
-@end defvr
-@defvr {Scheme-Variable} python-build-system
-Diese Variable wird vom Modul @code{(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
-@code{python setup.py build} ausgeführt und dann @code{python setup.py
-install --prefix=/gnu/store/@dots{}}.
-Für Pakete, die eigenständige Python-Programme nach @code{bin/}
-installieren, sorgt dieses Erstellungssystem dafür, dass die Programme in
-ein Wrapper-Skript verpackt werden, welches die eigentlichen Programme mit
-einer Umgebungsvariablen @code{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 @code{#:python} bestimmt werden. Das ist nützlich, wenn wir
-erzwingen wollen, dass ein Paket mit einer bestimmten Version des
-Python-Interpretierers arbeitet, was nötig sein kann, wenn das Programm nur
-mit einer einzigen Interpretiererversion kompatibel ist.
-Standardmäßig ruft Guix @code{setup.py} auf, was zu @code{setuptools}
-gehört, ähnlich wie es auch @command{pip} tut. Manche Pakete sind mit
-setuptools (und pip) inkompatibel, deswegen können Sie diese Einstellung
-abschalten, indem Sie den Parameter @code{#:use-setuptools} auf @code{#f}
-setzen.
-@end defvr
-@defvr {Scheme-Variable} perl-build-system
-Diese Variable wird vom Modul @code{(guix build-system perl)}
-exportiert. Mit ihr wird die Standard-Erstellungsprozedur für Perl-Pakete
-implementiert, welche entweder darin besteht, @code{perl Build.PL
--prefix=/gnu/store/@dots{}} gefolgt von @code{Build} und @code{Build
-install} auszuführen, oder @code{perl Makefile.PL PREFIX=/gnu/store/@dots{}}
-gefolgt von @code{make} und @code{make install} auszuführen, je nachdem, ob
-eine Datei @code{Build.PL} oder eine Datei @code{Makefile.PL} in der
-Paketdistribution vorliegt. Den Vorrang hat erstere, wenn sowohl
-@code{Build.PL} als auch @code{Makefile.PL} in der Paketdistribution
-existieren. Der Vorrang kann umgekehrt werden, indem @code{#t} für den
-Parameter @code{#:make-maker?} angegeben wird.
-Der erste Aufruf von @code{perl Makefile.PL} oder @code{perl Build.PL}
-übergibt die im Parameter @code{#:make-maker-flags}
-bzw. @code{#:module-build-flags} angegebenen Befehlszeilenoptionen, je
-nachdem, was verwendet wird.
-Welches Perl-Paket dafür benutzt wird, kann mit @code{#:perl} angegeben
-werden.
-@end defvr
-@defvr {Scheme-Variable} r-build-system
-Diese Variable wird vom Modul @code{(guix build-system r)} exportiert. Sie
-entspricht einer Implementierung der durch @uref{http://r-project.org,
-R}-Pakete genutzten Erstellungsprozedur, die wenig mehr tut, als @code{R CMD
-INSTALL --library=/gnu/store/@dots{}} in einer Umgebung auszuführen, in der
-die Umgebungsvariable @code{R_LIBS_SITE} die Pfade aller R-Pakete unter den
-Paketeingaben enthält. Tests werden nach der Installation mit der R-Funktion
-@code{tools::testInstalledPackage} ausgeführt.
-@end defvr
-@defvr {Scheme-Variable} rakudo-build-system
-This variable is exported by @code{(guix build-system rakudo)} It implements
-the build procedure used by @uref{https://rakudo.org/, Rakudo} for
-@uref{https://perl6.org/, Perl6} packages. It installs the package to
-@code{/gnu/store/@dots{}/NAME-VERSION/share/perl6} and installs the
-binaries, library files and the resources, as well as wrap the files under
-the @code{bin/} directory.  Tests can be skipped by passing @code{#f} to the
-@code{tests?} parameter.
-Which rakudo package is used can be specified with @code{rakudo}.  Which
-perl6-tap-harness package used for the tests can be specified with
-@code{#:prove6} or removed by passing @code{#f} to the @code{with-prove6?}
-parameter.  Which perl6-zef package used for tests and installing can be
-specified with @code{#:zef} or removed by passing @code{#f} to the
-@code{with-zef?} parameter.
-@end defvr
-@defvr {Scheme-Variable} texlive-build-system
-Diese Variable wird vom Modul @code{(guix build-system texlive)}
-exportiert. Mit ihr werden TeX-Pakete in Stapelverarbeitung (»batch mode«)
-mit der angegebenen Engine erstellt. Das Erstellungssystem setzt die
-Variable @code{TEXINPUTS} so, dass alle TeX-Quelldateien unter den Eingaben
-gefunden werden können.
-Standardmäßig wird @code{luatex} auf allen Dateien mit der Dateiendung
-@code{ins} ausgeführt. Eine andere Engine oder ein anderes Format kann mit
-dem Argument @code{#:tex-format} angegeben werden. Verschiedene
-Erstellungsziele können mit dem Argument @code{#:build-targets} festgelegt
-werden, das eine Liste von Dateinamen erwartet. Das Erstellungssystem fügt
-nur @code{texlive-bin} und @code{texlive-latex-base} zu den Eingaben hinzu
-(beide kommen aus dem Modul @code{(gnu packages tex}). Für beide kann das zu
-benutzende Paket jeweils mit den Argumenten @code{#:texlive-bin} oder
-@code{#:texlive-latex-base} geändert werden.
-Der Parameter @code{#:tex-directory} sagt dem Erstellungssystem, wohin die
-installierten Dateien im texmf-Verzeichnisbaum installiert werden sollen.
-@end defvr
-@defvr {Scheme-Variable} ruby-build-system
-Diese Variable wird vom Modul @code{(guix build-system ruby)}
-exportiert. Sie steht für eine Implementierung der
-RubyGems-Erstellungsprozedur, die für Ruby-Pakete benutzt wird, wobei
-@code{gem build} gefolgt von @code{gem install} ausgeführt wird.
-Das @code{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 @code{#:ruby}
-festgelegt werden. Eine Liste zusätzlicher Befehlszeilenoptionen für den
-Aufruf des @command{gem}-Befehls kann mit dem Parameter @code{#:gem-flags}
-angegeben werden.
-@end defvr
-@defvr {Scheme-Variable} waf-build-system
-Diese Variable wird durch das Modul @code{(guix build-system waf)}
-exportiert. Damit ist eine Erstellungsprozedur rund um das @code{waf}-Skript
-implementiert. Die üblichen Phasen — @code{configure}, @code{build} und
-@code{install} — sind implementiert, indem deren Namen als Argumente an das
-@code{waf}-Skript übergeben werden.
-Das @code{waf}-Skript wird vom Python-Interpetierer ausgeführt. Mit welchem
-Python-Paket das Skript ausgeführt werden soll, kann mit dem Parameter
-@code{#:python} angegeben werden.
-@end defvr
-@defvr {Scheme-Variable} scons-build-system
-Diese Variable wird vom Modul @code{(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 @code{scons} aus, um das Paket zu
-erstellen, führt mit @code{scons test} Tests aus und benutzt @code{scons
-install}, um das Paket zu installieren.
-Zusätzliche Optionen, die an @code{scons} übergeben werden sollen, können
-mit dem Parameter @code{#:scons-flags} angegeben werden. Die Python-Version,
-die benutzt werden soll, um SCons auszuführen, kann festgelegt werden, indem
-das passende SCons-Paket mit dem Parameter @code{#:scons} ausgewählt wird.
-@end defvr
-@defvr {Scheme-Variable} haskell-build-system
-Diese Variable wird vom Modul @code{(guix build-system haskell)}
-exportiert. Sie bietet Zugang zur Cabal-Erstellungsprozedur, die von
-Haskell-Paketen benutzt wird, was bedeutet, @code{runhaskell Setup.hs
-configure --prefix=/gnu/store/@dots{}} und @code{runhaskell Setup.hs build}
-auszuführen. Statt das Paket mit dem Befehl @code{runhaskell Setup.hs
-install} zu installieren, benutzt das Erstellungssystem @code{runhaskell
-Setup.hs copy} gefolgt von @code{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 @code{runhaskell Setup.hs haddock}, außer
-@code{#:haddock? #f} wurde übergeben. Optional können an Haddock Parameter
-mit Hilfe des Parameters @code{#:haddock-flags} übergeben werden. Wird die
-Datei @code{Setup.hs} nicht gefunden, sucht das Erstellungssystem
-stattdessen nach @code{Setup.lhs}.
-Welcher Haskell-Compiler benutzt werden soll, kann über den
-@code{#:haskell}-Parameter angegeben werden. Als Vorgabewert verwendet er
-@code{ghc}.
-@end defvr
-@defvr {Scheme-Variable} dub-build-system
-Diese Variable wird vom Modul @code{(guix build-system dub)} exportiert. Sie
-verweist auf eine Implementierung des Dub-Erstellungssystems, das von
-D-Paketen benutzt wird. Dabei werden @code{dub build} und @code{dub run}
-ausgeführt. Die Installation wird durch manuelles Kopieren der Dateien
-durchgeführt.
-Welcher D-Compiler benutzt wird, kann mit dem Parameter @code{#:ldc}
-festgelegt werden, was als Vorgabewert @code{ldc} benutzt.
-@end defvr
-@defvr {Scheme-Variable} emacs-build-system
-Diese Variable wird vom Modul @code{(guix build-system emacs)}
-exportiert. Darin wird eine Installationsprozedur ähnlich der des
-Paketsystems von Emacs selbst implementiert (siehe @ref{Packages,,, emacs,
-The GNU Emacs Manual}).
-Zunächst wird eine Datei @code{@var{Paket}-autoloads.el} erzeugt, dann
-werden alle Emacs-Lisp-Dateien zu Bytecode kompiliert. Anders als beim
-Emacs-Paketsystem werden die Info-Dokumentationsdateien in das
-Standardverzeichnis für Dokumentation verschoben und die Datei @file{dir}
-gelöscht. Jedes Paket wird in sein eigenes Verzeichnis unter
-@file{share/emacs/site-lisp/guix.d} installiert.
-@end defvr
-@defvr {Scheme-Variable} font-build-system
-Diese Variable wird vom Modul @code{(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.
-@end defvr
-@defvr {Scheme-Variable} meson-build-system
-Diese Variable wird vom Modul @code{(guix build-system meson)}
-exportiert. Sie enthält die Erstellungsprozedur für Pakete, die
-@url{http://mesonbuild.com, Meson} als ihr Erstellungssystem benutzen.
-Mit ihr werden sowohl Meson als auch @uref{https://ninja-build.org/, Ninja}
-zur Menge der Eingaben hinzugefügt; die Pakete dafür können mit den
-Parametern @code{#:meson} und @code{#:ninja} geändert werden, wenn
-nötig. Das vorgegebene Meson-Paket ist @code{meson-for-build}, ein
-besonderes Paket, dessen Besonderheit darin besteht, den @code{RUNPATH} von
-Binärdateien und Bibliotheken @emph{nicht} zu entfernen, wenn sie
-installiert werden.
-Dieses Erstellungssystem ist eine Erweiterung für das
-@var{gnu-build-system}, aber mit Änderungen an den folgenden Phasen, die
-Meson-spezifisch sind:
-@table @code
-@item configure
-Diese Phase führt den @code{meson}-Befehl mit den in
-@code{#:configure-flags} angegebenen Befehlszeilenoptionen aus. Die
-Befehlszeilenoption @code{--build-type} wird immer auf @code{plain} gesetzt,
-solange nichts anderes mit dem Parameter @code{#:build-type} angegeben
-wurde.
-@item build
-Diese Phase ruft @code{ninja} auf, um das Paket standardmäßig parallel zu
-erstellen. Die Vorgabeeinstellung, dass parallel erstellt wird, kann
-verändert werden durch Setzen von @code{#:parallel-build?}.
-@item check
-Diese Phase führt @code{ninja} mit dem als @code{#:test-target}
-spezifizierten Ziel für Tests auf, der Vorgabewert ist das Ziel namens
-@code{"test"}.
-@item install
-Diese Phase führt @code{ninja install} aus und kann nicht verändert werden.
-@end table
-Dazu fügt das Erstellungssystem noch folgende neue Phasen:
-@table @code
-@item 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
-@code{RUNPATH} hinzugefügt, wann immer es nötig ist. Auch werden diejenigen
-Referenzen zu Bibliotheken aus der Erstellungsphase wieder entfernt, die bei
-@code{meson-for-build} hinzugefügt wurden, aber eigentlich zur Laufzeit
-nicht gebraucht werden, wie Abhängigkeiten nur für Tests.
-@item glib-or-gtk-wrap
-Diese Phase ist dieselbe, die auch im @code{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
-@code{#:glib-or-gtk?} aktiviert werden.
-@item glib-or-gtk-compile-schemas
-Diese Phase ist dieselbe, die auch im @code{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
-@code{#:glib-or-gtk?} aktiviert werden.
-@end table
-@end defvr
-@defvr {Scheme Variable} linux-module-build-system
-@var{linux-module-build-system} allows building Linux kernel modules.
-@cindex Erstellungsphasen
-This build system is an extension of @var{gnu-build-system}, but with the
-following phases changed:
-@table @code
-@item configure
-This phase configures the environment so that the Linux kernel's Makefile
-can be used to build the external kernel module.
-@item build
-This phase uses the Linux kernel's Makefile in order to build the external
-kernel module.
-@item install
-This phase uses the Linux kernel's Makefile in order to install the external
-kernel module.
-@end table
-It is possible and useful to specify the Linux kernel to use for building
-the module (in the "arguments" form of a package using the
-linux-module-build-system, use the key #:linux to specify it).
-@end defvr
-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.
-@defvr {Scheme-Variable} trivial-build-system
-Diese Variable wird vom Modul @code{(guix build-system trivial)} exportiert.
-Diesem Erstellungssystem muss im Argument @code{#:builder} ein
-Scheme-Ausdruck übergeben werden, der die Paketausgabe(n) erstellt — wie bei
-@code{build-expression->derivation} (siehe @ref{Ableitungen,
-@code{build-expression->derivation}}).
-@end defvr
-@node Der Store
-@section Der Store
-@cindex Store
-@cindex Store-Objekte
-@cindex Store-Pfade
-Konzeptionell ist der @dfn{Store} der Ort, wo Ableitungen nach erfolgreicher
-Erstellung gespeichert werden — standardmäßig finden Sie ihn in
-@file{/gnu/store}. Unterverzeichnisse im Store werden @dfn{Store-Objekte}
-oder manchmal auch @dfn{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 @emph{gültig} sind, also Ergebnisse erfolgreicher Erstellungen
-sind. Die Datenbank befindet sich in @file{@var{localstatedir}/guix/db},
-wobei @var{localstatedir} das mit @option{--localstatedir} bei der
-Ausführung von »configure« angegebene Zustandsverzeichnis ist, normalerweise
-@file{/var}.
-Auf den Store wird @emph{nur} durch den Daemon im Auftrag seiner Clients
-zugegriffen (siehe @ref{Aufruf des guix-daemon}). Um den Store zu verändern,
-verbinden sich Clients über einen Unix-Socket mit dem Daemon, senden ihm
-entsprechende Anfragen und lesen dann dessen Antwort — so etwas nennt sich
-entfernter Prozeduraufruf (englisch »Remote Procedure Call« oder kurz RPC).
-@quotation Anmerkung
-Benutzer dürfen @emph{niemals} Dateien in @file{/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 @ref{Einführung}).
-Siehe @ref{Aufruf von guix gc, @command{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.
-@end quotation
-Das Modul @code{(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 @code{open-connection},
-und daher allen @command{guix}-Befehlen, ist, sich mit dem lokalen Daemon
-oder dem an der in der Umgebungsvariablen @code{GUIX_DAEMON_SOCKET}
-angegeben URL zu verbinden.
-@defvr {Umgebungsvariable} GUIX_DAEMON_SOCKET
-Ist diese Variable gesetzt, dann sollte ihr Wert ein Dateipfad oder eine URI
-sein, worüber man sich mit dem Daemon verbinden kann. Ist der Wert der Pfad
-zu einer Datei, bezeichnet dieser einen Unix-Socket, mit dem eine Verbindung
-hergestellt werden soll. Ist er eine URI, so werden folgende URI-Schemata
-unterstützt:
-@table @code
-@item file
-@itemx unix
-Für Unix-Sockets. @code{file:///var/guix/daemon-socket/socket} kann
-gleichbedeutend auch als @file{/var/guix/daemon-socket/socket} angegeben
-werden.
-@item guix
-@cindex Daemon, Fernzugriff
-@cindex Fernzugriff auf den Daemon
-@cindex Daemon, Einrichten auf Clustern
-@cindex Cluster, Einrichtung des Daemons
-Solche URIs benennen Verbindungen über TCP/IP ohne Verschlüsselung oder
-Authentifizierung des entfernten Rechners. Die URI muss den Hostnamen, also
-den Rechnernamen des entfernten Rechners, und optional eine Port-Nummer
-angeben (sonst wird als Vorgabe der Port 44146 benutzt):
-@example
-guix://master.guix.example.org:1234
-@end example
-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 @code{master.guix.example.org} verbinden können.
-Die Befehlszeilenoption @code{--listen} von @command{guix-daemon} kann
-benutzt werden, damit er auf TCP-Verbindungen lauscht (siehe @ref{Aufruf des guix-daemon, @code{--listen}}).
-@item ssh
-@cindex SSH-Zugriff auf Erstellungs-Daemons
-Mit solchen URIs kann eine Verbindung zu einem entfernten Daemon über SSH
-hergestellt werden@footnote{Diese Funktionalitäts setzt Guile-SSH voraus
-(siehe @ref{Voraussetzungen}).}. Eine typische URL sieht so aus:
-@example
-ssh://charlie@@guix.example.org:22
-@end example
-Was @command{guix copy} betrifft, richtet es sich nach den üblichen
-OpenSSH-Client-Konfigurationsdateien (siehe @ref{Aufruf von guix copy}).
-@end table
-In Zukunft könnten weitere URI-Schemata unterstützt werden.
-@c XXX: Remove this note when the protocol incurs fewer round trips
-@c and when (guix derivations) no longer relies on file system access.
-@quotation Anmerkung
-Die Fähigkeit, sich mit entfernten Erstellungs-Daemons zu verbinden, sehen
-wir als experimentell an, Stand @value{VERSION}. Bitte diskutieren Sie mit
-uns jegliche Probleme oder Vorschläge, die Sie haben könnten (siehe
-@ref{Mitwirken}).
-@end quotation
-@end defvr
-@deffn {Scheme-Prozedur} open-connection [@var{Uri}] [#:reserve-space? #t]
-Sich mit dem Daemon über den Unix-Socket an @var{Uri} verbinden (einer
-Zeichenkette). Wenn @var{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.
-@var{Uri} nimmt standardmäßig den Wert von @var{%default-socket-path} an,
-was dem bei der Installation mit dem Aufruf von @command{configure}
-ausgewählten Vorgabeort entspricht, gemäß den Befehlszeilenoptionen, mit
-denen @command{configure} aufgerufen wurde.
-@end deffn
-@deffn {Scheme-Prozedur} close-connection @var{Server}
-Die Verbindung zum @var{Server} trennen.
-@end deffn
-@defvr {Scheme-Variable} current-build-output-port
-Diese Variable ist an einen SRFI-39-Parameter gebunden, der auf den
-Scheme-Port verweist, an den vom Daemon empfangene Erstellungsprotokolle und
-Fehlerprotokolle geschrieben werden sollen.
-@end defvr
-Prozeduren, die entfernte Prozeduraufrufe durchführen, nehmen immer ein
-Server-Objekt als ihr erstes Argument.
-@deffn {Scheme-Prozedur} valid-path? @var{Server} @var{Pfad}
-@cindex ungültige Store-Objekte
-Liefert @code{#t}, wenn der @var{Pfad} ein gültiges Store-Objekt benennt,
-und sonst @code{#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 @code{&store-protocol-error}-Fehlerzustand wird ausgelöst, wenn der
-@var{Pfad} nicht mit dem Store-Verzeichnis als Präfix beginnt
-(@file{/gnu/store}).
-@end deffn
-@deffn {Scheme-Prozedur} add-text-to-store @var{Server} @var{Name} @var{Text} [@var{Referenzen}]
-Den @var{Text} im Store in einer Datei namens @var{Name} ablegen und ihren
-Store-Pfad zurückliefern. @var{Referenzen} ist die Liste der Store-Pfade,
-die der Store-Pfad dann referenzieren soll.
-@end deffn
-@deffn {Scheme-Prozedur} build-derivations @var{Server} @var{Ableitungen}
-Die @var{Ableitungen} erstellen (eine Liste von @code{<derivation>}-Objekten
-oder von Pfaden zu Ableitungen) und terminieren, sobald der Worker-Prozess
-mit dem Erstellen fertig ist. Liefert @code{#t} bei erfolgreicher
-Erstellung.
-@end deffn
-Es sei erwähnt, dass im Modul @code{(guix monads)} eine Monade sowie
-monadische Versionen obiger Prozeduren angeboten werden, damit an Code, der
-auf den Store zugreift, bequemer gearbeitet werden kann (siehe @ref{Die Store-Monade}).
-@c FIXME
-@i{Dieser Abschnitt ist im Moment noch unvollständig.}
-@node Ableitungen
-@section Ableitungen
-@cindex Ableitungen
-Systemnahe Erstellungsaktionen sowie die Umgebung, in der selbige
-durchzuführen sind, werden durch @dfn{Ableitungen} dargestellt. Eine
-Ableitung enthält folgende Informationen:
-@itemize
-@item
-Die Ausgaben, die die Ableitung hat. Ableitungen erzeugen mindestens eine
-Datei bzw. ein Verzeichnis im Store, können aber auch mehrere erzeugen.
-@item
-@cindex Erstellungszeitabhängigkeiten
-@cindex Abhängigkeiten zur Erstellungszeit
-Die Eingaben der Ableitung, also Abhängigkeiten zur Zeit ihrer Erstellung,
-die entweder andere Ableitungen oder einfache Dateien im Store sind (wie
-Patches, Erstellungsskripts usw.).
-@item
-Das System, wofür mit der Ableitung erstellt wird, also ihr Ziel — z.B.@:
-@code{x86_64-linux}.
-@item
-Der Dateiname eines Erstellungsskripts im Store, zusammen mit den
-Argumenten, mit denen es aufgerufen werden soll.
-@item
-Eine Liste zu definierender Umgebungsvariabler.
-@end itemize
-@cindex Ableitungspfad
-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 @code{.drv} enden — diese Dateien
-werden als @dfn{Ableitungspfade} bezeichnet. Ableitungspfade können an die
-Prozedur @code{build-derivations} übergeben werden, damit die darin
-niedergeschriebenen Erstellungsaktionen durchgeführt werden (siehe @ref{Der Store}).
-@cindex Ableitungen mit fester Ausgabe
-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 @dfn{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.
-@cindex references
-@cindex Laufzeitabhängigkeiten
-@cindex Abhängigkeiten, zur Laufzeit
-Den Ausgaben von Ableitungen — d.h.@: Erstellungergebnissen — ist eine Liste
-von @dfn{Referenzen} zugeordnet, die auch der entfernte Prozeduraufruf
-@code{references} oder der Befehl @command{guix gc --references} liefert
-(siehe @ref{Aufruf von guix gc}). Referenzen sind die Menge der
-Laufzeitabhängigkeiten von Erstellungsergebnissen. Referenzen sind eine
-Teilmenge der Eingaben von Ableitungen; die Teilmenge wird automatisch
-ermittelt, indem der Erstellungsdaemon alle Dateien unter den Ausgaben nach
-Referenzen durchsucht.
-Das Modul @code{(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 @code{derivation}:
-@deffn {Scheme-Prozedur} derivation @var{Store} @var{Name} @var{Ersteller} @
-  @var{Argumente} [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @
-[#:recursive? #f] [#:inputs '()] [#:env-vars '()] @ [#:system
-(%current-system)] [#:references-graphs #f] @ [#:allowed-references #f]
-[#:disallowed-references #f] @ [#:leaked-env-vars #f] [#:local-build? #f] @
-[#:substitutable? #t] [#:properties '()] Eine Ableitungen mit den
-@var{Argumente}n erstellen und das resultierende @code{<derivation>}-Objekt
-liefern.
-Wurden @var{hash} und @var{hash-algo} angegeben, wird eine @dfn{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 @var{recursive?} wahr ist, darf die Ableitung mit fester Ausgabe eine
-ausführbare Datei oder ein Verzeichnis sein und @var{hash} muss die
-Prüfsumme eines Archivs mit dieser Ausgabe sein.
-Ist @var{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 @var{allowed-references} ein wahr, muss es eine Liste von Store-Objekten
-oder Ausgaben sein, die die Ausgabe der Ableitung referenzieren darf. Ebenso
-muss @var{disallowed-references}, wenn es auf wahr gesetzt ist, eine Liste
-von Dingen bezeichnen, die die Ausgaben @emph{nicht} referenzieren dürfen.
-Ist @var{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 @var{hash} wahr
-ist. So ein Leck kann zum Beispiel benutzt werden, um Variable wie
-@code{http_proxy} an Ableitungen zu übergeben, die darüber Dateien
-herunterladen.
-Ist @var{local-build?} wahr, wird die Ableitung als schlechter Kandidat für
-das Auslagern deklariert, der besser lokal erstellt werden sollte (siehe
-@ref{Auslagern des Daemons einrichten}). Dies betrifft kleine Ableitungen, wo das
-Übertragen der Daten aufwendiger als ihre Erstellung ist.
-Ist @var{substitutable?} falsch, wird deklariert, dass für die Ausgabe der
-Ableitung keine Substitute benutzt werden sollen (siehe
-@ref{Substitute}). Das ist nützlich, wenn Pakete erstellt werden, die
-Details über den Prozessorbefehlssatz des Wirtssystems auslesen.
-@var{properties} muss eine assoziative Liste enthalten, die »Eigenschaften«
-der Ableitungen beschreibt. Sie wird genau so, wie sie ist, in der Ableitung
-gespeichert.
-@end deffn
-@noindent
-Hier ist ein Beispiel mit einem Shell-Skript, das als Ersteller benutzt
-wird. Es wird angenommen, dass @var{Store} eine offene Verbindung zum Daemon
-ist und @var{bash} auf eine ausführbare Bash im Store verweist:
-@lisp
-(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"))))
-@result{} #<derivation /gnu/store/@dots{}-foo.drv => /gnu/store/@dots{}-foo>
-@end lisp
-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 @code{gexp->derivation}. Mehr Informationen finden Sie im
-Abschnitt @ref{G-Ausdrücke}.
-Doch es gab einmal eine Zeit, zu der @code{gexp->derivation} noch nicht
-existiert hatte und wo das Zusammenstellen von Ableitungen mit
-Scheme-Erstellungscode noch mit @code{build-expression->derivation}
-bewerkstelligt wurde, was im Folgenden beschrieben wird. Diese Prozedur gilt
-als veraltet und man sollte nunmehr die viel schönere Prozedur
-@code{gexp->derivation} benutzen.
-@deffn {Scheme-Prozedur} build-expression->derivation @var{Store} @
-       @var{Name} @var{Ausdruck} @ [#:system (%current-system)] [#:inputs '()] @
-[#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @ [#:recursive? #f]
-[#:env-vars '()] [#:modules '()] @ [#:references-graphs #f]
-[#:allowed-references #f] @ [#:disallowed-references #f] @ [#:local-build?
-#f] [#:substitutable? #t] [#:guile-for-build #f] Liefert eine Ableitung, die
-den Scheme-Ausdruck @var{Ausdruck} als Ersteller einer Ableitung namens
-@var{Name} ausführt. @var{inputs} muss die Liste der Eingaben enthalten,
-jeweils als Tupel @code{(Name Ableitungspfad Unterableitung)}; wird keine
-@var{Unterableitung} angegeben, wird @code{"out"} angenommen. @var{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
-@var{Ausdruck} ausgeführt wird — z.B.@: @code{((guix build utils) (guix
-build gnu-build-system))}.
-Der @var{Ausdruck} wird in einer Umgebung ausgewertet, in der
-@code{%outputs} an eine Liste von Ausgabe-/Pfad-Paaren gebunden wurde und in
-der @code{%build-inputs} an eine Liste von Zeichenkette-/Ausgabepfad-Paaren
-gebunden wurde, die aus den @var{inputs}-Eingaben konstruiert worden
-ist. Optional kann in @var{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 @code{exit}
-mit dem Ergebnis des @var{Ausdruck}s aufruft; wenn also der @var{Ausdruck}
-den Wert @code{#f} liefert, wird angenommen, dass die Erstellung
-fehlgeschlagen ist.
-@var{Ausdruck} wird mit einer Ableitung @var{guile-for-build} erstellt. Wird
-kein @var{guile-for-build} angegeben oder steht es auf @code{#f}, wird
-stattdessen der Wert der Fluiden @code{%guile-for-build} benutzt.
-Siehe die Erklärungen zur Prozedur @code{derivation} für die Bedeutung von
-@var{references-graphs}, @var{allowed-references},
-@var{disallowed-references}, @var{local-build?} und @var{substitutable?}.
-@end deffn
-@noindent
-Hier ist ein Beispiel einer Ableitung mit nur einer Ausgabe, die ein
-Verzeichnis erzeugt, in dem eine einzelne Datei enthalten ist:
-@lisp
-(let ((builder '(let ((out (assoc-ref %outputs "out")))
-                  (mkdir out)    ; das Verzeichnis
-                                 ; /gnu/store/@dots{}-goo erstellen
-                  (call-with-output-file (string-append out "/test")
-                    (lambda (p)
-                      (display '(Hallo Guix) p))))))
-  (build-expression->derivation store "goo" builder))
-@result{} #<derivation /gnu/store/@dots{}-goo.drv => @dots{}>
-@end lisp
-@node Die Store-Monade
-@section Die Store-Monade
-@cindex Monade
-Die auf dem Store arbeitenden Prozeduren, die in den vorigen Abschnitten
-beschrieben wurden, nehmen alle eine offene Verbindung zum
-Erstellungs-Daemon als ihr erstes Argument entgegen. Obwohl das ihnen zu
-Grunde liegende Modell funktional ist, weisen sie doch alle Nebenwirkungen
-auf oder hängen vom momentanen Zustand des Stores ab.
-Ersteres ist umständlich, weil die Verbindung zum Erstellungs-Daemon
-zwischen all diesen Funktionen durchgereicht werden muss, so dass eine
-Komposition mit Funktionen ohne diesen Parameter unmöglich wird. Letzteres
-kann problematisch sein, weil Operationen auf dem Store Nebenwirkungen
-und/oder Abhängigkeiten von externem Zustand haben und ihre
-Ausführungsreihenfolge deswegen eine Rolle spielt.
-@cindex monadische Werte
-@cindex monadische Funktionen
-Hier kommt das Modul @code{(guix monads)} ins Spiel. Im Rahmen dieses Moduls
-können @dfn{Monaden} benutzt werden und dazu gehört insbesondere eine für
-unsere Zwecke sehr nützliche Monade, die @dfn{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 @dfn{monadische Werte} genannt; Prozeduren,
-die solche Werte liefern, heißen @dfn{monadische Prozeduren}.
-Betrachten Sie folgende »normale« Prozedur:
-@example
-(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))))
-@end example
-Unter Verwendung von @code{(guix monads)} und @code{(guix gexp)} lässt sie
-sich als monadische Funktion aufschreiben:
-@example
-(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))))
-@end example
-An der zweiten Version lassen sich mehrere Dinge beobachten: Der Parameter
-@code{Store} ist jetzt implizit geworden und wurde in die Aufrufe der
-monadischen Prozeduren @code{package->derivation} und
-@code{gexp->derivation} »eingefädelt« und der von @code{package->derivation}
-gelieferte monadische Wert wurde mit @code{mlet} statt einem einfachen
-@code{let} @dfn{gebunden}.
-Wie sich herausstellt, muss man den Aufruf von @code{package->derivation}
-nicht einmal aufschreiben, weil er implizit geschieht, wie wir später sehen
-werden (siehe @ref{G-Ausdrücke}):
-@example
-(define (sh-symlink)
-  (gexp->derivation "sh"
-                    #~(symlink (string-append #$bash "/bin/bash")
-                               #$output)))
-@end example
-@c See
-@c <https://syntaxexclamation.wordpress.com/2014/06/26/escaping-continuations/>
-@c for the funny quote.
-Die monadische @code{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
-@code{run-with-store} benutzen:
-@example
-(run-with-store (open-connection) (sh-symlink))
-@result{} /gnu/store/...-sh-symlink
-@end example
-Erwähnenswert ist, dass das Modul @code{(guix monad-repl)} die REPL von
-Guile um neue »Meta-Befehle« erweitert, mit denen es leichter ist, mit
-monadischen Prozeduren umzugehen: @code{run-in-store} und
-@code{enter-store-monad}. Mit Ersterer wird ein einzelner monadischer Wert
-durch den Store »laufen gelassen«:
-@example
-scheme@@(guile-user)> ,run-in-store (package->derivation hello)
-$1 = #<derivation /gnu/store/@dots{}-hello-2.9.drv => @dots{}>
-@end example
-Mit Letzterer wird rekursiv eine weitere REPL betreten, in der alle
-Rückgabewerte automatisch durch den Store laufen gelassen werden:
-@example
-scheme@@(guile-user)> ,enter-store-monad
-store-monad@@(guile-user) [1]> (package->derivation hello)
-$2 = #<derivation /gnu/store/@dots{}-hello-2.9.drv => @dots{}>
-store-monad@@(guile-user) [1]> (text-file "foo" "Hallo!")
-$3 = "/gnu/store/@dots{}-foo"
-store-monad@@(guile-user) [1]> ,q
-scheme@@(guile-user)>
-@end example
-@noindent
-Beachten Sie, dass in einer @code{store-monad}-REPL keine nicht-monadischen
-Werte zurückgeliefert werden können.
-Die wichtigsten syntaktischen Formen, um mit Monaden im Allgemeinen
-umzugehen, werden im Modul @code{(guix monads)} bereitgestellt und sind im
-Folgenden beschrieben.
-@deffn {Scheme-Syntax} with-monad @var{Monade} @var{Rumpf} ...
-Alle @code{>>=}- oder @code{return}-Formen im @var{Rumpf} in der
-@var{Monade} auswerten.
-@end deffn
-@deffn {Scheme-Syntax} return @var{Wert}
-Einen monadischen Wert liefern, der den übergebenen @var{Wert} kapselt.
-@end deffn
-@deffn {Scheme-Syntax} >>= @var{mWert} @var{mProz} ...
-Den monadischen Wert @var{mWert} @dfn{binden}, wobei sein »Inhalt« an die
-monadischen Prozeduren @var{mProz}@dots{} übergeben wird@footnote{Diese
-Operation wird gemeinhin »bind« genannt, aber mit diesem Begriff wird in
-Guile eine völlig andere Prozedur bezeichnet, die nichts damit zu tun
-hat. Also benutzen wir dieses etwas kryptische Symbol als Erbe der
-Haskell-Programmiersprache.}. Es kann eine einzelne @var{mProz} oder mehrere
-davon geben, wie in diesem Beispiel:
-@example
-(run-with-state
-    (with-monad %state-monad
-      (>>= (return 1)
-           (lambda (x) (return (+ 1 x)))
-           (lambda (x) (return (* 2 x)))))
-  'irgendein-Zustand)
-@result{} 4
-@result{} irgendein-Zustand
-@end example
-@end deffn
-@deffn {Scheme-Syntax} mlet @var{Monade} ((@var{Variable} @var{mWert}) ...) @
-       @var{Rumpf} ...
-@deffnx {Scheme-Syntax} mlet* @var{Monade} ((@var{Variable} @var{mWert}) ...) @
-       @var{Rumpf} ...  Die @var{Variable}n an die monadischen Werte @var{mWert} im
-@var{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 @var{mWert} steckt, wobei anschließend
-dieser rohe, nicht-monadische Wert im Sichtbarkeitsbereich des @var{Rumpf}s
-von der @var{Variable}n bezeichnet wird. Die Form (@var{Variable} ->
-@var{Wert}) bindet die @var{Variable} an den »normalen« @var{Wert}, wie es
-@code{let} tun würde. Die Bindungsoperation geschieht in der Reihenfolge von
-links nach rechts. Der letzte Ausdruck des @var{Rumpfs} muss ein monadischer
-Ausdruck sein und dessen Ergebnis wird das Ergebnis von @code{mlet} oder
-@code{mlet*} werden, wenn es durch die @var{Monad} laufen gelassen wurde.
-@code{mlet*} verhält sich gegenüber @code{mlet} wie @code{let*} gegenüber
-@code{let} (siehe @ref{Local Bindings,,, guile, GNU Guile Reference
-Manual}).
-@end deffn
-@deffn {Scheme-System} mbegin @var{Monade} @var{mAusdruck} ...
-Der Reihe nach den @var{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 @code{mlet}, außer dass die Rückgabewerte der
-monadischen Prozeduren ignoriert werden. In diesem Sinn verhält es sich
-analog zu @code{begin}, nur auf monadischen Ausdrücken.
-@end deffn
-@deffn {Scheme-System} mwhen @var{Bedingung} @var{mAusdr0} @var{mAusdr*} ...
-Wenn die @var{Bedingung} wahr ist, wird die Folge monadischer Ausdrücke
-@var{mAusdr0}..@var{mAusdr*} wie bei @code{mbegin} ausgewertet. Wenn die
-@var{Bedingung} falsch ist, wird @code{*unspecified*} in der momentanen
-Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer
-Ausdruck sein.
-@end deffn
-@deffn {Scheme-System} munless @var{Bedingung} @var{mAusdr0} @var{mAusdr*} ...
-Wenn die @var{Bedingung} falsch ist, wird die Folge monadischer Ausdrücke
-@var{mAusdr0}..@var{mAusdr*} wie bei @code{mbegin} ausgewertet. Wenn die
-@var{Bedingung} wahr ist, wird @code{*unspecified*} in der momentanen Monade
-zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer Ausdruck
-sein.
-@end deffn
-@cindex Zustandsmonade
-Das Modul @code{(guix monads)} macht die @dfn{Zustandsmonade} (englisch
-»state monad«) verfügbar, mit der ein zusätzlicher Wert — der Zustand —
-durch die monadischen Prozeduraufrufe @emph{gefädelt} werden kann.
-@defvr {Scheme-Variable} %state-monad
-Die Zustandsmonade. Prozeduren in der Zustandsmonade können auf den
-gefädelten Zustand zugreifen und ihn verändern.
-Betrachten Sie das folgende Beispiel. Die Prozedur @code{Quadrat} liefert
-einen Wert in der Zustandsmonade zurück. Sie liefert das Quadrat ihres
-Arguments, aber sie inkrementiert auch den momentanen Zustandswert:
-@example
-(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)
-@result{} (0 1 4)
-@result{} 3
-@end example
-Wird das »durch« die Zustandsmonade @var{%state-monad} laufen gelassen,
-erhalten wir jenen zusätzlichen Zustandswert, der der Anzahl der Aufrufe von
-@code{Quadrat} entspricht.
-@end defvr
-@deffn {Monadische Prozedur} current-state
-Liefert den momentanen Zustand als einen monadischen Wert.
-@end deffn
-@deffn {Monadische Prozedur} set-current-state @var{Wert}
-Setzt den momentanen Zustand auf @var{Wert} und liefert den vorherigen
-Zustand als einen monadischen Wert.
-@end deffn
-@deffn {Monadische Prozedur} state-push @var{Wert}
-Hängt den @var{Wert} vorne an den momentanen Zustand an, der eine Liste sein
-muss. Liefert den vorherigen Zustand als monadischen Wert.
-@end deffn
-@deffn {Monadische Prozedur} state-pop
-Entfernt einen Wert vorne vom momentanen Zustand und liefert ihn als
-monadischen Wert zurück. Dabei wird angenommen, dass es sich beim Zustand um
-eine Liste handelt.
-@end deffn
-@deffn {Scheme-Prozedur} run-with-state @var{mWert} [@var{Zustand}]
-Den monadischen Wert @var{mWert} mit @var{Zustand} als initialem Zustand
-laufen lassen. Dies liefert zwei Werte: den Ergebniswert und den
-Ergebniszustand.
-@end deffn
-Die zentrale Schnittstelle zur Store-Monade, wie sie vom Modul @code{(guix
-store)} angeboten wird, ist die Folgende:
-@defvr {Scheme-Variable} %store-monad
-Die Store-Monade — ein anderer Name für @var{%state-monad}.
-Werte in der Store-Monade kapseln Zugriffe auf den Store. Sobald seine
-Wirkung gebraucht wird, muss ein Wert der Store-Monade »ausgewertet« werden,
-indem er an die Prozedur @code{run-with-store} übergeben wird (siehe unten).
-@end defvr
-@deffn {Scheme-Prozedur} run-with-store @var{Store} @var{mWert} [#:guile-for-build] [#:system (%current-system)]
-Den @var{mWert}, einen monadischen Wert in der Store-Monade, in der offenen
-Verbindung @var{Store} laufen lassen.
-@end deffn
-@deffn {Monadische Prozedur} text-file @var{Name} @var{Text} [@var{Referenzen}]
-Als monadischen Wert den absoluten Dateinamen im Store für eine Datei
-liefern, deren Inhalt der der Zeichenkette @var{Text} ist. @var{Referenzen}
-ist dabei eine Liste von Store-Objekten, die die Ergebnis-Textdatei
-referenzieren wird; der Vorgabewert ist die leere Liste.
-@end deffn
-@deffn {Monadische Prozedur} binary-file @var{Name} @var{Daten} [@var{Referenzen}]
-Den absoluten Dateinamen im Store als monadischen Wert für eine Datei
-liefern, deren Inhalt der des Byte-Vektors @var{Daten} ist. @var{Referenzen}
-ist dabei eine Liste von Store-Objekten, die die Ergebnis-Binärdatei
-referenzieren wird; der Vorgabewert ist die leere Liste.
-@end deffn
-@deffn {Monadische Prozedur} interned-file @var{Datei} [@var{Name}] @
-         [#:recursive? #t] [#:select? (const #t)] Liefert den Namen der @var{Datei},
-nachdem sie in den Store interniert wurde. Dabei wird der @var{Name} als ihr
-Store-Name verwendet, oder, wenn kein @var{Name} angegeben wurde, der
-Basisname der @var{Datei}.
-Ist @var{recursive?} wahr, werden in der @var{Datei} enthaltene Dateien
-rekursiv hinzugefügt; ist die @var{Datei} eine flache Datei und
-@var{recursive?} ist wahr, wird ihr Inhalt in den Store eingelagert und ihre
-Berechtigungs-Bits übernommen.
-Steht @var{recursive?} auf wahr, wird @code{(@var{select?} @var{Datei}
-@var{Stat})} für jeden Verzeichniseintrag aufgerufen, wobei @var{Datei} der
-absolute Dateiname und @var{Stat} das Ergebnis von @code{lstat} ist, außer
-auf den Einträgen, wo @var{select?} keinen wahren Wert liefert.
-Folgendes Beispiel fügt eine Datei unter zwei verschiedenen Namen in den
-Store ein:
-@example
-(run-with-store (open-connection)
-  (mlet %store-monad ((a (interned-file "README"))
-                      (b (interned-file "README" "LEGU-MIN")))
-    (return (list a b))))
-@result{} ("/gnu/store/rwm@dots{}-README" "/gnu/store/44i@dots{}-LEGU-MIN")
-@end example
-@end deffn
-Das Modul @code{(guix packages)} exportiert die folgenden paketbezogenen
-monadischen Prozeduren:
-@deffn {Monadische Prozedur} package-file @var{Paket} [@var{Datei}] @
-       [#:system (%current-system)] [#:target #f] @ [#:output "out"] Liefert als
-monadischen Wert den absoluten Dateinamen der @var{Datei} innerhalb des
-Ausgabeverzeichnisses @var{output} des @var{Paket}s. Wird keine @var{Datei}
-angegeben, wird der Name des Ausgabeverzeichnisses @var{output} für das
-@var{Paket} zurückgeliefert. Ist @var{target} wahr, wird sein Wert als das
-Zielsystem bezeichnendes Tripel zum Cross-Kompilieren benutzt.
-@end deffn
-@deffn {Monadische Prozedur} package->derivation @var{Paket} [@var{System}]
-@deffnx {Monadische Prozedur} package->cross-derivation @var{Paket} @
-          @var{Ziel} [@var{System}] Monadische Version von @code{package-derivation}
-und @code{package-cross-derivation} (siehe @ref{Pakete definieren}).
-@end deffn
-@node G-Ausdrücke
-@section G-Ausdrücke
-@cindex G-Ausdruck
-@cindex Erstellungscode maskieren
-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 @ref{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 @ref{Aufruf des guix-daemon}).
-@cindex Schichten von Code
-Wenig überraschend ist, dass wir diese Erstellungsaktionen gerne in Scheme
-schreiben würden. Wenn wir das tun, bekommen wir zwei verschiedene
-@dfn{Schichten} von Scheme-Code@footnote{Der Begriff @dfn{Schicht}, englisch
-Stratum, wurde in diesem Kontext von Manuel Serrano et al.@: in ihrer Arbeit
-an Hop geprägt. Oleg Kiselyov, der aufschlussreiche
-@url{http://okmij.org/ftp/meta-programming/#meta-scheme, Essays und Code zu
-diesem Thema} geschrieben hat, nennt diese Art der Code-Generierung
-@dfn{Staging}, deutsch etwa Inszenierung bzw.@: Aufführung.}: 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, @command{make} aufgerufen wird etc.
-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 @code{quasiquote} in Scheme, wenn
-wir Erstellungsausdrücke konstruieren möchten.
-Das Modul @code{(guix gexp)} implementiert @dfn{G-Ausdrücke}, eine Form von
-S-Ausdrücken, die zu Erstellungsausdrücken angepasst wurden. G-Ausdrücke
-(englisch »G-expressions«, kurz @dfn{Gexps}) setzen sich grundlegend aus
-drei syntaktischen Formen zusammen: @code{gexp}, @code{ungexp} und
-@code{ungexp-splicing} (alternativ einfach: @code{#~}, @code{#$} und
-@code{#$@@}), die jeweils mit @code{quasiquote}, @code{unquote} und
-@code{unquote-splicing} vergleichbar sind (siehe @ref{Expression Syntax,
-@code{quasiquote},, guile, GNU Guile Reference Manual}). Es gibt aber auch
-erhebliche Unterschiede:
-@itemize
-@item
-G-Ausdrücke sind dafür gedacht, in eine Datei geschrieben zu werden, wo sie
-von anderen Prozessen ausgeführt oder manipuliert werden können.
-@item
-Wenn ein abstraktes Objekt wie ein Paket oder eine Ableitung innerhalb eines
-G-Ausdrücks demaskiert wird, ist das Ergebnis davon dasselbe, wie wenn
-dessen Ausgabedateiname genannt worden wäre.
-@item
-G-Ausdrücke tragen Informationen über die Pakete oder Ableitungen mit sich,
-auf die sie sich beziehen, und diese Abhängigkeiten werden automatisch zu
-den sie benutzenden Erstellungsprozessen als Eingaben hinzugefügt.
-@end itemize
-@cindex Herunterbrechen, von abstrakten Objekten in G-Ausdrücken
-Dieser Mechanismus ist nicht auf Pakete und Ableitung beschränkt: Es können
-@dfn{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 @code{local-file} und
-@code{plain-file}).
-Zur Veranschaulichung dieser Idee soll uns dieses Beispiel eines G-Ausdrucks
-dienen:
-@example
-(define build-exp
-  #~(begin
-      (mkdir #$output)
-      (chdir #$output)
-      (symlink (string-append #$coreutils "/bin/ls")
-               "list-files")))
-@end example
-Indem wir diesen G-Ausdruck an @code{gexp->derivation} übergeben, bekommen
-wir eine Ableitung, die ein Verzeichnis mit genau einer symbolischen
-Verknüpfung auf @file{/gnu/store/@dots{}-coreutils-8.22/bin/ls} erstellt:
-@example
-(gexp->derivation "das-ding" build-exp)
-@end example
-Wie man es erwarten würde, wird die Zeichenkette
-@code{"/gnu/store/@dots{}-coreutils-8.22"} anstelle der Referenzen auf das
-Paket @var{coreutils} im eigentlichen Erstellungscode eingefügt und
-@var{coreutils} automatisch zu einer Eingabe der Ableitung gemacht. Genauso
-wird auch @code{#$output} (was äquivalent zur Schreibweise @code{(ungexp
-output)} ist) ersetzt durch eine Zeichenkette mit dem Namen der Ausgabe der
-Ableitung.
-@cindex Cross-Kompilieren
-Im Kontext der Cross-Kompilierung bietet es sich an, zwischen Referenzen auf
-die @emph{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 @code{#+} dieselbe Rolle wie
-@code{#$}, steht aber für eine Referenz auf eine native Paketerstellung.
-@example
-(gexp->derivation "vi"
-   #~(begin
-       (mkdir #$output)
-       (system* (string-append #+coreutils "/bin/ln")
-                "-s"
-                (string-append #$emacs "/bin/emacs")
-                (string-append #$output "/bin/vi")))
-   #:target "mips64el-linux-gnu")
-@end example
-@noindent
-Im obigen Beispiel wird die native Erstellung der @var{coreutils} benutzt,
-damit @command{ln} tatsächlich auf dem Wirtssystem ausgeführt werden kann,
-aber danach die cross-kompilierte Erstellung von @var{emacs} referenziert.
-@cindex importierte Module, in G-Ausdrücken
-@findex with-imported-modules
-Eine weitere Funktionalität von G-Ausdrücken stellen @dfn{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
-@code{with-imported-modules}-Form macht das möglich:
-@example
-(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)))
-@end example
-@noindent
-In diesem Beispiel wird das Modul @code{(guix build utils)} automatisch in
-die isolierte Erstellungsumgebung unseres G-Ausdrucks geholt, so dass
-@code{(use-modules (guix build utils))} wie erwartet funktioniert.
-@cindex Modulabschluss
-@findex source-module-closure
-Normalerweise möchten Sie, dass der @emph{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 @code{source-module-closure}
-berechnet den Abschluss eines Moduls, indem es den Kopf seiner Quelldatei
-analysiert, deswegen schafft die Prozedur hier Abhilfe:
-@example
-(use-modules (guix modules))   ;»source-module-closure« verfügbar machen
-(with-imported-modules (source-module-closure
-                         '((guix build utils)
-                           (gnu build vm)))
-  (gexp->derivation "etwas-mit-vms"
-                    #~(begin
-                        (use-modules (guix build utils)
-                                     (gnu build vm))
-                        @dots{})))
-@end example
-@cindex Erweiterungen, für G-Ausdrücke
-@findex with-extensions
-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 @code{guile-json} auf der
-Erstellungsseite, dann könnten Sie es hiermit bekommen:
-@example
-(use-modules (gnu packages guile))  ;für »guile-json«
-(with-extensions (list guile-json)
-  (gexp->derivation "etwas-mit-json"
-                    #~(begin
-                        (use-modules (json))
-                        @dots{})))
-@end example
-Die syntaktische Form, in der G-Ausdrücke konstruiert werden, ist im
-Folgenden zusammengefasst.
-@deffn {Scheme-Syntax} #~@var{Ausdruck}
-@deffnx {Scheme-Syntax} (gexp @var{Ausdruck})
-Liefert einen G-Ausdruck, der den @var{Ausdruck} enthält. Der @var{Ausdruck}
-kann eine oder mehrere der folgenden Formen enthalten:
-@table @code
-@item #$@var{Objekt}
-@itemx (ungexp @var{Objekt})
-Eine Referenz auf das @var{Objekt} einführen. Das @var{Objekt} kann einen
-der unterstützten Typen haben, zum Beispiel ein Paket oder eine Ableitung,
-so dass die @code{ungexp}-Form durch deren Ausgabedateiname ersetzt wird —
-z.B.@: @code{"/gnu/store/@dots{}-coreutils-8.22}.
-Wenn das @var{Objekt} eine Liste ist, wird diese durchlaufen und alle
-unterstützten Objekte darin auf diese Weise ersetzt.
-Wenn das @var{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 @var{Objekt} eine andere Art von Objekt ist, wird es so wie es ist
-eingefügt.
-@item #$@var{Objekt}:@var{Ausgabe}
-@itemx (ungexp @var{Objekt} @var{Ausgabe})
-Dies verhält sich wie die Form oben, bezieht sich aber ausdrücklich auf die
-angegebene @var{Ausgabe} des @var{Objekt}s — dies ist nützlich, wenn das
-@var{Objekt} mehrere Ausgaben generiert (siehe @ref{Pakete mit mehreren Ausgaben.}).
-@item #+@var{Objekt}
-@itemx #+@var{Objekt}:@var{Ausgabe}
-@itemx (ungexp-native @var{Objekt})
-@itemx (ungexp-native @var{Objekt} @var{Ausgabe})
-Das Gleiche wie @code{ungexp}, jedoch wird im Kontext einer
-Cross-Kompilierung eine Referenz auf die @emph{native} Erstellung des
-@var{Objekt}s eingefügt.
-@item #$output[:@var{Ausgabe}]
-@itemx (ungexp output [@var{Ausgabe}])
-Fügt eine Referenz auf die angegebene @var{Ausgabe} dieser Ableitung ein,
-oder auf die Hauptausgabe, wenn keine @var{Ausgabe} angegeben wurde.
-Dies ist nur bei G-Ausdrücken sinnvoll, die an @code{gexp->derivation}
-übergeben werden.
-@item #$@@@var{Liste}
-@itemx (ungexp-splicing @var{Liste})
-Das Gleiche wie oben, jedoch wird nur der Inhalt der @var{Liste} in die
-äußere Liste eingespleißt.
-@item #+@@@var{Liste}
-@itemx (ungexp-native-splicing @var{Liste})
-Das Gleiche, aber referenziert werden native Erstellungen der Objekte in der
-@var{Liste}.
-@end table
-G-Ausdrücke, die mit @code{gexp} oder @code{#~} erzeugt wurden, sind zur
-Laufzeit Objekte vom Typ @code{gexp?} (siehe unten).
-@end deffn
-@deffn {Scheme-Syntax} with-imported-modules @var{Module} @var{Rumpf}@dots{}
-Markiert die in @var{Rumpf}@dots{} definierten G-Ausdrücke, dass sie in
-ihrer Ausführungsumgebung die angegebenen @var{Module} brauchen.
-Jedes Objekt unter den @var{Module}n kann der Name eines Moduls wie
-@code{(guix build utils)} sein, oder es kann nacheinander ein Modulname, ein
-Pfeil und ein dateiartiges Objekt sein:
-@example
-`((guix build utils)
-  (guix gcrypt)
-  ((guix config) => ,(scheme-file "config.scm"
-                                  #~(define-module @dots{}))))
-@end example
-@noindent
-Im Beispiel oben werden die ersten beiden Module vom Suchpfad genommen und
-das letzte aus dem angegebenen dateiartigen Objekt erzeugt.
-Diese Form hat einen @emph{lexikalischen} Sichtbarkeitsbereich: Sie wirkt
-sich auf die direkt in @var{Rumpf}@dots{} definierten G-Ausdrücke aus, aber
-nicht auf jene, die, sagen wir, in aus @var{Rumpf}@dots{} heraus
-aufgerufenen Prozeduren definiert wurden.
-@end deffn
-@deffn {Scheme-Syntax} with-extensions @var{Erweiterungen} @var{Rumpf}@dots{}
-Markiert die in @var{Rumpf}@dots{} definierten G-Ausdrücke, dass sie
-@var{Erweiterungen} in ihrer Erstellungs- und Ausführungsumgebung
-benötigen. @var{Erweiterungen} sind typischerweise eine Liste von
-Paketobjekten wie zum Beispiel die im Modul @code{(gnu packages guile)}
-definierten.
-Konkret werden die unter den @var{Erweiterungen} aufgeführten Pakete zum
-Ladepfad hinzugefügt, während die in @var{Rumpf}@dots{} aufgeführten
-importierten Module kompiliert werden und sie werden auch zum Ladepfad des
-von @var{Rumpf}@dots{} gelieferten G-Ausdrucks hinzugefügt.
-@end deffn
-@deffn {Scheme-Prozedur} gexp? @var{Objekt}
-Liefert @code{#t}, wenn das @var{Objekt} ein G-Ausdruck ist.
-@end deffn
-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
-@ref{Die Store-Monade}, wenn Sie mehr Informationen über Monaden suchen).
-@deffn {Monadische Prozedur} gexp->derivation @var{Name} @var{Ausdruck} @
-       [#:system (%current-system)] [#:target #f] [#:graft? #t] @ [#:hash #f]
-[#:hash-algo #f] @ [#:recursive? #f] [#:env-vars '()] [#:modules '()] @
-[#:module-path @var{%load-path}] @ [#:effective-version "2.2"] @
-[#:references-graphs #f] [#:allowed-references #f] @
-[#:disallowed-references #f] @ [#:leaked-env-vars #f] @ [#:script-name
-(string-append @var{Name} "-builder")] @ [#:deprecation-warnings #f] @
-[#:local-build? #f] [#:substitutable? #t] @ [#:properties '()]
-[#:guile-for-build #f] Liefert eine Ableitung unter dem @var{Name}n, die
-jeden @var{Ausdruck} (ein G-Ausdruck) mit @var{guile-for-build} (eine
-Ableitung) für das @var{System} erstellt; der @var{Ausdruck} wird dabei in
-einer Datei namens @var{script-name} gespeichert. Wenn »@var{target}« wahr
-ist, wird es beim Cross-Kompilieren als Zieltripel für mit @var{Ausdruck}
-bezeichnete Pakete benutzt.
-@var{modules} gilt als veraltet; stattdessen sollte
-@code{with-imported-modules} benutzt werden. Die Bedeutung ist, dass die
-@var{Module} im Ausführungskontext des @var{Ausdruck}s verfügbar gemacht
-werden; @var{modules} ist dabei eine Liste von Namen von Guile-Modulen, die
-im Modulpfad @var{module-path} gesucht werden, um sie in den Store zu
-kopieren, zu kompilieren und im Ladepfad während der Ausführung des
-@var{Ausdruck}s verfügbar zu machen — z.B.@: @code{((guix build utils) (guix
-build gnu-build-system))}.
-@var{effective-version} bestimmt, unter welcher Zeichenkette die
-Erweiterungen des @var{Ausdruck}s zum Suchpfad hinzugefügt werden (siehe
-@code{with-extensions}) — z.B.@: @code{"2.2"}.
-@var{graft?} bestimmt, ob vom @var{Ausdruck} benannte Pakete veredelt werden
-sollen, falls Veredelungen zur Verfügung stehen.
-Ist @var{references-graphs} wahr, muss es eine Liste von Tupeln in einer der
-folgenden Formen sein:
-@example
-(@var{Dateiname} @var{Paket})
-(@var{Dateiname} @var{Paket} @var{Ausgabe})
-(@var{Dateiname} @var{Ableitung})
-(@var{Dateiname} @var{Ableitung} @var{Ausgabe})
-(@var{Dateiname} @var{Store-Objekt})
-@end example
-Bei jedem Element von @var{references-graphs} wird das rechts Stehende
-automatisch zu einer Eingabe des Erstellungsprozesses vom @var{Ausdruck}
-gemacht. In der Erstellungsumgebung enthält das, was mit @var{Dateiname}
-bezeichnet wird, den Referenzgraphen des entsprechenden Objekts in einem
-einfachen Textformat.
-@var{allowed-references} muss entweder @code{#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 @var{disallowed-references}, was eine Liste von Objekten sein
-kann, die von den Ausgaben nicht referenziert werden dürfen.
-@var{deprecation-warnings} bestimmt, ob beim Kompilieren von Modulen
-Warnungen angezeigt werden sollen, wenn auf als veraltet markierten Code
-zugegriffen wird (»deprecation warnings«). @var{deprecation-warnings} kann
-@code{#f}, @code{#t} oder @code{'detailed} (detailliert) sein.
-Die anderen Argumente verhalten sich wie bei @code{derivation} (siehe
-@ref{Ableitungen}).
-@end deffn
-@cindex dateiartige Objekte
-Die im Folgenden erklärten Prozeduren @code{local-file}, @code{plain-file},
-@code{computed-file}, @code{program-file} und @code{scheme-file} liefern
-@dfn{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:
-@example
-#~(system* #$(file-append glibc "/sbin/nscd") "-f"
-           #$(local-file "/tmp/my-nscd.conf"))
-@end example
-Der Effekt hiervon ist, dass @file{/tmp/my-nscd.conf} »interniert« wird,
-indem es in den Store kopiert wird. Sobald er umgeschrieben wurde, zum
-Beispiel über @code{gexp->derivation}, referenziert der G-Ausdruck diese
-Kopie im @file{/gnu/store}. Die Datei in @file{/tmp} zu bearbeiten oder zu
-löschen, hat dann keinen Effekt mehr darauf, was der G-Ausdruck
-tut. @code{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.
-@deffn {Scheme-Prozedur} local-file @var{Datei} [@var{Name}] @
-   [#:recursive? #f] [#:select? (const #t)] Liefert ein Objekt, dass die lokale
-Datei @var{Datei} repräsentiert und sie zum Store hinzufügen lässt; dieses
-Objekt kann in einem G-Ausdruck benutzt werden. Wurde für die @var{Datei}
-ein relativer Dateiname angegeben, wird sie relativ zur Quelldatei gesucht,
-in der diese Form steht. Die @var{Datei} wird unter dem angegebenen
-@var{Name}n im Store abgelegt — als Vorgabe wird dabei der Basisname der
-@var{Datei} genommen.
-Ist @var{recursive?} wahr, werden in der @var{Datei} enthaltene Dateien
-rekursiv hinzugefügt; ist die @var{Datei} eine flache Datei und
-@var{recursive?} ist wahr, wird ihr Inhalt in den Store eingelagert und ihre
-Berechtigungs-Bits übernommen.
-Steht @var{recursive?} auf wahr, wird @code{(@var{select?} @var{Datei}
-@var{Stat})} für jeden Verzeichniseintrag aufgerufen, wobei @var{Datei} der
-absolute Dateiname und @var{Stat} das Ergebnis von @code{lstat} ist, außer
-auf den Einträgen, wo @var{select?} keinen wahren Wert liefert.
-Dies ist das deklarative Gegenstück zur monadischen Prozedur
-@code{interned-file} (siehe @ref{Die Store-Monade, @code{interned-file}}).
-@end deffn
-@deffn {Scheme-Prozedur} plain-file @var{Name} @var{Inhalt}
-Liefert ein Objekt, das eine Textdatei mit dem angegebenen @var{Name}n
-repräsentiert, die den angegebenen @var{Inhalt} hat (eine Zeichenkette oder
-ein Bytevektor), welche zum Store hinzugefügt werden soll.
-Dies ist das deklarative Gegenstück zu @code{text-file}.
-@end deffn
-@deffn {Scheme-Prozedur} computed-file @var{Name} @var{G-Ausdruck} @
-          [#:options '(#:local-build? #t)] Liefert ein Objekt, das das Store-Objekt
-mit dem @var{Name}n repräsentiert, eine Datei oder ein Verzeichnis, das vom
-@var{G-Ausdruck} berechnet wurde. @var{options} ist eine Liste zusätzlicher
-Argumente, die an @code{gexp->derivation} übergeben werden.
-Dies ist das deklarative Gegenstück zu @code{gexp->derivation}.
-@end deffn
-@deffn {Monadische Prozedur} gexp->script @var{Name} @var{Ausdruck} @
-  [#:guile (default-guile)] [#:module-path %load-path] Liefert ein
-ausführbares Skript namens @var{Name}, das den @var{Ausdruck} mit dem
-angegebenen @var{guile} ausführt, wobei vom @var{Ausdruck} importierte
-Module in seinem Suchpfad stehen. Die Module des @var{Ausdruck}s werden dazu
-im Modulpfad @var{module-path} gesucht.
-Folgendes Beispiel erstellt ein Skript, das einfach nur den Befehl
-@command{ls} ausführt:
-@example
-(use-modules (guix gexp) (gnu packages base))
-(gexp->script "list-files"
-              #~(execl #$(file-append coreutils "/bin/ls")
-                       "ls"))
-@end example
-Lässt man es durch den Store »laufen« (siehe @ref{Die Store-Monade,
-@code{run-with-store}}), erhalten wir eine Ableitung, die eine ausführbare
-Datei @file{/gnu/store/@dots{}-list-files} generiert, ungefähr so:
-@example
-#!/gnu/store/@dots{}-guile-2.0.11/bin/guile -ds
-!#
-(execl "/gnu/store/@dots{}-coreutils-8.22"/bin/ls" "ls")
-@end example
-@end deffn
-@deffn {Scheme-Prozedur} program-file @var{Name} @var{G-Ausdruck} @
-          [#:guile #f] [#:module-path %load-path] Liefert ein Objekt, das eine
-ausführbare Store-Datei @var{Name} repräsentiert, die den @var{G-Ausdruck}
-ausführt. @var{guile} ist das zu verwendende Guile-Paket, mit dem das Skript
-ausgeführt werden kann. Importierte Module des @var{G-Ausdruck}s werden im
-Modulpfad @var{module-path} gesucht.
-Dies ist das deklarative Gegenstück zu @code{gexp->script}.
-@end deffn
-@deffn {Monadische Prozedur} gexp->file @var{Name} @var{G-Ausdruck} @
-            [#:set-load-path? #t] [#:module-path %load-path] @ [#:splice? #f] @ [#:guile
-(default-guile)] Liefert eine Ableitung, die eine Datei @var{Name} erstellen
-wird, deren Inhalt der @var{G-Ausdruck} ist. Ist @var{splice?} wahr, dann
-wird @var{G-Ausdruck} stattdessen als eine Liste von mehreren G-Ausdrücken
-behandelt, die alle in die resultierende Datei gespleißt werden.
-Ist @var{set-load-path?} wahr, wird in die resultierende Datei Code
-hinzugefügt, der den Ladepfad @code{%load-path} und den Ladepfad für
-kompilierte Dateien @code{%load-compiled-path} festlegt, die für die
-importierten Module des @var{G-Ausdruck}s nötig sind. Die Module des
-@var{G-Ausdruck}s werden im Modulpfad @var{module-path} gesucht.
-Die resultierende Datei referenziert alle Abhängigkeiten des
-@var{G-Ausdruck}s oder eine Teilmenge davon.
-@end deffn
-@deffn {Scheme-Prozedur} scheme-file @var{Name} @var{G-Ausdruck} [#:splice? #f]
-Liefert ein Objekt, das die Scheme-Datei @var{Name} mit dem @var{G-Ausdruck}
-als Inhalt repräsentiert.
-Dies ist das deklarative Gegenstück zu @code{gexp->file}.
-@end deffn
-@deffn {Monadische Prozedur} text-file* @var{Name} @var{Text} @dots{}
-Liefert eine Ableitung als monadischen Wert, welche eine Textdatei erstellt,
-in der der gesamte @var{Text} enthalten ist. @var{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 @code{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:
-@example
-(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"))
-@end example
-In diesem Beispiel wird die resultierende Datei
-@file{/gnu/store/@dots{}-profile.sh} sowohl @var{coreutils}, @var{grep} als
-auch @var{sed} referenzieren, so dass der Müllsammler diese nicht löscht,
-während die resultierende Datei noch lebendig ist.
-@end deffn
-@deffn {Scheme-Prozedur} mixed-text-file @var{Name} @var{Text} @dots{}
-Liefert ein Objekt, was die Store-Datei @var{Name} repräsentiert, die
-@var{Text} enthält. @var{Text} ist dabei eine Folge von Zeichenketten und
-dateiartigen Objekten wie zum Beispiel:
-@example
-(mixed-text-file "profile"
-                 "export PATH=" coreutils "/bin:" grep "/bin")
-@end example
-Dies ist das deklarative Gegenstück zu @code{text-file*}.
-@end deffn
-@deffn {Scheme-Prozedur} file-union @var{Name} @var{Dateien}
-Liefert ein @code{<computed-file>}, das ein Verzeichnis mit allen
-@var{Dateien} enthält. Jedes Objekt in @var{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:
-@example
-(file-union "etc"
-            `(("hosts" ,(plain-file "hosts"
-                                    "127.0.0.1 localhost"))
-              ("bashrc" ,(plain-file "bashrc"
-                                     "alias ls='ls --color=auto'"))))
-@end example
-Dies liefert ein Verzeichnis @code{etc}, das zwei Dateien enthält.
-@end deffn
-@deffn {Scheme-Prozedur} directory-union @var{Name} @var{Dinge}
-Liefert ein Verzeichnis, was die Vereinigung (englisch »Union«) der
-@var{Dinge} darstellt, wobei @var{Dinge} eine Liste dateiartiger Objekte
-sein muss, die Verzeichnisse bezeichnen. Zum Beispiel:
-@example
-(directory-union "guile+emacs" (list guile emacs))
-@end example
-Das liefert ein Verzeichnis, welches die Vereinigung der Pakete @code{guile}
-und @code{emacs} ist.
-@end deffn
-@deffn {Scheme-Prozedur} file-append @var{Objekt} @var{Suffix} @dots{}
-Liefert ein dateiartiges Objekt, das zur Aneinanderreihung von @var{Objekt}
-und @var{Suffix} umgeschrieben wird, wobei das @var{Objekt} ein
-herunterbrechbares Objekt und jedes @var{Suffix} eine Zeichenkette sein
-muss.
-Betrachten Sie zum Beispiel diesen G-Ausdruck:
-@example
-(gexp->script "uname-ausfuehren"
-              #~(system* #$(file-append coreutils
-                                        "/bin/uname")))
-@end example
-Denselben Effekt könnte man erreichen mit:
-@example
-(gexp->script "uname-ausfuehren"
-              #~(system* (string-append #$coreutils
-                                        "/bin/uname")))
-@end example
-Es gibt jedoch einen Unterschied, nämlich enthält das resultierende Skript
-bei @code{file-append} tatsächlich den absoluten Dateinamen als
-Zeichenkette, während im anderen Fall das resultierende Skript einen
-Ausdruck @code{(string-append @dots{})} enthält, der den Dateinamen erst
-@emph{zur Laufzeit} zusammensetzt.
-@end deffn
-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 @code{(guix build
-@dots{})}.
-@cindex Herunterbrechen, von abstrakten Objekten in G-Ausdrücken
-Intern werden hochsprachliche, abstrakte Objekte mit ihrem Compiler entweder
-zu Ableitungen oder zu Store-Objekten @dfn{heruntergebrochen}. Wird zum
-Beispiel ein Paket heruntergebrochen, bekommt man eine Ableitung, während
-ein @code{plain-file} zu einem Store-Objekt heruntergebrochen wird. Das wird
-mit der monadischen Prozedur @code{lower-object} bewerkstelligt.
-@deffn {Monadische Prozedur} lower-object @var{Objekt} [@var{System}] @
-           [#:target #f] Liefert die Ableitung oder das Store-Objekt, das dem
-@var{Objekt} für @var{System} als Wert in der Store-Monade
-@var{%store-monad} entspricht, cross-kompiliert für das Zieltripel
-@var{target}, wenn @var{target} wahr ist. Das @var{Objekt} muss ein Objekt
-sein, für das es einen mit ihm assoziierten G-Ausdruck-Compiler gibt, wie
-zum Beispiel ein @code{<package>}.
-@end deffn
-@node Aufruf von guix repl
-@section @command{guix repl} aufrufen
-@cindex REPL (Lese-Auswerten-Schreiben-Schleife)
-Der Befehl @command{guix repl} startet eine Guile-REPL (@dfn{Read-Eval-Print
-Loop}, kurz REPL, deutsch Lese-Auswerten-Schreiben-Schleife) zur
-interaktiven Programmierung (siehe @ref{Using Guile Interactively,,, guile,
-GNU Guile Reference Manual}). Im Vergleich dazu, einfach den Befehl
-@command{guile} aufzurufen, garantiert @command{guix repl}, dass alle
-Guix-Module und deren Abhängigkeiten im Suchpfad verfügbar sind. Sie können
-die REPL so benutzen:
-@example
-$ guix repl
-scheme@@(guile-user)> ,use (gnu packages base)
-scheme@@(guile-user)> coreutils
-$1 = #<package coreutils@@8.29 gnu/packages/base.scm:327 3e28300>
-@end example
-@cindex Untergeordnete
-@command{guix repl} implementiert zusätzlich ein einfaches maschinenlesbares
-Protokoll für die REPL, das von @code{(guix inferior)} benutzt wird, um mit
-@dfn{Untergeordneten} zu interagieren, also mit getrennten Prozessen einer
-womöglich anderen Version von Guix.
-Folgende @var{Optionen} gibt es:
-@table @code
-@item --type=@var{Typ}
-@itemx -t @var{Typ}
-Startet eine REPL des angegebenen @var{Typ}s, der einer der Folgenden sein
-darf:
-@table @code
-@item guile
-Die Voreinstellung, mit der eine normale, voll funktionsfähige Guile-REPL
-gestartet wird.
-@item machine
-Startet eine REPL, die ein maschinenlesbares Protokoll benutzt. Dieses
-Protokoll wird vom Modul @code{(guix inferior)} gesprochen.
-@end table
-@item --listen=@var{Endpunkt}
-Der Vorgabe nach würde @command{guix repl} von der Standardeingabe lesen und
-auf die Standardausgabe schreiben. Wird diese Befehlszeilenoption angegeben,
-lauscht die REPL stattdessen auf dem @var{Endpunkt} auf Verbindungen. Hier
-sind Beispiele gültiger Befehlszeilenoptionen:
-@table @code
-@item --listen=tcp:37146
-Verbindungen mit dem »localhost« auf Port 37146 akzeptieren.
-@item --listen=unix:/tmp/socket
-Verbindungen zum Unix-Socket @file{/tmp/socket} akzeptieren.
-@end table
-@end table
-@c *********************************************************************
-@node Zubehör
-@chapter Zubehör
-Dieser Abschnitt beschreibt die Befehlszeilenwerkzeuge von Guix. Manche
-davon richten sich hauptsächlich an Entwickler und solche Nutzer, die neue
-Paketdefinitionen schreiben, andere sind auch für ein breiteres Publikum
-nützlich. Sie ergänzen die Scheme-Programmierschnittstelle um bequeme
-Befehle.
-@menu
-* Aufruf von guix build::    Pakete aus der Befehlszeile heraus erstellen.
-* Aufruf von guix edit::     Paketdefinitionen bearbeiten.
-* Aufruf von guix download::  Herunterladen einer Datei und Ausgabe ihres 
-                                Hashes.
-* Aufruf von guix hash::     Den kryptografischen Hash einer Datei 
-                               berechnen.
-* Aufruf von guix import::   Paketdefinitionen importieren.
-* Aufruf von guix refresh::  Paketdefinitionen aktualisieren.
-* Aufruf von guix lint::     Fehler in Paketdefinitionen finden.
-* Aufruf von guix size::     Plattenplatzverbrauch profilieren.
-* Aufruf von guix graph::    Den Paketgraphen visualisieren.
-* Aufruf von guix publish::  Substitute teilen.
-* Aufruf von guix challenge::  Die Substitut-Server anfechten.
-* Aufruf von guix copy::     Mit einem entfernten Store Dateien austauschen.
-* Aufruf von guix container::  Prozesse isolieren.
-* Aufruf von guix weather::  Die Verfügbarkeit von Substituten 
-                               einschätzen.
-* Aufruf von guix processes::  Auflisten der Client-Prozesse
-@end menu
-@node Aufruf von guix build
-@section Aufruf von @command{guix build}
-@cindex Paketerstellung
-@cindex @command{guix build}
-Der Befehl @command{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 @command{guix package} (siehe
-@ref{Aufruf von guix package}). @command{guix build} wird also hauptsächlich
-von Entwicklern der Distribution benutzt.
-Die allgemeine Syntax lautet:
-@example
-guix build @var{Optionen} @var{Paket-oder-Ableitung}@dots{}
-@end example
-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:
-@example
-guix build emacs guile
-@end example
-Folgender Befehl erstellt alle Pakete, die zur Verfügung stehen:
-@example
-guix build --quiet --keep-going \
-  `guix package -A | cut -f1,2 --output-delimiter=@@`
-@end example
-Als @var{Paket-oder-Ableitung} muss entweder der Name eines in der
-Software-Distribution zu findenden Pakets, wie etwa @code{coreutils} oder
-@code{coreutils@@8.20}, oder eine Ableitung wie
-@file{/gnu/store/@dots{}-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 @ref{Paketmodule}).
-Alternativ kann die Befehlszeilenoption @code{--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 @var{Optionen} können angegeben werden. Zur Verfügung stehen
-die in den folgenden Unterabschnitten beschriebenen Befehlszeilenoptionen.
-@menu
-* Gemeinsame Erstellungsoptionen::  Erstellungsoptionen für die meisten 
-                                      Befehle.
-* Paketumwandlungsoptionen::  Varianten von Paketen erzeugen.
-* Zusätzliche Erstellungsoptionen::  Optionen spezifisch für »guix 
-                                        build«.
-* Fehlschläge beim Erstellen untersuchen::  Praxiserfahrung bei der 
-                                               Paketerstellung.
-@end menu
-@node Gemeinsame Erstellungsoptionen
-@subsection Gemeinsame Erstellungsoptionen
-Einige dieser Befehlszeilenoptionen zur Steuerung des Erstellungsprozess
-haben @command{guix build} und andere Befehle, mit denen Erstellungen
-ausgelöst werden können, wie @command{guix package} oder @command{guix
-archive}, gemeinsam. Das sind folgende:
-@table @code
-@item --load-path=@var{Verzeichnis}
-@itemx -L @var{Verzeichnis}
-Das @var{Verzeichnis} vorne an den Suchpfad für Paketmodule anfügen (siehe
-@ref{Paketmodule}).
-Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete
-für die Befehlszeilenwerkzeuge sichtbar sind.
-@item --keep-failed
-@itemx -K
-Den Verzeichnisbaum, in dem fehlgeschlagene Erstellungen durchgeführt
-wurden, behalten. Wenn also eine Erstellung fehlschlägt, bleibt ihr
-Erstellungsbaum in @file{/tmp} erhalten. Der Name dieses Unterverzeichnisses
-wird am Ende dem Erstellungsprotokolls ausgegeben. Dies hilft bei der Suche
-nach Fehlern in Erstellungen. Der Abschnitt @ref{Fehlschläge beim Erstellen untersuchen}
-zeigt Ihnen Hinweise und Tricks, wie Erstellungsfehler untersucht werden
-können.
-Diese Option hat keine Auswirkungen, wenn eine Verbindung zu einem
-entfernten Daemon über eine @code{guix://}-URI verwendet wurde (siehe
-@ref{Der Store, the @code{GUIX_DAEMON_SOCKET} variable}).
-@item --keep-going
-@itemx -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.
-@item --dry-run
-@itemx -n
-Die Ableitungen nicht erstellen.
-@anchor{fallback-option}
-@item --fallback
-Wenn das Substituieren vorerstellter Binärdateien fehlschlägt, diese als
-»Fallback« lokal selbst erstellen (siehe @ref{Fehler bei der Substitution}).
-@item --substitute-urls=@var{URLs}
-@anchor{client-substitute-urls}
-Die @var{urls} als durch Leerraumzeichen getrennte Liste von Quell-URLs für
-Substitute anstelle der vorgegebenen URL-Liste für den @command{guix-daemon}
-verwenden (siehe @ref{daemon-substitute-urls,, @command{guix-daemon} URLs}).
-Das heißt, die Substitute dürfen von den @var{urls} heruntergeladen werden,
-sofern sie mit einem durch den Systemadministrator autorisierten Schlüssel
-signiert worden sind (siehe @ref{Substitute}).
-Wenn als @var{urls} eine leere Zeichenkette angegeben wurde, verhält es
-sich, als wären Substitute abgeschaltet.
-@item --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 @ref{Substitute}).
-@item --no-grafts
-Pakete nicht »veredeln« (engl. »graft«). Praktisch heißt das, dass als
-Veredelungen verfügbare Paketaktualisierungen nicht angewandt werden. Der
-Abschnitt @ref{Sicherheitsaktualisierungen} hat weitere Informationen zu Veredelungen.
-@item --rounds=@var{n}
-Jede Ableitung @var{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 @emph{verifizieren}
-können, ob von Drittanbietern bereitgestellte Binärdateien echt sind. Der
-Abschnitt @ref{Aufruf von guix challenge} erklärt dies genauer.
-Beachten Sie, dass die sich unterscheidenden Erstellungsergebnisse nicht
-erhalten bleiben, so dass Sie eventuelle Fehler manuell untersuchen müssen,
-z.B.@: indem Sie eines oder mehrere der Erstellungsergebnisse @code{guix
-archive --export} auslagern (siehe @ref{Aufruf von guix archive}), dann neu
-erstellen und letztlich die beiden Erstellungsergebnisse vergleichen.
-@item --no-build-hook
-Nicht versuchen, Erstellungen über den »Build-Hook« des Daemons auszulagern
-(siehe @ref{Auslagern des Daemons einrichten}). Somit wird lokal erstellt, statt
-Erstellungen auf entfernte Maschinen auszulagern.
-@item --max-silent-time=@var{Sekunden}
-Wenn der Erstellungs- oder Substitutionsprozess länger als
-@var{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
-@ref{Aufruf des guix-daemon, @code{--max-silent-time}}).
-@item --timeout=@var{Sekunden}
-Entsprechend wird hier der Erstellungs- oder Substitutionsprozess
-abgebrochen und als Fehlschlag gemeldet, wenn er mehr als
-@var{Sekunden}-lang dauert.
-Standardmäßig wird die Einstellung für den Daemon benutzt (siehe
-@ref{Aufruf des guix-daemon, @code{--timeout}}).
-@c Note: This option is actually not part of %standard-build-options but
-@c most programs honor it.
-@cindex Ausführlichkeit der Befehlszeilenwerkzeuge
-@cindex Erstellungsprotokolle, Ausführlichkeit
-@item -v @var{Stufe}
-@itemx --verbosity=@var{Stufe}
-Die angegebene Ausführlichkeitsstufe verwenden. Als @var{Stufe} muss eine
-ganze Zahl angegeben werden. Wird 0 gewählt, wird keine Ausgabe zur
-Fehlersuche angezeigt, 1 bedeutet eine knappe Ausgabe und 2 lässt alle
-Erstellungsprotokollausgaben auf die Standardfehlerausgabe schreiben.
-@item --cores=@var{n}
-@itemx -c @var{n}
-Die Nutzung von bis zu @var{n} Prozessorkernen für die Erstellungen
-gestatten. Der besondere Wert @code{0} bedeutet, dass so viele wie möglich
-benutzt werden.
-@item --max-jobs=@var{n}
-@itemx -M @var{n}
-Höchstens @var{n} gleichzeitige Erstellungsaufträge erlauben. Im Abschnitt
-@ref{Aufruf des guix-daemon, @code{--max-jobs}} finden Sie Details zu dieser
-Option und der äquivalenten Option des @command{guix-daemon}.
-@item --debug=@var{Stufe}
-Ein Protokoll zur Fehlersuche ausgeben, das vom Erstellungsdaemon kommt. Als
-@var{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.
-@end table
-Intern ist @command{guix build} im Kern eine Schnittstelle zur Prozedur
-@code{package-derivation} aus dem Modul @code{(guix packages)} und zu der
-Prozedur @code{build-derivations} des Moduls @code{(guix derivations)}.
-Neben auf der Befehlszeile übergebenen Optionen beachten @command{guix
-build} und andere @command{guix}-Befehle, die Erstellungen durchführen
-lassen, die Umgebungsvariable @code{GUIX_BUILD_OPTIONS}.
-@defvr {Umgebungsvariable} GUIX_BUILD_OPTIONS
-Nutzer können diese Variable auf eine Liste von Befehlszeilenoptionen
-definieren, die automatisch von @command{guix build} und anderen
-@command{guix}-Befehlen, die Erstellungen durchführen lassen, benutzt wird,
-wie in folgendem Beispiel:
-@example
-$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"
-@end example
-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.
-@end defvr
-@node Paketumwandlungsoptionen
-@subsection Paketumwandlungsoptionen
-@cindex Paketvarianten
-Eine weitere Gruppe von Befehlszeilenoptionen, die @command{guix build} und
-auch @command{guix package} unterstützen, sind
-@dfn{Paketumwandlungsoptionen}. Diese Optionen ermöglichen es,
-@dfn{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 @ref{Pakete definieren}).
-@table @code
-@item --with-source=@var{Quelle}
-@itemx --with-source=@var{Paket}=@var{Quelle}
-@itemx --with-source=@var{Paket}@@@var{Version}=@var{Quelle}
-Den Paketquellcode für das @var{Paket} von der angegebenen @var{Quelle}
-holen und die @var{Version} als seine Versionsnummer verwenden. Die
-@var{Quelle} muss ein Dateiname oder eine URL sein wie bei @command{guix
-download} (siehe @ref{Aufruf von guix download}).
-Wird kein @var{Paket} angegeben, wird als Paketname derjenige auf der
-Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende der
-@var{Quelle} passt — wenn z.B.@: als @var{Quelle} die Datei
-@code{/src/guile-2.0.10.tar.gz} angegeben wurde, entspricht das dem
-@code{guile}-Paket.
-Ebenso wird, wenn keine @var{Version} angegeben wurde, die Version als
-Zeichenkette aus der @var{Quelle} abgeleitet; im vorherigen Beispiel wäre
-sie @code{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 @file{ed-1.7.tar.gz} von einem GNU-Spiegelserver herunter und
-benutzt es als Quelle für das @code{ed}-Paket:
-@example
-guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz
-@end example
-Für Entwickler wird es einem durch @code{--with-source} leicht gemacht,
-»Release Candidates«, also Vorabversionen, zu testen:
-@example
-guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz
-@end example
-@dots{} oder ein Checkout eines versionskontrollierten Repositorys in einer
-isolierten Umgebung zu erstellen:
-@example
-$ git clone git://git.sv.gnu.org/guix.git
-$ guix build guix --with-source=guix@@1.0=./guix
-@end example
-@item --with-input=@var{Paket}=@var{Ersatz}
-Abhängigkeiten vom @var{Paket} durch eine Abhängigkeit vom
-@var{Ersatz}-Paket ersetzen. Als @var{Paket} muss ein Paketname angegeben
-werden und als @var{Ersatz} eine Paketspezifikation wie @code{guile} oder
-@code{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
-@code{guile@@2.0} ab:
-@example
-guix build --with-input=guile=guile@@2.0 guix
-@end example
-Die Ersetzung ist rekursiv und umfassend. In diesem Beispiel würde nicht nur
-@code{guix}, sondern auch seine Abhängigkeit @code{guile-json} (was auch von
-@code{guile} abhängt) für @code{guile@@2.0} neu erstellt.
-Implementiert wird das alles mit der Scheme-Prozedur
-@code{package-input-rewriting} (siehe @ref{Pakete definieren,
-@code{package-input-rewriting}}).
-@item --with-graft=@var{Paket}=@var{Ersatz}
-Dies verhält sich ähnlich wie mit @code{--with-input}, aber mit dem
-wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette neu
-erstellt wird, sondern das @var{Ersatz}-Paket erstellt und die
-ursprünglichen Binärdateien, die auf das @var{Paket} verwiesen haben, damit
-@dfn{veredelt} werden. Im Abschnitt @ref{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:
-@example
-guix build --with-graft=gnutls=gnutls@@3.5.4 wget
-@end example
-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 @var{Paket} und sein @var{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 @var{Ersatz}-Paket auf irgendeine Art inkompatibel
-mit dem @var{Paket} ist, könnte das Ergebnispaket unbrauchbar sein. Vorsicht
-ist also geboten!
-@item --with-git-url=@var{Paket}=@var{URL}
-@cindex Git, den neuesten Commit benutzen
-@cindex latest commit, building
-Build @var{package} from the latest commit of the @code{master} branch of
-the Git repository at @var{url}.  Git sub-modules of the repository are
-fetched, recursively.
-For example, the following command builds the NumPy Python library against
-the latest commit of the master branch of Python itself:
-@example
-guix build python-numpy \
-  --with-git-url=python=https://github.com/python/cpython
-@end example
-This option can also be combined with @code{--with-branch} or
-@code{--with-commit} (see below).
-@cindex continuous integration
-Obviously, since it uses the latest commit of the given branch, the result
-of such a command varies over time.  Nevertheless it is a convenient way to
-rebuild entire software stacks against the latest commit of one or more
-packages.  This is particularly useful in the context of continuous
-integration (CI).
-Checkouts are kept in a cache under @file{~/.cache/guix/checkouts} to speed
-up consecutive accesses to the same repository.  You may want to clean it up
-once in a while to save disk space.
-@item --with-branch=@var{Paket}=@var{Branch}
-Build @var{package} from the latest commit of @var{branch}.  If the
-@code{source} field of @var{package} is an origin with the @code{git-fetch}
-method (@pxref{»origin«-Referenz}) or a @code{git-checkout} object, the
-repository URL is taken from that @code{source}.  Otherwise you have to use
-@code{--with-git-url} to specify the URL of the Git repository.
-For instance, the following command builds @code{guile-sqlite3} from the
-latest commit of its @code{master} branch, and then builds @code{guix}
-(which depends on it) and @code{cuirass} (which depends on @code{guix})
-against this specific @code{guile-sqlite3} build:
-@example
-guix build --with-branch=guile-sqlite3=master cuirass
-@end example
-@item --with-commit=@var{Paket}=@var{Commit}
-This is similar to @code{--with-branch}, except that it builds from
-@var{commit} rather than the tip of a branch.  @var{commit} must be a valid
-Git commit SHA1 identifier.
-@end table
-@node Zusätzliche Erstellungsoptionen
-@subsection Zusätzliche Erstellungsoptionen
-Die unten aufgeführten Befehlszeilenoptionen funktionieren nur mit
-@command{guix build}.
-@table @code
-@item --quiet
-@itemx -q
-Schweigend erstellen, ohne das Erstellungsprotokoll anzuzeigen — dies ist
-äquivalent zu @code{--verbosity=0}. Nach Abschluss der Erstellung ist das
-Protokoll in @file{/var} (oder einem entsprechenden Ort) einsehbar und kann
-jederzeit mit der Befehlszeilenoption @option{--log-file} gefunden werden.
-@item --file=@var{Datei}
-@itemx -f @var{Datei}
-Das Paket, die Ableitung oder das dateiähnliche Objekt erstellen, zu dem der
-Code in der @var{Datei} ausgewertet wird (siehe @ref{G-Ausdrücke,
-file-like objects}).
-Zum Beispiel könnte in der @var{Datei} so eine Paketdefinition stehen (siehe
-@ref{Pakete definieren}):
-@example
-@verbatiminclude package-hello.scm
-@end example
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Das Paket oder die Ableitung erstellen, zu der der @var{Ausdruck}
-ausgewertet wird.
-Zum Beispiel kann der @var{Ausdruck} @code{(@@ (gnu packages guile)
-guile-1.8)} sein, was diese bestimmte Variante der Version 1.8 von Guile
-eindeutig bezeichnet.
-Alternativ kann der @var{Ausdruck} ein G-Ausdruck sein. In diesem Fall wird
-er als Erstellungsprogramm an @code{gexp->derivation} übergeben (siehe
-@ref{G-Ausdrücke}).
-Zudem kann der @var{Ausdruck} eine monadische Prozedur mit null Argumenten
-bezeichnen (siehe @ref{Die Store-Monade}). Die Prozedur muss eine Ableitung
-als monadischen Wert zurückliefern, die dann durch @code{run-with-store}
-laufen gelassen wird.
-@item --source
-@itemx -S
-Die Quellcode-Ableitung der Pakete statt die Pakete selbst erstellen.
-Zum Beispiel liefert @code{guix build -S gcc} etwas in der Art von
-@file{/gnu/store/@dots{}-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 @code{origin}-Objekt des Pakets
-festgelegt wurden (siehe @ref{Pakete definieren}).
-@item --sources
-Den Quellcode für @var{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 @code{--source}, die jeden der folgenden Argumentwerte
-akzeptiert:
-@table @code
-@item package
-Mit diesem Wert verhält sich die Befehlszeilenoption @code{--sources} auf
-genau die gleiche Weise wie die Befehlszeilenoption @code{--source}.
-@item all
-Erstellt die Quellcode-Ableitungen aller Pakete einschließlich allen
-Quellcodes, der als Teil der Eingaben im @code{inputs}-Feld aufgelistet
-ist. Dies ist der vorgegebene Wert, wenn sonst keiner angegeben wird.
-@example
-$ guix build --sources tzdata
-Folgende Ableitungen werden erstellt:
-   /gnu/store/@dots{}-tzdata2015b.tar.gz.drv
-   /gnu/store/@dots{}-tzcode2015b.tar.gz.drv
-@end example
-@item 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.
-@example
-$ guix build --sources=transitive tzdata
-Folgende Ableitungen werden erstellt:
-   /gnu/store/@dots{}-tzcode2015b.tar.gz.drv
-   /gnu/store/@dots{}-findutils-4.4.2.tar.xz.drv
-   /gnu/store/@dots{}-grep-2.21.tar.xz.drv
-   /gnu/store/@dots{}-coreutils-8.23.tar.xz.drv
-   /gnu/store/@dots{}-make-4.1.tar.xz.drv
-   /gnu/store/@dots{}-bash-4.3.tar.xz.drv
-@dots{}
-@end example
-@end table
-@item --system=@var{System}
-@itemx -s @var{System}
-Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu
-erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die
-Erstellung durchführt.
-@quotation Anmerkung
-Die Befehlszeilenoption @code{--system} dient der @emph{nativen}
-Kompilierung (nicht zu verwechseln mit Cross-Kompilierung). Siehe
-@code{--target} unten für Informationen zur Cross-Kompilierung.
-@end quotation
-Ein Beispiel sind Linux-basierte Systeme, die verschiedene Persönlichkeiten
-emulieren können. Zum Beispiel können Sie @code{--system=i686-linux} auf
-einem @code{x86_64-linux}-System oder @code{--system=armhf-linux} auf einem
-@code{aarch64-linux}-System angeben, um Pakete in einer vollständigen
-32-Bit-Umgebung zu erstellen.
-@quotation Anmerkung
-Das Erstellen für ein @code{armhf-linux}-System ist ungeprüft auf allen
-@code{aarch64-linux}-Maschinen aktiviert, obwohl bestimmte aarch64-Chipsätze
-diese Funktionalität nicht unterstützen, darunter auch ThunderX.
-@end quotation
-Ebenso können Sie, wenn transparente Emulation mit QEMU und
-@code{binfmt_misc} aktiviert sind (siehe @ref{Virtualisierungsdienste,
-@code{qemu-binfmt-service-type}}), für jedes System Erstellungen
-durchführen, für das ein QEMU-@code{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 @ref{Auslagern des Daemons einrichten}
-für mehr Informationen über das Auslagern.
-@item --target=@var{Tripel}
-@cindex Cross-Kompilieren
-Lässt für das angegebene @var{Tripel} cross-erstellen, dieses muss ein
-gültiges GNU-Tripel wie z.B.@: @code{"mips64el-linux-gnu"} sein (siehe
-@ref{Specifying target triplets, GNU configuration triplets,, autoconf,
-Autoconf}).
-@anchor{build-check}
-@item --check
-@cindex Determinismus, Überprüfung
-@cindex Reproduzierbarkeit, Überprüfung
-@var{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 @ref{Substitute}) oder auch ob das
-Erstellungsergebnis eines Pakets deterministisch ist. Siehe @ref{Aufruf von guix challenge} für mehr Hintergrundinformationen und Werkzeuge.
-Wenn dies zusammen mit @option{--keep-failed} benutzt wird, bleiben die sich
-unterscheidenden Ausgaben im Store unter dem Namen
-@file{/gnu/store/@dots{}-check}. Dadurch können Unterschiede zwischen den
-beiden Ergebnissen leicht erkannt werden.
-@item --repair
-@cindex Reparieren von Store-Objekten
-@cindex Datenbeschädigung, Behebung
-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 @code{root}
-kann sie verwenden.
-@item --derivations
-@itemx -d
-Liefert die Ableitungspfade und @emph{nicht} die Ausgabepfade für die
-angegebenen Pakete.
-@item --root=@var{Datei}
-@itemx -r @var{Datei}
-@cindex GC-Wurzeln, Hinzufügen
-@cindex Müllsammlerwurzeln, Hinzufügen
-Die @var{Datei} zu einer symbolischen Verknüpfung auf das Ergebnis machen
-und als Müllsammlerwurzel registrieren.
-Dadurch wird das Ergebnis dieses Aufrufs von @command{guix build} vor dem
-Müllsammler geschützt, bis die @var{Datei} gelöscht wird. Wird diese
-Befehlszeilenoption @emph{nicht} angegeben, können Erstellungsergebnisse vom
-Müllsammler geholt werden, sobald die Erstellung abgeschlossen ist. Siehe
-@ref{Aufruf von guix gc} für mehr Informationen zu Müllsammlerwurzeln.
-@item --log-file
-@cindex Erstellungsprotokolle, Zugriff
-Liefert die Dateinamen oder URLs der Erstellungsprotokolle für das
-angegebene @var{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:
-@example
-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)'
-@end example
-Wenn ein Protokoll lokal nicht verfügbar ist und sofern
-@code{--no-substitutes} nicht übergeben wurde, sucht der Befehl nach einem
-entsprechenden Protokoll auf einem der Substitutserver (die mit
-@code{--substitute-urls} angegeben werden können).
-Stellen Sie sich zum Beispiel vor, sie wollten das Erstellungsprotokoll von
-GDB auf einem MIPS-System sehen, benutzen aber selbst eine
-@code{x86_64}-Maschine:
-@example
-$ guix build --log-file gdb -s mips64el-linux
-https://@value{SUBSTITUTE-SERVER}/log/@dots{}-gdb-7.10
-@end example
-So haben Sie umsonst Zugriff auf eine riesige Bibliothek von
-Erstellungsprotokollen!
-@end table
-@node Fehlschläge beim Erstellen untersuchen
-@subsection Fehlschläge beim Erstellen untersuchen
-@cindex Erstellungsfehler, Fehlersuche
-Wenn Sie ein neues Paket definieren (siehe @ref{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
-@option{--keep-failed} oder @option{-K} von @command{guix build}
-einzusetzen, wodurch Verzeichnisbäume fehlgeschlagener Erstellungen in
-@file{/tmp} oder dem von Ihnen als @code{TMPDIR} ausgewiesenen Verzeichnis
-erhalten und nicht gelöscht werden (siehe @ref{Aufruf von guix build,
-@code{--keep-failed}}).
-Im Anschluss können Sie mit @command{cd} in die Verzeichnisse dieses
-fehlgeschlagenen Erstellungsbaums wechseln und mit @command{source} dessen
-@file{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
-@code{foo}, dann würde eine typische Sitzung so aussehen:
-@example
-$ guix build foo -K
-@dots{} @i{build fails}
-$ cd /tmp/guix-build-foo.drv-0
-$ source ./environment-variables
-$ cd foo-1.2
-@end example
-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, @file{/bin/sh} nicht exisiert usw.@: (siehe
-@ref{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:
-@example
-$ guix build -K foo
-@dots{}
-$ cd /tmp/guix-build-foo.drv-0
-$ guix environment --no-grafts -C foo --ad-hoc strace gdb
-[env]# source ./environment-variables
-[env]# cd foo-1.2
-@end example
-Hierbei erzeugt @command{guix environment -C} eine isolierte Umgebung und
-öffnet darin eine Shell (siehe @ref{Aufruf von guix environment}). Der Teil
-mit @command{--ad-hoc strace gdb} fügt die Befehle @command{strace} und
-@command{gdb} zur isolierten Umgebung hinzu, die Sie gut gebrauchen könnten,
-während Sie Fehler suchen. Wegen der Befehlszeilenoption
-@option{--no-grafts} bekommen Sie haargenau dieselbe Umgebung ohne veredelte
-Pakete (siehe @ref{Sicherheitsaktualisierungen} für mehr Informationen zu
-Veredelungen).
-Um der isolierten Umgebung des Erstellungsdaemons noch näher zu kommen,
-können wir @file{/bin/sh} entfernen:
-@example
-[env]# rm /bin/sh
-@end example
-(Keine Sorge, das ist harmlos: All dies passiert nur in der zuvor von
-@command{guix environment} erzeugten Wegwerf-Umgebung.)
-Der Befehl @command{strace} befindet sich wahrscheinlich nicht in Ihrem
-Suchpfad, aber wir können ihn so benutzen:
-@example
-[env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check
-@end example
-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.
-@node Aufruf von guix edit
-@section @command{guix edit} aufrufen
-@cindex @command{guix edit}
-@cindex Paketdefinition, Bearbeiten
-So viele Pakete, so viele Quelldateien! Der Befehl @command{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:
-@example
-guix edit gcc@@4.9 vim
-@end example
-@noindent
-das mit der Umgebungsvariablen @code{VISUAL} ode @code{EDITOR} angegebene
-Programm und lässt es das Rezept von GCC@tie{}4.9.3 und von Vim anzeigen.
-Wenn Sie ein Git-Checkout von Guix benutzen (siehe @ref{Erstellung aus dem Git})
-oder Ihre eigenen Pakete im @code{GUIX_PACKAGE_PATH} erstellt haben (siehe
-@ref{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.
-@node Aufruf von guix download
-@section @command{guix download} aufrufen
-@cindex @command{guix download}
-@cindex Paketquellcode herunterladen
-Wenn Entwickler einer Paketdefinition selbige schreiben, müssen diese
-normalerweise einen Quellcode-Tarball herunterladen, seinen SHA256-Hash als
-Prüfsumme berechnen und diese in der Paketdefinition eintragen (siehe
-@ref{Pakete definieren}). Das Werkzeug @command{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 @command{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 @ref{Aufruf von guix gc}).
-Der Befehl @command{guix download} unterstützt dieselben URIs, die in
-Paketdefinitionen verwendet werden. Insbesondere unterstützt er
-@code{mirror://}-URIs. @code{https}-URIs (HTTP über TLS) werden unterstützt,
-@emph{vorausgesetzt} die Guile-Anbindungen für GnuTLS sind in der Umgebung
-des Benutzers verfügbar; wenn nicht, wird ein Fehler gemeldet. Siehe
-@ref{Guile Preparations, how to install the GnuTLS bindings for Guile,,
-gnutls-guile, GnuTLS-Guile}, hat mehr Informationen.
-Mit @command{guix download} werden HTTPS-Serverzertifikate verifiziert,
-indem die Zertifikate der X.509-Autoritäten in das durch die
-Umgebungsvariable @code{SSL_CERT_DIR} bezeichnete Verzeichnis
-heruntergeladen werden (siehe @ref{X.509-Zertifikate}), außer
-@option{--no-check-certificate} wird benutzt.
-Folgende Befehlszeilenoptionen stehen zur Verfügung:
-@table @code
-@item --format=@var{Format}
-@itemx -f @var{Format}
-Die Hash-Prüfsumme im angegebenen @var{Format} ausgeben. Für weitere
-Informationen, was gültige Werte für das @var{Format} sind, siehe
-@ref{Aufruf von guix hash}.
-@item --no-check-certificate
-X.509-Zertifikate von HTTPS-Servern @emph{nicht} validieren.
-Wenn Sie diese Befehlszeilenoption benutzen, haben Sie @emph{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.
-@item --output=@var{Datei}
-@itemx -o @var{Datei}
-Die heruntergeladene Datei @emph{nicht} in den Store, sondern in die
-angegebene @var{Datei} abspeichern.
-@end table
-@node Aufruf von guix hash
-@section @command{guix hash} aufrufen
-@cindex @command{guix hash}
-Der Befehl @command{guix hash} berechnet den SHA256-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 @ref{Pakete definieren}).
-Die allgemeine Syntax lautet:
-@example
-guix hash @var{Option} @var{Datei}
-@end example
-Wird als @var{Datei} ein Bindestrich @code{-} angegeben, berechnet
-@command{guix hash} den Hash der von der Standardeingabe gelesenen
-Daten. @command{guix hash} unterstützt die folgenden Optionen:
-@table @code
-@item --format=@var{Format}
-@itemx -f @var{Format}
-Gibt die Prüfsumme im angegebenen @var{Format} aus.
-Unterstützte Formate: @code{nix-base32}, @code{base32}, @code{base16}
-(@code{hex} und @code{hexadecimal} können auch benutzt werden).
-Wird keine Befehlszeilenoption @option{--format} angegeben, wird
-@command{guix hash} die Prüfsumme im @code{nix-base32}-Format
-ausgeben. Diese Darstellung wird bei der Definition von Paketen benutzt.
-@item --recursive
-@itemx -r
-Die Prüfsumme der @var{Datei} rekursiv berechnen.
-@c FIXME: Replace xref above with xref to an ``Archive'' section when
-@c it exists.
-In diesem Fall wird die Prüfsumme eines Archivs berechnet, das die
-@var{Datei} enthält, und auch ihre Kinder, wenn es sich um ein Verzeichnis
-handelt. Einige der Metadaten der @var{Datei} sind Teil dieses Archivs. Zum
-Beispiel unterscheidet sich die berechnete Prüfsumme, wenn die @var{Datei}
-eine reguläre Datei ist, je nachdem, ob die @var{Datei} ausführbar ist oder
-nicht. Metadaten wie der Zeitstempel haben keinen Einfluss auf die Prüfsumme
-(siehe @ref{Aufruf von guix archive}).
-@item --exclude-vcs
-@itemx -x
-Wenn dies zusammen mit der Befehlszeilenoption @option{--recursive}
-angegeben wird, werden Verzeichnisse zur Versionskontrolle (@file{.bzr},
-@file{.git}, @file{.hg}, etc.)@: vom Archiv ausgenommen.
-@vindex git-fetch
-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
-@code{git-fetch} benutzen (siehe @ref{»origin«-Referenz}):
-@example
-$ git clone http://example.org/foo.git
-$ cd foo
-$ guix hash -rx .
-@end example
-@end table
-@node Aufruf von guix import
-@section @command{guix import} aufrufen
-@cindex Pakete importieren
-@cindex Paketimport
-@cindex Pakete an Guix anpassen
-@cindex @command{guix import} aufrufen
-Der Befehl @command{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
-@ref{Pakete definieren}).
-Die allgemeine Syntax lautet:
-@example
-guix import @var{Importer} @var{Optionen}@dots{}
-@end example
-Der @var{Importer} gibt die Quelle an, aus der Paketmetadaten importiert
-werden, und die @var{Optionen} geben eine Paketbezeichnung und andere vom
-@var{Importer} abhängige Daten an. Derzeit sind folgende »Importer«
-verfügbar:
-@table @code
-@item 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@tie{}Hello:
-@example
-guix import gnu hello
-@end example
-Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur
-Verfügung:
-@table @code
-@item --key-download=@var{Richtlinie}
-Die Richtlinie zum Umgang mit fehlenden OpenPGP-Schlüsseln beim Verifizieren
-der Paketsignatur (auch »Beglaubigung« genannt) festlegen, wie bei
-@code{guix refresh}. Siehe @ref{Aufruf von guix refresh,
-@code{--key-download}}.
-@end table
-@item pypi
-@cindex pypi
-Metadaten aus dem @uref{https://pypi.python.org/, Python Package Index}
-importieren. Informationen stammen aus der JSON-formatierten Beschreibung,
-die unter @code{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 @command{unzip} zu
-installieren, damit der Importer »Python Wheels« entpacken und daraus Daten
-beziehen kann.
-Der folgende Befehl importiert Metadaten für das Python-Paket namens
-@code{itsdangerous}:
-@example
-guix import pypi itsdangerous
-@end example
-@table @code
-@item --recursive
-@itemx -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.
-@end table
-@item gem
-@cindex gem
-Metadaten von @uref{https://rubygems.org/, RubyGems}
-importieren. Informationen kommen aus der JSON-formatierten Beschreibung,
-die auf @code{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 @code{rails}.
-@example
-guix import gem rails
-@end example
-@table @code
-@item --recursive
-@itemx -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.
-@end table
-@item cpan
-@cindex CPAN
-Importiert Metadaten von @uref{https://www.metacpan.org/,
-MetaCPAN}. Informationen werden aus den JSON-formatierten Metadaten
-genommen, die über die @uref{https://fastapi.metacpan.org/,
-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 @code{corelist}
-benutzt, um Kernmodule in der Abhängigkeitsliste wegzulassen.
-Folgender Befehl importiert Metadaten für das Perl-Modul
-@code{Acme::Boolean}:
-@example
-guix import cpan Acme::Boolean
-@end example
-@item cran
-@cindex CRAN
-@cindex Bioconductor
-Metadaten aus dem @uref{https://cran.r-project.org/, CRAN} importieren, der
-zentralen Sammlung für die @uref{http://r-project.org, statistische und
-grafische Umgebung GNU@tie{}R}.
-Informationen werden aus der Datei namens @code{DESCRIPTION} des Pakets
-extrahiert.
-Der folgende Befehl importiert Metadaten für das @code{Cairo}-R-Paket:
-@example
-guix import cran Cairo
-@end example
-Wird zudem @code{--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 @code{--archive=bioconductor} angegeben, werden Metadaten vom
-@uref{https://www.bioconductor.org/, 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 @code{DESCRIPTION}-Datei im Paket extrahiert,
-das auf der Weboberfläche des Bioconductor-SVN-Repositorys veröffentlicht
-wurde.
-Der folgende Befehl importiert Metadaten für das R-Paket
-@code{GenomicRanges}:
-@example
-guix import cran --archive=bioconductor GenomicRanges
-@end example
-@item texlive
-@cindex TeX Live
-@cindex CTAN
-Metadaten aus @uref{http://www.ctan.org/, CTAN}, dem umfassenden
-TeX-Archivnetzwerk, herunterladen, was für TeX-Pakete benutzt wird, die Teil
-der @uref{https://www.tug.org/texlive/, TeX-Live-Distribution} sind.
-Informationen über das Paket werden über die von CTAN angebotene
-XML-Programmierschnittstelle bezogen, wohingegen der Quellcode aus dem
-SVN-Repository des TeX-Live-Projekts heruntergeladen wird. Das wird so
-gemacht, weil CTAN keine versionierten Archive vorhält.
-Der folgende Befehl importiert Metadaten für das TeX-Paket @code{fontspec}:
-@example
-guix import texlive fontspec
-@end example
-Wenn @code{--archive=VERZEICHNIS} angegeben wird, wird der Quellcode
-@emph{nicht} aus dem Unterverzeichnis @file{latex} des
-@file{texmf-dist/source}-Baums im SVN-Repository von TeX Live
-heruntergeladen, sondern aus dem angegebenen Schwesterverzeichnis im selben
-Wurzelverzeichnis.
-Der folgende Befehl importiert Metadaten für das Paket @code{ifxetex} aus
-CTAN und lädt die Quelldateien aus dem Verzeichnis
-@file{texmf/source/generic}:
-@example
-guix import texlive --archive=generic ifxetex
-@end example
-@item json
-@cindex JSON, Import
-Paketmetadaten aus einer lokalen JSON-Datei importieren. Betrachten Sie
-folgende Beispiel-Paketdefinition im JSON-Format:
-@example
-@{
-  "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": ["gcc@@6"]
-@}
-@end example
-Die Felder sind genauso benannt wie bei einem @code{<package>}-Verbundstyp
-(siehe @ref{Pakete definieren}). Referenzen zu anderen Paketen stehen darin
-als JSON-Liste von mit Anführungszeichen quotierten Zeichenketten wie
-@code{guile} oder @code{guile@@2.0}.
-Der Importer unterstützt auch eine ausdrücklichere Definition der
-Quelldateien mit den üblichen Feldern eines @code{<origin>}-Verbunds:
-@example
-@{
-  @dots{}
-  "source": @{
-    "method": "url-fetch",
-    "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
-    "sha256": @{
-      "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
-    @}
-  @}
-  @dots{}
-@}
-@end example
-Der folgende Befehl liest Metadaten aus der JSON-Datei @code{hello.json} und
-gibt einen Paketausdruck aus:
-@example
-guix import json hello.json
-@end example
-@item nix
-Metadaten aus einer lokalen Kopie des Quellcodes der
-@uref{http://nixos.org/nixpkgs/, Nixpkgs-Distribution}
-importieren@footnote{Dazu wird der Befehl @command{nix-instantiate} von
-@uref{http://nixos.org/nix/, Nix} verwendet.}. Paketdefinitionen in Nixpkgs
-werden typischerweise in einer Mischung aus der Sprache von Nix und aus
-Bash-Code geschrieben. Dieser Befehl wird nur die abstrakte Paketstruktur,
-die in der Nix-Sprache geschrieben ist, importieren. Dazu gehören
-normalerweise alle grundlegenden Felder einer Paketdefinition.
-Beim Importieren eines GNU-Pakets werden Zusammenfassung und Beschreibung
-stattdessen durch deren kanonische Variante bei GNU ersetzt.
-Normalerweise würden Sie zunächst dies ausführen:
-@example
-export NIX_REMOTE=daemon
-@end example
-@noindent
-damit @command{nix-instantiate} nicht versucht, die Nix-Datenbank zu öffnen.
-Zum Beispiel importiert der Befehl unten die Paketdefinition von LibreOffice
-(genauer gesagt importiert er die Definition des an das Attribut
-@code{libreoffice} auf oberster Ebene gebundenen Pakets):
-@example
-guix import nix ~/path/to/nixpkgs libreoffice
-@end example
-@item hackage
-@cindex hackage
-Metadaten aus @uref{https://hackage.haskell.org/, 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:
-@table @code
-@item --stdin
-@itemx -s
-Eine Cabal-Datei von der Standardeingabe lesen.
-@item --no-test-dependencies
-@itemx -t
-Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden.
-@item --cabal-environment=@var{Aliste}
-@itemx -e @var{Aliste}
-@var{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: @code{os}, @code{arch},
-@code{impl} und eine Zeichenkette, die dem Namen einer Option (einer »Flag«)
-entspricht. Der mit einer »Flag« assoziierte Wert muss entweder das Symbol
-@code{true} oder @code{false} sein. Der anderen Schlüsseln zugeordnete Wert
-muss mit der Definition des Cabal-Dateiformats konform sein. Der vorgegebene
-Wert zu den Schlüsseln @code{os}, @code{arch} and @code{impl} ist jeweils
-@samp{linux}, @samp{x86_64} bzw. @samp{ghc}.
-@item --recursive
-@itemx -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.
-@end table
-Der folgende Befehl importiert Metadaten für die neuste Version des
-Haskell-@code{HTTP}-Pakets, ohne Testabhängigkeiten zu übernehmen und bei
-Übergabe von @code{false} als Wert der Flag @samp{network-uri}:
-@example
-guix import hackage -t -e "'((\"network-uri\" . false))" HTTP
-@end example
-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:
-@example
-guix import hackage mtl@@2.1.3.1
-@end example
-@item stackage
-@cindex stackage
-Der @code{stackage}-Importer ist ein Wrapper um den
-@code{hackage}-Importer. Er nimmt einen Paketnamen und schaut dafür die
-Paketversion nach, die Teil einer @uref{https://www.stackage.org,
-Stackage}-Veröffentlichung mit Langzeitunterstützung (englisch »Long-Term
-Support«, kurz LTS) ist, deren Metadaten er dann mit dem
-@code{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:
-@table @code
-@item --no-test-dependencies
-@itemx -t
-Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden.
-@item --lts-version=@var{Version}
-@itemx -l @var{Version}
-@var{Version} ist die gewünschte Version der LTS-Veröffentlichung. Wird
-keine angegeben, wird die neueste benutzt.
-@item --recursive
-@itemx -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.
-@end table
-Der folgende Befehl importiert Metadaten für dasjenige
-@code{HTTP}-Haskell-Paket, das in der LTS-Stackage-Veröffentlichung mit
-Version 7.18 vorkommt:
-@example
-guix import stackage --lts-version=7.18 HTTP
-@end example
-@item elpa
-@cindex elpa
-Metadaten aus der Paketsammlung »Emacs Lisp Package Archive« (ELPA)
-importieren (siehe @ref{Packages,,, emacs, The GNU Emacs Manual}).
-Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur
-Verfügung:
-@table @code
-@item --archive=@var{Repo}
-@itemx -a @var{Repo}
-Mit @var{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:
-@itemize -
-@item
-@uref{http://elpa.gnu.org/packages, GNU}, bezeichnet mit @code{gnu}. Dies
-ist die Vorgabe.
-Pakete aus @code{elpa.gnu.org} wurden mit einem der Schlüssel im
-GnuPG-Schlüsselbund in @file{share/emacs/25.1/etc/package-keyring.gpg} (oder
-einem ähnlichen Pfad) des @code{emacs}-Pakets signiert (siehe @ref{Package
-Installation, ELPA package signatures,, emacs, The GNU Emacs Manual}).
-@item
-@uref{http://stable.melpa.org/packages, MELPA-Stable}, bezeichnet mit
-@code{melpa-stable}.
-@item
-@uref{http://melpa.org/packages, MELPA}, bezeichnet mit @code{melpa}.
-@end itemize
-@item --recursive
-@itemx -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.
-@end table
-@item crate
-@cindex crate
-Metadaten aus der Paketsammlung crates.io für Rust importieren
-@uref{https://crates.io, crates.io}.
-@item opam
-@cindex OPAM
-@cindex OCaml
-Metadaten aus der Paketsammlung @uref{https://opam.ocaml.org/, OPAM} der
-OCaml-Gemeinde importieren.
-@end table
-@command{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 @ref{Mitwirken}).
-@node Aufruf von guix refresh
-@section @command{guix refresh} aufrufen
-@cindex @command{guix refresh}
-Die Zielgruppe des Befehls @command{guix refresh} zum Auffrischen von
-Paketen sind in erster Linie Entwickler der GNU-Software-Distribution. Nach
-Vorgabe werden damit alle Pakete in der Distribution gemeldet, die nicht der
-neuesten Version des Anbieters entsprechen, indem Sie dies ausführen:
-@example
-$ 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
-@end example
-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:
-@example
-$ 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
-@end example
-@command{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 @option{--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!
-@table @code
-@item --recursive
-Consider the packages specified, and all the packages upon which they
-depend.
-@example
-$ guix refresh --recursive coreutils
-gnu/packages/acl.scm:35:2: warning: no updater for acl
-gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4
-gnu/packages/xml.scm:68:2: warning: no updater for expat
-gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp
-@dots{}
-@end example
-@end table
-Manchmal unterscheidet sich der vom Anbieter benutzte Name von dem
-Paketnamen, der in Guix verwendet wird, so dass @command{guix refresh} etwas
-Unterstützung braucht. Die meisten Aktualisierungsprogramme folgen der
-Eigenschaft @code{upstream-name} in Paketdefinitionen, die diese
-Unterstützung bieten kann.
-@example
-(define-public network-manager
-  (package
-    (name "network-manager")
-    ;; @dots{}
-    (properties '((upstream-name . "NetworkManager")))))
-@end example
-Wenn @code{--update} übergeben wird, werden die Quelldateien der
-Distribution verändert, so dass für diese Paketrezepte die aktuelle Version
-und die aktuelle Hash-Prüfsumme des Quellcode-Tarballs eingetragen wird
-(siehe @ref{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
-@command{gpg} authentifiziert und schließlich dessen Hash berechnet. 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 @command{guix
-refresh} einen Fehler.
-Die folgenden Befehlszeilenoptionen werden unterstützt:
-@table @code
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird.
-Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in
-diesem Beispiel:
-@example
-guix refresh -l -e '(@@@@ (gnu packages commencement) glibc-final)'
-@end example
-Dieser Befehls listet auf, was alles von der »endgültigen« Erstellung von
-libc abhängt (praktisch alle Pakete).
-@item --update
-@itemx -u
-Die Quelldateien der Distribution (die Paketrezepte) werden direkt »in
-place« verändert. Normalerweise führen Sie dies aus einem Checkout des
-Guix-Quellbaums heraus aus (siehe @ref{Guix vor der Installation ausführen}):
-@example
-$ ./pre-inst-env guix refresh -s non-core -u
-@end example
-Siehe @ref{Pakete definieren} für mehr Informationen zu Paketdefinitionen.
-@item --select=[@var{Teilmenge}]
-@itemx -s @var{Teilmenge}
-Wählt alle Pakete aus der @var{Teilmenge} aus, die entweder @code{core} oder
-@code{non-core} sein muss.
-Die @code{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 @code{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.
-@item --manifest=@var{Datei}
-@itemx -m @var{Datei}
-Wählt alle Pakete im in der @var{Datei} stehenden Manifest aus. Das ist
-nützlich, um zu überprüfen, welche Pakete aus dem Manifest des Nutzers
-aktualisiert werden können.
-@item --type=@var{Aktualisierungsprogramm}
-@itemx -t @var{Aktualisierungsprogramm}
-Nur solche Pakete auswählen, die vom angegebenen
-@var{Aktualisierungsprogramm} behandelt werden. Es darf auch eine
-kommagetrennte Liste mehrerer Aktualisierungsprogramme angegeben werden. Zur
-Zeit kann als @var{Aktualisierungsprogramm} eines der folgenden angegeben
-werden:
-@table @code
-@item gnu
-Aktualisierungsprogramm für GNU-Pakete,
-@item gnome
-Aktualisierungsprogramm für GNOME-Pakete,
-@item kde
-Aktualisierungsprogramm für KDE-Pakete,
-@item xorg
-Aktualisierungsprogramm für X.org-Pakete,
-@item kernel.org
-Aktualisierungsprogramm auf kernel.org angebotener Pakete,
-@item elpa
-Aktualisierungsprogramm für @uref{http://elpa.gnu.org/, ELPA-Pakete},
-@item cran
-Aktualisierungsprogramm für @uref{https://cran.r-project.org/, CRAN-Pakete},
-@item bioconductor
-Aktualisierungsprogramm für R-Pakete vom
-@uref{https://www.bioconductor.org/, Bioconductor},
-@item cpan
-Aktualisierungsprogramm für @uref{http://www.cpan.org/, CPAN-Pakete},
-@item pypi
-Aktualisierungsprogramm für @uref{https://pypi.python.org, PyPI-Pakete},
-@item gem
-Aktualisierungsprogramm für @uref{https://rubygems.org, RubyGems-Pakete}.
-@item github
-Aktualisierungsprogramm für @uref{https://github.com, GitHub-Pakete}.
-@item hackage
-Aktualisierungsprogramm für @uref{https://hackage.haskell.org,
-Hackage-Pakete}.
-@item stackage
-Aktualisierungsprogramm für @uref{https://www.stackage.org,
-Stackage-Pakete}.
-@item crate
-Aktualisierungsprogramm für @uref{https://crates.io, Crates-Pakete}.
-@item launchpad
-Aktualisierungsprogramm für @uref{https://launchpad.net, Launchpad}.
-@end table
-Zum Beispiel prüft folgender Befehl nur auf mögliche Aktualisierungen von
-auf @code{elpa.gnu.org} angebotenen Emacs-Paketen und von CRAN-Paketen:
-@example
-$ guix refresh --type=elpa,cran
-gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
-gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
-@end example
-@end table
-An @command{guix refresh} können auch ein oder mehrere Paketnamen übergeben
-werden wie in diesem Beispiel:
-@example
-$ ./pre-inst-env guix refresh -u emacs idutils gcc@@4.8
-@end example
-@noindent
-Der Befehl oben aktualisiert speziell das @code{emacs}- und das
-@code{idutils}-Paket. Eine Befehlszeilenoption @code{--select} hätte dann
-keine Wirkung.
-Wenn Sie sich fragen, ob ein Paket aktualisiert werden sollte oder nicht,
-kann es helfen, sich anzuschauen, welche Pakete von der Aktualisierung
-betroffen wären und auf Kompatibilität hin geprüft werden sollten. Dazu kann
-die folgende Befehlszeilenoption zusammen mit einem oder mehreren Paketnamen
-an @command{guix refresh} übergeben werden:
-@table @code
-@item --list-updaters
-@itemx -L
-Eine Liste verfügbarer Aktualisierungsprogramme anzeigen und terminieren
-(siehe @option{--type} oben).
-Für jedes Aktualisierungsprogramm den Anteil der davon betroffenen Pakete
-anzeigen; zum Schluss wird der Gesamtanteil von irgendeinem
-Aktualisierungsprogramm betroffener Pakete angezeigt.
-@item --list-dependent
-@itemx -l
-Auflisten, welche abhängigen Pakete auf oberster Ebene neu erstellt werden
-müssten, wenn eines oder mehrere Pakete aktualisiert würden.
-Siehe @ref{Aufruf von guix graph, den @code{reverse-package}-Typ von
-@command{guix graph}} für Informationen dazu, wie Sie die Liste der
-Abhängigen eines Pakets visualisieren können.
-@end table
-Bedenken Sie, dass die Befehlszeilenoption @code{--list-dependent} das
-Ausmaß der nach einer Aktualisierungen benötigten Neuerstellungen nur
-@emph{annähert}. Es könnten auch unter Umständen mehr Neuerstellungen
-anfallen.
-@example
-$ guix refresh --list-dependent flex
-Building the following 120 packages would ensure 213 dependent packages are rebuilt:
-hop@@2.4.0 geiser@@0.4 notmuch@@0.18 mu@@0.9.9.5 cflow@@1.4 idutils@@4.6 @dots{}
-@end example
-Der oben stehende Befehl gibt einen Satz von Paketen aus, die Sie erstellen
-wollen könnten, um die Kompatibilität einer Aktualisierung des
-@code{flex}-Pakets beurteilen zu können.
-@table @code
-@item --list-transitive
-Die Pakete auflisten, von denen eines oder mehrere Pakete abhängen.
-@example
-$ guix refresh --list-transitive flex
-flex@@2.6.4 depends on the following 25 packages: perl@@5.28.0 help2man@@1.47.6
-bison@@3.0.5 indent@@2.2.10 tar@@1.30 gzip@@1.9 bzip2@@1.0.6 xz@@5.2.4 file@@5.33 @dots{}
-@end example
-@end table
-Der oben stehende Befehl gibt einen Satz von Paketen aus, die, wenn sie
-geändert würden, eine Neuerstellung des @code{flex}-Pakets auslösen würden.
-Mit den folgenden Befehlszeilenoptionen können Sie das Verhalten von GnuPG
-anpassen:
-@table @code
-@item --gpg=@var{Befehl}
-Den @var{Befehl} als GnuPG-2.x-Befehl einsetzen. Der @var{Befehl} wird im
-@code{$PATH} gesucht.
-@item --keyring=@var{Datei}
-Die @var{Datei} als Schlüsselbund mit Anbieterschlüsseln verwenden. Die
-@var{Datei} muss im @dfn{Keybox-Format} vorliegen. Keybox-Dateien haben
-normalerweise einen Namen, der auf @file{.kbx} endet. Sie können mit Hilfe
-von GNU@tie{}Privacy Guard (GPG) bearbeitet werden (siehe @ref{kbxutil,
-@command{kbxutil},, gnupg, Using the GNU Privacy Guard} für Informationen
-über ein Werkzeug zum Bearbeiten von Keybox-Dateien).
-Wenn diese Befehlszeilenoption nicht angegeben wird, benutzt @command{guix
-refresh} die Keybox-Datei @file{~/.config/guix/upstream/trustedkeys.kbx} als
-Schlüsselbund für Signierschlüssel von Anbietern. OpenPGP-Signaturen werden
-mit Schlüsseln aus diesem Schlüsselbund überprüft; fehlende Schlüssel werden
-auch in diesen Schlüsselbund heruntergeladen (siehe @option{--key-download}
-unten).
-Sie können Schlüssel aus Ihrem normalerweise benutzten GPG-Schlüsselbund in
-eine Keybox-Datei exportieren, indem Sie Befehle wie diesen benutzen:
-@example
-gpg --export rms@@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx
-@end example
-Ebenso können Sie wie folgt Schlüssel in eine bestimmte Keybox-Datei
-herunterladen:
-@example
-gpg --no-default-keyring --keyring mykeyring.kbx \
-  --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
-@end example
-Siehe @ref{GPG Configuration Options, @option{--keyring},, gnupg, Using the
-GNU Privacy Guard} für mehr Informationen zur Befehlszeilenoption
-@option{--keyring} von GPG.
-@item --key-download=@var{Richtlinie}
-Fehlende OpenPGP-Schlüssel gemäß dieser @var{Richtlinie} behandeln, für die
-eine der Folgenden angegeben werden kann:
-@table @code
-@item always
-Immer fehlende OpenPGP-Schlüssel herunterladen und zum GnuPG-Schlüsselbund
-des Nutzers hinzufügen.
-@item never
-Niemals fehlende OpenPGP-Schlüssel herunterladen, sondern einfach abbrechen.
-@item interactive
-Ist ein Paket mit einem unbekannten OpenPGP-Schlüssel signiert, wird der
-Nutzer gefragt, ob der Schlüssel heruntergeladen werden soll oder
-nicht. Dies entspricht dem vorgegebenen Verhalten.
-@end table
-@item --key-server=@var{Host}
-Den mit @var{Host} bezeichneten Rechner als Schlüsselserver für OpenPGP
-benutzen, wenn ein öffentlicher Schlüssel importiert wird.
-@end table
-Das @code{github}-Aktualisierungsprogramm benutzt die
-@uref{https://developer.github.com/v3/, GitHub-Programmierschnittstelle}
-(die »Github-API«), um Informationen über neue Veröffentlichungen
-einzuholen. Geschieht dies oft, z.B.@: beim Auffrischen aller Pakete, so
-wird GitHub irgendwann aufhören, weitere API-Anfragen zu
-beantworten. Normalerweise sind 60 API-Anfragen pro Stunde erlaubt, für eine
-vollständige Auffrischung aller GitHub-Pakete in Guix werden aber mehr
-benötigt. Wenn Sie sich bei GitHub mit Ihrem eigenen API-Token
-authentisieren, gelten weniger einschränkende Grenzwerte. Um einen API-Token
-zu benutzen, setzen Sie die Umgebungsvariable @code{GUIX_GITHUB_TOKEN} auf
-einen von @uref{https://github.com/settings/tokens} oder anderweitig
-bezogenen API-Token.
-@node Aufruf von guix lint
-@section @command{guix lint} aufrufen
-@cindex @command{guix lint}
-@cindex Pakete, auf Fehler prüfen
-Den Befehl @command{guix lint} gibt es, um Paketentwicklern beim Vermeiden
-häufiger Fehler und bei der Einhaltung eines konsistenten Code-Stils zu
-helfen. Er führt eine Reihe von Prüfungen auf einer angegebenen Menge von
-Paketen durch, um in deren Definition häufige Fehler aufzuspüren. Zu den
-verfügbaren @dfn{Prüfern} gehören (siehe @code{--list-checkers} für eine
-vollständige Liste):
-@table @code
-@item synopsis
-@itemx description
-Überprüfen, ob bestimmte typografische und stilistische Regeln in
-Paketbeschreibungen und -zusammenfassungen eingehalten wurden.
-@item inputs-should-be-native
-Eingaben identifizieren, die wahrscheinlich native Eingaben sein sollten.
-@item source
-@itemx home-page
-@itemx mirror-url
-@itemx github-url
-@itemx source-file-name
-Die URLs für die Felder @code{home-page} und @code{source} anrufen und nicht
-erreichbare URLs melden. Wenn passend, wird eine @code{mirror://}-URL
-vorgeschlagen. Wenn die Quell-URL auf eine GitHub-URL weiterleitet, wird
-eine Empfehlung ausgegeben, direkt letztere zu verwenden. Es wird geprüft,
-dass der Quell-Dateiname aussagekräftig ist, dass er also z.B.@: nicht nur
-aus einer Versionsnummer besteht oder als »git-checkout« angegeben wurde,
-ohne dass ein @code{Dateiname} deklariert wurde (siehe @ref{»origin«-Referenz}).
-@item source-unstable-tarball
-Parse the @code{source} URL to determine if a tarball from GitHub is
-autogenerated or if it is a release tarball.  Unfortunately GitHub's
-autogenerated tarballs are sometimes regenerated.
-@item cve
-@cindex Sicherheitslücken
-@cindex CVE, Common Vulnerabilities and Exposures
-Bekannte Sicherheitslücken melden, die in den Datenbanken der »Common
-Vulnerabilities and Exposures« (CVE) aus diesem und dem letzten Jahr
-vorkommen, @uref{https://nvd.nist.gov/download.cfm#CVE_FEED, wie sie von der
-US-amerikanischen NIST veröffentlicht werden}.
-Um Informationen über eine bestimmte Sicherheitslücke angezeigt zu bekommen,
-besuchen Sie Webseiten wie:
-@itemize
-@item
-@indicateurl{https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD}
-@item
-@indicateurl{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD}
-@end itemize
-@noindent
-wobei Sie statt @code{CVE-YYYY-ABCD} die CVE-Kennnummer angeben — z.B.@:
-@code{CVE-2015-7554}.
-Paketentwickler können in ihren Paketrezepten den Namen und die Version des
-Pakets in der @uref{https://nvd.nist.gov/cpe.cfm,Common Platform Enumeration
-(CPE)} angeben, falls sich diese von dem in Guix benutzten Namen und der
-Version unterscheiden, zum Beispiel so:
-@example
-(package
-  (name "grub")
-  ;; @dots{}
-  ;; CPE bezeichnet das Paket als "grub2".
-  (properties '((cpe-name . "grub2")
-                (cpe-version . "2.3")))
-@end example
-@c See <http://www.openwall.com/lists/oss-security/2017/03/15/3>.
-Manche Einträge in der CVE-Datenbank geben die Version des Pakets nicht an,
-auf das sie sich beziehen, und würden daher bis in alle Ewigkeit Warnungen
-auslösen. Paketentwickler, die CVE-Warnmeldungen gefunden und geprüft haben,
-dass diese ignoriert werden können, können sie wie in diesem Beispiel
-deklarieren:
-@example
-(package
-  (name "t1lib")
-  ;; @dots{}
-  ;; Diese CVEs treffen nicht mehr zu und können bedenkenlos ignoriert
-  ;; werden.
-  (properties `((lint-hidden-cve . ("CVE-2011-0433"
-                                    "CVE-2011-1553"
-                                    "CVE-2011-1554"
-                                    "CVE-2011-5244")))))
-@end example
-@item Formatierung
-Offensichtliche Fehler bei der Formatierung von Quellcode melden, z.B.@:
-Leerraum-Zeichen am Zeilenende oder Nutzung von Tabulatorzeichen.
-@end table
-Die allgemeine Syntax lautet:
-@example
-guix lint @var{Optionen} @var{Pakete}@dots{}
-@end example
-Wird kein Paket auf der Befehlszeile angegeben, dann werden alle Pakete
-geprüft, die es gibt. Als @var{Optionen} können null oder mehr der folgenden
-Befehlszeilenoptionen übergeben werden:
-@table @code
-@item --list-checkers
-@itemx -l
-Alle verfügbaren Prüfer für die Pakete auflisten und beschreiben.
-@item --checkers
-@itemx -c
-Nur die Prüfer aktivieren, die hiernach in einer kommagetrennten Liste aus
-von @code{--list-checkers} aufgeführten Prüfern vorkommen.
-@end table
-@node Aufruf von guix size
-@section @command{guix size} aufrufen
-@cindex Größe
-@cindex Paketgröße
-@cindex Abschluss
-@cindex @command{guix size}
-Der Befehl @command{guix size} hilft Paketentwicklern dabei, den
-Plattenplatzverbrauch von Paketen zu profilieren. Es ist leicht, die
-Auswirkungen zu unterschätzen, die das Hinzufügen zusätzlicher
-Abhängigkeiten zu einem Paket hat oder die das Verwenden einer einzelnen
-Ausgabe für ein leicht aufteilbares Paket ausmacht (siehe @ref{Pakete mit mehreren Ausgaben.}). Das sind typische Probleme, auf die @command{guix size}
-aufmerksam machen kann.
-Dem Befehl können eine oder mehrere Paketspezifikationen wie @code{gcc@@4.8}
-oder @code{guile:debug} übergeben werden, oder ein Dateiname im
-Store. Betrachten Sie dieses Beispiel:
-@example
-$ guix size coreutils
-Store-Objekt                            Gesamt   Selbst
-/gnu/store/@dots{}-gcc-5.5.0-lib           60.4    30.1  38.1%
-/gnu/store/@dots{}-glibc-2.27              30.3    28.8  36.6%
-/gnu/store/@dots{}-coreutils-8.28          78.9    15.0  19.0%
-/gnu/store/@dots{}-gmp-6.1.2               63.1     2.7   3.4%
-/gnu/store/@dots{}-bash-static-4.4.12       1.5     1.5   1.9%
-/gnu/store/@dots{}-acl-2.2.52              61.1     0.4   0.5%
-/gnu/store/@dots{}-attr-2.4.47             60.6     0.2   0.3%
-/gnu/store/@dots{}-libcap-2.25             60.5     0.2   0.2%
-Gesamt: 78.9 MiB
-@end example
-@cindex Abschluss
-Die hier aufgelisteten Store-Objekte bilden den @dfn{transitiven Abschluss}
-der Coreutils — d.h.@: die Coreutils und all ihre Abhängigkeiten und deren
-Abhängigkeiten, rekursiv —, wie sie hiervon angezeigt würden:<f
-@example
-$ guix gc -R /gnu/store/@dots{}-coreutils-8.23
-@end example
-Hier zeigt die Ausgabe neben den Store-Objekten noch drei Spalten. Die erste
-Spalte namens »Gesamt« gibt wieder, wieviele Mebibytes (MiB) der Abschluss
-des Store-Objekts groß ist — das heißt, dessen eigene Größe plus die Größe
-all seiner Abhängigkeiten. Die nächste Spalte, bezeichnet mit »Selbst«,
-zeigt die Größe nur dieses Objekts an. Die letzte Spalte zeigt das
-Verhältnis der Größe des Objekts zur Gesamtgröße aller hier aufgelisteten
-Objekte an.
-In diesem Beispiel sehen wir, dass der Abschluss der Coreutils 79@tie{}MiB
-schwer ist, wovon das meiste durch libc und die Bibliotheken zur
-Laufzeitunterstützung von GCC ausgemacht wird. (Dass libc und die
-Bibliotheken vom GCC einen großen Anteil am Abschluss ausmachen, ist aber an
-sich noch kein Problem, weil es Bibliotheken sind, die auf dem System
-sowieso immer verfügbar sein müssen.)
-Wenn das oder die Paket(e), die an @command{guix size} übergeben wurden, im
-Store verfügbar sind@footnote{Genauer gesagt braucht @command{guix size} die
-@emph{nicht veredelte} Variante des angegebenen Pakets bzw. der Pakete, wie
-@code{guix build @var{Paket} --no-grafts} sie liefert. Siehe @ref{Sicherheitsaktualisierungen} für Informationen über Veredelungen.}, beauftragen Sie mit
-@command{guix size} den Daemon, die Abhängigkeiten davon zu bestimmen und
-deren Größe im Store zu messen, ähnlich wie es mit @command{du -ms
--apparent-size} geschehen würde (siehe @ref{du invocation,,, coreutils, GNU
-Coreutils}).
-Wenn die übergebenen Pakete @emph{nicht} im Store liegen, erstattet
-@command{guix size} Bericht mit Informationen, die aus verfügbaren
-Substituten herausgelesen werden (siehe @ref{Substitute}). Dadurch kann die
-Plattenausnutzung von Store-Objekten profiliert werden, die gar nicht auf
-der Platte liegen und nur auf entfernten Rechnern vorhanden sind.
-Sie können auch mehrere Paketnamen angeben:
-@example
-$ guix size coreutils grep sed bash
-Store-Objekt                            Gesamt   Selbst
-/gnu/store/@dots{}-coreutils-8.24          77.8    13.8  13.4%
-/gnu/store/@dots{}-grep-2.22               73.1     0.8   0.8%
-/gnu/store/@dots{}-bash-4.3.42             72.3     4.7   4.6%
-/gnu/store/@dots{}-readline-6.3            67.6     1.2   1.2%
-@dots{}
-Gesamt: 102.3 MiB
-@end example
-@noindent
-In diesem Beispiel sehen wir, dass die Kombination der vier Pakete insgesamt
-102,3@tie{}MiB Platz verbraucht, was wesentlich weniger als die Summe der
-einzelnen Abschlüsse ist, weil diese viele Abhängigkeiten gemeinsam
-verwenden.
-Die verfügbaren Befehlszeilenoptionen sind:
-@table @option
-@item --substitute-urls=@var{URLs}
-Substitutinformationen von den @var{URLs} benutzen. Siehe
-@ref{client-substitute-urls, dieselbe Option bei @code{guix build}}.
-@item --sort=@var{Schlüssel}
-Zeilen anhand des @var{Schlüssel}s sortieren, der eine der folgenden
-Alternativen sein muss:
-@table @code
-@item self
-die Größe jedes Objekts (die Vorgabe),
-@item Abschluss
-die Gesamtgröße des Abschlusses des Objekts.
-@end table
-@item --map-file=@var{Datei}
-Eine grafische Darstellung des Plattenplatzverbrauchs als eine
-PNG-formatierte Karte in die @var{Datei} schreiben.
-Für das Beispiel oben sieht die Karte so aus:
-@image{images/coreutils-size-map,5in,, Karte der Plattenausnutzung der
-Coreutils, erzeugt mit @command{guix size}}
-Diese Befehlszeilenoption setzt voraus, dass
-@uref{http://wingolog.org/software/guile-charting/, Guile-Charting}
-installiert und im Suchpfad für Guile-Module sichtbar ist. Falls nicht,
-schlägt @command{guix size} beim Versuch fehl, dieses Modul zu laden.
-@item --system=@var{System}
-@itemx -s @var{System}
-Pakete für dieses @var{System} betrachten — z.B.@: für @code{x86_64-linux}.
-@end table
-@node Aufruf von guix graph
-@section @command{guix graph} aufrufen
-@cindex DAG
-@cindex @command{guix graph}
-@cindex Paketabhängigkeiten
-Pakete und ihre Abhängigkeiten bilden einen @dfn{Graphen}, genauer gesagt
-einen gerichteten azyklischen Graphen (englisch »Directed Acyclic Graph«,
-kurz DAG). Es kann schnell schwierig werden, ein Modell eines Paket-DAGs vor
-dem geistigen Auge zu behalten, weshalb der Befehl @command{guix graph} eine
-visuelle Darstellung des DAGs bietet. Das vorgegebene Verhalten von
-@command{guix graph} ist, eine DAG-Darstellung im Eingabeformat von
-@uref{http://www.graphviz.org/, Graphviz} auszugeben, damit die Ausgabe
-direkt an den Befehl @command{dot} aus Graphviz weitergeleitet werden
-kann. Es kann aber auch eine HTML-Seite mit eingebettetem JavaScript-Code
-ausgegeben werden, um ein »Sehnendiagramm« (englisch »Chord Diagram«) in
-einem Web-Browser anzuzeigen, mit Hilfe der Bibliothek
-@uref{https://d3js.org/, d3.js}, oder es können Cypher-Anfragen ausgegeben
-werden, mit denen eine die Anfragesprache @uref{http://www.opencypher.org/,
-openCypher} unterstützende Graph-Datenbank einen Graphen konstruieren
-kann. Die allgemeine Syntax ist:
-@example
-guix graph @var{Optionen} @var{Pakete}@dots{}
-@end example
-Zum Beispiel erzeugt der folgende Befehl eine PDF-Datei, die den Paket-DAG
-für die GNU@tie{}Core Utilities darstellt, welcher ihre Abhängigkeiten zur
-Erstellungszeit anzeigt:
-@example
-guix graph coreutils | dot -Tpdf > dag.pdf
-@end example
-Die Ausgabe sieht so aus:
-@image{images/coreutils-graph,2in,,Abhängigkeitsgraph der GNU Coreutils}
-Ein netter, kleiner Graph, oder?
-Aber es gibt mehr als eine Art von Graph! Der Graph oben ist kurz und knapp:
-Es ist der Graph der Paketobjekte, ohne implizite Eingaben wie GCC, libc,
-grep und so weiter. Oft möchte man einen knappen Graphen sehen, aber
-manchmal will man auch mehr Details sehen. @command{guix graph} unterstützt
-mehrere Typen von Graphen; Sie können den Detailgrad auswählen.
-@table @code
-@item package
-Der vorgegebene Typ aus dem Beispiel oben. Er zeigt den DAG der Paketobjekte
-ohne implizite Abhängigkeiten. Er ist knapp, filtert aber viele Details
-heraus.
-@item reverse-package
-Dies zeigt den @emph{umgekehrten} DAG der Pakete. Zum Beispiel:
-@example
-guix graph --type=reverse-package ocaml
-@end example
-...@: yields the graph of packages that @emph{explicitly} depend on OCaml
-(if you are also interested in cases where OCaml is an implicit dependency,
-see @code{reverse-bag} below.)
-Beachten Sie, dass für Kernpakete damit gigantische Graphen entstehen
-können. Wenn Sie nur die Anzahl der Pakete wissen wollen, die von einem
-gegebenen Paket abhängen, benutzen Sie @command{guix refresh
--list-dependent} (siehe @ref{Aufruf von guix refresh,
-@option{--list-dependent}}).
-@item bag-emerged
-Dies ist der Paket-DAG @emph{einschließlich} impliziter Eingaben.
-Zum Beispiel liefert der folgende Befehl:
-@example
-guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf
-@end example
-…@: diesen größeren Graphen:
-@image{images/coreutils-bag-graph,,5in,Detaillierter Abhängigkeitsgraph der
-GNU Coreutils}
-Am unteren Rand des Graphen sehen wir alle impliziten Eingaben des
-@var{gnu-build-system} (siehe @ref{Erstellungssysteme, @code{gnu-build-system}}).
-Beachten Sie dabei aber, dass auch hier die Abhängigkeiten dieser impliziten
-Eingaben — d.h.@: die @dfn{Bootstrap-Abhängigkeiten} (siehe
-@ref{Bootstrapping}) — nicht gezeigt werden, damit der Graph knapper bleibt.
-@item bag
-Ähnlich wie @code{bag-emerged}, aber diesmal mit allen
-Bootstrap-Abhängigkeiten.
-@item bag-with-origins
-Ähnlich wie @code{bag}, aber auch mit den Ursprüngen und deren
-Abhängigkeiten.
-@item reverse-bag
-This shows the @emph{reverse} DAG of packages.  Unlike
-@code{reverse-package}, it also takes implicit dependencies into account.
-For example:
-@example
-guix graph -t reverse-bag dune
-@end example
-@noindent
-...@: yields the graph of all packages that depend on Dune, directly or
-indirectly.  Since Dune is an @emph{implicit} dependency of many packages
-@i{via} @code{dune-build-system}, this shows a large number of packages,
-whereas @code{reverse-package} would show very few if any.
-@item Ableitung
-Diese Darstellung ist am detailliertesten: Sie zeigt den DAG der Ableitungen
-(siehe @ref{Ableitungen}) und der einfachen Store-Objekte. Verglichen mit
-obiger Darstellung sieht man viele zusätzliche Knoten einschließlich
-Erstellungs-Skripts, Patches, Guile-Module usw.
-Für diesen Typ Graph kann auch der Name einer @file{.drv}-Datei anstelle
-eines Paketnamens angegeben werden, etwa so:
-@example
-guix graph -t derivation `guix system build -d my-config.scm`
-@end example
-@item module
-Dies ist der Graph der @dfn{Paketmodule} (siehe @ref{Paketmodule}). Zum
-Beispiel zeigt der folgende Befehl den Graph für das Paketmodul an, das das
-@code{guile}-Paket definiert:
-@example
-guix graph -t module guile | dot -Tpdf > modul-graph.pdf
-@end example
-@end table
-Alle oben genannten Typen entsprechen @emph{Abhängigkeiten zur
-Erstellungszeit}. Der folgende Graphtyp repräsentiert die
-@emph{Abhängigkeiten zur Laufzeit}:
-@table @code
-@item references
-Dies ist der Graph der @dfn{Referenzen} einer Paketausgabe, wie
-@command{guix gc --references} sie liefert (siehe @ref{Aufruf von guix gc}).
-Wenn die angegebene Paketausgabe im Store nicht verfügbar ist, versucht
-@command{guix graph}, die Abhängigkeitsinformationen aus Substituten zu
-holen.
-Hierbei können Sie auch einen Store-Dateinamen statt eines Paketnamens
-angeben. Zum Beispiel generiert der Befehl unten den Referenzgraphen Ihres
-Profils (der sehr groß werden kann!):
-@example
-guix graph -t references `readlink -f ~/.guix-profile`
-@end example
-@item referrers
-Dies ist der Graph der ein Store-Objekt @dfn{referenzierenden} Objekte, wie
-@command{guix gc --referrers} sie liefern würde (siehe @ref{Aufruf von guix gc}).
-Er basiert ausschließlich auf lokalen Informationen aus Ihrem Store. Nehmen
-wir zum Beispiel an, dass das aktuelle Inkscape in 10 Profilen verfügbar
-ist, dann wird @command{guix graph -t referrers inkscape} einen Graph
-zeigen, der bei Inkscape gewurzelt ist und Kanten zu diesen 10 Profilen hat.
-Ein solcher Graph kann dabei helfen, herauszufinden, weshalb ein
-Store-Objekt nicht vom Müllsammler abgeholt werden kann.
-@end table
-Folgendes sind die verfügbaren Befehlszeilenoptionen:
-@table @option
-@item --type=@var{Typ}
-@itemx -t @var{Typ}
-Eine Graph-Ausgabe dieses @var{Typ}s generieren. Dieser @var{Typ} muss einer
-der oben genannten Werte sein.
-@item --list-types
-Die unterstützten Graph-Typen auflisten.
-@item --backend=@var{Backend}
-@itemx -b @var{Backend}
-Einen Graph mit Hilfe des ausgewählten @var{Backend}s generieren.
-@item --list-backends
-Die unterstützten Graph-Backends auflisten.
-Derzeit sind die verfügbaren Backends Graphviz und d3.js.
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird.
-Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in
-diesem Beispiel:
-@example
-guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)'
-@end example
-@item --system=@var{System}
-@itemx -s @var{System}
-Den Graphen für das @var{System} anzeigen — z.B.@: @code{i686-linux}.
-Der Abhängigkeitsgraph ist größtenteils von der Systemarchitektur
-unabhängig, aber ein paar architekturabhängige Teile können Ihnen mit dieser
-Befehlszeilenoption visualisiert werden.
-@end table
-@node Aufruf von guix publish
-@section @command{guix publish} aufrufen
-@cindex @command{guix publish}
-Der Zweck von @command{guix publish} ist, es Nutzern zu ermöglichen, ihren
-Store auf einfache Weise mit anderen zu teilen, die ihn dann als
-Substitutserver einsetzen können (siehe @ref{Substitute}).
-Wenn @command{guix publish} ausgeführt wird, wird dadurch ein HTTP-Server
-gestartet, so dass jeder mit Netzwerkzugang davon Substitute beziehen
-kann. Das bedeutet, dass jede Maschine, auf der Guix läuft, auch als
-Build-Farm fungieren kann, weil die HTTP-Schnittstelle mit Hydra, der
-Software, mit der die offizielle Build-Farm @code{@value{SUBSTITUTE-SERVER}}
-betrieben wird, kompatibel ist.
-Um Sicherheit zu gewährleisten, wird jedes Substitut signiert, so dass
-Empfänger dessen Authentizität und Integrität nachprüfen können (siehe
-@ref{Substitute}). Weil @command{guix publish} den Signierschlüssel des
-Systems benutzt, der nur vom Systemadministrator gelesen werden kann, muss
-es als der Administratornutzer »root« gestartet werden. Mit der
-Befehlszeilenoption @code{--user} werden Administratorrechte bald nach dem
-Start wieder abgelegt.
-Das Schlüsselpaar zum Signieren muss erzeugt werden, bevor @command{guix
-publish} gestartet wird. Dazu können Sie @command{guix archive
--generate-key} ausführen (siehe @ref{Aufruf von guix archive}).
-Die allgemeine Syntax lautet:
-@example
-guix publish @var{Optionen}@dots{}
-@end example
-Wird @command{guix publish} ohne weitere Argumente ausgeführt, wird damit
-ein HTTP-Server gestartet, der auf Port 8080 lauscht:
-@example
-guix publish
-@end example
-Sobald ein Server zum Veröffentlichen autorisiert wurde (siehe @ref{Aufruf von guix archive}), kann der Daemon davon Substitute herunterladen:
-@example
-guix-daemon --substitute-urls=http://example.org:8080
-@end example
-Nach den Voreinstellungen komprimiert @command{guix publish} Archive erst
-dann, wenn sie angefragt werden. Dieser »dynamische« Modus bietet sich an,
-weil so nichts weiter eingerichtet werden muss und er direkt verfügbar
-ist. Wenn Sie allerdings viele Clients bedienen wollen, empfehlen wir, dass
-Sie die Befehlszeilenoption @option{--cache} benutzen, die das
-Zwischenspeichern der komprimierten Archive aktiviert, bevor diese an die
-Clients geschickt werden — siehe unten für Details. Mit dem Befehl
-@command{guix weather} haben Sie eine praktische Methode zur Hand, zu
-überprüfen, was so ein Server anbietet (siehe @ref{Aufruf von guix weather}).
-Als Bonus dient @command{guix publish} auch als inhaltsadressierbarer
-Spiegelserver für Quelldateien, die in @code{origin}-Verbundsobjekten
-eingetragen sind (siehe @ref{»origin«-Referenz}). Wenn wir zum Beispiel
-annehmen, dass @command{guix publish} auf @code{example.org} läuft, liefert
-folgende URL die rohe @file{hello-2.10.tar.gz}-Datei mit dem angegebenen
-SHA256-Hash als ihre Prüfsumme (dargestellt im @code{nix-base32}-Format,
-siehe @ref{Aufruf von guix hash}):
-@example
-http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1@dots{}ndq1i
-@end example
-Offensichtlich funktionieren diese URLs nur mit solchen Dateien, die auch im
-Store vorliegen; in anderen Fällen werden sie 404 (»Nicht gefunden«)
-zurückliefern.
-@cindex Erstellungsprotokolle, Veröffentlichen
-Erstellungsprotokolle sind unter @code{/log}-URLs abrufbar:
-@example
-http://example.org/log/gwspk@dots{}-guile-2.2.3
-@end example
-@noindent
-Ist der @command{guix-daemon} so eingestellt, dass er Erstellungsprotokolle
-komprimiert abspeichert, wie es voreingestellt ist (siehe @ref{Aufruf des guix-daemon}), liefern @code{/log}-URLs das unveränderte komprimierte
-Protokoll, mit einer entsprechenden @code{Content-Type}- und/oder
-@code{Content-Encoding}-Kopfzeile. Wir empfehlen dabei, dass Sie den
-@command{guix-daemon} mit @code{--log-compression=gzip} ausführen, weil
-Web-Browser dieses Format automatisch dekomprimieren können, was bei
-bzip2-Kompression nicht der Fall ist.
-Folgende Befehlszeilenoptionen stehen zur Verfügung:
-@table @code
-@item --port=@var{Port}
-@itemx -p @var{Port}
-Auf HTTP-Anfragen auf diesem @var{Port} lauschen.
-@item --listen=@var{Host}
-Auf der Netzwerkschnittstelle für den angegebenen @var{Host}, also der
-angegebenen Rechneradresse, lauschen. Vorgegeben ist, Verbindungen mit jeder
-Schnittstelle zu akzeptieren.
-@item --user=@var{Benutzer}
-@itemx -u @var{Benutzer}
-So früh wie möglich alle über die Berechtigungen des @var{Benutzer}s
-hinausgehenden Berechtigungen ablegen — d.h.@: sobald der Server-Socket
-geöffnet und der Signierschlüssel gelesen wurde.
-@item --compression[=@var{Stufe}]
-@itemx -C [@var{Stufe}]
-Daten auf der angegebenen Kompressions-@var{Stufe} komprimieren. Wird als
-@var{Stufe} null angegeben, wird Kompression deaktiviert. Der Bereich von 1
-bis 9 entspricht unterschiedlichen gzip-Kompressionsstufen: 1 ist am
-schnellsten, während 9 am besten komprimiert (aber den Prozessor mehr
-auslastet). Der Vorgabewert ist 3.
-Wenn @option{--cache} nicht übergeben wird, werden Daten dynamisch immer
-erst dann komprimiert, wenn sie abgeschickt werden; komprimierte Datenströme
-landen in keinem Zwischenspeicher. Um also die Auslastung der Maschine, auf
-der @command{guix publish} läuft, zu reduzieren, kann es eine gute Idee
-sein, eine niedrige Kompressionsstufe zu wählen, @command{guix publish}
-einen Proxy mit Zwischenspeicher (einen »Caching Proxy«) voranzuschalten,
-oder @option{--cache} zu benutzen. @option{--cache} zu benutzen, hat den
-Vorteil, dass @command{guix publish} damit eine
-@code{Content-Length}-HTTP-Kopfzeile seinen Antworten beifügen kann.
-@item --cache=@var{Verzeichnis}
-@itemx -c @var{Verzeichnis}
-Archive und Metadaten (@code{.narinfo}-URLs) in das @var{Verzeichnis}
-zwischenspeichern und nur solche Archive versenden, die im Zwischenspeicher
-vorliegen.
-Wird diese Befehlszeilenoption weggelassen, dann werden Archive und
-Metadaten »dynamisch« erst auf eine Anfrage hin erzeugt. Dadurch kann die
-verfügbare Bandbreite reduziert werden, besonders wenn Kompression aktiviert
-ist, weil die Operation dann durch die Prozessorleistung beschränkt sein
-kann. Noch ein Nachteil des voreingestellten Modus ist, dass die Länge der
-Archive nicht im Voraus bekannt ist, @command{guix publish} also keine
-@code{Content-Length}-HTTP-Kopfzeile an seine Antworten anfügt, wodurch
-Clients nicht wissen können, welche Datenmenge noch heruntergeladen werden
-muss.
-Im Gegensatz dazu liefert, wenn @option{--cache} benutzt wird, die erste
-Anfrage nach einem Store-Objekt (über dessen @code{.narinfo}-URL) den
-Fehlercode 404, und im Hintergrund wird ein Prozess gestartet, der das
-Archiv in den Zwischenspeicher einlagert (auf Englisch sagen wir »@dfn{bake}
-the archive«), d.h.@: seine @code{.narinfo} wird berechnet und das Archiv,
-falls nötig, komprimiert. Sobald das Archiv im @var{Verzeichnis}
-zwischengespeichert wurde, werden nachfolgende Anfragen erfolgreich sein und
-direkt aus dem Zwischenspeicher bedient, der garantiert, dass Clients
-optimale Bandbreite genießen.
-Der Prozess zum Einlagern wird durch Worker-Threads umgesetzt. Der Vorgabe
-entsprechend wird dazu pro Prozessorkern ein Thread erzeugt, aber dieses
-Verhalten kann angepasst werden. Siehe @option{--workers} weiter unten.
-Wird @option{--ttl} verwendet, werden zwischengespeicherte Einträge
-automatisch gelöscht, sobald die dabei angegebene Zeit abgelaufen ist.
-@item --workers=@var{N}
-Wird @option{--cache} benutzt, wird die Reservierung von @var{N}
-Worker-Threads angefragt, um Archive einzulagern.
-@item --ttl=@var{ttl}
-@code{Cache-Control}-HTTP-Kopfzeilen erzeugen, die eine Time-to-live (TTL)
-von @var{ttl} signalisieren. Für @var{ttl} muss eine Dauer (mit dem
-Anfangsbuchstaben der Maßeinheit der Dauer im Englischen) angegeben werden:
-@code{5d} bedeutet 5 Tage, @code{1m} bedeutet 1 Monat und so weiter.
-Das ermöglicht es Guix, Substitutinformationen @var{ttl} lang
-zwischenzuspeichern. Beachten Sie allerdings, dass @code{guix publish}
-selbst @emph{nicht} garantiert, dass die davon angebotenen Store-Objekte so
-lange verfügbar bleiben, wie es die @var{ttl} vorsieht.
-Des Weiteren können bei Nutzung von @option{--cache} die
-zwischengespeicherten Einträge gelöscht werden, wenn auf sie @var{ttl} lang
-nicht zugegriffen wurde und kein ihnen entsprechendes Objekt mehr im Store
-existiert.
-@item --nar-path=@var{Pfad}
-Den @var{Pfad} als Präfix für die URLs von »nar«-Dateien benutzen (siehe
-@ref{Aufruf von guix archive, normalized archives}).
-Vorgegeben ist, dass Nars unter einer URL mit
-@code{/nar/gzip/@dots{}-coreutils-8.25} angeboten werden. Mit dieser
-Befehlszeilenoption können Sie den @code{/nar}-Teil durch den angegebenen
-@var{Pfad} ersetzen.
-@item --public-key=@var{Datei}
-@itemx --private-key=@var{Datei}
-Die angegebenen @var{Datei}en als das Paar aus öffentlichem und privatem
-Schlüssel zum Signieren veröffentlichter Store-Objekte benutzen.
-Die Dateien müssen demselben Schlüsselpaar entsprechen (der private
-Schlüssel wird zum Signieren benutzt, der öffentliche Schlüssel wird
-lediglich in den Metadaten der Signatur aufgeführt). Die Dateien müssen
-Schlüssel im kanonischen (»canonical«) S-Ausdruck-Format enthalten, wie es
-von @command{guix archive --generate-key} erzeugt wird (siehe @ref{Aufruf von guix archive}). Vorgegeben ist, dass @file{/etc/guix/signing-key.pub} und
-@file{/etc/guix/signing-key.sec} benutzt werden.
-@item --repl[=@var{Port}]
-@itemx -r [@var{Port}]
-Einen Guile-REPL-Server (siehe @ref{REPL Servers,,, guile, GNU Guile
-Reference Manual}) auf diesem @var{Port} starten (37146 ist
-voreingestellt). Dies kann zur Fehlersuche auf einem laufenden
-»@command{guix publish}«-Server benutzt werden.
-@end table
-@command{guix publish} auf einem »Guix System«-System zu aktivieren ist ein
-Einzeiler: Instanziieren Sie einfach einen
-@code{guix-publish-service-type}-Dienst im @code{services}-Feld Ihres
-@code{operating-system}-Objekts zur Betriebssystemdeklaration (siehe
-@ref{guix-publish-service-type, @code{guix-publish-service-type}}).
-Falls Sie Guix aber auf einer »Fremddistribution« laufen lassen, folgen Sie
-folgenden Anweisungen:
-@itemize
-@item
-Wenn Ihre Wirtsdistribution systemd als »init«-System benutzt:
-@example
-# ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service \
-        /etc/systemd/system/
-# systemctl start guix-publish && systemctl enable guix-publish
-@end example
-@item
-Wenn Ihre Wirts-Distribution als »init«-System Upstart verwendet:
-@example
-# ln -s ~root/.guix-profile/lib/upstart/system/guix-publish.conf /etc/init/
-# start guix-publish
-@end example
-@item
-Verfahren Sie andernfalls auf die gleiche Art für das »init«-System, das
-Ihre Distribution verwendet.
-@end itemize
-@node Aufruf von guix challenge
-@section @command{guix challenge} aufrufen
-@cindex Reproduzierbare Erstellungen
-@cindex verifizierbare Erstellungen
-@cindex @command{guix challenge}
-@cindex Anfechten
-Entsprechen die von diesem Server gelieferten Binärdateien tatsächlich dem
-Quellcode, aus dem sie angeblich erzeugt wurden? Ist ein
-Paketerstellungsprozess deterministisch? Diese Fragen versucht @command{guix
-challenge} zu beantworten.
-Die erste Frage ist offensichtlich wichtig: Bevor man einen Substitutserver
-benutzt (siehe @ref{Substitute}), @emph{verifiziert} man besser, dass er
-die richtigen Binärdateien liefert, d.h.@: man @emph{fechtet sie an}. Die
-letzte Frage macht die erste möglich: Wenn Paketerstellungen deterministisch
-sind, müssten voneinander unabhängige Erstellungen genau dasselbe Ergebnis
-liefern, Bit für Bit; wenn ein Server mit einer anderen Binärdatei als der
-lokal erstellten Binärdatei antwortet, ist diese entweder beschädigt oder
-bösartig.
-Wir wissen, dass die in @file{/gnu/store}-Dateinamen auftauchende
-Hash-Prüfsumme der Hash aller Eingaben des Prozesses ist, mit dem die Datei
-oder das Verzeichnis erstellt wurde — Compiler, Bibliotheken,
-Erstellungsskripts und so weiter (siehe @ref{Einführung}). Wenn wir von
-deterministischen Erstellungen ausgehen, sollte ein Store-Dateiname also auf
-genau eine Erstellungsausgabe abgebildet werden. Mit @command{guix
-challenge} prüft man, ob es tatsächlich eine eindeutige Abbildung gibt,
-indem die Erstellungsausgaben mehrerer unabhängiger Erstellungen jedes
-angegebenen Store-Objekts verglichen werden.
-Die Ausgabe des Befehls sieht so aus:
-@smallexample
-$ guix challenge --substitute-urls="https://@value{SUBSTITUTE-SERVER} https://guix.example.org"
-Liste der Substitute von »https://@value{SUBSTITUTE-SERVER}« wird aktualisiert … 100.0%
-Liste der Substitute von »https://guix.example.org« wird aktualisiert … 100.0%
-Inhalt von /gnu/store/@dots{}-openssl-1.0.2d verschieden:
-  lokale Prüfsumme: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
-  https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
-  https://guix.example.org/nar/@dots{}-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
-Inhalt von /gnu/store/@dots{}-git-2.5.0 verschieden:
-  lokale Prüfsumme: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
-  https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
-  https://guix.example.org/nar/@dots{}-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
-Inhalt von /gnu/store/@dots{}-pius-2.1.1 verschieden:
-  lokale Prüfsumme: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
-  https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
-  https://guix.example.org/nar/@dots{}-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
-@dots{}
-6,406 Store-Objekte wurden analysiert:
-  — 4,749 (74.1%) waren identisch
-  — 525 (8.2%) unterscheiden sich
-  — 1,132 (17.7%) blieben ergebnislos
-@end smallexample
-@noindent
-In diesem Beispiel wird mit @command{guix challenge} zuerst die Menge lokal
-erstellter Ableitungen im Store ermittelt — im Gegensatz zu von einem
-Substitserver heruntergeladenen Store-Objekten — und dann werden alle
-Substitutserver angefragt. Diejenigen Store-Objekte, bei denen der Server
-ein anderes Ergebnis berechnet hat als die lokale Erstellung, werden
-gemeldet.
-@cindex Nichtdeterminismus, in Paketerstellungen
-Nehmen wir zum Beispiel an, @code{guix.example.org} gibt uns immer eine
-verschiedene Antwort, aber @code{@value{SUBSTITUTE-SERVER}} stimmt mit
-lokalen Erstellungen überein, @emph{außer} im Fall von Git. Das könnte ein
-Hinweis sein, dass der Erstellungsprozess von Git nichtdeterministisch ist;
-das bedeutet, seine Ausgabe variiert abhängig von verschiedenen Umständen,
-die Guix nicht vollends kontrollieren kann, obwohl es Pakete in isolierten
-Umgebungen erstellt (siehe @ref{Funktionalitäten}). Zu den häufigsten Quellen von
-Nichtdeterminismus gehören das Einsetzen von Zeitstempeln innerhalb der
-Erstellungsgebnisse, das Einsetzen von Zufallszahlen und von Auflistungen
-eines Verzeichnisinhalts sortiert nach der Inode-Nummer. Siehe
-@uref{https://reproducible-builds.org/docs/} für mehr Informationen.
-Um herauszufinden, was mit dieser Git-Binärdatei nicht stimmt, können wir so
-etwas machen (siehe @ref{Aufruf von guix archive}):
-@example
-$ wget -q -O - https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0 \
-   | guix archive -x /tmp/git
-$ diff -ur --no-dereference /gnu/store/@dots{}-git.2.5.0 /tmp/git
-@end example
-Dieser Befehl zeigt die Unterschiede zwischen den Dateien, die sich aus der
-lokalen Erstellung ergeben, und den Dateien, die sich aus der Erstellung auf
-@code{@value{SUBSTITUTE-SERVER}} ergeben (siehe @ref{Overview, Comparing and
-Merging Files,, diffutils, Comparing and Merging Files}). Der Befehl
-@command{diff} funktioniert großartig für Textdateien. Wenn sich
-Binärdateien unterscheiden, ist @uref{https://diffoscope.org/, Diffoscope}
-die bessere Wahl: Es ist ein hilfreiches Werkzeug, das Unterschiede in allen
-Arten von Dateien visualisiert.
-Sobald Sie mit dieser Arbeit fertig sind, können Sie erkennen, ob die
-Unterschiede aufgrund eines nichtdeterministischen Erstellungsprozesses oder
-wegen einem bösartigen Server zustande kommen. Wir geben uns Mühe, Quellen
-von Nichtdeterminismus in Paketen zu entfernen, damit Substitute leichter
-verifiziert werden können, aber natürlich ist an diesem Prozess nicht nur
-Guix, sondern ein großer Teil der Freie-Software-Gemeinschaft beteiligt. In
-der Zwischenzeit ist @command{guix challenge} eines der Werkzeuge, die das
-Problem anzugehen helfen.
-Wenn Sie ein Paket für Guix schreiben, ermutigen wir Sie, zu überprüfen, ob
-@code{@value{SUBSTITUTE-SERVER}} und andere Substitutserver dasselbe
-Erstellungsergebnis bekommen, das Sie bekommen haben. Das geht so:
-@example
-$ guix challenge @var{Paket}
-@end example
-@noindent
-Dabei wird mit @var{Paket} eine Paketspezifikation wie @code{guile@@2.0}
-oder @code{glibc:debug} bezeichnet.
-Die allgemeine Syntax lautet:
-@example
-guix challenge @var{Optionen} [@var{Pakete}@dots{}]
-@end example
-Wird ein Unterschied zwischen der Hash-Prüfsumme des lokal erstellten
-Objekts und dem vom Server gelieferten Substitut festgestellt, oder zwischen
-den Substituten von unterschiedlichen Servern, dann wird der Befehl dies wie
-im obigen Beispiel anzeigen und mit dem Exit-Code 2 terminieren (andere
-Exit-Codes außer null stehen für andere Arten von Fehlern).
-Die eine, wichtige Befehlszeilenoption ist:
-@table @code
-@item --substitute-urls=@var{URLs}
-Die @var{URLs} als durch Leerraumzeichen getrennte Liste von
-Substitut-Quell-URLs benutzen. mit denen verglichen wird.
-@item --verbose
-@itemx -v
-Details auch zu Übereinstimmungen (deren Inhalt identisch ist) ausgeben,
-zusätzlich zu Informationen über Unterschiede.
-@end table
-@node Aufruf von guix copy
-@section @command{guix copy} aufrufen
-@cindex Kopieren, von Store-Objekten, über SSH
-@cindex SSH, Kopieren von Store-Objekten
-@cindex Store-Objekte zwischen Maschinen teilen
-@cindex Übertragen von Store-Objekten zwischen Maschinen
-Der Befehl @command{guix copy} kopiert Objekte aus dem Store einer Maschine
-in den Store einer anderen Maschine mittels einer Secure-Shell-Verbindung
-(kurz SSH-Verbindung)@footnote{Dieser Befehl steht nur dann zur Verfügung,
-wenn Guile-SSH gefunden werden kann. Siehe @ref{Voraussetzungen} für
-Details.}. Zum Beispiel kopiert der folgende Befehl das Paket
-@code{coreutils}, das Profil des Benutzers und all deren Abhängigkeiten auf
-den anderen @var{Rechner}, dazu meldet sich Guix als @var{Benutzer} an:
-@example
-guix copy --to=@var{Benutzer}@@@var{Rechner} \
-          coreutils `readlink -f ~/.guix-profile`
-@end example
-Wenn manche der zu kopierenden Objekte schon auf dem anderen @var{Rechner}
-vorliegen, werden sie tatsächlich @emph{nicht} übertragen.
-Der folgende Befehl bezieht @code{libreoffice} und @code{gimp} von dem
-@var{Rechner}, vorausgesetzt sie sind dort verfügbar:
-@example
-guix copy --from=@var{host} libreoffice gimp
-@end example
-Die SSH-Verbindung wird mit dem Guile-SSH-Client hergestellt, der mit
-OpenSSH kompatibel ist: Er berücksichtigt @file{~/.ssh/known_hosts} und
-@file{~/.ssh/config} und verwendet den SSH-Agenten zur Authentifizierung.
-Der Schlüssel, mit dem gesendete Objekte signiert sind, muss von der
-entfernten Maschine akzeptiert werden. Ebenso muss der Schlüssel, mit dem
-die Objekte signiert sind, die Sie von der entfernten Maschine empfangen, in
-Ihrer Datei @file{/etc/guix/acl} eingetragen sein, damit Ihr Daemon sie
-akzeptiert. Siehe @ref{Aufruf von guix archive} für mehr Informationen über
-die Authentifizierung von Store-Objekten.
-Die allgemeine Syntax lautet:
-@example
-guix copy [--to=@var{Spezifikation}|--from=@var{Spezifikation}] @var{Objekte}@dots{}
-@end example
-Sie müssen immer eine der folgenden Befehlszeilenoptionen angeben:
-@table @code
-@item --to=@var{Spezifikation}
-@itemx --from=@var{Spezifikation}
-Gibt den Rechner (den »Host«) an, an den oder von dem gesendet
-bzw. empfangen wird. Die @var{Spezifikation} muss eine SSH-Spezifikation
-sein wie @code{example.org}, @code{charlie@@example.org} oder
-@code{charlie@@example.org:2222}.
-@end table
-Die @var{Objekte} können entweder Paketnamen wie @code{gimp} oder
-Store-Objekte wie @file{/gnu/store/@dots{}-idutils-4.6} sein.
-Wenn ein zu sendendes Paket mit Namen angegeben wird, wird es erst erstellt,
-falls es nicht im Store vorliegt, außer @option{--dry-run} wurde angegeben
-wurde. Alle gemeinsamen Erstellungsoptionen werden unterstützt (siehe
-@ref{Gemeinsame Erstellungsoptionen}).
-@node Aufruf von guix container
-@section @command{guix container} aufrufen
-@cindex container
-@cindex @command{guix container}
-@quotation Anmerkung
-Dieses Werkzeug ist noch experimentell, Stand Version @value{VERSION}. Die
-Schnittstelle wird sich in Zukunft grundlegend verändern.
-@end quotation
-Der Zweck von @command{guix container} ist, in einer isolierten Umgebung
-(gemeinhin als »Container« bezeichnet) laufende Prozesse zu manipulieren,
-die typischerweise durch die Befehle @command{guix environment} (siehe
-@ref{Aufruf von guix environment}) und @command{guix system container} (siehe
-@ref{Aufruf von guix system}) erzeugt werden.
-Die allgemeine Syntax lautet:
-@example
-guix container @var{Aktion} @var{Optionen}@dots{}
-@end example
-Mit @var{Aktion} wird die Operation angegeben, die in der isolierten
-Umgebung durchgeführt werden soll, und mit @var{Optionen} werden die
-kontextabhängigen Argumente an die Aktion angegeben.
-Folgende Aktionen sind verfügbar:
-@table @code
-@item exec
-Führt einen Befehl im Kontext der laufenden isolierten Umgebung aus.
-Die Syntax ist:
-@example
-guix container exec @var{PID} @var{Programm} @var{Argumente}@dots{}
-@end example
-@var{PID} gibt die Prozess-ID der laufenden isolierten Umgebung an. Als
-@var{Programm} muss eine ausführbare Datei im Wurzeldateisystem der
-isolierten Umgebung angegeben werden. Die @var{Argumente} sind die
-zusätzlichen Befehlszeilenoptionen, die an das @var{Programm} übergeben
-werden.
-Der folgende Befehl startet eine interaktive Anmelde-Shell innerhalb einer
-isolierten Guix-Systemumgebung, gestartet durch @command{guix system
-container}, dessen Prozess-ID 9001 ist:
-@example
-guix container exec 9001 /run/current-system/profile/bin/bash --login
-@end example
-Beachten Sie, dass die @var{PID} nicht der Elternprozess der isolierten
-Umgebung sein darf, sondern PID 1 in der isolierten Umgebung oder einer
-seiner Kindprozesse sein muss.
-@end table
-@node Aufruf von guix weather
-@section @command{guix weather} aufrufen
-Manchmal werden Sie schlecht gelaunt sein, weil es zu wenige Substitute gibt
-und die Pakete bei Ihnen selbst erstellt werden müssen (siehe
-@ref{Substitute}). Der Befehl @command{guix weather} zeigt einen Bericht
-über die Verfügbarkeit von Substituten auf den angegebenen Servern an, damit
-Sie sich eine Vorstellung davon machen können, wie es heute um Ihre Laune
-bestellt sein wird. Manchmal bekommt man als Nutzer so hilfreiche
-Informationen, aber in erster Linie nützt der Befehl den Leuten, die
-@command{guix publish} benutzen (siehe @ref{Aufruf von guix publish}).
-@cindex Statistik, für Substitute
-@cindex Verfügbarkeit von Substituten
-@cindex Substitutverfügbarkeit
-@cindex Wetter, Substitutverfügbarkeit
-Hier ist ein Beispiel für einen Aufruf davon:
-@example
-$ guix weather --substitute-urls=https://guix.example.org
-5.872 Paketableitungen für x86_64-linux berechnen …
-Nach 6.128 Store-Objekten von https://guix.example.org suchen …
-updating list of substitutes from 'https://guix.example.org'... 100.0%
-https://guix.example.org
-  43,4% Substitute verfügbar (2.658 von 6.128)
-  7.032,5 MiB an Nars (komprimiert)
-  19.824,2 MiB auf der Platte (unkomprimiert)
-  0,030 Sekunden pro Anfrage (182,9 Sekunden insgesamt)
-  33,5 Anfragen pro Sekunde
-  9,8% (342 von 3.470) der fehlenden Objekte sind in der Warteschlange
-  Mindestens 867 Erstellungen in der Warteschlange
-      x86_64-linux: 518 (59,7%)
-      i686-linux: 221 (25,5%)
-      aarch64-linux: 128 (14,8%)
-  Erstellungsgeschwindigkeit: 23,41 Erstellungen pro Stunde
-      x86_64-linux: 11,16 Erstellungen pro Stunde
-      i686-linux: 6,03 Erstellungen pro Stunde
-      aarch64-linux: 6,41 Erstellungen pro Stunde
-@end example
-@cindex Kontinuierliche Integration, Statistik
-Wie Sie sehen können, wird der Anteil unter allen Paketen angezeigt, für die
-auf dem Server Substitute verfügbar sind — unabhängig davon, ob Substitute
-aktiviert sind, und unabhängig davon, ob der signierende Schlüssel des
-Servers autorisiert ist. Es wird auch über die Größe der komprimierten
-Archive (die »Nars«) berichtet, die vom Server angeboten werden, sowie über
-die Größe, die die zugehörigen Store-Objekte im Store belegen würden (unter
-der Annahme, dass Deduplizierung abgeschaltet ist) und über den Durchsatz
-des Servers. Der zweite Teil sind Statistiken zur Kontinuierlichen
-Integration (englisch »Continuous Integration«, kurz CI), wenn der Server
-dies unterstützt. Des Weiteren kann @command{guix weather}, wenn es mit der
-Befehlszeilenoption @option{--coverage} aufgerufen wird, »wichtige«
-Paketsubstitute, die auf dem Server fehlen, auflisten (siehe unten).
-Dazu werden mit @command{guix weather} Anfragen über HTTP(S) zu Metadaten
-(@dfn{Narinfos}) für alle relevanten Store-Objekte gestellt. Wie
-@command{guix challenge} werden die Signaturen auf den Substituten
-ignoriert, was harmlos ist, weil der Befehl nur Statistiken sammelt und
-keine Substitute installieren kann.
-Neben anderen Dingen ist es möglich, bestimmte Systemtypen und bestimmte
-Paketmengen anzufragen. Die verfügbaren Befehlszeilenoptionen sind folgende:
-@table @code
-@item --substitute-urls=@var{URLs}
-@var{URLs} ist eine leerzeichengetrennte Liste anzufragender
-Substitutserver-URLs. Wird diese Befehlszeilenoption weggelassen, wird die
-vorgegebene Menge an Substitutservern angefragt.
-@item --system=@var{System}
-@itemx -s @var{System}
-Substitute für das @var{System} anfragen — z.B.@: für
-@code{aarch64-linux}. Diese Befehlszeilenoption kann mehrmals angegeben
-werden, wodurch @command{guix weather} die Substitute für mehrere
-Systemtypen anfragt.
-@item --manifest=@var{Datei}
-Anstatt die Substitute für alle Pakete anzufragen, werden nur die in der
-@var{Datei} angegebenen Pakete erfragt. Die @var{Datei} muss ein
-@dfn{Manifest} enthalten, wie bei der Befehlszeilenoption @code{-m} von
-@command{guix package} (siehe @ref{Aufruf von guix package}).
-@item --coverage[=@var{Anzahl}]
-@itemx -c [@var{Anzahl}]
-Einen Bericht über die Substitutabdeckung für Pakete ausgeben, d.h.@: Pakete
-mit mindestens @var{Anzahl}-vielen Abhängigen (voreingestellt mindestens
-null) anzeigen, für die keine Substitute verfügbar sind. Die abhängigen
-Pakete werden selbst nicht aufgeführt: Wenn @var{b} von @var{a} abhängt und
-Substitute für @var{a} fehlen, wird nur @var{a} aufgeführt, obwohl dann in
-der Regel auch die Substitute für @var{b} fehlen. Das Ergebnis sieht so aus:
-@example
-$ guix weather --substitute-urls=https://ci.guix.de.info -c 10
-8.983 Paketableitungen für x86_64-linux berechnen …
-Nach 9.343 Store-Objekten von https://ci.guix.de.info suchen …
-Liste der Substitute von »https://ci.guix.de.info« wird aktualisiert … 100.0%
-https://ci.guix.de.info
-  64.7% Substitute verfügbar (6.047 von 9.343)
-@dots{}
-2502 Pakete fehlen auf »https://ci.guix.de.info« für »x86_64-linux«, darunter sind:
-    58  kcoreaddons@@5.49.0      /gnu/store/@dots{}-kcoreaddons-5.49.0
-    46  qgpgme@@1.11.1           /gnu/store/@dots{}-qgpgme-1.11.1
-    37  perl-http-cookiejar@@0.008  /gnu/store/@dots{}-perl-http-cookiejar-0.008
-    @dots{}
-@end example
-What this example shows is that @code{kcoreaddons} and presumably the 58
-packages that depend on it have no substitutes at @code{ci.guix.de.info};
-likewise for @code{qgpgme} and the 46 packages that depend on it.
-If you are a Guix developer, or if you are taking care of this build farm,
-you'll probably want to have a closer look at these packages: they may
-simply fail to build.
-@end table
-@node Aufruf von guix processes
-@section @command{guix processes} aufrufen
-Der Befehl @command{guix processes} kann sich für Entwickler und
-Systemadministratoren als nützlich erweisen, besonders auf Maschinen mit
-mehreren Nutzern und auf Build-Farms. Damit werden die aktuellen Sitzungen
-(also Verbindungen zum Daemon) sowie Informationen über die beteiligten
-Prozesse aufgelistet@footnote{Entfernte Sitzungen, wenn
-@command{guix-daemon} mit @option{--listen} unter Angabe eines TCP-Endpunkts
-gestartet wurde, werden @emph{nicht} aufgelistet.}. Hier ist ein Beispiel
-für die davon gelieferten Informationen:
-@example
-$ sudo guix processes
-SessionPID: 19002
-ClientPID: 19090
-ClientCommand: guix environment --ad-hoc python
-SessionPID: 19402
-ClientPID: 19367
-ClientCommand: guix publish -u guix-publish -p 3000 -C 9 @dots{}
-SessionPID: 19444
-ClientPID: 19419
-ClientCommand: cuirass --cache-directory /var/cache/cuirass @dots{}
-LockHeld: /gnu/store/@dots{}-perl-ipc-cmd-0.96.lock
-LockHeld: /gnu/store/@dots{}-python-six-bootstrap-1.11.0.lock
-LockHeld: /gnu/store/@dots{}-libjpeg-turbo-2.0.0.lock
-ChildProcess: 20495: guix offload x86_64-linux 7200 1 28800
-ChildProcess: 27733: guix offload x86_64-linux 7200 1 28800
-ChildProcess: 27793: guix offload x86_64-linux 7200 1 28800
-@end example
-In diesem Beispiel sehen wir, dass @command{guix-daemon} drei Clients hat:
-@command{guix environment}, @command{guix publish} und das Werkzeug Cuirass
-zur Kontinuierlichen Integration. Deren Prozesskennung (PID) ist jeweils im
-@code{ClientPID}-Feld zu sehen. Das Feld @code{SessionPID} zeigt die PID des
-@command{guix-daemon}-Unterprozesses dieser bestimmten Sitzung.
-Das Feld @code{LockHeld} zeigt an, welche Store-Objekte derzeit durch die
-Sitzung gesperrt sind, d.h.@: welche Store-Objekte zur Zeit erstellt oder
-substituiert werden (das @code{LockHeld}-Feld wird nicht angezeigt, wenn
-@command{guix processes} nicht als Administratornutzer root ausgeführt
-wird). Letztlich sehen wir am @code{ChildProcess}-Feld oben, dass diese drei
-Erstellungen hier ausgelagert (englisch »offloaded«) werden (siehe
-@ref{Auslagern des Daemons einrichten}).
-Die Ausgabe ist im Recutils-Format, damit wir den praktischen
-@command{recsel}-Befehl benutzen können, um uns interessierende Sitzungen
-auszuwählen (siehe @ref{Selection Expressions,,, recutils, GNU recutils
-manual}). Zum Beispiel zeigt dieser Befehl die Befehlszeile und PID des
-Clients an, der die Erstellung des Perl-Pakets ausgelöst hat:
-@example
-$ sudo guix processes | \
-    recsel -p ClientPID,ClientCommand -e 'LockHeld ~ "perl"'
-ClientPID: 19419
-ClientCommand: cuirass --cache-directory /var/cache/cuirass @dots{}
-@end example
-@node Systemkonfiguration
-@chapter Systemkonfiguration
-@cindex Systemkonfiguration
-Die »Guix System«-Distribution unterstützt einen Mechanismus zur
-konsistenten Konfiguration des gesamten Systems. Damit meinen wir, dass alle
-Aspekte der globalen Systemkonfiguration an einem Ort stehen, d.h.@: die zur
-Verfügung gestellten Systemdienste, die Zeitzone und Einstellungen zur
-Locale (also die Anpassung an regionale Gepflogenheiten und Sprachen) sowie
-Benutzerkonten. Sie alle werden an derselben Stelle deklariert. So eine
-@dfn{Systemkonfiguration} kann @dfn{instanziiert}, also umgesetzt, werden.
-@c Yes, we're talking of Puppet, Chef, & co. here.  ↑
-Einer der Vorteile, die ganze Systemkonfiguration unter die Kontrolle von
-Guix zu stellen, ist, dass so transaktionelle Systemaktualisierungen möglich
-werden und dass diese rückgängig gemacht werden können, wenn das
-aktualisierte System nicht richtig funktioniert (siehe @ref{Funktionalitäten}). Ein
-anderer Vorteil ist, dass dieselbe Systemkonfiguration leicht auf einer
-anderen Maschine oder zu einem späteren Zeitpunkt benutzt werden kann, ohne
-dazu eine weitere Schicht administrativer Werkzeuge über den systemeigenen
-Werkzeugen einsetzen zu müssen.
-In diesem Abschnitt wird dieser Mechanismus beschrieben. Zunächst betrachten
-wir ihn aus der Perspektive eines Administrators. Dabei wird erklärt, wie
-das System konfiguriert und instanziiert werden kann. Dann folgt eine
-Demonstration, wie der Mechanismus erweitert werden kann, etwa um neue
-Systemdienste zu unterstützen.
-@menu
-* Das Konfigurationssystem nutzen::  Ihr GNU-System anpassen.
-* »operating-system«-Referenz::  Details der Betriebssystem-Deklarationen.
-* Dateisysteme::             Die Dateisystemeinbindungen konfigurieren.
-* Zugeordnete Geräte::      Näheres zu blockorientierten Speichermedien.
-* Benutzerkonten::           Benutzerkonten festlegen.
-* Tastaturbelegung::         Wie das System Tastendrücke interpretiert.
-* Locales::                  Sprache und kulturelle Konventionen.
-* Dienste::                  Systemdienste festlegen.
-* Setuid-Programme::         Mit Administratorrechten startende Programme.
-* X.509-Zertifikate::        HTTPS-Server authentifizieren.
-* Name Service Switch::      Den Name Service Switch von libc konfigurieren.
-* Initiale RAM-Disk::        Linux-libre hochfahren.
-* Bootloader-Konfiguration::  Den Bootloader konfigurieren.
-* Aufruf von guix system::   Instanziierung einer Systemkonfiguration.
-* Guix in einer VM starten::  Wie man »Guix System« in einer virtuellen 
-                                Maschine startet.
-* Dienste definieren::       Neue Dienstdefinitionen hinzufügen.
-@end menu
-@node Das Konfigurationssystem nutzen
-@section Das Konfigurationssystem nutzen
-Das Betriebssystem können Sie konfigurieren, indem Sie eine
-@code{operating-system}-Deklaration in einer Datei speichern, die Sie dann
-dem Befehl @command{guix system} übergeben (siehe @ref{Aufruf von guix system}). Eine einfache Konfiguration mit den vorgegebenen Systemdiensten
-und dem vorgegebenen Linux-Libre als Kernel und mit einer initialen RAM-Disk
-und einem Bootloader, sieht so aus:
-@findex operating-system
-@lisp
-@include os-config-bare-bones.texi
-@end lisp
-Dieses Beispiel sollte selbsterklärend sein. Manche der Felder oben, wie
-etwa @code{host-name} und @code{bootloader}, müssen angegeben werden. Andere
-sind optional, wie etwa @code{packages} und @code{services}, sind optional;
-werden sie nicht angegeben, nehmen sie einen Vorgabewert an.
-Im Folgenden werden die Effekte von einigen der wichtigsten Feldern
-erläutert (siehe @ref{»operating-system«-Referenz} für Details zu allen
-verfügbaren Feldern), dann wird beschrieben, wie man das Betriebssystem mit
-@command{guix system} @dfn{instanziieren} kann.
-@unnumberedsubsec Bootloader
-@cindex Legacy-Boot, auf Intel-Maschinen
-@cindex BIOS-Boot, auf Intel-Maschinen
-@cindex UEFI-Boot
-@cindex EFI-Boot
-Das @code{bootloader}-Feld beschreibt, mit welcher Methode Ihr System
-»gebootet« werden soll. Maschinen, die auf Intel-Prozessoren basieren,
-können im alten »Legacy«-BIOS-Modus gebootet werden, wie es im obigen
-Beispiel der Fall wäre. Neuere Maschinen benutzen stattdessen das
-@dfn{Unified Extensible Firmware Interface} (UEFI) zum Booten. In diesem
-Fall sollte das @code{bootloader}-Feld in etwa so aussehen:
-@example
-(bootloader-configuration
-  (bootloader grub-efi-bootloader)
-  (target "/boot/efi"))
-@end example
-Siehe den Abschnitt @ref{Bootloader-Konfiguration} für weitere Informationen
-zu den verfügbaren Konfigurationsoptionen.
-@unnumberedsubsec global sichtbare Pakete
-@vindex %base-packages
-Im Feld @code{packages} werden Pakete aufgeführt, die auf dem System für
-alle Benutzerkonten global sichtbar sein sollen, d.h.@: in der
-@code{PATH}-Umgebungsvariablen jedes Nutzers, zusätzlich zu den
-nutzereigenen Profilen (siehe @ref{Aufruf von guix package}). Die Variable
-@var{%base-packages} bietet alle Werkzeuge, die man für grundlegende Nutzer-
-und Administratortätigkeiten erwarten würde, einschließlich der GNU Core
-Utilities, der GNU Networking Utilities, des leichtgewichtigen Texteditors
-GNU Zile, @command{find}, @command{grep} und so weiter. Obiges Beispiel fügt
-zu diesen noch das Programm GNU@tie{}Screen hinzu, welches aus dem Modul
-@code{(gnu packages screen)} genommen wird (siehe @ref{Paketmodule}). Die Syntax @code{(list package output)} kann benutzt werden, um
-eine bestimmte Ausgabe eines Pakets auszuwählen:
-@lisp
-(use-modules (gnu packages))
-(use-modules (gnu packages dns))
-(operating-system
-  ;; ...
-  (packages (cons (list bind "utils")
-                  %base-packages)))
-@end lisp
-@findex specification->package
-Sich auf Pakete anhand ihres Variablennamens zu beziehen, wie oben bei
-@code{bind}, hat den Vorteil, dass der Name eindeutig ist; Tippfehler werden
-direkt als »unbound variables« gemeldet. Der Nachteil ist, dass man wissen
-muss, in welchem Modul ein Paket definiert wird, um die Zeile mit
-@code{use-package-modules} entsprechend zu ergänzen. Um dies zu vermeiden,
-kann man auch die Prozedur @code{specification->package} aus dem Modul
-@code{(gnu packages)} aufrufen, welche das einem angegebenen Namen oder
-Name-Versions-Paar zu Grunde liegende Paket liefert:
-@lisp
-(use-modules (gnu packages))
-(operating-system
-  ;; ...
-  (packages (append (map specification->package
-                         '("tcpdump" "htop" "gnupg@@2.0"))
-                    %base-packages)))
-@end lisp
-@unnumberedsubsec Systemdienste
-@cindex services
-@vindex %base-services
-Das Feld @code{services} listet @dfn{Systemdienste} auf, die zur Verfügung
-stehen sollen, wenn das System startet (siehe @ref{Dienste}). Die
-@code{operating-system}-Deklaration oben legt fest, dass wir neben den
-grundlegenden Basis-Diensten auch wollen, dass der
-OpenSSH-Secure-Shell-Daemon auf Port 2222 lauscht (siehe @ref{Netzwerkdienste, @code{openssh-service-type}}). Intern sorgt der
-@code{openssh-service-type} dafür, dass @code{sshd} mit den richtigen
-Befehlszeilenoptionen aufgerufen wird, je nach Systemkonfiguration werden
-auch für dessen Betrieb nötige Konfigurationsdateien erstellt (siehe
-@ref{Dienste definieren}).
-@cindex Anpassung, von Diensten
-@findex modify-services
-Gelegentlich werden Sie die Basis-Dienste nicht einfach so, wie sie sind,
-benutzen, sondern anpassen wollen. Benutzen Sie @code{modify-services}
-(siehe @ref{Service-Referenz, @code{modify-services}}), um die Liste der
-Basis-Dienste zu modifizieren.
-Wenn Sie zum Beispiel @code{guix-daemon} und Mingetty (das Programm, womit
-Sie sich auf der Konsole anmelden) in der @var{%base-services}-Liste
-modifizieren möchten (siehe @ref{Basisdienste, @code{%base-services}}),
-schreiben Sie das Folgende in Ihre Betriebssystemdeklaration:
-@lisp
-(define %my-services
-  ;; Meine ganz eigene Liste von Diensten.
-  (modify-services %base-services
-    (guix-service-type config =>
-                       (guix-configuration
-                        (inherit config)
-                        (use-substitutes? #f)
-                        (extra-options '("--gc-keep-derivations"))))
-    (mingetty-service-type config =>
-                           (mingetty-configuration
-                            (inherit config)))))
-(operating-system
-  ;; @dots{}
-  (services %my-services))
-@end lisp
-Dadurch ändert sich die Konfiguration — d.h.@: die Dienst-Parameter — der
-@code{guix-service-type}-Instanz und die aller
-@code{mingetty-service-type}-Instanzen in der
-@var{%base-services}-Liste. Das funktioniert so: Zunächst arrangieren wir,
-dass die ursprüngliche Konfiguration an den Bezeichner @code{config} im
-@var{Rumpf} gebunden wird, dann schreiben wir den @var{Rumpf}, damit er zur
-gewünschten Konfiguration ausgewertet wird. Beachten Sie insbesondere, wie
-wir mit @code{inherit} eine neue Konfiguration erzeugen, die dieselben Werte
-wie die alte Konfiguration hat, aber mit ein paar Modifikationen.
-@cindex verschlüsselte Partition
-Die Konfiguration für typische »Schreibtisch«-Nutzung zum Arbeiten, mit
-einer verschlüsselten Partition für das Wurzeldateisystem, einem
-X11-Display-Server, GNOME und Xfce (Benutzer können im Anmeldebildschirm
-auswählen, welche dieser Arbeitsumgebungen sie möchten, indem sie die Taste
-@kbd{F1} drücken), Netzwerkverwaltung, Verwaltungswerkzeugen für den
-Energieverbrauch, und Weiteres, würde so aussehen:
-@lisp
-@include os-config-desktop.texi
-@end lisp
-Ein grafisches System mit einer Auswahl an leichtgewichtigen
-Fenster-Managern statt voll ausgestatteten Arbeitsumgebungen würde so
-aussehen:
-@lisp
-@include os-config-lightweight-desktop.texi
-@end lisp
-Dieses Beispiel bezieht sich auf das Dateisystem hinter @file{/boot/efi}
-über dessen UUID, @code{1234-ABCD}. Schreiben Sie statt dieser UUID die
-richtige UUID für Ihr System, wie sie der Befehl @command{blkid} liefert.
-Im Abschnitt @ref{Desktop-Dienste} finden Sie eine genaue Liste der unter
-@var{%desktop-services} angebotenen Dienste. Der Abschnitt @ref{X.509-Zertifikate} hat Hintergrundinformationen über das @code{nss-certs}-Paket,
-das hier benutzt wird.
-Beachten Sie, dass @var{%desktop-services} nur eine Liste von die Dienste
-repräsentierenden service-Objekten ist. Wenn Sie Dienste daraus entfernen
-möchten, können Sie dazu die Prozeduren zum Filtern von Listen benutzen
-(siehe @ref{SRFI-1 Filtering and Partitioning,,, guile, GNU Guile Reference
-Manual}). Beispielsweise liefert der folgende Ausdruck eine Liste mit allen
-Diensten von @var{%desktop-services} außer dem Avahi-Dienst.
-@example
-(remove (lambda (service)
-          (eq? (service-kind service) avahi-service-type))
-        %desktop-services)
-@end example
-@unnumberedsubsec Das System instanziieren
-Angenommen, Sie haben die @code{operating-system}-Deklaration in einer Datei
-@file{my-system-config.scm} gespeichert, dann instanziiert der Befehl
-@command{guix system reconfigure my-system-config.scm} diese Konfiguration
-und macht sie zum voreingestellten GRUB-Boot-Eintrag (siehe @ref{Aufruf von guix system}).
-Der normale Weg, die Systemkonfiguration nachträglich zu ändern, ist, die
-Datei zu aktualisieren und @command{guix system reconfigure} erneut
-auszuführen. Man sollte nie die Dateien in @file{/etc} bearbeiten oder den
-Systemzustand mit Befehlen wie @command{useradd} oder @command{grub-install}
-verändern. Tatsächlich müssen Sie das ausdrücklich vermeiden, sonst verfällt
-nicht nur Ihre Garantie, sondern Sie können Ihr System auch nicht mehr auf
-eine alte Version des Systems zurücksetzen, falls das jemals notwendig wird.
-@cindex Zurücksetzen, des Betriebssystems
-Zurücksetzen bezieht sich hierbei darauf, dass jedes Mal, wenn Sie
-@command{guix system reconfigure} ausführen, eine neue @dfn{Generation} des
-Systems erzeugt wird — ohne vorherige Generationen zu verändern. Alte
-Systemgenerationen bekommen einen Eintrag im Boot-Menü des Bootloaders,
-womit Sie alte Generationen beim Starten des Rechners auswählen können, wenn
-mit der neuesten Generation etwas nicht stimmt. Eine beruhigende
-Vorstellung, oder? Der Befehl @command{guix system list-generations} führt
-die auf der Platte verfügbaren Systemgenerationen auf. Es ist auch möglich,
-das System mit den Befehlen @command{guix system roll-back} und
-@command{guix system switch-generation} zurückzusetzen.
-Obwohl der Befehl @command{guix system reconfigure} vorherige Generationen
-nicht verändern wird, müssen Sie Acht geben, dass wenn die momentan aktuelle
-Generation nicht die neueste ist (z.B.@: nach einem Aufruf von @command{guix
-system roll-back}), weil @command{guix system reconfigure} alle neueren
-Generationen überschreibt (siehe @ref{Aufruf von guix system}).
-@unnumberedsubsec Die Programmierschnittstelle
-Auf der Ebene von Scheme wird der Großteil der
-@code{operating-system}-Deklaration mit der folgenden monadischen Prozedur
-instanziiert (siehe @ref{Die Store-Monade}):
-@deffn {Monadische Prozedur} operating-system-derivation os
-Liefert eine Ableitung, mit der ein @code{operating-system}-Objekt @var{os}
-erstellt wird (siehe @ref{Ableitungen}).
-Die Ausgabe der Ableitung ist ein einzelnes Verzeichnis mit Verweisen auf
-alle Pakete, Konfigurationsdateien und andere unterstützenden Dateien, die
-nötig sind, um @var{os} zu instanziieren.
-@end deffn
-Diese Prozedur wird vom Modul @code{(gnu system)} angeboten. Zusammen mit
-@code{(gnu services)} (siehe @ref{Dienste}) deckt dieses Modul den Kern von
-»Guix System« ab. Schauen Sie es sich mal an!
-@node »operating-system«-Referenz
-@section @code{operating-system}-Referenz
-Dieser Abschnitt fasst alle Optionen zusammen, die für
-@code{operating-system}-Deklarationen zur Verfügung stehen (siehe @ref{Das Konfigurationssystem nutzen}).
-@deftp {Datentyp} operating-system
-Der die Betriebssystemkonfiguration repräsentierende Datentyp. Damit meinen
-wir die globale Konfiguration des Systems und nicht die, die sich nur auf
-einzelne Nutzer bezieht (siehe @ref{Das Konfigurationssystem nutzen}).
-@table @asis
-@item @code{kernel} (Vorgabe: @var{linux-libre})
-Das Paket für den zu nutzenden Betriebssystem-Kernel als
-»package«-Objekt@footnote{Derzeit wird nur der Kernel Linux-libre
-unterstützt. In der Zukunft wird man auch GNU@tie{}Hurd benutzen können.}.
-@item @code{kernel-arguments} (Vorgabe: @code{'()})
-Eine Liste aus Zeichenketten oder G-Ausdrücken, die für zusätzliche
-Argumente an den Kernel stehen, die ihm auf seiner Befehlszeile übergeben
-werden — wie z.B.@: @code{("console=ttyS0")}.
-@item @code{bootloader}
-Das Konfigurationsobjekt für den Bootloader, mit dem das System gestartet
-wird. Siehe @ref{Bootloader-Konfiguration}.
-@item @code{label}
-This is the label (a string) as it appears in the bootloader's menu entry.
-The default label includes the kernel name and version.
-@item @code{keyboard-layout} (Vorgabe: @code{#f})
-Dieses Feld gibt an, welche Tastaturbelegung auf der Konsole benutzt werden
-soll. Es kann entweder auf @code{#f} gesetzt sein, damit die voreingestellte
-Tastaturbelegung benutzt wird (in der Regel ist diese »US English«), oder
-ein @code{<keyboard-layout>}-Verbundsobjekt sein.
-Diese Tastaturbelegung wird benutzt, sobald der Kernel gebootet wurde. Diese
-Tastaturbelegung wird zum Beispiel auch verwendet, wenn Sie eine Passphrase
-eintippen, falls sich Ihr Wurzeldateisystem auf einem mit
-@code{luks-device-mapping} zugeordneten Gerät befindet (siehe @ref{Zugeordnete Geräte}).
-@quotation Anmerkung
-Damit wird @emph{nicht} angegeben, welche Tastaturbelegung der Bootloader
-benutzt, und auch nicht, welche der grafische Display-Server
-verwendet. Siehe @ref{Bootloader-Konfiguration} für Informationen darüber,
-wie Sie die Tastaturbelegung des Bootloaders angeben können. Siehe @ref{X Window} für Informationen darüber, wie Sie die Tastaturbelegung angeben
-können, die das X-Fenstersystem verwendet.
-@end quotation
-@item @code{initrd-modules} (Vorgabe: @code{%base-initrd-modules})
-@cindex initrd
-@cindex initiale RAM-Disk
-Die Liste der Linux-Kernel-Module, die in der initialen RAM-Disk zur
-Verfügung stehen sollen. Siehe @ref{Initiale RAM-Disk}.
-@item @code{initrd} (Vorgabe: @code{base-initrd})
-Eine Prozedur, die eine initiale RAM-Disk für den Linux-Kernel
-liefert. Dieses Feld gibt es, damit auch sehr systemnahe Anpassungen
-vorgenommen werden können, aber für die normale Nutzung sollte man es kaum
-brauchen. Siehe @ref{Initiale RAM-Disk}.
-@item @code{firmware} (Vorgabe: @var{%base-firmware})
-@cindex Firmware
-Eine Liste der Firmware-Pakete, die vom Betriebssystem-Kernel geladen werden
-können.
-Vorgegeben ist, dass für Atheros- und Broadcom-basierte WLAN-Geräte nötige
-Firmware geladen werden kann (genauer jeweils die Linux-libre-Module
-@code{ath9k} und @code{b43-open}). Siehe den Abschnitt @ref{Hardware-Überlegungen} für mehr Informationen zu unterstützter Hardware.
-@item @code{host-name}
-Der Hostname
-@item @code{hosts-file}
-@cindex hosts-Datei
-Ein dateiartiges Objekt (siehe @ref{G-Ausdrücke, file-like objects}), das
-für @file{/etc/hosts} benutzt werden soll (siehe @ref{Host Names,,, libc,
-The GNU C Library Reference Manual}). Der Vorgabewert ist eine Datei mit
-Einträgen für @code{localhost} und @var{host-name}.
-@item @code{mapped-devices} (Vorgabe: @code{'()})
-Eine Liste zugeordneter Geräte (»mapped devices«). Siehe @ref{Zugeordnete Geräte}.
-@item @code{file-systems}
-Eine Liste von Dateisystemen. Siehe @ref{Dateisysteme}.
-@item @code{swap-devices} (Vorgabe: @code{'()})
-@cindex Swap-Geräte
-Eine Liste von Zeichenketten, die Geräte identifizieren oder als
-»Swap-Speicher« genutzte Dateien identifizieren (siehe @ref{Memory
-Concepts,,, libc, The GNU C Library Reference Manual}). Beispiele wären etwa
-@code{'("/dev/sda3")} oder @code{'("/swapdatei")}. Es ist möglich, eine
-Swap-Datei auf dem Dateisystem eines zugeordneten Geräts anzugeben, sofern
-auch die Gerätezuordnung und das Dateisystem mit angegeben werden. Siehe
-@ref{Zugeordnete Geräte} und @ref{Dateisysteme}.
-@item @code{users} (Vorgabe: @code{%base-user-accounts})
-@itemx @code{groups} (Vorgabe: @var{%base-groups})
-Liste der Benutzerkonten und Benutzergruppen. Siehe @ref{Benutzerkonten}.
-Wenn in der @code{users}-Liste kein Benutzerkonto mit der UID-Kennung@tie{}0
-aufgeführt wird, wird automatisch für den Administrator ein
-»root«-Benutzerkonto mit UID-Kennung@tie{}0 hinzugefügt.
-@item @code{skeletons} (Vorgabe: @code{(default-skeletons)})
-Eine Liste von Tupeln aus je einem Ziel-Dateinamen und einem dateiähnlichen
-Objekt (siehe @ref{G-Ausdrücke, file-like objects}). Diese Objekte werden
-als Skeleton-Dateien im Persönlichen Verzeichnis (»Home«-Verzeichnis) jedes
-neuen Benutzerkontos angelegt.
-Ein gültiger Wert könnte zum Beispiel so aussehen:
-@example
-`((".bashrc" ,(plain-file "bashrc" "echo Hallo\n"))
-  (".guile" ,(plain-file "guile"
-                         "(use-modules (ice-9 readline))
-                          (activate-readline)")))
-@end example
-@item @code{issue} (Vorgabe: @var{%default-issue})
-Eine Zeichenkette, die als Inhalt der Datei @file{/etc/issue} verwendet
-werden soll, der jedes Mal angezeigt wird, wenn sich ein Nutzer auf einer
-Textkonsole anmeldet.
-@item @code{packages} (Vorgabe: @var{%base-packages})
-Die Menge der Pakete, die ins globale Profil installiert werden sollen,
-welches unter @file{/run/current-system/profile} zu finden ist.
-Die vorgegebene Paketmenge umfasst zum Kern des Systems gehörende Werkzeuge
-(»core utilities«). Es ist empfehlenswert, nicht zum Kern gehörende
-Werkzeuge (»non-core«) stattdessen in Nutzerprofile zu installieren (siehe
-@ref{Aufruf von guix package}).
-@item @code{timezone}
-Eine Zeichenkette, die die Zeitzone bezeichnet, wie z.B.@:
-@code{"Europe/Berlin"}.
-Mit dem Befehl @command{tzselect} können Sie herausfinden, welche
-Zeichenkette der Zeitzone Ihrer Region entspricht. Wenn Sie eine ungültige
-Zeichenkette angeben, schlägt @command{guix system} fehl.
-@item @code{locale} (Vorgabe: @code{"en_US.utf8"})
-Der Name der als Voreinstellung zu verwendenden Locale (siehe @ref{Locale
-Names,,, libc, The GNU C Library Reference Manual}). Siehe @ref{Locales} für
-weitere Informationen.
-@item @code{locale-definitions} (Vorgabe: @var{%default-locale-definitions})
-Die Liste der Locale-Definitionen, die kompiliert werden sollen und dann im
-laufenden System benutzt werden können. Siehe @ref{Locales}.
-@item @code{locale-libcs} (Vorgabe: @code{(list @var{glibc})})
-Die Liste der GNU-libc-Pakete, deren Locale-Daten und -Werkzeuge zum
-Erzeugen der Locale-Definitionen verwendet werden sollen. Siehe
-@ref{Locales} für eine Erläuterung der Kompatibilitätsauswirkungen,
-deretwegen man diese Option benutzen wollen könnte.
-@item @code{name-service-switch} (Vorgabe: @var{%default-nss})
-Die Konfiguration des Name Service Switch (NSS) der libc — ein
-@code{<name-service-switch>}-Objekt. Siehe @ref{Name Service Switch} für
-Details.
-@item @code{services} (Vorgabe: @var{%base-services})
-Eine Liste von »service«-Objekten, die die Systemdienste
-repräsentieren. Siehe @ref{Dienste}.
-@cindex essenzielle Dienste
-@item @code{essential-services} (Vorgabe: …)
-The list of ``essential services''---i.e., things like instances of
-@code{system-service-type} and @code{host-name-service-type} (@pxref{Service-Referenz}), which are derived from the operating system definition itself.
-As a user you should @emph{never} need to touch this field.
-@item @code{pam-services} (Vorgabe: @code{(base-pam-services)})
-@cindex PAM
-@cindex Pluggable Authentication Modules
-@c FIXME: Add xref to PAM services section.
-Dienste für @dfn{Pluggable Authentication Modules} (PAM) von Linux.
-@item @code{setuid-programs} (Vorgabe: @var{%setuid-programs})
-Eine Liste von Zeichenketten liefernden G-Ausdrücken, die setuid-Programme
-bezeichnen. Siehe @ref{Setuid-Programme}.
-@item @code{sudoers-file} (Vorgabe: @var{%sudoers-specification})
-@cindex sudoers-Datei
-Der Inhalt der Datei @file{/etc/sudoers} als ein dateiähnliches Objekt
-(siehe @ref{G-Ausdrücke, @code{local-file} und @code{plain-file}}).
-Diese Datei gibt an, welche Nutzer den Befehl @command{sudo} benutzen
-dürfen, was sie damit tun und welche Berechtigungen sie so erhalten
-können. Die Vorgabe ist, dass nur der Administratornutzer @code{root} und
-Mitglieder der Benutzergruppe @code{wheel} den @code{sudo}-Befehl verwenden
-dürfen.
-@end table
-@deffn {Scheme Syntax} this-operating-system
-When used in the @emph{lexical scope} of an operating system field
-definition, this identifier resolves to the operating system being defined.
-The example below shows how to refer to the operating system being defined
-in the definition of the @code{label} field:
-@example
-(use-modules (gnu) (guix))
-(operating-system
-  ;; ...
-  (label (package-full-name
-          (operating-system-kernel this-operating-system))))
-@end example
-It is an error to refer to @code{this-operating-system} outside an operating
-system definition.
-@end deffn
-@end deftp
-@node Dateisysteme
-@section Dateisysteme
-Die Liste der Dateisysteme, die eingebunden werden sollen, steht im
-@code{file-systems}-Feld der Betriebssystemdeklaration (siehe @ref{Das Konfigurationssystem nutzen}). Jedes Dateisystem wird mit der
-@code{file-system}-Form deklariert, etwa so:
-@example
-(file-system
-  (mount-point "/home")
-  (device "/dev/sda3")
-  (type "ext4"))
-@end example
-Wie immer müssen manche Felder angegeben werden — die, die im Beispiel oben
-stehen —, während andere optional sind. Die Felder werden nun beschrieben.
-@deftp {Datentyp} file-system
-Objekte dieses Typs repräsentieren einzubindende Dateisysteme. Sie weisen
-folgende Komponenten auf:
-@table @asis
-@item @code{type}
-Eine Zeichenkette, die den Typ des Dateisystems spezifiziert, z.B.@:
-@code{"ext4"}.
-@item @code{mount-point}
-Der Einhängepunkt, d.h.@: der Pfad, an dem das Dateisystem eingebunden
-werden soll.
-@item @code{device}
-Hiermit wird die »Quelle« des Dateisystems bezeichnet. Sie kann eines von
-drei Dingen sein: die Bezeichnung (»Labels«) eines Dateisystems, die
-UUID-Kennung des Dateisystems oder der Name eines @file{/dev}-Knotens. Mit
-Bezeichnungen und UUIDs kann man Dateisysteme benennen, ohne den Gerätenamen
-festzuschreiben@footnote{Beachten Sie: Obwohl es verführerisch ist, mit
-@file{/dev/disk/by-uuid} und ähnlichen Gerätenamen dasselbe Resultat
-bekommen zu wollen, raten wir davon ab: Diese speziellen Gerätenamen werden
-erst vom udev-Daemon erzeugt und sind, wenn die Geräte eingebunden werden,
-vielleicht noch nicht verfügbar.}.
-@findex file-system-label
-Dateisystem-Bezeichnungen (»Labels«) werden mit der Prozedur
-@code{file-system-label} erzeugt und UUID-Kennungen werden mit @code{uuid}
-erzeugt, während Knoten in @file{/dev} mit ihrem Pfad als einfache
-Zeichenketten aufgeführt werden. Hier ist ein Beispiel, wie wir ein
-Dateisystem anhand seiner Bezeichnung aufführen, wie sie vom Befehl
-@command{e2label} angezeigt wird:
-@example
-(file-system
-  (mount-point "/home")
-  (type "ext4")
-  (device (file-system-label "my-home")))
-@end example
-@findex uuid
-UUID-Kennungen werden mit der @code{uuid}-Form von ihrer Darstellung als
-Zeichenkette (wie sie vom Befehl @command{tune2fs -l} angezeigt wird)
-konvertiert@footnote{Die @code{uuid}-Form nimmt 16-Byte-UUIDs entgegen, wie
-sie in @uref{https://tools.ietf.org/html/rfc4122, RFC@tie{}4122} definiert
-sind. Diese Form der UUID wird unter anderem von der ext2-Familie von
-Dateisystemen verwendet, sie unterscheidet sich jedoch zum Beispiel von den
-»UUID« genannten Kennungen, wie man sie bei FAT-Dateisystemen findet.} wie
-hier:
-@example
-(file-system
-  (mount-point "/home")
-  (type "ext4")
-  (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))
-@end example
-Wenn die Quelle eines Dateisystems ein zugeordnetes Gerät (siehe @ref{Zugeordnete Geräte}) ist, @emph{muss} sich das @code{device}-Feld auf den zugeordneten
-Gerätenamen beziehen — z.B.@: @file{"/dev/mapper/root-partition"}. Das ist
-nötig, damit das System weiß, dass das Einbinden des Dateisystems davon
-abhängt, die entsprechende Gerätezuordnung hergestellt zu haben.
-@item @code{flags} (Vorgabe: @code{'()})
-Eine Liste von Symbolen, die Einbinde-Flags (»mount flags«)
-bezeichnen. Erkannt werden unter anderem @code{read-only},
-@code{bind-mount}, @code{no-dev} (Zugang zu besonderen Dateien verweigern),
-@code{no-suid} (setuid- und setgid-Bits ignorieren) und @code{no-exec}
-(Programmausführungen verweigern).
-@item @code{options} (Vorgabe: @code{#f})
-Entweder @code{#f} oder eine Zeichenkette mit Einbinde-Optionen (»mount
-options«).
-@item @code{mount?} (Vorgabe: @code{#t})
-Dieser Wert zeigt an, ob das Dateisystem automatisch eingebunden werden
-soll, wenn das System gestartet wird. Ist der Wert @code{#f}, dann erhält
-das Dateisystem nur einen Eintrag in der Datei @file{/etc/fstab} (welche vom
-@command{mount}-Befehl zum Einbinden gelesen wird), es wird aber nicht
-automatisch eingebunden.
-@item @code{needed-for-boot?} (Vorgabe: @code{#f})
-Dieser boolesche Wert gibt an, ob das Dateisystem zum Hochfahren des Systems
-notwendig ist. In diesem Fall wird das Dateisystem eingebunden, wenn die
-initiale RAM-Disk (initrd) geladen wird. Für zum Beispiel das
-Wurzeldateisystem ist dies ohnehin immer der Fall.
-@item @code{check?} (Vorgabe: @code{#t})
-Dieser boolesche Wert sagt aus, ob das Dateisystem vor dem Einbinden auf
-Fehler hin geprüft werden soll.
-@item @code{create-mount-point?} (Vorgabe: @code{#f})
-Steht dies auf wahr, wird der Einhängepunkt vor dem Einbinden erstellt, wenn
-er noch nicht existiert.
-@item @code{dependencies} (Vorgabe: @code{'()})
-Dies ist eine Liste von @code{<file-system>}- oder
-@code{<mapped-device>}-Objekten, die Dateisysteme repräsentieren, die vor
-diesem Dateisystem eingebunden oder zugeordnet werden müssen (und nach
-diesem ausgehängt oder geschlossen werden müssen).
-Betrachten Sie zum Beispiel eine Hierarchie von Einbindungen:
-@file{/sys/fs/cgroup} ist eine Abhängigkeit von @file{/sys/fs/cgroup/cpu}
-und @file{/sys/fs/cgroup/memory}.
-Ein weiteres Beispiel ist ein Dateisystem, was von einem zugeordneten Gerät
-abhängt, zum Beispiel zur Verschlüsselung einer Partition (siehe @ref{Zugeordnete Geräte}).
-@end table
-@end deftp
-Das Modul @code{(gnu system file-systems)} exportiert die folgenden
-nützlichen Variablen.
-@defvr {Scheme-Variable} %base-file-systems
-Hiermit werden essenzielle Dateisysteme bezeichnet, die für normale Systeme
-unverzichtbar sind, wie zum Beispiel @var{%pseudo-terminal-file-system} und
-@var{%immutable-store} (siehe unten). Betriebssystemdeklaration sollten auf
-jeden Fall mindestens diese enthalten.
-@end defvr
-@defvr {Scheme-Variable} %pseudo-terminal-file-system
-Das als @file{/dev/pts} einzubindende Dateisystem. Es unterstützt über
-@code{openpty} und ähnliche Funktionen erstellte @dfn{Pseudo-Terminals}
-(siehe @ref{Pseudo-Terminals,,, libc, The GNU C Library Reference
-Manual}). Pseudo-Terminals werden von Terminal-Emulatoren wie
-@command{xterm} benutzt.
-@end defvr
-@defvr {Scheme-Variable} %shared-memory-file-system
-Dieses Dateisystem wird als @file{/dev/shm} eingebunden, um Speicher
-zwischen Prozessen teilen zu können (siehe @ref{Memory-mapped I/O,
-@code{shm_open},, libc, The GNU C Library Reference Manual}).
-@end defvr
-@defvr {Scheme-Variable} %immutable-store
-Dieses Dateisystem vollzieht einen »bind mount« des @file{/gnu/store}, um
-ihn für alle Nutzer einschließlich des Administratornutzers @code{root} nur
-lesbar zu machen, d.h.@: Schreibrechte zu entziehen. Dadurch kann als
-@code{root} ausgeführte Software, oder der Systemadministrator, nicht aus
-Versehen den Store modifizieren.
-Der Daemon kann weiterhin in den Store schreiben, indem er ihn selbst mit
-Schreibrechten in seinem eigenen »Namensraum« einbindet.
-@end defvr
-@defvr {Scheme-Variable} %binary-format-file-system
-Das @code{binfmt_misc}-Dateisystem, durch das beliebige Dateitypen als
-ausführbare Dateien auf der Anwendungsebene (dem User Space) zugänglich
-gemacht werden können. Es setzt voraus, dass das Kernel-Modul
-@code{binfmt.ko} geladen wurde.
-@end defvr
-@defvr {Scheme-Variable} %fuse-control-file-system
-Das @code{fusectl}-Dateisystem, womit »unprivilegierte« Nutzer ohne
-besondere Berechtigungen im User Space FUSE-Dateisysteme einbinden und
-aushängen können. Dazu muss das Kernel-Modul @code{fuse.ko} geladen sein.
-@end defvr
-@node Zugeordnete Geräte
-@section Zugeordnete Geräte
-@cindex Gerätezuordnung
-@cindex zugeordnete Geräte
-Der Linux-Kernel unterstützt das Konzept der @dfn{Gerätezuordnung}: Ein
-blockorientiertes Gerät wie eine Festplattenpartition kann einem neuen Gerät
-@dfn{zugeordnet} werden, gewöhnlich unter @code{/dev/mapper/}, wobei das
-neue Gerät durchlaufende Daten zusätzlicher Verarbeitung unterzogen
-werden@footnote{Beachten Sie, dass mit GNU@tie{}Hurd kein Unterschied
-zwischen dem Konzept eines »zugeordneten Geräts« und dem eines Dateisystems
-besteht: Dort werden bei beiden Ein- und Ausgabeoperationen auf eine Datei
-in Operationen auf dessen Hintergrundspeicher @emph{übersetzt}. Hurd
-implementiert zugeordnete Geräte genau wie Dateisysteme mit dem generischen
-@dfn{Übersetzer}-Mechanismus (siehe @ref{Translators,,, hurd, The GNU Hurd
-Reference Manual}).}. Ein typisches Beispiel ist eine Gerätezuordnung zur
-Verschlüsselung: Jeder Schreibzugriff auf das zugeordnete Gerät wird
-transparent verschlüsselt und jeder Lesezugriff ebenso entschlüsselt. Guix
-erweitert dieses Konzept, indem es darunter jedes Gerät und jede Menge von
-Geräten versteht, die auf irgendeine Weise @dfn{umgewandelt} wird, um ein
-neues Gerät zu bilden; zum Beispiel entstehen auch RAID-Geräte aus einem
-@dfn{Verbund} mehrerer anderer Geräte, wie etwa Festplatten oder Partition
-zu einem einzelnen Gerät, das sich wie eine Partition verhält. Ein weiteres
-Beispiel, das noch nicht in Guix implementiert wurde, sind »LVM logical
-volumes«.
-Zugeordnete Geräte werden mittels einer @code{mapped-device}-Form
-deklariert, die wie folgt definiert ist; Beispiele folgen weiter unten.
-@deftp {Datentyp} mapped-device
-Objekte dieses Typs repräsentieren Gerätezuordnungen, die gemacht werden,
-wenn das System hochfährt.
-@table @code
-@item source
-Es handelt sich entweder um eine Zeichenkette, die den Namen eines
-zuzuordnenden blockorientierten Geräts angibt, wie @code{"/dev/sda3"}, oder
-um eine Liste solcher Zeichenketten, sofern mehrere Geräts zu einem neuen
-Gerät verbunden werden.
-@item target
-Diese Zeichenkette gibt den Namen des neuen zugeordneten Geräts an. Bei
-Kernel-Zuordnern, wie verschlüsselten Geräten vom Typ
-@code{luks-device-mapping}, wird durch Angabe von @code{"my-partition"} ein
-Gerät @code{"/dev/mapper/my-partition"} erzeugt. Bei RAID-Geräten vom Typ
-@code{raid-device-mapping} muss der Gerätename als voller Pfad wie zum
-Beispiel @code{"/dev/md0"} angegeben werden.
-@item type
-Dies muss ein @code{mapped-device-kind}-Objekt sein, das angibt, wie die
-Quelle @var{source} dem Ziel @var{target} zugeordnet wird.
-@end table
-@end deftp
-@defvr {Scheme-Variable} luks-device-mapping
-Hiermit wird ein blockorientiertes Gerät mit LUKS verschlüsselt, mit Hilfe
-des Befehls @command{cryptsetup} aus dem gleichnamigen Paket. Dazu wird das
-Linux-Kernel-Modul @code{dm-crypt} vorausgesetzt.
-@end defvr
-@defvr {Scheme-Variable} raid-device-mapping
-Dies definiert ein RAID-Gerät, das mit dem Befehl @code{mdadm} aus dem
-gleichnamigen Paket als Verbund zusammengestellt wird. Es setzt voraus, dass
-das Linux-Kernel-Modul für das entsprechende RAID-Level geladen ist, z.B.@:
-@code{raid456} für RAID-4, RAID-5 oder RAID-6, oder @code{raid10} für
-RAID-10.
-@end defvr
-@cindex Laufwerksverschlüsselung
-@cindex LUKS
-Das folgende Beispiel gibt eine Zuordnung von @file{/dev/sda3} auf
-@file{/dev/mapper/home} mit LUKS an — dem
-@url{https://gitlab.com/cryptsetup/cryptsetup,Linux Unified Key Setup},
-einem Standardmechanismus zur Plattenverschlüsselung. Das Gerät
-@file{/dev/mapper/home} kann dann als @code{device} einer
-@code{file-system}-Deklaration benutzt werden (siehe @ref{Dateisysteme}).
-@example
-(mapped-device
-  (source "/dev/sda3")
-  (target "home")
-  (type luks-device-mapping))
-@end example
-Um nicht davon abhängig zu sein, wie Ihre Geräte nummeriert werden, können
-Sie auch die LUKS-UUID (@dfn{unique identifier}, d.h.@: den eindeutigen
-Bezeichner) des Quellgeräts auf der Befehlszeile ermitteln:
-@example
-cryptsetup luksUUID /dev/sda3
-@end example
-und wie folgt benutzen:
-@example
-(mapped-device
-  (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
-  (target "home")
-  (type luks-device-mapping))
-@end example
-@cindex Swap-Verschlüsselung
-Es ist auch wünschenswert, Swap-Speicher zu verschlüsseln, da in den
-Swap-Speicher sensible Daten ausgelagert werden können. Eine Möglichkeit
-ist, eine Swap-Datei auf einem mit LUKS-Verschlüsselung zugeordneten
-Dateisystem zu verwenden. Dann wird die Swap-Datei verschlüsselt, weil das
-ganze Gerät verschlüsselt wird. Ein Beispiel finden Sie im Abschnitt
-@ref{Vor der Installation,,Disk Partitioning}.
-Ein RAID-Gerät als Verbund der Partitionen @file{/dev/sda1} und
-@file{/dev/sdb1} kann wie folgt deklariert werden:
-@example
-(mapped-device
-  (source (list "/dev/sda1" "/dev/sdb1"))
-  (target "/dev/md0")
-  (type raid-device-mapping))
-@end example
-Das Gerät @file{/dev/md0} kann als @code{device} in einer
-@code{file-system}-Deklaration dienen (siehe @ref{Dateisysteme}). Beachten
-Sie, dass das RAID-Level dabei nicht angegeben werden muss; es wird während
-der initialen Erstellung und Formatierung des RAID-Geräts festgelegt und
-später automatisch bestimmt.
-@node Benutzerkonten
-@section Benutzerkonten
-@cindex Benutzer
-@cindex Konten
-@cindex Benutzerkonten
-Benutzerkonten und Gruppen werden allein durch die
-@code{operating-system}-Deklaration des Betriebssystems verwaltet. Sie
-werden mit den @code{user-account}- und @code{user-group}-Formen angegeben:
-@example
-(user-account
-  (name "alice")
-  (group "users")
-  (supplementary-groups '("wheel"   ;zur sudo-Nutzung usw. berechtigen
-                          "audio"   ;Soundkarte
-                          "video"   ;Videogeräte wie Webcams
-                          "cdrom")) ;die gute alte CD-ROM
-  (comment "Bobs Schwester")
-  (home-directory "/home/alice"))
-@end example
-Beim Hochfahren oder nach Abschluss von @command{guix system reconfigure}
-stellt das System sicher, dass nur die in der
-@code{operating-system}-Deklaration angegebenen Benutzerkonten und Gruppen
-existieren, mit genau den angegebenen Eigenschaften. Daher gehen durch
-direkten Aufruf von Befehlen wie @command{useradd} erwirkte Erstellungen
-oder Modifikationen von Konten oder Gruppen verloren, sobald rekonfiguriert
-oder neugestartet wird. So wird sichergestellt, dass das System genau so
-funktioniert, wie es deklariert wurde.
-@deftp {Datentyp} user-account
-Objekte dieses Typs repräsentieren Benutzerkonten. Darin können folgende
-Komponenten aufgeführt werden:
-@table @asis
-@item @code{name}
-Der Name des Benutzerkontos.
-@item @code{group}
-@cindex Gruppen
-Dies ist der Name (als Zeichenkette) oder die Bezeichnung (als Zahl) der
-Benutzergruppe, zu der dieses Konto gehört.
-@item @code{supplementary-groups} (Vorgabe: @code{'()})
-Dies kann optional als Liste von Gruppennamen angegeben werden, zu denen
-dieses Konto auch gehört.
-@item @code{uid} (Vorgabe: @code{#f})
-Dies ist entweder der Benutzeridentifikator dieses Kontos (seine »User ID«)
-als Zahl oder @code{#f}. Bei Letzterem wird vom System automatisch eine Zahl
-gewählt, wenn das Benutzerkonto erstellt wird.
-@item @code{comment} (Vorgabe: @code{""})
-Ein Kommentar zu dem Konto, wie etwa der vollständige Name des
-Kontoinhabers.
-@item @code{home-directory}
-Der Name des Persönlichen Verzeichnisses (»Home«-Verzeichnis) für dieses
-Konto.
-@item @code{create-home-directory?} (Vorgabe: @code{#t})
-Zeigt an, ob das Persönliche Verzeichnis für das Konto automatisch erstellt
-werden soll, falls es noch nicht existiert.
-@item @code{shell} (Vorgabe: Bash)
-Ein G-Ausdruck, der den Dateinamen des Programms angibt, das dem Benutzer
-als Shell dienen soll (siehe @ref{G-Ausdrücke}).
-@item @code{system?} (Vorgabe: @code{#f})
-Dieser boolesche Wert zeigt an, ob das Konto ein »System«-Benutzerkonto
-ist. Systemkonten werden manchmal anders behandelt, zum Beispiel werden sie
-auf grafischen Anmeldebildschirmen nicht aufgeführt.
-@anchor{user-account-password}
-@cindex Passwort, für Benutzerkonten
-@item @code{password} (Vorgabe: @code{#f})
-Normalerweise lassen Sie dieses Feld auf @code{#f} und initialisieren
-Benutzerpasswörter als @code{root} mit dem @command{passwd}-Befehl. Die
-Benutzer lässt man ihr eigenes Passwort dann mit @command{passwd}
-ändern. Mit @command{passwd} festgelegte Passwörter bleiben natürlich beim
-Neustarten und beim Rekonfigurieren erhalten.
-Wenn Sie aber @emph{doch} ein anfängliches Passwort für ein Konto
-voreinstellen möchten, muss dieses Feld hier das verschlüsselte Passwort als
-Zeichenkette enthalten. Sie können dazu die Prozedur @code{crypt} benutzen.
-@example
-(user-account
-  (name "charlie")
-  (group "users")
-  ;; Specify a SHA-512-hashed initial password.
-  (password (crypt "InitialPassword!" "$6$abc")))
-@end example
-@quotation Anmerkung
-The hash of this initial password will be available in a file in
-@file{/gnu/store}, readable by all the users, so this method must be used
-with care.
-@end quotation
-Siehe @ref{Passphrase Storage,,, libc, The GNU C Library Reference Manual}
-für weitere Informationen über Passwortverschlüsselung und
-@ref{Encryption,,, guile, GNU Guile Reference Manual} für Informationen über
-die Prozedur @code{crypt} in Guile.
-@end table
-@end deftp
-@cindex Gruppen
-Benutzergruppen-Deklarationen sind noch einfacher aufgebaut:
-@example
-(user-group (name "students"))
-@end example
-@deftp {Datentyp} user-group
-Dieser Typ gibt, nun ja, eine Benutzergruppe an. Es gibt darin nur ein paar
-Felder:
-@table @asis
-@item @code{name}
-Der Name der Gruppe.
-@item @code{id} (Vorgabe: @code{#f})
-Der Gruppenbezeichner (eine Zahl). Wird er als @code{#f} angegeben, wird
-automatisch eine neue Zahl reserviert, wenn die Gruppe erstellt wird.
-@item @code{system?} (Vorgabe: @code{#f})
-Dieser boolesche Wert gibt an, ob es sich um eine »System«-Gruppe
-handelt. Systemgruppen sind solche mit einer kleinen Zahl als Bezeichner.
-@item @code{password} (Vorgabe: @code{#f})
-Wie, Benutzergruppen können ein Passwort haben? Nun ja, anscheinend
-schon. Wenn es nicht auf @code{#f} steht, gibt dieses Feld das Passwort der
-Gruppe an.
-@end table
-@end deftp
-Um Ihnen das Leben zu erleichtern, gibt es eine Variable, worin alle
-grundlegenden Benutzergruppen aufgeführt sind, die man erwarten könnte:
-@defvr {Scheme-Variable} %base-groups
-Die Liste von Basis-Benutzergruppen, von denen Benutzer und/oder Pakete
-erwarten könnten, dass sie auf dem System existieren. Dazu gehören Gruppen
-wie »root«, »wheel« und »users«, sowie Gruppen, um den Zugriff auf bestimmte
-Geräte einzuschränken, wie »audio«, »disk« und »cdrom«.
-@end defvr
-@defvr {Scheme-Variable} %base-user-accounts
-Diese Liste enthält Basis-Systembenutzerkonten, von denen Programme erwarten
-können, dass sie auf einem GNU/Linux-System existieren, wie das Konto
-»nobody«.
-Beachten Sie, dass das Konto »root« für den Administratornutzer nicht
-dazugehört. Es ist ein Sonderfall und wird automatisch erzeugt, egal ob es
-spezifiziert wurde oder nicht.
-@end defvr
-@node Tastaturbelegung
-@section Tastaturbelegung
-@cindex Tastaturbelegung
-@cindex Keymap
-To specify what each key of your keyboard does, you need to tell the
-operating system what @dfn{keyboard layout} you want to use.  The default,
-when nothing is specified, is the US English QWERTY layout for 105-key PC
-keyboards.  However, German speakers will usually prefer the German QWERTZ
-layout, French speakers will want the AZERTY layout, and so on; hackers
-might prefer Dvorak or bépo, and they might even want to further customize
-the effect of some of the keys.  This section explains how to get that done.
-@cindex Tastaturbelegung, Definition
-There are three components that will want to know about your keyboard
-layout:
-@itemize
-@item
-The @emph{bootloader} may want to know what keyboard layout you want to use
-(@pxref{Bootloader-Konfiguration, @code{keyboard-layout}}).  This is useful
-if you want, for instance, to make sure that you can type the passphrase of
-your encrypted root partition using the right layout.
-@item
-The @emph{operating system kernel}, Linux, will need that so that the
-console is properly configured (@pxref{»operating-system«-Referenz,
-@code{keyboard-layout}}).
-@item
-The @emph{graphical display server}, usually Xorg, also has its own idea of
-the keyboard layout (@pxref{X Window, @code{keyboard-layout}}).
-@end itemize
-Guix allows you to configure all three separately but, fortunately, it
-allows you to share the same keyboard layout for all three components.
-@cindex XKB, Tastaturbelegungen
-Keyboard layouts are represented by records created by the
-@code{keyboard-layout} procedure of @code{(gnu system keyboard)}.  Following
-the X Keyboard extension (XKB), each layout has four attributes: a name
-(often a language code such as ``fi'' for Finnish or ``jp'' for Japanese),
-an optional variant name, an optional keyboard model name, and a possibly
-empty list of additional options.  In most cases the layout name is all you
-care about.  Here are a few example:
-@example
-;; The German QWERTZ layout.  Here we assume a standard
-;; "pc105" keyboard model.
-(keyboard-layout "de")
-;; The bépo variant of the French layout.
-(keyboard-layout "fr" "bepo")
-;; The Catalan layout.
-(keyboard-layout "es" "cat")
-;; The Latin American Spanish layout.  In addition, the
-;; "Caps Lock" key is used as an additional "Ctrl" key,
-;; and the "Menu" key is used as a "Compose" key to enter
-;; accented letters.
-(keyboard-layout "latam"
-                 #:options '("ctrl:nocaps" "compose:menu"))
-;; The Russian layout for a ThinkPad keyboard.
-(keyboard-layout "ru" #:model "thinkpad")
-;; The "US international" layout, which is the US layout plus
-;; dead keys to enter accented characters.  This is for an
-;; Apple MacBook keyboard.
-(keyboard-layout "us" "intl" #:model "macbook78")
-@end example
-See the @file{share/X11/xkb} directory of the @code{xkeyboard-config}
-package for a complete list of supported layouts, variants, and models.
-@cindex Tastaturbelegung, Konfiguration
-Let's say you want your system to use the Turkish keyboard layout throughout
-your system---bootloader, console, and Xorg.  Here's what your system
-configuration would look like:
-@findex set-xorg-configuration
-@lisp
-;; Using the Turkish layout for the bootloader, the console,
-;; and for Xorg.
-(operating-system
-  ;; ...
-  (keyboard-layout (keyboard-layout "tr"))  ;for the console
-  (bootloader (bootloader-configuration
-                (bootloader grub-efi-bootloader)
-                (target "/boot/efi")
-                (keyboard-layout keyboard-layout))) ;for GRUB
-  (services (cons (set-xorg-configuration
-                    (xorg-configuration             ;for Xorg
-                      (keyboard-layout keyboard-layout)))
-                  %desktop-services)))
-@end lisp
-In the example above, for GRUB and for Xorg, we just refer to the
-@code{keyboard-layout} field defined above, but we could just as well refer
-to a different layout.  The @code{set-xorg-configuration} procedure
-communicates the desired Xorg configuration to the graphical log-in manager,
-by default GDM.
-We've discussed how to specify the @emph{default} keyboard layout of your
-system when it starts, but you can also adjust it at run time:
-@itemize
-@item
-If you're using GNOME, its settings panel has a ``Region & Language'' entry
-where you can select one or more keyboard layouts.
-@item
-Under Xorg, the @command{setxkbmap} command (from the same-named package)
-allows you to change the current layout.  For example, this is how you would
-change the layout to US Dvorak:
-@example
-setxkbmap us dvorak
-@end example
-@item
-The @code{loadkeys} command changes the keyboard layout in effect in the
-Linux console.  However, note that @code{loadkeys} does @emph{not} use the
-XKB keyboard layout categorization described above.  The command below loads
-the French bépo layout:
-@example
-loadkeys fr-bepo
-@end example
-@end itemize
-@node Locales
-@section Locales
-@cindex Locale
-Eine @dfn{Locale} legt die kulturellen Konventionen einer bestimmten Sprache
-und Region auf der Welt fest (siehe @ref{Locales,,, libc, The GNU C Library
-Reference Manual}). Jede Locale hat einen Namen, der typischerweise von der
-Form @code{@var{Sprache}_@var{Gebiet}.@var{Kodierung}} — z.B.@: benennt
-@code{fr_LU.utf8} die Locale für französische Sprache mit den kulturellen
-Konventionen aus Luxemburg unter Verwendung der UTF-8-Kodierung.
-@cindex Locale-Definition
-Normalerweise werden Sie eine standardmäßig zu verwendende Locale für die
-Maschine vorgeben wollen, indem Sie das @code{locale}-Feld der
-@code{operating-system}-Deklaration verwenden (siehe @ref{»operating-system«-Referenz, @code{locale}}).
-Die ausgewählte Locale wird automatisch zu den dem System bekannten
-@dfn{Locale-Definitionen} hinzugefügt, falls nötig, und ihre Kodierung wird
-aus dem Namen hergeleitet — z.B.@: wird angenommen, dass @code{bo_CN.utf8}
-als Kodierung @code{UTF-8} verwendet. Zusätzliche Locale-Definitionen können
-im Feld @code{locale-definitions} vom @code{operating-system} festgelegt
-werden — das ist zum Beispiel dann nützlich, wenn die Kodierung nicht aus
-dem Locale-Namen hergeleitet werden konnte. Die vorgegebene Menge an
-Locale-Definitionen enthält manche weit verbreiteten Locales, aber um Platz
-zu sparen, nicht alle verfügbaren Locales.
-Um zum Beispiel die nordfriesische Locale für Deutschland hinzuzufügen,
-könnte der Wert des Feldes wie folgt aussehen:
-@example
-(cons (locale-definition
-        (name "fy_DE.utf8") (source "fy_DE"))
-      %default-locale-definitions)
-@end example
-Um Platz zu sparen, könnte man auch wollen, dass @code{locale-definitions}
-nur die tatsächlich benutzen Locales aufführt, wie etwa:
-@example
-(list (locale-definition
-        (name "ja_JP.eucjp") (source "ja_JP")
-        (charset "EUC-JP")))
-@end example
-@vindex LOCPATH
-Die kompilierten Locale-Definitionen sind unter
-@file{/run/current-system/locale/X.Y} verfügbar, wobei @code{X.Y} die
-Version von libc bezeichnet. Dies entspricht dem Pfad, an dem eine von Guix
-ausgelieferte GNU@tie{}libc standardmäßig nach Locale-Daten sucht. Er kann
-überschrieben werden durch die Umgebungsvariable @code{LOCPATH} (siehe
-@ref{locales-and-locpath, @code{LOCPATH} und Locale-Pakete}).
-Die @code{locale-definition}-Form wird vom Modul @code{(gnu system locale)}
-zur Verfügung gestellt.  Details folgen unten.
-@deftp {Datentyp} locale-definition
-Dies ist der Datentyp einer Locale-Definition.
-@table @asis
-@item @code{name}
-Der Name der Locale. Siehe @ref{Locale Names,,, libc, The GNU C Library
-Reference Manual} für mehr Informationen zu Locale-Namen.
-@item @code{source}
-Der Name der Quelle der Locale. Typischerweise ist das der Teil
-@code{@var{Sprache}_@var{Gebiet}} des Locale-Namens.
-@item @code{charset} (Vorgabe: @code{"UTF-8"})
-Der »Zeichensatz« oder das »Code set«, d.h.@: die Kodierung dieser Locale,
-@uref{http://www.iana.org/assignments/character-sets, wie die IANA sie
-definiert}.
-@end table
-@end deftp
-@defvr {Scheme-Variable} %default-locale-definitions
-Eine Liste häufig benutzter UTF-8-Locales, die als Vorgabewert des
-@code{locale-definitions}-Feldes in @code{operating-system}-Deklarationen
-benutzt wird.
-@cindex Locale-Name
-@cindex Normalisiertes Codeset in Locale-Namen
-Diese Locale-Definitionen benutzen das @dfn{normalisierte Codeset} für den
-Teil des Namens, der nach dem Punkt steht (siehe @ref{Using gettextized
-software, normalized codeset,, libc, The GNU C Library Reference
-Manual}). Zum Beispiel ist @code{uk_UA.utf8} enthalten, dagegen ist etwa
-@code{uk_UA.UTF-8} darin @emph{nicht} enthalten.
-@end defvr
-@subsection Kompatibilität der Locale-Daten
-@cindex Inkompatibilität, von Locale-Daten
-@code{operating-system}-Deklarationen verfügen über ein
-@code{locale-libcs}-Feld, um die GNU@tie{}libc-Pakete anzugeben, die zum
-Kompilieren von Locale-Deklarationen verwendet werden sollen (siehe
-@ref{»operating-system«-Referenz}). »Was interessiert mich das?«, könnten Sie
-fragen. Naja, leider ist das binäre Format der Locale-Daten von einer
-libc-Version auf die nächste manchmal nicht miteinander kompatibel.
-@c See <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>
-@c and <https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00737.html>.
-Zum Beispiel kann ein mit der libc-Version 2.21 gebundenes Programm keine
-mit libc 2.22 erzeugten Locale-Daten lesen; schlimmer noch, das Programm
-@emph{terminiert} statt einfach die inkompatiblen Locale-Daten zu
-ignorieren@footnote{Versionen 2.23 von GNU@tie{}libc und neuere werden
-inkompatible Locale-Daten nur mehr überspringen, was schon einmal eine
-Verbesserung ist.}. Ähnlich kann ein gegen libc 2.22 gebundenes Programm die
-meisten, aber nicht alle, Locale-Daten von libc 2.21 lesen (Daten zu
-@code{LC_COLLATE} sind aber zum Beispiel inkompatibel); somit schlagen
-Aufrufe von @code{setlocale} vielleicht fehl, aber das Programm läuft
-weiter.
-Das »Problem« mit Guix ist, dass Nutzer viel Freiheit genießen: Sie können
-wählen, ob und wann sie die Software in ihren Profilen aktualisieren und
-benutzen vielleicht eine andere libc-Version als sie der Systemadministrator
-benutzt hat, um die systemweiten Locale-Daten zu erstellen.
-Glücklicherweise können »unprivilegierte« Nutzer ohne zusätzliche
-Berechtigungen dann zumindest ihre eigenen Locale-Daten installieren und
-@var{GUIX_LOCPATH} entsprechend definieren (siehe @ref{locales-and-locpath,
-@code{GUIX_LOCPATH} und Locale-Pakete}).
-Trotzdem ist es am besten, wenn die systemweiten Locale-Daten unter
-@file{/run/current-system/locale} für alle libc-Versionen erstellt werden,
-die auf dem System noch benutzt werden, damit alle Programme auf sie
-zugreifen können — was auf einem Mehrbenutzersystem ganz besonders wichtig
-ist. Dazu kann der Administrator des Systems mehrere libc-Pakete im
-@code{locale-libcs}-Feld vom @code{operating-system} angeben:
-@example
-(use-package-modules base)
-(operating-system
-  ;; @dots{}
-  (locale-libcs (list glibc-2.21 (canonical-package glibc))))
-@end example
-Mit diesem Beispiel ergäbe sich ein System, was Locale-Definitionen sowohl
-für libc 2.21 als auch die aktuelle Version von libc in
-@file{/run/current-system/locale} hat.
-@node Dienste
-@section Dienste
-@cindex Systemdienste
-Ein wichtiger Bestandteil des Schreibens einer
-@code{operating-system}-Deklaration ist das Auflisten der
-@dfn{Systemdienste} und ihrer Konfiguration (siehe @ref{Das Konfigurationssystem nutzen}). Systemdienste sind typischerweise im Hintergrund
-laufende Daemon-Programme, die beim Hochfahren des Systems gestartet werden,
-oder andere Aktionen, die zu dieser Zeit durchgeführt werden müssen — wie
-das Konfigurieren des Netzwerkzugangs.
-Guix hat eine weit gefasste Definition, was ein »Dienst« ist (siehe
-@ref{Dienstkompositionen}), aber viele Dienste sind solche, die von
-GNU@tie{}Shepherd verwaltet werden (siehe @ref{Shepherd-Dienste}). Auf
-einem laufenden System kann der @command{herd}-Befehl benutzt werden, um
-verfügbare Dienste aufzulisten, ihren Status anzuzeigen, sie zu starten und
-zu stoppen oder andere angebotene Operationen durchzuführen (siehe @ref{Jump
-Start,,, shepherd, The GNU Shepherd Manual}). Zum Beispiel:
-@example
-# herd status
-@end example
-Dieser Befehl, durchgeführt als @code{root}, listet die momentan definierten
-Dienste auf. Der Befehl @command{herd doc} fasst kurz zusammen, was ein
-gegebener Dienst ist und welche Aktionen mit ihm assoziiert sind:
-@example
-# herd doc nscd
-Run libc's name service cache daemon (nscd).
-# herd doc nscd action invalidate
-invalidate: Invalidate the given cache--e.g., 'hosts' for host name lookups.
-@end example
-Die Unterbefehle @command{start}, @command{stop} und @command{restart} haben
-die Wirkung, die man erwarten würde. Zum Beispiel kann mit folgenden
-Befehlen der nscd-Dienst angehalten und der Xorg-Display-Server neu
-gestartet werden:
-@example
-# herd stop nscd
-Service nscd has been stopped.
-# herd restart xorg-server
-Service xorg-server has been stopped.
-Service xorg-server has been started.
-@end example
-Die folgenden Abschnitte dokumentieren die verfügbaren Dienste, die in einer
-@code{operating-system}-Deklaration benutzt werden können, angefangen mit
-den Diensten im Kern des Systems (»core services«)
-@menu
-* Basisdienste::             Essenzielle Systemdienste.
-* Geplante Auftragsausführung::  Der mcron-Dienst.
-* Log-Rotation::             Der rottlog-Dienst.
-* Netzwerkdienste::          Netzwerkeinrichtung, SSH-Daemon etc.
-* X Window::                 Grafische Anzeige.
-* Druckdienste::             Unterstützung für lokale und entfernte 
-                               Drucker.
-* Desktop-Dienste::          D-Bus- und Desktop-Dienste.
-* Tondienste::               Dienste für ALSA und Pulseaudio.
-* Datenbankdienste::         SQL-Datenbanken, Schlüssel-Wert-Speicher etc.
-* Mail-Dienste::             IMAP, POP3, SMTP und so weiter.
-* Kurznachrichtendienste::   Dienste für Kurznachrichten.
-* Telefondienste::           Telefoniedienste.
-* Überwachungsdienste::     Dienste zur Systemüberwachung.
-* Kerberos-Dienste::         Kerberos-Dienste.
-* LDAP-Dienste::             LDAP-Dienste.
-* Web-Dienste::              Web-Server.
-* Zertifikatsdienste::       TLS-Zertifikate via Let’s Encrypt.
-* DNS-Dienste::              DNS-Daemons.
-* VPN-Dienste::              VPN-Daemons.
-* Network File System::      Dienste mit Bezug zum Netzwerkdateisystem.
-* Kontinuierliche Integration::  Der Cuirass-Dienst.
-* Dienste zur Stromverbrauchsverwaltung::  Den Akku schonen.
-* Audio-Dienste::            Der MPD.
-* Virtualisierungsdienste::  Dienste für virtuelle Maschinen.
-* Versionskontrolldienste::  Entfernten Zugang zu Git-Repositorys bieten.
-* Spieldienste::             Spielserver.
-* Verschiedene Dienste::     Andere Dienste.
-@end menu
-@node Basisdienste
-@subsection Basisdienste
-Das Modul @code{(gnu services base)} stellt Definitionen für Basis-Dienste
-zur Verfügung, von denen man erwartet, dass das System sie anbietet. Im
-Folgenden sind die von diesem Modul exportierten Dienste aufgeführt.
-@defvr {Scheme-Variable} %base-services
-Diese Variable enthält eine Liste von Basis-Diensten, die man auf einem
-System vorzufinden erwartet (siehe @ref{Diensttypen und Dienste} für
-weitere Informationen zu Dienstobjekten): ein Anmeldungsdienst (mingetty)
-auf jeder Konsole (jedem »tty«), syslogd, den Name Service Cache Daemon
-(nscd) von libc, die udev-Geräteverwaltung und weitere.
-Dies ist der Vorgabewert für das @code{services}-Feld für die Dienste von
-@code{operating-system}-Deklarationen. Normalerweise werden Sie, wenn Sie
-ein Betriebssystem anpassen, Dienste an die @var{%base-services}-Liste
-anhängen, wie hier gezeigt:
-@example
-(append (list (service avahi-service-type)
-              (service openssh-service-type))
-        %base-services)
-@end example
-@end defvr
-@defvr {Scheme-Variable} special-files-service-type
-Dieser Dienst richtet »besondere Dateien« wie @file{/bin/sh} ein; eine
-Instanz des Dienstes ist Teil der @code{%base-services}.
-Der mit @code{special-files-service-type}-Diensten assoziierte Wert muss
-eine Liste von Tupeln sein, deren erstes Element eine »besondere Datei« und
-deren zweites Element deren Zielpfad ist. Der Vorgabewert ist:
-@cindex @file{/bin/sh}
-@cindex @file{sh}, in @file{/bin}
-@example
-`(("/bin/sh" ,(file-append @var{bash} "/bin/sh")))
-@end example
-@cindex @file{/usr/bin/env}
-@cindex @file{env}, in @file{/usr/bin}
-Wenn Sie zum Beispiel auch @code{/usr/bin/env} zu Ihrem System hinzufügen
-möchten, können Sie den Wert ändern auf:
-@example
-`(("/bin/sh" ,(file-append @var{bash} "/bin/sh"))
-  ("/usr/bin/env" ,(file-append @var{coreutils} "/bin/env")))
-@end example
-Da dieser Dienst Teil der @code{%base-services} ist, können Sie
-@code{modify-services} benutzen, um die Liste besonderer Dateien abzuändern
-(siehe @ref{Service-Referenz, @code{modify-services}}). Die leichte
-Alternative, um eine besondere Datei hinzuzufügen, ist über die Prozedur
-@code{extra-special-file} (siehe unten).
-@end defvr
-@deffn {Scheme-Prozedur} extra-special-file @var{Datei} @var{Ziel}
-Das @var{Ziel} als »besondere Datei« @var{Datei} verwenden.
-Beispielsweise können Sie die folgenden Zeilen in das @code{services}-Feld
-Ihrer Betriebssystemdeklaration einfügen für eine symbolische Verknüpfung
-@file{/usr/bin/env}:
-@example
-(extra-special-file "/usr/bin/env"
-                    (file-append coreutils "/bin/env"))
-@end example
-@end deffn
-@deffn {Scheme-Prozedur} host-name-service @var{Name}
-Liefert einen Dienst, der den Rechnernamen (den »Host«-Namen des Rechners)
-als @var{Name} festlegt.
-@end deffn
-@deffn {Scheme-Prozedur} login-service @var{Konfiguration}
-Liefert einen Dienst, der die Benutzeranmeldung möglich macht. Dazu
-verwendet er die angegebene @var{Konfiguration}, ein
-@code{<login-configuration>}-Objekt, das unter anderem die beim Anmelden
-angezeigte Mitteilung des Tages (englisch »Message of the Day«) festlegt.
-@end deffn
-@deftp {Datentyp} login-configuration
-Dies ist der Datentyp, der die Anmeldekonfiguration repräsentiert.
-@table @asis
-@item @code{motd}
-@cindex Message of the Day
-Ein dateiartiges Objekt, das die »Message of the Day« enthält.
-@item @code{allow-empty-passwords?} (Vorgabe: @code{#t})
-Leere Passwörter standardmäßig zulassen, damit sich neue Anwender anmelden
-können, direkt nachdem das Benutzerkonto »root« für den Administrator
-angelegt wurde.
-@end table
-@end deftp
-@deffn {Scheme-Prozedur} mingetty-service @var{Konfiguration}
-Liefert einen Dienst, der mingetty nach den Vorgaben der @var{Konfiguration}
-ausführt, einem @code{<mingetty-configuration>}-Objekt, das unter anderem
-die Konsole (das »tty«) festlegt, auf der mingetty laufen soll.
-@end deffn
-@deftp {Datentyp} mingetty-configuration
-Dieser Datentyp repräsentiert die Konfiguration von Mingetty, der
-vorgegebenen Implementierung zur Anmeldung auf einer virtuellen Konsole.
-@table @asis
-@item @code{tty}
-Der Name der Konsole, auf der diese Mingetty-Instanz läuft — z.B.@:
-@code{"tty1"}.
-@item @code{auto-login} (Vorgabe: @code{#f})
-Steht dieses Feld auf wahr, muss es eine Zeichenkette sein, die den
-Benutzernamen angibt, als der man vom System automatisch angemeldet
-wird. Ist es @code{#f}, so muss zur Anmeldung ein Benutzername und ein
-Passwort eingegeben werden.
-@item @code{login-program} (Vorgabe: @code{#f})
-Dies muss entweder @code{#f} sein, dann wird das voreingestellte
-Anmeldeprogramm benutzt (@command{login} aus dem Shadow-Werkzeugsatz) oder
-der Name des Anmeldeprogramms als G-Ausdruck.
-@item @code{login-pause?} (Vorgabe: @code{#f})
-Ist es auf @code{#t} gesetzt, sorgt es in Verbindung mit @var{auto-login}
-dafür, dass der Benutzer eine Taste drücken muss, ehe eine Anmelde-Shell
-gestartet wird.
-@item @code{mingetty} (Vorgabe: @var{mingetty})
-Welches Mingetty-Paket benutzt werden soll.
-@end table
-@end deftp
-@deffn {Scheme-Prozedur} agetty-service @var{Konfiguration}
-Liefert einen Dienst, um agetty entsprechend der @var{Konfiguration}
-auszuführen, welche ein @code{<agetty-configuration>}-Objekt sein muss, das
-unter anderem festlegt, auf welchem tty es laufen soll.
-@end deffn
-@deftp {Datentyp} agetty-configuration
-Dies ist der Datentyp, der die Konfiguration von agetty repräsentiert, was
-Anmeldungen auf einer virtuellen oder seriellen Konsole implementiert. Siehe
-die Handbuchseite @code{agetty(8)} für mehr Informationen.
-@table @asis
-@item @code{tty}
-Der Name der Konsole, auf der diese Instanz von agetty läuft, als
-Zeichenkette — z.B.@: @code{"ttyS0"}. Dieses Argument ist optional, sein
-Vorgabewert ist eine vernünftige Wahl unter den seriellen Schnittstellen,
-auf deren Benutzung der Linux-Kernel eingestellt ist.
-Hierzu wird, wenn in der Kernel-Befehlszeile ein Wert für eine Option namens
-@code{agetty.tty} festgelegt wurde, der Gerätename daraus für agetty
-extrahiert und benutzt.
-Andernfalls wird agetty, falls auf der Kernel-Befehlszeile eine Option
-@code{console} mit einem tty vorkommt, den daraus extrahierten Gerätenamen
-der seriellen Schnittstelle benutzen.
-In beiden Fällen wird agetty nichts an den anderen Einstellungen für
-serielle Geräte verändern (Baud-Rate etc.), in der Hoffnung, dass Linux sie
-auf die korrekten Werte festgelegt hat.
-@item @code{baud-rate} (Vorgabe: @code{#f})
-Eine Zeichenkette, die aus einer kommagetrennten Liste von einer oder
-mehreren Baud-Raten besteht, absteigend sortiert.
-@item @code{term} (Vorgabe: @code{#f})
-Eine Zeichenkette, die den Wert enthält, der für die Umgebungsvariable
-@code{TERM} benutzt werden soll.
-@item @code{eight-bits?} (Vorgabe: @code{#f})
-Steht dies auf @code{#t}, wird angenommen, dass das tty 8-Bit-korrekt ist,
-so dass die Paritätserkennung abgeschaltet wird.
-@item @code{auto-login} (Vorgabe: @code{#f})
-Wird hier ein Anmeldename als eine Zeichenkette übergeben, wird der
-angegebene Nutzer automatisch angemeldet, ohne nach einem Anmeldenamen oder
-Passwort zu fragen.
-@item @code{no-reset?} (Vorgabe: @code{#f})
-Steht dies auf @code{#t}, werden die Cflags des Terminals (d.h.@: dessen
-Steuermodi) nicht zurückgesetzt.
-@item @code{host} (Vorgabe: @code{#f})
-Dies akzeptiert eine Zeichenkette mit dem einzutragenden
-Anmeldungs-Rechnernamen "login_host", der in die Datei @file{/var/run/utmpx}
-geschrieben wird.
-@item @code{remote?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird in Verbindung mit @var{host} eine
-Befehlszeilenoption @code{-r} für einen falschen Rechnernamen (»Fakehost«)
-in der Befehlszeile des mit @var{login-program} angegebenen Anmeldeprogramms
-übergeben.
-@item @code{flow-control?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird Hardware-Flusssteuerung (RTS/CTS)
-aktiviert.
-@item @code{no-issue?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird der Inhalt der Datei @file{/etc/issue}
-@emph{nicht} angezeigt, bevor die Anmeldeaufforderung zu sehen ist.
-@item @code{init-string} (Vorgabe: @code{#f})
-Dies akzeptiert eine Zeichenkette, die zum tty oder zum Modem zuerst vor
-allem anderen gesendet wird. Es kann benutzt werden, um ein Modem zu
-initialisieren.
-@item @code{no-clear?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird agetty den Bildschirm @emph{nicht}
-löschen, bevor es die Anmeldeaufforderung anzeigt.
-@item @code{login-program} (Vorgabe: (file-append shadow "/bin/login"))
-Hier muss entweder ein G-Ausdruck mit dem Namen eines Anmeldeprogramms
-übergeben werden, oder dieses Feld wird nicht gesetzt, so dass als
-Vorgabewert das Programm @command{login} aus dem Shadow-Werkzeugsatz
-verwendet wird.
-@item @code{local-line} (Vorgabe: @code{#f})
-Steuert den Leitungsschalter CLOCAL. Hierfür wird eines von drei Symbolen
-als Argument akzeptiert, @code{'auto}, @code{'always} oder
-@code{'never}. Für @code{#f} wählt agetty als Vorgabewert @code{'auto}.
-@item @code{extract-baud?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, so wird agetty angewiesen, die Baud-Rate aus
-den Statusmeldungen mancher Arten von Modem abzulesen.
-@item @code{skip-login?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird der Benutzer nicht aufgefordert, einen
-Anmeldenamen einzugeben. Dies kann zusammen mit dem @var{login-program}-Feld
-benutzt werden, um nicht standardkonforme Anmeldesysteme zu benutzen.
-@item @code{no-newline?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird @emph{kein} Zeilenumbruch ausgegeben,
-bevor die Datei @file{/etc/issue} ausgegeben wird.
-@c Is this dangerous only when used with login-program, or always?
-@item @code{login-options} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine Zeichenkette mit den Befehlszeilenoptionen für
-das Anmeldeprogramm. Beachten Sie, dass bei einem selbst gewählten
-@var{login-program} ein böswilliger Nutzer versuchen könnte, als
-Anmeldenamen etwas mit eingebetteten Befehlszeilenoptionen anzugeben, die
-vom Anmeldeprogramm interpretiert werden könnten.
-@item @code{login-pause} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird auf das Drücken einer beliebigen Taste
-gewartet, bevor die Anmeldeaufforderung angezeigt wird. Hiermit kann in
-Verbindung mit @var{auto-login} weniger Speicher verbraucht werden, indem
-man Shells erst erzeugt, wenn sie benötigt werden.
-@item @code{chroot} (Vorgabe: @code{#f})
-Wechselt die Wurzel des Dateisystems auf das angegebene Verzeichnis. Dieses
-Feld akzeptiert einen Verzeichnispfad als Zeichenkette.
-@item @code{hangup?} (Vorgabe: @code{#f})
-Mit dem Linux-Systemaufruf @code{vhangup} auf dem angegebenen Terminal
-virtuell auflegen.
-@item @code{keep-baud?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird versucht, die bestehende Baud-Rate
-beizubehalten. Die Baud-Raten aus dem Feld @var{baud-rate} werden benutzt,
-wenn agetty ein @key{BREAK}-Zeichen empfängt.
-@item @code{timeout} (Vorgabe: @code{#f})
-Ist dies auf einen ganzzahligen Wert gesetzt, wird terminiert, falls kein
-Benutzername innerhalb von @var{timeout} Sekunden eingelesen werden konnte.
-@item @code{detect-case?} (Vorgabe: @code{#f})
-Ist dies auf @code{#t} gesetzt, wird Unterstützung für die Erkennung von
-Terminals aktiviert, die nur Großschreibung beherrschen. Mit dieser
-Einstellung wird, wenn ein Anmeldename nur aus Großbuchstaben besteht,
-dieser als Anzeichen dafür aufgefasst, dass das Terminal nur Großbuchstaben
-beherrscht, und einige Umwandlungen von Groß- in Kleinbuchstaben
-aktiviert. Beachten Sie, dass dabei @emph{keine} Unicode-Zeichen unterstützt
-werden.
-@item @code{wait-cr?} (Vorgabe: @code{#f})
-Wenn dies auf @code{#t} gesetzt ist, wird gewartet, bis der Benutzer oder
-das Modem einen Wagenrücklauf (»Carriage Return«) oder einen Zeilenvorschub
-(»Linefeed«) absendet, ehe @file{/etc/issue} oder eine Anmeldeaufforderung
-angezeigt wird. Dies wird typischerweise zusammen mit dem Feld
-@var{init-string} benutzt.
-@item @code{no-hints?} (Vorgabe: @code{#f})
-Ist es auf @code{#t} gesetzt, werden @emph{keine} Hinweise zu den
-Feststelltasten Num-Taste, Umschaltsperre (»Caps Lock«) und Rollen-Taste
-(»Scroll Lock«) angezeigt.
-@item @code{no-hostname?} (Vorgabe: @code{#f})
-Das vorgegebene Verhalten ist, den Rechnernamen auszugeben. Ist dieses Feld
-auf @code{#t} gesetzt, wird überhaupt kein Rechnername angezeigt.
-@item @code{long-hostname?} (Vorgabe: @code{#f})
-Das vorgegebene Verhalten ist, den Rechnernamen nur bis zu seinem ersten
-Punkt anzuzeigen. Ist dieses Feld auf @code{#t} gesetzt, wird der
-vollständige Rechnername (der »Fully Qualified Hostname«), wie ihn
-@code{gethostname} oder @code{getaddrinfo} liefern, angezeigt.
-@item @code{erase-characters} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine Zeichenkette aus Zeichen, die auch als Rücktaste
-(zum Löschen) interpretiert werden sollen, wenn der Benutzer seinen
-Anmeldenamen eintippt.
-@item @code{kill-characters} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine Zeichenkette aus Zeichen, deren Eingabe als
-»ignoriere alle vorherigen Zeichen« interpretiert werden soll (auch
-»kill«-Zeichen genannt), wenn der Benutzer seinen Anmeldenamen eintippt.
-@item @code{chdir} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine Zeichenkette, die einen Verzeichnispfad angibt,
-zu dem vor der Anmeldung gewechselt wird.
-@item @code{delay} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine ganze Zahl mit der Anzahl Sekunden, die gewartet
-werden soll, bis ein tty geöffnet und die Anmeldeaufforderung angezeigt
-wird.
-@item @code{nice} (Vorgabe: @code{#f})
-Dieses Feld akzeptiert eine ganze Zahl mit dem »nice«-Wert, mit dem das
-Anmeldeprogramm ausgeführt werden soll.
-@item @code{extra-options} (Vorgabe: @code{'()})
-Dieses Feld ist ein »Notausstieg«, mit dem Nutzer beliebige
-Befehlszeilenoptionen direkt an @command{agetty} übergeben können. Diese
-müssen hier als eine Liste von Zeichenketten angegeben werden.
-@end table
-@end deftp
-@deffn {Scheme-Prozedur} kmscon-service-type @var{Konfiguration}
-Liefert einen Dienst, um
-@uref{https://www.freedesktop.org/wiki/Software/kmscon,kmscon} entsprechend
-der @var{Konfiguration} auszuführen. Diese ist ein
-@code{<kmscon-configuration>}-Objekt, das unter anderem angibt, auf welchem
-tty es ausgeführt werden soll.
-@end deffn
-@deftp {Datentyp} kmscon-configuration
-Dieser Datentyp repräsentiert die Konfiguration von Kmscon, die das Anmelden
-auf virtuellen Konsolen ermöglicht.
-@table @asis
-@item @code{virtual-terminal}
-Der Name der Konsole, auf der diese Kmscon läuft — z.B.@: @code{"tty1"}.
-@item @code{login-program} (Vorgabe: @code{#~(string-append #$shadow "/bin/login")})
-Ein G-Ausdruck, der den Namen des Anmeldeprogramms angibt. Als Vorgabe wird
-das Anmeldeprogramm @command{login} aus dem Shadow-Werkzeugsatz verwendet.
-@item @code{login-arguments} (Vorgabe: @code{'("-p")})
-Eine Liste der Argumente, die an @command{login} übergeben werden sollen.
-@item @code{auto-login} (Vorgabe: @code{#f})
-Wird hier ein Anmeldename als eine Zeichenkette übergeben, wird der
-angegebene Nutzer automatisch angemeldet, ohne nach einem Anmeldenamen oder
-Passwort zu fragen.
-@item @code{hardware-acceleration?} (Vorgabe: #f)
-Ob Hardware-Beschleunigung verwendet werden soll.
-@item @code{kmscon} (Vorgabe: @var{kmscon})
-Das Kmscon-Paket, das benutzt werden soll.
-@end table
-@end deftp
-@cindex Name Service Cache Daemon
-@cindex nscd
-@deffn {Scheme-Prozedur} nscd-service [@var{Konfiguration}] [#:glibc glibc] @
-                [#:name-services '()] Liefert einen Dienst, der den Name Service Cache
-Daemon (nscd) von libc mit der angegebenen @var{Konfiguration} ausführt —
-diese muss ein @code{<nscd-configuration>}-Objekt sein. Siehe @ref{Name Service Switch} für ein Beispiel.
-Der Einfachheit halber bietet der Shepherd-Dienst für nscd die folgenden
-Aktionen an:
-@table @code
-@item invalidate
-@cindex Zwischenspeicher ungültig machen, nscd
-@cindex nscd, Ungültigmachen des Zwischenspeichers
-Dies macht den angegebenen Zwischenspeicher ungültig. Wenn Sie zum Beispiel:
-@example
-herd invalidate nscd hosts
-@end example
-@noindent
-ausführen, wird der Zwischenspeicher für die Auflösung von Rechnernamen (von
-»Host«-Namen) des nscd ungültig.
-@item statistics
-Wenn Sie @command{herd statistics nscd} ausführen, werden Ihnen
-Informationen angezeigt, welche Ihnen Informationen über den nscd-Zustand
-und die Zwischenspeicher angezeigt.
-@end table
-@end deffn
-@defvr {Scheme-Variable} %nscd-default-configuration
-Dies ist der vorgegebene Wert für die @code{<nscd-configuration>} (siehe
-unten), die @code{nscd-service} benutzt. Die Konfiguration benutzt die
-Zwischenspeicher, die in @var{%nscd-default-caches} definiert sind; siehe
-unten.
-@end defvr
-@deftp {Datentyp} nscd-configuration
-Dieser Datentyp repräsentiert die Konfiguration des Name Service Caching
-Daemon (kurz »nscd«).
-@table @asis
-@item @code{name-services} (Vorgabe: @code{'()})
-Liste von Paketen, die @dfn{Namensdienste} bezeichnen, die für den nscd
-sichtbar sein müssen, z.B.@: @code{(list @var{nss-mdns})}.
-@item @code{glibc} (Vorgabe: @var{glibc})
-Ein Paket-Objekt, das die GNU-C-Bibliothek angibt, woraus der
-@command{nscd}-Befehl genommen werden soll.
-@item @code{log-file} (Vorgabe: @code{"/var/log/nscd.log"})
-Name der nscd-Protokolldatei. Hierhin werden Ausgaben zur Fehlersuche
-geschrieben, falls @code{debug-level} echt positiv ist.
-@item @code{debug-level} (Vorgabe: @code{0})
-Eine ganze Zahl, die den Detailgrad der Ausgabe zur Fehlersuche
-angibt. Größere Zahlen bewirken eine ausführlichere Ausgabe.
-@item @code{caches} (Vorgabe: @var{%nscd-default-caches})
-Liste der @code{<nscd-cache>}-Objekte, die repräsentieren, was alles
-zwischengespeichert werden soll; siehe unten.
-@end table
-@end deftp
-@deftp {Datentyp} nscd-cache
-Ein Datentyp, der eine Zwischenspeicher-Datenbank von nscd mitsamt ihren
-Parametern definiert.
-@table @asis
-@item @code{Datenbank}
-Dies ist ein Symbol, was den Namen der Datenbank repräsentiert, die
-zwischengespeichert werden soll. Gültige Werte sind @code{passwd},
-@code{group}, @code{hosts} und @code{services}, womit jeweils die
-entsprechende NSS-Datenbank bezeichnet wird (siehe @ref{NSS Basics,,, libc,
-The GNU C Library Reference Manual}).
-@item @code{positive-time-to-live}
-@itemx @code{negative-time-to-live} (Vorgabe: @code{20})
-Eine Zahl, die für die Anzahl an Sekunden steht, die ein erfolgreiches
-(positives) oder erfolgloses (negatives) Nachschlageresultat im
-Zwischenspeicher verbleibt.
-@item @code{check-files?} (Vorgabe: @code{#t})
-Ob auf Änderungen an den der @var{database} entsprechenden Dateien reagiert
-werden soll.
-Wenn @var{database} zum Beispiel @code{hosts} ist, wird, wenn dieses Feld
-gesetzt ist, nscd Änderungen an @file{/etc/hosts} beobachten und
-berücksichtigen.
-@item @code{persistent?} (Vorgabe: @code{#t})
-Ob der Zwischenspeicher dauerhaft auf der Platte gespeichert werden soll.
-@item @code{shared?} (Vorgabe: @code{#t})
-Ob der Zwischenspeicher zwischen den Nutzern geteilt werden soll.
-@item @code{max-database-size} (Vorgabe: 32@tie{}MiB)
-Die Maximalgröße des Datenbank-Zwischenspeichers in Bytes.
-@c XXX: 'suggested-size' and 'auto-propagate?' seem to be expert
-@c settings, so leave them out.
-@end table
-@end deftp
-@defvr {Scheme-Variable} %nscd-default-caches
-Liste von @code{<nscd-cache>}-Objekten, die von der vorgegebenen
-@code{nscd-configuration} benutzt werden (siehe oben).
-Damit wird dauerhaftes und aggressives Zwischenspeichern beim Nachschlagen
-von Dienst- und Rechnernamen (»Host«-Namen) aktiviert. Letzteres verbessert
-die Leistungsfähigkeit beim Nachschlagen von Rechnernamen, sorgt für mehr
-Widerstandsfähigkeit gegenüber unverlässlichen Namens-Servern und bietet
-außerdem einen besseren Schutz der Privatsphäre — oftmals befindet sich das
-Ergebnis einer Anfrage nach einem Rechnernamen bereits im lokalen
-Zwischenspeicher und externe Namens-Server müssen nicht miteinbezogen
-werden.
-@end defvr
-@anchor{syslog-configuration-type}
-@cindex syslog
-@cindex Protokollierung
-@deftp {Datentyp} syslog-configuration
-Dieser Datentyp repräsentiert die Konfiguration des syslog-Daemons.
-@table @asis
-@item @code{syslogd} (Vorgabe: @code{#~(string-append #$inetutils "/libexec/syslogd")})
-Welcher Syslog-Daemon benutzt werden soll.
-@item @code{config-file} (Vorgabe: @code{%default-syslog.conf})
-Die zu benutzende syslog-Konfigurationsdatei.
-@end table
-@end deftp
-@anchor{syslog-service}
-@cindex syslog
-@deffn {Scheme-Prozedur} syslog-service @var{Konfiguration}
-Liefert einen Dienst, der einen syslog-Daemon entsprechend der
-@var{Konfiguration} ausführt.
-Siehe @ref{syslogd invocation,,, inetutils, GNU Inetutils} für weitere
-Informationen über die Syntax der Konfiguration.
-@end deffn
-@defvr {Scheme-Variable} guix-service-type
-Dies ist der Typ für den Dienst, der den Erstellungs-Daemon
-@command{guix-daemon} ausführt (siehe @ref{Aufruf des guix-daemon}). Als Wert
-muss ein @code{guix-configuration}-Verbundsobjekt verwendet werden, wie
-unten beschrieben.
-@end defvr
-@anchor{guix-configuration-type}
-@deftp {Datentyp} guix-configuration
-Dieser Datentyp repräsentiert die Konfiguration des Erstellungs-Daemons von
-Guix. Siehe @ref{Aufruf des guix-daemon} für weitere Informationen.
-@table @asis
-@item @code{guix} (Vorgabe: @var{guix})
-Das zu verwendende Guix-Paket.
-@item @code{build-group} (Vorgabe: @code{"guixbuild"})
-Der Name der Gruppe, zu der die Erstellungs-Benutzerkonten gehören.
-@item @code{build-accounts} (Vorgabe: @code{10})
-Die Anzahl zu erzeugender Erstellungs-Benutzerkonten.
-@item @code{authorize-key?} (Vorgabe: @code{#t})
-@cindex Substitute, deren Autorisierung
-Ob die unter @code{authorized-keys} aufgelisteten Substitutschlüssel
-autorisiert werden sollen — vorgegeben ist, den von
-@code{@value{SUBSTITUTE-SERVER}} zu autorisieren (siehe @ref{Substitute}).
-@vindex %default-authorized-guix-keys
-@item @code{authorized-keys} (Vorgabe: @var{%default-authorized-guix-keys})
-Die Liste der Dateien mit autorisierten Schlüsseln, d.h.@: eine Liste von
-Zeichenketten als G-Ausdrücke (siehe @ref{Aufruf von guix archive}). Der
-vorgegebene Inhalt ist der Schlüssel von @code{@value{SUBSTITUTE-SERVER}}
-(siehe @ref{Substitute}).
-@item @code{use-substitutes?} (Vorgabe: @code{#t})
-Ob Substitute benutzt werden sollen.
-@item @code{substitute-urls} (Vorgabe: @var{%default-substitute-urls})
-Die Liste der URLs, auf denen nach Substituten gesucht wird, wenn nicht
-anders angegeben.
-@item @code{max-silent-time} (Vorgabe: @code{0})
-@itemx @code{timeout} (Vorgabe: @code{0})
-Die Anzahl an Sekunden, die jeweils nichts in die Ausgabe geschrieben werden
-darf bzw. die es insgesamt dauern darf, bis ein Erstellungsprozess
-abgebrochen wird. Beim Wert null wird nie abgebrochen.
-@item @code{log-compression} (Vorgabe: @code{'bzip2})
-Die für Erstellungsprotokolle zu benutzende Kompressionsmethode — entweder
-@code{gzip}, @code{bzip2} oder @code{none}.
-@item @code{extra-options} (Vorgabe: @code{'()})
-Eine Liste zusätzlicher Befehlszeilenoptionen zu @command{guix-daemon}.
-@item @code{log-file} (Vorgabe: @code{"/var/log/guix-daemon.log"})
-Die Datei, in die die Standardausgabe und die Standardfehlerausgabe von
-@command{guix-daemon} geschrieben werden.
-@item @code{http-proxy} (Vorgabe: @code{#f})
-Der für das Herunterladen von Ableitungen mit fester Ausgabe und von
-Substituten zu verwendende HTTP-Proxy.
-@item @code{tmpdir} (Vorgabe: @code{#f})
-Ein Verzeichnispfad, der angibt, wo @command{guix-daemon} seine Erstellungen
-durchführt.
-@end table
-@end deftp
-@deffn {Scheme-Prozedur} udev-service [#:udev @var{eudev} #:rules @code{'()}]
-Führt @var{udev} aus, was zur Laufzeit Gerätedateien ins Verzeichnis
-@file{/dev} einfügt. udev-Regeln können über die @var{rules}-Variable als
-eine Liste von Dateien übergeben werden. Die Prozeduren @var{udev-rule} und
-@var{file->udev-rule} aus @code{(gnu services base)} vereinfachen die
-Erstellung einer solchen Regeldatei.
-@end deffn
-@deffn {Scheme-Prozedur} udev-rule [@var{Dateiname} @var{Inhalt}]
-Liefert eine udev-Regeldatei mit dem angegebenen @var{Dateiname}n, in der
-die vom Literal @var{Inhalt} definierten Regeln stehen.
-Im folgenden Beispiel wird eine Regel für ein USB-Gerät definiert und in der
-Datei @file{90-usb-ding.rules} gespeichert. Mit der Regel wird ein Skript
-ausgeführt, sobald ein USB-Gerät mit der angegebenen Produktkennung erkannt
-wird.
-@example
-(define %beispiel-udev-rule
-  (udev-rule
-    "90-usb-ding.rules"
-    (string-append "ACTION==\"add\", SUBSYSTEM==\"usb\", "
-                   "ATTR@{product@}==\"Beispiel\", "
-                   "RUN+=\"/pfad/zum/skript\"")))
-@end example
-The @command{herd rules udev} command, as root, returns the name of the
-directory containing all the active udev rules.
-@end deffn
-Hier zeigen wir, wie man den vorgegebenen @var{udev-service} um sie
-erweitern kann.
-@example
-(operating-system
- ;; @dots{}
- (services
- (modify-services %desktop-services
-   (udev-service-type config =>
-     (udev-configuration (inherit config)
-      (rules (append (udev-configuration-rules config)
-                     (list %beispiel-udev-rule))))))))
-@end example
-@deffn {Scheme-Prozedur} file->udev-rule [@var{Dateiname} @var{Datei}]
-Liefert eine udev-Datei mit dem angegebenen @var{Dateiname}n, in der alle in
-der @var{Datei}, einem dateiartigen Objekt, definierten Regeln stehen.
-Folgendes Beispiel stellt dar, wie wir eine bestehende Regeldatei verwenden
-können.
-@example
-(use-modules (guix download)     ;für url-fetch
-             (guix packages)     ;für origin
-             ;; @dots{})
-(define %android-udev-rules
-  (file->udev-rule
-    "51-android-udev.rules"
-    (let ((version "20170910"))
-      (origin
-       (method url-fetch)
-       (uri (string-append "https://raw.githubusercontent.com/M0Rf30/"
-                           "android-udev-rules/" version "/51-android.rules"))
-       (sha256
-        (base32 "0lmmagpyb6xsq6zcr2w1cyx9qmjqmajkvrdbhjx32gqf1d9is003"))))))
-@end example
-@end deffn
-Zusätzlich können Guix-Paketdefinitionen unter den @var{rules} aufgeführt
-werden, um die udev-Regeln um diejenigen Definitionen zu ergänzen, die im
-Unterverzeichnis @file{lib/udev/rules.d} des jeweiligen Pakets aufgeführt
-sind. Statt des bisherigen Beispiels zu @var{file->udev-rule} hätten wir
-also auch das Paket @var{android-udev-rules} benutzen können, das in Guix im
-Modul @code{(gnu packages android)} vorhanden ist.
-Das folgende Beispiel zeit, wie dieses Paket @var{android-udev-rules}
-benutzt werden kann, damit das »Android-Tool« @command{adb} Geräte erkennen
-kann, ohne dafür Administratorrechte vorauszusetzen. Man sieht hier auch,
-wie die Benutzergruppe @code{adbusers} erstellt werden kann, die existieren
-muss, damit die im Paket @var{android-udev-rules} definierten Regeln richtig
-funktionieren. Um so eine Benutzergruppe zu erzeugen, müssen wir sie sowohl
-unter den @var{supplementary-groups} unserer @var{user-account}-Deklaration
-aufführen, als auch sie im @var{groups}-Feld des
-@var{operating-system}-Verbundsobjekts aufführen.
-@example
-(use-modules (gnu packages android)  ;für android-udev-rules
-             (gnu system shadow)     ;für user-group
-             ;; @dots{})
-(operating-system
-  ;; @dots{}
-  (users (cons (user-acount
-                ;; @dots{}
-                (supplementary-groups
-                 '("adbusers"   ;für adb
-                   "wheel" "netdev" "audio" "video"))
-                ;; @dots{})))
-  (groups (cons (user-group (system? #t) (name "adbusers"))
-                %base-groups))
-  ;; @dots{}
-  (services
-   (modify-services %desktop-services
-     (udev-service-type
-      config =>
-      (udev-configuration (inherit config)
-                          (rules (cons android-udev-rules
-                                       (udev-configuration-rules config))))))))
-@end example
-@defvr {Scheme-Variable} urandom-seed-service-type
-Etwas Entropie in der Datei @var{%random-seed-file} aufsparen, die als
-Startwert (als sogenannter »Seed«) für @file{/dev/urandom} dienen kann,
-nachdem das System neu gestartet wurde. Es wird auch versucht,
-@file{/dev/urandom} beim Hochfahren mit Werten aus @file{/dev/hwrng} zu
-starten, falls @file{/dev/hwrng} existiert und lesbar ist.
-@end defvr
-@defvr {Scheme-Variable} %random-seed-file
-Der Name der Datei, in der einige zufällige Bytes vom
-@var{urandom-seed-service} abgespeichert werden, um sie nach einem Neustart
-von dort als Startwert für @file{/dev/urandom} auslesen zu können. Als
-Vorgabe wird @file{/var/lib/random-seed} verwendet.
-@end defvr
-@cindex Maus
-@cindex gpm
-@defvr {Scheme-Variable} gpm-service-type
-Dieser Typ wird für den Dienst verwendet, der GPM ausführt, den
-@dfn{General-Purpose Mouse Daemon}, welcher zur Linux-Konsole
-Mausunterstützung hinzufügt. GPM ermöglicht es seinen Benutzern, auch in der
-Konsole die Maus zu benutzen und damit etwa Text auszuwählen, zu kopieren
-und einzufügen.
-Der Wert für Dienste dieses Typs muss eine @code{gpm-configuration} sein
-(siehe unten). Dieser Dienst gehört @emph{nicht} zu den
-@var{%base-services}.
-@end defvr
-@deftp {Datentyp} gpm-configuration
-Repräsentiert die Konfiguration von GPM.
-@table @asis
-@item @code{options} (Vorgabe: @code{%default-gpm-options})
-Befehlszeilenoptionen, die an @command{gpm} übergeben werden. Die
-vorgegebenen Optionen weisen @command{gpm} an, auf Maus-Ereignisse auf der
-Datei @file{/dev/input/mice} zu lauschen. Siehe @ref{Command Line,,, gpm,
-gpm manual} für weitere Informationen.
-@item @code{gpm} (Vorgabe: @code{gpm})
-Das GPM-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@anchor{guix-publish-service-type}
-@deffn {Scheme-Variable} guix-publish-service-type
-Dies ist der Diensttyp für @command{guix publish} (siehe @ref{Aufruf von guix publish}). Sein Wert muss ein @code{guix-publish-configuration}-Objekt sein,
-wie im Folgenden beschrieben.
-Hierbei wird angenommen, dass @file{/etc/guix} bereits ein mit @command{guix
-archive --generate-key} erzeugtes Schlüsselpaar zum Signieren enthält (siehe
-@ref{Aufruf von guix archive}). Falls nicht, wird der Dienst beim Starten
-fehlschlagen.
-@end deffn
-@deftp {Datentyp} guix-publish-configuration
-Der Datentyp, der die Konfiguration des »@code{guix publish}«-Dienstes
-repräsentiert.
-@table @asis
-@item @code{guix} (Vorgabe: @code{guix})
-Das zu verwendende Guix-Paket.
-@item @code{port} (Vorgabe: @code{80})
-Der TCP-Port, auf dem auf Verbindungen gelauscht werden soll.
-@item @code{host} (Vorgabe: @code{"localhost"})
-Unter welcher Rechneradresse (welchem »Host«, also welcher
-Netzwerkschnittstelle) auf Verbindungen gelauscht wird. Benutzen Sie
-@code{"0.0.0.0"}, wenn auf allen verfügbaren Netzwerkschnittstellen
-gelauscht werden soll.
-@item @code{compression-level} (Vorgabe: @code{3})
-Die gzip-Kompressionsstufe, mit der Substitute komprimiert werden
-sollen. Benutzen Sie @code{0}, um Kompression völlig abzuschalten, und
-@code{9} für das höchste Kompressionsverhältnis, zu Lasten von zusätzlicher
-Prozessorauslastung.
-@item @code{nar-path} (Vorgabe: @code{"nar"})
-Der URL-Pfad, unter dem »Nars« zum Herunterladen angeboten werden. Siehe
-@ref{Aufruf von guix publish, @code{--nar-path}} für Details.
-@item @code{cache} (Vorgabe: @code{#f})
-Wenn dies @code{#f} ist, werden Archive nicht zwischengespeichert, sondern
-erst bei einer Anfrage erzeugt. Andernfalls sollte dies der Name eines
-Verzeichnisses sein — z.B.@: @code{"/var/cache/guix/publish"} —, in das
-@command{guix publish} fertige Archive und Metadaten zwischenspeichern
-soll. Siehe @ref{Aufruf von guix publish, @option{--cache}} für weitere
-Informationen über die jeweiligen Vor- und Nachteile.
-@item @code{workers} (Vorgabe: @code{#f})
-Ist dies eine ganze Zahl, gibt es die Anzahl der Worker-Threads an, die zum
-Zwischenspeichern benutzt werden; ist es @code{#f}, werden so viele benutzt,
-wie es Prozessoren gibt. Siehe @ref{Aufruf von guix publish,
-@option{--workers}} für mehr Informationen.
-@item @code{ttl} (Vorgabe: @code{#f})
-Wenn dies eine ganze Zahl ist, bezeichnet sie die @dfn{Time-to-live} als die
-Anzahl der Sekunden, die heruntergeladene veröffentlichte Archive
-zwischengespeichert werden dürfen. Siehe @ref{Aufruf von guix publish,
-@option{--ttl}} für mehr Informationen.
-@end table
-@end deftp
-@anchor{rngd-service}
-@deffn {Scheme-Prozedur} rngd-service [#:rng-tools @var{rng-tools}] @
-            [#:device "/dev/hwrng"] Liefert einen Dienst, der das
-@command{rngd}-Programm aus den @var{rng-tools} benutzt, um das mit
-@var{device} bezeichnete Gerät zum Entropie-Pool des Kernels
-hinzuzufügen. Dieser Dienst wird fehlschlagen, falls das mit @var{device}
-bezeichnete Gerät nicht existiert.
-@end deffn
-@anchor{pam-limits-service}
-@cindex Sitzungs-Limits
-@cindex ulimit
-@cindex Priorität
-@cindex Echtzeit
-@cindex jackd
-@deffn {Scheme-Prozedur} pam-limits-service [#:limits @code{'()}]
-Liefert einen Dienst, der eine Konfigurationsdatei für das
-@uref{http://linux-pam.org/Linux-PAM-html/sag-pam_limits.html,
-@code{pam_limits}-Modul} installiert. Diese Prozedur nimmt optional eine
-Liste von @code{pam-limits-entry}-Werten entgegen, die benutzt werden
-können, um @code{ulimit}-Limits und nice-Prioritäten für Benutzersitzungen
-festzulegen.
-Die folgenden Limit-Definitionen setzen zwei harte und weiche Limits für
-alle Anmeldesitzungen für Benutzer in der @code{realtime}-Gruppe.
-@example
-(pam-limits-service
- (list
-  (pam-limits-entry "@@realtime" 'both 'rtprio 99)
-  (pam-limits-entry "@@realtime" 'both 'memlock 'unlimited)))
-@end example
-Der erste Eintrag erhöht die maximale Echtzeit-Priorität für unprivilegierte
-Prozesse ohne zusätzliche Berechtigungen; der zweite Eintrag hebt jegliche
-Einschränkungen des maximalen Adressbereichs auf, der im Speicher reserviert
-werden darf. Diese Einstellungen werden in dieser Form oft für
-Echtzeit-Audio-Systeme verwendet.
-@end deffn
-@node Geplante Auftragsausführung
-@subsection Geplante Auftragsausführung
-@cindex cron
-@cindex mcron
-@cindex Planen von Aufträgen
-Das Modul @code{(gnu services mcron)} enthält eine Schnittstelle zu
-GNU@tie{}mcron, einem Daemon, der gemäß einem vorher festgelegten Zeitplan
-Aufträge (sogenannte »Jobs«) ausführt (siehe @ref{Top,,, mcron,
-GNU@tie{}mcron}). GNU@tie{}mcron ist ähnlich zum traditionellen
-@command{cron}-Daemon aus Unix; der größte Unterschied ist, dass mcron in
-Guile Scheme implementiert ist, wodurch einem viel Flexibilität bei der
-Spezifikation von Aufträgen und ihren Aktionen offen steht.
-Das folgende Beispiel definiert ein Betriebssystem, das täglich die Befehle
-@command{updatedb} (siehe @ref{Invoking updatedb,,, find, Finding Files})
-und @command{guix gc} (siehe @ref{Aufruf von guix gc}) ausführt sowie den
-Befehl @command{mkid} im Namen eines »unprivilegierten« Nutzers ohne
-besondere Berechtigungen laufen lässt (siehe @ref{mkid invocation,,,
-idutils, ID Database Utilities}). Zum Anlegen von Auftragsdefinitionen
-benutzt es G-Ausdrücke, die dann an mcron übergeben werden (siehe
-@ref{G-Ausdrücke}).
-@lisp
-(use-modules (guix) (gnu) (gnu services mcron))
-(use-package-modules base idutils)
-(define updatedb-job
-  ;; 'updatedb' jeden Tag um 3 Uhr morgens ausführen. Hier schreiben wir
-  ;; die vom Auftrag durchzuführende Aktion als eine Scheme-Prozedur.
-  #~(job '(next-hour '(3))
-         (lambda ()
-           (execl (string-append #$findutils "/bin/updatedb")
-                  "updatedb"
-                  "--prunepaths=/tmp /var/tmp /gnu/store"))))
-(define garbage-collector-job
-  ;; Jeden Tag 5 Minuten nach Mitternacht Müll sammeln gehen.
-  ;; Die Aktions des Auftrags ist ein Shell-Befehl.
-  #~(job "5 0 * * *"            ;Vixie-cron-Syntax
-         "guix gc -F 1G"))
-(define idutils-job
-  ;; Die Index-Datenbank des Benutzers "charlie" um 12:15 Uhr und
-  ;; 19:15 Uhr aktualisieren. Dies wird aus seinem Persönlichen
-  ;; Ordner heraus ausgeführt.
-  #~(job '(next-minute-from (next-hour '(12 19)) '(15))
-         (string-append #$idutils "/bin/mkid src")
-         #:user "charlie"))
-(operating-system
-  ;; @dots{}
-  (services (cons (service mcron-service-type
-                           (mcron-configuration
-                            (jobs (list garbage-collector-job
-                                        updatedb-job
-                                        idutils-job))))
-                  %base-services)))
-@end lisp
-Siehe @ref{Guile Syntax, mcron job specifications,, mcron, GNU@tie{}mcron}
-für weitere Informationen zu mcron-Auftragsspezifikationen. Nun folgt die
-Referenz des mcron-Dienstes.
-On a running system, you can use the @code{schedule} action of the service
-to visualize the mcron jobs that will be executed next:
-@example
-# herd schedule mcron
-@end example
-@noindent
-The example above lists the next five tasks that will be executed, but you
-can also specify the number of tasks to display:
-@example
-# herd schedule mcron 10
-@end example
-@defvr {Scheme Variable} mcron-service-type
-This is the type of the @code{mcron} service, whose value is an
-@code{mcron-configuration} object.
-This service type can be the target of a service extension that provides it
-additional job specifications (@pxref{Dienstkompositionen}).  In other
-words, it is possible to define services that provide additional mcron jobs
-to run.
-@end defvr
-@deftp {Data Type} mcron-configuration
-Data type representing the configuration of mcron.
-@table @asis
-@item @code{mcron} (default: @var{mcron})
-The mcron package to use.
-@item @code{jobs}
-This is a list of gexps (@pxref{G-Ausdrücke}), where each gexp corresponds
-to an mcron job specification (@pxref{Syntax, mcron job specifications,,
-mcron, GNU@tie{}mcron}).
-@end table
-@end deftp
-@node Log-Rotation
-@subsection Log-Rotation
-@cindex rottlog
-@cindex log rotation
-@cindex Protokollierung
-Log files such as those found in @file{/var/log} tend to grow endlessly, so
-it's a good idea to @dfn{rotate} them once in a while---i.e., archive their
-contents in separate files, possibly compressed.  The @code{(gnu services
-admin)} module provides an interface to GNU@tie{}Rot[t]log, a log rotation
-tool (@pxref{Top,,, rottlog, GNU Rot[t]log Manual}).
-The example below defines an operating system that provides log rotation
-with the default settings, for commonly encountered log files.
-@lisp
-(use-modules (guix) (gnu))
-(use-service-modules admin mcron)
-(use-package-modules base idutils)
-(operating-system
-  ;; @dots{}
-  (services (cons (service rottlog-service-type)
-                  %base-services)))
-@end lisp
-@defvr {Scheme Variable} rottlog-service-type
-This is the type of the Rottlog service, whose value is a
-@code{rottlog-configuration} object.
-Other services can extend this one with new @code{log-rotation} objects (see
-below), thereby augmenting the set of files to be rotated.
-This service type can define mcron jobs (@pxref{Geplante Auftragsausführung}) to
-run the rottlog service.
-@end defvr
-@deftp {Data Type} rottlog-configuration
-Data type representing the configuration of rottlog.
-@table @asis
-@item @code{rottlog} (default: @code{rottlog})
-The Rottlog package to use.
-@item @code{rc-file} (default: @code{(file-append rottlog "/etc/rc")})
-The Rottlog configuration file to use (@pxref{Mandatory RC Variables,,,
-rottlog, GNU Rot[t]log Manual}).
-@item @code{rotations} (default: @code{%default-rotations})
-A list of @code{log-rotation} objects as defined below.
-@item @code{jobs}
-This is a list of gexps where each gexp corresponds to an mcron job
-specification (@pxref{Geplante Auftragsausführung}).
-@end table
-@end deftp
-@deftp {Data Type} log-rotation
-Data type representing the rotation of a group of log files.
-Taking an example from the Rottlog manual (@pxref{Period Related File
-Examples,,, rottlog, GNU Rot[t]log Manual}), a log rotation might be defined
-like this:
-@example
-(log-rotation
-  (frequency 'daily)
-  (files '("/var/log/apache/*"))
-  (options '("storedir apache-archives"
-             "rotate 6"
-             "notifempty"
-             "nocompress")))
-@end example
-The list of fields is as follows:
-@table @asis
-@item @code{frequency} (default: @code{'weekly})
-The log rotation frequency, a symbol.
-@item @code{files}
-The list of files or file glob patterns to rotate.
-@item @code{options} (default: @code{'()})
-The list of rottlog options for this rotation (@pxref{Configuration
-parameters,,, rottlog, GNU Rot[t]lg Manual}).
-@item @code{post-rotate} (default: @code{#f})
-Either @code{#f} or a gexp to execute once the rotation has completed.
-@end table
-@end deftp
-@defvr {Scheme Variable} %default-rotations
-Specifies weekly rotation of @var{%rotated-files} and a couple of other
-files.
-@end defvr
-@defvr {Scheme Variable} %rotated-files
-The list of syslog-controlled files to be rotated.  By default it is:
-@code{'("/var/log/messages" "/var/log/secure")}.
-@end defvr
-@node Netzwerkdienste
-@subsection Netzwerkdienste
-The @code{(gnu services networking)} module provides services to configure
-the network interface.
-@cindex DHCP, networking service
-@defvr {Scheme Variable} dhcp-client-service-type
-This is the type of services that run @var{dhcp}, a Dynamic Host
-Configuration Protocol (DHCP) client, on all the non-loopback network
-interfaces.  Its value is the DHCP client package to use, @code{isc-dhcp} by
-default.
-@end defvr
-@deffn {Scheme Procedure} dhcpd-service-type
-This type defines a service that runs a DHCP daemon.  To create a service of
-this type, you must supply a @code{<dhcpd-configuration>}.  For example:
-@example
-(service dhcpd-service-type
-         (dhcpd-configuration
-          (config-file (local-file "my-dhcpd.conf"))
-          (interfaces '("enp0s25"))))
-@end example
-@end deffn
-@deftp {Data Type} dhcpd-configuration
-@table @asis
-@item @code{package} (default: @code{isc-dhcp})
-The package that provides the DHCP daemon.  This package is expected to
-provide the daemon at @file{sbin/dhcpd} relative to its output directory.
-The default package is the @uref{http://www.isc.org/products/DHCP, ISC's
-DHCP server}.
-@item @code{config-file} (default: @code{#f})
-The configuration file to use.  This is required.  It will be passed to
-@code{dhcpd} via its @code{-cf} option.  This may be any ``file-like''
-object (@pxref{G-Ausdrücke, file-like objects}).  See @code{man
-dhcpd.conf} for details on the configuration file syntax.
-@item @code{version} (default: @code{"4"})
-The DHCP version to use.  The ISC DHCP server supports the values ``4'',
-``6'', and ``4o6''.  These correspond to the @code{dhcpd} program options
-@code{-4}, @code{-6}, and @code{-4o6}.  See @code{man dhcpd} for details.
-@item @code{run-directory} (default: @code{"/run/dhcpd"})
-The run directory to use.  At service activation time, this directory will
-be created if it does not exist.
-@item @code{pid-file} (default: @code{"/run/dhcpd/dhcpd.pid"})
-The PID file to use.  This corresponds to the @code{-pf} option of
-@code{dhcpd}.  See @code{man dhcpd} for details.
-@item @code{interfaces} (default: @code{'()})
-The names of the network interfaces on which dhcpd should listen for
-broadcasts.  If this list is not empty, then its elements (which must be
-strings) will be appended to the @code{dhcpd} invocation when starting the
-daemon.  It may not be necessary to explicitly specify any interfaces here;
-see @code{man dhcpd} for details.
-@end table
-@end deftp
-@defvr {Scheme Variable} static-networking-service-type
-@c TODO Document <static-networking> data structures.
-This is the type for statically-configured network interfaces.
-@end defvr
-@deffn {Scheme Procedure} static-networking-service @var{interface} @var{ip} @
-       [#:netmask #f] [#:gateway #f] [#:name-servers @code{'()}] @ [#:requirement
-@code{'(udev)}] Return a service that starts @var{interface} with address
-@var{ip}.  If @var{netmask} is true, use it as the network mask.  If
-@var{gateway} is true, it must be a string specifying the default network
-gateway.  @var{requirement} can be used to declare a dependency on another
-service before configuring the interface.
-This procedure can be called several times, one for each network interface
-of interest.  Behind the scenes what it does is extend
-@code{static-networking-service-type} with additional network interfaces to
-handle.
-Zum Beispiel:
-@example
-(static-networking-service "eno1" "192.168.1.82"
-                           #:gateway "192.168.1.2"
-                           #:name-servers '("192.168.1.2"))
-@end example
-@end deffn
-@cindex wicd
-@cindex WLAN
-@cindex WiFi
-@cindex network management
-@deffn {Scheme Procedure} wicd-service [#:wicd @var{wicd}]
-Return a service that runs @url{https://launchpad.net/wicd,Wicd}, a network
-management daemon that aims to simplify wired and wireless networking.
-This service adds the @var{wicd} package to the global profile, providing
-several commands to interact with the daemon and configure networking:
-@command{wicd-client}, a graphical user interface, and the
-@command{wicd-cli} and @command{wicd-curses} user interfaces.
-@end deffn
-@cindex ModemManager
-@defvr {Scheme Variable} modem-manager-service-type
-This is the service type for the
-@uref{https://wiki.gnome.org/Projects/ModemManager, ModemManager}
-service. The value for this service type is a
-@code{modem-manager-configuration} record.
-This service is part of @code{%desktop-services} (@pxref{Desktop-Dienste}).
-@end defvr
-@deftp {Data Type} modem-manager-configuration
-Repräsentiert die Konfiguration vom ModemManager.
-@table @asis
-@item @code{modem-manager} (Vorgabe: @code{modem-manager})
-Das ModemManager-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@cindex NetworkManager
-@defvr {Scheme Variable} network-manager-service-type
-This is the service type for the
-@uref{https://wiki.gnome.org/Projects/NetworkManager, NetworkManager}
-service. The value for this service type is a
-@code{network-manager-configuration} record.
-This service is part of @code{%desktop-services} (@pxref{Desktop-Dienste}).
-@end defvr
-@deftp {Data Type} network-manager-configuration
-Data type representing the configuration of NetworkManager.
-@table @asis
-@item @code{network-manager} (default: @code{network-manager})
-The NetworkManager package to use.
-@item @code{dns} (default: @code{"default"})
-Processing mode for DNS, which affects how NetworkManager uses the
-@code{resolv.conf} configuration file.
-@table @samp
-@item default
-NetworkManager will update @code{resolv.conf} to reflect the nameservers
-provided by currently active connections.
-@item dnsmasq
-NetworkManager will run @code{dnsmasq} as a local caching nameserver, using
-a "split DNS" configuration if you are connected to a VPN, and then update
-@code{resolv.conf} to point to the local nameserver.
-@item none
-NetworkManager will not modify @code{resolv.conf}.
-@end table
-@item @code{vpn-plugins} (default: @code{'()})
-This is the list of available plugins for virtual private networks (VPNs).
-An example of this is the @code{network-manager-openvpn} package, which
-allows NetworkManager to manage VPNs @i{via} OpenVPN.
-@end table
-@end deftp
-@cindex Connman
-@deffn {Scheme Variable} connman-service-type
-This is the service type to run @url{https://01.org/connman,Connman}, a
-network connection manager.
-Its value must be an @code{connman-configuration} record as in this example:
-@example
-(service connman-service-type
-         (connman-configuration
-           (disable-vpn? #t)))
-@end example
-See below for details about @code{connman-configuration}.
-@end deffn
-@deftp {Data Type} connman-configuration
-Data Type representing the configuration of connman.
-@table @asis
-@item @code{connman} (default: @var{connman})
-The connman package to use.
-@item @code{disable-vpn?} (default: @code{#f})
-When true, disable connman's vpn plugin.
-@end table
-@end deftp
-@cindex WPA Supplicant
-@defvr {Scheme Variable} wpa-supplicant-service-type
-This is the service type to run @url{https://w1.fi/wpa_supplicant/,WPA
-supplicant}, an authentication daemon required to authenticate against
-encrypted WiFi or ethernet networks.
-@end defvr
-@deftp {Data Type} wpa-supplicant-configuration
-Repräsentiert die Konfiguration des WPA-Supplikanten.
-Sie hat folgende Parameter:
-@table @asis
-@item @code{wpa-supplicant} (Vorgabe: @code{wpa-supplicant})
-Das WPA-Supplicant-Paket, was benutzt werden soll.
-@item @code{dbus?} (Vorgabe: @code{#t})
-Whether to listen for requests on D-Bus.
-@item @code{pid-file} (Vorgabe: @code{"/var/run/wpa_supplicant.pid"})
-Wo die PID-Datei abgelegt wird.
-@item @code{interface} (Vorgabe: @code{#f})
-If this is set, it must specify the name of a network interface that WPA
-supplicant will control.
-@item @code{config-file} (default: @code{#f})
-Optionale Konfigurationsdatei.
-@item @code{extra-options} (Vorgabe: @code{'()})
-List of additional command-line arguments to pass to the daemon.
-@end table
-@end deftp
-@cindex iptables
-@defvr {Scheme Variable} iptables-service-type
-This is the service type to set up an iptables configuration.  iptables is a
-packet filtering framework supported by the Linux kernel.  This service
-supports configuring iptables for both IPv4 and IPv6.  A simple example
-configuration rejecting all incoming connections except those to the ssh
-port 22 is shown below.
-@lisp
-(service iptables-service-type
-         (iptables-configuration
-          (ipv4-rules (plain-file "iptables.rules" "*filter
-:INPUT ACCEPT
-:FORWARD ACCEPT
-:OUTPUT ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-COMMIT
-"))
-          (ipv6-rules (plain-file "ip6tables.rules" "*filter
-:INPUT ACCEPT
-:FORWARD ACCEPT
-:OUTPUT ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-port-unreachable
-COMMIT
-"))))
-@end lisp
-@end defvr
-@deftp {Datentyp} iptables-configuration
-Repräsentiert die iptables-Konfiguration.
-@table @asis
-@item @code{iptables} (Vorgabe: @code{iptables})
-The iptables package that provides @code{iptables-restore} and
-@code{ip6tables-restore}.
-@item @code{ipv4-rules} (Vorgabe: @code{%iptables-accept-all-rules})
-The iptables rules to use.  It will be passed to @code{iptables-restore}.
-This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like
-objects}).
-@item @code{ipv6-rules} (Vorgabe: @code{%iptables-accept-all-rules})
-The ip6tables rules to use.  It will be passed to @code{ip6tables-restore}.
-This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like
-objects}).
-@end table
-@end deftp
-@cindex NTP (Network Time Protocol), Dienst
-@cindex real time clock
-@defvr {Scheme Variable} ntp-service-type
-This is the type of the service running the @uref{http://www.ntp.org,
-Network Time Protocol (NTP)} daemon, @command{ntpd}.  The daemon will keep
-the system clock synchronized with that of the specified NTP servers.
-The value of this service is an @code{ntpd-configuration} object, as
-described below.
-@end defvr
-@deftp {Datentyp} ntp-configuration
-Der Datentyp für die Dienstkonfiguration des NTP-Dienstes.
-@table @asis
-@item @code{servers} (Vorgabe: @code{%ntp-servers})
-This is the list of servers (host names) with which @command{ntpd} will be
-synchronized.
-@item @code{allow-large-adjustment?} (default: @code{#f})
-This determines whether @command{ntpd} is allowed to make an initial
-adjustment of more than 1,000 seconds.
-@item @code{ntp} (Vorgabe: @code{ntp})
-Das NTP-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@defvr {Scheme Variable} %ntp-servers
-List of host names used as the default NTP servers.  These are servers of
-the @uref{https://www.ntppool.org/en/, NTP Pool Project}.
-@end defvr
-@cindex OpenNTPD
-@deffn {Scheme Procedure} openntpd-service-type
-Run the @command{ntpd}, the Network Time Protocol (NTP) daemon, as
-implemented by @uref{http://www.openntpd.org, OpenNTPD}.  The daemon will
-keep the system clock synchronized with that of the given servers.
-@example
-(service
- openntpd-service-type
- (openntpd-configuration
-  (listen-on '("127.0.0.1" "::1"))
-  (sensor '("udcf0 correction 70000"))
-  (constraint-from '("www.gnu.org"))
-  (constraints-from '("https://www.google.com/"))
-  (allow-large-adjustment? #t)))
-@end example
-@end deffn
-@deftp {Data Type} openntpd-configuration
-@table @asis
-@item @code{openntpd} (default: @code{(file-append openntpd "/sbin/ntpd")})
-The openntpd executable to use.
-@item @code{listen-on} (default: @code{'("127.0.0.1" "::1")})
-A list of local IP addresses or hostnames the ntpd daemon should listen on.
-@item @code{query-from} (default: @code{'()})
-A list of local IP address the ntpd daemon should use for outgoing queries.
-@item @code{sensor} (default: @code{'()})
-Specify a list of timedelta sensor devices ntpd should use.  @code{ntpd}
-will listen to each sensor that acutally exists and ignore non-existant
-ones.  See @uref{https://man.openbsd.org/ntpd.conf, upstream documentation}
-for more information.
-@item @code{server} (default: @var{%ntp-servers})
-Specify a list of IP addresses or hostnames of NTP servers to synchronize
-to.
-@item @code{servers} (default: @code{'()})
-Specify a list of IP addresses or hostnames of NTP pools to synchronize to.
-@item @code{constraint-from} (default: @code{'()})
-@code{ntpd} can be configured to query the ‘Date’ from trusted HTTPS servers
-via TLS.  This time information is not used for precision but acts as an
-authenticated constraint, thereby reducing the impact of unauthenticated NTP
-man-in-the-middle attacks.  Specify a list of URLs, IP addresses or
-hostnames of HTTPS servers to provide a constraint.
-@item @code{constraints-from} (default: @code{'()})
-As with constraint from, specify a list of URLs, IP addresses or hostnames
-of HTTPS servers to provide a constraint.  Should the hostname resolve to
-multiple IP addresses, @code{ntpd} will calculate a median constraint from
-all of them.
-@item @code{allow-large-adjustment?} (default: @code{#f})
-Determines if @code{ntpd} is allowed to make an initial adjustment of more
-than 180 seconds.
-@end table
-@end deftp
-@cindex inetd
-@deffn {Scheme variable} inetd-service-type
-This service runs the @command{inetd} (@pxref{inetd invocation,,, inetutils,
-GNU Inetutils}) daemon.  @command{inetd} listens for connections on internet
-sockets, and lazily starts the specified server program when a connection is
-made on one of these sockets.
-The value of this service is an @code{inetd-configuration} object.  The
-following example configures the @command{inetd} daemon to provide the
-built-in @command{echo} service, as well as an smtp service which forwards
-smtp traffic over ssh to a server @code{smtp-server} behind a gateway
-@code{hostname}:
-@example
-(service
- inetd-service-type
- (inetd-configuration
-  (entries (list
-            (inetd-entry
-             (name "echo")
-             (socket-type 'stream)
-             (protocol "tcp")
-             (wait? #f)
-             (user "root"))
-            (inetd-entry
-             (node "127.0.0.1")
-             (name "smtp")
-             (socket-type 'stream)
-             (protocol "tcp")
-             (wait? #f)
-             (user "root")
-             (program (file-append openssh "/bin/ssh"))
-             (arguments
-              '("ssh" "-qT" "-i" "/path/to/ssh_key"
-                "-W" "smtp-server:25" "user@@hostname")))))
-@end example
-See below for more details about @code{inetd-configuration}.
-@end deffn
-@deftp {Data Type} inetd-configuration
-Data type representing the configuration of @command{inetd}.
-@table @asis
-@item @code{program} (default: @code{(file-append inetutils "/libexec/inetd")})
-The @command{inetd} executable to use.
-@item @code{entries} (default: @code{'()})
-A list of @command{inetd} service entries.  Each entry should be created by
-the @code{inetd-entry} constructor.
-@end table
-@end deftp
-@deftp {Data Type} inetd-entry
-Data type representing an entry in the @command{inetd} configuration.  Each
-entry corresponds to a socket where @command{inetd} will listen for
-requests.
-@table @asis
-@item @code{node} (Vorgabe: @code{#f})
-Optional string, a comma-separated list of local addresses @command{inetd}
-should use when listening for this service.  @xref{Configuration file,,,
-inetutils, GNU Inetutils} for a complete description of all options.
-@item @code{name}
-A string, the name must correspond to an entry in @code{/etc/services}.
-@item @code{socket-type}
-One of @code{'stream}, @code{'dgram}, @code{'raw}, @code{'rdm} or
-@code{'seqpacket}.
-@item @code{protocol}
-A string, must correspond to an entry in @code{/etc/protocols}.
-@item @code{wait?} (Vorgabe: @code{#t})
-Whether @command{inetd} should wait for the server to exit before listening
-to new service requests.
-@item @code{user}
-A string containing the user (and, optionally, group) name of the user as
-whom the server should run.  The group name can be specified in a suffix,
-separated by a colon or period, i.e.@: @code{"user"}, @code{"user:group"} or
-@code{"user.group"}.
-@item @code{program} (default: @code{"internal"})
-The server program which will serve the requests, or @code{"internal"} if
-@command{inetd} should use a built-in service.
-@item @code{arguments} (Vorgabe: @code{'()})
-A list strings or file-like objects, which are the server program's
-arguments, starting with the zeroth argument, i.e.@: the name of the program
-itself.  For @command{inetd}'s internal services, this entry must be
-@code{'()} or @code{'("internal")}.
-@end table
-@xref{Configuration file,,, inetutils, GNU Inetutils} for a more detailed
-discussion of each configuration field.
-@end deftp
-@cindex Tor
-@defvr {Scheme Variable} tor-service-type
-This is the type for a service that runs the @uref{https://torproject.org,
-Tor} anonymous networking daemon.  The service is configured using a
-@code{<tor-configuration>} record.  By default, the Tor daemon runs as the
-@code{tor} unprivileged user, which is a member of the @code{tor} group.
-@end defvr
-@deftp {Datentyp} tor-configuration
-@table @asis
-@item @code{tor} (Vorgabe: @code{tor})
-The package that provides the Tor daemon.  This package is expected to
-provide the daemon at @file{bin/tor} relative to its output directory.  The
-default package is the @uref{https://www.torproject.org, Tor Project's}
-implementation.
-@item @code{config-file} (Vorgabe: @code{(plain-file "empty" "")})
-The configuration file to use.  It will be appended to a default
-configuration file, and the final configuration file will be passed to
-@code{tor} via its @code{-f} option.  This may be any ``file-like'' object
-(@pxref{G-Ausdrücke, file-like objects}).  See @code{man tor} for details
-on the configuration file syntax.
-@item @code{hidden-services} (Vorgabe: @code{'()})
-The list of @code{<hidden-service>} records to use.  For any hidden service
-you include in this list, appropriate configuration to enable the hidden
-service will be automatically added to the default configuration file.  You
-may conveniently create @code{<hidden-service>} records using the
-@code{tor-hidden-service} procedure described below.
-@item @code{socks-socket-type} (Vorgabe: @code{'tcp})
-The default socket type that Tor should use for its SOCKS socket.  This must
-be either @code{'tcp} or @code{'unix}.  If it is @code{'tcp}, then by
-default Tor will listen on TCP port 9050 on the loopback interface (i.e.,
-localhost).  If it is @code{'unix}, then Tor will listen on the UNIX domain
-socket @file{/var/run/tor/socks-sock}, which will be made writable by
-members of the @code{tor} group.
-If you want to customize the SOCKS socket in more detail, leave
-@code{socks-socket-type} at its default value of @code{'tcp} and use
-@code{config-file} to override the default by providing your own
-@code{SocksPort} option.
-@end table
-@end deftp
-@cindex hidden service
-@deffn {Scheme Procedure} tor-hidden-service @var{name} @var{mapping}
-Define a new Tor @dfn{hidden service} called @var{name} and implementing
-@var{mapping}.  @var{mapping} is a list of port/host tuples, such as:
-@example
- '((22 "127.0.0.1:22")
-   (80 "127.0.0.1:8080"))
-@end example
-In this example, port 22 of the hidden service is mapped to local port 22,
-and port 80 is mapped to local port 8080.
-This creates a @file{/var/lib/tor/hidden-services/@var{name}} directory,
-where the @file{hostname} file contains the @code{.onion} host name for the
-hidden service.
-See @uref{https://www.torproject.org/docs/tor-hidden-service.html.en, the
-Tor project's documentation} for more information.
-@end deffn
-The @code{(gnu services rsync)} module provides the following services:
-You might want an rsync daemon if you have files that you want available so
-anyone (or just yourself) can download existing files or upload new files.
-@deffn {Scheme Variable} rsync-service-type
-This is the type for the @uref{https://rsync.samba.org, rsync} rsync daemon,
-@command{rsync-configuration} record as in this example:
-@example
-(service rsync-service-type)
-@end example
-See below for details about @code{rsync-configuration}.
-@end deffn
-@deftp {Data Type} rsync-configuration
-Data type representing the configuration for @code{rsync-service}.
-@table @asis
-@item @code{package} (default: @var{rsync})
-@code{rsync} package to use.
-@item @code{port-number} (default: @code{873})
-TCP port on which @command{rsync} listens for incoming connections.  If port
-is less than @code{1024} @command{rsync} needs to be started as the
-@code{root} user and group.
-@item @code{pid-file} (default: @code{"/var/run/rsyncd/rsyncd.pid"})
-Name of the file where @command{rsync} writes its PID.
-@item @code{lock-file} (default: @code{"/var/run/rsyncd/rsyncd.lock"})
-Name of the file where @command{rsync} writes its lock file.
-@item @code{log-file} (default: @code{"/var/log/rsyncd.log"})
-Name of the file where @command{rsync} writes its log file.
-@item @code{use-chroot?} (default: @var{#t})
-Whether to use chroot for @command{rsync} shared directory.
-@item @code{share-path} (default: @file{/srv/rsync})
-Location of the @command{rsync} shared directory.
-@item @code{share-comment} (default: @code{"Rsync share"})
-Comment of the @command{rsync} shared directory.
-@item @code{read-only?} (default: @var{#f})
-Read-write permissions to shared directory.
-@item @code{timeout} (default: @code{300})
-I/O timeout in seconds.
-@item @code{user} (default: @var{"root"})
-Owner of the @code{rsync} process.
-@item @code{group} (default: @var{"root"})
-Group of the @code{rsync} process.
-@item @code{uid} (default: @var{"rsyncd"})
-User name or user ID that file transfers to and from that module should take
-place as when the daemon was run as @code{root}.
-@item @code{gid} (default: @var{"rsyncd"})
-Group name or group ID that will be used when accessing the module.
-@end table
-@end deftp
-Furthermore, @code{(gnu services ssh)} provides the following services.
-@cindex SSH
-@cindex SSH server
-@deffn {Scheme Procedure} lsh-service [#:host-key "/etc/lsh/host-key"] @
-       [#:daemonic? #t] [#:interfaces '()] [#:port-number 22] @
-[#:allow-empty-passwords? #f] [#:root-login? #f] @ [#:syslog-output? #t]
-[#:x11-forwarding? #t] @ [#:tcp/ip-forwarding? #t]
-[#:password-authentication? #t] @ [#:public-key-authentication? #t]
-[#:initialize? #t] Run the @command{lshd} program from @var{lsh} to listen
-on port @var{port-number}.  @var{host-key} must designate a file containing
-the host key, and readable only by root.
-When @var{daemonic?} is true, @command{lshd} will detach from the
-controlling terminal and log its output to syslogd, unless one sets
-@var{syslog-output?} to false.  Obviously, it also makes lsh-service depend
-on existence of syslogd service.  When @var{pid-file?} is true,
-@command{lshd} writes its PID to the file called @var{pid-file}.
-When @var{initialize?} is true, automatically create the seed and host key
-upon service activation if they do not exist yet.  This may take long and
-require interaction.
-When @var{initialize?} is false, it is up to the user to initialize the
-randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to
-create a key pair with the private key stored in file @var{host-key}
-(@pxref{lshd basics,,, lsh, LSH Manual}).
-When @var{interfaces} is empty, lshd listens for connections on all the
-network interfaces; otherwise, @var{interfaces} must be a list of host names
-or addresses.
-@var{allow-empty-passwords?} specifies whether to accept log-ins with empty
-passwords, and @var{root-login?} specifies whether to accept log-ins as
-root.
-The other options should be self-descriptive.
-@end deffn
-@cindex SSH
-@cindex SSH server
-@deffn {Scheme Variable} openssh-service-type
-This is the type for the @uref{http://www.openssh.org, OpenSSH} secure shell
-daemon, @command{sshd}.  Its value must be an @code{openssh-configuration}
-record as in this example:
-@example
-(service openssh-service-type
-         (openssh-configuration
-           (x11-forwarding? #t)
-           (permit-root-login 'without-password)
-           (authorized-keys
-             `(("alice" ,(local-file "alice.pub"))
-               ("bob" ,(local-file "bob.pub"))))))
-@end example
-See below for details about @code{openssh-configuration}.
-This service can be extended with extra authorized keys, as in this example:
-@example
-(service-extension openssh-service-type
-                   (const `(("charlie"
-                             ,(local-file "charlie.pub")))))
-@end example
-@end deffn
-@deftp {Data Type} openssh-configuration
-This is the configuration record for OpenSSH's @command{sshd}.
-@table @asis
-@item @code{pid-file} (default: @code{"/var/run/sshd.pid"})
-Name of the file where @command{sshd} writes its PID.
-@item @code{port-number} (default: @code{22})
-TCP port on which @command{sshd} listens for incoming connections.
-@item @code{permit-root-login} (default: @code{#f})
-This field determines whether and when to allow logins as root.  If
-@code{#f}, root logins are disallowed; if @code{#t}, they are allowed.  If
-it's the symbol @code{'without-password}, then root logins are permitted but
-not with password-based authentication.
-@item @code{allow-empty-passwords?} (default: @code{#f})
-When true, users with empty passwords may log in.  When false, they may not.
-@item @code{password-authentication?} (default: @code{#t})
-When true, users may log in with their password.  When false, they have
-other authentication methods.
-@item @code{public-key-authentication?} (default: @code{#t})
-When true, users may log in using public key authentication.  When false,
-users have to use other authentication method.
-Authorized public keys are stored in @file{~/.ssh/authorized_keys}.  This is
-used only by protocol version 2.
-@item @code{x11-forwarding?} (default: @code{#f})
-When true, forwarding of X11 graphical client connections is enabled---in
-other words, @command{ssh} options @option{-X} and @option{-Y} will work.
-@item @code{allow-agent-forwarding?} (Vorgabe: @code{#t})
-Whether to allow agent forwarding.
-@item @code{allow-tcp-forwarding?} (Vorgabe: @code{#t})
-Whether to allow TCP forwarding.
-@item @code{gateway-ports?} (Vorgabe: @code{#f})
-Whether to allow gateway ports.
-@item @code{challenge-response-authentication?} (default: @code{#f})
-Specifies whether challenge response authentication is allowed (e.g.@: via
-PAM).
-@item @code{use-pam?} (default: @code{#t})
-Enables the Pluggable Authentication Module interface.  If set to @code{#t},
-this will enable PAM authentication using
-@code{challenge-response-authentication?} and
-@code{password-authentication?}, in addition to PAM account and session
-module processing for all authentication types.
-Because PAM challenge response authentication usually serves an equivalent
-role to password authentication, you should disable either
-@code{challenge-response-authentication?} or
-@code{password-authentication?}.
-@item @code{print-last-log?} (default: @code{#t})
-Specifies whether @command{sshd} should print the date and time of the last
-user login when a user logs in interactively.
-@item @code{subsystems} (default: @code{'(("sftp" "internal-sftp"))})
-Configures external subsystems (e.g.@: file transfer daemon).
-This is a list of two-element lists, each of which containing the subsystem
-name and a command (with optional arguments) to execute upon subsystem
-request.
-The command @command{internal-sftp} implements an in-process SFTP server.
-Alternately, one can specify the @command{sftp-server} command:
-@example
-(service openssh-service-type
-         (openssh-configuration
-          (subsystems
-           `(("sftp" ,(file-append openssh "/libexec/sftp-server"))))))
-@end example
-@item @code{accepted-environment} (default: @code{'()})
-List of strings describing which environment variables may be exported.
-Each string gets on its own line.  See the @code{AcceptEnv} option in
-@code{man sshd_config}.
-This example allows ssh-clients to export the @code{COLORTERM} variable.  It
-is set by terminal emulators, which support colors.  You can use it in your
-shell's ressource file to enable colors for the prompt and commands if this
-variable is set.
-@example
-(service openssh-service-type
-         (openssh-configuration
-           (accepted-environment '("COLORTERM"))))
-@end example
-@item @code{authorized-keys} (default: @code{'()})
-@cindex authorized keys, SSH
-@cindex SSH authorized keys
-This is the list of authorized keys.  Each element of the list is a user
-name followed by one or more file-like objects that represent SSH public
-keys.  For example:
-@example
-(openssh-configuration
-  (authorized-keys
-    `(("rekado" ,(local-file "rekado.pub"))
-      ("chris" ,(local-file "chris.pub"))
-      ("root" ,(local-file "rekado.pub") ,(local-file "chris.pub")))))
-@end example
-@noindent
-registers the specified public keys for user accounts @code{rekado},
-@code{chris}, and @code{root}.
-Additional authorized keys can be specified @i{via}
-@code{service-extension}.
-Note that this does @emph{not} interfere with the use of
-@file{~/.ssh/authorized_keys}.
-@item @code{log-level} (Vorgabe: @code{'info})
-This is a symbol specifying the logging level: @code{quiet}, @code{fatal},
-@code{error}, @code{info}, @code{verbose}, @code{debug}, etc.  See the man
-page for @file{sshd_config} for the full list of level names.
-@item @code{extra-content} (Vorgabe: @code{""})
-This field can be used to append arbitrary text to the configuration file.
-It is especially useful for elaborate configurations that cannot be
-expressed otherwise.  This configuration, for example, would generally
-disable root logins, but permit them from one specific IP address:
-@example
-(openssh-configuration
-  (extra-content "\
-Match Address 192.168.0.1
-  PermitRootLogin yes"))
-@end example
-@end table
-@end deftp
-@deffn {Scheme Procedure} dropbear-service [@var{config}]
-Run the @uref{https://matt.ucc.asn.au/dropbear/dropbear.html,Dropbear SSH
-daemon} with the given @var{config}, a @code{<dropbear-configuration>}
-object.
-For example, to specify a Dropbear service listening on port 1234, add this
-call to the operating system's @code{services} field:
-@example
-(dropbear-service (dropbear-configuration
-                    (port-number 1234)))
-@end example
-@end deffn
-@deftp {Data Type} dropbear-configuration
-This data type represents the configuration of a Dropbear SSH daemon.
-@table @asis
-@item @code{dropbear} (default: @var{dropbear})
-The Dropbear package to use.
-@item @code{port-number} (default: 22)
-The TCP port where the daemon waits for incoming connections.
-@item @code{syslog-output?} (default: @code{#t})
-Whether to enable syslog output.
-@item @code{pid-file} (default: @code{"/var/run/dropbear.pid"})
-File name of the daemon's PID file.
-@item @code{root-login?} (default: @code{#f})
-Whether to allow @code{root} logins.
-@item @code{allow-empty-passwords?} (default: @code{#f})
-Whether to allow empty passwords.
-@item @code{password-authentication?} (default: @code{#t})
-Whether to enable password-based authentication.
-@end table
-@end deftp
-@defvr {Scheme Variable} %facebook-host-aliases
-This variable contains a string for use in @file{/etc/hosts} (@pxref{Host
-Names,,, libc, The GNU C Library Reference Manual}).  Each line contains a
-entry that maps a known server name of the Facebook on-line service---e.g.,
-@code{www.facebook.com}---to the local host---@code{127.0.0.1} or its IPv6
-equivalent, @code{::1}.
-This variable is typically used in the @code{hosts-file} field of an
-@code{operating-system} declaration (@pxref{»operating-system«-Referenz,
-@file{/etc/hosts}}):
-@example
-(use-modules (gnu) (guix))
-(operating-system
-  (host-name "mymachine")
-  ;; ...
-  (hosts-file
-    ;; Create a /etc/hosts file with aliases for "localhost"
-    ;; and "mymachine", as well as for Facebook servers.
-    (plain-file "hosts"
-                (string-append (local-host-aliases host-name)
-                               %facebook-host-aliases))))
-@end example
-This mechanism can prevent programs running locally, such as Web browsers,
-from accessing Facebook.
-@end defvr
-The @code{(gnu services avahi)} provides the following definition.
-@defvr {Scheme-Variable} avahi-service-type
-This is the service that runs @command{avahi-daemon}, a system-wide
-mDNS/DNS-SD responder that allows for service discovery and
-``zero-configuration'' host name lookups (see @uref{http://avahi.org/}).
-Its value must be a @code{zero-configuration} record---see below.
-This service extends the name service cache daemon (nscd) so that it can
-resolve @code{.local} host names using
-@uref{http://0pointer.de/lennart/projects/nss-mdns/, nss-mdns}.  @xref{Name Service Switch}, for information on host name resolution.
-Additionally, add the @var{avahi} package to the system profile so that
-commands such as @command{avahi-browse} are directly usable.
-@end defvr
-@deftp {Datentyp} avahi-configuration
-Dieser Datentyp repräsentiert die Konfiguration von Avahi.
-@table @asis
-@item @code{host-name} (Vorgabe: @code{#f})
-If different from @code{#f}, use that as the host name to publish for this
-machine; otherwise, use the machine's actual host name.
-@item @code{publish?} (Vorgabe: @code{#t})
-When true, allow host names and services to be published (broadcast) over
-the network.
-@item @code{publish-workstation?} (Vorgabe: @code{#t})
-When true, @command{avahi-daemon} publishes the machine's host name and IP
-address via mDNS on the local network.  To view the host names published on
-your local network, you can run:
-@example
-avahi-browse _workstation._tcp
-@end example
-@item @code{wide-area?} (Vorgabe: @code{#f})
-When true, DNS-SD over unicast DNS is enabled.
-@item @code{ipv4?} (Vorgabe: @code{#t})
-@itemx @code{ipv6?} (Vorgabe: @code{#t})
-These fields determine whether to use IPv4/IPv6 sockets.
-@item @code{domains-to-browse} (Vorgabe: @code{'()})
-This is a list of domains to browse.
-@end table
-@end deftp
-@deffn {Scheme Variable} openvswitch-service-type
-This is the type of the @uref{http://www.openvswitch.org, Open vSwitch}
-service, whose value should be an @code{openvswitch-configuration} object.
-@end deffn
-@deftp {Data Type} openvswitch-configuration
-Data type representing the configuration of Open vSwitch, a multilayer
-virtual switch which is designed to enable massive network automation
-through programmatic extension.
-@table @asis
-@item @code{package} (default: @var{openvswitch})
-Package object of the Open vSwitch.
-@end table
-@end deftp
-@node X Window
-@subsection X Window
-@cindex X11
-@cindex X Window System
-@cindex login manager
-Support for the X Window graphical display system---specifically Xorg---is
-provided by the @code{(gnu services xorg)} module.  Note that there is no
-@code{xorg-service} procedure.  Instead, the X server is started by the
-@dfn{login manager}, by default the GNOME Display Manager (GDM).
-@cindex GDM
-@cindex GNOME, login manager
-GDM of course allows users to log in into window managers and desktop
-environments other than GNOME; for those using GNOME, GDM is required for
-features such as automatic screen locking.
-@cindex window manager
-To use X11, you must install at least one @dfn{window manager}---for example
-the @code{windowmaker} or @code{openbox} packages---preferably by adding it
-to the @code{packages} field of your operating system definition
-(@pxref{»operating-system«-Referenz, system-wide packages}).
-@defvr {Scheme-Variable} gdm-service-type
-This is the type for the @uref{https://wiki.gnome.org/Projects/GDM/, GNOME
-Desktop Manager} (GDM), a program that manages graphical display servers and
-handles graphical user logins.  Its value must be a @code{gdm-configuration}
-(see below.)
-@cindex session types (X11)
-@cindex X11 session types
-GDM looks for @dfn{session types} described by the @file{.desktop} files in
-@file{/run/current-system/profile/share/xsessions} and allows users to
-choose a session from the log-in screen.  Packages such as @code{gnome},
-@code{xfce}, and @code{i3} provide @file{.desktop} files; adding them to the
-system-wide set of packages automatically makes them available at the log-in
-screen.
-In addition, @file{~/.xsession} files are honored.  When available,
-@file{~/.xsession} must be an executable that starts a window manager and/or
-other X clients.
-@end defvr
-@deftp {Datentyp} gdm-configuration
-@table @asis
-@item @code{auto-login?} (default: @code{#f})
-@itemx @code{default-user} (Vorgabe: @code{#f})
-When @code{auto-login?} is false, GDM presents a log-in screen.
-When @code{auto-login?} is true, GDM logs in directly as
-@code{default-user}.
-@item @code{gnome-shell-assets} (Vorgabe: …)
-List of GNOME Shell assets needed by GDM: icon theme, fonts, etc.
-@item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)})
-Xorg-Server für grafische Oberflächen konfigurieren.
-@item @code{xsession} (Vorgabe: @code{(xinitrc)})
-Script to run before starting a X session.
-@item @code{dbus-daemon} (Vorgabe: @code{dbus-daemon-wrapper})
-File name of the @code{dbus-daemon} executable.
-@item @code{gdm} (Vorgabe: @code{gdm})
-Das GDM-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@defvr {Scheme Variable} slim-service-type
-This is the type for the SLiM graphical login manager for X11.
-Like GDM, SLiM looks for session types described by @file{.desktop} files
-and allows users to choose a session from the log-in screen using @kbd{F1}.
-It also honors @file{~/.xsession} files.
-@end defvr
-@deftp {Data Type} slim-configuration
-Data type representing the configuration of @code{slim-service-type}.
-@table @asis
-@item @code{allow-empty-passwords?} (Vorgabe: @code{#t})
-Whether to allow logins with empty passwords.
-@item @code{auto-login?} (default: @code{#f})
-@itemx @code{default-user} (default: @code{""})
-When @code{auto-login?} is false, SLiM presents a log-in screen.
-When @code{auto-login?} is true, SLiM logs in directly as
-@code{default-user}.
-@item @code{theme} (default: @code{%default-slim-theme})
-@itemx @code{theme-name} (default: @code{%default-slim-theme-name})
-The graphical theme to use and its name.
-@item @code{auto-login-session} (default: @code{#f})
-If true, this must be the name of the executable to start as the default
-session---e.g., @code{(file-append windowmaker "/bin/windowmaker")}.
-If false, a session described by one of the available @file{.desktop} files
-in @code{/run/current-system/profile} and @code{~/.guix-profile} will be
-used.
-@quotation Anmerkung
-You must install at least one window manager in the system profile or in
-your user profile.  Failing to do that, if @code{auto-login-session} is
-false, you will be unable to log in.
-@end quotation
-@item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)})
-Xorg-Server für grafische Oberflächen konfigurieren.
-@item @code{xauth} (default: @code{xauth})
-The XAuth package to use.
-@item @code{shepherd} (default: @code{shepherd})
-The Shepherd package used when invoking @command{halt} and @command{reboot}.
-@item @code{sessreg} (default: @code{sessreg})
-The sessreg package used in order to register the session.
-@item @code{slim} (default: @code{slim})
-The SLiM package to use.
-@end table
-@end deftp
-@defvr {Scheme Variable} %default-theme
-@defvrx {Scheme Variable} %default-theme-name
-The default SLiM theme and its name.
-@end defvr
-@deftp {Data Type} sddm-configuration
-This is the data type representing the sddm service configuration.
-@table @asis
-@item @code{display-server} (default: "x11")
-Select display server to use for the greeter. Valid values are "x11" or
-"wayland".
-@item @code{numlock} (default: "on")
-Valid values are "on", "off" or "none".
-@item @code{halt-command} (default @code{#~(string-apppend #$shepherd "/sbin/halt")})
-Command to run when halting.
-@item @code{reboot-command} (default @code{#~(string-append #$shepherd "/sbin/reboot")})
-Command to run when rebooting.
-@item @code{theme} (default "maldives")
-Theme to use. Default themes provided by SDDM are "elarun" or "maldives".
-@item @code{themes-directory} (default "/run/current-system/profile/share/sddm/themes")
-Directory to look for themes.
-@item @code{faces-directory} (default "/run/current-system/profile/share/sddm/faces")
-Directory to look for faces.
-@item @code{default-path} (default "/run/current-system/profile/bin")
-Default PATH to use.
-@item @code{minimum-uid} (default 1000)
-Minimum UID to display in SDDM.
-@item @code{maximum-uid} (default 2000)
-Maximum UID to display in SDDM
-@item @code{remember-last-user?} (default #t)
-Remember last user.
-@item @code{remember-last-session?} (default #t)
-Remember last session.
-@item @code{hide-users} (default "")
-Usernames to hide from SDDM greeter.
-@item @code{hide-shells} (default @code{#~(string-append #$shadow "/sbin/nologin")})
-Users with shells listed will be hidden from the SDDM greeter.
-@item @code{session-command} (default @code{#~(string-append #$sddm "/share/sddm/scripts/wayland-session")})
-Script to run before starting a wayland session.
-@item @code{sessions-directory} (default "/run/current-system/profile/share/wayland-sessions")
-Directory to look for desktop files starting wayland sessions.
-@item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)})
-Xorg-Server für grafische Oberflächen konfigurieren.
-@item @code{xauth-path} (default @code{#~(string-append #$xauth "/bin/xauth")})
-Path to xauth.
-@item @code{xephyr-path} (default @code{#~(string-append #$xorg-server "/bin/Xephyr")})
-Path to Xephyr.
-@item @code{xdisplay-start} (default @code{#~(string-append #$sddm "/share/sddm/scripts/Xsetup")})
-Script to run after starting xorg-server.
-@item @code{xdisplay-stop} (default @code{#~(string-append #$sddm "/share/sddm/scripts/Xstop")})
-Script to run before stopping xorg-server.
-@item @code{xsession-command} (Vorgabe: @code{xinitrc})
-Script to run before starting a X session.
-@item @code{xsessions-directory} (default: "/run/current-system/profile/share/xsessions")
-Directory to look for desktop files starting X sessions.
-@item @code{minimum-vt} (default: 7)
-Minimum VT to use.
-@item @code{auto-login-user} (default "")
-User to use for auto-login.
-@item @code{auto-login-session} (default "")
-Desktop file to use for auto-login.
-@item @code{relogin?} (default #f)
-Relogin after logout.
-@end table
-@end deftp
-@cindex login manager
-@cindex X11 login
-@deffn {Scheme Procedure} sddm-service config
-Return a service that spawns the SDDM graphical login manager for config of
-type @code{<sddm-configuration>}.
-@example
-  (sddm-service (sddm-configuration
-                 (auto-login-user "Alice")
-                 (auto-login-session "xfce.desktop")))
-@end example
-@end deffn
-@cindex Xorg, Konfiguration
-@deftp {Datentyp} xorg-configuration
-This data type represents the configuration of the Xorg graphical display
-server.  Note that there is not Xorg service; instead, the X server is
-started by a ``display manager'' such as GDM, SDDM, and SLiM.  Thus, the
-configuration of these display managers aggregates an
-@code{xorg-configuration} record.
-@table @asis
-@item @code{modules} (Vorgabe: @code{%default-xorg-modules})
-This is a list of @dfn{module packages} loaded by the Xorg server---e.g.,
-@code{xf86-video-vesa}, @code{xf86-input-keyboard}, and so on.
-@item @code{fonts} (Vorgabe: @code{%default-xorg-fonts})
-This is a list of font directories to add to the server's @dfn{font path}.
-@item @code{drivers} (Vorgabe: @code{'()})
-This must be either the empty list, in which case Xorg chooses a graphics
-driver automatically, or a list of driver names that will be tried in this
-order---e.g., @code{("modesetting" "vesa")}.
-@item @code{resolutions} (Vorgabe: @code{'()})
-When @code{resolutions} is the empty list, Xorg chooses an appropriate
-screen resolution.  Otherwise, it must be a list of resolutions---e.g.,
-@code{((1024 768) (640 480))}.
-@cindex Tastaturbelegung, für Xorg
-@cindex keymap, for Xorg
-@item @code{keyboard-layout} (Vorgabe: @code{#f})
-If this is @code{#f}, Xorg uses the default keyboard layout---usually US
-English (``qwerty'') for a 105-key PC keyboard.
-Otherwise this must be a @code{keyboard-layout} object specifying the
-keyboard layout in use when Xorg is running.  @xref{Tastaturbelegung}, for
-more information on how to specify the keyboard layout.
-@item @code{extra-config} (Vorgabe: @code{'()})
-This is a list of strings or objects appended to the configuration file.  It
-is used to pass extra text to be added verbatim to the configuration file.
-@item @code{server} (Vorgabe: @code{xorg-server})
-This is the package providing the Xorg server.
-@item @code{server-arguments} (Vorgabe: @code{%default-xorg-server-arguments})
-This is the list of command-line arguments to pass to the X server.  The
-default is @code{-nolisten tcp}.
-@end table
-@end deftp
-@deffn {Scheme-Prozedur} set-xorg-configuration @var{Konfiguration} @
-  [@var{login-manager-service-type}] Tell the log-in manager (of type
-@var{login-manager-service-type}) to use @var{config}, an
-<xorg-configuration> record.
-Since the Xorg configuration is embedded in the log-in manager's
-configuration---e.g., @code{gdm-configuration}---this procedure provides a
-shorthand to set the Xorg configuration.
-@end deffn
-@deffn {Scheme-Prozedur} xorg-start-command [@var{Konfiguration}]
-Return a @code{startx} script in which the modules, fonts, etc. specified in
-@var{config}, are available.  The result should be used in place of
-@code{startx}.
-Usually the X server is started by a login manager.
-@end deffn
-@deffn {Scheme Procedure} screen-locker-service @var{package} [@var{program}]
-Add @var{package}, a package for a screen locker or screen saver whose
-command is @var{program}, to the set of setuid programs and add a PAM entry
-for it.  For example:
-@lisp
-(screen-locker-service xlockmore "xlock")
-@end lisp
-makes the good ol' XlockMore usable.
-@end deffn
-@node Druckdienste
-@subsection Druckdienste
-@cindex printer support with CUPS
-Das Modul @code{(gnu services cups)} stellt eine Guix-Dienstdefinition für
-den CUPS-Druckdienst zur Verfügung. Wenn Sie Druckerunterstützung zu einem
-Guix-System hinzufügen möchten, dann fügen Sie einen
-@code{cups-service}-Dienst in die Betriebssystemdefinition ein.
-@deffn {Scheme Variable} cups-service-type
-The service type for the CUPS print server.  Its value should be a valid
-CUPS configuration (see below).  To use the default settings, simply write:
-@example
-(service cups-service-type)
-@end example
-@end deffn
-The CUPS configuration controls the basic things about your CUPS
-installation: what interfaces it listens on, what to do if a print job
-fails, how much logging to do, and so on.  To actually add a printer, you
-have to visit the @url{http://localhost:631} URL, or use a tool such as
-GNOME's printer configuration services.  By default, configuring a CUPS
-service will generate a self-signed certificate if needed, for secure
-connections to the print server.
-Suppose you want to enable the Web interface of CUPS and also add support
-for Epson printers @i{via} the @code{escpr} package and for HP printers
-@i{via} the @code{hplip-minimal} package.  You can do that directly, like
-this (you need to use the @code{(gnu packages cups)} module):
-@example
-(service cups-service-type
-         (cups-configuration
-           (web-interface? #t)
-           (extensions
-             (list cups-filters escpr hplip-minimal))))
-@end example
-Note: If you wish to use the Qt5 based GUI which comes with the hplip
-package then it is suggested that you install the @code{hplip} package,
-either in your OS configuration file or as your user.
-The available configuration parameters follow.  Each parameter definition is
-preceded by its type; for example, @samp{string-list foo} indicates that the
-@code{foo} parameter should be specified as a list of strings.  There is
-also a way to specify the configuration as a string, if you have an old
-@code{cupsd.conf} file that you want to port over from some other system;
-see the end for more details.
-@c The following documentation was initially generated by
-@c (generate-documentation) in (gnu services cups).  Manually maintained
-@c documentation is better, so we shouldn't hesitate to edit below as
-@c needed.  However if the change you want to make to this documentation
-@c can be done in an automated way, it's probably easier to change
-@c (generate-documentation) than to make it below and have to deal with
-@c the churn as CUPS updates.
-Available @code{cups-configuration} fields are:
-@deftypevr {@code{cups-configuration} parameter} package cups
-The CUPS package.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} package-list extensions
-Drivers and other extensions to the CUPS package.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} files-configuration files-configuration
-Configuration of where to write logs, what directories to use for print
-spools, and related privileged configuration parameters.
-Available @code{files-configuration} fields are:
-@deftypevr {@code{files-configuration} parameter} log-location access-log
-Defines the access log filename.  Specifying a blank filename disables
-access log generation.  The value @code{stderr} causes log entries to be
-sent to the standard error file when the scheduler is running in the
-foreground, or to the system log daemon when run in the background.  The
-value @code{syslog} causes log entries to be sent to the system log daemon.
-The server name may be included in filenames using the string @code{%s}, as
-in @code{/var/log/cups/%s-access_log}.
-Defaults to @samp{"/var/log/cups/access_log"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} file-name cache-dir
-Where CUPS should cache data.
-Defaults to @samp{"/var/cache/cups"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string config-file-perm
-Specifies the permissions for all configuration files that the scheduler
-writes.
-Note that the permissions for the printers.conf file are currently masked to
-only allow access from the scheduler user (typically root).  This is done
-because printer device URIs sometimes contain sensitive authentication
-information that should not be generally known on the system.  There is no
-way to disable this security feature.
-Defaults to @samp{"0640"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} log-location error-log
-Defines the error log filename.  Specifying a blank filename disables access
-log generation.  The value @code{stderr} causes log entries to be sent to
-the standard error file when the scheduler is running in the foreground, or
-to the system log daemon when run in the background.  The value
-@code{syslog} causes log entries to be sent to the system log daemon.  The
-server name may be included in filenames using the string @code{%s}, as in
-@code{/var/log/cups/%s-error_log}.
-Defaults to @samp{"/var/log/cups/error_log"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string fatal-errors
-Specifies which errors are fatal, causing the scheduler to exit.  The kind
-strings are:
-@table @code
-@item none
-No errors are fatal.
-@item all
-All of the errors below are fatal.
-@item browse
-Browsing initialization errors are fatal, for example failed connections to
-the DNS-SD daemon.
-@item config
-Configuration file syntax errors are fatal.
-@item listen
-Listen or Port errors are fatal, except for IPv6 failures on the loopback or
-@code{any} addresses.
-@item log
-Log file creation or write errors are fatal.
-@item permissions
-Bad startup file permissions are fatal, for example shared TLS certificate
-and key files with world-read permissions.
-@end table
-Defaults to @samp{"all -browse"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} boolean file-device?
-Specifies whether the file pseudo-device can be used for new printer
-queues.  The URI @uref{file:///dev/null} is always allowed.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string group
-Specifies the group name or ID that will be used when executing external
-programs.
-Defaults to @samp{"lp"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string log-file-perm
-Specifies the permissions for all log files that the scheduler writes.
-Defaults to @samp{"0644"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} log-location page-log
-Defines the page log filename.  Specifying a blank filename disables access
-log generation.  The value @code{stderr} causes log entries to be sent to
-the standard error file when the scheduler is running in the foreground, or
-to the system log daemon when run in the background.  The value
-@code{syslog} causes log entries to be sent to the system log daemon.  The
-server name may be included in filenames using the string @code{%s}, as in
-@code{/var/log/cups/%s-page_log}.
-Defaults to @samp{"/var/log/cups/page_log"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string remote-root
-Specifies the username that is associated with unauthenticated accesses by
-clients claiming to be the root user.  The default is @code{remroot}.
-Defaults to @samp{"remroot"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} file-name request-root
-Specifies the directory that contains print jobs and other HTTP request
-data.
-Defaults to @samp{"/var/spool/cups"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} sandboxing sandboxing
-Specifies the level of security sandboxing that is applied to print filters,
-backends, and other child processes of the scheduler; either @code{relaxed}
-or @code{strict}.  This directive is currently only used/supported on macOS.
-Defaults to @samp{strict}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} file-name server-keychain
-Specifies the location of TLS certificates and private keys.  CUPS will look
-for public and private keys in this directory: a @code{.crt} files for
-PEM-encoded certificates and corresponding @code{.key} files for PEM-encoded
-private keys.
-Defaults to @samp{"/etc/cups/ssl"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} file-name server-root
-Specifies the directory containing the server configuration files.
-Defaults to @samp{"/etc/cups"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} boolean sync-on-close?
-Specifies whether the scheduler calls fsync(2) after writing configuration
-or state files.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} space-separated-string-list system-group
-Specifies the group(s) to use for @code{@@SYSTEM} group authentication.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} file-name temp-dir
-Specifies the directory where temporary files are stored.
-Defaults to @samp{"/var/spool/cups/tmp"}.
-@end deftypevr
-@deftypevr {@code{files-configuration} parameter} string user
-Specifies the user name or ID that is used when running external programs.
-Defaults to @samp{"lp"}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} access-log-level access-log-level
-Specifies the logging level for the AccessLog file.  The @code{config} level
-logs when printers and classes are added, deleted, or modified and when
-configuration files are accessed or updated.  The @code{actions} level logs
-when print jobs are submitted, held, released, modified, or canceled, and
-any of the conditions for @code{config}.  The @code{all} level logs all
-requests.
-Defaults to @samp{actions}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean auto-purge-jobs?
-Specifies whether to purge job history data automatically when it is no
-longer required for quotas.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} browse-local-protocols browse-local-protocols
-Specifies which protocols to use for local printer sharing.
-Defaults to @samp{dnssd}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean browse-web-if?
-Specifies whether the CUPS web interface is advertised.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean browsing?
-Specifies whether shared printers are advertised.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string classification
-Specifies the security classification of the server.  Any valid banner name
-can be used, including "classified", "confidential", "secret", "topsecret",
-and "unclassified", or the banner can be omitted to disable secure printing
-functions.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean classify-override?
-Specifies whether users may override the classification (cover page) of
-individual print jobs using the @code{job-sheets} option.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} default-auth-type default-auth-type
-Specifies the default type of authentication to use.
-Defaults to @samp{Basic}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} default-encryption default-encryption
-Specifies whether encryption will be used for authenticated requests.
-Defaults to @samp{Required}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string default-language
-Specifies the default language to use for text and web content.
-Defaults to @samp{"en"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string default-paper-size
-Specifies the default paper size for new print queues.  @samp{"Auto"} uses a
-locale-specific default, while @samp{"None"} specifies there is no default
-paper size.  Specific size names are typically @samp{"Letter"} or
-@samp{"A4"}.
-Defaults to @samp{"Auto"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string default-policy
-Specifies the default access policy to use.
-Defaults to @samp{"default"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean default-shared?
-Specifies whether local printers are shared by default.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer dirty-clean-interval
-Specifies the delay for updating of configuration and state files, in
-seconds.  A value of 0 causes the update to happen as soon as possible,
-typically within a few milliseconds.
-Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} error-policy error-policy
-Specifies what to do when an error occurs.  Possible values are
-@code{abort-job}, which will discard the failed print job; @code{retry-job},
-which will retry the job at a later time; @code{retry-this-job}, which
-retries the failed job immediately; and @code{stop-printer}, which stops the
-printer.
-Defaults to @samp{stop-printer}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer filter-limit
-Specifies the maximum cost of filters that are run concurrently, which can
-be used to minimize disk, memory, and CPU resource problems.  A limit of 0
-disables filter limiting.  An average print to a non-PostScript printer
-needs a filter limit of about 200.  A PostScript printer needs about half
-that (100).  Setting the limit below these thresholds will effectively limit
-the scheduler to printing a single job at any time.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer filter-nice
-Specifies the scheduling priority of filters that are run to print a job.
-The nice value ranges from 0, the highest priority, to 19, the lowest
-priority.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} host-name-lookups host-name-lookups
-Specifies whether to do reverse lookups on connecting clients.  The
-@code{double} setting causes @code{cupsd} to verify that the hostname
-resolved from the address matches one of the addresses returned for that
-hostname.  Double lookups also prevent clients with unregistered addresses
-from connecting to your server.  Only set this option to @code{#t} or
-@code{double} if absolutely required.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer job-kill-delay
-Specifies the number of seconds to wait before killing the filters and
-backend associated with a canceled or held job.
-Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer job-retry-interval
-Specifies the interval between retries of jobs in seconds.  This is
-typically used for fax queues but can also be used with normal print queues
-whose error policy is @code{retry-job} or @code{retry-current-job}.
-Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer job-retry-limit
-Specifies the number of retries that are done for jobs.  This is typically
-used for fax queues but can also be used with normal print queues whose
-error policy is @code{retry-job} or @code{retry-current-job}.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean keep-alive?
-Specifies whether to support HTTP keep-alive connections.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer keep-alive-timeout
-Specifies how long an idle client connection remains open, in seconds.
-Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer limit-request-body
-Specifies the maximum size of print files, IPP requests, and HTML form
-data.  A limit of 0 disables the limit check.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} multiline-string-list listen
-Listens on the specified interfaces for connections.  Valid values are of
-the form @var{address}:@var{port}, where @var{address} is either an IPv6
-address enclosed in brackets, an IPv4 address, or @code{*} to indicate all
-addresses.  Values can also be file names of local UNIX domain sockets.  The
-Listen directive is similar to the Port directive but allows you to restrict
-access to specific interfaces or networks.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer listen-back-log
-Specifies the number of pending connections that will be allowed.  This
-normally only affects very busy servers that have reached the MaxClients
-limit, but can also be triggered by large numbers of simultaneous
-connections.  When the limit is reached, the operating system will refuse
-additional connections until the scheduler can accept the pending ones.
-Defaults to @samp{128}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} location-access-control-list location-access-controls
-Specifies a set of additional access controls.
-Available @code{location-access-controls} fields are:
-@deftypevr {@code{location-access-controls} parameter} file-name path
-Specifies the URI path to which the access control applies.
-@end deftypevr
-@deftypevr {@code{location-access-controls} parameter} access-control-list access-controls
-Access controls for all access to this path, in the same format as the
-@code{access-controls} of @code{operation-access-control}.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{location-access-controls} parameter} method-access-control-list method-access-controls
-Access controls for method-specific access to this path.
-Defaults to @samp{()}.
-Available @code{method-access-controls} fields are:
-@deftypevr {@code{method-access-controls} parameter} boolean reverse?
-If @code{#t}, apply access controls to all methods except the listed
-methods.  Otherwise apply to only the listed methods.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{method-access-controls} parameter} method-list methods
-Methods to which this access control applies.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{method-access-controls} parameter} access-control-list access-controls
-Access control directives, as a list of strings.  Each string should be one
-directive, such as "Order allow,deny".
-Defaults to @samp{()}.
-@end deftypevr
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer log-debug-history
-Specifies the number of debugging messages that are retained for logging if
-an error occurs in a print job.  Debug messages are logged regardless of the
-LogLevel setting.
-Defaults to @samp{100}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} log-level log-level
-Specifies the level of logging for the ErrorLog file.  The value @code{none}
-stops all logging while @code{debug2} logs everything.
-Defaults to @samp{info}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} log-time-format log-time-format
-Specifies the format of the date and time in the log files.  The value
-@code{standard} logs whole seconds while @code{usecs} logs microseconds.
-Defaults to @samp{standard}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-clients
-Specifies the maximum number of simultaneous clients that are allowed by the
-scheduler.
-Defaults to @samp{100}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-clients-per-host
-Specifies the maximum number of simultaneous clients that are allowed from a
-single address.
-Defaults to @samp{100}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-copies
-Specifies the maximum number of copies that a user can print of each job.
-Defaults to @samp{9999}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-hold-time
-Specifies the maximum time a job may remain in the @code{indefinite} hold
-state before it is canceled.  A value of 0 disables cancellation of held
-jobs.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs
-Specifies the maximum number of simultaneous jobs that are allowed.  Set to
-0 to allow an unlimited number of jobs.
-Defaults to @samp{500}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs-per-printer
-Specifies the maximum number of simultaneous jobs that are allowed per
-printer.  A value of 0 allows up to MaxJobs jobs per printer.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs-per-user
-Specifies the maximum number of simultaneous jobs that are allowed per
-user.  A value of 0 allows up to MaxJobs jobs per user.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-job-time
-Specifies the maximum time a job may take to print before it is canceled, in
-seconds.  Set to 0 to disable cancellation of "stuck" jobs.
-Defaults to @samp{10800}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer max-log-size
-Specifies the maximum size of the log files before they are rotated, in
-bytes.  The value 0 disables log rotation.
-Defaults to @samp{1048576}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer multiple-operation-timeout
-Specifies the maximum amount of time to allow between files in a multiple
-file print job, in seconds.
-Defaults to @samp{300}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string page-log-format
-Specifies the format of PageLog lines.  Sequences beginning with percent
-(@samp{%}) characters are replaced with the corresponding information, while
-all other characters are copied literally.  The following percent sequences
-are recognized:
-@table @samp
-@item %%
-insert a single percent character
-@item %@{name@}
-insert the value of the specified IPP attribute
-@item %C
-insert the number of copies for the current page
-@item %P
-insert the current page number
-@item %T
-insert the current date and time in common log format
-@item %j
-insert the job ID
-@item %p
-insert the printer name
-@item %u
-insert the username
-@end table
-A value of the empty string disables page logging.  The string @code{%p %u
-%j %T %P %C %@{job-billing@} %@{job-originating-host-name@} %@{job-name@}
-%@{media@} %@{sides@}} creates a page log with the standard items.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} environment-variables environment-variables
-Passes the specified environment variable(s) to child processes; a list of
-strings.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} policy-configuration-list policies
-Specifies named access control policies.
-Available @code{policy-configuration} fields are:
-@deftypevr {@code{policy-configuration} parameter} string name
-Name of the policy.
-@end deftypevr
-@deftypevr {@code{policy-configuration} parameter} string job-private-access
-Specifies an access list for a job's private values.  @code{@@ACL} maps to
-the printer's requesting-user-name-allowed or requesting-user-name-denied
-values.  @code{@@OWNER} maps to the job's owner.  @code{@@SYSTEM} maps to
-the groups listed for the @code{system-group} field of the
-@code{files-config} configuration, which is reified into the
-@code{cups-files.conf(5)} file.  Other possible elements of the access list
-include specific user names, and @code{@@@var{group}} to indicate members of
-a specific group.  The access list may also be simply @code{all} or
-@code{default}.
-Defaults to @samp{"@@OWNER @@SYSTEM"}.
-@end deftypevr
-@deftypevr {@code{policy-configuration} parameter} string job-private-values
-Specifies the list of job values to make private, or @code{all},
-@code{default}, or @code{none}.
-Defaults to @samp{"job-name job-originating-host-name
-job-originating-user-name phone"}.
-@end deftypevr
-@deftypevr {@code{policy-configuration} parameter} string subscription-private-access
-Specifies an access list for a subscription's private values.  @code{@@ACL}
-maps to the printer's requesting-user-name-allowed or
-requesting-user-name-denied values.  @code{@@OWNER} maps to the job's
-owner.  @code{@@SYSTEM} maps to the groups listed for the
-@code{system-group} field of the @code{files-config} configuration, which is
-reified into the @code{cups-files.conf(5)} file.  Other possible elements of
-the access list include specific user names, and @code{@@@var{group}} to
-indicate members of a specific group.  The access list may also be simply
-@code{all} or @code{default}.
-Defaults to @samp{"@@OWNER @@SYSTEM"}.
-@end deftypevr
-@deftypevr {@code{policy-configuration} parameter} string subscription-private-values
-Specifies the list of job values to make private, or @code{all},
-@code{default}, or @code{none}.
-Defaults to @samp{"notify-events notify-pull-method notify-recipient-uri
-notify-subscriber-user-name notify-user-data"}.
-@end deftypevr
-@deftypevr {@code{policy-configuration} parameter} operation-access-control-list access-controls
-Access control by IPP operation.
-Defaults to @samp{()}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean-or-non-negative-integer preserve-job-files
-Specifies whether job files (documents) are preserved after a job is
-printed.  If a numeric value is specified, job files are preserved for the
-indicated number of seconds after printing.  Otherwise a boolean value
-applies indefinitely.
-Defaults to @samp{86400}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean-or-non-negative-integer preserve-job-history
-Specifies whether the job history is preserved after a job is printed.  If a
-numeric value is specified, the job history is preserved for the indicated
-number of seconds after printing.  If @code{#t}, the job history is
-preserved until the MaxJobs limit is reached.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer reload-timeout
-Specifies the amount of time to wait for job completion before restarting
-the scheduler.
-Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string rip-cache
-Specifies the maximum amount of memory to use when converting documents into
-bitmaps for a printer.
-Defaults to @samp{"128m"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string server-admin
-Specifies the email address of the server administrator.
-Defaults to @samp{"root@@localhost.localdomain"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} host-name-list-or-* server-alias
-The ServerAlias directive is used for HTTP Host header validation when
-clients connect to the scheduler from external interfaces.  Using the
-special name @code{*} can expose your system to known browser-based DNS
-rebinding attacks, even when accessing sites through a firewall.  If the
-auto-discovery of alternate names does not work, we recommend listing each
-alternate name with a ServerAlias directive instead of using @code{*}.
-Defaults to @samp{*}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string server-name
-Specifies the fully-qualified host name of the server.
-Defaults to @samp{"localhost"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} server-tokens server-tokens
-Specifies what information is included in the Server header of HTTP
-responses.  @code{None} disables the Server header.  @code{ProductOnly}
-reports @code{CUPS}.  @code{Major} reports @code{CUPS 2}.  @code{Minor}
-reports @code{CUPS 2.0}.  @code{Minimal} reports @code{CUPS 2.0.0}.
-@code{OS} reports @code{CUPS 2.0.0 (@var{uname})} where @var{uname} is the
-output of the @code{uname} command.  @code{Full} reports @code{CUPS 2.0.0
-(@var{uname}) IPP/2.0}.
-Defaults to @samp{Minimal}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} string set-env
-Set the specified environment variable to be passed to child processes.
-Defaults to @samp{"variable value"}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} multiline-string-list ssl-listen
-Listens on the specified interfaces for encrypted connections.  Valid values
-are of the form @var{address}:@var{port}, where @var{address} is either an
-IPv6 address enclosed in brackets, an IPv4 address, or @code{*} to indicate
-all addresses.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} ssl-options ssl-options
-Sets encryption options.  By default, CUPS only supports encryption using
-TLS v1.0 or higher using known secure cipher suites.  The @code{AllowRC4}
-option enables the 128-bit RC4 cipher suites, which are required for some
-older clients that do not implement newer ones.  The @code{AllowSSL3} option
-enables SSL v3.0, which is required for some older clients that do not
-support TLS v1.0.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean strict-conformance?
-Specifies whether the scheduler requires clients to strictly adhere to the
-IPP specifications.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} non-negative-integer timeout
-Specifies the HTTP request timeout, in seconds.
-Defaults to @samp{300}.
-@end deftypevr
-@deftypevr {@code{cups-configuration} parameter} boolean web-interface?
-Specifies whether the web interface is enabled.
-Defaults to @samp{#f}.
-@end deftypevr
-At this point you're probably thinking ``oh dear, Guix manual, I like you
-but you can stop already with the configuration options''.  Indeed.
-However, one more point: it could be that you have an existing
-@code{cupsd.conf} that you want to use.  In that case, you can pass an
-@code{opaque-cups-configuration} as the configuration of a
-@code{cups-service-type}.
-Available @code{opaque-cups-configuration} fields are:
-@deftypevr {@code{opaque-cups-configuration} parameter} package cups
-The CUPS package.
-@end deftypevr
-@deftypevr {@code{opaque-cups-configuration} parameter} string cupsd.conf
-The contents of the @code{cupsd.conf}, as a string.
-@end deftypevr
-@deftypevr {@code{opaque-cups-configuration} parameter} string cups-files.conf
-The contents of the @code{cups-files.conf} file, as a string.
-@end deftypevr
-For example, if your @code{cupsd.conf} and @code{cups-files.conf} are in
-strings of the same name, you could instantiate a CUPS service like this:
-@example
-(service cups-service-type
-         (opaque-cups-configuration
-           (cupsd.conf cupsd.conf)
-           (cups-files.conf cups-files.conf)))
-@end example
-@node Desktop-Dienste
-@subsection Desktop-Dienste
-The @code{(gnu services desktop)} module provides services that are usually
-useful in the context of a ``desktop'' setup---that is, on a machine running
-a graphical display server, possibly with graphical user interfaces, etc.
-It also defines services that provide specific desktop environments like
-GNOME, Xfce or MATE.
-To simplify things, the module defines a variable containing the set of
-services that users typically expect on a machine with a graphical
-environment and networking:
-@defvr {Scheme Variable} %desktop-services
-This is a list of services that builds upon @var{%base-services} and adds or
-adjusts services for a typical ``desktop'' setup.
-In particular, it adds a graphical login manager (@pxref{X Window,
-@code{gdm-service-type}}), screen lockers, a network management tool
-(@pxref{Netzwerkdienste, @code{network-manager-service-type}}), energy
-and color management services, the @code{elogind} login and seat manager,
-the Polkit privilege service, the GeoClue location service, the
-AccountsService daemon that allows authorized users change system passwords,
-an NTP client (@pxref{Netzwerkdienste}), the Avahi daemon, and has the
-name service switch service configured to be able to use @code{nss-mdns}
-(@pxref{Name Service Switch, mDNS}).
-@end defvr
-The @var{%desktop-services} variable can be used as the @code{services}
-field of an @code{operating-system} declaration (@pxref{»operating-system«-Referenz, @code{services}}).
-Additionally, the @code{gnome-desktop-service-type},
-@code{xfce-desktop-service}, @code{mate-desktop-service-type} and
-@code{enlightenment-desktop-service-type} procedures can add GNOME, Xfce,
-MATE and/or Enlightenment to a system.  To ``add GNOME'' means that
-system-level services like the backlight adjustment helpers and the power
-management utilities are added to the system, extending @code{polkit} and
-@code{dbus} appropriately, allowing GNOME to operate with elevated
-privileges on a limited number of special-purpose system interfaces.
-Additionally, adding a service made by @code{gnome-desktop-service-type}
-adds the GNOME metapackage to the system profile.  Likewise, adding the Xfce
-service not only adds the @code{xfce} metapackage to the system profile, but
-it also gives the Thunar file manager the ability to open a ``root-mode''
-file management window, if the user authenticates using the administrator's
-password via the standard polkit graphical interface.  To ``add MATE'' means
-that @code{polkit} and @code{dbus} are extended appropriately, allowing MATE
-to operate with elevated privileges on a limited number of special-purpose
-system interfaces.  Additionally, adding a service of type
-@code{mate-desktop-service-type} adds the MATE metapackage to the system
-profile.  ``Adding Enlightenment'' means that @code{dbus} is extended
-appropriately, and several of Enlightenment's binaries are set as setuid,
-allowing Enlightenment's screen locker and other functionality to work as
-expetected.
-The desktop environments in Guix use the Xorg display server by default.  If
-you'd like to use the newer display server protocol called Wayland, you need
-to use the @code{sddm-service} instead of GDM as the graphical login
-manager.  You should then select the ``GNOME (Wayland)'' session in SDDM.
-Alternatively you can also try starting GNOME on Wayland manually from a TTY
-with the command ``XDG_SESSION_TYPE=wayland exec dbus-run-session
-gnome-session``.  Currently only GNOME has support for Wayland.
-@defvr {Scheme-Variable} gnome-desktop-service-type
-Dies ist der Typ des Dienstes, der die @uref{https://www.gnome.org,
-GNOME}-Arbeitsumgebung bereitstellt. Sein Wert ist ein
-@code{gnome-desktop-configuration}-Objekt (siehe unten).
-This service adds the @code{gnome} package to the system profile, and
-extends polkit with the actions from @code{gnome-settings-daemon}.
-@end defvr
-@deftp {Datentyp} gnome-desktop-configuration
-Configuration record for the GNOME desktop environment.
-@table @asis
-@item @code{gnome} (Vorgabe: @code{gnome})
-Welches GNOME-Paket benutzt werden soll.
-@end table
-@end deftp
-@defvr {Scheme-Variable} xfce-desktop-service-type
-Der Typ des Dienstes, um die @uref{Xfce, https://xfce.org/}-Arbeitsumgebung
-auszuführen. Sein Wert ist ein @code{xfce-desktop-configuration}-Objekt
-(siehe unten).
-This service that adds the @code{xfce} package to the system profile, and
-extends polkit with the ability for @code{thunar} to manipulate the file
-system as root from within a user session, after the user has authenticated
-with the administrator's password.
-@end defvr
-@deftp {Datentyp} xfce-desktop-configuration
-Verbundstyp für Einstellungen zur Xfce-Arbeitsumgebung.
-@table @asis
-@item @code{xfce} (Vorgabe: @code{xfce})
-Das Xfce-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@deffn {Scheme-Variable} mate-desktop-service-type
-Dies ist der Typ des Dienstes, um die @uref{https://mate-desktop.org/,
-MATE-Arbeitsumgebung} auszuführen. Sein Wert ist ein
-@code{mate-desktop-configuration}-Objekt (siehe unten).
-This service adds the @code{mate} package to the system profile, and extends
-polkit with the actions from @code{mate-settings-daemon}.
-@end deffn
-@deftp {Datentyp} mate-desktop-configuration
-Verbundstyp für die Einstellungen der MATE-Arbeitsumgebung.
-@table @asis
-@item @code{mate} (Vorgabe: @code{mate})
-Das MATE-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@deffn {Scheme-Variable} enlightenment-desktop-service-type
-Return a service that adds the @code{enlightenment} package to the system
-profile, and extends dbus with actions from @code{efl}.
-@end deffn
-@deftp {Data Type} enlightenment-desktop-service-configuration
-@table @asis
-@item @code{enlightenment} (Vorgabe: @code{enlightenment})
-Das Enlightenment-Paket, was benutzt werden soll.
-@end table
-@end deftp
-Because the GNOME, Xfce and MATE desktop services pull in so many packages,
-the default @code{%desktop-services} variable doesn't include any of them by
-default.  To add GNOME, Xfce or MATE, just @code{cons} them onto
-@code{%desktop-services} in the @code{services} field of your
-@code{operating-system}:
-@example
-(use-modules (gnu))
-(use-service-modules desktop)
-(operating-system
-  ...
-  ;; cons* adds items to the list given as its last argument.
-  (services (cons* (service gnome-desktop-service-type)
-                   (service xfce-desktop-service)
-                   %desktop-services))
-  ...)
-@end example
-These desktop environments will then be available as options in the
-graphical login window.
-The actual service definitions included in @code{%desktop-services} and
-provided by @code{(gnu services dbus)} and @code{(gnu services desktop)} are
-described below.
-@deffn {Scheme Procedure} dbus-service [#:dbus @var{dbus}] [#:services '()]
-Return a service that runs the ``system bus'', using @var{dbus}, with
-support for @var{services}.
-@uref{http://dbus.freedesktop.org/, D-Bus} is an inter-process communication
-facility.  Its system bus is used to allow system services to communicate
-and to be notified of system-wide events.
-@var{services} must be a list of packages that provide an
-@file{etc/dbus-1/system.d} directory containing additional D-Bus
-configuration and policy files.  For example, to allow avahi-daemon to use
-the system bus, @var{services} must be equal to @code{(list avahi)}.
-@end deffn
-@deffn {Scheme Procedure} elogind-service [#:config @var{config}]
-Return a service that runs the @code{elogind} login and seat management
-daemon.  @uref{https://github.com/elogind/elogind, Elogind} exposes a D-Bus
-interface that can be used to know which users are logged in, know what kind
-of sessions they have open, suspend the system, inhibit system suspend,
-reboot the system, and other tasks.
-Elogind handles most system-level power events for a computer, for example
-suspending the system when a lid is closed, or shutting it down when the
-power button is pressed.
-The @var{config} keyword argument specifies the configuration for elogind,
-and should be the result of an @code{(elogind-configuration (@var{parameter}
-@var{value})...)} invocation.  Available parameters and their default values
-are:
-@table @code
-@item kill-user-processes?
-@code{#f}
-@item kill-only-users
-@code{()}
-@item kill-exclude-users
-@code{("root")}
-@item inhibit-delay-max-seconds
-@code{5}
-@item handle-power-key
-@code{poweroff}
-@item handle-suspend-key
-@code{suspend}
-@item handle-hibernate-key
-@code{hibernate}
-@item handle-lid-switch
-@code{suspend}
-@item handle-lid-switch-docked
-@code{ignore}
-@item power-key-ignore-inhibited?
-@code{#f}
-@item suspend-key-ignore-inhibited?
-@code{#f}
-@item hibernate-key-ignore-inhibited?
-@code{#f}
-@item lid-switch-ignore-inhibited?
-@code{#t}
-@item holdoff-timeout-seconds
-@code{30}
-@item idle-action
-@code{ignore}
-@item idle-action-seconds
-@code{(* 30 60)}
-@item runtime-directory-size-percent
-@code{10}
-@item runtime-directory-size
-@code{#f}
-@item remove-ipc?
-@code{#t}
-@item suspend-state
-@code{("mem" "standby" "freeze")}
-@item suspend-mode
-@code{()}
-@item hibernate-state
-@code{("disk")}
-@item hibernate-mode
-@code{("platform" "shutdown")}
-@item hybrid-sleep-state
-@code{("disk")}
-@item hybrid-sleep-mode
-@code{("suspend" "platform" "shutdown")}
-@end table
-@end deffn
-@deffn {Scheme Procedure} accountsservice-service @
-       [#:accountsservice @var{accountsservice}] Return a service that runs
-AccountsService, a system service that can list available accounts, change
-their passwords, and so on.  AccountsService integrates with PolicyKit to
-enable unprivileged users to acquire the capability to modify their system
-configuration.
-@uref{https://www.freedesktop.org/wiki/Software/AccountsService/, the
-accountsservice web site} for more information.
-The @var{accountsservice} keyword argument is the @code{accountsservice}
-package to expose as a service.
-@end deffn
-@deffn {Scheme Procedure} polkit-service @
-                         [#:polkit @var{polkit}] Return a service that runs the
-@uref{http://www.freedesktop.org/wiki/Software/polkit/, Polkit privilege
-management service}, which allows system administrators to grant access to
-privileged operations in a structured way.  By querying the Polkit service,
-a privileged system component can know when it should grant additional
-capabilities to ordinary users.  For example, an ordinary user can be
-granted the capability to suspend the system if the user is logged in
-locally.
-@end deffn
-@defvr {Scheme-Variable} upower-service-type
-Service that runs @uref{http://upower.freedesktop.org/, @command{upowerd}},
-a system-wide monitor for power consumption and battery levels, with the
-given configuration settings.
-It implements the @code{org.freedesktop.UPower} D-Bus interface, and is
-notably used by GNOME.
-@end defvr
-@deftp {Datentyp} upower-configuration
-Repräsentiert die Konfiguration von UPower.
-@table @asis
-@item @code{upower} (Vorgabe: @var{upower})
-Package to use for @code{upower}.
-@item @code{watts-up-pro?} (Vorgabe: @code{#f})
-Enable the Watts Up Pro device.
-@item @code{poll-batteries?} (Vorgabe: @code{#t})
-Enable polling the kernel for battery level changes.
-@item @code{ignore-lid?} (Vorgabe: @code{#f})
-Ignore the lid state, this can be useful if it's incorrect on a device.
-@item @code{use-percentage-for-policy?} (Vorgabe: @code{#f})
-Whether battery percentage based policy should be used.  The default is to
-use the time left, change to @code{#t} to use the percentage.
-@item @code{percentage-low} (Vorgabe: @code{10})
-When @code{use-percentage-for-policy?} is @code{#t}, this sets the
-percentage at which the battery is considered low.
-@item @code{percentage-critical} (Vorgabe: @code{3})
-When @code{use-percentage-for-policy?} is @code{#t}, this sets the
-percentage at which the battery is considered critical.
-@item @code{percentage-action} (Vorgabe: @code{2})
-When @code{use-percentage-for-policy?} is @code{#t}, this sets the
-percentage at which action will be taken.
-@item @code{time-low} (Vorgabe: @code{1200})
-When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining
-in seconds at which the battery is considered low.
-@item @code{time-critical} (Vorgabe: @code{300})
-When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining
-in seconds at which the battery is considered critical.
-@item @code{time-action} (Vorgabe: @code{120})
-When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining
-in seconds at which action will be taken.
-@item @code{critical-power-action} (Vorgabe: @code{'hybrid-sleep})
-The action taken when @code{percentage-action} or @code{time-action} is
-reached (depending on the configuration of
-@code{use-percentage-for-policy?}).
-Possible values are:
-@itemize @bullet
-@item
-@code{'power-off}
-@item
-@code{'hibernate}
-@item
-@code{'hybrid-sleep}.
-@end itemize
-@end table
-@end deftp
-@deffn {Scheme Procedure} udisks-service [#:udisks @var{udisks}]
-Return a service for @uref{http://udisks.freedesktop.org/docs/latest/,
-UDisks}, a @dfn{disk management} daemon that provides user interfaces with
-notifications and ways to mount/unmount disks.  Programs that talk to UDisks
-include the @command{udisksctl} command, part of UDisks, and GNOME Disks.
-@end deffn
-@deffn {Scheme Procedure} colord-service [#:colord @var{colord}]
-Return a service that runs @command{colord}, a system service with a D-Bus
-interface to manage the color profiles of input and output devices such as
-screens and scanners.  It is notably used by the GNOME Color Manager
-graphical tool.  See @uref{http://www.freedesktop.org/software/colord/, the
-colord web site} for more information.
-@end deffn
-@deffn {Scheme Procedure} geoclue-application name [#:allowed? #t] [#:system? #f] [#:users '()]
-Return a configuration allowing an application to access GeoClue location
-data.  @var{name} is the Desktop ID of the application, without the
-@code{.desktop} part.  If @var{allowed?} is true, the application will have
-access to location information by default.  The boolean @var{system?} value
-indicates whether an application is a system component or not.  Finally
-@var{users} is a list of UIDs of all users for which this application is
-allowed location info access.  An empty users list means that all users are
-allowed.
-@end deffn
-@defvr {Scheme Variable} %standard-geoclue-applications
-The standard list of well-known GeoClue application configurations, granting
-authority to the GNOME date-and-time utility to ask for the current location
-in order to set the time zone, and allowing the IceCat and Epiphany web
-browsers to request location information.  IceCat and Epiphany both query
-the user before allowing a web page to know the user's location.
-@end defvr
-@deffn {Scheme Procedure} geoclue-service [#:colord @var{colord}] @
-                         [#:whitelist '()] @ [#:wifi-geolocation-url
-"https://location.services.mozilla.com/v1/geolocate?key=geoclue"] @
-[#:submit-data? #f] [#:wifi-submission-url
-"https://location.services.mozilla.com/v1/submit?key=geoclue"] @
-[#:submission-nick "geoclue"] @ [#:applications
-%standard-geoclue-applications] Return a service that runs the GeoClue
-location service.  This service provides a D-Bus interface to allow
-applications to request access to a user's physical location, and optionally
-to add information to online location databases.  See
-@uref{https://wiki.freedesktop.org/www/Software/GeoClue/, the GeoClue web
-site} for more information.
-@end deffn
-@deffn {Scheme Procedure} bluetooth-service [#:bluez @var{bluez}] @
-       [@w{#:auto-enable? #f}] Return a service that runs the @command{bluetoothd}
-daemon, which manages all the Bluetooth devices and provides a number of
-D-Bus interfaces.  When AUTO-ENABLE? is true, the bluetooth controller is
-powered automatically at boot, which can be useful when using a bluetooth
-keyboard or mouse.
-Users need to be in the @code{lp} group to access the D-Bus service.
-@end deffn
-@node Tondienste
-@subsection Tondienste
-@cindex sound support
-@cindex ALSA
-@cindex PulseAudio, sound support
-The @code{(gnu services sound)} module provides a service to configure the
-Advanced Linux Sound Architecture (ALSA) system, which makes PulseAudio the
-preferred ALSA output driver.
-@deffn {Scheme Variable} alsa-service-type
-This is the type for the @uref{https://alsa-project.org/, Advanced Linux
-Sound Architecture} (ALSA) system, which generates the
-@file{/etc/asound.conf} configuration file.  The value for this type is a
-@command{alsa-configuration} record as in this example:
-@example
-(service alsa-service-type)
-@end example
-See below for details about @code{alsa-configuration}.
-@end deffn
-@deftp {Datentyp} alsa-configuration
-Repräsentiert die Konfiguration für den Dienst @code{alsa-service}.
-@table @asis
-@item @code{alsa-plugins} (Vorgabe: @var{alsa-plugins})
-@code{alsa-plugins}-Paket, was benutzt werden soll.
-@item @code{pulseaudio?} (Vorgabe: @var{#t})
-Whether ALSA applications should transparently be made to use the
-@uref{http://www.pulseaudio.org/, PulseAudio} sound server.
-Using PulseAudio allows you to run several sound-producing applications at
-the same time and to individual control them @i{via} @command{pavucontrol},
-among other things.
-@item @code{extra-options} (Vorgabe: @var{""})
-String to append to the @file{/etc/asound.conf} file.
-@end table
-@end deftp
-Individual users who want to override the system configuration of ALSA can
-do it with the @file{~/.asoundrc} file:
-@example
-# In guix, we have to specify the absolute path for plugins.
-pcm_type.jack @{
-  lib "/home/alice/.guix-profile/lib/alsa-lib/libasound_module_pcm_jack.so"
-@}
-# Routing ALSA to jack:
-# <http://jackaudio.org/faq/routing_alsa.html>.
-pcm.rawjack @{
-  type jack
-  playback_ports @{
-    0 system:playback_1
-    1 system:playback_2
-  @}
-  capture_ports @{
-    0 system:capture_1
-    1 system:capture_2
-  @}
-@}
-pcm.!default @{
-  type plug
-  slave @{
-    pcm "rawjack"
-  @}
-@}
-@end example
-See @uref{https://www.alsa-project.org/main/index.php/Asoundrc} for the
-details.
-@node Datenbankdienste
-@subsection Datenbankdienste
-@cindex Datenbank
-@cindex SQL
-The @code{(gnu services databases)} module provides the following services.
-@deffn {Scheme Procedure} postgresql-service [#:postgresql postgresql] @
-       [#:config-file] [#:data-directory ``/var/lib/postgresql/data''] @ [#:port
-5432] [#:locale ``en_US.utf8''] [#:extension-packages '()] Return a service
-that runs @var{postgresql}, the PostgreSQL database server.
-The PostgreSQL daemon loads its runtime configuration from
-@var{config-file}, creates a database cluster with @var{locale} as the
-default locale, stored in @var{data-directory}.  It then listens on
-@var{port}.
-@cindex postgresql extension-packages
-Additional extensions are loaded from packages listed in
-@var{extension-packages}.  Extensions are available at runtime.  For
-instance, to create a geographic database using the @code{postgis}
-extension, a user can configure the postgresql-service as in this example:
-@cindex postgis
-@example
-(use-package-modules databases geo)
-(operating-system
-  …
-  ;; postgresql wird benötigt, um »psql« auszuführen, aber postgis ist
-  ;; für den Betrieb nicht unbedingt notwendig.
-  (packages (cons* postgresql %base-packages))
-  (services
-    (cons*
-      (postgresql-service #:extension-packages (list postgis))
-      %base-services)))
-@end example
-Then the extension becomes visible and you can initialise an empty
-geographic database in this way:
-@example
-psql -U postgres
-> create database postgistest;
-> \connect postgistest;
-> create extension postgis;
-> create extension postgis_topology;
-@end example
-There is no need to add this field for contrib extensions such as hstore or
-dblink as they are already loadable by postgresql.  This field is only
-required to add extensions provided by other packages.
-@end deffn
-@deffn {Scheme Procedure} mysql-service [#:config (mysql-configuration)]
-Return a service that runs @command{mysqld}, the MySQL or MariaDB database
-server.
-The optional @var{config} argument specifies the configuration for
-@command{mysqld}, which should be a @code{<mysql-configuration>} object.
-@end deffn
-@deftp {Data Type} mysql-configuration
-Data type representing the configuration of @var{mysql-service}.
-@table @asis
-@item @code{mysql} (default: @var{mariadb})
-Package object of the MySQL database server, can be either @var{mariadb} or
-@var{mysql}.
-For MySQL, a temporary root password will be displayed at activation time.
-For MariaDB, the root password is empty.
-@item @code{port} (default: @code{3306})
-TCP port on which the database server listens for incoming connections.
-@end table
-@end deftp
-@defvr {Scheme Variable} memcached-service-type
-This is the service type for the @uref{https://memcached.org/, Memcached}
-service, which provides a distributed in memory cache.  The value for the
-service type is a @code{memcached-configuration} object.
-@end defvr
-@example
-(service memcached-service-type)
-@end example
-@deftp {Data Type} memcached-configuration
-Data type representing the configuration of memcached.
-@table @asis
-@item @code{memcached} (default: @code{memcached})
-The Memcached package to use.
-@item @code{interfaces} (default: @code{'("0.0.0.0")})
-Network interfaces on which to listen.
-@item @code{tcp-port} (default: @code{11211})
-Port on which to accept connections on,
-@item @code{udp-port} (default: @code{11211})
-Port on which to accept UDP connections on, a value of 0 will disable
-listening on a UDP socket.
-@item @code{additional-options} (default: @code{'()})
-Additional command line options to pass to @code{memcached}.
-@end table
-@end deftp
-@defvr {Scheme Variable} mongodb-service-type
-This is the service type for @uref{https://www.mongodb.com/, MongoDB}.  The
-value for the service type is a @code{mongodb-configuration} object.
-@end defvr
-@example
-(service mongodb-service-type)
-@end example
-@deftp {Data Type} mongodb-configuration
-Data type representing the configuration of mongodb.
-@table @asis
-@item @code{mongodb} (default: @code{mongodb})
-The MongoDB package to use.
-@item @code{config-file} (default: @code{%default-mongodb-configuration-file})
-The configuration file for MongoDB.
-@item @code{data-directory} (default: @code{"/var/lib/mongodb"})
-This value is used to create the directory, so that it exists and is owned
-by the mongodb user.  It should match the data-directory which MongoDB is
-configured to use through the configuration file.
-@end table
-@end deftp
-@defvr {Scheme Variable} redis-service-type
-This is the service type for the @uref{https://redis.io/, Redis} key/value
-store, whose value is a @code{redis-configuration} object.
-@end defvr
-@deftp {Data Type} redis-configuration
-Data type representing the configuration of redis.
-@table @asis
-@item @code{redis} (default: @code{redis})
-The Redis package to use.
-@item @code{bind} (default: @code{"127.0.0.1"})
-Network interface on which to listen.
-@item @code{port} (default: @code{6379})
-Port on which to accept connections on, a value of 0 will disable listening
-on a TCP socket.
-@item @code{working-directory} (default: @code{"/var/lib/redis"})
-Directory in which to store the database and related files.
-@end table
-@end deftp
-@node Mail-Dienste
-@subsection Mail-Dienste
-@cindex mail
-@cindex email
-The @code{(gnu services mail)} module provides Guix service definitions for
-email services: IMAP, POP3, and LMTP servers, as well as mail transport
-agents (MTAs).  Lots of acronyms! These services are detailed in the
-subsections below.
-@subsubheading Dovecot Service
-@deffn {Scheme Procedure} dovecot-service [#:config (dovecot-configuration)]
-Return a service that runs the Dovecot IMAP/POP3/LMTP mail server.
-@end deffn
-By default, Dovecot does not need much configuration; the default
-configuration object created by @code{(dovecot-configuration)} will suffice
-if your mail is delivered to @code{~/Maildir}.  A self-signed certificate
-will be generated for TLS-protected connections, though Dovecot will also
-listen on cleartext ports by default.  There are a number of options,
-though, which mail administrators might need to change, and as is the case
-with other services, Guix allows the system administrator to specify these
-parameters via a uniform Scheme interface.
-For example, to specify that mail is located at @code{maildir~/.mail}, one
-would instantiate the Dovecot service like this:
-@example
-(dovecot-service #:config
-                 (dovecot-configuration
-                  (mail-location "maildir:~/.mail")))
-@end example
-The available configuration parameters follow.  Each parameter definition is
-preceded by its type; for example, @samp{string-list foo} indicates that the
-@code{foo} parameter should be specified as a list of strings.  There is
-also a way to specify the configuration as a string, if you have an old
-@code{dovecot.conf} file that you want to port over from some other system;
-see the end for more details.
-@c The following documentation was initially generated by
-@c (generate-documentation) in (gnu services mail).  Manually maintained
-@c documentation is better, so we shouldn't hesitate to edit below as
-@c needed.  However if the change you want to make to this documentation
-@c can be done in an automated way, it's probably easier to change
-@c (generate-documentation) than to make it below and have to deal with
-@c the churn as dovecot updates.
-Available @code{dovecot-configuration} fields are:
-@deftypevr {@code{dovecot-configuration} parameter} package dovecot
-The dovecot package.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} comma-separated-string-list listen
-A list of IPs or hosts where to listen for connections.  @samp{*} listens on
-all IPv4 interfaces, @samp{::} listens on all IPv6 interfaces.  If you want
-to specify non-default ports or anything more complex, customize the address
-and port fields of the @samp{inet-listener} of the specific services you are
-interested in.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} protocol-configuration-list protocols
-List of protocols we want to serve.  Available protocols include
-@samp{imap}, @samp{pop3}, and @samp{lmtp}.
-Available @code{protocol-configuration} fields are:
-@deftypevr {@code{protocol-configuration} parameter} string name
-The name of the protocol.
-@end deftypevr
-@deftypevr {@code{protocol-configuration} parameter} string auth-socket-path
-UNIX socket path to the master authentication server to find users.  This is
-used by imap (for shared users) and lda.  It defaults to
-@samp{"/var/run/dovecot/auth-userdb"}.
-@end deftypevr
-@deftypevr {@code{protocol-configuration} parameter} space-separated-string-list mail-plugins
-Space separated list of plugins to load.
-@end deftypevr
-@deftypevr {@code{protocol-configuration} parameter} non-negative-integer mail-max-userip-connections
-Maximum number of IMAP connections allowed for a user from each IP address.
-NOTE: The username is compared case-sensitively.  Defaults to @samp{10}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} service-configuration-list services
-List of services to enable.  Available services include @samp{imap},
-@samp{imap-login}, @samp{pop3}, @samp{pop3-login}, @samp{auth}, and
-@samp{lmtp}.
-Available @code{service-configuration} fields are:
-@deftypevr {@code{service-configuration} parameter} string kind
-The service kind.  Valid values include @code{director}, @code{imap-login},
-@code{pop3-login}, @code{lmtp}, @code{imap}, @code{pop3}, @code{auth},
-@code{auth-worker}, @code{dict}, @code{tcpwrap}, @code{quota-warning}, or
-anything else.
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} listener-configuration-list listeners
-Listeners for the service.  A listener is either a
-@code{unix-listener-configuration}, a @code{fifo-listener-configuration}, or
-an @code{inet-listener-configuration}.  Defaults to @samp{()}.
-Available @code{unix-listener-configuration} fields are:
-@deftypevr {@code{unix-listener-configuration} parameter} string path
-Path to the file, relative to @code{base-dir} field.  This is also used as
-the section name.
-@end deftypevr
-@deftypevr {@code{unix-listener-configuration} parameter} string mode
-The access mode for the socket.  Defaults to @samp{"0600"}.
-@end deftypevr
-@deftypevr {@code{unix-listener-configuration} parameter} string user
-The user to own the socket.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{unix-listener-configuration} parameter} string group
-The group to own the socket.  Defaults to @samp{""}.
-@end deftypevr
-Available @code{fifo-listener-configuration} fields are:
-@deftypevr {@code{fifo-listener-configuration} parameter} string path
-Path to the file, relative to @code{base-dir} field.  This is also used as
-the section name.
-@end deftypevr
-@deftypevr {@code{fifo-listener-configuration} parameter} string mode
-The access mode for the socket.  Defaults to @samp{"0600"}.
-@end deftypevr
-@deftypevr {@code{fifo-listener-configuration} parameter} string user
-The user to own the socket.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{fifo-listener-configuration} parameter} string group
-The group to own the socket.  Defaults to @samp{""}.
-@end deftypevr
-Available @code{inet-listener-configuration} fields are:
-@deftypevr {@code{inet-listener-configuration} parameter} string protocol
-The protocol to listen for.
-@end deftypevr
-@deftypevr {@code{inet-listener-configuration} parameter} string address
-The address on which to listen, or empty for all addresses.  Defaults to
-@samp{""}.
-@end deftypevr
-@deftypevr {@code{inet-listener-configuration} parameter} non-negative-integer port
-The port on which to listen.
-@end deftypevr
-@deftypevr {@code{inet-listener-configuration} parameter} boolean ssl?
-Whether to use SSL for this service; @samp{yes}, @samp{no}, or
-@samp{required}.  Defaults to @samp{#t}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} non-negative-integer client-limit
-Maximum number of simultaneous client connections per process.  Once this
-number of connections is received, the next incoming connection will prompt
-Dovecot to spawn another process.  If set to 0, @code{default-client-limit}
-is used instead.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} non-negative-integer service-count
-Number of connections to handle before starting a new process.  Typically
-the only useful values are 0 (unlimited) or 1.  1 is more secure, but 0 is
-faster.  <doc/wiki/LoginProcess.txt>.  Defaults to @samp{1}.
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} non-negative-integer process-limit
-Maximum number of processes that can exist for this service.  If set to 0,
-@code{default-process-limit} is used instead.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} non-negative-integer process-min-avail
-Number of processes to always keep waiting for more connections.  Defaults
-to @samp{0}.
-@end deftypevr
-@deftypevr {@code{service-configuration} parameter} non-negative-integer vsz-limit
-If you set @samp{service-count 0}, you probably need to grow this.  Defaults
-to @samp{256000000}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} dict-configuration dict
-Dict configuration, as created by the @code{dict-configuration} constructor.
-Available @code{dict-configuration} fields are:
-@deftypevr {@code{dict-configuration} parameter} free-form-fields entries
-A list of key-value pairs that this dict should hold.  Defaults to
-@samp{()}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} passdb-configuration-list passdbs
-A list of passdb configurations, each one created by the
-@code{passdb-configuration} constructor.
-Available @code{passdb-configuration} fields are:
-@deftypevr {@code{passdb-configuration} parameter} string driver
-The driver that the passdb should use.  Valid values include @samp{pam},
-@samp{passwd}, @samp{shadow}, @samp{bsdauth}, and @samp{static}.  Defaults
-to @samp{"pam"}.
-@end deftypevr
-@deftypevr {@code{passdb-configuration} parameter} space-separated-string-list args
-Space separated list of arguments to the passdb driver.  Defaults to
-@samp{""}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} userdb-configuration-list userdbs
-List of userdb configurations, each one created by the
-@code{userdb-configuration} constructor.
-Available @code{userdb-configuration} fields are:
-@deftypevr {@code{userdb-configuration} parameter} string driver
-The driver that the userdb should use.  Valid values include @samp{passwd}
-and @samp{static}.  Defaults to @samp{"passwd"}.
-@end deftypevr
-@deftypevr {@code{userdb-configuration} parameter} space-separated-string-list args
-Space separated list of arguments to the userdb driver.  Defaults to
-@samp{""}.
-@end deftypevr
-@deftypevr {@code{userdb-configuration} parameter} free-form-args override-fields
-Override fields from passwd.  Defaults to @samp{()}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} plugin-configuration plugin-configuration
-Plug-in configuration, created by the @code{plugin-configuration}
-constructor.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} list-of-namespace-configuration namespaces
-List of namespaces.  Each item in the list is created by the
-@code{namespace-configuration} constructor.
-Available @code{namespace-configuration} fields are:
-@deftypevr {@code{namespace-configuration} parameter} string name
-Name for this namespace.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} string type
-Namespace type: @samp{private}, @samp{shared} or @samp{public}.  Defaults to
-@samp{"private"}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} string separator
-Hierarchy separator to use. You should use the same separator for all
-namespaces or some clients get confused.  @samp{/} is usually a good one.
-The default however depends on the underlying mail storage format.  Defaults
-to @samp{""}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} string prefix
-Prefix required to access this namespace.  This needs to be different for
-all namespaces. For example @samp{Public/}.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} string location
-Physical location of the mailbox. This is in the same format as
-mail_location, which is also the default for it.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} boolean inbox?
-There can be only one INBOX, and this setting defines which namespace has
-it.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} boolean hidden?
-If namespace is hidden, it's not advertised to clients via NAMESPACE
-extension. You'll most likely also want to set @samp{list? #f}.  This is
-mostly useful when converting from another server with different namespaces
-which you want to deprecate but still keep working.  For example you can
-create hidden namespaces with prefixes @samp{~/mail/}, @samp{~%u/mail/} and
-@samp{mail/}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} boolean list?
-Show the mailboxes under this namespace with the LIST command. This makes
-the namespace visible for clients that do not support the NAMESPACE
-extension.  The special @code{children} value lists child mailboxes, but
-hides the namespace prefix.  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} boolean subscriptions?
-Namespace handles its own subscriptions.  If set to @code{#f}, the parent
-namespace handles them.  The empty prefix should always have this as
-@code{#t}).  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{namespace-configuration} parameter} mailbox-configuration-list mailboxes
-List of predefined mailboxes in this namespace.  Defaults to @samp{()}.
-Available @code{mailbox-configuration} fields are:
-@deftypevr {@code{mailbox-configuration} parameter} string name
-Name for this mailbox.
-@end deftypevr
-@deftypevr {@code{mailbox-configuration} parameter} string auto
-@samp{create} will automatically create this mailbox.  @samp{subscribe} will
-both create and subscribe to the mailbox.  Defaults to @samp{"no"}.
-@end deftypevr
-@deftypevr {@code{mailbox-configuration} parameter} space-separated-string-list special-use
-List of IMAP @code{SPECIAL-USE} attributes as specified by RFC 6154.  Valid
-values are @code{\All}, @code{\Archive}, @code{\Drafts}, @code{\Flagged},
-@code{\Junk}, @code{\Sent}, and @code{\Trash}.  Defaults to @samp{()}.
-@end deftypevr
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name base-dir
-Base directory where to store runtime data.  Defaults to
-@samp{"/var/run/dovecot/"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string login-greeting
-Greeting message for clients.  Defaults to @samp{"Dovecot ready."}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-trusted-networks
-List of trusted network ranges.  Connections from these IPs are allowed to
-override their IP addresses and ports (for logging and for authentication
-checks).  @samp{disable-plaintext-auth} is also ignored for these networks.
-Typically you would specify your IMAP proxy servers here.  Defaults to
-@samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-access-sockets
-List of login access check sockets (e.g.@: tcpwrap).  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean verbose-proctitle?
-Show more verbose process titles (in ps).  Currently shows user name and IP
-address.  Useful for seeing who is actually using the IMAP processes (e.g.@:
-shared mailboxes or if the same uid is used for multiple accounts).
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean shutdown-clients?
-Should all processes be killed when Dovecot master process shuts down.
-Setting this to @code{#f} means that Dovecot can be upgraded without forcing
-existing client connections to close (although that could also be a problem
-if the upgrade is e.g.@: due to a security fix).  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer doveadm-worker-count
-If non-zero, run mail commands via this many connections to doveadm server,
-instead of running them directly in the same process.  Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string doveadm-socket-path
-UNIX socket or host:port used for connecting to doveadm server.  Defaults to
-@samp{"doveadm-server"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list import-environment
-List of environment variables that are preserved on Dovecot startup and
-passed down to all of its child processes.  You can also give key=value
-pairs to always set specific settings.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean disable-plaintext-auth?
-Disable LOGIN command and all other plaintext authentications unless SSL/TLS
-is used (LOGINDISABLED capability).  Note that if the remote IP matches the
-local IP (i.e.@: you're connecting from the same computer), the connection
-is considered secure and plaintext authentication is allowed.  See also
-ssl=required setting.  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-cache-size
-Authentication cache size (e.g.@: @samp{#e10e6}).  0 means it's disabled.
-Note that bsdauth, PAM and vpopmail require @samp{cache-key} to be set for
-caching to be used.  Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-cache-ttl
-Time to live for cached data.  After TTL expires the cached record is no
-longer used, *except* if the main database lookup returns internal failure.
-We also try to handle password changes automatically: If user's previous
-authentication was successful, but this one wasn't, the cache isn't used.
-For now this works only with plaintext authentication.  Defaults to @samp{"1
-hour"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-cache-negative-ttl
-TTL for negative hits (user not found, password mismatch).  0 disables
-caching them completely.  Defaults to @samp{"1 hour"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-realms
-List of realms for SASL authentication mechanisms that need them.  You can
-leave it empty if you don't want to support multiple realms.  Many clients
-simply use the first one listed here, so keep the default realm first.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-default-realm
-Default realm/domain to use if none was specified.  This is used for both
-SASL realms and appending @@domain to username in plaintext logins.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-username-chars
-List of allowed characters in username.  If the user-given username contains
-a character not listed in here, the login automatically fails.  This is just
-an extra check to make sure user can't exploit any potential quote escaping
-vulnerabilities with SQL/LDAP databases.  If you want to allow all
-characters, set this value to empty.  Defaults to
-@samp{"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@@"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-username-translation
-Username character translations before it's looked up from databases.  The
-value contains series of from -> to characters.  For example @samp{#@@/@@}
-means that @samp{#} and @samp{/} characters are translated to @samp{@@}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-username-format
-Username formatting before it's looked up from databases.  You can use the
-standard variables here, e.g.@: %Lu would lowercase the username, %n would
-drop away the domain if it was given, or @samp{%n-AT-%d} would change the
-@samp{@@} into @samp{-AT-}.  This translation is done after
-@samp{auth-username-translation} changes.  Defaults to @samp{"%Lu"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-master-user-separator
-If you want to allow master users to log in by specifying the master
-username within the normal username string (i.e.@: not using SASL
-mechanism's support for it), you can specify the separator character here.
-The format is then <username><separator><master username>.  UW-IMAP uses
-@samp{*} as the separator, so that could be a good choice.  Defaults to
-@samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-anonymous-username
-Username to use for users logging in with ANONYMOUS SASL mechanism.
-Defaults to @samp{"anonymous"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-worker-max-count
-Maximum number of dovecot-auth worker processes.  They're used to execute
-blocking passdb and userdb queries (e.g.@: MySQL and PAM).  They're
-automatically created and destroyed as needed.  Defaults to @samp{30}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-gssapi-hostname
-Host name to use in GSSAPI principal names.  The default is to use the name
-returned by gethostname().  Use @samp{$ALL} (with quotes) to allow all
-keytab entries.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-krb5-keytab
-Kerberos keytab to use for the GSSAPI mechanism.  Will use the system
-default (usually @file{/etc/krb5.keytab}) if not specified.  You may need to
-change the auth service to run as root to be able to read this file.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-use-winbind?
-Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon and
-@samp{ntlm-auth} helper.  <doc/wiki/Authentication/Mechanisms/Winbind.txt>.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name auth-winbind-helper-path
-Path for Samba's @samp{ntlm-auth} helper binary.  Defaults to
-@samp{"/usr/bin/ntlm_auth"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string auth-failure-delay
-Time to delay before replying to failed authentications.  Defaults to
-@samp{"2 secs"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-require-client-cert?
-Require a valid SSL client certificate or the authentication fails.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-username-from-cert?
-Take the username from client's SSL certificate, using
-@code{X509_NAME_get_text_by_NID()} which returns the subject's DN's
-CommonName.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-mechanisms
-List of wanted authentication mechanisms.  Supported mechanisms are:
-@samp{plain}, @samp{login}, @samp{digest-md5}, @samp{cram-md5}, @samp{ntlm},
-@samp{rpa}, @samp{apop}, @samp{anonymous}, @samp{gssapi}, @samp{otp},
-@samp{skey}, and @samp{gss-spnego}.  NOTE: See also
-@samp{disable-plaintext-auth} setting.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-servers
-List of IPs or hostnames to all director servers, including ourself.  Ports
-can be specified as ip:port.  The default port is the same as what director
-service's @samp{inet-listener} is using.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-mail-servers
-List of IPs or hostnames to all backend mail servers.  Ranges are allowed
-too, like 10.0.0.10-10.0.0.30.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string director-user-expire
-How long to redirect users to a specific server after it no longer has any
-connections.  Defaults to @samp{"15 min"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string director-username-hash
-How the username is translated before being hashed.  Useful values include
-%Ln if user can log in with or without @@domain, %Ld if mailboxes are shared
-within domain.  Defaults to @samp{"%Lu"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string log-path
-Log file to use for error messages.  @samp{syslog} logs to syslog,
-@samp{/dev/stderr} logs to stderr.  Defaults to @samp{"syslog"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string info-log-path
-Log file to use for informational messages.  Defaults to @samp{log-path}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string debug-log-path
-Log file to use for debug messages.  Defaults to @samp{info-log-path}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string syslog-facility
-Syslog facility to use if you're logging to syslog.  Usually if you don't
-want to use @samp{mail}, you'll use local0..local7.  Also other standard
-facilities are supported.  Defaults to @samp{"mail"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose?
-Log unsuccessful authentication attempts and the reasons why they failed.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose-passwords?
-In case of password mismatches, log the attempted password.  Valid values
-are no, plain and sha1.  sha1 can be useful for detecting brute force
-password attempts vs.  user simply trying the same password over and over
-again.  You can also truncate the value to n chars by appending ":n" (e.g.@:
-sha1:6).  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug?
-Even more verbose logging for debugging purposes.  Shows for example SQL
-queries.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug-passwords?
-In case of password mismatches, log the passwords and used scheme so the
-problem can be debugged.  Enabling this also enables @samp{auth-debug}.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mail-debug?
-Enable mail process debugging.  This can help you figure out why Dovecot
-isn't finding your mails.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean verbose-ssl?
-Show protocol level SSL errors.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string log-timestamp
-Prefix for each line written to log file.  % codes are in strftime(3)
-format.  Defaults to @samp{"\"%b %d %H:%M:%S \""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-log-format-elements
-List of elements we want to log.  The elements which have a non-empty
-variable value are joined together to form a comma-separated string.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string login-log-format
-Login log format.  %s contains @samp{login-log-format-elements} string, %$
-contains the data we want to log.  Defaults to @samp{"%$: %s"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-log-prefix
-Log prefix for mail processes.  See doc/wiki/Variables.txt for list of
-possible variables you can use.  Defaults to
-@samp{"\"%s(%u)<%@{pid@}><%@{session@}>: \""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string deliver-log-format
-Format to use for logging mail deliveries.  You can use variables:
-@table @code
-@item %$
-Delivery status message (e.g.@: @samp{saved to INBOX})
-@item %m
-Message-ID
-@item %s
-Subject
-@item %f
-From address
-@item %p
-Physical size
-@item %w
-Virtual size.
-@end table
-Defaults to @samp{"msgid=%m: %$"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-location
-Location for users' mailboxes.  The default is empty, which means that
-Dovecot tries to find the mailboxes automatically.  This won't work if the
-user doesn't yet have any mail, so you should explicitly tell Dovecot the
-full location.
-If you're using mbox, giving a path to the INBOX file (e.g.@: /var/mail/%u)
-isn't enough.  You'll also need to tell Dovecot where the other mailboxes
-are kept.  This is called the "root mail directory", and it must be the
-first path given in the @samp{mail-location} setting.
-There are a few special variables you can use, eg.:
-@table @samp
-@item %u
-username
-@item %n
-user part in user@@domain, same as %u if there's no domain
-@item %d
-domain part in user@@domain, empty if there's no domain
-@item %h
-home director
-@end table
-See doc/wiki/Variables.txt for full list.  Some examples:
-@table @samp
-@item maildir:~/Maildir
-@item mbox:~/mail:INBOX=/var/mail/%u
-@item mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%
-@end table
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-uid
-System user and group used to access mails.  If you use multiple, userdb can
-override these by returning uid or gid fields.  You can use either numbers
-or names.  <doc/wiki/UserIds.txt>.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-gid
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-privileged-group
-Group to enable temporarily for privileged operations.  Currently this is
-used only with INBOX when either its initial creation or dotlocking fails.
-Typically this is set to "mail" to give access to /var/mail.  Defaults to
-@samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-access-groups
-Grant access to these supplementary groups for mail processes.  Typically
-these are used to set up access to shared mailboxes.  Note that it may be
-dangerous to set these if users can create symlinks (e.g.@: if "mail" group
-is set here, ln -s /var/mail ~/mail/var could allow a user to delete others'
-mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading
-it).  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mail-full-filesystem-access?
-Allow full file system access to clients.  There's no access checks other
-than what the operating system does for the active UID/GID.  It works with
-both maildir and mboxes, allowing you to prefix mailboxes names with e.g.@:
-/path/ or ~user/.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mmap-disable?
-Don't use mmap() at all.  This is required if you store indexes to shared
-file systems (NFS or clustered file system).  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean dotlock-use-excl?
-Rely on @samp{O_EXCL} to work when creating dotlock files.  NFS supports
-@samp{O_EXCL} since version 3, so this should be safe to use nowadays by
-default.  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-fsync
-When to use fsync() or fdatasync() calls:
-@table @code
-@item optimized
-Whenever necessary to avoid losing important data
-@item always
-Useful with e.g.@: NFS when write()s are delayed
-@item never
-Never use it (best performance, but crashes can lose data).
-@end table
-Defaults to @samp{"optimized"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-storage?
-Mail storage exists in NFS.  Set this to yes to make Dovecot flush NFS
-caches whenever needed.  If you're using only a single mail server this
-isn't needed.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-index?
-Mail index files also exist in NFS.  Setting this to yes requires
-@samp{mmap-disable? #t} and @samp{fsync-disable? #f}.  Defaults to
-@samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string lock-method
-Locking method for index files.  Alternatives are fcntl, flock and dotlock.
-Dotlocking uses some tricks which may create more disk I/O than other
-locking methods.  NFS users: flock doesn't work, remember to change
-@samp{mmap-disable}.  Defaults to @samp{"fcntl"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name mail-temp-dir
-Directory in which LDA/LMTP temporarily stores incoming mails >128 kB.
-Defaults to @samp{"/tmp"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-uid
-Valid UID range for users.  This is mostly to make sure that users can't log
-in as daemons or other system users.  Note that denying root logins is
-hardcoded to dovecot binary and can't be done even if @samp{first-valid-uid}
-is set to 0.  Defaults to @samp{500}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-uid
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-gid
-Valid GID range for users.  Users having non-valid GID as primary group ID
-aren't allowed to log in.  If user belongs to supplementary groups with
-non-valid GIDs, those groups are not set.  Defaults to @samp{1}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-gid
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-max-keyword-length
-Maximum allowed length for mail keyword name.  It's only forced when trying
-to create new keywords.  Defaults to @samp{50}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} colon-separated-file-name-list valid-chroot-dirs
-List of directories under which chrooting is allowed for mail processes
-(i.e.@: /var/mail will allow chrooting to /var/mail/foo/bar too).  This
-setting doesn't affect @samp{login-chroot} @samp{mail-chroot} or auth chroot
-settings.  If this setting is empty, "/./" in home dirs are ignored.
-WARNING: Never add directories here which local users can modify, that may
-lead to root exploit.  Usually this should be done only if you don't allow
-shell access for users.  <doc/wiki/Chrooting.txt>.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-chroot
-Default chroot directory for mail processes.  This can be overridden for
-specific users in user database by giving /./ in user's home directory
-(e.g.@: /home/./user chroots into /home).  Note that usually there is no
-real need to do chrooting, Dovecot doesn't allow users to access files
-outside their mail directory anyway.  If your home directories are prefixed
-with the chroot directory, append "/."@: to @samp{mail-chroot}.
-<doc/wiki/Chrooting.txt>.  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name auth-socket-path
-UNIX socket path to master authentication server to find users.  This is
-used by imap (for shared users) and lda.  Defaults to
-@samp{"/var/run/dovecot/auth-userdb"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name mail-plugin-dir
-Directory where to look up mail plugins.  Defaults to
-@samp{"/usr/lib/dovecot"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mail-plugins
-List of plugins to load for all services.  Plugins specific to IMAP, LDA,
-etc.@: are added to this list in their own .conf files.  Defaults to
-@samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-cache-min-mail-count
-The minimum number of mails in a mailbox before updates are done to cache
-file.  This allows optimizing Dovecot's behavior to do less disk writes at
-the cost of more disk reads.  Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mailbox-idle-check-interval
-When IDLE command is running, mailbox is checked once in a while to see if
-there are any new mails or other changes.  This setting defines the minimum
-time to wait between those checks.  Dovecot can also use dnotify, inotify
-and kqueue to find out immediately when changes occur.  Defaults to
-@samp{"30 secs"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mail-save-crlf?
-Save mails with CR+LF instead of plain LF.  This makes sending those mails
-take less CPU, especially with sendfile() syscall with Linux and FreeBSD.
-But it also creates a bit more disk I/O which may just make it slower.  Also
-note that if other software reads the mboxes/maildirs, they may handle the
-extra CRs wrong and cause problems.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-stat-dirs?
-By default LIST command returns all entries in maildir beginning with a
-dot.  Enabling this option makes Dovecot return only entries which are
-directories.  This is done by stat()ing each entry, so it causes more disk
-I/O.  (For systems setting struct @samp{dirent->d_type} this check is free
-and it's done always regardless of this setting).  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-copy-with-hardlinks?
-When copying a message, do it with hard links whenever possible.  This makes
-the performance much better, and it's unlikely to have any side effects.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean maildir-very-dirty-syncs?
-Assume Dovecot is the only MUA accessing Maildir: Scan cur/ directory only
-when its mtime changes unexpectedly or when we can't find the mail
-otherwise.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-read-locks
-Which locking methods to use for locking mbox.  There are four available:
-@table @code
-@item dotlock
-Create <mailbox>.lock file.  This is the oldest and most NFS-safe solution.
-If you want to use /var/mail/ like directory, the users will need write
-access to that directory.
-@item dotlock-try
-Same as dotlock, but if it fails because of permissions or because there
-isn't enough disk space, just skip it.
-@item fcntl
-Use this if possible.  Works with NFS too if lockd is used.
-@item flock
-May not exist in all systems.  Doesn't work with NFS.
-@item lockf
-May not exist in all systems.  Doesn't work with NFS.
-@end table
-You can use multiple locking methods; if you do the order they're declared
-in is important to avoid deadlocks if other MTAs/MUAs are using multiple
-locking methods as well.  Some operating systems don't allow using some of
-them simultaneously.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-write-locks
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mbox-lock-timeout
-Maximum time to wait for lock (all of them) before aborting.  Defaults to
-@samp{"5 mins"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mbox-dotlock-change-timeout
-If dotlock exists but the mailbox isn't modified in any way, override the
-lock file after this much time.  Defaults to @samp{"2 mins"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-dirty-syncs?
-When mbox changes unexpectedly we have to fully read it to find out what
-changed.  If the mbox is large this can take a long time.  Since the change
-is usually just a newly appended mail, it'd be faster to simply read the new
-mails.  If this setting is enabled, Dovecot does this but still safely
-fallbacks to re-reading the whole mbox file whenever something in mbox isn't
-how it's expected to be.  The only real downside to this setting is that if
-some other MUA changes message flags, Dovecot doesn't notice it
-immediately.  Note that a full sync is done with SELECT, EXAMINE, EXPUNGE
-and CHECK commands.  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-very-dirty-syncs?
-Like @samp{mbox-dirty-syncs}, but don't do full syncs even with SELECT,
-EXAMINE, EXPUNGE or CHECK commands.  If this is set, @samp{mbox-dirty-syncs}
-is ignored.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mbox-lazy-writes?
-Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK
-commands and when closing the mailbox).  This is especially useful for POP3
-where clients often delete all mails.  The downside is that our changes
-aren't immediately visible to other MUAs.  Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mbox-min-index-size
-If mbox size is smaller than this (e.g.@: 100k), don't write index files.
-If an index file already exists it's still read, just not updated.  Defaults
-to @samp{0}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mdbox-rotate-size
-Maximum dbox file size until it's rotated.  Defaults to @samp{10000000}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mdbox-rotate-interval
-Maximum dbox file age until it's rotated.  Typically in days.  Day begins
-from midnight, so 1d = today, 2d = yesterday, etc.  0 = check disabled.
-Defaults to @samp{"1d"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean mdbox-preallocate-space?
-When creating new mdbox files, immediately preallocate their size to
-@samp{mdbox-rotate-size}.  This setting currently works only in Linux with
-some file systems (ext4, xfs).  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-dir
-sdbox and mdbox support saving mail attachments to external files, which
-also allows single instance storage for them.  Other backends don't support
-this for now.
-WARNING: This feature hasn't been tested much yet.  Use at your own risk.
-Directory root where to store mail attachments.  Disabled, if empty.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-attachment-min-size
-Attachments smaller than this aren't saved externally.  It's also possible
-to write a plugin to disable saving specific attachments externally.
-Defaults to @samp{128000}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-fs
-File system backend to use for saving attachments:
-@table @code
-@item posix
-No SiS done by Dovecot (but this might help FS's own deduplication)
-@item sis posix
-SiS with immediate byte-by-byte comparison during saving
-@item sis-queue posix
-SiS with delayed comparison and deduplication.
-@end table
-Defaults to @samp{"sis posix"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-hash
-Hash format to use in attachment filenames.  You can add any text and
-variables: @code{%@{md4@}}, @code{%@{md5@}}, @code{%@{sha1@}},
-@code{%@{sha256@}}, @code{%@{sha512@}}, @code{%@{size@}}.  Variables can be
-truncated, e.g.@: @code{%@{sha256:80@}} returns only first 80 bits.
-Defaults to @samp{"%@{sha1@}"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-process-limit
-Defaults to @samp{100}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-client-limit
-Defaults to @samp{1000}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-vsz-limit
-Default VSZ (virtual memory size) limit for service processes.  This is
-mainly intended to catch and kill processes that leak memory before they eat
-up everything.  Defaults to @samp{256000000}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string default-login-user
-Login user is internally used by login processes.  This is the most
-untrusted user in Dovecot system.  It shouldn't have access to anything at
-all.  Defaults to @samp{"dovenull"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string default-internal-user
-Internal user is used by unprivileged processes.  It should be separate from
-login user, so that login processes can't disturb other processes.  Defaults
-to @samp{"dovecot"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl?
-SSL/TLS support: yes, no, required.  <doc/wiki/SSL.txt>.  Defaults to
-@samp{"required"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-cert
-PEM encoded X.509 SSL/TLS certificate (public key).  Defaults to
-@samp{"</etc/dovecot/default.pem"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-key
-PEM encoded SSL/TLS private key.  The key is opened before dropping root
-privileges, so keep the key file unreadable by anyone but root.  Defaults to
-@samp{"</etc/dovecot/private/default.pem"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-key-password
-If key file is password protected, give the password here.  Alternatively
-give it when starting dovecot with -p parameter.  Since this file is often
-world-readable, you may want to place this setting instead to a different.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-ca
-PEM encoded trusted certificate authority.  Set this only if you intend to
-use @samp{ssl-verify-client-cert? #t}.  The file should contain the CA
-certificate(s) followed by the matching CRL(s).  (e.g.@: @samp{ssl-ca
-</etc/ssl/certs/ca.pem}).  Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean ssl-require-crl?
-Require that CRL check succeeds for client certificates.  Defaults to
-@samp{#t}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean ssl-verify-client-cert?
-Request client to send a certificate.  If you also want to require it, set
-@samp{auth-ssl-require-client-cert? #t} in auth section.  Defaults to
-@samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-cert-username-field
-Which field from certificate to use for username.  commonName and
-x500UniqueIdentifier are the usual choices.  You'll also need to set
-@samp{auth-ssl-username-from-cert? #t}.  Defaults to @samp{"commonName"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-min-protocol
-Minimum SSL protocol version to accept.  Defaults to @samp{"TLSv1"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-cipher-list
-SSL ciphers to use.  Defaults to
-@samp{"ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@@STRENGTH"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string ssl-crypto-device
-SSL crypto device to use, for valid values run "openssl engine".  Defaults
-to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string postmaster-address
-Address to use when sending rejection mails.  %d expands to recipient
-domain.  Defaults to @samp{"postmaster@@%d"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string hostname
-Hostname to use in various parts of sent mails (e.g.@: in Message-Id)  and
-in LMTP replies.  Default is the system's real hostname@@domain.  Defaults
-to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean quota-full-tempfail?
-If user is over quota, return with temporary failure instead of bouncing the
-mail.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} file-name sendmail-path
-Binary to use for sending mails.  Defaults to @samp{"/usr/sbin/sendmail"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string submission-host
-If non-empty, send mails via this SMTP host[:port] instead of sendmail.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string rejection-subject
-Subject: header to use for rejection mails.  You can use the same variables
-as for @samp{rejection-reason} below.  Defaults to @samp{"Rejected: %s"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string rejection-reason
-Human readable error message for rejection mails.  You can use variables:
-@table @code
-@item %n
-CRLF
-@item %r
-reason
-@item %s
-original subject
-@item %t
-recipient
-@end table
-Defaults to @samp{"Your message to <%t> was automatically rejected:%n%r"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string recipient-delimiter
-Delimiter character between local-part and detail in email address.
-Defaults to @samp{"+"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string lda-original-recipient-header
-Header where the original recipient address (SMTP's RCPT TO: address) is
-taken from if not available elsewhere.  With dovecot-lda -a parameter
-overrides this.  A commonly used header for this is X-Original-To.  Defaults
-to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autocreate?
-Should saving a mail to a nonexistent mailbox automatically create it?.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autosubscribe?
-Should automatically created mailboxes be also automatically subscribed?.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} non-negative-integer imap-max-line-length
-Maximum IMAP command line length.  Some clients generate very long command
-lines with huge mailboxes, so you may need to raise this if you get "Too
-long argument" or "IMAP command line too large" errors often.  Defaults to
-@samp{64000}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-logout-format
-IMAP logout format string:
-@table @code
-@item %i
-total number of bytes read from client
-@item %o
-total number of bytes sent to client.
-@end table
-See @file{doc/wiki/Variables.txt} for a list of all the variables you can
-use.  Defaults to @samp{"in=%i out=%o deleted=%@{deleted@}
-expunged=%@{expunged@} trashed=%@{trashed@} hdr_count=%@{fetch_hdr_count@}
-hdr_bytes=%@{fetch_hdr_bytes@} body_count=%@{fetch_body_count@}
-body_bytes=%@{fetch_body_bytes@}"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-capability
-Override the IMAP CAPABILITY response.  If the value begins with '+', add
-the given capabilities on top of the defaults (e.g.@: +XFOO XBAR).  Defaults
-to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-idle-notify-interval
-How long to wait between "OK Still here" notifications when client is
-IDLEing.  Defaults to @samp{"2 mins"}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-id-send
-ID field names and values to send to clients.  Using * as the value makes
-Dovecot use the default value.  The following fields have default values
-currently: name, version, os, os-version, support-url, support-email.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-id-log
-ID fields sent by client to log.  * means everything.  Defaults to
-@samp{""}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list imap-client-workarounds
-Workarounds for various client bugs:
-@table @code
-@item delay-newmail
-Send EXISTS/RECENT new mail notifications only when replying to NOOP and
-CHECK commands.  Some clients ignore them otherwise, for example OSX Mail
-(<v2.1).  Outlook Express breaks more badly though, without this it may show
-user "Message no longer in server" errors.  Note that OE6 still breaks even
-with this workaround if synchronization is set to "Headers Only".
-@item tb-extra-mailbox-sep
-Thunderbird gets somehow confused with LAYOUT=fs (mbox and dbox) and adds
-extra @samp{/} suffixes to mailbox names.  This option causes Dovecot to
-ignore the extra @samp{/} instead of treating it as invalid mailbox name.
-@item tb-lsub-flags
-Show \Noselect flags for LSUB replies with LAYOUT=fs (e.g.@: mbox).  This
-makes Thunderbird realize they aren't selectable and show them greyed out,
-instead of only later giving "not selectable" popup error.
-@end table
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{dovecot-configuration} parameter} string imap-urlauth-host
-Host allowed in URLAUTH URLs sent by client.  "*" allows all.  Defaults to
-@samp{""}.
-@end deftypevr
-Whew! Lots of configuration options.  The nice thing about it though is that
-Guix has a complete interface to Dovecot's configuration language.  This
-allows not only a nice way to declare configurations, but also offers
-reflective capabilities as well: users can write code to inspect and
-transform configurations from within Scheme.
-However, it could be that you just want to get a @code{dovecot.conf} up and
-running.  In that case, you can pass an @code{opaque-dovecot-configuration}
-as the @code{#:config} parameter to @code{dovecot-service}.  As its name
-indicates, an opaque configuration does not have easy reflective
-capabilities.
-Available @code{opaque-dovecot-configuration} fields are:
-@deftypevr {@code{opaque-dovecot-configuration} parameter} package dovecot
-The dovecot package.
-@end deftypevr
-@deftypevr {@code{opaque-dovecot-configuration} parameter} string string
-The contents of the @code{dovecot.conf}, as a string.
-@end deftypevr
-For example, if your @code{dovecot.conf} is just the empty string, you could
-instantiate a dovecot service like this:
-@example
-(dovecot-service #:config
-                 (opaque-dovecot-configuration
-                  (string "")))
-@end example
-@subsubheading OpenSMTPD Service
-@deffn {Scheme Variable} opensmtpd-service-type
-This is the type of the @uref{https://www.opensmtpd.org, OpenSMTPD} service,
-whose value should be an @code{opensmtpd-configuration} object as in this
-example:
-@example
-(service opensmtpd-service-type
-         (opensmtpd-configuration
-           (config-file (local-file "./my-smtpd.conf"))))
-@end example
-@end deffn
-@deftp {Data Type} opensmtpd-configuration
-Data type representing the configuration of opensmtpd.
-@table @asis
-@item @code{package} (default: @var{opensmtpd})
-Package object of the OpenSMTPD SMTP server.
-@item @code{config-file} (default: @var{%default-opensmtpd-file})
-File-like object of the OpenSMTPD configuration file to use.  By default it
-listens on the loopback network interface, and allows for mail from users
-and daemons on the local machine, as well as permitting email to remote
-servers.  Run @command{man smtpd.conf} for more information.
-@end table
-@end deftp
-@subsubheading Exim Service
-@cindex mail transfer agent (MTA)
-@cindex MTA (mail transfer agent)
-@cindex SMTP
-@deffn {Scheme Variable} exim-service-type
-This is the type of the @uref{https://exim.org, Exim} mail transfer agent
-(MTA), whose value should be an @code{exim-configuration} object as in this
-example:
-@example
-(service exim-service-type
-         (exim-configuration
-           (config-file (local-file "./my-exim.conf"))))
-@end example
-@end deffn
-In order to use an @code{exim-service-type} service you must also have a
-@code{mail-aliases-service-type} service present in your
-@code{operating-system} (even if it has no aliases).
-@deftp {Data Type} exim-configuration
-Data type representing the configuration of exim.
-@table @asis
-@item @code{package} (default: @var{exim})
-Package object of the Exim server.
-@item @code{config-file} (default: @code{#f})
-File-like object of the Exim configuration file to use. If its value is
-@code{#f} then use the default configuration file from the package provided
-in @code{package}. The resulting configuration file is loaded after setting
-the @code{exim_user} and @code{exim_group} configuration variables.
-@end table
-@end deftp
-@subsubheading Mail Aliases Service
-@cindex email aliases
-@cindex aliases, for email addresses
-@deffn {Scheme Variable} mail-aliases-service-type
-This is the type of the service which provides @code{/etc/aliases},
-specifying how to deliver mail to users on this system.
-@example
-(service mail-aliases-service-type
-         '(("postmaster" "bob")
-           ("bob" "bob@@example.com" "bob@@example2.com")))
-@end example
-@end deffn
-The configuration for a @code{mail-aliases-service-type} service is an
-association list denoting how to deliver mail that comes to this
-system. Each entry is of the form @code{(alias addresses ...)}, with
-@code{alias} specifying the local alias and @code{addresses} specifying
-where to deliver this user's mail.
-The aliases aren't required to exist as users on the local system. In the
-above example, there doesn't need to be a @code{postmaster} entry in the
-@code{operating-system}'s @code{user-accounts} in order to deliver the
-@code{postmaster} mail to @code{bob} (which subsequently would deliver mail
-to @code{bob@@example.com} and @code{bob@@example2.com}).
-@subsubheading GNU Mailutils IMAP4 Daemon
-@cindex GNU Mailutils IMAP4 Daemon
-@deffn {Scheme-Variable} imap4d-service-type
-This is the type of the GNU Mailutils IMAP4 Daemon (@pxref{imap4d,,,
-mailutils, GNU Mailutils Manual}), whose value should be an
-@code{imap4d-configuration} object as in this example:
-@example
-(service imap4d-service-type
-         (imap4d-configuration
-           (config-file (local-file "imap4d.conf"))))
-@end example
-@end deffn
-@deftp {Datentyp} imap4d-configuration
-Datentyp, der die Konfiguration von @command{imap4d} repräsentiert.
-@table @asis
-@item @code{package} (Vorgabe: @code{mailutils})
-The package that provides @command{imap4d}.
-@item @code{config-file} (Vorgabe: @code{%default-imap4d-config-file})
-File-like object of the configuration file to use, by default it will listen
-on TCP port 143 of @code{localhost}.  @xref{Conf-imap4d,,, mailutils, GNU
-Mailutils Manual}, for details.
-@end table
-@end deftp
-@node Kurznachrichtendienste
-@subsection Kurznachrichtendienste
-@cindex messaging
-@cindex jabber
-@cindex XMPP
-The @code{(gnu services messaging)} module provides Guix service definitions
-for messaging services: currently only Prosody is supported.
-@subsubheading Prosody Service
-@deffn {Scheme Variable} prosody-service-type
-This is the type for the @uref{https://prosody.im, Prosody XMPP
-communication server}.  Its value must be a @code{prosody-configuration}
-record as in this example:
-@example
-(service prosody-service-type
-         (prosody-configuration
-          (modules-enabled (cons "groups" "mam" %default-modules-enabled))
-          (int-components
-           (list
-            (int-component-configuration
-             (hostname "conference.example.net")
-             (plugin "muc")
-             (mod-muc (mod-muc-configuration)))))
-          (virtualhosts
-           (list
-            (virtualhost-configuration
-             (domain "example.net"))))))
-@end example
-See below for details about @code{prosody-configuration}.
-@end deffn
-By default, Prosody does not need much configuration.  Only one
-@code{virtualhosts} field is needed: it specifies the domain you wish
-Prosody to serve.
-You can perform various sanity checks on the generated configuration with
-the @code{prosodyctl check} command.
-Prosodyctl will also help you to import certificates from the
-@code{letsencrypt} directory so that the @code{prosody} user can access
-them.  See @url{https://prosody.im/doc/letsencrypt}.
-@example
-prosodyctl --root cert import /etc/letsencrypt/live
-@end example
-The available configuration parameters follow.  Each parameter definition is
-preceded by its type; for example, @samp{string-list foo} indicates that the
-@code{foo} parameter should be specified as a list of strings.  Types
-starting with @code{maybe-} denote parameters that won't show up in
-@code{prosody.cfg.lua} when their value is @code{'disabled}.
-There is also a way to specify the configuration as a string, if you have an
-old @code{prosody.cfg.lua} file that you want to port over from some other
-system; see the end for more details.
-The @code{file-object} type designates either a file-like object
-(@pxref{G-Ausdrücke, file-like objects}) or a file name.
-@c The following documentation was initially generated by
-@c (generate-documentation) in (gnu services messaging).  Manually maintained
-@c documentation is better, so we shouldn't hesitate to edit below as
-@c needed.  However if the change you want to make to this documentation
-@c can be done in an automated way, it's probably easier to change
-@c (generate-documentation) than to make it below and have to deal with
-@c the churn as Prosody updates.
-Available @code{prosody-configuration} fields are:
-@deftypevr {@code{prosody-configuration} parameter} package prosody
-The Prosody package.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} file-name data-path
-Location of the Prosody data storage directory.  See
-@url{https://prosody.im/doc/configure}.  Defaults to
-@samp{"/var/lib/prosody"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} file-object-list plugin-paths
-Additional plugin directories.  They are searched in all the specified paths
-in order.  See @url{https://prosody.im/doc/plugins_directory}.  Defaults to
-@samp{()}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} file-name certificates
-Every virtual host and component needs a certificate so that clients and
-servers can securely verify its identity.  Prosody will automatically load
-certificates/keys from the directory specified here.  Defaults to
-@samp{"/etc/prosody/certs"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string-list admins
-This is a list of accounts that are admins for the server.  Note that you
-must create the accounts separately.  See
-@url{https://prosody.im/doc/admins} and
-@url{https://prosody.im/doc/creating_accounts}.  Example: @code{(admins
-'("user1@@example.com" "user2@@example.net"))} Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} boolean use-libevent?
-Enable use of libevent for better performance under high load.  See
-@url{https://prosody.im/doc/libevent}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} module-list modules-enabled
-This is the list of modules Prosody will load on startup.  It looks for
-@code{mod_modulename.lua} in the plugins folder, so make sure that exists
-too.  Documentation on modules can be found at:
-@url{https://prosody.im/doc/modules}.  Defaults to @samp{("roster"
-"saslauth" "tls" "dialback" "disco" "carbons" "private" "blocklist" "vcard"
-"version" "uptime" "time" "ping" "pep" "register" "admin_adhoc")}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string-list modules-disabled
-@samp{"offline"}, @samp{"c2s"} and @samp{"s2s"} are auto-loaded, but should
-you want to disable them then add them to this list.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} file-object groups-file
-Path to a text file where the shared groups are defined.  If this path is
-empty then @samp{mod_groups} does nothing.  See
-@url{https://prosody.im/doc/modules/mod_groups}.  Defaults to
-@samp{"/var/lib/prosody/sharedgroups.txt"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} boolean allow-registration?
-Disable account creation by default, for security.  See
-@url{https://prosody.im/doc/creating_accounts}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} maybe-ssl-configuration ssl
-These are the SSL/TLS-related settings.  Most of them are disabled so to use
-Prosody's defaults.  If you do not completely understand these options, do
-not add them to your config, it is easy to lower the security of your server
-using them.  See @url{https://prosody.im/doc/advanced_ssl_config}.
-Available @code{ssl-configuration} fields are:
-@deftypevr {@code{ssl-configuration} parameter} maybe-string protocol
-This determines what handshake to use.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-file-name key
-Path to your private key file.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-file-name certificate
-Path to your certificate file.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} file-object capath
-Path to directory containing root certificates that you wish Prosody to
-trust when verifying the certificates of remote servers.  Defaults to
-@samp{"/etc/ssl/certs"}.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-file-object cafile
-Path to a file containing root certificates that you wish Prosody to trust.
-Similar to @code{capath} but with all certificates concatenated together.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string-list verify
-A list of verification options (these mostly map to OpenSSL's
-@code{set_verify()} flags).
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string-list options
-A list of general options relating to SSL/TLS.  These map to OpenSSL's
-@code{set_options()}.  For a full list of options available in LuaSec, see
-the LuaSec source.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-non-negative-integer depth
-How long a chain of certificate authorities to check when looking for a
-trusted root certificate.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string ciphers
-An OpenSSL cipher string.  This selects what ciphers Prosody will offer to
-clients, and in what order.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-file-name dhparam
-A path to a file containing parameters for Diffie-Hellman key exchange.  You
-can create such a file with: @code{openssl dhparam -out
-/etc/prosody/certs/dh-2048.pem 2048}
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string curve
-Curve for Elliptic curve Diffie-Hellman. Prosody's default is
-@samp{"secp384r1"}.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string-list verifyext
-A list of "extra" verification options.
-@end deftypevr
-@deftypevr {@code{ssl-configuration} parameter} maybe-string password
-Password for encrypted private keys.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} boolean c2s-require-encryption?
-Whether to force all client-to-server connections to be encrypted or not.
-See @url{https://prosody.im/doc/modules/mod_tls}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string-list disable-sasl-mechanisms
-Set of mechanisms that will never be offered.  See
-@url{https://prosody.im/doc/modules/mod_saslauth}.  Defaults to
-@samp{("DIGEST-MD5")}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} boolean s2s-require-encryption?
-Whether to force all server-to-server connections to be encrypted or not.
-See @url{https://prosody.im/doc/modules/mod_tls}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} boolean s2s-secure-auth?
-Whether to require encryption and certificate authentication.  This provides
-ideal security, but requires servers you communicate with to support
-encryption AND present valid, trusted certificates.  See
-@url{https://prosody.im/doc/s2s#security}.  Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string-list s2s-insecure-domains
-Many servers don't support encryption or have invalid or self-signed
-certificates.  You can list domains here that will not be required to
-authenticate using certificates.  They will be authenticated using DNS.  See
-@url{https://prosody.im/doc/s2s#security}.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string-list s2s-secure-domains
-Even if you leave @code{s2s-secure-auth?} disabled, you can still require
-valid certificates for some domains by specifying a list here.  See
-@url{https://prosody.im/doc/s2s#security}.  Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string authentication
-Select the authentication backend to use.  The default provider stores
-passwords in plaintext and uses Prosody's configured data storage to store
-the authentication data.  If you do not trust your server please see
-@url{https://prosody.im/doc/modules/mod_auth_internal_hashed} for
-information about using the hashed backend.  See also
-@url{https://prosody.im/doc/authentication} Defaults to
-@samp{"internal_plain"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} maybe-string log
-Set logging options.  Advanced logging configuration is not yet supported by
-the Prosody service.  See @url{https://prosody.im/doc/logging}.  Defaults to
-@samp{"*syslog"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} file-name pidfile
-File to write pid in.  See @url{https://prosody.im/doc/modules/mod_posix}.
-Defaults to @samp{"/var/run/prosody/prosody.pid"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} maybe-non-negative-integer http-max-content-size
-Maximum allowed size of the HTTP body (in bytes).
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} maybe-string http-external-url
-Some modules expose their own URL in various ways.  This URL is built from
-the protocol, host and port used.  If Prosody sits behind a proxy, the
-public URL will be @code{http-external-url} instead.  See
-@url{https://prosody.im/doc/http#external_url}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} virtualhost-configuration-list virtualhosts
-A host in Prosody is a domain on which user accounts can be created.  For
-example if you want your users to have addresses like
-@samp{"john.smith@@example.com"} then you need to add a host
-@samp{"example.com"}.  All options in this list will apply only to this
-host.
-Note: the name "virtual" host is used in configuration to avoid confusion
-with the actual physical host that Prosody is installed on.  A single
-Prosody instance can serve many domains, each one defined as a VirtualHost
-entry in Prosody's configuration.  Conversely a server that hosts a single
-domain would have just one VirtualHost entry.
-See @url{https://prosody.im/doc/configure#virtual_host_settings}.
-Available @code{virtualhost-configuration} fields are:
-all these @code{prosody-configuration} fields: @code{admins},
-@code{use-libevent?}, @code{modules-enabled}, @code{modules-disabled},
-@code{groups-file}, @code{allow-registration?}, @code{ssl},
-@code{c2s-require-encryption?}, @code{disable-sasl-mechanisms},
-@code{s2s-require-encryption?}, @code{s2s-secure-auth?},
-@code{s2s-insecure-domains}, @code{s2s-secure-domains},
-@code{authentication}, @code{log}, @code{http-max-content-size},
-@code{http-external-url}, @code{raw-content}, plus:
-@deftypevr {@code{virtualhost-configuration} parameter} string domain
-Domain you wish Prosody to serve.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} int-component-configuration-list int-components
-Components are extra services on a server which are available to clients,
-usually on a subdomain of the main server (such as
-@samp{"mycomponent.example.com"}).  Example components might be chatroom
-servers, user directories, or gateways to other protocols.
-Internal components are implemented with Prosody-specific plugins.  To add
-an internal component, you simply fill the hostname field, and the plugin
-you wish to use for the component.
-See @url{https://prosody.im/doc/components}.  Defaults to @samp{()}.
-Available @code{int-component-configuration} fields are:
-all these @code{prosody-configuration} fields: @code{admins},
-@code{use-libevent?}, @code{modules-enabled}, @code{modules-disabled},
-@code{groups-file}, @code{allow-registration?}, @code{ssl},
-@code{c2s-require-encryption?}, @code{disable-sasl-mechanisms},
-@code{s2s-require-encryption?}, @code{s2s-secure-auth?},
-@code{s2s-insecure-domains}, @code{s2s-secure-domains},
-@code{authentication}, @code{log}, @code{http-max-content-size},
-@code{http-external-url}, @code{raw-content}, plus:
-@deftypevr {@code{int-component-configuration} parameter} string hostname
-Hostname of the component.
-@end deftypevr
-@deftypevr {@code{int-component-configuration} parameter} string plugin
-Plugin you wish to use for the component.
-@end deftypevr
-@deftypevr {@code{int-component-configuration} parameter} maybe-mod-muc-configuration mod-muc
-Multi-user chat (MUC) is Prosody's module for allowing you to create hosted
-chatrooms/conferences for XMPP users.
-General information on setting up and using multi-user chatrooms can be
-found in the "Chatrooms" documentation
-(@url{https://prosody.im/doc/chatrooms}), which you should read if you are
-new to XMPP chatrooms.
-See also @url{https://prosody.im/doc/modules/mod_muc}.
-Available @code{mod-muc-configuration} fields are:
-@deftypevr {@code{mod-muc-configuration} parameter} string name
-The name to return in service discovery responses.  Defaults to
-@samp{"Prosody Chatrooms"}.
-@end deftypevr
-@deftypevr {@code{mod-muc-configuration} parameter} string-or-boolean restrict-room-creation
-If @samp{#t}, this will only allow admins to create new chatrooms.
-Otherwise anyone can create a room.  The value @samp{"local"} restricts room
-creation to users on the service's parent domain.  E.g.@:
-@samp{user@@example.com} can create rooms on @samp{rooms.example.com}.  The
-value @samp{"admin"} restricts to service administrators only.  Defaults to
-@samp{#f}.
-@end deftypevr
-@deftypevr {@code{mod-muc-configuration} parameter} non-negative-integer max-history-messages
-Maximum number of history messages that will be sent to the member that has
-just joined the room.  Defaults to @samp{20}.
-@end deftypevr
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} ext-component-configuration-list ext-components
-External components use XEP-0114, which most standalone components support.
-To add an external component, you simply fill the hostname field.  See
-@url{https://prosody.im/doc/components}.  Defaults to @samp{()}.
-Available @code{ext-component-configuration} fields are:
-all these @code{prosody-configuration} fields: @code{admins},
-@code{use-libevent?}, @code{modules-enabled}, @code{modules-disabled},
-@code{groups-file}, @code{allow-registration?}, @code{ssl},
-@code{c2s-require-encryption?}, @code{disable-sasl-mechanisms},
-@code{s2s-require-encryption?}, @code{s2s-secure-auth?},
-@code{s2s-insecure-domains}, @code{s2s-secure-domains},
-@code{authentication}, @code{log}, @code{http-max-content-size},
-@code{http-external-url}, @code{raw-content}, plus:
-@deftypevr {@code{ext-component-configuration} parameter} string component-secret
-Password which the component will use to log in.
-@end deftypevr
-@deftypevr {@code{ext-component-configuration} parameter} string hostname
-Hostname of the component.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} non-negative-integer-list component-ports
-Port(s) Prosody listens on for component connections.  Defaults to
-@samp{(5347)}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} string component-interface
-Interface Prosody listens on for component connections.  Defaults to
-@samp{"127.0.0.1"}.
-@end deftypevr
-@deftypevr {@code{prosody-configuration} parameter} maybe-raw-content raw-content
-Raw content that will be added to the configuration file.
-@end deftypevr
-It could be that you just want to get a @code{prosody.cfg.lua} up and
-running.  In that case, you can pass an @code{opaque-prosody-configuration}
-record as the value of @code{prosody-service-type}.  As its name indicates,
-an opaque configuration does not have easy reflective capabilities.
-Available @code{opaque-prosody-configuration} fields are:
-@deftypevr {@code{opaque-prosody-configuration} parameter} package prosody
-The prosody package.
-@end deftypevr
-@deftypevr {@code{opaque-prosody-configuration} parameter} string prosody.cfg.lua
-The contents of the @code{prosody.cfg.lua} to use.
-@end deftypevr
-For example, if your @code{prosody.cfg.lua} is just the empty string, you
-could instantiate a prosody service like this:
-@example
-(service prosody-service-type
-         (opaque-prosody-configuration
-          (prosody.cfg.lua "")))
-@end example
-@c end of Prosody auto-generated documentation
-@subsubheading BitlBee Service
-@cindex IRC (Internet Relay Chat)
-@cindex IRC gateway
-@url{http://bitlbee.org,BitlBee} is a gateway that provides an IRC interface
-to a variety of messaging protocols such as XMPP.
-@defvr {Scheme Variable} bitlbee-service-type
-This is the service type for the @url{http://bitlbee.org,BitlBee} IRC
-gateway daemon.  Its value is a @code{bitlbee-configuration} (see below).
-To have BitlBee listen on port 6667 on localhost, add this line to your
-services:
-@example
-(service bitlbee-service-type)
-@end example
-@end defvr
-@deftp {Data Type} bitlbee-configuration
-This is the configuration for BitlBee, with the following fields:
-@table @asis
-@item @code{interface} (default: @code{"127.0.0.1"})
-@itemx @code{port} (default: @code{6667})
-Listen on the network interface corresponding to the IP address specified in
-@var{interface}, on @var{port}.
-When @var{interface} is @code{127.0.0.1}, only local clients can connect;
-when it is @code{0.0.0.0}, connections can come from any networking
-interface.
-@item @code{package} (default: @code{bitlbee})
-The BitlBee package to use.
-@item @code{plugins} (Vorgabe: @code{'()})
-List of plugin packages to use---e.g., @code{bitlbee-discord}.
-@item @code{extra-settings} (default: @code{""})
-Configuration snippet added as-is to the BitlBee configuration file.
-@end table
-@end deftp
-@subsubheading Quassel-Dienst
-@cindex IRC (Internet Relay Chat)
-@url{https://quassel-irc.org/,Quassel} is a distributed IRC client, meaning
-that one or more clients can attach to and detach from the central core.
-@defvr {Scheme-Variable} quassel-service-type
-This is the service type for the @url{https://quassel-irc.org/,Quassel} IRC
-backend daemon.  Its value is a @code{quassel-configuration} (see below).
-@end defvr
-@deftp {Datentyp} quassel-configuration
-This is the configuration for Quassel, with the following fields:
-@table @asis
-@item @code{quassel} (Vorgabe: @code{quassel})
-Das zu verwendende Quassel-Paket.
-@item @code{interface} (Vorgabe: @code{"::,0.0.0.0"})
-@item @code{port} (Vorgabe: @code{4242})
-Listen on the network interface(s) corresponding to the IPv4 or IPv6
-interfaces specified in the comma delimited @var{interface}, on @var{port}.
-@item @code{loglevel} (Vorgabe: @code{"Info"})
-The level of logging desired.  Accepted values are Debug, Info, Warning and
-Error.
-@end table
-@end deftp
-@node Telefondienste
-@subsection Telefondienste
-@cindex Murmur (VoIP server)
-@cindex VoIP server
-This section describes how to set up and run a Murmur server.  Murmur is the
-server of the @uref{https://mumble.info, Mumble} voice-over-IP (VoIP) suite.
-@deftp {Data Type} murmur-configuration
-The service type for the Murmur server.  An example configuration can look
-like this:
-@example
-(service murmur-service-type
-         (murmur-configuration
-          (welcome-text
-            "Welcome to this Mumble server running on Guix!")
-          (cert-required? #t) ;disallow text password logins
-          (ssl-cert "/etc/letsencrypt/live/mumble.example.com/fullchain.pem")
-          (ssl-key "/etc/letsencrypt/live/mumble.example.com/privkey.pem")))
-@end example
-After reconfiguring your system, you can manually set the murmur
-@code{SuperUser} password with the command that is printed during the
-activation phase.
-It is recommended to register a normal Mumble user account and grant it
-admin or moderator rights.  You can use the @code{mumble} client to login as
-new normal user, register yourself, and log out.  For the next step login
-with the name @code{SuperUser} use the @code{SuperUser} password that you
-set previously, and grant your newly registered mumble user administrator or
-moderator rights and create some channels.
-Available @code{murmur-configuration} fields are:
-@table @asis
-@item @code{package} (default: @code{mumble})
-Package that contains @code{bin/murmurd}.
-@item @code{user} (default: @code{"murmur"})
-User who will run the Murmur server.
-@item @code{group} (default: @code{"murmur"})
-Group of the user who will run the murmur server.
-@item @code{port} (default: @code{64738})
-Port on which the server will listen.
-@item @code{welcome-text} (default: @code{""})
-Welcome text sent to clients when they connect.
-@item @code{server-password} (default: @code{""})
-Password the clients have to enter in order to connect.
-@item @code{max-users} (default: @code{100})
-Maximum of users that can be connected to the server at once.
-@item @code{max-user-bandwidth} (default: @code{#f})
-Maximum voice traffic a user can send per second.
-@item @code{database-file} (default: @code{"/var/lib/murmur/db.sqlite"})
-File name of the sqlite database.  The service's user will become the owner
-of the directory.
-@item @code{log-file} (default: @code{"/var/log/murmur/murmur.log"})
-File name of the log file.  The service's user will become the owner of the
-directory.
-@item @code{autoban-attempts} (default: @code{10})
-Maximum number of logins a user can make in @code{autoban-timeframe} without
-getting auto banned for @code{autoban-time}.
-@item @code{autoban-timeframe} (default: @code{120})
-Timeframe for autoban in seconds.
-@item @code{autoban-time} (default: @code{300})
-Amount of time in seconds for which a client gets banned when violating the
-autoban limits.
-@item @code{opus-threshold} (default: @code{100})
-Percentage of clients that need to support opus before switching over to
-opus audio codec.
-@item @code{channel-nesting-limit} (default: @code{10})
-How deep channels can be nested at maximum.
-@item @code{channelname-regex} (default: @code{#f})
-A string in form of a Qt regular expression that channel names must conform
-to.
-@item @code{username-regex} (default: @code{#f})
-A string in form of a Qt regular expression that user names must conform to.
-@item @code{text-message-length} (default: @code{5000})
-Maximum size in bytes that a user can send in one text chat message.
-@item @code{image-message-length} (default: @code{(* 128 1024)})
-Maximum size in bytes that a user can send in one image message.
-@item @code{cert-required?} (default: @code{#f})
-If it is set to @code{#t} clients that use weak password authentification
-will not be accepted. Users must have completed the certificate wizard to
-join.
-@item @code{remember-channel?} (Vorgabe: @code{#f})
-Should murmur remember the last channel each user was in when they
-disconnected and put them into the remembered channel when they rejoin.
-@item @code{allow-html?} (default: @code{#f})
-Should html be allowed in text messages, user comments, and channel
-descriptions.
-@item @code{allow-ping?} (default: @code{#f})
-Setting to true exposes the current user count, the maximum user count, and
-the server's maximum bandwidth per client to unauthenticated users. In the
-Mumble client, this information is shown in the Connect dialog.
-Disabling this setting will prevent public listing of the server.
-@item @code{bonjour?} (default: @code{#f})
-Should the server advertise itself in the local network through the bonjour
-protocol.
-@item @code{send-version?} (default: @code{#f})
-Should the murmur server version be exposed in ping requests.
-@item @code{log-days} (default: @code{31})
-Murmur also stores logs in the database, which are accessible via RPC.  The
-default is 31 days of months, but you can set this setting to 0 to keep logs
-forever, or -1 to disable logging to the database.
-@item @code{obfuscate-ips?} (Vorgabe: @code{#t})
-Should logged ips be obfuscated to protect the privacy of users.
-@item @code{ssl-cert} (default: @code{#f})
-File name of the SSL/TLS certificate used for encrypted connections.
-@example
-(ssl-cert "/etc/letsencrypt/live/example.com/fullchain.pem")
-@end example
-@item @code{ssl-key} (default: @code{#f})
-Filepath to the ssl private key used for encrypted connections.
-@example
-(ssl-key "/etc/letsencrypt/live/example.com/privkey.pem")
-@end example
-@item @code{ssl-dh-params} (default: @code{#f})
-File name of a PEM-encoded file with Diffie-Hellman parameters for the
-SSL/TLS encryption.  Alternatively you set it to @code{"@@ffdhe2048"},
-@code{"@@ffdhe3072"}, @code{"@@ffdhe4096"}, @code{"@@ffdhe6144"} or
-@code{"@@ffdhe8192"} to use bundled parameters from RFC 7919.
-@item @code{ssl-ciphers} (default: @code{#f})
-The @code{ssl-ciphers} option chooses the cipher suites to make available
-for use in SSL/TLS.
-This option is specified using
-@uref{https://www.openssl.org/docs/apps/ciphers.html#CIPHER-LIST-FORMAT,
-OpenSSL cipher list notation}.
-It is recommended that you try your cipher string using 'openssl ciphers
-<string>' before setting it here, to get a feel for which cipher suites you
-will get.  After setting this option, it is recommend that you inspect your
-Murmur log to ensure that Murmur is using the cipher suites that you
-expected it to.
-Note: Changing this option may impact the backwards compatibility of your
-Murmur server, and can remove the ability for older Mumble clients to be
-able to connect to it.
-@item @code{public-registration} (default: @code{#f})
-Must be a @code{<murmur-public-registration-configuration>} record or
-@code{#f}.
-You can optionally register your server in the public server list that the
-@code{mumble} client shows on startup.  You cannot register your server if
-you have set a @code{server-password}, or set @code{allow-ping} to
-@code{#f}.
-It might take a few hours until it shows up in the public list.
-@item @code{file} (default: @code{#f})
-Optional alternative override for this configuration.
-@end table
-@end deftp
-@deftp {Data Type} murmur-public-registration-configuration
-Configuration for public registration of a murmur service.
-@table @asis
-@item @code{name}
-This is a display name for your server. Not to be confused with the
-hostname.
-@item @code{password}
-A password to identify your registration.  Subsequent updates will need the
-same password. Don't lose your password.
-@item @code{url}
-This should be a @code{http://} or @code{https://} link to your web site.
-@item @code{hostname} (default: @code{#f})
-By default your server will be listed by its IP address.  If it is set your
-server will be linked by this host name instead.
-@end table
-@end deftp
-@node Überwachungsdienste
-@subsection Überwachungsdienste
-@subsubheading Tailon Service
-@uref{https://tailon.readthedocs.io/, Tailon} is a web application for
-viewing and searching log files.
-The following example will configure the service with default values.  By
-default, Tailon can be accessed on port 8080 (@code{http://localhost:8080}).
-@example
-(service tailon-service-type)
-@end example
-The following example customises more of the Tailon configuration, adding
-@command{sed} to the list of allowed commands.
-@example
-(service tailon-service-type
-         (tailon-configuration
-           (config-file
-             (tailon-configuration-file
-               (allowed-commands '("tail" "grep" "awk" "sed"))))))
-@end example
-@deftp {Data Type} tailon-configuration
-Data type representing the configuration of Tailon.  This type has the
-following parameters:
-@table @asis
-@item @code{config-file} (default: @code{(tailon-configuration-file)})
-The configuration file to use for Tailon. This can be set to a
-@dfn{tailon-configuration-file} record value, or any gexp
-(@pxref{G-Ausdrücke}).
-For example, to instead use a local file, the @code{local-file} function can
-be used:
-@example
-(service tailon-service-type
-         (tailon-configuration
-           (config-file (local-file "./my-tailon.conf"))))
-@end example
-@item @code{package} (default: @code{tailon})
-The tailon package to use.
-@end table
-@end deftp
-@deftp {Data Type} tailon-configuration-file
-Data type representing the configuration options for Tailon.  This type has
-the following parameters:
-@table @asis
-@item @code{files} (default: @code{(list "/var/log")})
-List of files to display. The list can include strings for a single file or
-directory, or a list, where the first item is the name of a subsection, and
-the remaining items are the files or directories in that subsection.
-@item @code{bind} (default: @code{"localhost:8080"})
-Address and port to which Tailon should bind on.
-@item @code{relative-root} (default: @code{#f})
-URL path to use for Tailon, set to @code{#f} to not use a path.
-@item @code{allow-transfers?} (default: @code{#t})
-Allow downloading the log files in the web interface.
-@item @code{follow-names?} (default: @code{#t})
-Allow tailing of not-yet existent files.
-@item @code{tail-lines} (default: @code{200})
-Number of lines to read initially from each file.
-@item @code{allowed-commands} (default: @code{(list "tail" "grep" "awk")})
-Commands to allow running. By default, @code{sed} is disabled.
-@item @code{debug?} (default: @code{#f})
-Set @code{debug?} to @code{#t} to show debug messages.
-@item @code{wrap-lines} (default: @code{#t})
-Initial line wrapping state in the web interface. Set to @code{#t} to
-initially wrap lines (the default), or to @code{#f} to initially not wrap
-lines.
-@item @code{http-auth} (default: @code{#f})
-HTTP authentication type to use. Set to @code{#f} to disable authentication
-(the default). Supported values are @code{"digest"} or @code{"basic"}.
-@item @code{users} (default: @code{#f})
-If HTTP authentication is enabled (see @code{http-auth}), access will be
-restricted to the credentials provided here. To configure users, use a list
-of pairs, where the first element of the pair is the username, and the 2nd
-element of the pair is the password.
-@example
-(tailon-configuration-file
-  (http-auth "basic")
-  (users     '(("user1" . "password1")
-               ("user2" . "password2"))))
-@end example
-@end table
-@end deftp
-@subsubheading Darkstat Service
-@cindex darkstat
-Darkstat is a packet sniffer that captures network traffic, calculates
-statistics about usage, and serves reports over HTTP.
-@defvar {Scheme Variable} darkstat-service-type
-This is the service type for the @uref{https://unix4lyfe.org/darkstat/,
-darkstat} service, its value must be a @code{darkstat-configuration} record
-as in this example:
-@example
-(service darkstat-service-type
-         (darkstat-configuration
-           (interface "eno1")))
-@end example
-@end defvar
-@deftp {Data Type} darkstat-configuration
-Data type representing the configuration of @command{darkstat}.
-@table @asis
-@item @code{package} (default: @code{darkstat})
-The darkstat package to use.
-@item @code{interface}
-Capture traffic on the specified network interface.
-@item @code{port} (default: @code{"667"})
-Bind the web interface to the specified port.
-@item @code{bind-address} (default: @code{"127.0.0.1"})
-Bind the web interface to the specified address.
-@item @code{base} (default: @code{"/"})
-Specify the path of the base URL.  This can be useful if @command{darkstat}
-is accessed via a reverse proxy.
-@end table
-@end deftp
-@subsubheading Prometheus Node Exporter Service
-@cindex prometheus-node-exporter
-The Prometheus ``node exporter'' makes hardware and operating system
-statistics provided by the Linux kernel available for the Prometheus
-monitoring system.  This service should be deployed on all physical nodes
-and virtual machines, where monitoring these statistics is desirable.
-@defvar {Scheme variable} prometheus-node-exporter-service-type
-This is the service type for the
-@uref{https://github.com/prometheus/node_exporter/,
-prometheus-node-exporter} service, its value must be a
-@code{prometheus-node-exporter-configuration} record as in this example:
-@example
-(service prometheus-node-exporter-service-type
-         (prometheus-node-exporter-configuration
-           (web-listen-address ":9100")))
-@end example
-@end defvar
-@deftp {Data Type} prometheus-node-exporter-configuration
-Repräsentiert die Konfiguration von @command{node_exporter}.
-@table @asis
-@item @code{package} (Vorgabe: @code{go-github-com-prometheus-node-exporter})
-Das Paket für den prometheus-node-exporter, was benutzt werden soll.
-@item @code{web-listen-address} (Vorgabe: @code{":9100"})
-Bind the web interface to the specified address.
-@end table
-@end deftp
-@subsubheading Zabbix-Server
-@cindex zabbix zabbix-server
-Zabbix provides monitoring metrics, among others network utilization, CPU
-load and disk space consumption:
-@itemize
-@item High performance, high capacity (able to monitor hundreds of thousands of devices).
-@item Auto-discovery of servers and network devices and interfaces.
-@item Low-level discovery, allows to automatically start monitoring new items, file systems or network interfaces among others.
-@item Distributed monitoring with centralized web administration.
-@item Native high performance agents.
-@item SLA, and ITIL KPI metrics on reporting.
-@item High-level (business) view of monitored resources through user-defined visual console screens and dashboards.
-@item Remote command execution through Zabbix proxies.
-@end itemize
-@c %start of fragment
-Available @code{zabbix-server-configuration} fields are:
-@deftypevr {@code{zabbix-server-configuration} parameter} package zabbix-server
-Das zabbix-server-Paket.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string user
-User who will run the Zabbix server.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} group group
-Group who will run the Zabbix server.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string db-host
-Rechnername der Datenbank.
-Defaults to @samp{"127.0.0.1"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string db-name
-Datenbankname.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string db-user
-Benutzerkonto der Datenbank.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string db-password
-Database password.  Please, use @code{include-files} with
-@code{DBPassword=SECRET} inside a specified file instead.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} number db-port
-Datenbank-Portnummer.
-Defaults to @samp{5432}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string log-type
-Specifies where log messages are written to:
-@itemize @bullet
-@item
-@code{system} - syslog.
-@item
-@code{file} - file specified with @code{log-file} parameter.
-@item
-@code{console} - standard output.
-@end itemize
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string log-file
-Log file name for @code{log-type} @code{file} parameter.
-Defaults to @samp{"/var/log/zabbix/server.log"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string pid-file
-Name der PID-Datei.
-Defaults to @samp{"/var/run/zabbix/zabbix_server.pid"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string ssl-ca-location
-The location of certificate authority (CA) files for SSL server certificate
-verification.
-Defaults to @samp{"/etc/ssl/certs/ca-certificates.crt"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string ssl-cert-location
-Location of SSL client certificates.
-Defaults to @samp{"/etc/ssl/certs"}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} string extra-options
-Extra options will be appended to Zabbix server configuration file.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-server-configuration} parameter} include-files include-files
-You may include individual files or all files in a directory in the
-configuration file.
-Defaults to @samp{()}.
-@end deftypevr
-@c %end of fragment
-@subsubheading Zabbix agent
-@cindex zabbix zabbix-agent
-Zabbix agent gathers information for Zabbix server.
-@c %start of fragment
-Available @code{zabbix-agent-configuration} fields are:
-@deftypevr {@code{zabbix-agent-configuration} parameter} package zabbix-agent
-Das zabbix-agent-Paket.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string user
-User who will run the Zabbix agent.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} group group
-Group who will run the Zabbix agent.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string hostname
-Unique, case sensitive hostname which is required for active checks and must
-match hostname as configured on the server.
-Defaults to @samp{"Zabbix server"}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string log-type
-Specifies where log messages are written to:
-@itemize @bullet
-@item
-@code{system} - syslog.
-@item
-@code{file} - file specified with @code{log-file} parameter.
-@item
-@code{console} - standard output.
-@end itemize
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string log-file
-Log file name for @code{log-type} @code{file} parameter.
-Defaults to @samp{"/var/log/zabbix/agent.log"}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string pid-file
-Name der PID-Datei.
-Defaults to @samp{"/var/run/zabbix/zabbix_agent.pid"}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} list server
-List of IP addresses, optionally in CIDR notation, or hostnames of Zabbix
-servers and Zabbix proxies.  Incoming connections will be accepted only from
-the hosts listed here.
-Defaults to @samp{("127.0.0.1")}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} list server-active
-List of IP:port (or hostname:port) pairs of Zabbix servers and Zabbix
-proxies for active checks.  If port is not specified, default port is used.
-If this parameter is not specified, active checks are disabled.
-Defaults to @samp{("127.0.0.1")}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} string extra-options
-Extra options will be appended to Zabbix server configuration file.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-agent-configuration} parameter} include-files include-files
-You may include individual files or all files in a directory in the
-configuration file.
-Defaults to @samp{()}.
-@end deftypevr
-@c %end of fragment
-@subsubheading Zabbix front-end
-@cindex zabbix zabbix-front-end
-This service provides a WEB interface to Zabbix server.
-@c %start of fragment
-Available @code{zabbix-front-end-configuration} fields are:
-@deftypevr {@code{zabbix-front-end-configuration} parameter} nginx-server-configuration-list nginx
-NGINX configuration.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string db-host
-Rechnername der Datenbank.
-Defaults to @samp{"localhost"}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} number db-port
-Datenbank-Portnummer.
-Defaults to @samp{5432}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string db-name
-Datenbankname.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string db-user
-Benutzerkonto der Datenbank.
-Defaults to @samp{"zabbix"}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string db-password
-Database password.  Please, use @code{db-secret-file} instead.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string db-secret-file
-Secret file which will be appended to @file{zabbix.conf.php} file.  This
-file contains credentials for use by Zabbix front-end.  You are expected to
-create it manually.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} string zabbix-host
-Zabbix server hostname.
-Defaults to @samp{"localhost"}.
-@end deftypevr
-@deftypevr {@code{zabbix-front-end-configuration} parameter} number zabbix-port
-Zabbix server port.
-Defaults to @samp{10051}.
-@end deftypevr
-@c %end of fragment
-@node Kerberos-Dienste
-@subsection Kerberos-Dienste
-@cindex Kerberos
-The @code{(gnu services kerberos)} module provides services relating to the
-authentication protocol @dfn{Kerberos}.
-@subsubheading Krb5 Service
-Programs using a Kerberos client library normally expect a configuration
-file in @file{/etc/krb5.conf}.  This service generates such a file from a
-definition provided in the operating system declaration.  It does not cause
-any daemon to be started.
-No ``keytab'' files are provided by this service---you must explicitly
-create them.  This service is known to work with the MIT client library,
-@code{mit-krb5}.  Other implementations have not been tested.
-@defvr {Scheme Variable} krb5-service-type
-A service type for Kerberos 5 clients.
-@end defvr
-@noindent
-Here is an example of its use:
-@lisp
-(service krb5-service-type
-         (krb5-configuration
-          (default-realm "EXAMPLE.COM")
-          (allow-weak-crypto? #t)
-          (realms (list
-                   (krb5-realm
-                    (name "EXAMPLE.COM")
-                    (admin-server "groucho.example.com")
-                    (kdc "karl.example.com"))
-                   (krb5-realm
-                    (name "ARGRX.EDU")
-                    (admin-server "kerb-admin.argrx.edu")
-                    (kdc "keys.argrx.edu"))))))
-@end lisp
-@noindent
-This example provides a Kerberos@tie{}5 client configuration which:
-@itemize
-@item Recognizes two realms, @i{viz:} ``EXAMPLE.COM'' and ``ARGRX.EDU'', both
-of which have distinct administration servers and key distribution centers;
-@item Will default to the realm ``EXAMPLE.COM'' if the realm is not explicitly
-specified by clients;
-@item Accepts services which only support encryption types known to be weak.
-@end itemize
-The @code{krb5-realm} and @code{krb5-configuration} types have many fields.
-Only the most commonly used ones are described here.  For a full list, and
-more detailed explanation of each, see the MIT
-@uref{http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html,,krb5.conf}
-documentation.
-@deftp {Data Type} krb5-realm
-@cindex realm, kerberos
-@table @asis
-@item @code{name}
-This field is a string identifying the name of the realm.  A common
-convention is to use the fully qualified DNS name of your organization,
-converted to upper case.
-@item @code{admin-server}
-This field is a string identifying the host where the administration server
-is running.
-@item @code{kdc}
-This field is a string identifying the key distribution center for the
-realm.
-@end table
-@end deftp
-@deftp {Data Type} krb5-configuration
-@table @asis
-@item @code{allow-weak-crypto?} (default: @code{#f})
-If this flag is @code{#t} then services which only offer encryption
-algorithms known to be weak will be accepted.
-@item @code{default-realm} (default: @code{#f})
-This field should be a string identifying the default Kerberos realm for the
-client.  You should set this field to the name of your Kerberos realm.  If
-this value is @code{#f} then a realm must be specified with every Kerberos
-principal when invoking programs such as @command{kinit}.
-@item @code{realms}
-This should be a non-empty list of @code{krb5-realm} objects, which clients
-may access.  Normally, one of them will have a @code{name} field matching
-the @code{default-realm} field.
-@end table
-@end deftp
-@subsubheading PAM krb5 Service
-@cindex pam-krb5
-The @code{pam-krb5} service allows for login authentication and password
-management via Kerberos.  You will need this service if you want PAM enabled
-applications to authenticate users using Kerberos.
-@defvr {Scheme Variable} pam-krb5-service-type
-A service type for the Kerberos 5 PAM module.
-@end defvr
-@deftp {Data Type} pam-krb5-configuration
-Data type representing the configuration of the Kerberos 5 PAM module This
-type has the following parameters:
-@table @asis
-@item @code{pam-krb5} (default: @code{pam-krb5})
-The pam-krb5 package to use.
-@item @code{minimum-uid} (default: @code{1000})
-The smallest user ID for which Kerberos authentications should be
-attempted.  Local accounts with lower values will silently fail to
-authenticate.
-@end table
-@end deftp
-@node LDAP-Dienste
-@subsection LDAP-Dienste
-@cindex LDAP
-@cindex nslcd, LDAP service
-The @code{(gnu services authentication)} module provides the
-@code{nslcd-service-type}, which can be used to authenticate against an LDAP
-server.  In addition to configuring the service itself, you may want to add
-@code{ldap} as a name service to the Name Service Switch. @xref{Name Service Switch} for detailed information.
-Here is a simple operating system declaration with a default configuration
-of the @code{nslcd-service-type} and a Name Service Switch configuration
-that consults the @code{ldap} name service last:
-@example
-(use-service-modules authentication)
-(use-modules (gnu system nss))
-...
-(operating-system
-  ...
-  (services
-    (cons*
-      (service nslcd-service-type)
-      (service dhcp-client-service-type)
-      %base-services))
-  (name-service-switch
-   (let ((services (list (name-service (name "db"))
-                         (name-service (name "files"))
-                         (name-service (name "ldap")))))
-     (name-service-switch
-      (inherit %mdns-host-lookup-nss)
-      (password services)
-      (shadow   services)
-      (group    services)
-      (netgroup services)
-      (gshadow  services)))))
-@end example
-@c %start of generated documentation for nslcd-configuration
-Available @code{nslcd-configuration} fields are:
-@deftypevr {@code{nslcd-configuration} parameter} package nss-pam-ldapd
-Das @code{nss-pam-ldapd}-Paket, was benutzt werden soll.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number threads
-The number of threads to start that can handle requests and perform LDAP
-queries.  Each thread opens a separate connection to the LDAP server.  The
-default is to start 5 threads.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} string uid
-This specifies the user id with which the daemon should be run.
-Defaults to @samp{"nslcd"}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} string gid
-This specifies the group id with which the daemon should be run.
-Defaults to @samp{"nslcd"}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} log-option log
-This option controls the way logging is done via a list containing SCHEME
-and LEVEL.  The SCHEME argument may either be the symbols "none" or
-"syslog", or an absolute file name.  The LEVEL argument is optional and
-specifies the log level.  The log level may be one of the following symbols:
-"crit", "error", "warning", "notice", "info" or "debug".  All messages with
-the specified log level or higher are logged.
-Defaults to @samp{("/var/log/nslcd" info)}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} list uri
-The list of LDAP server URIs.  Normally, only the first server will be used
-with the following servers as fall-back.
-Defaults to @samp{("ldap://localhost:389/")}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string ldap-version
-The version of the LDAP protocol to use.  The default is to use the maximum
-version supported by the LDAP library.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string binddn
-Specifies the distinguished name with which to bind to the directory server
-for lookups.  The default is to bind anonymously.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string bindpw
-Specifies the credentials with which to bind.  This option is only
-applicable when used with binddn.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string rootpwmoddn
-Specifies the distinguished name to use when the root user tries to modify a
-user's password using the PAM module.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string rootpwmodpw
-Specifies the credentials with which to bind if the root user tries to
-change a user's password.  This option is only applicable when used with
-rootpwmoddn
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-mech
-Specifies the SASL mechanism to be used when performing SASL authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-realm
-Specifies the SASL realm to be used when performing SASL authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-authcid
-Specifies the authentication identity to be used when performing SASL
-authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-authzid
-Specifies the authorization identity to be used when performing SASL
-authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean sasl-canonicalize?
-Determines whether the LDAP server host name should be canonicalised.  If
-this is enabled the LDAP library will do a reverse host name lookup.  By
-default, it is left up to the LDAP library whether this check is performed
-or not.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string krb5-ccname
-Set the name for the GSS-API Kerberos credentials cache.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} string base
-Basis für die Verzeichnissuche.
-Vorgegeben ist @samp{"dc=example,dc=com"}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} scope-option scope
-Specifies the search scope (subtree, onelevel, base or children).  The
-default scope is subtree; base scope is almost never useful for name service
-lookups; children scope is not supported on all servers.
-Defaults to @samp{(subtree)}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-deref-option deref
-Specifies the policy for dereferencing aliases.  The default policy is to
-never dereference aliases.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean referrals
-Specifies whether automatic referral chasing should be enabled.  The default
-behaviour is to chase referrals.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} list-of-map-entries maps
-This option allows for custom attributes to be looked up instead of the
-default RFC 2307 attributes.  It is a list of maps, each consisting of the
-name of a map, the RFC 2307 attribute to match and the query expression for
-the attribute as it is available in the directory.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} list-of-filter-entries filters
-A list of filters consisting of the name of a map to which the filter
-applies and an LDAP search filter expression.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number bind-timelimit
-Specifies the time limit in seconds to use when connecting to the directory
-server.  The default value is 10 seconds.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number timelimit
-Specifies the time limit (in seconds) to wait for a response from the LDAP
-server.  A value of zero, which is the default, is to wait indefinitely for
-searches to be completed.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number idle-timelimit
-Specifies the period if inactivity (in seconds) after which the con‐ nection
-to the LDAP server will be closed.  The default is not to time out
-connections.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number reconnect-sleeptime
-Specifies the number of seconds to sleep when connecting to all LDAP servers
-fails.  By default one second is waited between the first failure and the
-first retry.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number reconnect-retrytime
-Specifies the time after which the LDAP server is considered to be
-permanently unavailable.  Once this time is reached retries will be done
-only once per this time period.  The default value is 10 seconds.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-ssl-option ssl
-Specifies whether to use SSL/TLS or not (the default is not to).  If
-'start-tls is specified then StartTLS is used rather than raw LDAP over SSL.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-tls-reqcert-option tls-reqcert
-Specifies what checks to perform on a server-supplied certificate.  The
-meaning of the values is described in the ldap.conf(5) manual page.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cacertdir
-Specifies the directory containing X.509 certificates for peer authen‐
-tication.  This parameter is ignored when using GnuTLS.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cacertfile
-Specifies the path to the X.509 certificate for peer authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-randfile
-Specifies the path to an entropy source.  This parameter is ignored when
-using GnuTLS.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-ciphers
-Specifies the ciphers to use for TLS as a string.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cert
-Specifies the path to the file containing the local certificate for client
-TLS authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-key
-Specifies the path to the file containing the private key for client TLS
-authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number pagesize
-Set this to a number greater than 0 to request paged results from the LDAP
-server in accordance with RFC2696.  The default (0) is to not request paged
-results.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-ignore-users-option nss-initgroups-ignoreusers
-This option prevents group membership lookups through LDAP for the specified
-users.  Alternatively, the value 'all-local may be used.  With that value
-nslcd builds a full list of non-LDAP users on startup.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-min-uid
-This option ensures that LDAP users with a numeric user id lower than the
-specified value are ignored.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-uid-offset
-This option specifies an offset that is added to all LDAP numeric user ids.
-This can be used to avoid user id collisions with local users.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-gid-offset
-This option specifies an offset that is added to all LDAP numeric group
-ids.  This can be used to avoid user id collisions with local groups.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-nested-groups
-If this option is set, the member attribute of a group may point to another
-group.  Members of nested groups are also returned in the higher level group
-and parent groups are returned when finding groups for a specific user.  The
-default is not to perform extra searches for nested groups.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-getgrent-skipmembers
-If this option is set, the group member list is not retrieved when looking
-up groups.  Lookups for finding which groups a user belongs to will remain
-functional so the user will likely still get the correct groups assigned on
-login.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-disable-enumeration
-If this option is set, functions which cause all user/group entries to be
-loaded from the directory will not succeed in doing so.  This can
-dramatically reduce LDAP server load in situations where there are a great
-number of users and/or groups.  This option is not recommended for most
-configurations.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string validnames
-This option can be used to specify how user and group names are verified
-within the system.  This pattern is used to check all user and group names
-that are requested and returned from LDAP.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean ignorecase
-This specifies whether or not to perform searches using case-insensitive
-matching.  Enabling this could open up the system to authorization bypass
-vulnerabilities and introduce nscd cache poisoning vulnerabilities which
-allow denial of service.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-boolean pam-authc-ppolicy
-This option specifies whether password policy controls are requested and
-handled from the LDAP server when performing user authentication.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-authc-search
-By default nslcd performs an LDAP search with the user's credentials after
-BIND (authentication) to ensure that the BIND operation was successful.  The
-default search is a simple check to see if the user's DN exists.  A search
-filter can be specified that will be used instead.  It should return at
-least one entry.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-authz-search
-This option allows flexible fine tuning of the authorisation check that
-should be performed.  The search filter specified is executed and if any
-entries match, access is granted, otherwise access is denied.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-password-prohibit-message
-If this option is set password modification using pam_ldap will be denied
-and the specified message will be presented to the user instead.  The
-message can be used to direct the user to an alternative means of changing
-their password.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{nslcd-configuration} parameter} list pam-services
-List of pam service names for which LDAP authentication should suffice.
-Defaults to @samp{()}.
-@end deftypevr
-@c %end of generated documentation for nslcd-configuration
-@node Web-Dienste
-@subsection Web-Dienste
-@cindex Web
-@cindex WWW
-@cindex HTTP
-Das Modul @code{(gnu services web)} stellt den Apache-HTTP-Server, den
-nginx-Webserver und auch einen fastcgi-Wrapperdienst bereit.
-@subsubheading Apache-HTTP-Server
-@deffn {Scheme-Variable} httpd-service-type
-Diensttyp für den @uref{https://httpd.apache.org/,Apache-HTTP-Server}
-(@dfn{httpd}). Der Wert dieses Diensttyps ist ein
-@code{httpd-configuration}-Verbund.
-Es folgt ein einfaches Beispiel der Konfiguration.
-@example
-(service httpd-service-type
-         (httpd-configuration
-           (config
-             (httpd-config-file
-               (server-name "www.example.com")
-               (document-root "/srv/http/www.example.com")))))
-@end example
-Andere Dienste können den @code{httpd-service-type} auch erweitern, um etwas
-zur Konfiguration hinzuzufügen.
-@example
-(simple-service 'my-extra-server httpd-service-type
-                (list
-                  (httpd-virtualhost
-                    "*:80"
-                    (list (string-append
-                           "ServerName "www.example.com
-                            DocumentRoot \"/srv/http/www.example.com\"")))))
-@end example
-@end deffn
-Nun folgt eine Beschreibung der Verbundstypen @code{httpd-configuration},
-@code{httpd-module}, @code{httpd-config-file} und @code{httpd-virtualhost}.
-@deffn {Datentyp} httpd-configuration
-Dieser Datentyp repräsentiert die Konfiguration des httpd-Dienstes.
-@table @asis
-@item @code{package} (Vorgabe: @code{httpd})
-Das zu benutzende httpd-Paket.
-@item @code{pid-file} (Vorgabe: @code{"/var/run/httpd"})
-Die vom Shepherd-Dienst benutzte PID-Datei.
-@item @code{config} (Vorgabe: @code{(httpd-config-file)})
-Die vom httpd-Dienst zu benutzende Konfigurationsdatei. Vorgegeben ist ein
-@code{httpd-config-file}-Verbundsobjekt, aber als Wert kann auch ein anderer
-G-Ausdruck benutzt werden, der eine Datei erzeugt, zum Beispiel ein
-@code{plain-file}. Es kann auch eine Datei außerhalb des Stores mit einer
-Zeichenkette angegeben werden.
-@end table
-@end deffn
-@deffn {Datentyp} httpd-module
-Dieser Datentyp steht für ein Modul des httpd-Dienstes.
-@table @asis
-@item @code{name}
-Der Name des Moduls.
-@item @code{file}
-Die Datei, in der das Modul steht. Sie kann relativ zum benutzten
-httpd-Paket oder als absoluter Pfad einer Datei oder als ein G-Ausdruck für
-eine Datei im Store angegeben werden, zum Beispiel @code{(file-append
-mod-wsgi "/modules/mod_wsgi.so")}.
-@end table
-@end deffn
-@defvr {Scheme-Variable} %default-httpd-modules
-Eine vorgegebene Liste von @code{httpd-module}-Objekten.
-@end defvr
-@deffn {Datentyp} httpd-config-file
-Dieser Datentyp repräsentiert eine Konfigurationsdatei für den httpd-Dienst.
-@table @asis
-@item @code{modules} (Vorgabe: @code{%default-httpd-modules})
-Welche Module geladen werden sollen. Zusätzliche Module können hier
-eingetragen werden oder durch eine zusätzliche Konfigurationsangabe geladen
-werden.
-Um zum Beispiel Anfragen nach PHP-Dateien zu behandeln, können Sie das Modul
-@code{mod_proxy_fcgi} von Apache zusammen mit @code{php-fpm-service-type}
-benutzen:
-@example
-(service httpd-service-type
-         (httpd-configuration
-          (config
-           (httpd-config-file
-            (modules (cons*
-                      (httpd-module
-                       (name "proxy_module")
-                       (file "modules/mod_proxy.so"))
-                      (httpd-module
-                       (name "proxy_fcgi_module")
-                       (file "modules/mod_proxy_fcgi.so"))
-                      %default-httpd-modules))
-            (extra-config (list "\
-<FilesMatch \\.php$>
-    SetHandler \"proxy:unix:/var/run/php-fpm.sock|fcgi://localhost/\"
-</FilesMatch>"))))))
-(service php-fpm-service-type
-         (php-fpm-configuration
-          (socket "/var/run/php-fpm.sock")
-          (socket-group "httpd")))
-@end example
-@item @code{server-root} (Vorgabe: @code{httpd})
-Die @code{ServerRoot} in der Konfigurationsdatei, vorgegeben ist das
-httpd-Paket. Direktiven wie @code{Include} und @code{LoadModule} werden
-relativ zur ServerRoot interpretiert.
-@item @code{server-name} (Vorgabe: @code{#f})
-Der @code{ServerName} in der Konfigurationsdatei, mit dem das Anfrageschema
-(Request Scheme), der Rechnername (Hostname) und Port angegeben wird, mit
-denen sich der Server identifiziert.
-Es muss nicht als Teil der Server-Konfiguration festgelegt werden, sondern
-kann auch in virtuellen Rechnern (Virtual Hosts) festgelegt
-werden. Vorgegeben ist @code{#f}, wodurch kein @code{ServerName} festgelegt
-wird.
-@item @code{document-root} (Vorgabe: @code{"/srv/http"})
-Das @code{DocumentRoot}-Verzeichnis, in dem sich die Dateien befinden, die
-man vom Server abrufen kann.
-@item @code{listen} (Vorgabe: @code{'("80")})
-Die Liste der Werte für die @code{Listen}-Direktive in der
-Konfigurationsdatei. Als Wert sollte eine Liste von Zeichenketten angegeben
-werden, die jeweils die Portnummer, auf der gelauscht wird, und optional
-auch die zu benutzende IP-Adresse und das Protokoll angeben.
-@item @code{pid-file} (Vorgabe: @code{"/var/run/httpd"})
-Hiermit wird die PID-Datei als @code{PidFile}-Direktive angegeben. Der Wert
-sollte mit der @code{pid-file}-Datei in der @code{httpd-configuration}
-übereinstimmen, damit der Shepherd-Dienst richtig konfiguriert ist.
-@item @code{error-log} (Vorgabe: @code{"/var/log/httpd/error_log"})
-Der Ort, an den der Server mit der @code{ErrorLog}-Direktive
-Fehlerprotokolle schreibt.
-@item @code{user} (Vorgabe: @code{"httpd"})
-Der Benutzer, als der der Server durch die @code{User}-Direktive Anfragen
-beantwortet.
-@item @code{group} (Vorgabe: @code{"httpd"})
-Die Gruppe, mit der der Server durch die @code{Group}-Direktive Anfragen
-beantwortet.
-@item @code{extra-config} (Vorgabe: @code{(list "TypesConfig etc/httpd/mime.types")})
-Eine flache Liste von Zeichenketten und G-Ausdrücken, die am Ende der
-Konfigurationsdatei hinzugefügt werden.
-Alle Werte, mit denen dieser Dienst erweitert wird, werden an die Liste
-angehängt.
-@end table
-@end deffn
-@deffn {Datentyp} httpd-virtualhost
-Dieser Datentyp repräsentiert einen Konfigurationsblock für einen virtuellen
-Rechner (Virtual Host) des httpd-Dienstes.
-Sie sollten zur zusätzlichen Konfiguration extra-config des httpd-Dienstes
-hinzugefügt werden.
-@example
-(simple-service 'my-extra-server httpd-service-type
-                (list
-                  (httpd-virtualhost
-                    "*:80"
-                    (list (string-append
-                           "ServerName "www.example.com
-                            DocumentRoot \"/srv/http/www.example.com\"")))))
-@end example
-@table @asis
-@item @code{addresses-and-ports}
-Adressen und Ports für die @code{VirtualHost}-Direktive.
-@item @code{contents}
-Der Inhalt der @code{VirtualHost}-Direktive. Er sollte als Liste von
-Zeichenketten und G-Ausdrücken angegeben werden.
-@end table
-@end deffn
-@subsubheading NGINX
-@deffn {Scheme-Variable} nginx-service-type
-Diensttyp für den @uref{https://nginx.org/,NGinx}-Webserver. Der Wert des
-Dienstes ist ein @code{<nginx-configuration>}-Verbundsobjekt.
-Es folgt ein einfaches Beispiel der Konfiguration.
-@example
-(service nginx-service-type
-         (nginx-configuration
-           (server-blocks
-             (list (nginx-server-configuration
-                     (server-name '("www.example.com"))
-                     (root "/srv/http/www.example.com"))))))
-@end example
-Außer durch direktes Hinzufügen von Server-Blöcken zur Dienstkonfiguration
-kann der Dienst auch durch andere Dienste erweitert werden, um Server-Blöcke
-hinzuzufügen, wie man im folgenden Beispiel sieht:
-@example
-(simple-service 'my-extra-server nginx-service-type
-                (list (nginx-server-configuration
-                        (root "/srv/http/extra-website")
-                        (try-files (list "$uri" "$uri/index.html")))))
-@end example
-@end deffn
-Beim Starten hat @command{nginx} seine Konfigurationsdatei noch nicht
-gelesen und benutzt eine vorgegebene Datei, um Fehlermeldungen zu
-protokollieren. Wenn er seine Konfigurationsdatei nicht laden kann, landen
-Fehlermeldungen also dort. Nachdem die Konfigurationsdatei geladen ist,
-werden Fehlerprotokolle nach Voreinstellung in die Datei geschrieben, die in
-der Konfiguration angegeben ist. In unserem Fall können Sie Fehlermeldungen
-beim Starten in @file{/var/run/nginx/logs/error.log} finden und nachdem die
-Konfiguration eingelesen wurde, finden Sie sie in
-@file{/var/log/nginx/error.log}. Letzterer Ort kann mit der
-Konfigurationsoption @var{log-directory} geändert werden.
-@deffn {Datentyp} nginx-configuration
-Dieser Datentyp repräsentiert die Konfiguration von NGinx. Ein Teil der
-Konfiguration kann hierüber und über die anderen zu Ihrer Verfügung
-stehenden Verbundstypen geschehen, alternativ können Sie eine
-Konfigurationsdatei mitgeben.
-@table @asis
-@item @code{nginx} (Vorgabe: @code{nginx})
-Das zu benutzende nginx-Paket.
-@item @code{log-directory} (Vorgabe: @code{"/var/log/nginx"})
-In welches Verzeichnis NGinx Protokolldateien schreiben wird.
-@item @code{run-directory} (Vorgabe: @code{"/var/run/nginx"})
-In welchem Verzeichnis NGinx eine PID-Datei anlegen und temporäre Dateien
-ablegen wird.
-@item @code{server-blocks} (Vorgabe: @code{'()})
-Eine Liste von @dfn{Server-Blöcken}, die in der erzeugten
-Konfigurationsdatei stehen sollen. Die Elemente davon sollten den Typ
-@code{<nginx-server-configuration>} haben.
-Im folgenden Beispiel wäre NGinx so eingerichtet, dass Anfragen an
-@code{www.example.com} mit Dateien aus dem Verzeichnis
-@code{/srv/http/www.example.com} beantwortet werden, ohne HTTPS zu benutzen.
-@example
-(service nginx-service-type
-         (nginx-configuration
-           (server-blocks
-             (list (nginx-server-configuration
-                     (server-name '("www.example.com"))
-                     (root "/srv/http/www.example.com"))))))
-@end example
-@item @code{upstream-blocks} (Vorgabe: @code{'()})
-Eine Liste von @dfn{Upstream-Blöcken}, die in der erzeugten
-Konfigurationsdatei stehen sollen. Ihre Elemente sollten den Typ
-@code{<nginx-upstream-configuration>} haben.
-Upstreams als @code{upstream-blocks} zu konfigurieren, kann hilfreich sein,
-wenn es mit @code{locations} in @code{<nginx-server-configuration>}
-verbunden wird. Das folgende Beispiel erzeugt eine Server-Konfiguration mit
-einer Location-Konfiguration, bei der Anfragen als Proxy entsprechend einer
-Upstream-Konfiguration weitergeleitet werden, wodurch zwei Server diese
-beantworten können.
-@example
-(service
-  nginx-service-type
-  (nginx-configuration
-    (server-blocks
-      (list (nginx-server-configuration
-              (server-name '("www.example.com"))
-              (root "/srv/http/www.example.com")
-              (locations
-                (list
-                  (nginx-location-configuration
-                  (uri "/path1")
-                  (body '("proxy_pass http://server-proxy;"))))))))
-    (upstream-blocks
-      (list (nginx-upstream-configuration
-              (name "server-proxy")
-              (servers (list "server1.example.com"
-                             "server2.example.com")))))))
-@end example
-@item @code{file} (default: @code{#f})
-Wenn eine Konfigurationsdatei als @var{file} angegeben wird, dann wird diese
-benutzt und @emph{keine} Konfigurationsdatei anhand der angegebenen
-@code{log-directory}, @code{run-directory}, @code{server-blocks} und
-@code{upstream-blocks} erzeugt. Trotzdem sollten diese Argumente bei einer
-richtigen Konfiguration mit denen in der Datei @var{file} übereinstimmen,
-damit die Verzeichnisse bei Aktivierung des Dienstes erzeugt werden.
-Das kann nützlich sein, wenn Sie schon eine bestehende Konfigurationsdatei
-haben oder das, was Sie brauchen, nicht mit anderen Teilen eines
-nginx-configuration-Verbundsobjekts umgesetzt werden kann.
-@item @code{server-names-hash-bucket-size} (Vorgabe: @code{#f})
-Größe der Behälter (englisch »Buckets«) für die Hashtabelle der Servernamen;
-vorgegeben ist @code{#f}, wodurch die Größe der Cache-Lines des Prozessors
-verwendet wird.
-@item @code{server-names-hash-bucket-max-size} (Vorgabe: @code{#f})
-Maximale Behältergröße für die Hashtabelle der Servernamen.
-@item @code{extra-content} (Vorgabe: @code{""})
-Zusätzlicher Inhalt des @code{http}-Blocks. Er sollte eine Zeichenkette oder
-ein zeichenkettenwertiger G-Ausdruck.
-@end table
-@end deffn
-@deftp {Datentyp} nginx-server-configuration
-Der Datentyp, der die Konfiguration eines nginx-Serverblocks
-repräsentiert. Dieser Typ hat die folgenden Parameter:
-@table @asis
-@item @code{listen} (Vorgabe: @code{'("80" "443 ssl")})
-Jede @code{listen}-Direktive legt Adresse und Port für eine IP fest oder
-gibt einen Unix-Socket an, auf dem der Server Anfragen beantwortet. Es
-können entweder sowohl Adresse als auch Port oder nur die Adresse oder nur
-der Port angegeben werden. Als Adresse kann auch ein Rechnername
-(»Hostname«) angegeben werden, zum Beispiel:
-@example
-'("127.0.0.1:8000" "127.0.0.1" "8000" "*:8000" "localhost:8000")
-@end example
-@item @code{server-name} (Vorgabe: @code{(list 'default)})
-Eine Liste von Servernamen, die dieser Server repräsentiert. @code{'default}
-repräsentiert den voreingestellten Server, der für Verbindungen verwendet
-wird, die zu keinem anderen Server passen.
-@item @code{root} (Vorgabe: @code{"/srv/http"})
-Wurzelverzeichnis der Webpräsenz, die über nginx abgerufen werden kann.
-@item @code{locations} (Vorgabe: @code{'()})
-Eine Liste von @dfn{nginx-location-configuration}- oder
-@dfn{nginx-named-location-configuration}-Verbundsobjekten, die innerhalb des
-Serverblocks benutzt werden.
-@item @code{index} (Vorgabe: @code{(list "index.html")})
-Index-Dateien, mit denen Anfragen nach einem Verzeichnis beantwortet
-werden. Wenn @emph{keine} davon gefunden wird, antwortet Nginx mit der Liste
-der Dateien im Verzeichnis.
-@item @code{try-files} (Vorgabe: @code{'()})
-Eine Liste der Dateien, bei denen in der angegebenen Reihenfolge geprüft
-wird, ob sie existieren. @code{nginx} beantwortet die Anfrage mit der ersten
-Datei, die es findet.
-@item @code{ssl-certificate} (Vorgabe: @code{#f})
-Wo das Zertifikat für sichere Verbindungen gespeichert ist. Sie sollten es
-auf @code{#f} setzen, wenn Sie kein Zertifikat haben oder kein HTTPS
-benutzen möchten.
-@item @code{ssl-certificate-key} (Vorgabe: @code{#f})
-Wo der private Schlüssel für sichere Verbindungen gespeichert ist. Sie
-sollten ihn auf @code{#f} setzen, wenn Sie keinen Schlüssel haben oder kein
-HTTPS benutzen möchten.
-@item @code{server-tokens?} (Vorgabe: @code{#f})
-Ob der Server Informationen über seine Konfiguration bei Antworten beilegen
-soll.
-@item @code{raw-content} (Vorgabe: @code{'()})
-Eine Liste von Zeilen, die unverändert in den Serverblock eingefügt werden.
-@end table
-@end deftp
-@deftp {Datentyp} nginx-upstream-configuration
-Der Datentyp, der die Konfiguration eines nginx-@code{upstream}-Blocks
-repräsentiert. Dieser Typ hat folgende Parameter:
-@table @asis
-@item @code{name}
-Der Name dieser Servergruppe.
-@item @code{servers}
-Gibt die Adressen der Server in der Gruppe an. Die Adresse kann als
-IP-Adresse (z.B.@: @samp{127.0.0.1}), Domänenname (z.B.@:
-@samp{backend1.example.com}) oder als Pfad eines Unix-Sockets mit dem
-vorangestellten Präfix @samp{unix:} angegeben werden. Wenn Adressen eine
-IP-Adresse oder einen Domänennamen benutzen, ist der voreingestellte Port
-80, aber ein abweichender Port kann auch explizit angegeben werden.
-@end table
-@end deftp
-@deftp {Datentyp} nginx-location-configuration
-Der Datentyp, der die Konfiguration eines nginx-@code{location}-Blocks
-angibt. Der Typ hat die folgenden Parameter:
-@table @asis
-@item @code{uri}
-Die URI, die auf diesen Block passt.
-@anchor{nginx-location-configuration body}
-@item @code{body}
-Der Rumpf des location-Blocks, der als eine Liste von Zeichenketten
-angegeben werden muss. Er kann viele Konfigurationsdirektiven enthalten, zum
-Beispiel können Anfragen an eine Upstream-Servergruppe weitergeleitet
-werden, die mit einem @code{nginx-upstream-configuration}-Block angegeben
-wurde, indem diese Direktive im Rumpf angegeben wird: @samp{(list
-"proxy_pass http://upstream-name;")}.
-@end table
-@end deftp
-@deftp {Datentyp} nginx-named-location-configuration
-Der Datentyp repräsentiert die Konfiguration eines mit Namen versehenen
-nginx-location-Blocks (»Named Location Block«). Ein mit Namen versehener
-location-Block wird zur Umleitung von Anfragen benutzt und nicht für die
-normale Anfrageverarbeitung. Dieser Typ hat die folgenden Parameter:
-@table @asis
-@item @code{name}
-Der Name, mit dem dieser location-Block identifiziert wird.
-@item @code{body}
-Siehe @ref{nginx-location-configuration body}, weil der Rumpf (»Body«) eines
-mit Namen versehenen location-Blocks wie ein
-@code{nginx-location-configuration body} benutzt werden kann. Eine
-Einschränkung ist, dass der Rumpf eines mit Namen versehenen location-Blocks
-keine location-Blöcke enthalten kann.
-@end table
-@end deftp
-@subsubheading Varnish Cache
-@cindex Varnish
-Varnish is a fast cache server that sits in between web applications and end
-users.  It proxies requests from clients and caches the accessed URLs such
-that multiple requests for the same resource only creates one request to the
-back-end.
-@defvr {Scheme Variable} varnish-service-type
-Service type for the Varnish daemon.
-@end defvr
-@deftp {Data Type} varnish-configuration
-Data type representing the @code{varnish} service configuration.  This type
-has the following parameters:
-@table @asis
-@item @code{package} (Vorgabe: @code{varnish})
-Das Varnish-Paket, was benutzt werden soll.
-@item @code{name} (Vorgabe: @code{"default"})
-A name for this Varnish instance.  Varnish will create a directory in
-@file{/var/varnish/} with this name and keep temporary files there.  If the
-name starts with a forward slash, it is interpreted as an absolute directory
-name.
-Pass the @code{-n} argument to other Varnish programs to connect to the
-named instance, e.g.@: @command{varnishncsa -n default}.
-@item @code{backend} (Vorgabe: @code{"localhost:8080"})
-The backend to use.  This option has no effect if @code{vcl} is set.
-@item @code{vcl} (Vorgabe: #f)
-The @dfn{VCL} (Varnish Configuration Language) program to run.  If this is
-@code{#f}, Varnish will proxy @code{backend} using the default
-configuration.  Otherwise this must be a file-like object with valid VCL
-syntax.
-@c Varnish does not support HTTPS, so keep this URL to avoid confusion.
-For example, to mirror @url{http://www.gnu.org,www.gnu.org} with VCL you can
-do something along these lines:
-@example
-(define %gnu-mirror
-  (plain-file
-   "gnu.vcl"
-   "vcl 4.1;
-backend gnu @{ .host = "www.gnu.org"; @}"))
-(operating-system
-  ...
-  (services (cons (service varnish-service-type
-                           (varnish-configuration
-                            (listen '(":80"))
-                            (vcl %gnu-mirror)))
-                  %base-services)))
-@end example
-The configuration of an already running Varnish instance can be inspected
-and changed using the @command{varnishadm} program.
-Consult the @url{https://varnish-cache.org/docs/,Varnish User Guide} and
-@url{https://book.varnish-software.com/4.0/,Varnish Book} for comprehensive
-documentation on Varnish and its configuration language.
-@item @code{listen} (Vorgabe: @code{'("localhost:80")})
-List of addresses Varnish will listen on.
-@item @code{storage} (Vorgabe: @code{'("malloc,128m")})
-List of storage backends that will be available in VCL.
-@item @code{parameters} (Vorgabe: @code{'()})
-List of run-time parameters in the form @code{'(("parameter" . "value"))}.
-@item @code{extra-options} (Vorgabe: @code{'()})
-Additional arguments to pass to the @command{varnishd} process.
-@end table
-@end deftp
-@subsubheading FastCGI
-@cindex fastcgi
-@cindex fcgiwrap
-FastCGI is an interface between the front-end and the back-end of a web
-service.  It is a somewhat legacy facility; new web services should
-generally just talk HTTP between the front-end and the back-end.  However
-there are a number of back-end services such as PHP or the optimized HTTP
-Git repository access that use FastCGI, so we have support for it in Guix.
-To use FastCGI, you configure the front-end web server (e.g., nginx) to
-dispatch some subset of its requests to the fastcgi backend, which listens
-on a local TCP or UNIX socket.  There is an intermediary @code{fcgiwrap}
-program that sits between the actual backend process and the web server.
-The front-end indicates which backend program to run, passing that
-information to the @code{fcgiwrap} process.
-@defvr {Scheme Variable} fcgiwrap-service-type
-A service type for the @code{fcgiwrap} FastCGI proxy.
-@end defvr
-@deftp {Data Type} fcgiwrap-configuration
-Der Datentyp, der die Konfiguration des @code{fcgiwrap}-Dienstes
-repräsentiert. Dieser Typ hat die folgenden Parameter:
-@table @asis
-@item @code{package} (default: @code{fcgiwrap})
-The fcgiwrap package to use.
-@item @code{socket} (default: @code{tcp:127.0.0.1:9000})
-The socket on which the @code{fcgiwrap} process should listen, as a string.
-Valid @var{socket} values include @code{unix:@var{/path/to/unix/socket}},
-@code{tcp:@var{dot.ted.qu.ad}:@var{port}} and
-@code{tcp6:[@var{ipv6_addr}]:port}.
-@item @code{user} (default: @code{fcgiwrap})
-@itemx @code{group} (default: @code{fcgiwrap})
-The user and group names, as strings, under which to run the @code{fcgiwrap}
-process.  The @code{fastcgi} service will ensure that if the user asks for
-the specific user or group names @code{fcgiwrap} that the corresponding user
-and/or group is present on the system.
-It is possible to configure a FastCGI-backed web service to pass HTTP
-authentication information from the front-end to the back-end, and to allow
-@code{fcgiwrap} to run the back-end process as a corresponding local user.
-To enable this capability on the back-end., run @code{fcgiwrap} as the
-@code{root} user and group.  Note that this capability also has to be
-configured on the front-end as well.
-@end table
-@end deftp
-@cindex php-fpm
-PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI
-implementation with some additional features useful for sites of any size.
-These features include:
-@itemize @bullet
-@item Adaptive process spawning
-@item Basic statistics (similar to Apache's mod_status)
-@item Advanced process management with graceful stop/start
-@item Ability to start workers with different uid/gid/chroot/environment
-and different php.ini (replaces safe_mode)
-@item Stdout & stderr logging
-@item Emergency restart in case of accidental opcode cache destruction
-@item Accelerated upload support
-@item Support for a "slowlog"
-@item Enhancements to FastCGI, such as fastcgi_finish_request() -
-a special function to finish request & flush all data while continuing to do
-something time-consuming (video converting, stats processing, etc.)
-@end itemize
-...@: and much more.
-@defvr {Scheme Variable} php-fpm-service-type
-A Service type for @code{php-fpm}.
-@end defvr
-@deftp {Data Type} php-fpm-configuration
-Data Type for php-fpm service configuration.
-@table @asis
-@item @code{php} (default: @code{php})
-The php package to use.
-@item @code{socket} (default: @code{(string-append "/var/run/php" (version-major (package-version php)) "-fpm.sock")})
-The address on which to accept FastCGI requests.  Valid syntaxes are:
-@table @asis
-@item @code{"ip.add.re.ss:port"}
-Listen on a TCP socket to a specific address on a specific port.
-@item @code{"port"}
-Listen on a TCP socket to all addresses on a specific port.
-@item @code{"/path/to/unix/socket"}
-Listen on a unix socket.
-@end table
-@item @code{user} (default: @code{php-fpm})
-User who will own the php worker processes.
-@item @code{group} (default: @code{php-fpm})
-Group of the worker processes.
-@item @code{socket-user} (default: @code{php-fpm})
-User who can speak to the php-fpm socket.
-@item @code{socket-group} (default: @code{php-fpm})
-Group that can speak to the php-fpm socket.
-@item @code{pid-file} (default: @code{(string-append "/var/run/php" (version-major (package-version php)) "-fpm.pid")})
-The process id of the php-fpm process is written to this file once the
-service has started.
-@item @code{log-file} (default: @code{(string-append "/var/log/php" (version-major (package-version php)) "-fpm.log")})
-Log for the php-fpm master process.
-@item @code{process-manager} (default: @code{(php-fpm-dynamic-process-manager-configuration)})
-Detailed settings for the php-fpm process manager.  Must be either:
-@table @asis
-@item @code{<php-fpm-dynamic-process-manager-configuration>}
-@item @code{<php-fpm-static-process-manager-configuration>}
-@item @code{<php-fpm-on-demand-process-manager-configuration>}
-@end table
-@item @code{display-errors} (default @code{#f})
-Determines whether php errors and warning should be sent to clients and
-displayed in their browsers.  This is useful for local php development, but
-a security risk for public sites, as error messages can reveal passwords and
-personal data.
-@item @code{timezone} (Vorgabe: @code{#f})
-Specifies @code{php_admin_value[date.timezone]} parameter.
-@item @code{workers-logfile} (default @code{(string-append "/var/log/php" (version-major (package-version php)) "-fpm.www.log")})
-This file will log the @code{stderr} outputs of php worker processes.  Can
-be set to @code{#f} to disable logging.
-@item @code{file} (default @code{#f})
-An optional override of the whole configuration.  You can use the
-@code{mixed-text-file} function or an absolute filepath for it.
-@end table
-@end deftp
-@deftp {Data type} php-fpm-dynamic-process-manager-configuration
-Data Type for the @code{dynamic} php-fpm process manager.  With the
-@code{dynamic} process manager, spare worker processes are kept around based
-on it's configured limits.
-@table @asis
-@item @code{max-children} (default: @code{5})
-Maximum of worker processes.
-@item @code{start-servers} (default: @code{2})
-How many worker processes should be started on start-up.
-@item @code{min-spare-servers} (default: @code{1})
-How many spare worker processes should be kept around at minimum.
-@item @code{max-spare-servers} (default: @code{3})
-How many spare worker processes should be kept around at maximum.
-@end table
-@end deftp
-@deftp {Data type} php-fpm-static-process-manager-configuration
-Data Type for the @code{static} php-fpm process manager.  With the
-@code{static} process manager, an unchanging number of worker processes are
-created.
-@table @asis
-@item @code{max-children} (default: @code{5})
-Maximum of worker processes.
-@end table
-@end deftp
-@deftp {Data type} php-fpm-on-demand-process-manager-configuration
-Data Type for the @code{on-demand} php-fpm process manager.  With the
-@code{on-demand} process manager, worker processes are only created as
-requests arrive.
-@table @asis
-@item @code{max-children} (default: @code{5})
-Maximum of worker processes.
-@item @code{process-idle-timeout} (default: @code{10})
-The time in seconds after which a process with no requests is killed.
-@end table
-@end deftp
-@deffn {Scheme Procedure} nginx-php-fpm-location @
-       [#:nginx-package nginx] @ [socket (string-append "/var/run/php" @
-(version-major (package-version php)) @ "-fpm.sock")] A helper function to
-quickly add php to an @code{nginx-server-configuration}.
-@end deffn
-A simple services setup for nginx with php can look like this:
-@example
-(services (cons* (service dhcp-client-service-type)
-                 (service php-fpm-service-type)
-                 (service nginx-service-type
-                          (nginx-server-configuration
-                           (server-name '("example.com"))
-                           (root "/srv/http/")
-                           (locations
-                            (list (nginx-php-location)))
-                           (listen '("80"))
-                           (ssl-certificate #f)
-                           (ssl-certificate-key #f)))
-                 %base-services))
-@end example
-@cindex cat-avatar-generator
-The cat avatar generator is a simple service to demonstrate the use of
-php-fpm in @code{Nginx}.  It is used to generate cat avatar from a seed, for
-instance the hash of a user's email address.
-@deffn {Scheme-Prozedur} cat-avatar-generator-service @
-       [#:cache-dir "/var/cache/cat-avatar-generator"] @ [#:package
-cat-avatar-generator] @ [#:configuration (nginx-server-configuration)]
-Returns an nginx-server-configuration that inherits @code{configuration}.
-It extends the nginx configuration to add a server block that serves
-@code{package}, a version of cat-avatar-generator.  During execution,
-cat-avatar-generator will be able to use @code{cache-dir} as its cache
-directory.
-@end deffn
-A simple setup for cat-avatar-generator can look like this:
-@example
-(services (cons* (cat-avatar-generator-service
-                  #:configuration
-                  (nginx-server-configuration
-                    (server-name '("example.com"))))
-                 ...
-                 %base-services))
-@end example
-@subsubheading Hpcguix-web
-@cindex hpcguix-web
-The @uref{hpcguix-web, https://github.com/UMCUGenetics/hpcguix-web/} program
-is a customizable web interface to browse Guix packages, initially designed
-for users of high-performance computing (HPC)  clusters.
-@defvr {Scheme Variable} hpcguix-web-service-type
-The service type for @code{hpcguix-web}.
-@end defvr
-@deftp {Data Type} hpcguix-web-configuration
-Data type for the hpcguix-web service configuration.
-@table @asis
-@item @code{specs}
-A gexp (@pxref{G-Ausdrücke}) specifying the hpcguix-web service
-configuration.  The main items available in this spec are:
-@table @asis
-@item @code{title-prefix} (Vorgabe: @code{"hpcguix | "})
-Das Präfix der Webseitentitel.
-@item @code{guix-command} (Vorgabe: @code{"guix"})
-Der @command{guix}-Befehl.
-@item @code{package-filter-proc} (Vorgabe: @code{(const #t)})
-Eine Prozedur, die festlegt, wie anzuzeigende Pakete gefiltert werden.
-@item @code{package-page-extension-proc} (Vorgabe: @code{(const '())})
-Extension package for @code{hpcguix-web}.
-@item @code{menu} (Vorgabe: @code{'()})
-Additional entry in page @code{menu}.
-@item @code{channels} (Vorgabe: @code{%default-channels})
-List of channels from which the package list is built (@pxref{Kanäle}).
-@item @code{package-list-expiration} (Vorgabe: @code{(* 12 3600)})
-The expiration time, in seconds, after which the package list is rebuilt
-from the latest instances of the given channels.
-@end table
-See the hpcguix-web repository for a
-@uref{https://github.com/UMCUGenetics/hpcguix-web/blob/master/hpcweb-configuration.scm,
-complete example}.
-@item @code{package} (Vorgabe: @code{hpcguix-web})
-Das hpcguix-web-Paket, was benutzt werden soll.
-@end table
-@end deftp
-A typical hpcguix-web service declaration looks like this:
-@example
-(service hpcguix-web-service-type
-         (hpcguix-web-configuration
-          (specs
-           #~(define site-config
-               (hpcweb-configuration
-                (title-prefix "Guix-HPC - ")
-                (menu '(("/about" "ABOUT"))))))))
-@end example
-@quotation Anmerkung
-The hpcguix-web service periodically updates the package list it publishes
-by pulling channels from Git.  To that end, it needs to access X.509
-certificates so that it can authenticate Git servers when communicating over
-HTTPS, and it assumes that @file{/etc/ssl/certs} contains those
-certificates.
-Thus, make sure to add @code{nss-certs} or another certificate package to
-the @code{packages} field of your configuration.  @ref{X.509-Zertifikate},
-for more information on X.509 certificates.
-@end quotation
-@node Zertifikatsdienste
-@subsection Zertifikatsdienste
-@cindex Web
-@cindex HTTP, HTTPS
-@cindex Let's Encrypt
-@cindex TLS certificates
-The @code{(gnu services certbot)} module provides a service to automatically
-obtain a valid TLS certificate from the Let's Encrypt certificate
-authority.  These certificates can then be used to serve content securely
-over HTTPS or other TLS-based protocols, with the knowledge that the client
-will be able to verify the server's authenticity.
-@url{https://letsencrypt.org/, Let's Encrypt} provides the @code{certbot}
-tool to automate the certification process.  This tool first securely
-generates a key on the server.  It then makes a request to the Let's Encrypt
-certificate authority (CA) to sign the key.  The CA checks that the request
-originates from the host in question by using a challenge-response protocol,
-requiring the server to provide its response over HTTP.  If that protocol
-completes successfully, the CA signs the key, resulting in a certificate.
-That certificate is valid for a limited period of time, and therefore to
-continue to provide TLS services, the server needs to periodically ask the
-CA to renew its signature.
-The certbot service automates this process: the initial key generation, the
-initial certification request to the Let's Encrypt service, the web server
-challenge/response integration, writing the certificate to disk, the
-automated periodic renewals, and the deployment tasks associated with the
-renewal (e.g.@: reloading services, copying keys with different
-permissions).
-Certbot is run twice a day, at a random minute within the hour.  It won't do
-anything until your certificates are due for renewal or revoked, but running
-it regularly would give your service a chance of staying online in case a
-Let's Encrypt-initiated revocation happened for some reason.
-By using this service, you agree to the ACME Subscriber Agreement, which can
-be found there: @url{https://acme-v01.api.letsencrypt.org/directory}.
-@defvr {Scheme Variable} certbot-service-type
-A service type for the @code{certbot} Let's Encrypt client.  Its value must
-be a @code{certbot-configuration} record as in this example:
-@example
-(define %nginx-deploy-hook
-  (program-file
-   "nginx-deploy-hook"
-   #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read)))
-       (kill pid SIGHUP))))
-(service certbot-service-type
-         (certbot-configuration
-          (email "foo@@example.net")
-          (certificates
-           (list
-            (certificate-configuration
-             (domains '("example.net" "www.example.net"))
-             (deploy-hook %nginx-deploy-hook))
-            (certificate-configuration
-             (domains '("bar.example.net")))))))
-@end example
-See below for details about @code{certbot-configuration}.
-@end defvr
-@deftp {Data Type} certbot-configuration
-Data type representing the configuration of the @code{certbot} service.
-This type has the following parameters:
-@table @asis
-@item @code{package} (default: @code{certbot})
-The certbot package to use.
-@item @code{webroot} (default: @code{/var/www})
-The directory from which to serve the Let's Encrypt challenge/response
-files.
-@item @code{certificates} (default: @code{()})
-A list of @code{certificates-configuration}s for which to generate
-certificates and request signatures.  Each certificate has a @code{name} and
-several @code{domains}.
-@item @code{email}
-Mandatory email used for registration, recovery contact, and important
-account notifications.
-@item @code{rsa-key-size} (default: @code{2048})
-Size of the RSA key.
-@item @code{default-location} (default: @i{see below})
-The default @code{nginx-location-configuration}.  Because @code{certbot}
-needs to be able to serve challenges and responses, it needs to be able to
-run a web server.  It does so by extending the @code{nginx} web service with
-an @code{nginx-server-configuration} listening on the @var{domains} on port
-80, and which has a @code{nginx-location-configuration} for the
-@code{/.well-known/} URI path subspace used by Let's Encrypt.  @xref{Web-Dienste}, for more on these nginx configuration data types.
-Requests to other URL paths will be matched by the @code{default-location},
-which if present is added to all @code{nginx-server-configuration}s.
-By default, the @code{default-location} will issue a redirect from
-@code{http://@var{domain}/...} to @code{https://@var{domain}/...}, leaving
-you to define what to serve on your site via @code{https}.
-Pass @code{#f} to not issue a default location.
-@end table
-@end deftp
-@deftp {Data Type} certificate-configuration
-Data type representing the configuration of a certificate.  This type has
-the following parameters:
-@table @asis
-@item @code{name} (default: @i{see below})
-This name is used by Certbot for housekeeping and in file paths; it doesn't
-affect the content of the certificate itself.  To see certificate names, run
-@code{certbot certificates}.
-Its default is the first provided domain.
-@item @code{domains} (default: @code{()})
-The first domain provided will be the subject CN of the certificate, and all
-domains will be Subject Alternative Names on the certificate.
-@item @code{deploy-hook} (default: @code{#f})
-Command to be run in a shell once for each successfully issued certificate.
-For this command, the shell variable @code{$RENEWED_LINEAGE} will point to
-the config live subdirectory (for example,
-@samp{"/etc/letsencrypt/live/example.com"}) containing the new certificates
-and keys; the shell variable @code{$RENEWED_DOMAINS} will contain a
-space-delimited list of renewed certificate domains (for example,
-@samp{"example.com www.example.com"}.
-@end table
-@end deftp
-For each @code{certificate-configuration}, the certificate is saved to
-@code{/etc/letsencrypt/live/@var{name}/fullchain.pem} and the key is saved
-to @code{/etc/letsencrypt/live/@var{name}/privkey.pem}.
-@node DNS-Dienste
-@subsection DNS-Dienste
-@cindex DNS (domain name system)
-@cindex domain name system (DNS)
-The @code{(gnu services dns)} module provides services related to the
-@dfn{domain name system} (DNS).  It provides a server service for hosting an
-@emph{authoritative} DNS server for multiple zones, slave or master.  This
-service uses @uref{https://www.knot-dns.cz/, Knot DNS}.  And also a caching
-and forwarding DNS server for the LAN, which uses
-@uref{http://www.thekelleys.org.uk/dnsmasq/doc.html, dnsmasq}.
-@subsubheading Knot-Dienst
-An example configuration of an authoritative server for two zones, one
-master and one slave, is:
-@lisp
-(define-zone-entries example.org.zone
-;; Name TTL Class Type Data
-  ("@@"  ""  "IN"  "A"  "127.0.0.1")
-  ("@@"  ""  "IN"  "NS" "ns")
-  ("ns" ""  "IN"  "A"  "127.0.0.1"))
-(define master-zone
-  (knot-zone-configuration
-    (domain "example.org")
-    (zone (zone-file
-            (origin "example.org")
-            (entries example.org.zone)))))
-(define slave-zone
-  (knot-zone-configuration
-    (domain "plop.org")
-    (dnssec-policy "default")
-    (master (list "plop-master"))))
-(define plop-master
-  (knot-remote-configuration
-    (id "plop-master")
-    (address (list "208.76.58.171"))))
-(operating-system
-  ;; ...
-  (services (cons* (service knot-service-type
-                     (knot-configuration
-                       (remotes (list plop-master))
-                       (zones (list master-zone slave-zone))))
-                   ;; ...
-                   %base-services)))
-@end lisp
-@deffn {Scheme Variable} knot-service-type
-This is the type for the Knot DNS server.
-Knot DNS is an authoritative DNS server, meaning that it can serve multiple
-zones, that is to say domain names you would buy from a registrar.  This
-server is not a resolver, meaning that it can only resolve names for which
-it is authoritative.  This server can be configured to serve zones as a
-master server or a slave server as a per-zone basis.  Slave zones will get
-their data from masters, and will serve it as an authoritative server.  From
-the point of view of a resolver, there is no difference between master and
-slave.
-The following data types are used to configure the Knot DNS server:
-@end deffn
-@deftp {Data Type} knot-key-configuration
-Data type representing a key.  This type has the following parameters:
-@table @asis
-@item @code{id} (default: @code{""})
-An identifier for other configuration fields to refer to this key. IDs must
-be unique and must not be empty.
-@item @code{algorithm} (default: @code{#f})
-The algorithm to use.  Choose between @code{#f}, @code{'hmac-md5},
-@code{'hmac-sha1}, @code{'hmac-sha224}, @code{'hmac-sha256},
-@code{'hmac-sha384} and @code{'hmac-sha512}.
-@item @code{secret} (default: @code{""})
-The secret key itself.
-@end table
-@end deftp
-@deftp {Data Type} knot-acl-configuration
-Data type representing an Access Control List (ACL) configuration.  This
-type has the following parameters:
-@table @asis
-@item @code{id} (default: @code{""})
-An identifier for ether configuration fields to refer to this key. IDs must
-be unique and must not be empty.
-@item @code{address} (default: @code{'()})
-An ordered list of IP addresses, network subnets, or network ranges
-represented with strings.  The query must match one of them.  Empty value
-means that address match is not required.
-@item @code{key} (default: @code{'()})
-An ordered list of references to keys represented with strings.  The string
-must match a key ID defined in a @code{knot-key-configuration}.  No key
-means that a key is not require to match that ACL.
-@item @code{action} (default: @code{'()})
-An ordered list of actions that are permitted or forbidden by this ACL.
-Possible values are lists of zero or more elements from @code{'transfer},
-@code{'notify} and @code{'update}.
-@item @code{deny?} (default: @code{#f})
-When true, the ACL defines restrictions.  Listed actions are forbidden.
-When false, listed actions are allowed.
-@end table
-@end deftp
-@deftp {Data Type} zone-entry
-Data type represnting a record entry in a zone file.  This type has the
-following parameters:
-@table @asis
-@item @code{name} (default: @code{"@@"})
-The name of the record.  @code{"@@"} refers to the origin of the zone.
-Names are relative to the origin of the zone.  For example, in the
-@code{example.org} zone, @code{"ns.example.org"} actually refers to
-@code{ns.example.org.example.org}.  Names ending with a dot are absolute,
-which means that @code{"ns.example.org."} refers to @code{ns.example.org}.
-@item @code{ttl} (default: @code{""})
-The Time-To-Live (TTL) of this record.  If not set, the default TTL is used.
-@item @code{class} (default: @code{"IN"})
-The class of the record.  Knot currently supports only @code{"IN"} and
-partially @code{"CH"}.
-@item @code{type} (default: @code{"A"})
-The type of the record.  Common types include A (IPv4 address), AAAA (IPv6
-address), NS (Name Server) and MX (Mail eXchange).  Many other types are
-defined.
-@item @code{data} (default: @code{""})
-The data contained in the record.  For instance an IP address associated
-with an A record, or a domain name associated with an NS record.  Remember
-that domain names are relative to the origin unless they end with a dot.
-@end table
-@end deftp
-@deftp {Data Type} zone-file
-Data type representing the content of a zone file.  This type has the
-following parameters:
-@table @asis
-@item @code{entries} (default: @code{'()})
-The list of entries.  The SOA record is taken care of, so you don't need to
-put it in the list of entries.  This list should probably contain an entry
-for your primary authoritative DNS server.  Other than using a list of
-entries directly, you can use @code{define-zone-entries} to define a object
-containing the list of entries more easily, that you can later pass to the
-@code{entries} field of the @code{zone-file}.
-@item @code{origin} (default: @code{""})
-The name of your zone.  This parameter cannot be empty.
-@item @code{ns} (default: @code{"ns"})
-The domain of your primary authoritative DNS server.  The name is relative
-to the origin, unless it ends with a dot.  It is mandatory that this primary
-DNS server corresponds to an NS record in the zone and that it is associated
-to an IP address in the list of entries.
-@item @code{mail} (default: @code{"hostmaster"})
-An email address people can contact you at, as the owner of the zone.  This
-is translated as @code{<mail>@@<origin>}.
-@item @code{serial} (default: @code{1})
-The serial number of the zone.  As this is used to keep track of changes by
-both slaves and resolvers, it is mandatory that it @emph{never} decreases.
-Always increment it when you make a change in your zone.
-@item @code{refresh} (default: @code{(* 2 24 3600)})
-The frequency at which slaves will do a zone transfer.  This value is a
-number of seconds.  It can be computed by multiplications or with
-@code{(string->duration)}.
-@item @code{retry} (default: @code{(* 15 60)})
-The period after which a slave will retry to contact its master when it
-fails to do so a first time.
-@item @code{expiry} (default: @code{(* 14 24 3600)})
-Default TTL of records.  Existing records are considered correct for at most
-this amount of time.  After this period, resolvers will invalidate their
-cache and check again that it still exists.
-@item @code{nx} (default: @code{3600})
-Default TTL of inexistant records.  This delay is usually short because you
-want your new domains to reach everyone quickly.
-@end table
-@end deftp
-@deftp {Data Type} knot-remote-configuration
-Data type representing a remote configuration.  This type has the following
-parameters:
-@table @asis
-@item @code{id} (default: @code{""})
-An identifier for other configuration fields to refer to this remote. IDs
-must be unique and must not be empty.
-@item @code{address} (default: @code{'()})
-An ordered list of destination IP addresses.  Addresses are tried in
-sequence.  An optional port can be given with the @@ separator.  For
-instance: @code{(list "1.2.3.4" "2.3.4.5@@53")}.  Default port is 53.
-@item @code{via} (default: @code{'()})
-An ordered list of source IP addresses.  An empty list will have Knot choose
-an appropriate source IP.  An optional port can be given with the @@
-separator.  The default is to choose at random.
-@item @code{key} (default: @code{#f})
-A reference to a key, that is a string containing the identifier of a key
-defined in a @code{knot-key-configuration} field.
-@end table
-@end deftp
-@deftp {Data Type} knot-keystore-configuration
-Data type representing a keystore to hold dnssec keys.  This type has the
-following parameters:
-@table @asis
-@item @code{id} (default: @code{""})
-The id of the keystore.  It must not be empty.
-@item @code{backend} (default: @code{'pem})
-The backend to store the keys in.  Can be @code{'pem} or @code{'pkcs11}.
-@item @code{config} (default: @code{"/var/lib/knot/keys/keys"})
-The configuration string of the backend.  An example for the PKCS#11 is:
-@code{"pkcs11:token=knot;pin-value=1234
-/gnu/store/.../lib/pkcs11/libsofthsm2.so"}.  For the pem backend, the string
-reprensents a path in the file system.
-@end table
-@end deftp
-@deftp {Data Type} knot-policy-configuration
-Data type representing a dnssec policy.  Knot DNS is able to automatically
-sign your zones.  It can either generate and manage your keys automatically
-or use keys that you generate.
-Dnssec is usually implemented using two keys: a Key Signing Key (KSK) that
-is used to sign the second, and a Zone Signing Key (ZSK) that is used to
-sign the zone.  In order to be trusted, the KSK needs to be present in the
-parent zone (usually a top-level domain).  If your registrar supports
-dnssec, you will have to send them your KSK's hash so they can add a DS
-record in their zone.  This is not automated and need to be done each time
-you change your KSK.
-The policy also defines the lifetime of keys.  Usually, ZSK can be changed
-easily and use weaker cryptographic functions (they use lower parameters) in
-order to sign records quickly, so they are changed often.  The KSK however
-requires manual interaction with the registrar, so they are changed less
-often and use stronger parameters because they sign only one record.
-This type has the following parameters:
-@table @asis
-@item @code{id} (default: @code{""})
-The id of the policy.  It must not be empty.
-@item @code{keystore} (default: @code{"default"})
-A reference to a keystore, that is a string containing the identifier of a
-keystore defined in a @code{knot-keystore-configuration} field.  The
-@code{"default"} identifier means the default keystore (a kasp database that
-was setup by this service).
-@item @code{manual?} (default: @code{#f})
-Whether the key management is manual or automatic.
-@item @code{single-type-signing?} (default: @code{#f})
-When @code{#t}, use the Single-Type Signing Scheme.
-@item @code{algorithm} (default: @code{"ecdsap256sha256"})
-An algorithm of signing keys and issued signatures.
-@item @code{ksk-size} (default: @code{256})
-The length of the KSK.  Note that this value is correct for the default
-algorithm, but would be unsecure for other algorithms.
-@item @code{zsk-size} (default: @code{256})
-The length of the ZSK.  Note that this value is correct for the default
-algorithm, but would be unsecure for other algorithms.
-@item @code{dnskey-ttl} (default: @code{'default})
-The TTL value for DNSKEY records added into zone apex.  The special
-@code{'default} value means same as the zone SOA TTL.
-@item @code{zsk-lifetime} (default: @code{(* 30 24 3600)})
-The period between ZSK publication and the next rollover initiation.
-@item @code{propagation-delay} (default: @code{(* 24 3600)})
-An extra delay added for each key rollover step.  This value should be high
-enough to cover propagation of data from the master server to all slaves.
-@item @code{rrsig-lifetime} (default: @code{(* 14 24 3600)})
-A validity period of newly issued signatures.
-@item @code{rrsig-refresh} (default: @code{(* 7 24 3600)})
-A period how long before a signature expiration the signature will be
-refreshed.
-@item @code{nsec3?} (default: @code{#f})
-When @code{#t}, NSEC3 will be used instead of NSEC.
-@item @code{nsec3-iterations} (default: @code{5})
-The number of additional times the hashing is performed.
-@item @code{nsec3-salt-length} (default: @code{8})
-The length of a salt field in octets, which is appended to the original
-owner name before hashing.
-@item @code{nsec3-salt-lifetime} (default: @code{(* 30 24 3600)})
-The validity period of newly issued salt field.
-@end table
-@end deftp
-@deftp {Data Type} knot-zone-configuration
-Data type representing a zone served by Knot.  This type has the following
-parameters:
-@table @asis
-@item @code{domain} (default: @code{""})
-The domain served by this configuration.  It must not be empty.
-@item @code{file} (default: @code{""})
-The file where this zone is saved.  This parameter is ignored by master
-zones.  Empty means default location that depends on the domain name.
-@item @code{zone} (default: @code{(zone-file)})
-The content of the zone file.  This parameter is ignored by slave zones.  It
-must contain a zone-file record.
-@item @code{master} (default: @code{'()})
-A list of master remotes.  When empty, this zone is a master.  When set,
-this zone is a slave.  This is a list of remotes identifiers.
-@item @code{ddns-master} (default: @code{#f})
-The main master.  When empty, it defaults to the first master in the list of
-masters.
-@item @code{notify} (default: @code{'()})
-A list of slave remote identifiers.
-@item @code{acl} (default: @code{'()})
-A list of acl identifiers.
-@item @code{semantic-checks?} (default: @code{#f})
-When set, this adds more semantic checks to the zone.
-@item @code{disable-any?} (default: @code{#f})
-When set, this forbids queries of the ANY type.
-@item @code{zonefile-sync} (default: @code{0})
-The delay between a modification in memory and on disk.  0 means immediate
-synchronization.
-@item @code{serial-policy} (default: @code{'increment})
-A policy between @code{'increment} and @code{'unixtime}.
-@end table
-@end deftp
-@deftp {Data Type} knot-configuration
-Data type representing the Knot configuration.  This type has the following
-parameters:
-@table @asis
-@item @code{knot} (default: @code{knot})
-The Knot package.
-@item @code{run-directory} (default: @code{"/var/run/knot"})
-The run directory.  This directory will be used for pid file and sockets.
-@item @code{listen-v4} (default: @code{"0.0.0.0"})
-An ip address on which to listen.
-@item @code{listen-v6} (default: @code{"::"})
-An ip address on which to listen.
-@item @code{listen-port} (default: @code{53})
-A port on which to listen.
-@item @code{keys} (default: @code{'()})
-The list of knot-key-configuration used by this configuration.
-@item @code{acls} (default: @code{'()})
-The list of knot-acl-configuration used by this configuration.
-@item @code{remotes} (default: @code{'()})
-The list of knot-remote-configuration used by this configuration.
-@item @code{zones} (default: @code{'()})
-The list of knot-zone-configuration used by this configuration.
-@end table
-@end deftp
-@subsubheading Dnsmasq-Dienst
-@deffn {Scheme Variable} dnsmasq-service-type
-This is the type of the dnsmasq service, whose value should be an
-@code{dnsmasq-configuration} object as in this example:
-@example
-(service dnsmasq-service-type
-         (dnsmasq-configuration
-           (no-resolv? #t)
-           (servers '("192.168.1.1"))))
-@end example
-@end deffn
-@deftp {Datentyp} dnsmasq-configuration
-Repräsentiert die dnsmasq-Konfiguration.
-@table @asis
-@item @code{package} (Vorgabe: @var{dnsmasq})
-Package object of the dnsmasq server.
-@item @code{no-hosts?} (Vorgabe: @code{#f})
-When true, don't read the hostnames in /etc/hosts.
-@item @code{port} (Vorgabe: @code{53})
-The port to listen on.  Setting this to zero completely disables DNS
-responses, leaving only DHCP and/or TFTP functions.
-@item @code{local-service?} (Vorgabe: @code{#t})
-Accept DNS queries only from hosts whose address is on a local subnet, ie a
-subnet for which an interface exists on the server.
-@item @code{listen-addresses} (Vorgabe: @code{'()})
-Listen on the given IP addresses.
-@item @code{resolv-file} (Vorgabe: @code{"/etc/resolv.conf"})
-The file to read the IP address of the upstream nameservers from.
-@item @code{no-resolv?} (Vorgabe: @code{#f})
-When true, don't read @var{resolv-file}.
-@item @code{servers} (default: @code{'()})
-Specify IP address of upstream servers directly.
-@item @code{cache-size} (Vorgabe: @code{150})
-Set the size of dnsmasq's cache.  Setting the cache size to zero disables
-caching.
-@item @code{negative-cache?} (Vorgabe: @code{#t})
-When false, disable negative caching.
-@end table
-@end deftp
-@subsubheading ddclient-Dienst
-@cindex ddclient
-The ddclient service described below runs the ddclient daemon, which takes
-care of automatically updating DNS entries for service providers such as
-@uref{https://dyn.com/dns/, Dyn}.
-The following example show instantiates the service with its default
-configuration:
-@example
-(service ddclient-service-type)
-@end example
-Note that ddclient needs to access credentials that are stored in a
-@dfn{secret file}, by default @file{/etc/ddclient/secrets} (see
-@code{secret-file} below.)  You are expected to create this file manually,
-in an ``out-of-band'' fashion (you @emph{could} make this file part of the
-service configuration, for instance by using @code{plain-file}, but it will
-be world-readable @i{via} @file{/gnu/store}.)  See the examples in the
-@file{share/ddclient} directory of the @code{ddclient} package.
-@c %start of fragment
-Available @code{ddclient-configuration} fields are:
-@deftypevr {@code{ddclient-configuration} parameter} package ddclient
-Das ddclient-Paket.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} integer daemon
-The period after which ddclient will retry to check IP and domain name.
-Defaults to @samp{300}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} boolean syslog
-Use syslog for the output.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string mail
-Mail to user.
-Defaults to @samp{"root"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string mail-failure
-Den Nutzer per Mail bei fehlgeschlagenen Aktualisierungen benachrichtigen.
-Defaults to @samp{"root"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string pid
-PID-Datei für den ddclient.
-Defaults to @samp{"/var/run/ddclient/ddclient.pid"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} boolean ssl
-Enable SSL support.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string user
-Specifies the user name or ID that is used when running ddclient program.
-Defaults to @samp{"ddclient"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string group
-Group of the user who will run the ddclient program.
-Defaults to @samp{"ddclient"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} string secret-file
-Secret file which will be appended to @file{ddclient.conf} file.  This file
-contains credentials for use by ddclient.  You are expected to create it
-manually.
-Defaults to @samp{"/etc/ddclient/secrets.conf"}.
-@end deftypevr
-@deftypevr {@code{ddclient-configuration} parameter} list extra-options
-Extra options will be appended to @file{ddclient.conf} file.
-Defaults to @samp{()}.
-@end deftypevr
-@c %end of fragment
-@node VPN-Dienste
-@subsection VPN-Dienste
-@cindex VPN (virtual private network)
-@cindex virtual private network (VPN)
-The @code{(gnu services vpn)} module provides services related to
-@dfn{virtual private networks} (VPNs).  It provides a @emph{client} service
-for your machine to connect to a VPN, and a @emph{servire} service for your
-machine to host a VPN.  Both services use @uref{https://openvpn.net/,
-OpenVPN}.
-@deffn {Scheme Procedure} openvpn-client-service @
-       [#:config (openvpn-client-configuration)]
-Return a service that runs @command{openvpn}, a VPN daemon, as a client.
-@end deffn
-@deffn {Scheme Procedure} openvpn-server-service @
-       [#:config (openvpn-server-configuration)]
-Return a service that runs @command{openvpn}, a VPN daemon, as a server.
-Both can be run simultaneously.
-@end deffn
-@c %automatically generated documentation
-Available @code{openvpn-client-configuration} fields are:
-@deftypevr {@code{openvpn-client-configuration} parameter} package openvpn
-The OpenVPN package.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} string pid-file
-The OpenVPN pid file.
-Defaults to @samp{"/var/run/openvpn/openvpn.pid"}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} proto proto
-The protocol (UDP or TCP) used to open a channel between clients and
-servers.
-Defaults to @samp{udp}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} dev dev
-The device type used to represent the VPN connection.
-Defaults to @samp{tun}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} string ca
-The certificate authority to check connections against.
-Defaults to @samp{"/etc/openvpn/ca.crt"}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} string cert
-The certificate of the machine the daemon is running on.  It should be
-signed by the authority given in @code{ca}.
-Defaults to @samp{"/etc/openvpn/client.crt"}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} string key
-The key of the machine the daemon is running on.  It must be the key whose
-certificate is @code{cert}.
-Defaults to @samp{"/etc/openvpn/client.key"}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} boolean comp-lzo?
-Whether to use the lzo compression algorithm.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-key?
-Don't re-read key files across SIGUSR1 or --ping-restart.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-tun?
-Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1
-or --ping-restart restarts.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} number verbosity
-Verbosity level.
-Defaults to @samp{3}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} tls-auth-client tls-auth
-Add an additional layer of HMAC authentication on top of the TLS control
-channel to protect against DoS attacks.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} key-usage verify-key-usage?
-Whether to check the server certificate has server usage extension.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} bind bind?
-Bind to a specific local port number.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} resolv-retry resolv-retry?
-Retry resolving server address.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-client-configuration} parameter} openvpn-remote-list remote
-A list of remote servers to connect to.
-Defaults to @samp{()}.
-Available @code{openvpn-remote-configuration} fields are:
-@deftypevr {@code{openvpn-remote-configuration} parameter} string name
-Server name.
-Defaults to @samp{"my-server"}.
-@end deftypevr
-@deftypevr {@code{openvpn-remote-configuration} parameter} number port
-Port number the server listens to.
-Defaults to @samp{1194}.
-@end deftypevr
-@end deftypevr
-@c %end of automatic openvpn-client documentation
-@c %automatically generated documentation
-Available @code{openvpn-server-configuration} fields are:
-@deftypevr {@code{openvpn-server-configuration} parameter} package openvpn
-The OpenVPN package.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string pid-file
-The OpenVPN pid file.
-Defaults to @samp{"/var/run/openvpn/openvpn.pid"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} proto proto
-The protocol (UDP or TCP) used to open a channel between clients and
-servers.
-Defaults to @samp{udp}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} dev dev
-The device type used to represent the VPN connection.
-Defaults to @samp{tun}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string ca
-The certificate authority to check connections against.
-Defaults to @samp{"/etc/openvpn/ca.crt"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string cert
-The certificate of the machine the daemon is running on.  It should be
-signed by the authority given in @code{ca}.
-Defaults to @samp{"/etc/openvpn/client.crt"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string key
-The key of the machine the daemon is running on.  It must be the key whose
-certificate is @code{cert}.
-Defaults to @samp{"/etc/openvpn/client.key"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} boolean comp-lzo?
-Whether to use the lzo compression algorithm.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-key?
-Don't re-read key files across SIGUSR1 or --ping-restart.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-tun?
-Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1
-or --ping-restart restarts.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} number verbosity
-Verbosity level.
-Defaults to @samp{3}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} tls-auth-server tls-auth
-Add an additional layer of HMAC authentication on top of the TLS control
-channel to protect against DoS attacks.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} number port
-Specifies the port number on which the server listens.
-Defaults to @samp{1194}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} ip-mask server
-An ip and mask specifying the subnet inside the virtual network.
-Defaults to @samp{"10.8.0.0 255.255.255.0"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} cidr6 server-ipv6
-A CIDR notation specifying the IPv6 subnet inside the virtual network.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string dh
-The Diffie-Hellman parameters file.
-Defaults to @samp{"/etc/openvpn/dh2048.pem"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string ifconfig-pool-persist
-The file that records client IPs.
-Defaults to @samp{"/etc/openvpn/ipp.txt"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} gateway redirect-gateway?
-When true, the server will act as a gateway for its clients.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} boolean client-to-client?
-When true, clients are allowed to talk to each other inside the VPN.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} keepalive keepalive
-Causes ping-like messages to be sent back and forth over the link so that
-each side knows when the other side has gone down.  @code{keepalive}
-requires a pair.  The first element is the period of the ping sending, and
-the second element is the timeout before considering the other side down.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} number max-clients
-The maximum number of clients.
-Defaults to @samp{100}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} string status
-The status file.  This file shows a small report on current connection.  It
-is truncated and rewritten every minute.
-Defaults to @samp{"/var/run/openvpn/status"}.
-@end deftypevr
-@deftypevr {@code{openvpn-server-configuration} parameter} openvpn-ccd-list client-config-dir
-The list of configuration for some clients.
-Defaults to @samp{()}.
-Available @code{openvpn-ccd-configuration} fields are:
-@deftypevr {@code{openvpn-ccd-configuration} parameter} string name
-Client name.
-Defaults to @samp{"client"}.
-@end deftypevr
-@deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask iroute
-Client own network
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask ifconfig-push
-Client VPN IP.
-Defaults to @samp{#f}.
-@end deftypevr
-@end deftypevr
-@c %end of automatic openvpn-server documentation
-@node Network File System
-@subsection Network File System
-@cindex NFS
-The @code{(gnu services nfs)} module provides the following services, which
-are most commonly used in relation to mounting or exporting directory trees
-as @dfn{network file systems} (NFS).
-@subsubheading RPC Bind Service
-@cindex rpcbind
-The RPC Bind service provides a facility to map program numbers into
-universal addresses.  Many NFS related services use this facility.  Hence it
-is automatically started when a dependent service starts.
-@defvr {Scheme Variable} rpcbind-service-type
-A service type for the RPC portmapper daemon.
-@end defvr
-@deftp {Data Type} rpcbind-configuration
-Data type representing the configuration of the RPC Bind Service.  This type
-has the following parameters:
-@table @asis
-@item @code{rpcbind} (default: @code{rpcbind})
-The rpcbind package to use.
-@item @code{warm-start?} (default: @code{#t})
-If this parameter is @code{#t}, then the daemon will read a state file on
-startup thus reloading state information saved by a previous instance.
-@end table
-@end deftp
-@subsubheading Pipefs Pseudo File System
-@cindex pipefs
-@cindex rpc_pipefs
-The pipefs file system is used to transfer NFS related data between the
-kernel and user space programs.
-@defvr {Scheme Variable} pipefs-service-type
-A service type for the pipefs pseudo file system.
-@end defvr
-@deftp {Data Type} pipefs-configuration
-Data type representing the configuration of the pipefs pseudo file system
-service.  This type has the following parameters:
-@table @asis
-@item @code{mount-point} (default: @code{"/var/lib/nfs/rpc_pipefs"})
-The directory to which the file system is to be attached.
-@end table
-@end deftp
-@subsubheading GSS Daemon Service
-@cindex GSSD
-@cindex GSS
-@cindex global security system
-The @dfn{global security system} (GSS) daemon provides strong security for
-RPC based protocols.  Before exchanging RPC requests an RPC client must
-establish a security context.  Typically this is done using the Kerberos
-command @command{kinit} or automatically at login time using PAM services
-(@pxref{Kerberos-Dienste}).
-@defvr {Scheme Variable} gss-service-type
-A service type for the Global Security System (GSS) daemon.
-@end defvr
-@deftp {Data Type} gss-configuration
-Data type representing the configuration of the GSS daemon service.  This
-type has the following parameters:
-@table @asis
-@item @code{nfs-utils} (default: @code{nfs-utils})
-The package in which the @command{rpc.gssd} command is to be found.
-@item @code{pipefs-directory} (default: @code{"/var/lib/nfs/rpc_pipefs"})
-The directory where the pipefs file system is mounted.
-@end table
-@end deftp
-@subsubheading IDMAP Daemon Service
-@cindex idmapd
-@cindex name mapper
-The idmap daemon service provides mapping between user IDs and user names.
-Typically it is required in order to access file systems mounted via NFSv4.
-@defvr {Scheme Variable} idmap-service-type
-A service type for the Identity Mapper (IDMAP) daemon.
-@end defvr
-@deftp {Data Type} idmap-configuration
-Data type representing the configuration of the IDMAP daemon service.  This
-type has the following parameters:
-@table @asis
-@item @code{nfs-utils} (default: @code{nfs-utils})
-The package in which the @command{rpc.idmapd} command is to be found.
-@item @code{pipefs-directory} (default: @code{"/var/lib/nfs/rpc_pipefs"})
-The directory where the pipefs file system is mounted.
-@item @code{domain} (default: @code{#f})
-The local NFSv4 domain name.  This must be a string or @code{#f}.  If it is
-@code{#f} then the daemon will use the host's fully qualified domain name.
-@end table
-@end deftp
-@node Kontinuierliche Integration
-@subsection Kontinuierliche Integration
-@cindex continuous integration
-@uref{https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git, Cuirass} is a
-continuous integration tool for Guix.  It can be used both for development
-and for providing substitutes to others (@pxref{Substitute}).
-The @code{(gnu services cuirass)} module provides the following service.
-@defvr {Scheme Procedure} cuirass-service-type
-The type of the Cuirass service.  Its value must be a
-@code{cuirass-configuration} object, as described below.
-@end defvr
-To add build jobs, you have to set the @code{specifications} field of the
-configuration.  Here is an example of a service that polls the Guix
-repository and builds the packages from a manifest.  Some of the packages
-are defined in the @code{"custom-packages"} input, which is the equivalent
-of @code{GUIX_PACKAGE_PATH}.
-@example
-(define %cuirass-specs
-  #~(list
-     '((#:name . "my-manifest")
-       (#:load-path-inputs . ("guix"))
-       (#:package-path-inputs . ("custom-packages"))
-       (#:proc-input . "guix")
-       (#:proc-file . "build-aux/cuirass/gnu-system.scm")
-       (#:proc . cuirass-jobs)
-       (#:proc-args . ((subset . "manifests")
-                       (systems . ("x86_64-linux"))
-                       (manifests . (("config" . "guix/manifest.scm")))))
-       (#:inputs . (((#:name . "guix")
-                     (#:url . "git://git.savannah.gnu.org/guix.git")
-                     (#:load-path . ".")
-                     (#:branch . "master")
-                     (#:no-compile? . #t))
-                    ((#:name . "config")
-                     (#:url . "git://git.example.org/config.git")
-                     (#:load-path . ".")
-                     (#:branch . "master")
-                     (#:no-compile? . #t))
-                    ((#:name . "custom-packages")
-                     (#:url . "git://git.example.org/custom-packages.git")
-                     (#:load-path . ".")
-                     (#:branch . "master")
-                     (#:no-compile? . #t)))))))
-(service cuirass-service-type
-         (cuirass-configuration
-          (specifications %cuirass-specs)))
-@end example
-While information related to build jobs is located directly in the
-specifications, global settings for the @command{cuirass} process are
-accessible in other @code{cuirass-configuration} fields.
-@deftp {Data Type} cuirass-configuration
-Data type representing the configuration of Cuirass.
-@table @asis
-@item @code{log-file} (default: @code{"/var/log/cuirass.log"})
-Location of the log file.
-@item @code{cache-directory} (default: @code{"/var/cache/cuirass"})
-Location of the repository cache.
-@item @code{user} (default: @code{"cuirass"})
-Owner of the @code{cuirass} process.
-@item @code{group} (default: @code{"cuirass"})
-Owner's group of the @code{cuirass} process.
-@item @code{interval} (default: @code{60})
-Number of seconds between the poll of the repositories followed by the
-Cuirass jobs.
-@item @code{database} (Vorgabe: @code{"/var/lib/cuirass/cuirass.db"})
-Location of sqlite database which contains the build results and previously
-added specifications.
-@item @code{ttl} (Vorgabe: @code{(* 30 24 3600)})
-Specifies the time-to-live (TTL) in seconds of garbage collector roots that
-are registered for build results.  This means that build results are
-protected from garbage collection for at least @var{ttl} seconds.
-@item @code{port} (default: @code{8081})
-Port number used by the HTTP server.
-@item --listen=@var{Host}
-Listen on the network interface for @var{host}.  The default is to accept
-connections from localhost.
-@item @code{specifications} (default: @code{#~'()})
-A gexp (@pxref{G-Ausdrücke}) that evaluates to a list of specifications,
-where a specification is an association list (@pxref{Associations Lists,,,
-guile, GNU Guile Reference Manual}) whose keys are keywords
-(@code{#:keyword-example}) as shown in the example above.
-@item @code{use-substitutes?} (default: @code{#f})
-This allows using substitutes to avoid building every dependencies of a job
-from source.
-@item @code{one-shot?} (default: @code{#f})
-Only evaluate specifications and build derivations once.
-@item @code{fallback?} (default: @code{#f})
-When substituting a pre-built binary fails, fall back to building packages
-locally.
-@item @code{cuirass} (default: @code{cuirass})
-The Cuirass package to use.
-@end table
-@end deftp
-@node Dienste zur Stromverbrauchsverwaltung
-@subsection Dienste zur Stromverbrauchsverwaltung
-@cindex tlp
-@cindex power management with TLP
-@subsubheading TLP-Daemon
-The @code{(gnu services pm)} module provides a Guix service definition for
-the Linux power management tool TLP.
-TLP enables various powersaving modes in userspace and kernel.  Contrary to
-@code{upower-service}, it is not a passive, monitoring tool, as it will
-apply custom settings each time a new power source is detected.  More
-information can be found at @uref{http://linrunner.de/en/tlp/tlp.html, TLP
-home page}.
-@deffn {Scheme Variable} tlp-service-type
-The service type for the TLP tool.  Its value should be a valid TLP
-configuration (see below).  To use the default settings, simply write:
-@example
-(service tlp-service-type)
-@end example
-@end deffn
-By default TLP does not need much configuration but most TLP parameters can
-be tweaked using @code{tlp-configuration}.
-Each parameter definition is preceded by its type; for example,
-@samp{boolean foo} indicates that the @code{foo} parameter should be
-specified as a boolean.  Types starting with @code{maybe-} denote parameters
-that won't show up in TLP config file when their value is @code{'disabled}.
-@c The following documentation was initially generated by
-@c (generate-tlp-documentation) in (gnu services pm).  Manually maintained
-@c documentation is better, so we shouldn't hesitate to edit below as
-@c needed.  However if the change you want to make to this documentation
-@c can be done in an automated way, it's probably easier to change
-@c (generate-documentation) than to make it below and have to deal with
-@c the churn as TLP updates.
-Available @code{tlp-configuration} fields are:
-@deftypevr {@code{tlp-configuration} parameter} package tlp
-The TLP package.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean tlp-enable?
-Set to true if you wish to enable TLP.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string tlp-default-mode
-Default mode when no power supply can be detected.  Alternatives are AC and
-BAT.
-Defaults to @samp{"AC"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer disk-idle-secs-on-ac
-Number of seconds Linux kernel has to wait after the disk goes idle, before
-syncing on AC.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer disk-idle-secs-on-bat
-Same as @code{disk-idle-ac} but on BAT mode.
-Defaults to @samp{2}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer max-lost-work-secs-on-ac
-Dirty pages flushing periodicity, expressed in seconds.
-Defaults to @samp{15}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer max-lost-work-secs-on-bat
-Same as @code{max-lost-work-secs-on-ac} but on BAT mode.
-Defaults to @samp{60}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list cpu-scaling-governor-on-ac
-CPU frequency scaling governor on AC mode.  With intel_pstate driver,
-alternatives are powersave and performance.  With acpi-cpufreq driver,
-alternatives are ondemand, powersave, performance and conservative.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list cpu-scaling-governor-on-bat
-Same as @code{cpu-scaling-governor-on-ac} but on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-min-freq-on-ac
-Set the min available frequency for the scaling governor on AC.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-max-freq-on-ac
-Set the max available frequency for the scaling governor on AC.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-min-freq-on-bat
-Set the min available frequency for the scaling governor on BAT.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-max-freq-on-bat
-Set the max available frequency for the scaling governor on BAT.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-min-perf-on-ac
-Limit the min P-state to control the power dissipation of the CPU, in AC
-mode.  Values are stated as a percentage of the available performance.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-max-perf-on-ac
-Limit the max P-state to control the power dissipation of the CPU, in AC
-mode.  Values are stated as a percentage of the available performance.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-min-perf-on-bat
-Same as @code{cpu-min-perf-on-ac} on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-max-perf-on-bat
-Same as @code{cpu-max-perf-on-ac} on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-boolean cpu-boost-on-ac?
-Enable CPU turbo boost feature on AC mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-boolean cpu-boost-on-bat?
-Same as @code{cpu-boost-on-ac?} on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean sched-powersave-on-ac?
-Allow Linux kernel to minimize the number of CPU cores/hyper-threads used
-under light load conditions.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean sched-powersave-on-bat?
-Same as @code{sched-powersave-on-ac?} but on BAT mode.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean nmi-watchdog?
-Enable Linux kernel NMI watchdog.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-string phc-controls
-For Linux kernels with PHC patch applied, change CPU voltages.  An example
-value would be @samp{"F:V F:V F:V F:V"}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string energy-perf-policy-on-ac
-Set CPU performance versus energy saving policy on AC.  Alternatives are
-performance, normal, powersave.
-Defaults to @samp{"performance"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string energy-perf-policy-on-bat
-Same as @code{energy-perf-policy-ac} but on BAT mode.
-Defaults to @samp{"powersave"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disks-devices
-Hard disk devices.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disk-apm-level-on-ac
-Hard disk advanced power management level.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disk-apm-level-on-bat
-Same as @code{disk-apm-bat} but on BAT mode.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-spindown-timeout-on-ac
-Hard disk spin down timeout.  One value has to be specified for each
-declared hard disk.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-spindown-timeout-on-bat
-Same as @code{disk-spindown-timeout-on-ac} but on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-iosched
-Select IO scheduler for disk devices.  One value has to be specified for
-each declared hard disk.  Example alternatives are cfq, deadline and noop.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string sata-linkpwr-on-ac
-SATA aggressive link power management (ALPM) level.  Alternatives are
-min_power, medium_power, max_performance.
-Defaults to @samp{"max_performance"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string sata-linkpwr-on-bat
-Same as @code{sata-linkpwr-ac} but on BAT mode.
-Defaults to @samp{"min_power"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-string sata-linkpwr-blacklist
-Exclude specified SATA host devices for link power management.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-on-off-boolean ahci-runtime-pm-on-ac?
-Enable Runtime Power Management for AHCI controller and disks on AC mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-on-off-boolean ahci-runtime-pm-on-bat?
-Same as @code{ahci-runtime-pm-on-ac} on BAT mode.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer ahci-runtime-pm-timeout
-Seconds of inactivity before disk is suspended.
-Defaults to @samp{15}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string pcie-aspm-on-ac
-PCI Express Active State Power Management level.  Alternatives are default,
-performance, powersave.
-Defaults to @samp{"performance"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string pcie-aspm-on-bat
-Same as @code{pcie-aspm-ac} but on BAT mode.
-Defaults to @samp{"powersave"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-power-profile-on-ac
-Radeon graphics clock speed level.  Alternatives are low, mid, high, auto,
-default.
-Defaults to @samp{"high"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-power-profile-on-bat
-Same as @code{radeon-power-ac} but on BAT mode.
-Defaults to @samp{"low"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-state-on-ac
-Radeon dynamic power management method (DPM).  Alternatives are battery,
-performance.
-Defaults to @samp{"performance"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-state-on-bat
-Same as @code{radeon-dpm-state-ac} but on BAT mode.
-Defaults to @samp{"battery"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-perf-level-on-ac
-Radeon DPM performance level.  Alternatives are auto, low, high.
-Defaults to @samp{"auto"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-perf-level-on-bat
-Same as @code{radeon-dpm-perf-ac} but on BAT mode.
-Defaults to @samp{"auto"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} on-off-boolean wifi-pwr-on-ac?
-Wifi power saving mode.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} on-off-boolean wifi-pwr-on-bat?
-Same as @code{wifi-power-ac?} but on BAT mode.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} y-n-boolean wol-disable?
-Disable wake on LAN.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer sound-power-save-on-ac
-Timeout duration in seconds before activating audio power saving on Intel
-HDA and AC97 devices.  A value of 0 disables power saving.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} non-negative-integer sound-power-save-on-bat
-Same as @code{sound-powersave-ac} but on BAT mode.
-Defaults to @samp{1}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} y-n-boolean sound-power-save-controller?
-Disable controller in powersaving mode on Intel HDA devices.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean bay-poweroff-on-bat?
-Enable optical drive in UltraBay/MediaBay on BAT mode.  Drive can be powered
-on again by releasing (and reinserting) the eject lever or by pressing the
-disc eject button on newer models.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string bay-device
-Name of the optical drive device to power off.
-Defaults to @samp{"sr0"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string runtime-pm-on-ac
-Runtime Power Management for PCI(e) bus devices.  Alternatives are on and
-auto.
-Defaults to @samp{"on"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} string runtime-pm-on-bat
-Same as @code{runtime-pm-ac} but on BAT mode.
-Defaults to @samp{"auto"}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean runtime-pm-all?
-Runtime Power Management for all PCI(e) bus devices, except blacklisted
-ones.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list runtime-pm-blacklist
-Exclude specified PCI(e) device addresses from Runtime Power Management.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} space-separated-string-list runtime-pm-driver-blacklist
-Exclude PCI(e) devices assigned to the specified drivers from Runtime Power
-Management.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean usb-autosuspend?
-Enable USB autosuspend feature.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-string usb-blacklist
-Exclude specified devices from USB autosuspend.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean usb-blacklist-wwan?
-Exclude WWAN devices from USB autosuspend.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-string usb-whitelist
-Include specified devices into USB autosuspend, even if they are already
-excluded by the driver or via @code{usb-blacklist-wwan?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} maybe-boolean usb-autosuspend-disable-on-shutdown?
-Enable USB autosuspend before shutdown.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{tlp-configuration} parameter} boolean restore-device-state-on-startup?
-Restore radio device state (bluetooth, wifi, wwan) from previous shutdown on
-system startup.
-Defaults to @samp{#f}.
-@end deftypevr
-@cindex thermald
-@cindex CPU frequency scaling with thermald
-@subsubheading Thermald-Daemon
-The @code{(gnu services pm)} module provides an interface to thermald, a CPU
-frequency scaling service which helps prevent overheating.
-@defvr {Scheme Variable} thermald-service-type
-This is the service type for @uref{https://01.org/linux-thermal-daemon/,
-thermald}, the Linux Thermal Daemon, which is responsible for controlling
-the thermal state of processors and preventing overheating.
-@end defvr
-@deftp {Data Type} thermald-configuration
-Data type representing the configuration of @code{thermald-service-type}.
-@table @asis
-@item @code{ignore-cpuid-check?} (default: @code{#f})
-Ignore cpuid check for supported CPU models.
-@item @code{thermald} (default: @var{thermald})
-Package object of thermald.
-@end table
-@end deftp
-@node Audio-Dienste
-@subsection Audio-Dienste
-The @code{(gnu services audio)} module provides a service to start MPD (the
-Music Player Daemon).
-@cindex mpd
-@subsubheading Music Player Daemon
-The Music Player Daemon (MPD) is a service that can play music while being
-controlled from the local machine or over the network by a variety of
-clients.
-The following example shows how one might run @code{mpd} as user
-@code{"bob"} on port @code{6666}.  It uses pulseaudio for output.
-@example
-(service mpd-service-type
-         (mpd-configuration
-          (user "bob")
-          (port "6666")))
-@end example
-@defvr {Scheme Variable} mpd-service-type
-The service type for @command{mpd}
-@end defvr
-@deftp {Data Type} mpd-configuration
-Data type representing the configuration of @command{mpd}.
-@table @asis
-@item @code{user} (default: @code{"mpd"})
-The user to run mpd as.
-@item @code{music-dir} (default: @code{"~/Music"})
-The directory to scan for music files.
-@item @code{playlist-dir} (default: @code{"~/.mpd/playlists"})
-The directory to store playlists.
-@item @code{db-file} (Vorgabe: @code{"~/.mpd/tag_cache"})
-Der Ort, an dem die Musikdatenbank gespeichert wird.
-@item @code{state-file} (Vorgabe: @code{"~/.mpd/state"})
-The location of the file that stores current MPD's state.
-@item @code{sticker-file} (Vorgabe: @code{"~/.mpd/sticker.sql"})
-Der Ort, an dem die Sticker-Datenbank gespeichert wird.
-@item @code{port} (default: @code{"6600"})
-The port to run mpd on.
-@item @code{address} (default: @code{"any"})
-The address that mpd will bind to.  To use a Unix domain socket, an absolute
-path can be specified here.
-@end table
-@end deftp
-@node Virtualisierungsdienste
-@subsection Virtualization services
-The @code{(gnu services virtualization)} module provides services for the
-libvirt and virtlog daemons, as well as other virtualization-related
-services.
-@subsubheading Libvirt daemon
-@code{libvirtd} is the server side daemon component of the libvirt
-virtualization management system. This daemon runs on host servers and
-performs required management tasks for virtualized guests.
-@deffn {Scheme Variable} libvirt-service-type
-This is the type of the @uref{https://libvirt.org, libvirt daemon}.  Its
-value must be a @code{libvirt-configuration}.
-@example
-(service libvirt-service-type
-         (libvirt-configuration
-          (unix-sock-group "libvirt")
-          (tls-port "16555")))
-@end example
-@end deffn
-@c Auto-generated with (generate-libvirt-documentation)
-Available @code{libvirt-configuration} fields are:
-@deftypevr {@code{libvirt-configuration} parameter} package libvirt
-Libvirt package.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean listen-tls?
-Flag listening for secure TLS connections on the public TCP/IP port.  must
-set @code{listen} for this to have any effect.
-It is necessary to setup a CA and issue server certificates before using
-this capability.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean listen-tcp?
-Listen for unencrypted TCP connections on the public TCP/IP port.  must set
-@code{listen} for this to have any effect.
-Using the TCP socket requires SASL authentication by default.  Only SASL
-mechanisms which support data encryption are allowed.  This is DIGEST_MD5
-and GSSAPI (Kerberos5)
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string tls-port
-Port for accepting secure TLS connections This can be a port number, or
-service name
-Defaults to @samp{"16514"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string tcp-port
-Port for accepting insecure TCP connections This can be a port number, or
-service name
-Defaults to @samp{"16509"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string listen-addr
-IP address or hostname used for client connections.
-Defaults to @samp{"0.0.0.0"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean mdns-adv?
-Flag toggling mDNS advertisement of the libvirt service.
-Alternatively can disable for all services on a host by stopping the Avahi
-daemon.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string mdns-name
-Default mDNS advertisement name.  This must be unique on the immediate
-broadcast network.
-Defaults to @samp{"Virtualization Host <hostname>"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string unix-sock-group
-UNIX domain socket group ownership.  This can be used to allow a 'trusted'
-set of users access to management capabilities without becoming root.
-Defaults to @samp{"root"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string unix-sock-ro-perms
-UNIX socket permissions for the R/O socket.  This is used for monitoring VM
-status only.
-Defaults to @samp{"0777"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string unix-sock-rw-perms
-UNIX socket permissions for the R/W socket.  Default allows only root.  If
-PolicyKit is enabled on the socket, the default will change to allow
-everyone (eg, 0777)
-Defaults to @samp{"0770"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string unix-sock-admin-perms
-UNIX socket permissions for the admin socket.  Default allows only owner
-(root), do not change it unless you are sure to whom you are exposing the
-access to.
-Defaults to @samp{"0777"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string unix-sock-dir
-The directory in which sockets will be found/created.
-Defaults to @samp{"/var/run/libvirt"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string auth-unix-ro
-Authentication scheme for UNIX read-only sockets.  By default socket
-permissions allow anyone to connect
-Defaults to @samp{"polkit"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string auth-unix-rw
-Authentication scheme for UNIX read-write sockets.  By default socket
-permissions only allow root.  If PolicyKit support was compiled into
-libvirt, the default will be to use 'polkit' auth.
-Defaults to @samp{"polkit"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string auth-tcp
-Authentication scheme for TCP sockets.  If you don't enable SASL, then all
-TCP traffic is cleartext.  Don't do this outside of a dev/test scenario.
-Defaults to @samp{"sasl"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string auth-tls
-Authentication scheme for TLS sockets.  TLS sockets already have encryption
-provided by the TLS layer, and limited authentication is done by
-certificates.
-It is possible to make use of any SASL authentication mechanism as well, by
-using 'sasl' for this option
-Defaults to @samp{"none"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} optional-list access-drivers
-API access control scheme.
-By default an authenticated user is allowed access to all APIs.  Access
-drivers can place restrictions on this.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string key-file
-Server key file path.  If set to an empty string, then no private key is
-loaded.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string cert-file
-Server key file path.  If set to an empty string, then no certificate is
-loaded.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string ca-file
-Server key file path.  If set to an empty string, then no CA certificate is
-loaded.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string crl-file
-Certificate revocation list path.  If set to an empty string, then no CRL is
-loaded.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean tls-no-sanity-cert
-Disable verification of our own server certificates.
-When libvirtd starts it performs some sanity checks against its own
-certificates.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean tls-no-verify-cert
-Disable verification of client certificates.
-Client certificate verification is the primary authentication mechanism.
-Any client which does not present a certificate signed by the CA will be
-rejected.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} optional-list tls-allowed-dn-list
-Whitelist of allowed x509 Distinguished Name.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} optional-list sasl-allowed-usernames
-Whitelist of allowed SASL usernames.  The format for username depends on the
-SASL authentication mechanism.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string tls-priority
-Override the compile time default TLS priority string.  The default is
-usually "NORMAL" unless overridden at build time.  Only set this is it is
-desired for libvirt to deviate from the global default settings.
-Defaults to @samp{"NORMAL"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-clients
-Maximum number of concurrent client connections to allow over all sockets
-combined.
-Defaults to @samp{5000}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-queued-clients
-Maximum length of queue of connections waiting to be accepted by the
-daemon.  Note, that some protocols supporting retransmission may obey this
-so that a later reattempt at connection succeeds.
-Defaults to @samp{1000}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-anonymous-clients
-Maximum length of queue of accepted but not yet authenticated clients.  Set
-this to zero to turn this feature off
-Defaults to @samp{20}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer min-workers
-Number of workers to start up initially.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-workers
-Maximum number of worker threads.
-If the number of active clients exceeds @code{min-workers}, then more
-threads are spawned, up to max_workers limit.  Typically you'd want
-max_workers to equal maximum number of clients allowed.
-Defaults to @samp{20}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer prio-workers
-Number of priority workers.  If all workers from above pool are stuck, some
-calls marked as high priority (notably domainDestroy) can be executed in
-this pool.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-requests
-Total global limit on concurrent RPC calls.
-Defaults to @samp{20}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer max-client-requests
-Limit on concurrent requests from a single client connection.  To avoid one
-client monopolizing the server this should be a small fraction of the global
-max_requests and max_workers parameter.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-min-workers
-Same as @code{min-workers} but for the admin interface.
-Defaults to @samp{1}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-max-workers
-Same as @code{max-workers} but for the admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-max-clients
-Same as @code{max-clients} but for the admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-max-queued-clients
-Same as @code{max-queued-clients} but for the admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-max-client-requests
-Same as @code{max-client-requests} but for the admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer log-level
-Logging level.  4 errors, 3 warnings, 2 information, 1 debug.
-Defaults to @samp{3}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string log-filters
-Logging filters.
-A filter allows to select a different logging level for a given category of
-logs The format for a filter is one of:
-@itemize @bullet
-@item
-x:name
-@item
-x:+name
-@end itemize
-where @code{name} is a string which is matched against the category given in
-the @code{VIR_LOG_INIT()} at the top of each libvirt source file, e.g.,
-"remote", "qemu", or "util.json" (the name in the filter can be a substring
-of the full category name, in order to match multiple similar categories),
-the optional "+" prefix tells libvirt to log stack trace for each message
-matching name, and @code{x} is the minimal level where matching messages
-should be logged:
-@itemize @bullet
-@item
-1: DEBUG
-@item
-2: INFO
-@item
-3: WARNING
-@item
-4: ERROR
-@end itemize
-Multiple filters can be defined in a single filters statement, they just
-need to be separated by spaces.
-Defaults to @samp{"3:remote 4:event"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string log-outputs
-Logging outputs.
-An output is one of the places to save logging information The format for an
-output can be:
-@table @code
-@item x:stderr
-output goes to stderr
-@item x:syslog:name
-use syslog for the output and use the given name as the ident
-@item x:file:file_path
-output to a file, with the given filepath
-@item x:journald
-output to journald logging system
-@end table
-In all case the x prefix is the minimal level, acting as a filter
-@itemize @bullet
-@item
-1: DEBUG
-@item
-2: INFO
-@item
-3: WARNING
-@item
-4: ERROR
-@end itemize
-Multiple outputs can be defined, they just need to be separated by spaces.
-Defaults to @samp{"3:stderr"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer audit-level
-Allows usage of the auditing subsystem to be altered
-@itemize @bullet
-@item
-0: disable all auditing
-@item
-1: enable auditing, only if enabled on host
-@item
-2: enable auditing, and exit if disabled on host.
-@end itemize
-Defaults to @samp{1}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} boolean audit-logging
-Send audit messages via libvirt logging infrastructure.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} optional-string host-uuid
-Host UUID.  UUID must not have all digits be the same.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} string host-uuid-source
-Source to read host UUID.
-@itemize @bullet
-@item
-@code{smbios}: fetch the UUID from @code{dmidecode -s system-uuid}
-@item
-@code{machine-id}: fetch the UUID from @code{/etc/machine-id}
-@end itemize
-If @code{dmidecode} does not provide a valid UUID a temporary UUID will be
-generated.
-Defaults to @samp{"smbios"}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer keepalive-interval
-A keepalive message is sent to a client after @code{keepalive_interval}
-seconds of inactivity to check if the client is still responding.  If set to
-1, libvirtd will never send keepalive requests; however clients can still
-send them and the daemon will send responses.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer keepalive-count
-Maximum number of keepalive messages that are allowed to be sent to the
-client without getting any response before the connection is considered
-broken.
-In other words, the connection is automatically closed approximately after
-@code{keepalive_interval * (keepalive_count + 1)} seconds since the last
-message received from the client.  When @code{keepalive-count} is set to 0,
-connections will be automatically closed after @code{keepalive-interval}
-seconds of inactivity without sending any keepalive messages.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-keepalive-interval
-Same as above but for admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer admin-keepalive-count
-Same as above but for admin interface.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{libvirt-configuration} parameter} integer ovs-timeout
-Timeout for Open vSwitch calls.
-The @code{ovs-vsctl} utility is used for the configuration and its timeout
-option is set by default to 5 seconds to avoid potential infinite waits
-blocking libvirt.
-Defaults to @samp{5}.
-@end deftypevr
-@c %end of autogenerated docs
-@subsubheading Virtlog daemon
-The virtlogd service is a server side daemon component of libvirt that is
-used to manage logs from virtual machine consoles.
-This daemon is not used directly by libvirt client applications, rather it
-is called on their behalf by @code{libvirtd}. By maintaining the logs in a
-standalone daemon, the main @code{libvirtd} daemon can be restarted without
-risk of losing logs. The @code{virtlogd} daemon has the ability to re-exec()
-itself upon receiving @code{SIGUSR1}, to allow live upgrades without
-downtime.
-@deffn {Scheme Variable} virtlog-service-type
-This is the type of the virtlog daemon.  Its value must be a
-@code{virtlog-configuration}.
-@example
-(service virtlog-service-type
-         (virtlog-configuration
-          (max-clients 1000)))
-@end example
-@end deffn
-@deftypevr {@code{virtlog-configuration} parameter} integer log-level
-Logging level.  4 errors, 3 warnings, 2 information, 1 debug.
-Defaults to @samp{3}.
-@end deftypevr
-@deftypevr {@code{virtlog-configuration} parameter} string log-filters
-Logging filters.
-A filter allows to select a different logging level for a given category of
-logs The format for a filter is one of:
-@itemize @bullet
-@item
-x:name
-@item
-x:+name
-@end itemize
-where @code{name} is a string which is matched against the category given in
-the @code{VIR_LOG_INIT()} at the top of each libvirt source file, e.g.,
-"remote", "qemu", or "util.json" (the name in the filter can be a substring
-of the full category name, in order to match multiple similar categories),
-the optional "+" prefix tells libvirt to log stack trace for each message
-matching name, and @code{x} is the minimal level where matching messages
-should be logged:
-@itemize @bullet
-@item
-1: DEBUG
-@item
-2: INFO
-@item
-3: WARNING
-@item
-4: ERROR
-@end itemize
-Multiple filters can be defined in a single filters statement, they just
-need to be separated by spaces.
-Defaults to @samp{"3:remote 4:event"}.
-@end deftypevr
-@deftypevr {@code{virtlog-configuration} parameter} string log-outputs
-Logging outputs.
-An output is one of the places to save logging information The format for an
-output can be:
-@table @code
-@item x:stderr
-output goes to stderr
-@item x:syslog:name
-use syslog for the output and use the given name as the ident
-@item x:file:file_path
-output to a file, with the given filepath
-@item x:journald
-output to journald logging system
-@end table
-In all case the x prefix is the minimal level, acting as a filter
-@itemize @bullet
-@item
-1: DEBUG
-@item
-2: INFO
-@item
-3: WARNING
-@item
-4: ERROR
-@end itemize
-Multiple outputs can be defined, they just need to be separated by spaces.
-Defaults to @samp{"3:stderr"}.
-@end deftypevr
-@deftypevr {@code{virtlog-configuration} parameter} integer max-clients
-Maximum number of concurrent client connections to allow over all sockets
-combined.
-Defaults to @samp{1024}.
-@end deftypevr
-@deftypevr {@code{virtlog-configuration} parameter} integer max-size
-Maximum file size before rolling over.
-Defaults to @samp{2MB}
-@end deftypevr
-@deftypevr {@code{virtlog-configuration} parameter} integer max-backups
-Maximum number of backup files to keep.
-Defaults to @samp{3}
-@end deftypevr
-@subsubheading Transparent Emulation with QEMU
-@cindex emulation
-@cindex @code{binfmt_misc}
-@code{qemu-binfmt-service-type} provides support for transparent emulation
-of program binaries built for different architectures---e.g., it allows you
-to transparently execute an ARMv7 program on an x86_64 machine.  It achieves
-this by combining the @uref{https://www.qemu.org, QEMU} emulator and the
-@code{binfmt_misc} feature of the kernel Linux.
-@defvr {Scheme Variable} qemu-binfmt-service-type
-This is the type of the QEMU/binfmt service for transparent emulation.  Its
-value must be a @code{qemu-binfmt-configuration} object, which specifies the
-QEMU package to use as well as the architecture we want to emulated:
-@example
-(service qemu-binfmt-service-type
-         (qemu-binfmt-configuration
-           (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))))
-@end example
-In this example, we enable transparent emulation for the ARM and aarch64
-platforms.  Running @code{herd stop qemu-binfmt} turns it off, and running
-@code{herd start qemu-binfmt} turns it back on (@pxref{Invoking herd, the
-@command{herd} command,, shepherd, The GNU Shepherd Manual}).
-@end defvr
-@deftp {Data Type} qemu-binfmt-configuration
-This is the configuration for the @code{qemu-binfmt} service.
-@table @asis
-@item @code{platforms} (default: @code{'()})
-The list of emulated QEMU platforms.  Each item must be a @dfn{platform
-object} as returned by @code{lookup-qemu-platforms} (see below).
-@item @code{guix-support?} (default: @code{#f})
-When it is true, QEMU and all its dependencies are added to the build
-environment of @command{guix-daemon} (@pxref{Aufruf des guix-daemon,
-@code{--chroot-directory} option}).  This allows the @code{binfmt_misc}
-handlers to be used within the build environment, which in turn means that
-you can transparently build programs for another architecture.
-For example, let's suppose you're on an x86_64 machine and you have this
-service:
-@example
-(service qemu-binfmt-service-type
-         (qemu-binfmt-configuration
-           (platforms (lookup-qemu-platforms "arm"))
-           (guix-support? #t)))
-@end example
-You can run:
-@example
-guix build -s armhf-linux inkscape
-@end example
-@noindent
-and it will build Inkscape for ARMv7 @emph{as if it were a native build},
-transparently using QEMU to emulate the ARMv7 CPU.  Pretty handy if you'd
-like to test a package build for an architecture you don't have access to!
-@item @code{qemu} (default: @code{qemu})
-The QEMU package to use.
-@end table
-@end deftp
-@deffn {Scheme Procedure} lookup-qemu-platforms @var{platforms}@dots{}
-Return the list of QEMU platform objects corresponding to
-@var{platforms}@dots{}.  @var{platforms} must be a list of strings
-corresponding to platform names, such as @code{"arm"}, @code{"sparc"},
-@code{"mips64el"}, and so on.
-@end deffn
-@deffn {Scheme Procedure} qemu-platform? @var{obj}
-Return true if @var{obj} is a platform object.
-@end deffn
-@deffn {Scheme Procedure} qemu-platform-name @var{platform}
-Return the name of @var{platform}---a string such as @code{"arm"}.
-@end deffn
-@node Versionskontrolldienste
-@subsection Versionskontrolldienste
-The @code{(gnu services version-control)} module provides a service to allow
-remote access to local Git repositories.  There are three options: the
-@code{git-daemon-service}, which provides access to repositories via the
-@code{git://} unsecured TCP-based protocol, extending the @code{nginx} web
-server to proxy some requests to @code{git-http-backend}, or providing a web
-interface with @code{cgit-service-type}.
-@deffn {Scheme Procedure} git-daemon-service [#:config (git-daemon-configuration)]
-Return a service that runs @command{git daemon}, a simple TCP server to
-expose repositories over the Git protocol for anonymous access.
-The optional @var{config} argument should be a
-@code{<git-daemon-configuration>} object, by default it allows read-only
-access to exported@footnote{By creating the magic file
-"git-daemon-export-ok" in the repository directory.} repositories under
-@file{/srv/git}.
-@end deffn
-@deftp {Data Type} git-daemon-configuration
-Data type representing the configuration for @code{git-daemon-service}.
-@table @asis
-@item @code{package} (default: @var{git})
-Package object of the Git distributed version control system.
-@item @code{export-all?} (default: @var{#f})
-Whether to allow access for all Git repositories, even if they do not have
-the @file{git-daemon-export-ok} file.
-@item @code{base-path} (default: @file{/srv/git})
-Whether to remap all the path requests as relative to the given path.  If
-you run git daemon with @var{(base-path "/srv/git")} on example.com, then if
-you later try to pull @code{git://example.com/hello.git}, git daemon will
-interpret the path as @code{/srv/git/hello.git}.
-@item @code{user-path} (default: @var{#f})
-Whether to allow @code{~user} notation to be used in requests.  When
-specified with empty string, requests to @code{git://host/~alice/foo} is
-taken as a request to access @code{foo} repository in the home directory of
-user @code{alice}.  If @var{(user-path "path")} is specified, the same
-request is taken as a request to access @code{path/foo} repository in the
-home directory of user @code{alice}.
-@item @code{listen} (default: @var{'()})
-Whether to listen on specific IP addresses or hostnames, defaults to all.
-@item @code{port} (default: @var{#f})
-Whether to listen on an alternative port, which defaults to 9418.
-@item @code{whitelist} (default: @var{'()})
-If not empty, only allow access to this list of directories.
-@item @code{extra-options} (default: @var{'()})
-Extra options will be passed to @code{git daemon}, please run @command{man
-git-daemon} for more information.
-@end table
-@end deftp
-The @code{git://} protocol lacks authentication.  When you pull from a
-repository fetched via @code{git://}, you don't know that the data you
-receive was modified is really coming from the specified host, and you have
-your connection is subject to eavesdropping.  It's better to use an
-authenticated and encrypted transport, such as @code{https}.  Although Git
-allows you to serve repositories using unsophisticated file-based web
-servers, there is a faster protocol implemented by the
-@code{git-http-backend} program.  This program is the back-end of a proper
-Git web service.  It is designed to sit behind a FastCGI proxy.  @xref{Web-Dienste}, for more on running the necessary @code{fcgiwrap} daemon.
-Guix has a separate configuration data type for serving Git repositories
-over HTTP.
-@deftp {Data Type} git-http-configuration
-Data type representing the configuration for @code{git-http-service}.
-@table @asis
-@item @code{package} (default: @var{git})
-Package object of the Git distributed version control system.
-@item @code{git-root} (default: @file{/srv/git})
-Directory containing the Git repositories to expose to the world.
-@item @code{export-all?} (default: @var{#f})
-Whether to expose access for all Git repositories in @var{git-root}, even if
-they do not have the @file{git-daemon-export-ok} file.
-@item @code{uri-path} (default: @file{/git/})
-Path prefix for Git access.  With the default @code{/git/} prefix, this will
-map @code{http://@var{server}/git/@var{repo}.git} to
-@code{/srv/git/@var{repo}.git}.  Requests whose URI paths do not begin with
-this prefix are not passed on to this Git instance.
-@item @code{fcgiwrap-socket} (default: @code{127.0.0.1:9000})
-The socket on which the @code{fcgiwrap} daemon is listening.  @xref{Web-Dienste}.
-@end table
-@end deftp
-There is no @code{git-http-service-type}, currently; instead you can create
-an @code{nginx-location-configuration} from a @code{git-http-configuration}
-and then add that location to a web server.
-@deffn {Scheme Procedure} git-http-nginx-location-configuration @
-       [config=(git-http-configuration)] Compute an
-@code{nginx-location-configuration} that corresponds to the given Git http
-configuration.  An example nginx service definition to serve the default
-@file{/srv/git} over HTTPS might be:
-@example
-(service nginx-service-type
-         (nginx-configuration
-          (server-blocks
-           (list
-            (nginx-server-configuration
-             (listen '("443 ssl"))
-             (server-name "git.my-host.org")
-             (ssl-certificate
-              "/etc/letsencrypt/live/git.my-host.org/fullchain.pem")
-             (ssl-certificate-key
-              "/etc/letsencrypt/live/git.my-host.org/privkey.pem")
-             (locations
-              (list
-               (git-http-nginx-location-configuration
-                (git-http-configuration (uri-path "/"))))))))))
-@end example
-This example assumes that you are using Let's Encrypt to get your TLS
-certificate.  @xref{Zertifikatsdienste}.  The default @code{certbot}
-service will redirect all HTTP traffic on @code{git.my-host.org} to HTTPS.
-You will also need to add an @code{fcgiwrap} proxy to your system services.
-@xref{Web-Dienste}.
-@end deffn
-@subsubheading Cgit Service
-@cindex Cgit service
-@cindex Git, web interface
-@uref{https://git.zx2c4.com/cgit/, Cgit} is a web frontend for Git
-repositories written in C.
-The following example will configure the service with default values.  By
-default, Cgit can be accessed on port 80 (@code{http://localhost:80}).
-@example
-(service cgit-service-type)
-@end example
-The @code{file-object} type designates either a file-like object
-(@pxref{G-Ausdrücke, file-like objects}) or a string.
-@c %start of fragment
-Available @code{cgit-configuration} fields are:
-@deftypevr {@code{cgit-configuration} parameter} package package
-The CGIT package.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} nginx-server-configuration-list nginx
-NGINX configuration.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object about-filter
-Specifies a command which will be invoked to format the content of about
-pages (both top-level and for each repository).
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string agefile
-Specifies a path, relative to each repository path, which can be used to
-specify the date and time of the youngest commit in the repository.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object auth-filter
-Specifies a command that will be invoked for authenticating repository
-access.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string branch-sort
-Flag which, when set to @samp{age}, enables date ordering in the branch ref
-list, and when set @samp{name} enables ordering by branch name.
-Defaults to @samp{"name"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string cache-root
-Path used to store the cgit cache entries.
-Defaults to @samp{"/var/cache/cgit"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-static-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of repository pages accessed with a fixed SHA1.
-Defaults to @samp{-1}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-dynamic-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of repository pages accessed without a fixed SHA1.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-repo-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of the repository summary page.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-root-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of the repository index page.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-scanrc-ttl
-Number which specifies the time-to-live, in minutes, for the result of
-scanning a path for Git repositories.
-Defaults to @samp{15}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-about-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of the repository about page.
-Defaults to @samp{15}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-snapshot-ttl
-Number which specifies the time-to-live, in minutes, for the cached version
-of snapshots.
-Defaults to @samp{5}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer cache-size
-The maximum number of entries in the cgit cache.  When set to @samp{0},
-caching is disabled.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean case-sensitive-sort?
-Sort items in the repo list case sensitively.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} list clone-prefix
-List of common prefixes which, when combined with a repository URL,
-generates valid clone URLs for the repository.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} list clone-url
-List of @code{clone-url} templates.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object commit-filter
-Command which will be invoked to format commit messages.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string commit-sort
-Flag which, when set to @samp{date}, enables strict date ordering in the
-commit log, and when set to @samp{topo} enables strict topological ordering.
-Defaults to @samp{"git log"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object css
-URL which specifies the css document to include in all cgit pages.
-Defaults to @samp{"/share/cgit/cgit.css"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object email-filter
-Specifies a command which will be invoked to format names and email address
-of committers, authors, and taggers, as represented in various places
-throughout the cgit interface.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean embedded?
-Flag which, when set to @samp{#t}, will make cgit generate a HTML fragment
-suitable for embedding in other HTML pages.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-commit-graph?
-Flag which, when set to @samp{#t}, will make cgit print an ASCII-art commit
-history graph to the left of the commit messages in the repository log page.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-filter-overrides?
-Flag which, when set to @samp{#t}, allows all filter settings to be
-overridden in repository-specific cgitrc files.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-follow-links?
-Flag which, when set to @samp{#t}, allows users to follow a file in the log
-view.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-http-clone?
-If set to @samp{#t}, cgit will act as an dumb HTTP endpoint for Git clones.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-index-links?
-Flag which, when set to @samp{#t}, will make cgit generate extra links
-"summary", "commit", "tree" for each repo in the repository index.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-index-owner?
-Flag which, when set to @samp{#t}, will make cgit display the owner of each
-repo in the repository index.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-log-filecount?
-Flag which, when set to @samp{#t}, will make cgit print the number of
-modified files for each commit on the repository log page.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-log-linecount?
-Flag which, when set to @samp{#t}, will make cgit print the number of added
-and removed lines for each commit on the repository log page.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-remote-branches?
-Flag which, when set to @code{#t}, will make cgit display remote branches in
-the summary and refs views.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-subject-links?
-Flag which, when set to @code{1}, will make cgit use the subject of the
-parent commit as link text when generating links to parent commits in commit
-view.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-html-serving?
-Flag which, when set to @samp{#t}, will make cgit use the subject of the
-parent commit as link text when generating links to parent commits in commit
-view.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-tree-linenumbers?
-Flag which, when set to @samp{#t}, will make cgit generate linenumber links
-for plaintext blobs printed in the tree view.
-Defaults to @samp{#t}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean enable-git-config?
-Flag which, when set to @samp{#f}, will allow cgit to use Git config to set
-any repo specific settings.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object favicon
-URL used as link to a shortcut icon for cgit.
-Defaults to @samp{"/favicon.ico"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string footer
-The content of the file specified with this option will be included verbatim
-at the bottom of all pages (i.e.@: it replaces the standard "generated
-by..."@: message).
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string head-include
-The content of the file specified with this option will be included verbatim
-in the HTML HEAD section on all pages.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string header
-The content of the file specified with this option will be included verbatim
-at the top of all pages.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object include
-Name of a configfile to include before the rest of the current config- file
-is parsed.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string index-header
-The content of the file specified with this option will be included verbatim
-above the repository index.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string index-info
-The content of the file specified with this option will be included verbatim
-below the heading on the repository index page.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean local-time?
-Flag which, if set to @samp{#t}, makes cgit print commit and tag times in
-the servers timezone.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object logo
-URL which specifies the source of an image which will be used as a logo on
-all cgit pages.
-Defaults to @samp{"/share/cgit/cgit.png"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string logo-link
-URL loaded when clicking on the cgit logo image.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object owner-filter
-Command which will be invoked to format the Owner column of the main page.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-atom-items
-Number of items to display in atom feeds view.
-Defaults to @samp{10}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-commit-count
-Number of entries to list per page in "log" view.
-Defaults to @samp{50}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-message-length
-Number of commit message characters to display in "log" view.
-Defaults to @samp{80}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-repo-count
-Specifies the number of entries to list per page on the repository index
-page.
-Defaults to @samp{50}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-repodesc-length
-Specifies the maximum number of repo description characters to display on
-the repository index page.
-Defaults to @samp{80}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer max-blob-size
-Specifies the maximum size of a blob to display HTML for in KBytes.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string max-stats
-Maximum statistics period.  Valid values are @samp{week},@samp{month},
-@samp{quarter} and @samp{year}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} mimetype-alist mimetype
-Mimetype for the specified filename extension.
-Defaults to @samp{((gif "image/gif") (html "text/html") (jpg "image/jpeg")
-(jpeg "image/jpeg") (pdf "application/pdf") (png "image/png") (svg
-"image/svg+xml"))}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object mimetype-file
-Specifies the file to use for automatic mimetype lookup.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string module-link
-Text which will be used as the formatstring for a hyperlink when a submodule
-is printed in a directory listing.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean nocache?
-If set to the value @samp{#t} caching will be disabled.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean noplainemail?
-If set to @samp{#t} showing full author email addresses will be disabled.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean noheader?
-Flag which, when set to @samp{#t}, will make cgit omit the standard header
-on all pages.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} project-list project-list
-A list of subdirectories inside of @code{repository-directory}, relative to
-it, that should loaded as Git repositories.  An empty list means that all
-subdirectories will be loaded.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object readme
-Text which will be used as default value for @code{cgit-repo-readme}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean remove-suffix?
-If set to @code{#t} and @code{repository-directory} is enabled, if any
-repositories are found with a suffix of @code{.git}, this suffix will be
-removed for the URL and name.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer renamelimit
-Maximum number of files to consider when detecting renames.
-Defaults to @samp{-1}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string repository-sort
-The way in which repositories in each section are sorted.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} robots-list robots
-Text used as content for the @code{robots} meta-tag.
-Defaults to @samp{("noindex" "nofollow")}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string root-desc
-Text printed below the heading on the repository index page.
-Defaults to @samp{"a fast webinterface for the git dscm"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string root-readme
-The content of the file specified with this option will be included verbatim
-below thef "about" link on the repository index page.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string root-title
-Text printed as heading on the repository index page.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean scan-hidden-path
-If set to @samp{#t} and repository-directory is enabled,
-repository-directory will recurse into directories whose name starts with a
-period.  Otherwise, repository-directory will stay away from such
-directories, considered as "hidden".  Note that this does not apply to the
-".git" directory in non-bare repos.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} list snapshots
-Text which specifies the default set of snapshot formats that cgit generates
-links for.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} repository-directory repository-directory
-Name of the directory to scan for repositories (represents
-@code{scan-path}).
-Defaults to @samp{"/srv/git"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string section
-The name of the current repository section - all repositories defined after
-this option will inherit the current section name.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string section-sort
-Flag which, when set to @samp{1}, will sort the sections on the repository
-listing by name.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer section-from-path
-A number which, if defined prior to repository-directory, specifies how many
-path elements from each repo path to use as a default section name.
-Defaults to @samp{0}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} boolean side-by-side-diffs?
-If set to @samp{#t} shows side-by-side diffs instead of unidiffs per
-default.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} file-object source-filter
-Specifies a command which will be invoked to format plaintext blobs in the
-tree view.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer summary-branches
-Specifies the number of branches to display in the repository "summary"
-view.
-Defaults to @samp{10}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer summary-log
-Specifies the number of log entries to display in the repository "summary"
-view.
-Defaults to @samp{10}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} integer summary-tags
-Specifies the number of tags to display in the repository "summary" view.
-Defaults to @samp{10}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string strict-export
-Filename which, if specified, needs to be present within the repository for
-cgit to allow access to that repository.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} string virtual-root
-URL which, if specified, will be used as root for all cgit links.
-Defaults to @samp{"/"}.
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} repository-cgit-configuration-list repositories
-A list of @dfn{cgit-repo} records to use with config.
-Defaults to @samp{()}.
-Available @code{repository-cgit-configuration} fields are:
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-list snapshots
-A mask of snapshot formats for this repo that cgit generates links for,
-restricted by the global @code{snapshots} setting.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object source-filter
-Override the default @code{source-filter}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string url
-The relative URL used to access the repository.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object about-filter
-Override the default @code{about-filter}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string branch-sort
-Flag which, when set to @samp{age}, enables date ordering in the branch ref
-list, and when set to @samp{name} enables ordering by branch name.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-list clone-url
-A list of URLs which can be used to clone repo.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object commit-filter
-Override the default @code{commit-filter}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string commit-sort
-Flag which, when set to @samp{date}, enables strict date ordering in the
-commit log, and when set to @samp{topo} enables strict topological ordering.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string defbranch
-The name of the default branch for this repository.  If no such branch
-exists in the repository, the first branch name (when sorted) is used as
-default instead.  By default branch pointed to by HEAD, or "master" if there
-is no suitable HEAD.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string desc
-The value to show as repository description.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string homepage
-The value to show as repository homepage.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object email-filter
-Override the default @code{email-filter}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-commit-graph?
-A flag which can be used to disable the global setting
-@code{enable-commit-graph?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-log-filecount?
-A flag which can be used to disable the global setting
-@code{enable-log-filecount?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-log-linecount?
-A flag which can be used to disable the global setting
-@code{enable-log-linecount?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-remote-branches?
-Flag which, when set to @code{#t}, will make cgit display remote branches in
-the summary and refs views.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-subject-links?
-A flag which can be used to override the global setting
-@code{enable-subject-links?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-html-serving?
-A flag which can be used to override the global setting
-@code{enable-html-serving?}.
-Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert).
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-boolean hide?
-Flag which, when set to @code{#t}, hides the repository from the repository
-index.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-boolean ignore?
-Flag which, when set to @samp{#t}, ignores the repository.
-Defaults to @samp{#f}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object logo
-URL which specifies the source of an image which will be used as a logo on
-this repo’s pages.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string logo-link
-URL loaded when clicking on the cgit logo image.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object owner-filter
-Override the default @code{owner-filter}.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string module-link
-Text which will be used as the formatstring for a hyperlink when a submodule
-is printed in a directory listing.  The arguments for the formatstring are
-the path and SHA1 of the submodule commit.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} module-link-path module-link-path
-Text which will be used as the formatstring for a hyperlink when a submodule
-with the specified subdirectory path is printed in a directory listing.
-Defaults to @samp{()}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string max-stats
-Override the default maximum statistics period.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string name
-The value to show as repository name.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string owner
-A value used to identify the owner of the repository.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string path
-An absolute path to the repository directory.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string readme
-A path (relative to repo) which specifies a file to include verbatim as the
-"About" page for this repo.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-string section
-The name of the current repository section - all repositories defined after
-this option will inherit the current section name.
-Defaults to @samp{""}.
-@end deftypevr
-@deftypevr {@code{repository-cgit-configuration} parameter} repo-list extra-options
-Extra options will be appended to cgitrc file.
-Defaults to @samp{()}.
-@end deftypevr
-@end deftypevr
-@deftypevr {@code{cgit-configuration} parameter} list extra-options
-Extra options will be appended to cgitrc file.
-Defaults to @samp{()}.
-@end deftypevr
-@c %end of fragment
-However, it could be that you just want to get a @code{cgitrc} up and
-running.  In that case, you can pass an @code{opaque-cgit-configuration} as
-a record to @code{cgit-service-type}.  As its name indicates, an opaque
-configuration does not have easy reflective capabilities.
-Available @code{opaque-cgit-configuration} fields are:
-@deftypevr {@code{opaque-cgit-configuration} parameter} package cgit
-The cgit package.
-@end deftypevr
-@deftypevr {@code{opaque-cgit-configuration} parameter} string string
-The contents of the @code{cgitrc}, as a string.
-@end deftypevr
-For example, if your @code{cgitrc} is just the empty string, you could
-instantiate a cgit service like this:
-@example
-(service cgit-service-type
-         (opaque-cgit-configuration
-          (cgitrc "")))
-@end example
-@subsubheading Gitolite-Dienst
-@cindex Gitolite-Dienst
-@cindex Git, hosting
-@uref{http://gitolite.com/gitolite/, Gitolite} is a tool for hosting Git
-repositories on a central server.
-Gitolite can handle multiple repositories and users, and supports flexible
-configuration of the permissions for the users on the repositories.
-The following example will configure Gitolite using the default @code{git}
-user, and the provided SSH public key.
-@example
-(service gitolite-service-type
-         (gitolite-configuration
-           (admin-pubkey (plain-file
-                           "yourname.pub"
-                           "ssh-rsa AAAA... guix@@example.com"))))
-@end example
-Gitolite is configured through a special admin repository which you can
-clone, for example, if you setup Gitolite on @code{example.com}, you would
-run the following command to clone the admin repository.
-@example
-git clone git@@example.com:gitolite-admin
-@end example
-When the Gitolite service is activated, the provided @code{admin-pubkey}
-will be inserted in to the @file{keydir} directory in the gitolite-admin
-repository.  If this results in a change in the repository, it will be
-committed using the message ``gitolite setup by GNU Guix''.
-@deftp {Datentyp} gitolite-configuration
-Repräsentiert die Konfiguration vom @code{gitolite-service-type}.
-@table @asis
-@item @code{package} (Vorgabe: @var{gitolite})
-Welches Gitolite-Paket benutzt werden soll.
-@item @code{user} (Vorgabe: @var{git})
-User to use for Gitolite.  This will be user that you use when accessing
-Gitolite over SSH.
-@item @code{group} (Vorgabe: @var{git})
-Group to use for Gitolite.
-@item @code{home-directory} (Vorgabe: @var{"/var/lib/gitolite"})
-Directory in which to store the Gitolite configuration and repositories.
-@item @code{rc-file} (Vorgabe: @var{(gitolite-rc-file)})
-A ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}),
-representing the configuration for Gitolite.
-@item @code{admin-pubkey} (Vorgabe: @var{#f})
-A ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}) used to
-setup Gitolite.  This will be inserted in to the @file{keydir} directory
-within the gitolite-admin repository.
-To specify the SSH key as a string, use the @code{plain-file} function.
-@example
-(plain-file "yourname.pub" "ssh-rsa AAAA... guix@@example.com")
-@end example
-@end table
-@end deftp
-@deftp {Datentyp} gitolite-rc-file
-Repräsentiert die Gitolie-RC-Datei.
-@table @asis
-@item @code{umask} (Vorgabe: @code{#o0077})
-This controls the permissions Gitolite sets on the repositories and their
-contents.
-A value like @code{#o0027} will give read access to the group used by
-Gitolite (by default: @code{git}). This is necessary when using Gitolite
-with software like cgit or gitweb.
-@item @code{git-config-keys} (Vorgabe: @code{""})
-Gitolite allows you to set git config values using the "config"
-keyword. This setting allows control over the config keys to accept.
-@item @code{roles} (Vorgabe: @code{'(("READERS" . 1) ("WRITERS" . ))})
-Set the role names allowed to be used by users running the perms command.
-@item @code{enable} (default: @code{'("help" "desc" "info" "perms" "writable" "ssh-authkeys" "git-config" "daemon" "gitweb")})
-This setting controls the commands and features to enable within Gitolite.
-@end table
-@end deftp
-@node Spieldienste
-@subsection Spieldienste
-@subsubheading The Battle for Wesnoth Service
-@cindex wesnothd
-@uref{https://wesnoth.org, The Battle for Wesnoth} is a fantasy, turn based
-tactical strategy game, with several single player campaigns, and
-multiplayer games (both networked and local).
-@defvar {Scheme Variable} wesnothd-service-type
-Service type for the wesnothd service.  Its value must be a
-@code{wesnothd-configuration} object.  To run wesnothd in the default
-configuration, instantiate it as:
-@example
-(service wesnothd-service-type)
-@end example
-@end defvar
-@deftp {Data Type} wesnothd-configuration
-Data type representing the configuration of @command{wesnothd}.
-@table @asis
-@item @code{package} (default: @code{wesnoth-server})
-The wesnoth server package to use.
-@item @code{port} (default: @code{15000})
-The port to bind the server to.
-@end table
-@end deftp
-@node Verschiedene Dienste
-@subsection Verschiedene Dienste
-@cindex fingerprint
-@subsubheading Fingerabdrucklese-Dienst
-The @code{(gnu services authentication)} module provides a DBus service to
-read and identify fingerprints via a fingerprint sensor.
-@defvr {Scheme Variable} fprintd-service-type
-The service type for @command{fprintd}, which provides the fingerprint
-reading capability.
-@example
-(service fprintd-service-type)
-@end example
-@end defvr
-@cindex sysctl
-@subsubheading System Control Service
-The @code{(gnu services sysctl)} provides a service to configure kernel
-parameters at boot.
-@defvr {Scheme Variable} sysctl-service-type
-The service type for @command{sysctl}, which modifies kernel parameters
-under @file{/proc/sys/}.  To enable IPv4 forwarding, it can be instantiated
-as:
-@example
-(service sysctl-service-type
-         (sysctl-configuration
-           (settings '(("net.ipv4.ip_forward" . "1")))))
-@end example
-@end defvr
-@deftp {Data Type} sysctl-configuration
-The data type representing the configuration of @command{sysctl}.
-@table @asis
-@item @code{sysctl} (default: @code{(file-append procps "/sbin/sysctl"})
-The @command{sysctl} executable to use.
-@item @code{settings} (default: @code{'()})
-An association list specifies kernel parameters and their values.
-@end table
-@end deftp
-@cindex pcscd
-@subsubheading PC/SC Smart Card Daemon Service
-The @code{(gnu services security-token)} module provides the following
-service to run @command{pcscd}, the PC/SC Smart Card Daemon.
-@command{pcscd} is the daemon program for pcsc-lite and the MuscleCard
-framework. It is a resource manager that coordinates communications with
-smart card readers, smart cards and cryptographic tokens that are connected
-to the system.
-@defvr {Scheme Variable} pcscd-service-type
-Service type for the @command{pcscd} service.  Its value must be a
-@code{pcscd-configuration} object.  To run pcscd in the default
-configuration, instantiate it as:
-@example
-(service pcscd-service-type)
-@end example
-@end defvr
-@deftp {Datentyp} pcscd-configuration
-Repräsentiert die Konfiguration von @command{pcscd}.
-@table @asis
-@item @code{pcsc-lite} (Vorgabe: @code{pcsc-lite})
-The pcsc-lite package that provides pcscd.
-@item @code{usb-drivers} (Vorgabe: @code{(list ccid)})
-List of packages that provide USB drivers to pcscd. Drivers are expected to
-be under @file{pcsc/drivers} in the store directory of the package.
-@end table
-@end deftp
-@cindex lirc
-@subsubheading Lirc Service
-The @code{(gnu services lirc)} module provides the following service.
-@deffn {Scheme Procedure} lirc-service [#:lirc lirc] @
-       [#:device #f] [#:driver #f] [#:config-file #f] @ [#:extra-options '()]
-Return a service that runs @url{http://www.lirc.org,LIRC}, a daemon that
-decodes infrared signals from remote controls.
-Optionally, @var{device}, @var{driver} and @var{config-file} (configuration
-file name) may be specified.  See @command{lircd} manual for details.
-Finally, @var{extra-options} is a list of additional command-line options
-passed to @command{lircd}.
-@end deffn
-@cindex spice
-@subsubheading Spice Service
-The @code{(gnu services spice)} module provides the following service.
-@deffn {Scheme Procedure} spice-vdagent-service [#:spice-vdagent]
-Returns a service that runs @url{http://www.spice-space.org,VDAGENT}, a
-daemon that enables sharing the clipboard with a vm and setting the guest
-display resolution when the graphical console window resizes.
-@end deffn
-@cindex inputattach
-@subsubheading inputattach-Dienst
-@cindex tablet input, for Xorg
-@cindex touchscreen input, for Xorg
-The @uref{https://linuxwacom.github.io/, inputattach} service allows you to
-use input devices such as Wacom tablets, touchscreens, or joysticks with the
-Xorg display server.
-@deffn {Scheme-Variable} inputattach-service-type
-Type of a service that runs @command{inputattach} on a device and dispatches
-events from it.
-@end deffn
-@deftp {Datentyp} inputattach-configuration
-@table @asis
-@item @code{device-type} (Vorgabe: @code{"wacom"})
-The type of device to connect to.  Run @command{inputattach --help}, from
-the @code{inputattach} package, to see the list of supported device types.
-@item @code{device} (Vorgabe: @code{"/dev/ttyS0"})
-The device file to connect to the device.
-@item @code{log-file} (Vorgabe: @code{#f})
-If true, this must be the name of a file to log messages to.
-@end table
-@end deftp
-@subsection Dictionary Services
-@cindex dictionary
-The @code{(gnu services dict)} module provides the following service:
-@deffn {Scheme Procedure} dicod-service [#:config (dicod-configuration)]
-Return a service that runs the @command{dicod} daemon, an implementation of
-DICT server (@pxref{Dicod,,, dico, GNU Dico Manual}).
-The optional @var{config} argument specifies the configuration for
-@command{dicod}, which should be a @code{<dicod-configuration>} object, by
-default it serves the GNU Collaborative International Dictonary of English.
-You can add @command{open localhost} to your @file{~/.dico} file to make
-@code{localhost} the default server for @command{dico} client
-(@pxref{Initialization File,,, dico, GNU Dico Manual}).
-@end deffn
-@deftp {Data Type} dicod-configuration
-Data type representing the configuration of dicod.
-@table @asis
-@item @code{dico} (default: @var{dico})
-Package object of the GNU Dico dictionary server.
-@item @code{interfaces} (default: @var{'("localhost")})
-This is the list of IP addresses and ports and possibly socket file names to
-listen to (@pxref{Server Settings, @code{listen} directive,, dico, GNU Dico
-Manual}).
-@item @code{handlers} (default: @var{'()})
-List of @code{<dicod-handler>} objects denoting handlers (module instances).
-@item @code{databases} (default: @var{(list %dicod-database:gcide)})
-List of @code{<dicod-database>} objects denoting dictionaries to be served.
-@end table
-@end deftp
-@deftp {Data Type} dicod-handler
-Data type representing a dictionary handler (module instance).
-@table @asis
-@item @code{name}
-Name of the handler (module instance).
-@item @code{module} (default: @var{#f})
-Name of the dicod module of the handler (instance).  If it is @code{#f}, the
-module has the same name as the handler.  (@pxref{Module,,, dico, GNU Dico
-Manual}).
-@item @code{options}
-List of strings or gexps representing the arguments for the module handler
-@end table
-@end deftp
-@deftp {Data Type} dicod-database
-Data type representing a dictionary database.
-@table @asis
-@item @code{name}
-Name of the database, will be used in DICT commands.
-@item @code{handler}
-Name of the dicod handler (module instance) used by this database
-(@pxref{Handlers,,, dico, GNU Dico Manual}).
-@item @code{complex?} (default: @var{#f})
-Whether the database configuration complex.  The complex configuration will
-need a corresponding @code{<dicod-handler>} object, otherwise not.
-@item @code{options}
-List of strings or gexps representing the arguments for the database
-(@pxref{Databases,,, dico, GNU Dico Manual}).
-@end table
-@end deftp
-@defvr {Scheme Variable} %dicod-database:gcide
-A @code{<dicod-database>} object serving the GNU Collaborative International
-Dictionary of English using the @code{gcide} package.
-@end defvr
-The following is an example @code{dicod-service} configuration.
-@example
-(dicod-service #:config
-  (dicod-configuration
-   (handlers (list (dicod-handler
-                    (name "wordnet")
-                    (module "dictorg")
-                    (options
-                     (list #~(string-append "dbdir=" #$wordnet))))))
-   (databases (list (dicod-database
-                     (name "wordnet")
-                     (complex? #t)
-                     (handler "wordnet")
-                     (options '("database=wn")))
-                    %dicod-database:gcide))))
-@end example
-@cindex Docker
-@subsubheading Docker-Dienst
-Das Modul @code{(gnu services docker)} stellt den folgenden Dienst zur
-Verfügung.
-@defvr {Scheme-Variable} docker-service-type
-This is the type of the service that runs
-@url{http://www.docker.com,Docker}, a daemon that can execute application
-bundles (sometimes referred to as ``containers'') in isolated environments.
-@end defvr
-@deftp {Datentyp} docker-configuration
-Dies ist der Datentyp, der die Konfiguration von Docker und Containerd
-repräsentiert.
-@table @asis
-@item @code{package} (Vorgabe: @code{docker})
-Das Docker-Paket, was benutzt werden soll.
-@item @code{containerd} (Vorgabe: @var{containerd})
-Das Containerd-Paket, was benutzt werden soll.
-@end table
-@end deftp
-@node Setuid-Programme
-@section Setuid-Programme
-@cindex setuid-Programme
-Manche Programme müssen mit Administratorrechten (also den Berechtigungen
-des »root«-Benutzers) ausgeführt werden, selbst wenn Nutzer ohne besondere
-Berechtigungen sie starten. Ein bekanntes Beispiel ist das Programm
-@command{passwd}, womit Nutzer ihr Passwort ändern können, wozu das Programm
-auf die Dateien @file{/etc/passwd} und @file{/etc/shadow} zugreifen muss —
-was normalerweise nur der »root«-Nutzer darf, aus offensichtlichen Gründen
-der Informationssicherheit. Deswegen sind diese ausführbaren Programmdateien
-@dfn{setuid-root}, d.h.@: sie laufen immer mit den Administratorrechten des
-root-Nutzers, egal wer sie startet (siehe @ref{How Change Persona,,, libc,
-The GNU C Library Reference Manual} für mehr Informationen über den
-setuid-Mechanismus).
-Der Store selbst kann @emph{keine} setuid-Programme enthalten: Das wäre eine
-Sicherheitslücke, weil dann jeder Nutzer auf dem System Ableitungen
-schreiben könnte, die in den Store solche Dateien einfügen würden (siehe
-@ref{Der Store}). Wir benutzen also einen anderen Mechanismus: Statt auf den
-ausführbaren Dateien im Store selbst deren setuid-Bit zu setzen, lassen wir
-den Systemadministrator @emph{deklarieren}, welche Programme mit setuid-root
-gestartet werden.
-Das Feld @code{setuid-programs} einer @code{operating-system}-Deklaration
-enthält eine Liste von G-Ausdrücken, die die Namen der Programme angeben,
-die setuid-root sein sollen (siehe @ref{Das Konfigurationssystem nutzen}). Zum Beispiel kann das Programm @command{passwd}, was Teil des
-Shadow-Pakets ist, durch diesen G-Ausdruck bezeichnet werden (siehe
-@ref{G-Ausdrücke}):
-@example
-#~(string-append #$shadow "/bin/passwd")
-@end example
-Eine vorgegebene Menge von setuid-Programmen wird durch die Variable
-@code{%setuid-programs} aus dem Modul @code{(gnu system)} definiert.
-@defvr {Scheme-Variable} %setuid-programs
-Eine Liste von G-Ausdrücken, die übliche Programme angeben, die setuid-root
-sein müssen.
-Die Liste enthält Befehle wie @command{passwd}, @command{ping}, @command{su}
-und @command{sudo}.
-@end defvr
-Intern erzeugt Guix die eigentlichen setuid-Programme im Verzeichnis
-@file{/run/setuid-programs}, wenn das System aktiviert wird. Die Dateien in
-diesem Verzeichnis verweisen auf die »echten« Binärdateien im Store.
-@node X.509-Zertifikate
-@section X.509-Zertifikate
-@cindex HTTPS, Zertifikate
-@cindex X.509-Zertifikate
-@cindex TLS
-Über HTTPS verfügbare Webserver (also HTTP mit gesicherter Transportschicht,
-englisch »Transport-Layer Security«, kurz TLS) senden Client-Programmen ein
-@dfn{X.509-Zertifikat}, mit dem der Client den Server dann
-@emph{authentifizieren} kann. Dazu verifiziert der Client, dass das
-Zertifikat des Servers von einer sogenannten Zertifizierungsstelle signiert
-wurde (englisch @dfn{Certificate Authority}, kurz CA). Damit er aber die
-Signatur der Zertifizierungsstelle verifizieren kann, muss jeder Client das
-Zertifikat der Zertifizierungsstelle besitzen.
-Web-Browser wie GNU@tie{}IceCat liefern ihre eigenen CA-Zertifikate mit,
-damit sie von Haus aus Zertifikate verifizieren können.
-Den meisten anderen Programmen, die HTTPS sprechen können — @command{wget},
-@command{git}, @command{w3m} etc.@: — muss allerdings erst mitgeteilt
-werden, wo die CA-Zertifikate installiert sind.
-@cindex @code{nss-certs}
-In Guix müssen Sie dazu ein Paket, das Zertifikate enthält, in das
-@code{packages}-Feld der @code{operating-system}-Deklaration des
-Betriebssystems hinzufügen (siehe @ref{»operating-system«-Referenz}). Guix
-liefert ein solches Paket mit, @code{nss-certs}, was als Teil von Mozillas
-»Network Security Services« angeboten wird.
-Beachten Sie, dass es @emph{nicht} zu den @var{%base-packages} gehört, Sie
-es also ausdrücklich hinzufügen müssen. Das Verzeichnis
-@file{/etc/ssl/certs}, wo die meisten Anwendungen und Bibliotheken ihren
-Voreinstellungen entsprechend nach Zertifikaten suchen, verweist auf die
-global installierten Zertifikate.
-Unprivilegierte Benutzer, wie die, die Guix auf einer Fremddistribution
-benutzen, können sich auch lokal ihre eigenen Pakete mit Zertifikaten in ihr
-Profil installieren. Eine Reihe von Umgebungsvariablen muss dazu definiert
-werden, damit Anwendungen und Bibliotheken wissen, wo diese Zertifikate zu
-finden sind. Und zwar folgt die OpenSSL-Bibliothek den Umgebungsvariablen
-@code{SSL_CERT_DIR} und @code{SSL_CERT_FILE}, manche Anwendungen benutzen
-stattdessen aber ihre eigenen Umgebungsvariablen. Das Versionskontrollsystem
-Git liest den Ort zum Beispiel aus der Umgebungsvariablen
-@code{GIT_SSL_CAINFO} aus. Sie würden typischerweise also so etwas
-ausführen:
-@example
-$ guix package -i nss-certs
-$ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
-$ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
-$ export GIT_SSL_CAINFO="$SSL_CERT_FILE"
-@end example
-Ein weiteres Beispiel ist R, was voraussetzt, dass die Umgebungsvariable
-@code{CURL_CA_BUNDLE} auf ein Zertifikatsbündel verweist, weshalb Sie etwas
-wie hier ausführen müssten:
-@example
-$ guix package -i nss-certs
-$ export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
-@end example
-Für andere Anwendungen möchten Sie die Namen der benötigten
-Umgebungsvariablen vielleicht in deren Dokumentation nachschlagen.
-@node Name Service Switch
-@section Name Service Switch
-@cindex Name Service Switch
-@cindex NSS
-Das Modul @code{(gnu system nss)} enthält Anbindungen für die Konfiguration
-des @dfn{Name Service Switch} (NSS) der libc (siehe @ref{NSS Configuration
-File,,, libc, The GNU C Library Reference Manual}). Kurz gesagt ist der NSS
-ein Mechanismus, mit dem die libc um neue »Namens«-Auflösungsmethoden für
-Systemdatenbanken erweitert werden kann; dazu gehören Rechnernamen (auch
-bekannt als »Host«-Namen), Dienstnamen, Benutzerkonten und mehr (siehe
-@ref{Name Service Switch, System Databases and Name Service Switch,, libc,
-The GNU C Library Reference Manual}).
-Die NSS-Konfiguration legt für jede Systemdatenbank fest, mit welcher
-Methode der Name nachgeschlagen (»aufgelöst«) werden kann und welche
-Methoden zusammenhängen — z.B.@: unter welchen Umständen der NSS es mit der
-nächsten Methode auf seiner Liste versuchen sollte. Die NSS-Konfiguration
-wird im Feld @code{name-service-switch} von
-@code{operating-system}-Deklarationen angegeben (siehe @ref{»operating-system«-Referenz, @code{name-service-switch}}).
-@cindex nss-mdns
-@cindex .local, Rechnernamensauflösung
-Zum Beispiel konfigurieren die folgenden Deklarationen den NSS so, dass er
-das @uref{http://0pointer.de/lennart/projects/nss-mdns/,
-@code{nss-mdns}-Backend} benutzt, wodurch er auf @code{.local} endende
-Rechnernamen über Multicast-DNS (mDNS) auflöst:
-@example
-(name-service-switch
-   (hosts (list %files    ;zuerst in /etc/hosts nachschlagen
-                ;; Wenn das keinen Erfolg hatte, es
-                ;; mit 'mdns_minimal' versuchen.
-                (name-service
-                  (name "mdns_minimal")
-                  ;; 'mdns_minimal' ist die Autorität für
-                  ;; '.local'. Gibt es not-found ("nicht
-                  ;; gefunden") zurück, müssen wir die
-                  ;; nächsten Methoden gar nicht erst
-                  ;; versuchen.
-                  (reaction (lookup-specification
-                             (not-found => return))))
-                ;; Ansonsten benutzen wir DNS.
-                (name-service
-                  (name "dns"))
-                ;; Ein letzter Versuch mit dem
-                ;; "vollständigen" 'mdns'.
-                (name-service
-                  (name "mdns")))))
-@end example
-Keine Sorge: Die Variable @code{%mdns-host-lookup-nss} (siehe unten) enthält
-diese Konfiguration bereits. Statt das alles selst einzutippen, können Sie
-sie benutzen, wenn alles, was Sie möchten, eine funktionierende
-Namensauflösung für @code{.local}-Rechner ist.
-Beachten Sie dabei, dass es zusätzlich zum Festlegen des
-@code{name-service-switch} in der @code{operating-system}-Deklaration auch
-erforderlich ist, den @code{avahi-service-type} zu benutzen (siehe
-@ref{Netzwerkdienste, @code{avahi-service-type}}). Es genügt auch, wenn
-Sie die @var{%desktop-services} benutzen, weil er darin enthalten ist (siehe
-@ref{Desktop-Dienste}). Dadurch wird @code{nss-mdns} für den Name Service
-Cache Daemon nutzbar (siehe @ref{Basisdienste, @code{nscd-service}}).
-Um sich eine lange Konfiguration zu ersparen, können Sie auch einfach die
-folgenden Variablen für typische NSS-Konfigurationen benutzen.
-@defvr {Scheme-Variable} %default-nss
-Die vorgegebene Konfiguration des Name Service Switch als ein
-@code{name-service-switch}-Objekt.
-@end defvr
-@defvr {Scheme-Variable} %mdns-host-lookup-nss
-Die Name-Service-Switch-Konfiguration mit Unterstützung für
-Rechnernamensauflösung über »Multicast DNS« (mDNS) für auf @code{.local}
-endende Rechnernamen.
-@end defvr
-Im Folgenden finden Sie eine Referenz, wie eine
-Name-Service-Switch-Konfiguration aussehen muss. Sie hat eine direkte
-Entsprechung zum Konfigurationsdateiformat der C-Bibliothek, lesen Sie
-weitere Informationen also bitte im Handbuch der C-Bibliothek nach (siehe
-@ref{NSS Configuration File,,, libc, The GNU C Library Reference
-Manual}). Gegenüber dem Konfigurationsdateiformat des libc-NSS bekommen Sie
-mit unserer Syntax nicht nur ein warm umklammerndes Gefühl, sondern auch
-eine statische Analyse: Wenn Sie Syntax- und Schreibfehler machen, werden
-Sie darüber benachrichtigt, sobald Sie @command{guix system} aufrufen.
-@deftp {Datentyp} name-service-switch
-Der Datentyp, der die Konfiguration des Name Service Switch (NSS) der libc
-repräsentiert. Jedes im Folgenden aufgeführte Feld repräsentiert eine der
-unterstützten Systemdatenbanken.
-@table @code
-@item aliases
-@itemx ethers
-@itemx group
-@itemx gshadow
-@itemx hosts
-@itemx initgroups
-@itemx netgroup
-@itemx networks
-@itemx password
-@itemx public-key
-@itemx rpc
-@itemx services
-@itemx shadow
-Das sind die Systemdatenbanken, um die sich NSS kümmern kann. Jedes dieser
-Felder muss eine Liste aus @code{<name-service>}-Objekten sein (siehe
-unten).
-@end table
-@end deftp
-@deftp {Datentyp} name-service
-Der einen eigentlichen Namensdienst repräsentierende Datentyp zusammen mit
-der zugehörigen Auflösungsaktion.
-@table @code
-@item name
-Eine Zeichenkette, die den Namensdienst bezeichnet (siehe @ref{Services in
-the NSS configuration,,, libc, The GNU C Library Reference Manual}).
-Beachten Sie, dass hier aufgeführte Namensdienste für den nscd sichtbar sein
-müssen. Dazu übergeben Sie im Argument @code{#:name-services} des
-@code{nscd-service} die Liste der Pakete, die die entsprechenden
-Namensdienste anbieten (siehe @ref{Basisdienste, @code{nscd-service}}).
-@item reaction
-Eine mit Hilfe des Makros @code{lookup-specification} angegebene Aktion
-(siehe @ref{Actions in the NSS configuration,,, libc, The GNU C Library
-Reference Manual}). Zum Beispiel:
-@example
-(lookup-specification (unavailable => continue)
-                      (success => return))
-@end example
-@end table
-@end deftp
-@node Initiale RAM-Disk
-@section Initiale RAM-Disk
-@cindex initrd
-@cindex initiale RAM-Disk
-Um ihn zu initialisieren (zu »bootstrappen«), wird für den Kernel
-Linux-Libre eine @dfn{initiale RAM-Disk} angegeben (kurz @dfn{initrd}). Eine
-initrd enthält ein temporäres Wurzeldateisystem sowie ein Skript zur
-Initialisierung. Letzteres ist dafür zuständig, das echte Wurzeldateisystem
-einzubinden und alle Kernel-Module zu laden, die dafür nötig sein könnten.
-Mit dem Feld @code{initrd-modules} einer @code{operating-system}-Deklaration
-können Sie angeben, welche Kernel-Module für Linux-libre in der initrd
-verfügbar sein müssen. Insbesondere müssen hier die Module aufgeführt
-werden, um die Festplatte zu betreiben, auf der sich Ihre Wurzelpartition
-befindet — allerdings sollte der vorgegebene Wert der @code{initrd-modules}
-in dem meisten Fällen genügen. Wenn Sie aber zum Beispiel das Kernel-Modul
-@code{megaraid_sas} zusätzlich zu den vorgegebenen Modulen brauchen, um auf
-Ihr Wurzeldateisystem zugreifen zu können, würden Sie das so schreiben:
-@example
-(operating-system
-  ;; @dots{}
-  (initrd-modules (cons "megaraid_sas" %base-initrd-modules)))
-@end example
-@defvr {Scheme-Variable} %base-initrd-modules
-Der Vorgabewert für die Liste der Kernel-Module, die in der initrd enthalten
-sein sollen.
-@end defvr
-Wenn Sie noch systemnähere Anpassungen durchführen wollen, können Sie im
-Feld @code{initrd} einer @code{operating-system}-Deklaration angeben, was
-für eine Art von initrd Sie benutzen möchten. Das Modul @code{(gnu system
-linux-initrd)} enthält drei Arten, eine initrd zu erstellen: die abstrakte
-Prozedur @code{base-initrd} und die systemnahen Prozeduren @code{raw-initrd}
-und @code{expression->initrd}.
-Mit der Prozedur @code{base-initrd} sollten Sie die häufigsten
-Anwendungszwecke abdecken können. Wenn Sie zum Beispiel ein paar
-Kernel-Module zur Boot-Zeit laden lassen möchten, können Sie das
-@code{initrd}-Feld auf diese Art definieren:
-@example
-(initrd (lambda (file-systems . rest)
-          ;; Eine gewöhnliche initrd, aber das Netzwerk wird
-          ;; mit den Parametern initialisiert, die QEMU
-          ;; standardmäßig erwartet.
-          (apply base-initrd file-systems
-                 #:qemu-networking? #t
-                 rest)))
-@end example
-Die Prozedur @code{base-initrd} kann auch mit üblichen Anwendungszwecken
-umgehen, um das System als QEMU-Gastsystem zu betreiben oder als ein
-»Live«-System ohne ein dauerhaft gespeichertes Wurzeldateisystem.
-Die Prozedur @code{base-initrd} baut auf der Prozedur @code{raw-initrd}
-auf. Anders als @code{base-initrd} hat @code{raw-initrd} keinerlei
-Zusatzfunktionalitäten: Es wird kein Versuch unternommen, für die initrd
-notwendige Kernel-Module und Pakete automatisch
-hinzuzunehmen. @code{raw-initrd} kann zum Beispiel benutzt werden, wenn ein
-Nutzer eine eigene Konfiguration des Linux-Kernels verwendet und die
-Standard-Kernel-Module, die mit @code{base-initrd} hinzugenommen würden,
-nicht verfügbar sind.
-Die initiale RAM-Disk, wie sie von @code{base-initrd} oder @code{raw-initrd}
-erzeugt wird, richtet sich nach verschiedenen Optionen, die auf der
-Kernel-Befehlszeile übergeben werden (also über GRUBs @code{linux}-Befehl
-oder die @code{-append}-Befehlszeilenoption von QEMU). Erwähnt werden
-sollten:
-@table @code
-@item --load=@var{boot}
-Die initiale RAM-Disk eine Datei @var{boot}, in der ein Scheme-Programm
-steht, laden lassen, nachdem das Wurzeldateisystem eingebunden wurde.
-Guix übergibt mit dieser Befehlszeilenoption die Kontrolle an ein
-Boot-Programm, das die Dienstaktivierungsprogramme ausführt und anschließend
-den GNU@tie{}Shepherd startet, das Initialisierungssystem (»init«-System)
-von Guix System.
-@item --root=@var{Wurzel}
-Das mit @var{Wurzel} bezeichnete Dateisystem als Wurzeldateisystem
-einbinden. @var{Wurzel} kann ein Geratename wie @code{/dev/sda1}, eine
-Dateisystembezeichnung (d.h.@: ein Dateisystem-»Label«) oder eine
-Dateisystem-UUID sein.
-@item --system=@var{System}
-@file{/run/booted-system} und @file{/run/current-system} auf das
-@var{System} zeigen lassen.
-@item modprobe.blacklist=@var{Module}@dots{}
-@cindex Kernel-Module, Sperrliste
-@cindex Sperrliste, von Kernel-Modulen
-Die initiale RAM-Disk sowie den Befehl @command{modprobe} (aus dem
-kmod-Paket) anweisen, das Laden der angegebenen @var{Module} zu
-verweigern. Als @var{Module} muss eine kommagetrennte Liste von
-Kernel-Modul-Namen angegeben werden — z.B.@: @code{usbkbd,9pnet}.
-@item --repl
-Eine Lese-Auswerten-Schreiben-Schleife (englisch »Read-Eval-Print Loop«,
-kurz REPL) von der initialen RAM-Disk starten, bevor diese die Kernel-Module
-zu laden versucht und das Wurzeldateisystem einbindet. Unsere
-Marketingabteilung nennt das @dfn{boot-to-Guile}. Der Schemer in Ihnen wird
-das lieben. Siehe @ref{Using Guile Interactively,,, guile, GNU Guile
-Reference Manual} für mehr Informationen über die REPL von Guile.
-@end table
-Jetzt wo Sie wissen, was für Funktionalitäten eine durch @code{base-initrd}
-und @code{raw-initrd} erzeugte initiale RAM-Disk so haben kann, möchten Sie
-vielleicht auch wissen, wie man Sie benutzt und weiter anpasst:
-@cindex initrd
-@cindex initiale RAM-Disk
-@deffn {Scheme-Prozedur} raw-initrd @var{Dateisysteme} @
-       [#:linux-modules '()] [#:mapped-devices '()] @ [#:keyboard-layout #f] @
-[#:helper-packages '()] [#:qemu-networking? #f] [#:volatile-root? #f]
-Liefert eine Ableitung, die eine rohe (»raw«) initrd
-erstellt. @var{Dateisysteme} bezeichnet eine Liste von durch die initrd
-einzubindenden Dateisystemen, unter Umständen zusätzlich zum auf der
-Kernel-Befehlszeile mit @code{--root} angegebenen
-Wurzeldateisystem. @var{linux-modules} ist eine Liste von Kernel-Modulen,
-die zur Boot-Zeit geladen werden sollen. @var{mapped-devices} ist eine Liste
-von Gerätezuordnungen, die hergestellt sein müssen, bevor die unter
-@var{file-systems} aufgeführten Dateisysteme eingebunden werden (siehe
-@ref{Zugeordnete Geräte}). @var{helper-packages} ist eine Liste von Paketen, die
-in die initrd kopiert werden. Darunter kann @code{e2fsck/static} oder andere
-Pakete aufgeführt werden, mit denen durch die initrd das Wurzeldateisystem
-auf Fehler hin geprüft werden kann.
-When true, @var{keyboard-layout} is a @code{<keyboard-layout>} record
-denoting the desired console keyboard layout.  This is done before
-@var{mapped-devices} are set up and before @var{file-systems} are mounted
-such that, should the user need to enter a passphrase or use the REPL, this
-happens using the intended keyboard layout.
-Wenn @var{qemu-networking?} wahr ist, wird eine Netzwerkverbindung mit den
-Standard-QEMU-Parametern hergestellt. Wenn @var{virtio?} wahr ist, werden
-zusätzliche Kernel-Module geladen, damit die initrd als ein QEMU-Gast
-paravirtualisierte Ein-/Ausgabetreiber benutzen kann.
-Wenn @var{volatile-root?} wahr ist, ist Schreiben auf das Wurzeldateisystem
-möglich, aber Änderungen daran bleiben nicht erhalten.
-@end deffn
-@deffn {Scheme-Prozedur} base-initrd @var{Dateisysteme} @
-       [#:mapped-devices '()] [#:keyboard-layout #f] @ [#:qemu-networking? #f]
-[#:volatile-root? #f] @ [#:linux-modules '()] Liefert eine allgemein
-anwendbare, generische initrd als dateiartiges Objekt mit den Kernel-Modulen
-aus @var{linux}. Die @var{file-systems} sind eine Liste von durch die initrd
-einzubindenden Dateisystemen, unter Umständen zusätzlich zum
-Wurzeldateisystem, das auf der Kernel-Befehlszeile mit @code{--root}
-angegeben wurde. Die @var{mapped-devices} sind eine Liste von
-Gerätezuordnungen, die hergestellt sein müssen, bevor die @var{file-systems}
-eingebunden werden.
-When true, @var{keyboard-layout} is a @code{<keyboard-layout>} record
-denoting the desired console keyboard layout.  This is done before
-@var{mapped-devices} are set up and before @var{file-systems} are mounted
-such that, should the user need to enter a passphrase or use the REPL, this
-happens using the intended keyboard layout.
-@var{qemu-networking?} und @var{volatile-root?} verhalten sich wie bei
-@code{raw-initrd}.
-In die initrd werden automatisch alle Kernel-Module eingefügt, die für die
-unter @var{file-systems} angegebenen Dateisysteme und die angegebenen
-Optionen nötig sind. Zusätzliche Kernel-Module können unter den
-@var{linux-modules} aufgeführt werden. Diese werden zur initrd hinzugefügt
-und zur Boot-Zeit in der Reihenfolge geladen, in der sie angegeben wurden.
-@end deffn
-Selbstverständlich betten die hier erzeugten und benutzten initrds ein
-statisch gebundenes Guile ein und das Initialisierungsprogramm ist ein
-Guile-Programm. Dadurch haben wir viel Flexibilität. Die Prozedur
-@code{expression->initrd} erstellt eine solche initrd für ein an sie
-übergebenes Programm.
-@deffn {Scheme-Prozedur} expression->initrd @var{G-Ausdruck} @
-       [#:guile %guile-static-stripped] [#:name "guile-initrd"] Liefert eine
-Linux-initrd (d.h.@: ein gzip-komprimiertes cpio-Archiv) als dateiartiges
-Objekt, in dem @var{guile} enthalten ist, womit der @var{G-Ausdruck} nach
-dem Booten ausgewertet wird. Alle vom @var{G-Ausdruck} referenzierten
-Ableitungen werden automatisch in die initrd kopiert.
-@end deffn
-@node Bootloader-Konfiguration
-@section Bootloader-Konfiguration
-@cindex bootloader
-@cindex Bootloader
-Das Betriebssystem unterstützt mehrere Bootloader. Der gewünschte Bootloader
-wird mit der @code{bootloader-configuration}-Deklaration konfiguriert. Alle
-Felder dieser Struktur sind für alle Bootloader gleich außer dem einen Feld
-@code{bootloader}, das angibt, welcher Bootloader konfiguriert und
-installiert werden soll.
-Manche der Bootloader setzen nicht alle Felder einer
-@code{bootloader-configuration} um. Zum Beispiel ignoriert der
-extlinux-Bootloader das @code{theme}-Feld, weil er keine eigenen Themen
-unterstützt.
-@deftp {Datentyp} bootloader-configuration
-Der Typ der Deklaration einer Bootloader-Konfiguration.
-@table @asis
-@item @code{bootloader}
-@cindex EFI, Bootloader
-@cindex UEFI, Bootloader
-@cindex BIOS, Bootloader
-Der zu benutzende Bootloader als ein @code{bootloader}-Objekt. Zur Zeit
-werden @code{grub-bootloader}, @code{grub-efi-bootloader},
-@code{extlinux-bootloader} und @code{u-boot-bootloader} unterstützt.
-@vindex grub-efi-bootloader
-@code{grub-efi-bootloader} macht es möglich, auf modernen Systemen mit
-@dfn{Unified Extensible Firmware Interface} (UEFI) zu booten. Sie sollten
-das hier benutzen, wenn im Installationsabbild ein Verzeichnis
-@file{/sys/firmware/efi} vorhanden ist, wenn Sie davon auf Ihrem System
-booten.
-@vindex grub-bootloader
-Mit @code{grub-bootloader} können Sie vor allem auf Intel-basierten
-Maschinen im alten »Legacy«-BIOS-Modus booten.
-@cindex ARM, Bootloader
-@cindex AArch64, Bootloader
-Verfügbare Bootloader werden in den Modulen @code{(gnu bootloader @dots{})}
-beschrieben. Insbesondere enthält @code{(gnu bootloader u-boot)}
-Definitionen für eine Vielzahl von ARM- und AArch64-Systemen, die den
-@uref{http://www.denx.de/wiki/U-Boot/, U-Boot-Bootloader} benutzen.
-@item @code{target}
-Eine Zeichenkette, die angibt, auf welches Ziel der Bootloader installiert
-werden soll.
-Was das bedeutet, hängt vom jeweiligen Bootloader ab. Für
-@code{grub-bootloader} sollte hier zum Beispiel ein Gerätename angegeben
-werden, der vom @command{installer}-Befehl des Bootloaders verstanden wird,
-etwa @code{/dev/sda} oder @code{(hd0)} (siehe @ref{Invoking grub-install,,,
-grub, GNU GRUB Manual}). Für @code{grub-efi-bootloader} sollte der
-Einhängepunkt des EFI-Dateisystems angegeben werden, in der Regel
-@file{/boot/efi}.
-@item @code{menu-entries} (Vorgabe: @code{()})
-Eine möglicherweise leere Liste von @code{menu-entry}-Objekten (siehe
-unten), die für Menüeinträge stehen, die im Bootloader-Menü auftauchen
-sollen, zusätzlich zum aktuellen Systemeintrag und dem auf vorherige
-Systemgenerationen verweisenden Eintrag.
-@item @code{default-entry} (Vorgabe: @code{0})
-Die Position des standardmäßig ausgewählten Bootmenü-Eintrags. An Position 0
-steht der Eintrag der aktuellen Systemgeneration.
-@item @code{timeout} (Vorgabe: @code{5})
-Wieviele Sekunden lang im Menü auf eine Tastatureingabe gewartet wird, bevor
-gebootet wird. 0 steht für sofortiges Booten, für -1 wird ohne
-Zeitbeschränkung gewartet.
-@cindex Tastaturbelegung, beim Bootloader
-@item @code{keyboard-layout} (Vorgabe: @code{#f})
-Wenn dies auf @code{#f} gesetzt ist, verwendet das Menü des Bootloaders
-(falls vorhanden) die Vorgabe-Tastaturbelegung, normalerweise
-US@tie{}English (»qwerty«).
-Andernfalls muss es ein @code{keyboard-layout}-Objekt sein (siehe
-@ref{Tastaturbelegung}).
-@quotation Anmerkung
-Dieses Feld wird derzeit von Bootloadern außer @code{grub} und
-@code{grub-efi} ignoriert.
-@end quotation
-@item @code{theme} (Vorgabe: @var{#f})
-Ein Objekt für das im Bootloader anzuzeigende Thema. Wird kein Thema
-angegeben, benutzen manche Bootloader vielleicht ein voreingestelltes Thema;
-GRUB zumindest macht es so.
-@item @code{terminal-outputs} (Vorgabe: @code{'gfxterm})
-Die Ausgabeterminals, die für das Boot-Menü des Bootloaders benutzt werden,
-als eine Liste von Symbolen. GRUB akzeptiert hier diese Werte:
-@code{console}, @code{serial}, @code{serial_@{0–3@}}, @code{gfxterm},
-@code{vga_text}, @code{mda_text}, @code{morse} und @code{pkmodem}. Dieses
-Feld entspricht der GRUB-Variablen @code{GRUB_TERMINAL_OUTPUT} (siehe
-@ref{Simple configuration,,, grub,GNU GRUB manual}).
-@item @code{terminal-inputs} (Vorgabe: @code{'()})
-Die Eingabeterminals, die für das Boot-Menü des Bootloaders benutzt werden,
-als eine Liste von Symbolen. GRUB verwendet hier das zur Laufzeit bestimmte
-Standardterminal. GRUB akzeptiert sonst diese Werte: @code{console},
-@code{serial}, @code{serial_@{0-3@}}, @code{at_keyboard} und
-@code{usb_keyboard}. Dieses Feld entspricht der GRUB-Variablen
-@code{GRUB_TERMINAL_INPUT} (siehe @ref{Simple configuration,,, grub,GNU GRUB
-manual}).
-@item @code{serial-unit} (Vorgabe: @code{#f})
-Die serielle Einheit, die der Bootloader benutzt, als eine ganze Zahl
-zwischen 0 und 3, einschließlich. Für GRUB wird sie automatisch zur Laufzeit
-ausgewählt; derzeit wählt GRUB die 0 aus, die COM1 entspricht (siehe
-@ref{Serial terminal,,, grub,GNU GRUB manual}).
-@item @code{serial-speed} (Vorgabe: @code{#f})
-Die Geschwindigkeit der seriellen Schnittstelle als eine ganze Zahl. GRUB
-bestimmt den Wert standardmäßig zur Laufzeit; derzeit wählt GRUB
-9600@tie{}bps (siehe @ref{Serial terminal,,, grub,GNU GRUB manual}).
-@end table
-@end deftp
-@cindex Dual-Boot
-@cindex Bootmenü
-Sollten Sie zusätzliche Bootmenü-Einträge über das oben beschriebene
-@code{menu-entries}-Feld hinzufügen möchten, müssen Sie diese mit der
-@code{menu-entry}-Form erzeugen. Stellen Sie sich zum Beispiel vor, Sie
-wollten noch eine andere Distribution booten können (schwer vorstellbar!),
-dann könnten Sie einen Menüeintrag wie den Folgenden definieren:
-@example
-(menu-entry
-  (label "Die _andere_ Distribution")
-  (linux "/boot/old/vmlinux-2.6.32")
-  (linux-arguments '("root=/dev/sda2"))
-  (initrd "/boot/old/initrd"))
-@end example
-Details finden Sie unten.
-@deftp {Datentyp} menu-entry
-Der Typ eines Eintrags im Bootloadermenü.
-@table @asis
-@item @code{label}
-Die Beschriftung, die im Menü gezeigt werden soll — z.B.@: @code{"GNU"}.
-@item @code{linux}
-Das Linux-Kernel-Abbild, was gebootet werden soll, zum Beispiel:
-@example
-(file-append linux-libre "/bzImage")
-@end example
-Für GRUB kann hier auch ein Gerät ausdrücklich zum Dateipfad angegeben
-werden, unter Verwendung von GRUBs Konventionen zur Gerätebenennung (siehe
-@ref{Naming convention,,, grub, GNU GRUB manual}), zum Beispiel:
-@example
-"(hd0,msdos1)/boot/vmlinuz"
-@end example
-Wenn das Gerät auf diese Weise ausdrücklich angegeben wird, wird das
-@code{device}-Feld gänzlich ignoriert.
-@item @code{linux-arguments} (Vorgabe: @code{()})
-Die Liste zusätzlicher Linux-Kernel-Befehlszeilenargumente — z.B.@:
-@code{("console=ttyS0")}.
-@item @code{initrd}
-Ein G-Ausdruck oder eine Zeichenkette, die den Dateinamen der initialen
-RAM-Disk angibt, die benutzt werden soll (siehe @ref{G-Ausdrücke}).
-@item @code{device} (Vorgabe: @code{#f})
-Das Gerät, auf dem Kernel und initrd zu finden sind — d.h.@: bei GRUB die
-Wurzel (@dfn{root}) dieses Menüeintrags (siehe @ref{root,,, grub, GNU GRUB
-manual}).
-Dies kann eine Dateisystembezeichnung (als Zeichenkette), eine
-Dateisystem-UUID (als Bytevektor, siehe @ref{Dateisysteme}) oder @code{#f}
-sein, im letzten Fall wird der Bootloader auf dem Gerät suchen, das die vom
-@code{linux}-Feld benannte Datei enthält (siehe @ref{search,,, grub, GNU
-GRUB manual}). Ein vom Betriebssystem vergebener Gerätename wie
-@file{/dev/sda1} ist aber @emph{nicht} erlaubt.
-@end table
-@end deftp
-@c FIXME: Write documentation once it's stable.
-For now only GRUB has theme support. GRUB themes are created using the
-@code{grub-theme} form, which is not documented yet.
-@defvr {Scheme Variable} %default-theme
-Das vorgegebene GRUB-Thema, das vom Betriebssystem benutzt wird, wenn kein
-@code{theme}-Feld im @code{bootloader-configuration}-Verbundsobjekt
-angegeben wurde.
-Es wird von einem feschen Hintergrundbild begleitet, das die Logos von GNU
-und Guix zeigt.
-@end defvr
-@node Aufruf von guix system
-@section @code{guix system} aufrufen
-Sobald Sie eine Betriebssystemdeklaration geschrieben haben, wie wir sie in
-den vorangehenden Abschnitten gesehen haben, kann diese @dfn{instanziiert}
-werden, indem Sie den Befehl @command{guix system}
-aufrufen. Zusammengefasst:
-@example
-guix system @var{Optionen}@dots{} @var{Aktion} @var{Datei}
-@end example
-@var{Datei} muss der Name einer Datei sein, in der eine
-Betriebssystemdeklaration als @code{operating-system}-Objekt
-steht. @var{Aktion} gibt an, wie das Betriebssystem instanziiert
-wird. Derzeit werden folgende Werte dafür unterstützt:
-@table @code
-@item search
-Verfügbare Diensttypendefinitionen anzeigen, die zum angegebenen regulären
-Ausdruck passen, sortiert nach Relevanz:
-@example
-$ guix system search console font
-name: console-fonts
-location: gnu/services/base.scm:729:2
-extends: shepherd-root
-description: Install the given fonts on the specified ttys (fonts are
-+ per virtual console on GNU/Linux).  The value of this service is a list
-+ of tty/font pairs like:
-+ 
-+      '(("tty1" . "LatGrkCyr-8x16"))
-relevance: 20
-name: mingetty
-location: gnu/services/base.scm:1048:2
-extends: shepherd-root
-description: Provide console login using the `mingetty' program.
-relevance: 2
-name: login
-location: gnu/services/base.scm:775:2
-extends: pam
-description: Provide a console log-in service as specified by its
-+ configuration value, a `login-configuration' object.
-relevance: 2
-@dots{}
-@end example
-Wie auch bei @command{guix package --search} wird das Ergebnis im
-@code{recutils}-Format geliefert, so dass es leicht ist, die Ausgabe zu
-filtern (siehe @ref{Top, GNU recutils databases,, recutils, GNU recutils
-manual}).
-@item reconfigure
-Das in der @var{Datei} beschriebene Betriebssystem erstellen, aktivieren und
-zu ihm wechseln@footnote{Diese Aktion (und die dazu ähnlichen Aktionen
-@code{switch-generation} und @code{roll-back}) sind nur auf Systemen
-nutzbar, auf denen »Guix System« bereits läuft.}.
-Dieser Befehl setzt die in der @var{Datei} festgelegte Konfiguration
-vollständig um: Benutzerkonten, Systemdienste, die Liste globaler Pakete,
-setuid-Programme und so weiter. Der Befehl startet die in der @var{Datei}
-angegebenen Systemdienste, die aktuell nicht laufen; bei aktuell laufenden
-Diensten wird sichergestellt, dass sie aktualisiert werden, sobald sie das
-nächste Mal angehalten wurden (z.B.@: durch @code{herd stop X} oder
-@code{herd restart X}).
-Dieser Befehl erzeugt eine neue Generation, deren Nummer (wie @command{guix
-system list-generations} sie anzeigt) um eins größer als die der aktuellen
-Generation ist. Wenn die so nummerierte Generation bereits existiert, wird
-sie überschrieben. Dieses Verhalten entspricht dem von @command{guix
-package} (siehe @ref{Aufruf von guix package}).
-Des Weiteren wird für den Bootloader ein Menüeintrag für die neue
-Betriebssystemkonfiguration hinzugefügt, außer die Befehlszeilenoption
-@option{--no-bootloader} wurde übergeben. Bei GRUB werden Einträge für
-ältere Konfigurationen in ein Untermenü verschoben, so dass Sie auch eine
-ältere Systemgeneration beim Booten noch hochfahren können, falls es
-notwendig wird.
-@quotation Anmerkung
-@c The paragraph below refers to the problem discussed at
-@c <http://lists.gnu.org/archive/html/guix-devel/2014-08/msg00057.html>.
-Es ist sehr zu empfehlen, @command{guix pull} einmal auszuführen, bevor Sie
-@command{guix system reconfigure} zum ersten Mal aufrufen (siehe
-@ref{Aufruf von guix pull}). Wenn Sie das nicht tun, könnten Sie nach dem
-Abschluss von @command{reconfigure} eine ältere Version von Guix vorfinden,
-als Sie vorher hatten.
-@end quotation
-@item switch-generation
-@cindex Generationen
-Zu einer bestehenden Systemgeneration wechseln. Diese Aktion wechselt das
-Systemprofil atomar auf die angegebene Systemgeneration. Hiermit werden auch
-die bestehenden Menüeinträge des Bootloaders umgeordnet. Der Menüeintrag für
-die angegebene Systemgeneration wird voreingestellt und die Einträge der
-anderen Generationen werden in ein Untermenü verschoben, sofern der
-verwendete Bootloader dies unterstützt. Das nächste Mal, wenn das System
-gestartet wird, wird die hier angegebene Systemgeneration hochgefahren.
-Der Bootloader selbst wird durch diesen Befehl @emph{nicht} neu
-installiert. Es wird also lediglich der bereits installierte Bootloader mit
-einer neuen Konfigurationsdatei benutzt werden.
-Die Zielgeneration kann ausdrücklich über ihre Generationsnummer angegeben
-werden. Zum Beispiel würde folgender Aufruf einen Wechsel zur
-Systemgeneration 7 bewirken:
-@example
-guix system switch-generation 7
-@end example
-Die Zielgeneration kann auch relativ zur aktuellen Generation angegeben
-werden, in der Form @code{+N} oder @code{-N}, wobei @code{+3} zum Beispiel
-»3 Generationen weiter als die aktuelle Generation« bedeuten würde und
-@code{-1} »1 Generation vor der aktuellen Generation« hieße. Wenn Sie einen
-negativen Wert wie @code{-1} angeben, müssen Sie @code{--} der
-Befehlszeilenoption voranstellen, damit die negative Zahl nicht selbst als
-Befehlszeilenoption aufgefasst wird. Zum Beispiel:
-@example
-guix system switch-generation -- -1
-@end example
-Zur Zeit bewirkt ein Aufruf dieser Aktion @emph{nur} einen Wechsel des
-Systemprofils auf eine bereits existierende Generation und ein Umordnen der
-Bootloader-Menüeinträge. Um die Ziel-Systemgeneration aber tatsächlich zu
-benutzen, müssen Sie Ihr System neu hochfahren, nachdem Sie diese Aktion
-ausgeführt haben. In einer zukünftigen Version von Guix wird diese Aktion
-einmal dieselben Dinge tun, wie @command{reconfigure}, also etwa Dienste
-aktivieren und deaktivieren.
-Diese Aktion schlägt fehl, wenn die angegebene Generation nicht existiert.
-@item roll-back
-@cindex rücksetzen
-Zur vorhergehenden Systemgeneration wechseln. Wenn das System das nächste
-Mal hochgefahren wird, wird es die vorhergehende Systemgeneration
-benutzen. Dies ist die Umkehrung von @command{reconfigure} und tut genau
-dasselbe, wie @command{switch-generation} mit dem Argument @code{-1}
-aufzurufen.
-Wie auch bei @command{switch-generation} müssen Sie derzeit, nachdem Sie
-diese Aktion aufgerufen haben, Ihr System neu starten, um die vorhergehende
-Systemgeneration auch tatsächlich zu benutzen.
-@item delete-generations
-@cindex Löschen von Systemgenerationen
-@cindex Platz sparen
-Systemgenerationen löschen, wodurch diese zu Kandidaten für den Müllsammler
-werden (siehe @ref{Aufruf von guix gc} für Informationen, wie Sie den
-»Müllsammler« laufen lassen).
-Es funktioniert auf die gleiche Weise wie @command{guix package
--delete-generations} (siehe @ref{Aufruf von guix package,
-@code{--delete-generations}}). Wenn keine Argumente angegeben werden, werden
-alle Systemgenerationen außer der aktuellen gelöscht:
-@example
-guix system delete-generations
-@end example
-Sie können auch eine Auswahl treffen, welche Generationen Sie löschen
-möchten. Das folgende Beispiel hat die Löschung aller Systemgenerationen zur
-Folge, die älter als zwei Monate sind:
-@example
-guix system delete-generations 2m
-@end example
-Wenn Sie diesen Befehl ausführen, wird automatisch der Bootloader mit einer
-aktualisierten Liste von Menüeinträgen neu erstellt — z.B.@: werden im
-Untermenü für die »alten Generationen« in GRUB die gelöschten Generationen
-nicht mehr aufgeführt.
-@item build
-Die Ableitung des Betriebssystems erstellen, einschließlich aller
-Konfigurationsdateien und Programme, die zum Booten und Starten benötigt
-werden. Diese Aktion installiert jedoch nichts davon.
-@item init
-In das angegebene Verzeichnis alle Dateien einfügen, um das in der
-@var{Datei} angegebene Betriebssystem starten zu können. Dies ist nützlich
-bei erstmaligen Installationen von »Guix System«. Zum Beispiel:
-@example
-guix system init my-os-config.scm /mnt
-@end example
-Hiermit werden alle Store-Objekte nach @file{/mnt} kopiert, die von der in
-@file{my-os-config.scm} angegebenen Konfiguration vorausgesetzt werden. Dazu
-gehören Konfigurationsdateien, Pakete und so weiter. Auch andere essenzielle
-Dateien, die auf dem System vorhanden sein müssen, damit es richtig
-funktioniert, werden erzeugt — z.B.@: die Verzeichnisse @file{/etc},
-@file{/var} und @file{/run} und die Datei @file{/bin/sh}.
-Dieser Befehl installiert auch den Bootloader auf dem in @file{my-os-config}
-angegebenen Ziel, außer die Befehlszeilenoption @option{--no-bootloader}
-wurde übergeben.
-@item vm
-@cindex virtuelle Maschine
-@cindex VM
-@anchor{guix system vm}
-Eine virtuelle Maschine (VM) erstellen, die das in der @var{Datei}
-deklarierte Betriebssystem enthält, und ein Skript liefern, das diese
-virtuelle Maschine startet.
-@quotation Anmerkung
-Die Aktion @code{vm} sowie solche, die weiter unten genannt werden, können
-KVM-Unterstützung im Kernel Linux-libre ausnutzen. Insbesondere sollte, wenn
-die Maschine Hardware-Virtualisierung unterstützt, das entsprechende
-KVM-Kernelmodul geladen sein und das Gerät @file{/dev/kvm} muss dann
-existieren und dem Benutzer und den Erstellungsbenutzern des Daemons müssen
-Berechtigungen zum Lesen und Schreiben darauf gegeben werden (siehe
-@ref{Einrichten der Erstellungsumgebung}).
-@end quotation
-An das Skript übergebene Argumente werden an QEMU weitergereicht, wie Sie am
-folgenden Beispiel sehen können. Damit würde eine Netzwerkverbindung
-aktiviert und 1@tie{}GiB an RAM für die emulierte Maschine angefragt:
-@example
-$ /gnu/store/@dots{}-run-vm.sh -m 1024 -net user
-@end example
-Die virtuelle Maschine verwendet denselben Store wie das Wirtssystem.
-Mit den Befehlszeilenoptionen @code{--share} und @code{--expose} können
-weitere Dateisysteme zwischen dem Wirtssystem und der VM geteilt werden: Der
-erste Befehl gibt ein mit Schreibzugriff zu teilendes Verzeichnis an,
-während der letzte Befehl nur Lesezugriff auf das gemeinsame Verzeichnis
-gestattet.
-Im folgenden Beispiel wird eine virtuelle Maschine erzeugt, die auf das
-Persönliche Verzeichnis des Benutzers nur Lesezugriff hat, wo das
-Verzeichnis @file{/austausch} aber mit Lese- und Schreibzugriff dem
-Verzeichnis @file{$HOME/tmp} auf dem Wirtssystem zugeordnet wurde:
-@example
-guix system vm my-config.scm \
-   --expose=$HOME --share=$HOME/tmp=/austausch
-@end example
-Für GNU/Linux ist das vorgegebene Verhalten, direkt in den Kernel zu booten,
-wodurch nur ein sehr winziges »Disk-Image« (eine Datei mit einem Abbild des
-Plattenspeichers der virtuellen Maschine) für das Wurzeldateisystem nötig
-wird, weil der Store des Wirtssystems davon eingebunden werden kann.
-Mit der Befehlszeilenoption @code{--full-boot} wird erzwungen, einen
-vollständigen Bootvorgang durchzuführen, angefangen mit dem
-Bootloader. Dadurch wird mehr Plattenplatz verbraucht, weil dazu ein
-Disk-Image mindestens mit dem Kernel, initrd und Bootloader-Datendateien
-erzeugt werden muss. Mit der Befehlszeilenoption @code{--image-size} kann
-die Größe des Disk-Images angegeben werden.
-@cindex System-Disk-Images, Erstellung in verschiedenen Formaten
-@cindex Erzeugen von System-Disk-Images in verschiedenen Formaten
-@item vm-image
-@itemx disk-image
-@itemx docker-image
-Ein eigenständiges Disk-Image für eine virtuelle Maschine, ein allgemeines
-Disk-Image oder ein Docker-Abbild für das in der @var{Datei} deklarierte
-Betriebssystem liefern. Das vorgegebene Verhalten von @command{guix system}
-ist, die Größe des Images zu schätzen, die zum Speichern des Systems
-benötigt wird, aber Sie können mit der Befehlszeilenoption
-@option{--image-size} selbst Ihre gewünschte Größe
-bestimmen. Docker-Abbilder werden aber so erstellt, dass sie gerade nur das
-enthalten, was für sie nötig ist, daher wird die Befehlszeilenoption
-@option{--image-size} im Fall von @code{docker-image} ignoriert.
-Sie können den Dateisystemtyp für das Wurzeldateisystem mit der
-Befehlszeilenoption @option{--file-system-type} festlegen. Vorgegeben ist,
-@code{ext4} zu verwenden.
-Wenn Sie ein @code{vm-image} anfordern, ist das gelieferte Disk-Image im
-qcow2-Format, was vom QEMU-Emulator effizient benutzt werden kann. Im
-Abschnitt @ref{Guix in einer VM starten} finden Sie mehr Informationen, wie Sie
-das Disk-Image in einer virtuellen Maschine laufen lassen.
-Wenn Sie ein @code{disk-image} anfordern, wird ein rohes Disk-Image
-hergestellt; es kann zum Beispiel auf einen USB-Stick kopiert
-werden. Angenommen @code{/dev/sdc} ist das dem USB-Stick entsprechende
-Gerät, dann kann das Disk-Image mit dem folgenden Befehls darauf kopiert
-werden:
-@example
-# dd if=$(guix system disk-image my-os.scm) of=/dev/sdc
-@end example
-Wenn Sie ein @code{docker-image} anfordern, wird ein Abbild für Docker
-hergestellt. Guix erstellt das Abbild von Grund auf und @emph{nicht} aus
-einem vorerstellten Docker-Basisabbild heraus, daher enthält es @emph{exakt}
-das, was Sie in der Konfigurationsdatei für das Betriebssystem angegeben
-haben. Sie können das Abbild dann wie folgt laden und einen Docker-Container
-damit erzeugen:
-@example
-image_id="$(docker load < guix-system-docker-image.tar.gz)"
-docker run -e GUIX_NEW_SYSTEM=/var/guix/profiles/system \\
-    --entrypoint /var/guix/profiles/system/profile/bin/guile \\
-    $image_id /var/guix/profiles/system/boot
-@end example
-Dieser Befehl startet einen neuen Docker-Container aus dem angegebenen
-Abbild. Damit wird das Guix-System auf die normale Weise hochgefahren,
-d.h.@: zunächst werden alle Dienste gestartet, die Sie in der Konfiguration
-des Betriebssystems angegeben haben. Je nachdem, was Sie im Docker-Container
-ausführen, kann es nötig sein, dass Sie ihn mit weitergehenden
-Berechtigungen ausstatten. Wenn Sie zum Beispiel Software mit Guix innerhalb
-des Docker-Containers erstellen wollen, müssen Sie an @code{docker run} die
-Befehlszeilenoption @option{--privileged} übergeben.
-@item container
-Liefert ein Skript, um das in der @var{Datei} deklarierte Betriebssystem in
-einem Container auszuführen. Mit Container wird hier eine Reihe
-ressourcenschonender Isolierungsmechanismen im Kernel Linux-libre
-bezeichnet. Container beanspruchen wesentlich weniger Ressourcen als
-vollumfängliche virtuelle Maschinen, weil der Kernel, Bibliotheken in
-gemeinsam nutzbaren Objektdateien (»Shared Objects«) sowie andere Ressourcen
-mit dem Wirtssystem geteilt werden können. Damit ist also eine »dünnere«
-Isolierung möglich.
-Zur Zeit muss das Skript als Administratornutzer »root« ausgeführt werden,
-damit darin mehr als nur ein einzelner Benutzer und eine Benutzergruppe
-unterstützt wird. Der Container teilt seinen Store mit dem Wirtssystem.
-Wie bei der Aktion @code{vm} (siehe @ref{guix system vm}) können zusätzlich
-weitere Dateisysteme zwischen Wirt und Container geteilt werden, indem man
-die Befehlszeilenoptionen @option{--share} und @option{--expose} verwendet:
-@example
-guix system container my-config.scm \
-   --expose=$HOME --share=$HOME/tmp=/austausch
-@end example
-@quotation Anmerkung
-Diese Befehlszeilenoption funktioniert nur mit Linux-libre 3.19 oder neuer.
-@end quotation
-@end table
-Unter den @var{Optionen} können beliebige gemeinsame Erstellungsoptionen
-aufgeführt werden (siehe @ref{Gemeinsame Erstellungsoptionen}). Des Weiteren kann als
-@var{Optionen} Folgendes angegeben werden:
-@table @option
-@item --expression=@var{Ausdruck}
-@itemx -e @var{Ausdruck}
-Als Konfiguration des Betriebssystems das »operating-system« betrachten, zu
-dem der @var{Ausdruck} ausgewertet wird. Dies ist eine Alternative dazu, die
-Konfiguration in einer Datei festzulegen. Hiermit wird auch das
-Installationsabbild des Guix-Systems erstellt, siehe @ref{Ein Abbild zur Installation erstellen}).
-@item --system=@var{System}
-@itemx -s @var{System}
-Versuche, für das angegebene @var{System} statt für denselben Systemtyp wie
-auf dem Wirtssystem zu erstellen. Dies funktioniert wie bei @command{guix
-build} (siehe @ref{Aufruf von guix build}).
-@item --derivation
-@itemx -d
-Liefert den Namen der Ableitungsdatei für das angegebene Betriebssystem,
-ohne dazu etwas zu erstellen.
-@item --file-system-type=@var{Typ}
-@itemx -t @var{Typ}
-Für die Aktion @code{disk-image} wird hiermit ein Dateisystem des
-angegebenen @var{Typ}s im Abbild bzw. Disk-Image erzeugt.
-Wird diese Befehlszeilenoption nicht angegeben, so benutzt @command{guix
-system} als Dateisystemtyp @code{ext4}.
-@cindex ISO-9660-Format
-@cindex CD-Abbild-Format
-@cindex DVD-Abbild-Format
-@code{--file-system-type=iso9660} erzeugt ein Abbild im Format ISO-9660, was
-für das Brennen auf CDs und DVDs geeignet ist.
-@item --image-size=@var{Größe}
-Für die Aktionen @code{vm-image} und @code{disk-image} wird hiermit
-festgelegt, dass ein Abbild der angegebenen @var{Größe} erstellt werden
-soll. Die @var{Größe} kann als Zahl die Anzahl Bytes angeben oder mit einer
-Einheit als Suffix versehen werden (siehe @ref{Block size, size
-specifications,, coreutils, GNU Coreutils}).
-Wird keine solche Befehlszeilenoption angegeben, berechnet @command{guix
-system} eine Schätzung der Abbildgröße anhand der Größe des in der
-@var{Datei} deklarierten Systems.
-@item --root=@var{Datei}
-@itemx -r @var{Datei}
-Die @var{Datei} zu einer symbolischen Verknüpfung auf das Ergebnis machen
-und als Müllsammlerwurzel registrieren.
-@item --skip-checks
-Die Konfiguration @emph{nicht} vor der Installation zur Sicherheit auf
-Fehler prüfen.
-Das vorgegebene Verhalten von @command{guix system init} und @command{guix
-system reconfigure} sieht vor, die Konfiguration zur Sicherheit auf Fehler
-hin zu überprüfen, die ihr Autor übersehen haben könnte: Es wird
-sichergestellt, dass die in der @code{operating-system}-Deklaration
-erwähnten Dateisysteme tatsächlich existieren (siehe @ref{Dateisysteme}) und
-dass alle Linux-Kernelmodule, die beim Booten benötigt werden könnten, auch
-im @code{initrd-modules}-Feld aufgeführt sind (siehe @ref{Initiale RAM-Disk}). Mit dieser Befehlszeilenoption werden diese Tests allesamt
-übersprungen.
-@cindex on-error
-@cindex on-error-Strategie
-@cindex Fehlerstrategie
-@item --on-error=@var{Strategie}
-Beim Auftreten eines Fehlers beim Einlesen der @var{Datei} die angegebene
-@var{Strategie} verfolgen. Als @var{Strategie} dient eine der Folgenden:
-@table @code
-@item nothing-special
-Nichts besonderes; der Fehler wird kurz gemeldet und der Vorgang
-abgebrochen. Dies ist die vorgegebene Strategie.
-@item backtrace
-Ebenso, aber zusätzlich wird eine Rückverfolgung des Fehlers (ein
-»Backtrace«) angezeigt.
-@item debug
-Nach dem Melden des Fehlers wird der Debugger von Guile zur Fehlersuche
-gestartet. Von dort können Sie Befehle ausführen, zum Beispiel können Sie
-sich mit @code{,bt} eine Rückverfolgung (»Backtrace«) anzeigen lassen und
-mit @code{,locals} die Werte lokaler Variabler anzeigen lassen. Im
-Allgemeinen können Sie mit Befehlen den Zustand des Programms
-inspizieren. Siehe @ref{Debug Commands,,, guile, GNU Guile Reference Manual}
-für eine Liste verfügbarer Befehle zur Fehlersuche.
-@end table
-@end table
-Sobald Sie Ihre Guix-Installation erstellt, konfiguriert, neu konfiguriert
-und nochmals neu konfiguriert haben, finden Sie es vielleicht hilfreich,
-sich die auf der Platte verfügbaren — und im Bootmenü des Bootloaders
-auswählbaren — Systemgenerationen auflisten zu lassen:
-@table @code
-@item list-generations
-Eine für Menschen verständliche Zusammenfassung jeder auf der Platte
-verfügbaren Generation des Betriebssystems ausgeben. Dies ähnelt der
-Befehlszeilenoption @option{--list-generations} von @command{guix package}
-(siehe @ref{Aufruf von guix package}).
-Optional kann ein Muster angegeben werden, was dieselbe Syntax wie
-@command{guix package --list-generations} benutzt, um damit die Liste
-anzuzeigender Generationen einzuschränken. Zum Beispiel zeigt der folgende
-Befehl Generationen an, die bis zu 10 Tage alt sind:
-@example
-$ guix system list-generations 10d
-@end example
-@end table
-Der Befehl @command{guix system} hat sogar noch mehr zu bieten! Mit
-folgenden Unterbefehlen wird Ihnen visualisiert, wie Ihre Systemdienste
-voneinander abhängen:
-@anchor{system-extension-graph}
-@table @code
-@item extension-graph
-Im Dot-/Graphviz-Format auf die Standardausgabe den
-@dfn{Diensterweiterungsgraphen} des in der @var{Datei} definierten
-Betriebssystems ausgeben (siehe @ref{Dienstkompositionen} für mehr
-Informationen zu Diensterweiterungen).
-Der Befehl:
-@example
-$ guix system extension-graph @var{file} | dot -Tpdf > services.pdf
-@end example
-erzeugt eine PDF-Datei, in der die Erweiterungsrelation unter Diensten
-angezeigt wird.
-@anchor{system-shepherd-graph}
-@item shepherd-graph
-Im Dot-/Graphviz-Format auf die Standardausgabe den
-@dfn{Abhängigkeitsgraphen} der Shepherd-Dienste des in der @var{Datei}
-definierten Betriebssystems ausgeben. Siehe @ref{Shepherd-Dienste} für mehr
-Informationen sowie einen Beispielgraphen.
-@end table
-@node Guix in einer VM starten
-@section Guix in einer virtuellen Maschine betreiben
-@cindex virtuelle Maschine
-Um Guix in einer virtuellen Maschine (VM) auszuführen, können Sie entweder
-das vorerstellte Guix-VM-Abbild benutzen, das auf
-@indicateurl{https://alpha.gnu.org/gnu/guix/guix-system-vm-image-@value{VERSION}.@var{System}.xz}
-angeboten wird, oder Ihr eigenes Abbild erstellen, indem Sie @command{guix
-system vm-image} benutzen (siehe @ref{Aufruf von guix system}). Das Abbild
-wird im qcow2-Format zurückgeliefert, das der @uref{http://qemu.org/,
-QEMU-Emulator} effizient benutzen kann.
-@cindex QEMU
-Wenn Sie Ihr eigenes Abbild erstellen haben lassen, müssen Sie es aus dem
-Store herauskopieren (siehe @ref{Der Store}) und sich darauf
-Schreibberechtigung geben, um die Kopie benutzen zu können. Wenn Sie QEMU
-aufrufen, müssen Sie einen Systememulator angeben, der für Ihre
-Hardware-Plattform passend ist. Hier ist ein minimaler QEMU-Aufruf, der das
-Ergebnis von @command{guix system vm-image} auf x86_64-Hardware bootet:
-@example
-$ qemu-system-x86_64 \
-   -net user -net nic,model=virtio \
-   -enable-kvm -m 256 /tmp/qemu-image
-@end example
-Die Bedeutung jeder dieser Befehlszeilenoptionen ist folgende:
-@table @code
-@item qemu-system-x86_64
-Hiermit wird die zu emulierende Hardware-Plattform angegeben. Sie sollte zum
-Wirtsrechner passen.
-@item -net user
-Den als Nutzer ausgeführten Netzwerkstapel (»User-Mode Network Stack«) ohne
-besondere Berechtigungen benutzen. Mit dieser Art von Netzwerkanbindung kann
-das Gast-Betriebssystem eine Verbindung zum Wirt aufbauen, aber nicht
-andersherum. Es ist die einfachste Art, das Gast-Betriebssystem mit dem
-Internet zu verbinden.
-@item -net nic,model=virtio
-Sie müssen ein Modell einer zu emulierenden Netzwerkschnittstelle
-angeben. Wenn Sie keine Netzwerkkarte (englisch »Network Interface Card«,
-kurz NIC) erzeugen lassen, wird das Booten fehlschlagen. Falls Ihre
-Hardware-Plattform x86_64 ist, können Sie eine Liste verfügbarer NIC-Modelle
-einsehen, indem Sie @command{qemu-system-x86_64 -net nic,model=help}
-ausführen.
-@item -enable-kvm
-Wenn Ihr System über Erweiterungen zur Hardware-Virtualisierung verfügt,
-beschleunigt es die Dinge, wenn Sie die Virtualisierungsunterstützung »KVM«
-des Linux-Kernels benutzen lassen.
-@item -m 256
-Die Menge an Arbeitsspeicher (RAM), die dem Gastbetriebssystem zur Verfügung
-stehen soll, in Mebibytes. Vorgegeben wären 128@tie{}MiB, was für einige
-Operationen zu wenig sein könnte.
-@item /tmp/qemu-image
-Der Dateiname des qcow2-Abbilds.
-@end table
-Das voreingestellte @command{run-vm.sh}-Skript, das durch einen Aufruf von
-@command{guix system vm} erzeugt wird, fügt keine Befehlszeilenoption
-@command{-net user} an. Um innerhalb der virtuellen Maschine Netzwerkzugang
-zu haben, fügen Sie den @code{(dhcp-client-service)} zu Ihrer
-Systemdefinition hinzu und starten Sie die VM mit @command{`guix system vm
-config.scm` -net user}. Erwähnt werden sollte der Nachteil, dass bei
-Verwendung von @command{-net user} zur Netzanbindung der
-@command{ping}-Befehl @emph{nicht} funktionieren wird, weil dieser das
-ICMP-Protokoll braucht. Sie werden also einen anderen Befehl benutzen
-müssen, um auszuprobieren, ob Sie mit dem Netzwerk verbunden sind, zum
-Beispiel @command{guix download}.
-@subsection Verbinden über SSH
-@cindex SSH
-@cindex SSH server
-Um SSH in der virtuellen Maschine zu aktivieren, müssen Sie einen SSH-Server
-wie den @code{(dropbear-service)} oder den @code{(lsh-service)} zu ihr
-hinzufügen. Der @code{(lsh-service}) kann derzeit nicht ohne
-Benutzerinteraktion starten, weil der Benutzer erst ein paar Zeichen
-eintippen muss, um den Zufallsgenerator zu initialisieren. Des Weiteren
-müssen Sie den SSH-Port für das Wirtssystem freigeben (standardmäßig hat er
-die Portnummer 22). Das geht zum Beispiel so:
-@example
-`guix system vm config.scm` -net user,hostfwd=tcp::10022-:22
-@end example
-Um sich mit der virtuellen Maschine zu verbinden, benutzen Sie diesen
-Befehl:
-@example
-ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022
-@end example
-Mit @command{-p} wird @command{ssh} der Port mitgeteilt, über den eine
-Verbindung hergestellt werden soll. @command{-o
-UserKnownHostsFile=/dev/null} verhindert, dass @command{ssh} sich bei jeder
-Modifikation Ihrer @command{config.scm}-Datei beschwert, ein anderer
-bekannter Rechner sei erwartet worden, und @command{-o
-StrictHostKeyChecking=no} verhindert, dass Sie die Verbindung zu unbekannten
-Rechnern jedes Mal bestätigen müssen, wenn Sie sich verbinden.
-@subsection @command{virt-viewer} mit Spice benutzen
-Eine Alternative zur grafischen Schnittstelle des standardmäßigen
-@command{qemu} ist, sich mit Hilfe des @command{remote-viewer} aus dem Paket
-@command{virt-viewer} zu verbinden. Um eine Verbindung herzustellen,
-übergeben Sie die Befehlszeilenoption @command{-spice
-port=5930,disable-ticketing} an @command{qemu}. Siehe den vorherigen
-Abschnitt für weitere Informationen, wie Sie das übergeben.
-Spice macht es auch möglich, ein paar nette Hilfestellungen zu benutzen, zum
-Beispiel können Sie Ihren Zwischenspeicher zum Kopieren und Einfügen (Ihr
-»Clipboard«) mit Ihrer virtuellen Maschine teilen. Um das zu aktivieren,
-werden Sie die folgenden Befehlszeilennoptionen zusätzlich an @command{qemu}
-übergeben müssen:
-@example
-device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5
-chardev spicevmc,name=vdagent,id=vdagent
-device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,
-name=com.redhat.spice.0
-@end example
-Sie werden auch den @ref{Verschiedene Dienste, Spice-Dienst} hinzufügen
-müssen.
-@node Dienste definieren
-@section Dienste definieren
-Der vorhergehende Abschnitt präsentiert die verfügbaren Dienste und wie man
-sie in einer @code{operating-system}-Deklaration kombiniert. Aber wie
-definieren wir solche Dienste eigentlich? Und was ist überhaupt ein Dienst?
-@menu
-* Dienstkompositionen::      Wie Dienste zusammengestellt werden.
-* Diensttypen und Dienste::  Typen und Dienste.
-* Service-Referenz::         Referenz zur Programmierschnittstelle.
-* Shepherd-Dienste::         Eine spezielle Art von Dienst.
-@end menu
-@node Dienstkompositionen
-@subsection Dienstkompositionen
-@cindex services
-@cindex Daemons
-Wir definieren hier einen @dfn{Dienst} (englisch »Service«) als, grob
-gesagt, etwas, das die Funktionalität des Betriebssystems erweitert. Oft ist
-ein Dienst ein Prozess — ein sogenannter @dfn{Daemon} —, der beim Hochfahren
-des Systems gestartet wird: ein Secure-Shell-Server, ein Web-Server, der
-Guix-Erstellungsdaemon usw. Manchmal ist ein Dienst ein Daemon, dessen
-Ausführung von einem anderen Daemon ausgelöst wird — zum Beispiel wird ein
-FTP-Server von @command{inetd} gestartet oder ein D-Bus-Dienst durch
-@command{dbus-daemon} aktiviert. Manchmal entspricht ein Dienst aber auch
-keinem Daemon. Zum Beispiel nimmt sich der Benutzerkonten-Dienst (»account
-service«) die Benutzerkonten und sorgt dafür, dass sie existieren, wenn das
-System läuft. Der »udev«-Dienst sammelt die Regeln zur Geräteverwaltung an
-und macht diese für den eudev-Daemon verfügbar. Der @file{/etc}-Dienst fügt
-Dateien in das Verzeichnis @file{/etc} des Systems ein.
-@cindex Diensterweiterungen
-Dienste des Guix-Systems werden durch @dfn{Erweiterungen} (»Extensions«)
-miteinander verbunden. Zum Beispiel @emph{erweitert} der Secure-Shell-Dienst
-den Shepherd — Shepherd ist das Initialisierungssystem (auch »init«-System
-genannt), was als PID@tie{}1 läuft —, indem es ihm die Befehlszeilen zum
-Starten und Stoppen des Secure-Shell-Daemons übergibt (siehe @ref{Netzwerkdienste, @code{openssh-service-type}}). Der UPower-Dienst erweitert den
-D-Bus-Dienst, indem es ihm seine @file{.service}-Spezifikation übergibt, und
-erweitert den udev-Dienst, indem es ihm Geräteverwaltungsregeln übergibt
-(siehe @ref{Desktop-Dienste, @code{upower-service}}). Der
-Guix-Daemon-Dienst erweitert den Shepherd, indem er ihm die Befehlszeilen
-zum Starten und Stoppen des Daemons übergibt, und er erweitert den
-Benutzerkontendienst (»account service«), indem er ihm eine Liste der
-benötigten Erstellungsbenutzerkonten übergibt (siehe @ref{Basisdienste}).
-Alles in allem bilden Dienste und ihre »Erweitert«-Relationen einen
-gerichteten azyklischen Graphen (englisch »Directed Acyclic Graph«, kurz
-DAG). Wenn wir Dienste als Kästen und Erweiterungen als Pfeile darstellen,
-könnte ein typisches System so etwas hier anbieten:
-@image{images/service-graph,,5in,Typischer Diensterweiterungsgraph}
-@cindex Systemdienst
-Ganz unten sehen wir den @dfn{Systemdienst}, der das Verzeichnis erzeugt, in
-dem alles zum Ausführen und Hochfahren enthalten ist, so wie es der Befehl
-@command{guix system build} liefert. Siehe @ref{Service-Referenz}, um mehr
-über die anderen hier gezeigten Diensttypen zu erfahren. Beim
-@ref{system-extension-graph, Befehl @command{guix system extension-graph}}
-finden Sie Informationen darüber, wie Sie diese Darstellung für eine
-Betriebssystemdefinition Ihrer Wahl generieren lassen.
-@cindex Diensttypen
-Technisch funktioniert es so, dass Entwickler @dfn{Diensttypen} definieren
-können, um diese Beziehungen auszudrücken. Im System kann es beliebig viele
-Dienste zu jedem Typ geben — zum Beispiel können auf einem System zwei
-Instanzen des GNU-Secure-Shell-Servers (lsh) laufen, mit zwei Instanzen des
-Diensttyps @code{lsh-service-type} mit je unterschiedlichen Parametern.
-Der folgende Abschnitt beschreibt die Programmierschnittstelle für
-Diensttypen und Dienste.
-@node Diensttypen und Dienste
-@subsection Diensttypen und Dienste
-Ein @dfn{Diensttyp} (»service type«) ist ein Knoten im oben beschriebenen
-ungerichteten azyklischen Graphen (DAG). Fangen wir an mit einem einfachen
-Beispiel: dem Diensttyp für den Guix-Erstellungsdaemon (siehe @ref{Aufruf des guix-daemon}):
-@example
-(define guix-service-type
-  (service-type
-   (name 'guix)
-   (extensions
-    (list (service-extension shepherd-root-service-type guix-shepherd-service)
-          (service-extension account-service-type guix-accounts)
-          (service-extension activation-service-type guix-activation)))
-   (default-value (guix-configuration))))
-@end example
-@noindent
-Damit sind drei Dinge definiert:
-@enumerate
-@item
-Ein Name, der nur dazu da ist, dass man leichter die Abläufe verstehen und
-Fehler suchen kann.
-@item
-Eine Liste von @dfn{Diensterweiterungen} (»service extensions«). Jede
-Erweiterung gibt den Ziel-Diensttyp an sowie eine Prozedur, die für gegebene
-Parameter für den Dienst eine Liste von Objekten zurückliefert, um den
-Dienst dieses Typs zu erweitern.
-Jeder Diensttyp benutzt mindestens eine Diensterweiterung. Die einzige
-Ausnahme ist der @dfn{boot service type}, der die Grundlage aller Dienste
-ist.
-@item
-Optional kann ein Vorgabewert für Instanzen dieses Typs angegeben werden.
-@end enumerate
-In this example, @code{guix-service-type} extends three services:
-@table @code
-@item shepherd-root-service-type
-The @code{guix-shepherd-service} procedure defines how the Shepherd service
-is extended.  Namely, it returns a @code{<shepherd-service>} object that
-defines how @command{guix-daemon} is started and stopped (@pxref{Shepherd-Dienste}).
-@item account-service-type
-This extension for this service is computed by @code{guix-accounts}, which
-returns a list of @code{user-group} and @code{user-account} objects
-representing the build user accounts (@pxref{Aufruf des guix-daemon}).
-@item activation-service-type
-Here @code{guix-activation} is a procedure that returns a gexp, which is a
-code snippet to run at ``activation time''---e.g., when the service is
-booted.
-@end table
-Ein Dienst dieses Typs wird dann so instanziiert:
-@example
-(service guix-service-type
-         (guix-configuration
-           (build-accounts 5)
-           (use-substitutes? #f)))
-@end example
-Das zweite Argument an die @code{service}-Form ist ein Wert, der die
-Parameter dieser bestimmten Dienstinstanz repräsentiert. Siehe
-@ref{guix-configuration-type, @code{guix-configuration}} für Informationen
-über den @code{guix-configuration}-Datentyp. Wird kein Wert angegeben, wird
-die Vorgabe verwendet, die im @code{guix-service-type} angegeben wurde:
-@example
-(service guix-service-type)
-@end example
-@code{guix-service-type} is quite simple because it extends other services
-but is not extensible itself.
-@c @subsubsubsection Extensible Service Types
-Der Diensttyp eines @emph{erweiterbaren} Dienstes sieht ungefähr so aus:
-@example
-(define udev-service-type
-  (service-type (name 'udev)
-                (extensions
-                 (list (service-extension shepherd-root-service-type
-                                          udev-shepherd-service)))
-                (compose concatenate)     ;Liste der Regeln zusammenfügen
-                (extend (lambda (config rules) ;Konfiguration und Regeln
-                          (match config
-                            (($ <udev-configuration> udev initial-rules)
-                             (udev-configuration
-                              (udev udev) ;zu benutzendes udev-Paket
-                              (rules (append initial-rules rules)))))))))
-@end example
-This is the service type for the
-@uref{https://wiki.gentoo.org/wiki/Project:Eudev, eudev device management
-daemon}.  Compared to the previous example, in addition to an extension of
-@code{shepherd-root-service-type}, we see two new fields:
-@table @code
-@item compose
-Die Prozedur, um die Liste der jeweiligen Erweiterungen für den Dienst
-dieses Typs zu einem Objekt zusammenzustellen (zu »komponieren«, englisch
-@dfn{compose}).
-Dienste können den udev-Dienst erweitern, indem sie eine Liste von Regeln
-(»Rules«) an ihn übergeben; wir komponieren mehrere solche Erweiterungen,
-indem wir die Listen einfach zusammenfügen.
-@item extend
-Diese Prozedur definiert, wie der Wert des Dienstes um die Komposition mit
-Erweiterungen erweitert (»extended«) werden kann.
-Udev-Erweiterungen werden zu einer einzigen Liste von Regeln komponiert,
-aber der Wert des udev-Dienstes ist ein
-@code{<udev-configuration>}-Verbundsobjekt. Deshalb erweitern wir diesen
-Verbund, indem wir die Liste der von Erweiterungen beigetragenen Regeln an
-die im Verbund gespeicherte Liste der Regeln anhängen.
-@item description
-Diese Zeichenkette gibt einen Überblick über den Systemtyp. Die Zeichenkette
-darf mit Texinfo ausgezeichnet werden (siehe @ref{Overview,,, texinfo, GNU
-Texinfo}). Der Befehl @command{guix system search} durchsucht diese
-Zeichenketten und zeigt sie an (siehe @ref{Aufruf von guix system}).
-@end table
-There can be only one instance of an extensible service type such as
-@code{udev-service-type}.  If there were more, the @code{service-extension}
-specifications would be ambiguous.
-Sind Sie noch da? Der nächste Abschnitt gibt Ihnen eine Referenz der
-Programmierschnittstelle für Dienste.
-@node Service-Referenz
-@subsection Service-Referenz
-Wir haben bereits einen Überblick über Diensttypen gesehen (siehe
-@ref{Diensttypen und Dienste}). Dieser Abschnitt hier stellt eine
-Referenz dar, wie Dienste und Diensttypen manipuliert werden können. Diese
-Schnittstelle wird vom Modul @code{(gnu services)} angeboten.
-@deffn {Scheme-Prozedur} service @var{Typ} [@var{Wert}]
-Liefert einen neuen Dienst des angegebenen @var{Typ}s. Der @var{Typ} muss
-als @code{<service-type>}-Objekt angegeben werden (siehe unten). Als
-@var{Wert} kann ein beliebiges Objekt angegeben werden, das die Parameter
-dieser bestimmten Instanz dieses Dienstes repräsentiert.
-Wenn kein @var{Wert} angegeben wird, wird der vom @var{Typ} festgelegte
-Vorgabewert verwendet; verfügt der @var{Typ} über keinen Vorgabewert, dann
-wird ein Fehler gemeldet.
-Zum Beispiel bewirken Sie hiermit:
-@example
-(service openssh-service-type)
-@end example
-@noindent
-dasselbe wie mit:
-@example
-(service openssh-service-type
-         (openssh-configuration))
-@end example
-In beiden Fällen ist das Ergebnis eine Instanz von
-@code{openssh-service-type} mit der vorgegebenen Konfiguration.
-@end deffn
-@deffn {Scheme-Prozedur} service? @var{Objekt}
-Liefert wahr zurück, wenn das @var{Objekt} ein Dienst ist.
-@end deffn
-@deffn {Scheme-Prozedur} service-kind @var{Dienst}
-Liefert den Typ des @var{Dienst}es — d.h.@: ein
-@code{<service-type>}-Objekt.
-@end deffn
-@deffn {Scheme-Prozedur} service-value @var{Dienst}
-Liefert den Wert, der mit dem @var{Dienst} assoziiert wurde. Er
-repräsentiert die Parameter des @var{Dienst}es.
-@end deffn
-Hier ist ein Beispiel, wie ein Dienst erzeugt und manipuliert werden kann:
-@example
-(define s
-  (service nginx-service-type
-           (nginx-configuration
-            (nginx nginx)
-            (log-directory log-Verzeichnis)
-            (run-directory run-Verzeichnis)
-            (file config-Datei))))
-(service? s)
-@result{} #t
-(eq? (service-kind s) nginx-service-type)
-@result{} #t
-@end example
-The @code{modify-services} form provides a handy way to change the
-parameters of some of the services of a list such as @code{%base-services}
-(@pxref{Basisdienste, @code{%base-services}}).  It evaluates to a list of
-services.  Of course, you could always use standard list combinators such as
-@code{map} and @code{fold} to do that (@pxref{SRFI-1, List Library,, guile,
-GNU Guile Reference Manual}); @code{modify-services} simply provides a more
-concise form for this common pattern.
-@deffn {Scheme-Syntax} modify-services @var{Dienste} @
-  (@var{Typ} @var{Variable} => @var{Rumpf}) @dots{}
-Passt die von @var{Dienste} bezeichnete Dienst-Liste entsprechend den
-angegebenen Klauseln an. Jede Klausel hat die Form:
-@example
-(@var{Typ} @var{Variable} => @var{Rumpf})
-@end example
-wobei @var{Typ} einen Diensttyp (»service type«) bezeichnet — wie zum
-Beispiel @code{guix-service-type} — und @var{Variable} ein Bezeichner ist,
-der im @var{Rumpf} an die Dienst-Parameter — z.B.@: eine
-@code{guix-configuration}-Instanz — des ursprünglichen Dienstes mit diesem
-@var{Typ} gebunden wird.
-Der @var{Rumpf} muss zu den neuen Dienst-Parametern ausgewertet werden,
-welche benutzt werden, um den neuen Dienst zu konfigurieren. Dieser neue
-Dienst wird das Original in der resultierenden Liste ersetzen. Weil die
-Dienstparameter eines Dienstes mit @code{define-record-type*} erzeugt
-werden, können Sie einen kurzen @var{Rumpf} schreiben, der zu den neuen
-Dienstparametern ausgewertet wird, indem Sie die Funktionalität namens
-@code{inherit} benutzen, die von @code{define-record-type*} bereitgestellt
-wird.
-Siehe @ref{Das Konfigurationssystem nutzen} für ein Anwendungsbeispiel.
-@end deffn
-Als Nächstes ist die Programmierschnittstelle für Diensttypen an der
-Reihe. Sie ist etwas, was Sie kennen werden wollen, wenn Sie neue
-Dienstdefinitionen schreiben, aber wenn Sie nur Ihre
-@code{operating-system}-Deklaration anpassen möchten, brauchen Sie diese
-Schnittstelle wahrscheinlich nicht.
-@deftp {Datentyp} service-type
-@cindex Diensttyp
-Die Repräsentation eines @dfn{Diensttypen} (siehe @ref{Diensttypen und Dienste}).
-@table @asis
-@item @code{name}
-Dieses Symbol wird nur verwendet, um die Abläufe im System anzuzeigen und
-die Fehlersuche zu erleichtern.
-@item @code{extensions}
-Eine nicht-leere Liste von @code{<service-extension>}-Objekten (siehe
-unten).
-@item @code{compose} (Vorgabe: @code{#f})
-Wenn es auf @code{#f} gesetzt ist, dann definiert der Diensttyp Dienste, die
-nicht erweitert werden können — d.h.@: diese Dienste erhalten ihren Wert
-nicht von anderen Diensten.
-Andernfalls muss es eine Prozedur sein, die ein einziges Argument
-entgegennimmt. Die Prozedur wird durch @code{fold-services} aufgerufen und
-ihr wird die Liste von aus den Erweiterungen angesammelten Werten
-übergeben. Sie gibt daraufhin einen einzelnen Wert zurück.
-@item @code{extend} (Vorgabe: @code{#f})
-Ist dies auf @code{#f} gesetzt, dann können Dienste dieses Typs nicht
-erweitert werden.
-Andernfalls muss es eine zwei Argumente nehmende Prozedur sein, die von
-@code{fold-services} mit dem anfänglichen Wert für den Dienst als erstes
-Argument und dem durch Anwendung von @code{compose} gelieferten Wert als
-zweites Argument aufgerufen wird. Als Ergebnis muss ein Wert geliefert
-werden, der einen zulässigen neuen Parameterwert für die Dienstinstanz
-darstellt.
-@end table
-Siehe den Abschnitt @ref{Diensttypen und Dienste} für Beispiele.
-@end deftp
-@deffn {Scheme-Prozedur} service-extension @var{Zieltyp} @
-                              @var{Berechner} Liefert eine neue Erweiterung für den Dienst mit dem
-@var{Zieltyp}. Als @var{Berechner} muss eine Prozedur angegeben werden, die
-ein einzelnes Argument nimmt: @code{fold-services} ruft sie auf und übergibt
-an sie den Wert des erweiternden Dienstes, sie muss dafür einen zulässigen
-Wert für den @var{Zieltyp} liefern.
-@end deffn
-@deffn {Scheme-Prozedur} service-extension? @var{Objekt}
-Liefert wahr zurück, wenn das @var{Objekt} eine Diensterweiterung ist.
-@end deffn
-Manchmal wollen Sie vielleicht einfach nur einen bestehenden Dienst
-erweitern. Dazu müssten Sie einen neuen Diensttyp definieren und die
-Erweiterung definieren, für die Sie sich interessieren, was ganz schön
-wortreich werden kann. Mit der Prozedur @code{simple-service} können Sie es
-kürzer fassen.
-@deffn {Scheme-Prozedur} simple-service @var{Name} @var{Zieltyp} @var{Wert}
-Liefert einen Dienst, der den Dienst mit dem @var{Zieltyp} um den @var{Wert}
-erweitert. Dazu wird ein Diensttyp mit dem @var{Name}n für den einmaligen
-Gebrauch erzeugt, den der zurückgelieferte Dienst instanziiert.
-Zum Beispiel kann mcron (siehe @ref{Geplante Auftragsausführung}) so um einen
-zusätzlichen Auftrag erweitert werden:
-@example
-(simple-service 'my-mcron-job mcron-service-type
-                #~(job '(next-hour (3)) "guix gc -F 2G"))
-@end example
-@end deffn
-Den Kern dieses abstrakten Modells für Dienste bildet die Prozedur
-@code{fold-services}, die für das »Kompilieren« einer Liste von Diensten hin
-zu einem einzelnen Verzeichnis verantwortlich ist, in welchem alles
-enthalten ist, was Sie zum Booten und Hochfahren des Systems brauchen —
-d.h.@: das Verzeichnis, das der Befehl @command{guix system build} anzeigt
-(siehe @ref{Aufruf von guix system}). Einfach ausgedrückt propagiert
-@code{fold-services} Diensterweiterungen durch den Dienstgraphen nach unten
-und aktualisiert dabei in jedem Knoten des Graphen dessen Parameter, bis nur
-noch der Wurzelknoten übrig bleibt.
-@deffn {Scheme-Prozedur} fold-services @var{Dienste} @
-                            [#:target-type @var{system-service-type}] Faltet die @var{Dienste} wie die
-funktionale Prozedur @code{fold} zu einem einzigen zusammen, indem ihre
-Erweiterungen nach unten propagiert werden, bis eine Wurzel vom
-@var{target-type} als Diensttyp erreicht wird; dieser so angepasste
-Wurzeldienst wird zurückgeliefert.
-@end deffn
-Als Letztes definiert das Modul @code{(gnu services)} noch mehrere
-essenzielle Diensttypen, von denen manche im Folgenden aufgelistet sind:
-@defvr {Scheme-Variable} system-service-type
-Die Wurzel des Dienstgraphen. Davon wird das Systemverzeichnis erzeugt, wie
-es vom Befehl @command{guix system build} zurückgeliefert wird.
-@end defvr
-@defvr {Scheme-Variable} boot-service-type
-Der Typ des »Boot-Dienstes«, der das @dfn{Boot-Skript} erzeugt. Das
-Boot-Skript ist das, was beim Booten durch die initiale RAM-Disk ausgeführt
-wird.
-@end defvr
-@defvr {Scheme-Variable} etc-service-type
-Der Typ des @file{/etc}-Dienstes. Dieser Dienst wird benutzt, um im
-@file{/etc}-Verzeichnis Dateien zu platzieren. Er kann erweitert werden,
-indem man Name-/Datei-Tupel an ihn übergibt wie in diesem Beispiel:
-@example
-(list `("issue" ,(plain-file "issue" "Willkommen!\n")))
-@end example
-Dieses Beispiel würde bewirken, dass eine Datei @file{/etc/issue} auf die
-angegebene Datei verweist.
-@end defvr
-@defvr {Scheme-Variable} setuid-program-service-type
-Der Typ des Dienstes für setuid-Programme, der eine Liste von ausführbaren
-Dateien ansammelt, die jeweils als G-Ausdrücke übergeben werden und dann zur
-Menge der setuid-gesetzten Programme auf dem System hinzugefügt werden
-(siehe @ref{Setuid-Programme}).
-@end defvr
-@defvr {Scheme-Variable} profile-service-type
-Der Typ des Dienstes zum Einfügen von Dateien ins @dfn{Systemprofil} —
-d.h.@: die Programme unter @file{/run/current-system/profile}. Andere
-Dienste können ihn erweitern, indem sie ihm Listen von ins Systemprofil zu
-installierenden Paketen übergeben.
-@end defvr
-@node Shepherd-Dienste
-@subsection Shepherd-Dienste
-@cindex Shepherd-Dienste
-@cindex PID 1
-@cindex init-System
-Das Modul @code{(gnu services shepherd)} gibt eine Methode an, mit der
-Dienste definiert werden können, die von GNU@tie{}Shepherd verwaltet werden,
-was das Initialisierungssystem (das »init«-System) ist — es ist der erste
-Prozess, der gestartet wird, wenn das System gebootet wird, auch bekannt als
-PID@tie{}1 (siehe @ref{Einführung,,, shepherd, The GNU Shepherd Manual}).
-Dienste unter dem Shepherd können voneinander abhängen. Zum Beispiel kann es
-sein, dass der SSH-Daemon erst gestartet werden darf, nachdem der
-Syslog-Daemon gestartet wurde, welcher wiederum erst gestartet werden kann,
-sobald alle Dateisysteme eingebunden wurden. Das einfache Betriebssystem,
-dessen Definition wir zuvor gesehen haben (siehe @ref{Das Konfigurationssystem nutzen}), ergibt folgenden Dienstgraphen:
-@image{images/shepherd-graph,,5in,Typischer Shepherd-Dienstgraph}
-Sie können so einen Graphen tatsächlich für jedes Betriebssystem erzeugen
-lassen, indem Sie den Befehl @command{guix system shepherd-graph} benutzen
-(siehe @ref{system-shepherd-graph, @command{guix system shepherd-graph}}).
-The @code{%shepherd-root-service} is a service object representing
-PID@tie{}1, of type @code{shepherd-root-service-type}; it can be extended by
-passing it lists of @code{<shepherd-service>} objects.
-@deftp {Datentyp} shepherd-service
-Der Datentyp, der einen von Shepherd verwalteten Dienst repräsentiert.
-@table @asis
-@item @code{provision}
-Diese Liste von Symbolen gibt an, was vom Dienst angeboten wird.
-Das bedeutet, es sind die Namen, die an @command{herd start}, @command{herd
-status} und ähnliche Befehle übergeben werden können (siehe @ref{Invoking
-herd,,, shepherd, The GNU Shepherd Manual}). Siehe @ref{Slots of services,
-the @code{provides} slot,, shepherd, The GNU Shepherd Manual} für Details.
-@item @code{requirements} (Vorgabe: @code{'()})
-Eine Liste von Symbolen, die angegeben, von welchen anderen
-Shepherd-Diensten dieser hier abhängt.
-@item @code{respawn?} (Vorgabe: @code{#t})
-Ob der Dienst neu gestartet werden soll, nachdem er gestoppt wurde, zum
-Beispiel wenn der ihm zu Grunde liegende Prozess terminiert wird.
-@item @code{start}
-@itemx @code{stop} (Vorgabe: @code{#~(const #f)})
-Die Felder @code{start} und @code{stop} beziehen sich auf Shepherds
-Funktionen zum Starten und Stoppen von Prozessen (siehe @ref{Service De- and
-Constructors,,, shepherd, The GNU Shepherd Manual}). Sie enthalten
-G-Ausdrücke, die in eine Shepherd-Konfigurationdatei umgeschrieben werden
-(siehe @ref{G-Ausdrücke}).
-@item @code{actions} (Vorgabe: @code{'()})
-@cindex Aktionen, bei Shepherd-Diensten
-Dies ist eine Liste von @code{shepherd-action}-Objekten (siehe unten), die
-vom Dienst zusätzlich unterstützte @dfn{Aktionen} neben den Standardaktionen
-@code{start} und @code{stop} angeben. Hier aufgeführte Aktionen werden als
-@command{herd}-Unterbefehle verfügbar gemacht:
-@example
-herd @var{Aktion} @var{Dienst} [@var{Argumente}@dots{}]
-@end example
-@item @code{Dokumentation}
-Eine Zeichenkette zur Dokumentation, die angezeigt wird, wenn man dies
-ausführt:
-@example
-herd doc @var{Dienstname}
-@end example
-where @var{service-name} is one of the symbols in @code{provision}
-(@pxref{Invoking herd,,, shepherd, The GNU Shepherd Manual}).
-@item @code{modules} (default: @code{%default-modules})
-Dies ist die Liste der Module, die in den Sichtbarkeitsbereich geladen sein
-müssen, wenn @code{start} und @code{stop} ausgewertet werden.
-@end table
-@end deftp
-@deftp {Datentyp} shepherd-action
-Dieser Datentyp definiert zusätzliche Aktionen, die ein Shepherd-Dienst
-implementiert (siehe oben).
-@table @code
-@item name
-Die Aktion bezeichnendes Symbol.
-@item Dokumentation
-Diese Zeichenkette ist die Dokumentation für die Aktion. Sie können sie
-sehen, wenn Sie dies ausführen:
-@example
-herd doc @var{Dienst} action @var{Aktion}
-@end example
-@item procedure
-Dies sollte ein G-Ausdruck sein, der zu einer mindestens ein Argument
-nehmenden Prozedur ausgewertet wird. Das Argument ist der »running«-Wert des
-Dienstes (siehe @ref{Slots of services,,, shepherd, The GNU Shepherd
-Manual}).
-@end table
-Das folgende Beispiel definiert eine Aktion namens @code{sag-hallo}, die den
-Benutzer freundlich begrüßt:
-@example
-(shepherd-action
-  (name 'sag-hallo)
-  (documentation "Sag Hallo!")
-  (procedure #~(lambda (running . args)
-                 (format #t "Hallo, Freund! Argumente: ~s\n"
-                         args)
-                 #t)))
-@end example
-Wenn wir annehmen, dass wir die Aktion zum Dienst @code{beispiel}
-hinzufügen, können Sie Folgendes ausführen:
-@example
-# herd sag-hallo beispiel
-Hallo, Freund! Argumente: ()
-# herd sag-hallo beispiel a b c
-Hallo, Freund! Argumente: ("a" "b" "c")
-@end example
-Wie Sie sehen können, ist das eine sehr ausgeklügelte Art, Hallo zu
-sagen. Siehe @ref{Service Convenience,,, shepherd, The GNU Shepherd Manual}
-für mehr Informationen zu Aktionen.
-@end deftp
-@defvr {Scheme-Variable} shepherd-root-service-type
-Der Diensttyp für den Shepherd-»Wurzeldienst« — also für PID@tie{}1.
-Dieser Diensttyp stellt das Ziel für Diensterweiterungen dar, die
-Shepherd-Dienste erzeugen sollen (siehe @ref{Diensttypen und Dienste} für
-ein Beispiel). Jede Erweiterung muss eine Liste von
-@code{<shepherd-service>}-Objekten übergeben.
-@end defvr
-@defvr {Scheme-Variable} %shepherd-root-service
-Dieser Dienst repräsentiert PID@tie{}1.
-@end defvr
-@node Dokumentation
-@chapter Dokumentation
-@cindex documentation, searching for
-@cindex searching for documentation
-@cindex Info, documentation format
-@cindex man pages
-@cindex manual pages
-In most cases packages installed with Guix come with documentation.  There
-are two main documentation formats: ``Info'', a browseable hypertext format
-used for GNU software, and ``manual pages'' (or ``man pages''), the linear
-documentation format traditionally found on Unix.  Info manuals are accessed
-with the @command{info} command or with Emacs, and man pages are accessed
-using @command{man}.
-You can look for documentation of software installed on your system by
-keyword.  For example, the following command searches for information about
-``TLS'' in Info manuals:
-@example
-$ info -k TLS
-"(emacs)Network Security" -- STARTTLS
-"(emacs)Network Security" -- TLS
-"(gnutls)Core TLS API" -- gnutls_certificate_set_verify_flags
-"(gnutls)Core TLS API" -- gnutls_certificate_set_verify_function
-@dots{}
-@end example
-@noindent
-The command below searches for the same keyword in man pages:
-@example
-$ man -k TLS
-SSL (7)              - OpenSSL SSL/TLS library
-certtool (1)         - GnuTLS certificate tool
-@dots {}
-@end example
-These searches are purely local to your computer so you have the guarantee
-that documentation you find corresponds to what you have actually installed,
-you can access it off-line, and your privacy is respected.
-Once you have these results, you can view the relevant documentation by
-running, say:
-@example
-$ info "(gnutls)Core TLS API"
-@end example
-@noindent
-or:
-@example
-$ man certtool
-@end example
-Info manuals contain sections and indices as well as hyperlinks like those
-found in Web pages.  The @command{info} reader (@pxref{Top, Info reader,,
-info-stnd, Stand-alone GNU Info}) and its Emacs counterpart (@pxref{Misc
-Help,,, emacs, The GNU Emacs Manual}) provide intuitive key bindings to
-navigate manuals.  @xref{Getting Started,,, info, Info: An Introduction},
-for an introduction to Info navigation.
-@node Dateien zur Fehlersuche installieren
-@chapter Dateien zur Fehlersuche installieren
-@cindex debugging files
-Program binaries, as produced by the GCC compilers for instance, are
-typically written in the ELF format, with a section containing
-@dfn{debugging information}.  Debugging information is what allows the
-debugger, GDB, to map binary code to source code; it is required to debug a
-compiled program in good conditions.
-The problem with debugging information is that is takes up a fair amount of
-disk space.  For example, debugging information for the GNU C Library weighs
-in at more than 60 MiB.  Thus, as a user, keeping all the debugging info of
-all the installed programs is usually not an option.  Yet, space savings
-should not come at the cost of an impediment to debugging---especially in
-the GNU system, which should make it easier for users to exert their
-computing freedom (@pxref{GNU-Distribution}).
-Thankfully, the GNU Binary Utilities (Binutils) and GDB provide a mechanism
-that allows users to get the best of both worlds: debugging information can
-be stripped from the binaries and stored in separate files.  GDB is then
-able to load debugging information from those files, when they are available
-(@pxref{Separate Debug Files,,, gdb, Debugging with GDB}).
-The GNU distribution takes advantage of this by storing debugging
-information in the @code{lib/debug} sub-directory of a separate package
-output unimaginatively called @code{debug} (@pxref{Pakete mit mehreren Ausgaben.}).  Users can choose to install the @code{debug} output of a package
-when they need it.  For instance, the following command installs the
-debugging information for the GNU C Library and for GNU Guile:
-@example
-guix package -i glibc:debug guile:debug
-@end example
-GDB must then be told to look for debug files in the user's profile, by
-setting the @code{debug-file-directory} variable (consider setting it from
-the @file{~/.gdbinit} file, @pxref{Startup,,, gdb, Debugging with GDB}):
-@example
-(gdb) set debug-file-directory ~/.guix-profile/lib/debug
-@end example
-From there on, GDB will pick up debugging information from the @code{.debug}
-files under @file{~/.guix-profile/lib/debug}.
-In addition, you will most likely want GDB to be able to show the source
-code being debugged.  To do that, you will have to unpack the source code of
-the package of interest (obtained with @code{guix build --source},
-@pxref{Aufruf von guix build}), and to point GDB to that source directory
-using the @code{directory} command (@pxref{Source Path, @code{directory},,
-gdb, Debugging with GDB}).
-@c XXX: keep me up-to-date
-The @code{debug} output mechanism in Guix is implemented by the
-@code{gnu-build-system} (@pxref{Erstellungssysteme}).  Currently, it is
-opt-in---debugging information is available only for the packages with
-definitions explicitly declaring a @code{debug} output.  This may be changed
-to opt-out in the future if our build farm servers can handle the load.  To
-check whether a package has a @code{debug} output, use @command{guix package
--list-available} (@pxref{Aufruf von guix package}).
-@node Sicherheitsaktualisierungen
-@chapter Sicherheitsaktualisierungen
-@cindex security updates
-@cindex Sicherheitslücken
-Occasionally, important security vulnerabilities are discovered in software
-packages and must be patched.  Guix developers try hard to keep track of
-known vulnerabilities and to apply fixes as soon as possible in the
-@code{master} branch of Guix (we do not yet provide a ``stable'' branch
-containing only security updates.)  The @command{guix lint} tool helps
-developers find out about vulnerable versions of software packages in the
-distribution:
-@smallexample
-$ guix lint -c cve
-gnu/packages/base.scm:652:2: glibc@@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547
-gnu/packages/gcc.scm:334:2: gcc@@4.9.3: probably vulnerable to CVE-2015-5276
-gnu/packages/image.scm:312:2: openjpeg@@2.1.0: probably vulnerable to CVE-2016-1923, CVE-2016-1924
-@dots{}
-@end smallexample
-@xref{Aufruf von guix lint}, for more information.
-@quotation Anmerkung
-As of version @value{VERSION}, the feature described below is considered
-``beta''.
-@end quotation
-Guix follows a functional package management discipline
-(@pxref{Einführung}), which implies that, when a package is changed,
-@emph{every package that depends on it} must be rebuilt.  This can
-significantly slow down the deployment of fixes in core packages such as
-libc or Bash, since basically the whole distribution would need to be
-rebuilt.  Using pre-built binaries helps (@pxref{Substitute}), but
-deployment may still take more time than desired.
-@cindex grafts
-To address this, Guix implements @dfn{grafts}, a mechanism that allows for
-fast deployment of critical updates without the costs associated with a
-whole-distribution rebuild.  The idea is to rebuild only the package that
-needs to be patched, and then to ``graft'' it onto packages explicitly
-installed by the user and that were previously referring to the original
-package.  The cost of grafting is typically very low, and order of
-magnitudes lower than a full rebuild of the dependency chain.
-@cindex replacements of packages, for grafts
-For instance, suppose a security update needs to be applied to Bash.  Guix
-developers will provide a package definition for the ``fixed'' Bash, say
-@code{bash-fixed}, in the usual way (@pxref{Pakete definieren}).  Then, the
-original package definition is augmented with a @code{replacement} field
-pointing to the package containing the bug fix:
-@example
-(define bash
-  (package
-    (name "bash")
-    ;; @dots{}
-    (replacement bash-fixed)))
-@end example
-From there on, any package depending directly or indirectly on Bash---as
-reported by @command{guix gc --requisites} (@pxref{Aufruf von guix gc})---that
-is installed is automatically ``rewritten'' to refer to @code{bash-fixed}
-instead of @code{bash}.  This grafting process takes time proportional to
-the size of the package, usually less than a minute for an ``average''
-package on a recent machine.  Grafting is recursive: when an indirect
-dependency requires grafting, then grafting ``propagates'' up to the package
-that the user is installing.
-Currently, the length of the name and version of the graft and that of the
-package it replaces (@code{bash-fixed} and @code{bash} in the example above)
-must be equal.  This restriction mostly comes from the fact that grafting
-works by patching files, including binary files, directly.  Other
-restrictions may apply: for instance, when adding a graft to a package
-providing a shared library, the original shared library and its replacement
-must have the same @code{SONAME} and be binary-compatible.
-The @option{--no-grafts} command-line option allows you to forcefully avoid
-grafting (@pxref{Gemeinsame Erstellungsoptionen, @option{--no-grafts}}).  Thus, the
-command:
-@example
-guix build bash --no-grafts
-@end example
-@noindent
-returns the store file name of the original Bash, whereas:
-@example
-guix build bash
-@end example
-@noindent
-returns the store file name of the ``fixed'', replacement Bash.  This allows
-you to distinguish between the two variants of Bash.
-To verify which Bash your whole profile refers to, you can run
-(@pxref{Aufruf von guix gc}):
-@example
-guix gc -R `readlink -f ~/.guix-profile` | grep bash
-@end example
-@noindent
-@dots{} and compare the store file names that you get with those above.
-Likewise for a complete Guix system generation:
-@example
-guix gc -R `guix system build my-config.scm` | grep bash
-@end example
-Lastly, to check which Bash running processes are using, you can use the
-@command{lsof} command:
-@example
-lsof | grep /gnu/store/.*bash
-@end example
-@node Bootstrapping
-@chapter Bootstrapping
-@c Adapted from the ELS 2013 paper.
-@cindex bootstrapping
-Bootstrapping in our context refers to how the distribution gets built
-``from nothing''.  Remember that the build environment of a derivation
-contains nothing but its declared inputs (@pxref{Einführung}).  So there's
-an obvious chicken-and-egg problem: how does the first package get built?
-How does the first compiler get compiled? Note that this is a question of
-interest only to the curious hacker, not to the regular user, so you can
-shamelessly skip this section if you consider yourself a ``regular user''.
-@cindex bootstrap binaries
-The GNU system is primarily made of C code, with libc at its core.  The GNU
-build system itself assumes the availability of a Bourne shell and
-command-line tools provided by GNU Coreutils, Awk, Findutils, `sed', and
-`grep'.  Furthermore, build programs---programs that run @code{./configure},
-@code{make}, etc.---are written in Guile Scheme (@pxref{Ableitungen}).
-Consequently, to be able to build anything at all, from scratch, Guix relies
-on pre-built binaries of Guile, GCC, Binutils, libc, and the other packages
-mentioned above---the @dfn{bootstrap binaries}.
-These bootstrap binaries are ``taken for granted'', though we can also
-re-create them if needed (more on that later).
-@unnumberedsec Preparing to Use the Bootstrap Binaries
-@c As of Emacs 24.3, Info-mode displays the image, but since it's a
-@c large image, it's hard to scroll.  Oh well.
-@image{images/bootstrap-graph,6in,,Dependency graph of the early bootstrap
-derivations}
-The figure above shows the very beginning of the dependency graph of the
-distribution, corresponding to the package definitions of the @code{(gnu
-packages bootstrap)} module.  A similar figure can be generated with
-@command{guix graph} (@pxref{Aufruf von guix graph}), along the lines of:
-@example
-guix graph -t derivation \
-  -e '(@@@@ (gnu packages bootstrap) %bootstrap-gcc)' \
-  | dot -Tps > t.ps
-@end example
-At this level of detail, things are slightly complex.  First, Guile itself
-consists of an ELF executable, along with many source and compiled Scheme
-files that are dynamically loaded when it runs.  This gets stored in the
-@file{guile-2.0.7.tar.xz} tarball shown in this graph.  This tarball is part
-of Guix's ``source'' distribution, and gets inserted into the store with
-@code{add-to-store} (@pxref{Der Store}).
-But how do we write a derivation that unpacks this tarball and adds it to
-the store? To solve this problem, the @code{guile-bootstrap-2.0.drv}
-derivation---the first one that gets built---uses @code{bash} as its
-builder, which runs @code{build-bootstrap-guile.sh}, which in turn calls
-@code{tar} to unpack the tarball.  Thus, @file{bash}, @file{tar}, @file{xz},
-and @file{mkdir} are statically-linked binaries, also part of the Guix
-source distribution, whose sole purpose is to allow the Guile tarball to be
-unpacked.
-Once @code{guile-bootstrap-2.0.drv} is built, we have a functioning Guile
-that can be used to run subsequent build programs.  Its first task is to
-download tarballs containing the other pre-built binaries---this is what the
-@code{.tar.xz.drv} derivations do.  Guix modules such as
-@code{ftp-client.scm} are used for this purpose.  The
-@code{module-import.drv} derivations import those modules in a directory in
-the store, using the original layout.  The @code{module-import-compiled.drv}
-derivations compile those modules, and write them in an output directory
-with the right layout.  This corresponds to the @code{#:modules} argument of
-@code{build-expression->derivation} (@pxref{Ableitungen}).
-Finally, the various tarballs are unpacked by the derivations
-@code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv}, etc., at which
-point we have a working C tool chain.
-@unnumberedsec Building the Build Tools
-Bootstrapping is complete when we have a full tool chain that does not
-depend on the pre-built bootstrap tools discussed above.  This no-dependency
-requirement is verified by checking whether the files of the final tool
-chain contain references to the @file{/gnu/store} directories of the
-bootstrap inputs.  The process that leads to this ``final'' tool chain is
-described by the package definitions found in the @code{(gnu packages
-commencement)} module.
-The @command{guix graph} command allows us to ``zoom out'' compared to the
-graph above, by looking at the level of package objects instead of
-individual derivations---remember that a package may translate to several
-derivations, typically one derivation to download its source, one to build
-the Guile modules it needs, and one to actually build the package from
-source.  The command:
-@example
-guix graph -t bag \
-  -e '(@@@@ (gnu packages commencement)
-          glibc-final-with-bootstrap-bash)' | dot -Tps > t.ps
-@end example
-@noindent
-produces the dependency graph leading to the ``final'' C
-library@footnote{You may notice the @code{glibc-intermediate} label,
-suggesting that it is not @emph{quite} final, but as a good approximation,
-we will consider it final.}, depicted below.
-@image{images/bootstrap-packages,6in,,Dependency graph of the early
-packages}
-@c See <http://lists.gnu.org/archive/html/gnu-system-discuss/2012-10/msg00000.html>.
-The first tool that gets built with the bootstrap binaries is
-GNU@tie{}Make---noted @code{make-boot0} above---which is a prerequisite for
-all the following packages.  From there Findutils and Diffutils get built.
-Then come the first-stage Binutils and GCC, built as pseudo cross
-tools---i.e., with @code{--target} equal to @code{--host}.  They are used to
-build libc.  Thanks to this cross-build trick, this libc is guaranteed not
-to hold any reference to the initial tool chain.
-From there the final Binutils and GCC (not shown above) are built.  GCC uses
-@code{ld} from the final Binutils, and links programs against the just-built
-libc.  This tool chain is used to build the other packages used by Guix and
-by the GNU Build System: Guile, Bash, Coreutils, etc.
-And voilà! At this point we have the complete set of build tools that the
-GNU Build System expects.  These are in the @code{%final-inputs} variable of
-the @code{(gnu packages commencement)} module, and are implicitly used by
-any package that uses @code{gnu-build-system} (@pxref{Erstellungssysteme,
-@code{gnu-build-system}}).
-@unnumberedsec Building the Bootstrap Binaries
-@cindex bootstrap binaries
-Because the final tool chain does not depend on the bootstrap binaries,
-those rarely need to be updated.  Nevertheless, it is useful to have an
-automated way to produce them, should an update occur, and this is what the
-@code{(gnu packages make-bootstrap)} module provides.
-The following command builds the tarballs containing the bootstrap binaries
-(Guile, Binutils, GCC, libc, and a tarball containing a mixture of Coreutils
-and other basic command-line tools):
-@example
-guix build bootstrap-tarballs
-@end example
-The generated tarballs are those that should be referred to in the
-@code{(gnu packages bootstrap)} module mentioned at the beginning of this
-section.
-Still here? Then perhaps by now you've started to wonder: when do we reach a
-fixed point? That is an interesting question! The answer is unknown, but if
-you would like to investigate further (and have significant computational
-and storage resources to do so), then let us know.
-@unnumberedsec Reducing the Set of Bootstrap Binaries
-Our bootstrap binaries currently include GCC, Guile, etc.  That's a lot of
-binary code! Why is that a problem? It's a problem because these big chunks
-of binary code are practically non-auditable, which makes it hard to
-establish what source code produced them.  Every unauditable binary also
-leaves us vulnerable to compiler backdoors as described by Ken Thompson in
-the 1984 paper @emph{Reflections on Trusting Trust}.
-This is mitigated by the fact that our bootstrap binaries were generated
-from an earlier Guix revision.  Nevertheless it lacks the level of
-transparency that we get in the rest of the package dependency graph, where
-Guix always gives us a source-to-binary mapping.  Thus, our goal is to
-reduce the set of bootstrap binaries to the bare minimum.
-The @uref{http://bootstrappable.org, Bootstrappable.org web site} lists
-on-going projects to do that.  One of these is about replacing the bootstrap
-GCC with a sequence of assemblers, interpreters, and compilers of increasing
-complexity, which could be built from source starting from a simple and
-auditable assembler.  Your help is welcome!
-@node Portierung
-@chapter Porting to a New Platform
-As discussed above, the GNU distribution is self-contained, and
-self-containment is achieved by relying on pre-built ``bootstrap binaries''
-(@pxref{Bootstrapping}).  These binaries are specific to an operating system
-kernel, CPU architecture, and application binary interface (ABI).  Thus, to
-port the distribution to a platform that is not yet supported, one must
-build those bootstrap binaries, and update the @code{(gnu packages
-bootstrap)} module to use them on that platform.
-Fortunately, Guix can @emph{cross compile} those bootstrap binaries.  When
-everything goes well, and assuming the GNU tool chain supports the target
-platform, this can be as simple as running a command like this one:
-@example
-guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs
-@end example
-For this to work, the @code{glibc-dynamic-linker} procedure in @code{(gnu
-packages bootstrap)} must be augmented to return the right file name for
-libc's dynamic linker on that platform; likewise,
-@code{system->linux-architecture} in @code{(gnu packages linux)} must be
-taught about the new platform.
-Once these are built, the @code{(gnu packages bootstrap)} module needs to be
-updated to refer to these binaries on the target platform.  That is, the
-hashes and URLs of the bootstrap tarballs for the new platform must be added
-alongside those of the currently supported platforms.  The bootstrap Guile
-tarball is treated specially: it is expected to be available locally, and
-@file{gnu/local.mk} has rules to download it for the supported
-architectures; a rule for the new platform must be added as well.
-In practice, there may be some complications.  First, it may be that the
-extended GNU triplet that specifies an ABI (like the @code{eabi} suffix
-above) is not recognized by all the GNU tools.  Typically, glibc recognizes
-some of these, whereas GCC uses an extra @code{--with-abi} configure flag
-(see @code{gcc.scm} for examples of how to handle this).  Second, some of
-the required packages could fail to build for that platform.  Lastly, the
-generated binaries could be broken for some reason.
-@c *********************************************************************
-@include contributing.de.texi
-@c *********************************************************************
-@node Danksagungen
-@chapter Danksagungen
-Guix baut auf dem @uref{http://nixos.org/nix/, Nix-Paketverwaltungsprogramm}
-auf, das von Eelco Dolstra entworfen und entwickelt wurde, mit Beiträgen von
-anderen Leuten (siehe die Datei @file{nix/AUTHORS} in Guix). Nix hat für die
-funktionale Paketverwaltung die Pionierarbeit geleistet und noch nie
-dagewesene Funktionalitäten vorangetrieben wie transaktionsbasierte
-Paketaktualisierungen und die Rücksetzbarkeit selbiger, eigene Paketprofile
-für jeden Nutzer und referenziell transparente Erstellungsprozesse. Ohne
-diese Arbeit gäbe es Guix nicht.
-Die Nix-basierten Software-Distributionen Nixpkgs und NixOS waren auch eine
-Inspiration für Guix.
-GNU@tie{}Guix ist selbst das Produkt kollektiver Arbeit mit Beiträgen durch
-eine Vielzahl von Leuten. Siehe die Datei @file{AUTHORS} in Guix für mehr
-Informationen, wer diese wunderbaren Menschen sind. In der Datei
-@file{THANKS} finden Sie eine Liste der Leute, die uns geholfen haben, indem
-Sie Fehler gemeldet, sich um unsere Infrastruktur gekümmert, künstlerische
-Arbeit und schön gestaltete Themen beigesteuert, Vorschläge gemacht und noch
-vieles mehr getan haben — vielen Dank!
-@c *********************************************************************
-@node GNU-Lizenz für freie Dokumentation
-@appendix GNU-Lizenz für freie Dokumentation
-@cindex Lizenz, GNU-Lizenz für freie Dokumentation
-@include fdl-1.3.texi
-@c *********************************************************************
-@node Konzeptverzeichnis
-@unnumbered Konzeptverzeichnis
-@printindex cp
-@node Programmierverzeichnis
-@unnumbered Programmierverzeichnis
-@syncodeindex tp fn
-@syncodeindex vr fn
-@printindex fn
-@bye
-@c Local Variables:
-@c ispell-local-dictionary: "american";
-@c End: