This is guix.de.info, produced by makeinfo version 6.7 from
guix.de.texi.

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021
Ludovic Courtès
Copyright © 2013, 2014, 2016 Andreas Enge
Copyright © 2013 Nikita Karetnikov
Copyright © 2014, 2015, 2016 Alex Kost
Copyright © 2015, 2016 Mathieu Lirzin
Copyright © 2014 Pierre-Antoine Rault
Copyright © 2015 Taylan Ulrich Bayırlı/Kammer
Copyright © 2015, 2016, 2017, 2019, 2020, 2021 Leo Famulari
Copyright © 2015, 2016, 2017, 2018, 2019, 2020 Ricardo Wurmus
Copyright © 2016 Ben Woodcroft
Copyright © 2016, 2017, 2018, 2021 Chris Marusich
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Efraim Flashner
Copyright © 2016 John Darrington
Copyright © 2016, 2017 Nikita Gillmann
Copyright © 2016, 2017, 2018, 2019, 2020 Jan Nieuwenhuizen
Copyright © 2016, 2017, 2018, 2019, 2020 Julien Lepiller
Copyright © 2016 Alex ter Weele
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Christopher Baines
Copyright © 2017, 2018, 2019 Clément Lassieur
Copyright © 2017, 2018, 2020, 2021 Mathieu Othacehe
Copyright © 2017 Federico Beffa
Copyright © 2017, 2018 Carlo Zancanaro
Copyright © 2017 Thomas Danckaert
Copyright © 2017 humanitiesNerd
Copyright © 2017, 2021 Christopher Lemmer Webber
Copyright © 2017, 2018, 2019, 2020 Marius Bakke
Copyright © 2017, 2019, 2020 Hartmut Goebel
Copyright © 2017, 2019, 2020, 2021 Maxim Cournoyer
Copyright © 2017, 2018, 2019, 2020, 2021 Tobias Geerinckx-Rice
Copyright © 2017 George Clemmer
Copyright © 2017 Andy Wingo
Copyright © 2017, 2018, 2019, 2020 Arun Isaac
Copyright © 2017 nee
Copyright © 2018 Rutger Helling
Copyright © 2018, 2021 Oleg Pykhalov
Copyright © 2018 Mike Gerwitz
Copyright © 2018 Pierre-Antoine Rouby
Copyright © 2018, 2019 Gábor Boskovits
Copyright © 2018, 2019, 2020 Florian Pelz
Copyright © 2018 Laura Lazzati
Copyright © 2018 Alex Vong
Copyright © 2019 Josh Holland
Copyright © 2019, 2020 Diego Nicola Barbato
Copyright © 2019 Ivan Petkov
Copyright © 2019 Jakob L. Kreuze
Copyright © 2019 Kyle Andrews
Copyright © 2019 Alex Griffin
Copyright © 2019, 2020 Guillaume Le Vaillant
Copyright © 2020 Leo Prikler
Copyright © 2019, 2020 Simon Tournier
Copyright © 2020 Wiktor Żelazny
Copyright © 2020 Damien Cassou
Copyright © 2020 Jakub Kądziołka
Copyright © 2020 Jack Hill
Copyright © 2020 Naga Malleswari
Copyright © 2020 Brice Waegeneire
Copyright © 2020 R Veera Kumar
Copyright © 2020 Pierre Langlois
Copyright © 2020 pinoaffe
Copyright © 2020 André Batista
Copyright © 2020, 2021 Alexandru-Sergiu Marton
Copyright © 2020 raingloom
Copyright © 2020 Daniel Brooks
Copyright © 2020 John Soo
Copyright © 2020 Jonathan Brielmaier
Copyright © 2020 Edgar Vincent
Copyright © 2021 Maxime Devos

   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“.
INFO-DIR-SECTION Systemadministration
START-INFO-DIR-ENTRY
* 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.
* guix deploy: (guix.de)guix deploy aufrufen.  Betriebssystemkonfigurationen
                                                 entfernter Rechner verwalten.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Softwareentwicklung
START-INFO-DIR-ENTRY
* 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-INFO-DIR-ENTRY


File: guix.de.info,  Node: Pakete definieren,  Next: Paketvarianten definieren,  Prev: Paketmodule,  Up: Programmierschnittstelle

8.2 Pakete definieren
=====================

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     Was hat es mit diesen einfachen Anführungszeichen (‘'’) auf sich?
     Sie gehören zur Syntax von Scheme und führen eine wörtlich zu
     interpretierende Datenlisten ein; dies nennt sich Maskierung oder
     Quotierung. ‘'’ ist synonym mit ‘quote’. *note Quotierung:
     (guile)Expression Syntax. enthält weitere Details. Hierbei ist also
     der Wert des ‘arguments’-Feldes eine Liste von Argumenten, die an
     das Erstellungssystem weitergereicht werden, wie bei ‘apply’ (siehe
     *note ‘apply’: (guile)Fly Evaluation.).

     Ein Doppelkreuz gefolgt von einem Doppelpunkt (‘#:’) definiert ein
     Scheme-“Schlüsselwort” (siehe *note (guile)Keywords::) und
     ‘#:configure-flags’ ist ein Schlüsselwort, um eine
     Befehlszeilenoption an das Erstellungssystem mitzugeben (siehe
     *note (guile)Coding With Keywords::).

   • Das Feld ‘inputs’ legt Eingaben an den Erstellungsprozess fest —
     d.h. Abhängigkeiten des Pakets zur Erstellungs- oder Laufzeit. Hier
     definieren wir eine Eingabe namens ‘"gawk"’, deren Wert wir auf den
     Wert der ‘gawk’-Variablen festlegen; GAWK ist auch selbst wiederum
     an ein ‘<package>’-Objekt als Variablenwert gebunden.

     Auch mit ‘`’ (einem Backquote, stattdessen kann man auch das
     längere Synonym ‘quasiquote’ schreiben) können wir eine wörtlich
     als Daten interpretierte Liste im ‘inputs’-Feld einführen, aber bei
     dieser „Quasimaskierung“ kann ‘,’ (ein Komma, oder dessen Synonym
     ‘unquote’) benutzt werden, um den ausgewerteten Wert eines
     Ausdrucks in diese Liste einzufügen (siehe *note unquote:
     (guile)Expression Syntax.).

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

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

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

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

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

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

 -- Scheme-Prozedur: package-derivation STORE PAKET [SYSTEM]
     Das ‘<derivation>’-Objekt zum PAKET für das angegebene SYSTEM
     liefern (siehe *note Ableitungen::).

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

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

 -- Scheme-Prozedur: package-cross-derivation STORE PAKET ZIEL [SYSTEM]
          Liefert das
     ‘<derivation>’-Objekt, um das PAKET zu cross-erstellen vom SYSTEM
     aus für das ZIEL-System.

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

   Wenn Sie einmal Paketdefinitionen fertig verfasst haben, können Sie
leicht _Varianten_ derselben Pakete definieren. Siehe *note
Paketvarianten definieren:: für mehr Informationen dazu.

* Menu:

* „package“-Referenz::   Der Datentyp für Pakete.
* „origin“-Referenz::    Datentyp für Paketursprünge.


File: guix.de.info,  Node: „package“-Referenz,  Next: „origin“-Referenz,  Up: Pakete definieren

8.2.1 ‘package’-Referenz
------------------------

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

 -- Datentyp: package
     Dieser Datentyp steht für ein Paketrezept.

     ‘name’
          Der Name des Pakets als Zeichenkette.

     ‘version’
          Die Version des Pakets als Zeichenkette.

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

     ‘build-system’
          Das Erstellungssystem, mit dem das Paket erstellt werden soll
          (siehe *note Erstellungssysteme::).

     ‘arguments’ (Vorgabe: ‘'()’)
          Die Argumente, die an das Erstellungssystem übergeben werden
          sollen. Dies ist eine Liste, typischerweise eine Reihe von
          Schlüssel-Wert-Paaren.

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

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

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

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

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

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

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

     ‘outputs’ (Vorgabe: ‘'("out")’)
          Die Liste der Benennungen der Ausgaben des Pakets. Der
          Abschnitt *note Pakete mit mehreren Ausgaben.:: beschreibt
          übliche Nutzungen zusätzlicher Ausgaben.

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

     ‘replacement’ (Vorgabe: ‘#f’)
          Dies muss entweder ‘#f’ oder ein package-Objekt sein, das als
          Ersatz (“replacement”) dieses Pakets benutzt werden soll. Im
          Abschnitt zu *note Veredelungen: Sicherheitsaktualisierungen.
          wird dies erklärt.

     ‘synopsis’
          Eine einzeilige Beschreibung des Pakets.

     ‘description’
          Eine ausführlichere Beschreibung des Pakets.

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

     ‘home-page’
          Die URL, die die Homepage des Pakets angibt, als Zeichenkette.

     ‘supported-systems’ (Vorgabe: ‘%supported-systems’)
          Die Liste der vom Paket unterstützten Systeme als
          Zeichenketten der Form ‘Architektur-Kernel’, zum Beispiel
          ‘"x86_64-linux"’.

     ‘location’ (Vorgabe: die Stelle im Quellcode, wo die ‘package’-Form steht)
          Wo im Quellcode das Paket definiert wurde. Es ist sinnvoll,
          dieses Feld manuell zuzuweisen, wenn das Paket von einem
          anderen Paket erbt, weil dann dieses Feld nicht automatisch
          berichtigt wird.

 -- Scheme-Syntax: this-package
     Wenn dies im _lexikalischen Geltungsbereich_ der Definition eines
     Feldes im Paket steht, bezieht sich dieser Bezeichner auf das
     Paket, das gerade definiert wird.

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

          (package
            (name "guile")
            ;; …

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

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

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

 -- Scheme-Prozedur: package-with-c-toolchain PAKET TOOLCHAIN
     Liefert eine Variante des PAKETs, die die angegebene TOOLCHAIN
     anstelle der vorgegebenen GNU-C/C++-Toolchain benutzt. Als
     TOOLCHAIN muss eine Liste von Eingaben (als Tupel aus Bezeichnung
     und bezeichnetem Paket) angegeben werden, die eine gleichartige
     Funktion erfüllen, wie zum Beispiel das Paket ‘gcc-toolchain’.

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

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

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


File: guix.de.info,  Node: „origin“-Referenz,  Prev: „package“-Referenz,  Up: Pakete definieren

8.2.2 ‘origin’-Referenz
-----------------------

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

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

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

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

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

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

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

          Diese Informationen liefert Ihnen der Befehl ‘guix download’
          (siehe *note Aufruf von guix download::) oder ‘guix hash’
          (siehe *note Aufruf von guix hash::).

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

     ‘patches’ (Vorgabe: ‘'()’)
          Eine Liste von Dateinamen, Ursprüngen oder dateiähnlichen
          Objekten (siehe *note dateiartige Objekte: G-Ausdrücke.) mit
          Patches, welche auf den Quellcode anzuwenden sind.

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

     ‘snippet’ (Vorgabe: ‘#f’)
          Ein im Quellcode-Verzeichnis auszuführender G-Ausdruck (siehe
          *note G-Ausdrücke::) oder S-Ausdruck. Hiermit kann der
          Quellcode bequem modifiziert werden, manchmal ist dies
          bequemer als mit einem Patch.

     ‘patch-flags’ (Vorgabe: ‘'("-p1")’)
          Eine Liste der Befehlszeilenoptionen, die dem ‘patch’-Befehl
          übergeben werden sollen.

     ‘patch-inputs’ (Vorgabe: ‘#f’)
          Eingabepakete oder -ableitungen für den Patch-Prozess. Bei
          ‘#f’ werden die üblichen Patcheingaben wie GNU Patch
          bereitgestellt.

     ‘modules’ (Vorgabe: ‘'()’)
          Eine Liste von Guile-Modulen, die während des Patch-Prozesses
          und während der Ausführung des ‘snippet’-Felds geladen sein
          sollen.

     ‘patch-guile’ (Vorgabe: ‘#f’)
          Welches Guile-Paket für den Patch-Prozess benutzt werden soll.
          Bei ‘#f’ wird ein vernünftiger Vorgabewert angenommen.

 -- Datentyp: content-hash WERT [ALGORITHMUS]
     Erzeugt ein Inhaltshash-Objekt für den gegebenen ALGORITHMUS und
     benutzt dabei den WERT als dessen Hashwert. Wenn kein ALGORITHMUS
     angegeben wird, wird ‘sha256’ angenommen.

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

     Folgende Formen sind äquivalent:

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

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

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

 -- Scheme-Prozedur: url-fetch URL HASH-ALGO HASH [name] [#:executable?
          #f] Liefert eine Ableitung mit fester Ausgabe, die
     Daten von der URL lädt (einer Zeichenkette oder Liste von
     Zeichenketten für alternativ mögliche URLs). Es wird erwartet, dass
     die Daten HASH als Prüfsumme haben, gemäß dem Algorithmus, der in
     HASH-ALGO (einem Symbol) angegebenen wurde. Nach Vorgabe ergibt
     sich der Dateiname aus dem Basisnamen der URL; optional kann in
     NAME ein anderslautender Name festgelegt werden. Wenn EXECUTABLE?
     wahr ist, wird die heruntergeladene Datei als ausführbar markiert.

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

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

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

 -- Scheme-Prozedur: git-fetch REF HASH-ALGO HASH
     Liefert eine Ableitung mit fester Ausgabe, die REF lädt, ein
     ‘<git-reference>’-Objekt. Es wird erwartet, dass die Ausgabe
     rekursiv die Prüfsumme HASH aufweist (ein „rekursiver Hash“) gemäß
     dem Typ HASH-ALGO (einem Symbol). Als Dateiname wird NAME
     verwendet, oder ein generischer Name, falls NAME ‘#f’ ist.

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

     ‘url’
          Die URL des zu klonenden Git-Repositorys.

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

     ‘recursive?’ (Vorgabe: ‘#f’)
          Dieser boolesche Wert gibt an, ob Git-Submodule rekursiv
          geladen werden sollen.

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

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

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

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

   Bei Mercurial-Repositorys finden Sie im Modul ‘(guix hg-download)’
Definitionen für die Methode ‘hg-fetch’ für Paketursprünge sowie den
Datentyp ‘hg-reference’. Mit ihnen wird das Versionskontrollsystem
Mercurial unterstützt.

 -- Scheme-Prozedur: hg-fetch REF HASH-ALGO HASH [Name] Liefert eine
          Ableitung mit fester Ausgabe, die REF lädt, ein
     ‘<hg-reference>’-Objekt. Es wird erwartet, dass die Ausgabe
     rekursiv die Prüfsumme HASH aufweist (ein „rekursiver Hash“) gemäß
     dem Typ HASH-ALGO (einem Symbol). Als Dateiname wird NAME
     verwendet, oder ein generischer Name, falls NAME ‘#false’ ist.


File: guix.de.info,  Node: Paketvarianten definieren,  Next: Erstellungssysteme,  Prev: Pakete definieren,  Up: Programmierschnittstelle

8.3 Paketvarianten definieren
=============================

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

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

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

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

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

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

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

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

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

   Der obige Aufruf von ‘alist-delete’ entfernt das Tupel aus dem
‘inputs’-Feld, dessen erstes Element ‘"guile"’ ist (siehe *note
(guile)SRFI-1 Association Lists::).

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

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

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

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

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

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

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

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

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

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

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

… dieses hier:

     (use-modules (guix transformations))

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

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

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

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

 -- Scheme-Prozedur: package-input-rewriting ERSETZUNGEN
          [UMGESCHRIEBENER-NAME] [#:deep? #t] Eine Prozedur liefern, die
          für ein
     ihr übergebenes Paket dessen direkte und indirekte Abhängigkeit
     gemäß den ERSETZUNGEN umschreibt, einschließlich ihrer impliziten
     Eingaben, wenn DEEP? wahr ist. ERSETZUNGEN ist eine Liste von
     Paketpaaren; das erste Element eines Paares ist das zu ersetzende
     Paket und das zweite ist, wodurch es ersetzt werden soll.

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

Betrachten Sie dieses Beispiel:

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

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

Hier definieren wir zuerst eine Umschreibeprozedur, die OPENSSL durch
LIBRESSL ersetzt. Dann definieren wir damit eine “Variante” des
GIT-Pakets, die LIBRESSL statt OPENSSL benutzt. Das ist genau, was auch
die Befehlszeilenoption ‘--with-input’ tut (siehe *note ‘--with-input’:
Paketumwandlungsoptionen.).

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

 -- Scheme-Prozedur: package-input-rewriting/spec ERSETZUNGEN [#:deep?
          #t]
     Liefert eine Prozedur, die für ein gegebenes Paket die angegebenen
     ERSETZUNGEN auf dessen gesamten Paketgraphen anwendet
     (einschließlich impliziter Eingaben, außer wenn DEEP? falsch ist).
     ERSETZUNGEN muss dabei eine Liste von Paaren aus je einer
     Spezifikation und Prozedur sein. Dabei ist jede Spezifikation eine
     Paketspezifikation wie ‘"gcc"’ oder ‘"guile@2"’ und jede Prozedur
     nimmt ein passendes Paket und liefert dafür einen Ersatz für das
     Paket.

   Das obige Beispiel könnte auch so geschrieben werden:

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

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

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

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


File: guix.de.info,  Node: Erstellungssysteme,  Next: Erstellungsphasen,  Prev: Paketvarianten definieren,  Up: Programmierschnittstelle

8.4 Erstellungssysteme
======================

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

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

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

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

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

 -- Scheme-Variable: gnu-build-system
     ‘gnu-build-system’ steht für das GNU-Erstellungssystem und
     Varianten desselben (siehe *note Konfiguration und
     Makefile-Konventionen: (standards)Configuration.).

     Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt
     und installiert mit der üblichen Befehlsfolge ‘./configure && make
     && make check && make install’. In der Praxis braucht man oft noch
     ein paar weitere Schritte. Alle Schritte sind in voneinander
     getrennte “Phasen” unterteilt. Siehe *note Erstellungsphasen:: für
     mehr Informationen zu Erstellungsphasen und wie man sie anpassen
     kann.

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

     Dieses Erstellungssystem unterstützt eine Reihe von
     Schlüsselwortargumenten, die über das ‘arguments’-Feld eines Pakets
     übergeben werden können. Hier sind einige der wichtigen Parameter:

     ‘#:phases’
          Mit diesem Argument wird erstellungsseitiger Code angegeben,
          der zu einer assoziativen Liste von Erstellungsphasen
          ausgewertet wird. Siehe *note Erstellungsphasen:: für nähere
          Informationen.

     ‘#:configure-flags’
          Diese Liste von Befehlszeilenoptionen (als Zeichenketten)
          werden dem ‘configure’-Skript übergeben. Siehe *note Pakete
          definieren:: für ein Beispiel.

     ‘#:make-flags’
          Diese Zeichenkettenliste enthält Befehlszeilenoptionen, die
          als Argumente an ‘make’-Aufrufe in den Phasen ‘build’, ‘check’
          und ‘install’ übergeben werden.

     ‘#:out-of-source?’
          Dieser Boolesche Ausdruck, nach Vorgabe steht er auf ‘#f’,
          zeigt an, ob Erstellungen in einem gesonderten
          Erstellungsverzeichnis abseits des Quellbaums ausgeführt
          werden sollen.

          Wenn es auf wahr steht, wird in der ‘configure’-Phase eigens
          ein Erstellungsverzeichnis angelegt, dorthin gewechselt und
          das ‘configure’-Skript von dort ausgeführt. Das ist nützlich
          bei Paketen, die so etwas voraussetzen, wie ‘glibc’.

     ‘#:tests?’
          Dieser Boolesche Ausdruck, nach Vorgabe steht er auf ‘#t’,
          zeigt an, ob in der ‘check’-Phase der Testkatalog des Pakets
          ausgeführt werden soll.

     ‘#:test-target’
          In dieser Zeichenkette, nach Vorgabe ‘"check"’, wird der Name
          des Makefile-Ziels angegeben, das die ‘check’-Phase benutzt.

     ‘#:parallel-build?’
     ‘#:parallel-tests?’
          Mit diesen Booleschen Werten wird festgelegt, ob die
          Erstellung respektive der Testkatalog parallel ausgeführt
          werden soll, indem die Befehlszeilenoption ‘-j’ an ‘make’
          übergeben wird. Wenn die Werte wahr sind, wird an ‘make’ die
          Option ‘-jN’ übergeben, wobei N die Zahl ist, die in der
          ‘--cores’-Befehlszeilenoption an ‘guix-daemon’ oder an den
          ‘guix’-Clientbefehl übergeben wurde (siehe *note ‘--cores’:
          Gemeinsame Erstellungsoptionen.).

     ‘#:validate-runpath?’
          Dieser Boolesche Ausdruck, nach Vorgabe ‘#t’, bestimmt, ob der
          in ELF-Binärdateien, die in der ‘install’-Phase installiert
          worden sind, eingetragene ‘RUNPATH’ „validiert“ werden soll.
          ELF-Binärdateien sind gemeinsame Bibliotheken („Shared
          Libraries“ mit Dateiendung ‘.so’) sowie ausführbare Dateien.

          Die Validierung besteht darin, sicherzustellen, dass jede
          gemeinsame Bibliothek, die von einer ELF-Binärdatei gebraucht
          wird (sie sind in ‘DT_NEEDED’-Einträgen im
          ‘PT_DYNAMIC’-Segment der ELF-Datei aufgeführt), im
          ‘DT_RUNPATH’-Eintrag der Datei gefunden wird. Mit anderen
          Worten wird gewährleistet, dass es beim Ausführen oder
          Benutzen einer solchen Binärdatei nicht zur Laufzeit zu einem
          Fehler kommt, eine Datei würde nicht gefunden. Siehe *note
          ‘-rpath’: (ld)Options. für mehr Informationen zum ‘RUNPATH’.

     ‘#:substitutable?’
          Dieser Boolesche Ausdruck, nach Vorgabe ‘#t’, sagt aus, ob
          Paketausgaben substituierbar sein sollen, d.h. ob Benutzer
          Substitute dafür beziehen können sollen statt sie lokal
          erstellen zu müssen (siehe *note Substitute::).

     ‘#:allowed-references’
     ‘#:disallowed-references’
          Wenn für diese Argumente ein wahrer Wert angegeben wird, muss
          er einer Liste von Abhängigkeiten entsprechen, die _nicht_
          unter den Referenzen der Erstellungsergebnisse vorkommen
          dürfen. Wenn nach dem Ende der Erstellung eine solche Referenz
          noch vorhanden ist, schlägt der Erstellungsvorgang fehl.

          Sie eignen sich, um zu garantieren, dass ein Paket nicht
          fälschlich seine Abhängigkeiten aus der Erstellungszeit weiter
          referenziert, wenn das, zum Beispiel, die Größe unnötig in die
          Höhe treiben würde.

     Auch die meisten anderen Erstellungssysteme unterstützen diese
     Schlüsselwortargumente.

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

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

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

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

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

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

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

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

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

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

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

     Diese Variablen, die vom Modul ‘(guix build-system asdf)’
     exportiert werden, implementieren Erstellungsprozeduren für
     Common-Lisp-Pakete, welche „ASDF“
     (https://common-lisp.net/project/asdf/) benutzen. ASDF dient der
     Systemdefinition für Common-Lisp-Programme und -Bibliotheken.

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

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

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

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

     Vorgegeben ist, alle ‘.asd’-Dateien im Quellverzeichnis zu lesen,
     um zu ermitteln, welche Systeme definiert sind. Mit dem Parameter
     ‘#:asd-files’ kann die Liste zu lesender ‘.asd’-Dateien festgelegt
     werden. Außerdem wird bei Paketen, für deren Tests ein System in
     einer separaten Datei definiert wurde, dieses System geladen, bevor
     die Tests ablaufen, wenn es im Parameter ‘#:test-asd-file’ steht.
     Ist dafür kein Wert gesetzt, werden die Dateien
     ‘<system>-tests.asd’, ‘<system>-test.asd’, ‘tests.asd’ und
     ‘test.asd’ durchsucht, wenn sie existieren.

     Wenn aus irgendeinem Grund der Paketname nicht den
     Namenskonventionen folgen kann oder wenn mehrere Systeme kompiliert
     werden, kann der Parameter ‘#:asd-systems’ benutzt werden, um die
     Liste der Systemnamen anzugeben.

 -- Scheme-Variable: cargo-build-system
     Diese Variable wird vom Modul ‘(guix build-system cargo)’
     exportiert. Damit können Pakete mit Cargo erstellt werden, dem
     Erstellungswerkzeug der Rust-Programmiersprache
     (https://www.rust-lang.org).

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

     Normale cargo-Abhängigkeiten sollten so wie bei anderen Paketen in
     die Paketdefinition eingetragen werden; wenn sie nur zur
     Erstellungszeit gebraucht werden, gehören sie in ‘native-inputs’,
     sonst in ‘inputs’. Wenn die Abhängigkeiten Crates sind, die nur als
     Quellcode vorliegen, sollten sie zusätzlich über den Parameter
     ‘#:cargo-inputs’ als eine Liste von Paaren aus Name und
     Spezifikation hinzugefügt, wobei als Spezifikation ein Paket oder
     eine Quellcode-Definition angegeben werden kann. Beachten Sie, dass
     die Spezifikation zu einem mit gzip komprimierten Tarball
     ausgewertet werden muss, der eine Datei ‘Cargo.toml’ in seinem
     Wurzelverzeichnis enthält, ansonsten wird sie ignoriert. Analog
     sollten solche Abhängigkeiten, die in cargo als „dev-dependencies“
     deklariert werden, zur Paketdefinition über den Parameter
     ‘#:cargo-development-inputs’ hinzugefügt werden.

     In seiner ‘configure’-Phase sorgt dieses Erstellungssystem dafür,
     dass cargo alle Quellcodeeingaben zur Verfügung stehen, die in den
     Parametern ‘#:cargo-inputs’ und ‘#:cargo-development-inputs’
     angegeben wurden. Außerdem wird eine enthaltene ‘Cargo.lock’-Datei
     entfernt, damit ‘cargo’ selbige während der ‘build’-Phase neu
     erzeugt. Die ‘package’-Phase führt ‘cargo package’ aus, um eine
     Quellcode-Crate zur späteren Nutzung zu erzeugen. Die
     ‘install’-Phase installiert die in der Crate definierten
     Binärdateien. Wenn _nicht_ ‘install-source? #f’ definiert ist,
     werden auch ein Verzeichnis mit dem eigenen Quellcode in einer
     Crate und auch der unverpackte Quellcode installiert, damit es
     leichter ist, später an Rust-Paketen zu hacken.

 -- Scheme-Variable: chicken-build-system
     Diese Variable wird von ‘(guix build-system chicken)’ exportiert.
     Mit ihr werden Module von CHICKEN Scheme (https://call-cc.org/)
     kompiliert. Sie sind auch bekannt als „Eggs“ oder als
     „Erweiterungen“. CHICKEN erzeugt C-Quellcode, der dann von einem
     C-Compiler kompiliert wird; in diesem Fall vom GCC.

     Dieses Erstellungssystem fügt ‘chicken’ neben den Paketen des
     ‘gnu-build-system’ zu den Paketeingaben hinzu.

     Das Erstellungssystem kann den Namen des Eggs (noch) nicht
     automatisch herausfinden, also müssen Sie, ähnlich wie beim
     ‘#:import-path’ des ‘go-build-system’, im ‘arguments’-Feld des
     Pakets den ‘#:egg-name’ festlegen.

     Zum Beispiel würden Sie so vorgehen, um ein Paket für das Egg
     ‘srfi-1’ zu schreiben:

          (arguments '(#:egg-name "srfi-1"))

     Abhängigkeiten von Eggs müssen in ‘propagated-inputs’ genannt
     werden und _nicht_ in ‘inputs’, weil CHICKEN keine absoluten
     Referenzen in kompilierte Eggs einbettet. Abhängigkeiten für Tests
     sollten wie üblich in ‘native-inputs’ stehen.

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

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

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

        • Wenn die QUELLE einer Datei oder einem Verzeichnis ohne
          Schrägstrich am Ende entspricht, wird sie nach ZIEL
          installiert.
             • Hat das ZIEL einen Schrägstrich am Ende, wird mit dem
               Basisnamen der QUELLE innerhalb von ZIEL installiert.
             • Andernfalls wird die QUELLE als ZIEL installiert.

        • Falls es sich bei der QUELLE um ein Verzeichnis mit
          Schrägstrich am Ende handelt oder wenn FILTER benutzt werden,
          so ist der Schrägstrich am Ende von ZIEL mit der Bedeutung wie
          oben implizit.
             • Ohne Angabe von FILTERn wird der gesamte _Inhalt_ der
               QUELLE nach ZIEL installiert.
             • Werden FILTER als ‘#:include’, ‘#:include-regexp’,
               ‘#:exclude’ oder ‘#:exclude-regexp’ aufgeführt, werden je
               nach Filter nur die ausgewählten Dateien installiert.
               Jeder Filter wird als Liste von Zeichenketten angegeben.
                  • Bei ‘#:include’ werden all die Dateien installiert,
                    deren Pfad als Suffix zu mindestens einem der
                    Elemente der angegebenen Liste passt.
                  • Bei ‘#:include-regexp’ werden all die Dateien
                    installiert, deren Unterpfad zu mindestens einem der
                    regulären Ausdrücke in der angegebenen Liste passt.
                  • Die Filter ‘#:exclude’ und ‘#:exclude-regexp’
                    bewirken das Gegenteil ihrer Include-Entsprechungen.
                    Ohne ‘#:include’-Angaben werden alle Dateien außer
                    den zu den Exclude-Filtern passenden installiert.
                    Werden sowohl ‘#:include’ als auch ‘#:exclude’
                    angegeben, werden zuerst die ‘#:include’-Angaben
                    beachtet und danach wird durch ‘#:exclude’
                    gefiltert.
          In jedem Fall bleiben die Pfade relativ zur QUELLE innerhalb
          des ZIELs erhalten.

     Beispiele:

        • ‘("foo/bar" "share/my-app/")’: Installiert ‘bar’ nach
          ‘share/my-app/bar’.
        • ‘("foo/bar" "share/my-app/baz")’: Installiert ‘bar’ nach
          ‘share/my-app/baz’.
        • ‘("foo/" "share/my-app")’: Installiert den Inhalt von ‘foo’
          innerhalb von ‘share/my-app’. Zum Beispiel wird
          ‘foo/sub/datei’ nach ‘share/my-app/sub/datei’ installiert.
        • ‘("foo/" "share/my-app" #:include ("sub/datei"))’: Installiert
          nur ‘foo/sub/datei’ nach ‘share/my-app/sub/datei’.
        • ‘("foo/sub" "share/my-app" #:include ("datei"))’: Installiert
          ‘foo/sub/datei’ nach ‘share/my-app/datei’.

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

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

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

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

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

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

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

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

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

 -- Scheme-Variable: cmake-build-system
     Diese Variable wird von ‘(guix build-system cmake)’ exportiert. Sie
     implementiert die Erstellungsprozedur für Pakete, die das
     CMake-Erstellungswerkzeug (https://www.cmake.org) benutzen.

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

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

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

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

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

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

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

 -- Scheme-Variable: go-build-system
     Diese Variable wird vom Modul ‘(guix build-system go)’ exportiert.
     Mit ihr ist eine Erstellungsprozedur für Go-Pakete implementiert,
     die dem normalen Go-Erstellungsmechanismus
     (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies)
     entspricht.

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

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

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

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

     ‘glib-or-gtk-wrap’
          Die Phase ‘glib-or-gtk-wrap’ stellt sicher, dass Programme in
          ‘bin/’ in der Lage sind, GLib-„Schemata“ und GTK-Module
          (https://developer.gnome.org/gtk3/stable/gtk-running.html) zu
          finden. Dazu wird für das Programm ein Wrapper-Skript erzeugt,
          dass das eigentliche Programm mit den richtigen Werten für die
          Umgebungsvariablen ‘XDG_DATA_DIRS’ und ‘GTK_PATH’ aufruft.

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

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

     Beide Phasen finden nach der ‘install’-Phase statt.

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

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

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

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

     Der Name des Julia-Pakets wird aus der Datei ‘Project.toml’
     ausgelesen. Durch Angabe des Arguments ‘#:julia-package-name’ kann
     ein anderer Wert verwendet werden (die Groß-/Kleinschreibung muss
     stimmen).

     Julia-Pakete verwalten ihre Abhängigkeiten zu Binärdateien für
     gewöhnlich mittels ‘JLLWrappers.jl’, einem Julia-Paket, das ein
     Modul erzeugt (benannt nach der Bibliothek, die zugänglich gemacht
     wird, gefolgt von ‘_jll.jl’).

     Um die ‘_jll.jl’-Pakete mit den Pfaden zu Binärdateien
     hinzuzufügen, müssen Sie die Dateien in ‘src/wrappers/’ patchen, um
     dem Aufruf an das Makro ‘JLLWrappers.@generate_wrapper_header’ noch
     ein zweites Argument mit dem Store-Pfad der Binärdatei mitzugeben.

     Zum Beispiel fügen wir für das MbedTLS-Julia-Paket eine
     Erstellungsphase hinzu (siehe *note Erstellungsphasen::), in der
     der absolute Dateiname des zugänglich gemachten MbedTLS-Pakets
     hinzugefügt wird:

          (add-after 'unpack 'override-binary-path
            (lambda* (#:key inputs #:allow-other-keys)
              (for-each (lambda (wrapper)
                          (substitute* wrapper
                            (("generate_wrapper_header.*")
                             (string-append
                              "generate_wrapper_header(\"MbedTLS\", \""
                              (assoc-ref inputs "mbedtls-apache") "\")\n"))))
                        ;; Es gibt eine Julia-Datei für jede Plattform,
                        ;; wir ändern sie alle.
                        (find-files "src/wrappers/" "\\.jl$"))))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 -- Scheme-Variable: renpy-build-system
     Diese Variable wird vom Modul ‘(guix build-system renpy)’
     exportiert. Sie implementiert mehr oder weniger die herkömmliche
     Erstellungsprozedur, die für Ren’py-Spiele benutzt wird. Das
     bedeutet, das ‘#:game’ wird einmal geladen, wodurch Bytecode dafür
     erzeugt wird.

     Des Weiteren wird ein Wrapper-Skript in ‘bin/’ und eine
     *.desktop-Datei in ‘share/applications’ erzeugt. Mit beiden davon
     kann man das Spiel starten.

     Welches Ren’py-Paket benutzt wird, gibt man mit ‘#:renpy’ an.
     Spiele können auch in andere Ausgaben als in „out“ installiert
     werden, indem man ‘#:output’ benutzt.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 -- Scheme-Variable: emacs-build-system
     Diese Variable wird vom Modul ‘(guix build-system emacs)’
     exportiert. Darin wird eine Installationsprozedur ähnlich der des
     Paketsystems von Emacs selbst implementiert (siehe *note
     (emacs)Packages::).

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

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

 -- Scheme-Variable: meson-build-system
     Diese Variable wird vom Modul ‘(guix build-system meson)’
     exportiert. Sie enthält die Erstellungsprozedur für Pakete, die
     Meson (https://mesonbuild.com) als ihr Erstellungssystem benutzen.

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

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

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

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

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

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

     Dazu fügt das Erstellungssystem noch folgende neue Phasen:

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

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

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

 -- Scheme-Variable: linux-module-build-system
     Mit ‘linux-module-build-system’ können Linux-Kernelmodule erstellt
     werden.

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

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

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

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

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

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

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

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

 -- Scheme-Variable: trivial-build-system
     Diese Variable wird vom Modul ‘(guix build-system trivial)’
     exportiert.

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


File: guix.de.info,  Node: Erstellungsphasen,  Next: Werkzeuge zur Erstellung,  Prev: Erstellungssysteme,  Up: Programmierschnittstelle

8.5 Erstellungsphasen
=====================

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

   Wie im letzten Abschnitt erläutert, stellen diese Erstellungssysteme
eine standardisierte Liste von Phasen zur Verfügung. Für
‘gnu-build-system’ sind dies die hauptsächlichen Erstellungsphasen:

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

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

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

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

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

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

‘patch-shebangs’
     Shebangs in den installierten ausführbaren Dateien beheben.

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

   Andere Erstellungssysteme haben ähnliche, aber etwas unterschiedliche
Phasen. Zum Beispiel hat das ‘cmake-build-system’ gleichnamige Phasen,
aber seine ‘configure’-Phase führt ‘cmake’ statt ‘./configure’ aus.
Andere Erstellungssysteme wie z.B. ‘python-build-system’ haben eine
völlig andere Liste von Standardphasen. Dieser gesamte Code läuft
“erstellungsseitig”: Er wird dann ausgewertet, wenn Sie das Paket
wirklich erstellen, in einem eigenen Erstellungprozess nur dafür, den
der Erstellungs-Daemon erzeugt (siehe *note Aufruf des guix-daemon::).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   ---------- Footnotes ----------

   (1) Wir stellen hier nur eine vereinfachte Sicht auf diese
Erstellungsphasen vor. Wenn Sie alle Details wollen, schauen Sie sich
‘(guix build gnu-build-system)’ an!


File: guix.de.info,  Node: Werkzeuge zur Erstellung,  Next: Der Store,  Prev: Erstellungsphasen,  Up: Programmierschnittstelle

8.6 Werkzeuge zur Erstellung
============================

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

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

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

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

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

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

8.6.1 Umgehen mit Store-Dateinamen
----------------------------------

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

 -- Scheme-Prozedur: %store-directory
     Liefert den Verzeichnisnamen des Stores.

 -- Scheme-Prozedur: store-file-name? DATEI
     Liefert wahr zurück, wenn sich DATEI innerhalb des Stores befindet.

 -- Scheme-Prozedur: strip-store-file-name DATEI
     Liefert den Namen der DATEI, die im Store liegt, ohne den Anfang
     ‘/gnu/store’ und ohne die Prüfsumme am Namensanfang. Als Ergebnis
     ergibt sich typischerweise eine Zeichenkette aus ‘"PAKET-VERSION"’.

 -- Scheme-Prozedur: package-name->name+version NAME
     Liefert für den Paket-NAMEn (so etwas wie ‘"foo-0.9.1b"’) zwei
     Werte zurück: zum einen ‘"foo"’ und zum anderen ‘"0.9.1b"’. Wenn
     der Teil mit der Version fehlt, werden der NAME und ‘#f’
     zurückgeliefert. Am ersten Bindestrich, auf den eine Ziffer folgt,
     wird der Versionsteil abgetrennt.

8.6.2 Dateitypen
----------------

Bei den folgenden Prozeduren geht es um Dateien und Dateitypen.

 -- Scheme-Prozedur: directory-exists? VERZEICHNIS
     Liefert ‘#t’, wenn das VERZEICHNIS existiert und ein Verzeichnis
     ist.

 -- Scheme-Prozedur: executable-file? DATEI
     Liefert ‘#t’, wenn die DATEI existiert und ausführbar ist.

 -- Scheme-Prozedur: symbolic-link? DATEI
     Liefert ‘#t’, wenn die DATEI eine symbolische Verknüpfung ist (auch
     bekannt als „Symlink“).

 -- Scheme-Prozedur: elf-file? DATEI
 -- Scheme-Prozedur: ar-file? DATEI
 -- Scheme-Prozedur: gzip-file? DATEI
     Liefert ‘#t’, wenn die DATEI jeweils eine ELF-Datei, ein
     ‘ar’-Archiv (etwa eine statische Bibliothek mit ‘.a’) oder eine
     gzip-Datei ist.

 -- Scheme-Prozedur: reset-gzip-timestamp DATEI [#:keep-mtime? #t]
     Wenn die DATEI eine gzip-Datei ist, wird ihr eingebetteter
     Zeitstempel zurückgesetzt (wie bei ‘gzip --no-name’) und wahr
     geliefert. Ansonsten wird ‘#f’ geliefert. Wenn KEEP-MTIME? wahr
     ist, wird der Zeitstempel der letzten Modifikation von DATEI
     beibehalten.

8.6.3 Änderungen an Dateien
---------------------------

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

 -- Scheme-Syntax: with-directory-excursion VERZEICHNIS RUMPF…
     Den RUMPF ausführen mit dem VERZEICHNIS als aktuellem Verzeichnis
     des Prozesses.

     Im Grunde ändert das Makro das aktuelle Arbeitsverzeichnis auf
     VERZEICHNIS bevor der RUMPF ausgewertet wird, mittels ‘chdir’
     (siehe *note (guile)Processes::). Wenn der dynamische Bereich von
     RUMPF wieder verlassen wird, wechselt es wieder ins anfängliche
     Verzeichnis zurück, egal ob der RUMPF durch normales Zurückliefern
     eines Ergebnisses oder durch einen nichtlokalen Sprung wie etwa
     eine Ausnahme verlassen wurde.

 -- Scheme-Prozedur: mkdir-p VERZEICHNIS
     Das VERZEICHNIS und all seine Vorgänger erstellen.

 -- Scheme-Prozedur: install-file DATEI VERZEICHNIS
     VERZEICHNIS erstellen, wenn es noch nicht existiert, und die DATEI
     mit ihrem Namen dorthin kopieren.

 -- Scheme-Prozedur: make-file-writable DATEI
     Dem Besitzer der DATEI Schreibberechtigung darauf erteilen.

 -- Scheme-Prozedur: copy-recursively QUELLE ZIELORT [#:log
          (current-output-port)] [#:follow-symlinks? #f] [#:keep-mtime?
          #f] Das
     Verzeichnis QUELLE rekursiv an den ZIELORT kopieren. Wenn
     FOLLOW-SYMLINKS? wahr ist, folgt die Rekursion symbolischen
     Verknüpfungen, ansonsten werden die Verknüpfungen als solche
     beibehalten. Wenn KEEP-MTIME? wahr ist, bleibt der Zeitstempel der
     letzten Änderung an den Dateien in QUELLE dabei bei denen am
     ZIELORT erhalten. Ein ausführliches Protokoll wird in den bei LOG
     angegebenen Port geschrieben.

 -- Scheme-Prozedur: delete-file-recursively VERZEICHNIS
          [#:follow-mounts? #f] Das VERZEICHNIS rekursiv löschen, wie
          bei
     ‘rm -rf’, ohne symbolischen Verknüpfungen zu folgen. Auch
     Einhängepunkten wird _nicht_ gefolgt, außer falls FOLLOW-MOUNTS?
     wahr ist. Fehler dabei werden angezeigt aber ignoriert.

 -- Scheme-Syntax: substitute* DATEI ((REGEXP MUSTER-VARIABLE...)
          RUMPF…) … Den regulären
     Ausdruck REGEXP in der DATEI durch die durch RUMPF berechnete
     Zeichenkette ersetzen. Bei der Auswertung von RUMPF wird jede
     MUSTER-VARIABLE an den Teilausdruck an der entsprechenden Position
     der Regexp gebunden. Zum Beispiel:

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

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

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

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

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

8.6.4 Dateien suchen
--------------------

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

 -- Scheme-Prozedur: file-name-predicate REGEXP
     Liefert ein Prädikat, das gegeben einen Dateinamen, dessen
     Basisnamen auf REGEXP passt, wahr liefert.

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

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

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

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

     ;; ar-Dateien im aktuellen Verzeichnis auflisten.
     (find-files "." (lambda (file stat) (ar-file? file)))
     ⇒ ("./libformat.a" "./libstore.a" …)

 -- Scheme-Prozedur: which PROGRAMM
     Liefert den vollständigen Dateinamen für das PROGRAMM, der in
     ‘$PATH’ gesucht wird, oder ‘#f’, wenn das PROGRAMM nicht gefunden
     werden konnte.

8.6.5 Erstellungsphasen
-----------------------

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

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

 -- Scheme-Syntax: modify-phases PHASEN KLAUSEL…
     Die PHASEN der Reihe nach entsprechend jeder KLAUSEL ändern. Die
     Klauseln dürfen eine der folgenden Formen haben:

          (delete ALTER-PHASENNAME)
          (replace ALTER-PHASENNAME NEUE-PHASE)
          (add-before ALTER-PHASENNAME NEUER-PHASENNAME NEUE-PHASE)
          (add-after ALTER-PHASENNAME NEUER-PHASENNAME NEUE-PHASE)

     Jeder PHASENNAME oben ist ein Ausdruck, der zu einem Symbol
     auswertet, und NEUE-PHASE ist ein Ausdruck, der zu einer Prozedur
     auswertet.

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

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

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

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


File: guix.de.info,  Node: Der Store,  Next: Ableitungen,  Prev: Werkzeuge zur Erstellung,  Up: Programmierschnittstelle

8.7 Der Store
=============

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

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

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

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

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

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

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

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

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

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

          Die Befehlszeilenoption ‘--listen’ von ‘guix-daemon’ kann
          benutzt werden, damit er auf TCP-Verbindungen lauscht (siehe
          *note ‘--listen’: Aufruf des guix-daemon.).

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

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

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

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

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

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

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

 -- Scheme-Prozedur: close-connection SERVER
     Die Verbindung zum SERVER trennen.

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

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

 -- Scheme-Prozedur: valid-path? SERVER PFAD
     Liefert ‘#t’, wenn der PFAD ein gültiges Store-Objekt benennt, und
     sonst ‘#f’ (ein ungültiges Objekt kann auf der Platte gespeichert
     sein, tatsächlich aber ungültig sein, zum Beispiel weil es das
     Ergebnis einer abgebrochenen oder fehlgeschlagenen Erstellung ist).

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

 -- Scheme-Prozedur: add-text-to-store SERVER NAME TEXT [REFERENZEN]
     Den TEXT im Store in einer Datei namens NAME ablegen und ihren
     Store-Pfad zurückliefern. REFERENZEN ist die Liste der Store-Pfade,
     die der Store-Pfad dann referenzieren soll.

 -- Scheme-Prozedur: build-derivations STORE ABLEITUNGEN [MODUS] Die
          ABLEITUNGEN erstellen (eine Liste von
     ‘<derivation>’-Objekten, ‘.drv’-Dateinamen oder Paaren aus je
     Ableitung und Ausgabe. Dabei gilt der angegebene MODUS — vorgegeben
     ist ‘(build-mode normal)’.

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

   Dieser Abschnitt ist im Moment noch unvollständig.


File: guix.de.info,  Node: Ableitungen,  Next: Die Store-Monade,  Prev: Der Store,  Up: Programmierschnittstelle

8.8 Ableitungen
===============

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

   • Die Ausgaben, die die Ableitung hat. Ableitungen erzeugen
     mindestens eine Datei bzw. ein Verzeichnis im Store, können aber
     auch mehrere erzeugen.

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

   • Das System, wofür mit der Ableitung erstellt wird, also ihr Ziel —
     z.B. ‘x86_64-linux’.

   • Der Dateiname eines Erstellungsskripts im Store, zusammen mit den
     Argumenten, mit denen es aufgerufen werden soll.

   • Eine Liste zu definierender Umgebungsvariabler.

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

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

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

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

 -- Scheme-Prozedur: derivation STORE NAME ERSTELLER ARGUMENTE
          [#:outputs '("out")] [#:hash #f] [#:hash-algo #f]
          [#:recursive? #f] [#:inputs '()] [#:env-vars '()]  [#:system
     (%current-system)] [#:references-graphs #f]  [#:allowed-references
     #f] [#:disallowed-references #f]  [#:leaked-env-vars #f]
     [#:local-build? #f]  [#:substitutable? #t] [#:properties ’()] Eine
     Ableitungen mit den ARGUMENTEn erstellen und das resultierende
     ‘<derivation>’-Objekt liefern.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     AUSDRUCK wird mit einer Ableitung GUILE-FOR-BUILD erstellt. Wird
     kein GUILE-FOR-BUILD angegeben oder steht es auf ‘#f’, wird
     stattdessen der Wert der Fluiden ‘%guile-for-build’ benutzt.

     Siehe die Erklärungen zur Prozedur ‘derivation’ für die Bedeutung
     von REFERENCES-GRAPHS, ALLOWED-REFERENCES, DISALLOWED-REFERENCES,
     LOCAL-BUILD? und SUBSTITUTABLE?.

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

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

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


File: guix.de.info,  Node: Die Store-Monade,  Next: G-Ausdrücke,  Prev: Ableitungen,  Up: Programmierschnittstelle

8.9 Die Store-Monade
====================

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

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

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

   Betrachten Sie folgende „normale“ Prozedur:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 -- Scheme-Syntax: with-monad MONADE RUMPF ...
     Alle ‘>>=’- oder ‘return’-Formen im RUMPF in der MONADE auswerten.

 -- Scheme-Syntax: return WERT
     Einen monadischen Wert liefern, der den übergebenen WERT kapselt.

 -- Scheme-Syntax: >>= MWERT MPROZ ...
     Den monadischen Wert MWERT “binden”, wobei sein „Inhalt“ an die
     monadischen Prozeduren MPROZ… übergeben wird(1). Es kann eine
     einzelne MPROZ oder mehrere davon geben, wie in diesem Beispiel:

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

          ⇒ 4
          ⇒ irgendein-Zustand

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

     ‘mlet*’ verhält sich gegenüber ‘mlet’ wie ‘let*’ gegenüber ‘let’
     (siehe *note (guile)Local Bindings::).

 -- Scheme-System: mbegin MONADE MAUSDRUCK ...
     Der Reihe nach den MAUSDRUCK und die nachfolgenden monadischen
     Ausdrücke binden und als Ergebnis das des letzten Ausdrucks
     liefern. Jeder Ausdruck in der Abfolge muss ein monadischer
     Ausdruck sein.

     Dies verhält sich ähnlich wie ‘mlet’, außer dass die Rückgabewerte
     der monadischen Prozeduren ignoriert werden. In diesem Sinn verhält
     es sich analog zu ‘begin’, nur auf monadischen Ausdrücken.

 -- Scheme-System: mwhen BEDINGUNG MAUSDR0 MAUSDR* ...
     Wenn die BEDINGUNG wahr ist, wird die Folge monadischer Ausdrücke
     MAUSDR0..MAUSDR* wie bei ‘mbegin’ ausgewertet. Wenn die BEDINGUNG
     falsch ist, wird ‘*unspecified*’ („unbestimmt“) in der momentanen
     Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein
     monadischer Ausdruck sein.

 -- Scheme-System: munless BEDINGUNG MAUSDR0 MAUSDR* ...
     Wenn die BEDINGUNG falsch ist, wird die Folge monadischer Ausdrücke
     MAUSDR0..MAUSDR* wie bei ‘mbegin’ ausgewertet. Wenn die BEDINGUNG
     wahr ist, wird ‘*unspecified*’ („unbestimmt“) in der momentanen
     Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein
     monadischer Ausdruck sein.

   Das Modul ‘(guix monads)’ macht die “Zustandsmonade” (englisch „state
monad“) verfügbar, mit der ein zusätzlicher Wert — der Zustand — durch
die monadischen Prozeduraufrufe _gefädelt_ werden kann.

 -- Scheme-Variable: %state-monad
     Die Zustandsmonade. Prozeduren in der Zustandsmonade können auf den
     gefädelten Zustand zugreifen und ihn verändern.

     Betrachten Sie das folgende Beispiel. Die Prozedur ‘Quadrat’
     liefert einen Wert in der Zustandsmonade zurück. Sie liefert das
     Quadrat ihres Arguments, aber sie inkrementiert auch den momentanen
     Zustandswert:

          (define (Quadrat x)
            (mlet %state-monad ((Anzahl (current-state)))
              (mbegin %state-monad
                (set-current-state (+ 1 Anzahl))
                (return (* x x)))))

          (run-with-state (sequence %state-monad (map Quadrat (iota 3))) 0)
          ⇒ (0 1 4)
          ⇒ 3

     Wird das „durch“ die Zustandsmonade ‘%state-monad’ laufen gelassen,
     erhalten wir jenen zusätzlichen Zustandswert, der der Anzahl der
     Aufrufe von ‘Quadrat’ entspricht.

 -- Monadische Prozedur: current-state
     Liefert den momentanen Zustand als einen monadischen Wert.

 -- Monadische Prozedur: set-current-state WERT
     Setzt den momentanen Zustand auf WERT und liefert den vorherigen
     Zustand als einen monadischen Wert.

 -- Monadische Prozedur: state-push WERT
     Hängt den WERT vorne an den momentanen Zustand an, der eine Liste
     sein muss. Liefert den vorherigen Zustand als monadischen Wert.

 -- Monadische Prozedur: state-pop
     Entfernt einen Wert vorne vom momentanen Zustand und liefert ihn
     als monadischen Wert zurück. Dabei wird angenommen, dass es sich
     beim Zustand um eine Liste handelt.

 -- Scheme-Prozedur: run-with-state MWERT [ZUSTAND]
     Den monadischen Wert MWERT mit ZUSTAND als initialem Zustand laufen
     lassen. Dies liefert zwei Werte: den Ergebniswert und den
     Ergebniszustand.

   Die zentrale Schnittstelle zur Store-Monade, wie sie vom Modul ‘(guix
store)’ angeboten wird, ist die Folgende:

 -- Scheme-Variable: %store-monad
     Die Store-Monade — ein anderer Name für ‘%state-monad’.

     Werte in der Store-Monade kapseln Zugriffe auf den Store. Sobald
     ihre Wirkung gebraucht wird, muss ein Wert der Store-Monade
     „ausgewertet“ werden, indem er an die Prozedur ‘run-with-store’
     übergeben wird (siehe unten).

 -- Scheme-Prozedur: run-with-store STORE MWERT [#:guile-for-build]
          [#:system (%current-system)]
     Den MWERT, einen monadischen Wert in der Store-Monade, in der
     offenen Verbindung STORE laufen lassen.

 -- Monadische Prozedur: text-file NAME TEXT [REFERENZEN]
     Als monadischen Wert den absoluten Dateinamen im Store für eine
     Datei liefern, deren Inhalt der der Zeichenkette TEXT ist.
     REFERENZEN ist dabei eine Liste von Store-Objekten, die die
     Ergebnis-Textdatei referenzieren wird; der Vorgabewert ist die
     leere Liste.

 -- Monadische Prozedur: binary-file NAME DATEN [REFERENZEN]
     Den absoluten Dateinamen im Store als monadischen Wert für eine
     Datei liefern, deren Inhalt der des Byte-Vektors DATEN ist.
     REFERENZEN ist dabei eine Liste von Store-Objekten, die die
     Ergebnis-Binärdatei referenzieren wird; der Vorgabewert ist die
     leere Liste.

 -- Monadische Prozedur: interned-file DATEI [NAME] [#:recursive? #t]
          [#:select? (const #t)] Liefert den Namen der DATEI,
     nachdem sie in den Store interniert wurde. Dabei wird der NAME als
     ihr Store-Name verwendet, oder, wenn kein NAME angegeben wurde, der
     Basisname der DATEI.

     Ist RECURSIVE? wahr, werden in der DATEI enthaltene Dateien
     rekursiv hinzugefügt; ist die DATEI eine flache Datei und
     RECURSIVE? ist wahr, wird ihr Inhalt in den Store eingelagert und
     ihre Berechtigungs-Bits übernommen.

     Steht RECURSIVE? auf wahr, wird ‘(SELECT? DATEI STAT)’ für jeden
     Verzeichniseintrag aufgerufen, wobei DATEI der absolute Dateiname
     und STAT das Ergebnis von ‘lstat’ ist, außer auf den Einträgen, wo
     SELECT? keinen wahren Wert liefert.

     Folgendes Beispiel fügt eine Datei unter zwei verschiedenen Namen
     in den Store ein:

          (run-with-store (open-connection)
            (mlet %store-monad ((a (interned-file "README"))
                                (b (interned-file "README" "LEGU-MIN")))
              (return (list a b))))

          ⇒ ("/gnu/store/rwm…-README" "/gnu/store/44i…-LEGU-MIN")

   Das Modul ‘(guix packages)’ exportiert die folgenden paketbezogenen
monadischen Prozeduren:

 -- Monadische Prozedur: package-file PAKET [DATEI] [#:system
          (%current-system)] [#:target #f]  [#:output "out"] Liefert als
     monadischen Wert den absoluten Dateinamen der DATEI innerhalb des
     Ausgabeverzeichnisses OUTPUT des PAKETs. Wird keine DATEI
     angegeben, wird der Name des Ausgabeverzeichnisses OUTPUT für das
     PAKET zurückgeliefert. Ist TARGET wahr, wird sein Wert als das
     Zielsystem bezeichnendes Tripel zum Cross-Kompilieren benutzt.

     Beachten Sie, dass durch diese Prozedur das PAKET _nicht_ erstellt
     wird, also muss ihr Ergebnis keine bereits existierende Datei
     bezeichnen, kann aber. Wir empfehlen, diese Prozedur nur dann zu
     benutzen, wenn Sie wissen, was Sie tun.

 -- Monadische Prozedur: package->derivation PAKET [SYSTEM]
 -- Monadische Prozedur: package->cross-derivation PAKET ZIEL [SYSTEM]
          Monadische Version von ‘package-derivation’
     und ‘package-cross-derivation’ (siehe *note Pakete definieren::).

   ---------- Footnotes ----------

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


File: guix.de.info,  Node: G-Ausdrücke,  Next: Aufruf von guix repl,  Prev: Die Store-Monade,  Up: Programmierschnittstelle

8.10 G-Ausdrücke
================

Es gibt also „Ableitungen“, die eine Abfolge von Erstellungsaktionen
repräsentieren, die durchgeführt werden müssen, um ein Objekt im Store
zu erzeugen (siehe *note 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 *note Aufruf des
guix-daemon::).

   Wenig überraschend ist, dass wir diese Erstellungsaktionen gerne in
Scheme schreiben würden. Wenn wir das tun, bekommen wir zwei
verschiedene “Schichten” von Scheme-Code(1): den „wirtsseitigen Code“
(„host code“) — also Code, der Pakete definiert, mit dem Daemon
kommuniziert etc. — und den „erstellungsseitigen Code“ („build code“) —
also Code, der die Erstellungsaktionen auch wirklich umsetzt, indem
Dateien erstellt werden, ‘make’ aufgerufen wird und so weiter (siehe
*note Erstellungsphasen::).

   Um eine Ableitung und ihre Erstellungsaktionen zu beschreiben, muss
man normalerweise erstellungsseitigen Code im wirtsseitigen Code
einbetten. Das bedeutet, man behandelt den erstellungsseitigen Code als
Daten, was wegen der Homoikonizität von Scheme — dass Code genauso als
Daten repräsentiert werden kann — sehr praktisch ist. Doch brauchen wir
hier mehr als nur den normalen Quasimaskierungsmechanismus mit
‘quasiquote’ in Scheme, wenn wir Erstellungsausdrücke konstruieren
möchten.

   Das Modul ‘(guix gexp)’ implementiert “G-Ausdrücke”, eine Form von
S-Ausdrücken, die zu Erstellungsausdrücken angepasst wurden. G-Ausdrücke
(englisch „G-expressions“, kurz “Gexps”) setzen sich grundlegend aus
drei syntaktischen Formen zusammen: ‘gexp’, ‘ungexp’ und
‘ungexp-splicing’ (alternativ einfach: ‘#~’, ‘#$’ und ‘#$@’), die
jeweils mit ‘quasiquote’, ‘unquote’ und ‘unquote-splicing’ vergleichbar
sind (siehe *note ‘quasiquote’: (guile)Expression Syntax.). Es gibt aber
auch erhebliche Unterschiede:

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

   • Wenn ein abstraktes Objekt wie ein Paket oder eine Ableitung
     innerhalb eines G-Ausdrucks demaskiert wird, ist das Ergebnis davon
     dasselbe, wie wenn dessen Ausgabedateiname genannt worden wäre.

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

   Dieser Mechanismus ist nicht auf Pakete und Ableitung beschränkt: Es
können “Compiler” definiert werden, die weitere abstrakte,
hochsprachliche Objekte auf Ableitungen oder Dateien im Store
„herunterbrechen“, womit diese Objekte dann auch in G-Ausdrücken
eingefügt werden können. Zum Beispiel sind „dateiartige Objekte“ ein
nützlicher Typ solcher abstrakter Objekte. Mit ihnen können Dateien
leicht in den Store eingefügt und von Ableitungen und anderem
referenziert werden (siehe unten ‘local-file’ und ‘plain-file’).

   Zur Veranschaulichung dieser Idee soll uns dieses Beispiel eines
G-Ausdrucks dienen:

     (define build-exp
       #~(begin
           (mkdir #$output)
           (chdir #$output)
           (symlink (string-append #$coreutils "/bin/ls")
                    "list-files")))

   Indem wir diesen G-Ausdruck an ‘gexp->derivation’ übergeben, bekommen
wir eine Ableitung, die ein Verzeichnis mit genau einer symbolischen
Verknüpfung auf ‘/gnu/store/…-coreutils-8.22/bin/ls’ erstellt:

     (gexp->derivation "das-ding" build-exp)

   Wie man es erwarten würde, wird die Zeichenkette
‘"/gnu/store/…-coreutils-8.22"’ anstelle der Referenzen auf das Paket
COREUTILS im eigentlichen Erstellungscode eingefügt und COREUTILS
automatisch zu einer Eingabe der Ableitung gemacht. Genauso wird auch
‘#$output’ (was äquivalent zur Schreibweise ‘(ungexp output)’ ist)
ersetzt durch eine Zeichenkette mit dem Namen der Ausgabe der Ableitung.

   Im Kontext der Cross-Kompilierung bietet es sich an, zwischen
Referenzen auf die _native_ Erstellung eines Pakets — also der, die auf
dem Wirtssystem ausgeführt werden kann — und Referenzen auf
Cross-Erstellungen eines Pakets zu unterscheiden. Hierfür spielt ‘#+’
dieselbe Rolle wie ‘#$’, steht aber für eine Referenz auf eine native
Paketerstellung.

     (gexp->derivation "vi"
        #~(begin
            (mkdir #$output)
            (mkdir (string-append #$output "/bin"))
            (system* (string-append #+coreutils "/bin/ln")
                     "-s"
                     (string-append #$emacs "/bin/emacs")
                     (string-append #$output "/bin/vi")))
        #:target "aarch64-linux-gnu")

Im obigen Beispiel wird die native Erstellung der COREUTILS benutzt,
damit ‘ln’ tatsächlich auf dem Wirtssystem ausgeführt werden kann, aber
danach die cross-kompilierte Erstellung von EMACS referenziert.

   Eine weitere Funktionalität von G-Ausdrücken stellen “importierte
Module” dar. Manchmal will man bestimmte Guile-Module von der
„wirtsseitigen Umgebung“ im G-Ausdruck benutzen können, deswegen sollten
diese Module in die „erstellungsseitige Umgebung“ importiert werden. Die
‘with-imported-modules’-Form macht das möglich:

     (let ((build (with-imported-modules '((guix build utils))
                    #~(begin
                        (use-modules (guix build utils))
                        (mkdir-p (string-append #$output "/bin"))))))
       (gexp->derivation "leeres-Verzeichnis"
                         #~(begin
                             #$build
                             (display "Erfolg!\n")
                             #t)))

In diesem Beispiel wird das Modul ‘(guix build utils)’ automatisch in
die isolierte Erstellungsumgebung unseres G-Ausdrucks geholt, so dass
‘(use-modules (guix build utils))’ wie erwartet funktioniert.

   Normalerweise möchten Sie, dass der _Abschluss_ eines Moduls
importiert wird — also das Modul und alle Module, von denen es abhängt —
statt nur das Modul selbst. Ansonsten scheitern Versuche, das Modul zu
benutzen, weil seine Modulabhängigkeiten fehlen. Die Prozedur
‘source-module-closure’ berechnet den Abschluss eines Moduls, indem es
den Kopf seiner Quelldatei analysiert, deswegen schafft die Prozedur
hier Abhilfe:

     (use-modules (guix modules))   ;„source-module-closure“ verfügbar machen

     (with-imported-modules (source-module-closure
                              '((guix build utils)
                                (gnu build vm)))
       (gexp->derivation "etwas-mit-vm"
                         #~(begin
                             (use-modules (guix build utils)
                                          (gnu build vm))
                             …)))

   Auf die gleiche Art können Sie auch vorgehen, wenn Sie nicht bloß
reine Scheme-Module importieren möchten, sondern auch „Erweiterungen“
wie Guile-Anbindungen von C-Bibliotheken oder andere „vollumfängliche“
Pakete. Sagen wir, Sie bräuchten das Paket ‘guile-json’ auf der
Erstellungsseite, dann könnten Sie es hiermit bekommen:

     (use-modules (gnu packages guile))  ;für „guile-json“

     (with-extensions (list guile-json)
       (gexp->derivation "etwas-mit-json"
                         #~(begin
                             (use-modules (json))
                             …)))

   Die syntaktische Form, in der G-Ausdrücke konstruiert werden, ist im
Folgenden zusammengefasst.

 -- Scheme-Syntax: #~AUSDRUCK
 -- Scheme-Syntax: (gexp AUSDRUCK)
     Liefert einen G-Ausdruck, der den AUSDRUCK enthält. Der AUSDRUCK
     kann eine oder mehrere der folgenden Formen enthalten:

     ‘#$OBJEKT’
     ‘(ungexp OBJEKT)’
          Eine Referenz auf das OBJEKT einführen. Das OBJEKT kann einen
          der unterstützten Typen haben, zum Beispiel ein Paket oder
          eine Ableitung, so dass die ‘ungexp’-Form durch deren
          Ausgabedateiname ersetzt wird — z.B.
          ‘"/gnu/store/…-coreutils-8.22’.

          Wenn das OBJEKT eine Liste ist, wird diese durchlaufen und
          alle unterstützten Objekte darin auf diese Weise ersetzt.

          Wenn das OBJEKT ein anderer G-Ausdruck ist, wird sein Inhalt
          eingefügt und seine Abhängigkeiten zu denen des äußeren
          G-Ausdrucks hinzugefügt.

          Wenn das OBJEKT eine andere Art von Objekt ist, wird es so wie
          es ist eingefügt.

     ‘#$OBJEKT:AUSGABE’
     ‘(ungexp OBJEKT AUSGABE)’
          Dies verhält sich wie die Form oben, bezieht sich aber
          ausdrücklich auf die angegebene AUSGABE des OBJEKTs — dies ist
          nützlich, wenn das OBJEKT mehrere Ausgaben generiert (siehe
          *note Pakete mit mehreren Ausgaben.::).

     ‘#+OBJEKT’
     ‘#+OBJEKT:AUSGABE’
     ‘(ungexp-native OBJEKT)’
     ‘(ungexp-native OBJEKT AUSGABE)’
          Das Gleiche wie ‘ungexp’, jedoch wird im Kontext einer
          Cross-Kompilierung eine Referenz auf die _native_ Erstellung
          des OBJEKTs eingefügt.

     ‘#$output[:AUSGABE]’
     ‘(ungexp output [AUSGABE])’
          Fügt eine Referenz auf die angegebene AUSGABE dieser Ableitung
          ein, oder auf die Hauptausgabe, wenn keine AUSGABE angegeben
          wurde.

          Dies ist nur bei G-Ausdrücken sinnvoll, die an
          ‘gexp->derivation’ übergeben werden.

     ‘#$@LISTE’
     ‘(ungexp-splicing LISTE)’
          Das Gleiche wie oben, jedoch wird nur der Inhalt der LISTE in
          die äußere Liste eingespleißt.

     ‘#+@LISTE’
     ‘(ungexp-native-splicing LISTE)’
          Das Gleiche, aber referenziert werden native Erstellungen der
          Objekte in der LISTE.

     G-Ausdrücke, die mit ‘gexp’ oder ‘#~’ erzeugt wurden, sind zur
     Laufzeit Objekte vom Typ ‘gexp?’ (siehe unten).

 -- Scheme-Syntax: with-imported-modules MODULE RUMPF…
     Markiert die in RUMPF… definierten G-Ausdrücke, dass sie in ihrer
     Ausführungsumgebung die angegebenen MODULE brauchen.

     Jedes Objekt unter den MODULEn kann der Name eines Moduls wie
     ‘(guix build utils)’ sein, oder es kann nacheinander ein Modulname,
     ein Pfeil und ein dateiartiges Objekt sein:

          `((guix build utils)
            (guix gcrypt)
            ((guix config) => ,(scheme-file "config.scm"
                                            #~(define-module …))))

     Im Beispiel oben werden die ersten beiden Module vom Suchpfad
     genommen und das letzte aus dem angegebenen dateiartigen Objekt
     erzeugt.

     Diese Form hat einen _lexikalischen_ Sichtbarkeitsbereich: Sie
     wirkt sich auf die direkt in RUMPF… definierten G-Ausdrücke aus,
     aber nicht auf jene, die, sagen wir, in aus RUMPF… heraus
     aufgerufenen Prozeduren definiert wurden.

 -- Scheme-Syntax: with-extensions ERWEITERUNGEN RUMPF…
     Markiert die in RUMPF… definierten G-Ausdrücke, dass sie
     ERWEITERUNGEN in ihrer Erstellungs- und Ausführungsumgebung
     benötigen. ERWEITERUNGEN sind typischerweise eine Liste von
     Paketobjekten wie zum Beispiel die im Modul ‘(gnu packages guile)’
     definierten.

     Konkret werden die unter den ERWEITERUNGEN aufgeführten Pakete zum
     Ladepfad hinzugefügt, während die in RUMPF… aufgeführten
     importierten Module kompiliert werden und sie werden auch zum
     Ladepfad des von RUMPF… gelieferten G-Ausdrucks hinzugefügt.

 -- Scheme-Prozedur: gexp? OBJEKT
     Liefert ‘#t’, wenn das OBJEKT ein G-Ausdruck ist.

   G-Ausdrücke sind dazu gedacht, auf die Platte geschrieben zu werden,
entweder als Code, der eine Ableitung erstellt, oder als einfache
Dateien im Store. Die monadischen Prozeduren unten ermöglichen Ihnen das
(siehe *note Die Store-Monade::, wenn Sie mehr Informationen über
Monaden suchen).

 -- Monadische Prozedur: gexp->derivation NAME AUSDRUCK [#:system
          (%current-system)] [#:target #f] [#:graft? #t]  [#:hash #f]
     [#:hash-algo #f]  [#:recursive? #f] [#:env-vars ’()] [#:modules
     ’()]  [#:module-path ‘%load-path’]  [#:effective-version "2.2"]
      [#:references-graphs #f] [#:allowed-references #f]
      [#:disallowed-references #f]  [#:leaked-env-vars #f]
      [#:script-name (string-append NAME "-builder")]
      [#:deprecation-warnings #f]  [#:local-build? #f] [#:substitutable?
     #t]  [#:properties ’()] [#:guile-for-build #f] Liefert eine
     Ableitung unter dem NAMEn, die jeden AUSDRUCK (ein G-Ausdruck) mit
     GUILE-FOR-BUILD (eine Ableitung) für das SYSTEM erstellt; der
     AUSDRUCK wird dabei in einer Datei namens SCRIPT-NAME gespeichert.
     Wenn „TARGET“ wahr ist, wird es beim Cross-Kompilieren als
     Zieltripel für mit AUSDRUCK bezeichnete Pakete benutzt.

     MODULES gilt als veraltet; stattdessen sollte
     ‘with-imported-modules’ benutzt werden. Die Bedeutung ist, dass die
     MODULE im Ausführungskontext des AUSDRUCKs verfügbar gemacht
     werden; MODULES ist dabei eine Liste von Namen von Guile-Modulen,
     die im Modulpfad MODULE-PATH gesucht werden, um sie in den Store zu
     kopieren, zu kompilieren und im Ladepfad während der Ausführung des
     AUSDRUCKs verfügbar zu machen — z.B. ‘((guix build utils) (guix
     build gnu-build-system))’.

     EFFECTIVE-VERSION bestimmt, unter welcher Zeichenkette die
     Erweiterungen des AUSDRUCKs zum Suchpfad hinzugefügt werden (siehe
     ‘with-extensions’) — z.B. ‘"2.2"’.

     GRAFT? bestimmt, ob vom AUSDRUCK benannte Pakete veredelt werden
     sollen, falls Veredelungen zur Verfügung stehen.

     Ist REFERENCES-GRAPHS wahr, muss es eine Liste von Tupeln in einer
     der folgenden Formen sein:

          (DATEINAME PAKET)
          (DATEINAME PAKET AUSGABE)
          (DATEINAME ABLEITUNG)
          (DATEINAME ABLEITUNG AUSGABE)
          (DATEINAME STORE-OBJEKT)

     Bei jedem Element von REFERENCES-GRAPHS wird das rechts Stehende
     automatisch zu einer Eingabe des Erstellungsprozesses vom AUSDRUCK
     gemacht. In der Erstellungsumgebung enthält das, was mit DATEINAME
     bezeichnet wird, den Referenzgraphen des entsprechenden Objekts in
     einem einfachen Textformat.

     ALLOWED-REFERENCES muss entweder ‘#f’ oder eine Liste von
     Ausgabenamen und Paketen sein. Eine solche Liste benennt
     Store-Objekte, die das Ergebnis referenzieren darf. Jede Referenz
     auf ein nicht dort aufgeführtes Store-Objekt löst einen
     Erstellungsfehler aus. Genauso funktioniert DISALLOWED-REFERENCES,
     was eine Liste von Objekten sein kann, die von den Ausgaben nicht
     referenziert werden dürfen.

     DEPRECATION-WARNINGS bestimmt, ob beim Kompilieren von Modulen
     Warnungen angezeigt werden sollen, wenn auf als veraltet markierten
     Code zugegriffen wird. DEPRECATION-WARNINGS kann ‘#f’, ‘#t’ oder
     ‘'detailed’ (detailliert) sein.

     Die anderen Argumente verhalten sich wie bei ‘derivation’ (siehe
     *note Ableitungen::).

   Die im Folgenden erklärten Prozeduren ‘local-file’, ‘plain-file’,
‘computed-file’, ‘program-file’ und ‘scheme-file’ liefern “dateiartige
Objekte”. Das bedeutet, dass diese Objekte, wenn sie in einem G-Ausdruck
demaskiert werden, zu einer Datei im Store führen. Betrachten Sie zum
Beispiel diesen G-Ausdruck:

     #~(system* #$(file-append glibc "/sbin/nscd") "-f"
                #$(local-file "/tmp/my-nscd.conf"))

   Der Effekt hiervon ist, dass ‘/tmp/my-nscd.conf’ „interniert“ wird,
indem es in den Store kopiert wird. Sobald er umgeschrieben wurde, zum
Beispiel über ‘gexp->derivation’, referenziert der G-Ausdruck diese
Kopie im ‘/gnu/store’. Die Datei in ‘/tmp’ zu bearbeiten oder zu
löschen, hat dann keinen Effekt mehr darauf, was der G-Ausdruck tut.
‘plain-file’ kann in ähnlicher Weise benutzt werden, es unterscheidet
sich aber darin, dass dort der Prozedur der Inhalt der Datei als eine
Zeichenkette übergeben wird.

 -- Scheme-Prozedur: local-file DATEI [NAME] [#:recursive? #f]
          [#:select? (const #t)] Liefert ein Objekt, dass die lokale
     Datei DATEI repräsentiert und sie zum Store hinzufügen lässt;
     dieses Objekt kann in einem G-Ausdruck benutzt werden. Wurde für
     die DATEI ein relativer Dateiname als literaler Ausdruck angegeben,
     wird sie relativ zur Quelldatei gesucht, in der diese Form steht.
     Wurde die DATEI _nicht_ als literale Zeichenkette angegeben, wird
     sie zur Laufzeit relativ zum aktuellen Arbeitsverzeichnis gesucht.
     Die DATEI wird unter dem angegebenen NAMEn im Store abgelegt — als
     Vorgabe wird dabei der Basisname der DATEI genommen.

     Ist RECURSIVE? wahr, werden in der DATEI enthaltene Dateien
     rekursiv hinzugefügt; ist die DATEI eine flache Datei und
     RECURSIVE? ist wahr, wird ihr Inhalt in den Store eingelagert und
     ihre Berechtigungs-Bits übernommen.

     Steht RECURSIVE? auf wahr, wird ‘(SELECT? DATEI STAT)’ für jeden
     Verzeichniseintrag aufgerufen, wobei DATEI der absolute Dateiname
     und STAT das Ergebnis von ‘lstat’ ist, außer auf den Einträgen, wo
     SELECT? keinen wahren Wert liefert.

     Dies ist das deklarative Gegenstück zur monadischen Prozedur
     ‘interned-file’ (siehe *note ‘interned-file’: Die Store-Monade.).

 -- Scheme-Prozedur: plain-file NAME INHALT
     Liefert ein Objekt, das eine Textdatei mit dem angegebenen NAMEn
     repräsentiert, die den angegebenen INHALT hat (eine Zeichenkette
     oder ein Bytevektor), welche zum Store hinzugefügt werden soll.

     Dies ist das deklarative Gegenstück zu ‘text-file’.

 -- Scheme-Prozedur: computed-file NAME G-AUSDRUCK [#:local-build? #t]
          [#:options '()] Liefert ein Objekt, das das Store-Objekt
     mit dem NAMEn repräsentiert, eine Datei oder ein Verzeichnis, das
     vom G-AUSDRUCK berechnet wurde. Wenn LOCAL-BUILD? auf wahr steht
     (wie vorgegeben), wird auf der lokalen Maschine erstellt. OPTIONS
     ist eine Liste zusätzlicher Argumente, die an ‘gexp->derivation’
     übergeben werden.

     Dies ist das deklarative Gegenstück zu ‘gexp->derivation’.

 -- Monadische Prozedur: gexp->script NAME AUSDRUCK [#:guile
          (default-guile)] [#:module-path %load-path]  [#:system
     (%current-system)] [#:target #f] Liefert ein ausführbares Skript
     namens NAME, das den AUSDRUCK mit dem angegebenen GUILE ausführt,
     wobei vom AUSDRUCK importierte Module in seinem Suchpfad stehen.
     Die Module des AUSDRUCKs werden dazu im Modulpfad MODULE-PATH
     gesucht.

     Folgendes Beispiel erstellt ein Skript, das einfach nur den Befehl
     ‘ls’ ausführt:

          (use-modules (guix gexp) (gnu packages base))

          (gexp->script "list-files"
                        #~(execl #$(file-append coreutils "/bin/ls")
                                 "ls"))

     Lässt man es durch den Store „laufen“ (siehe *note
     ‘run-with-store’: Die Store-Monade.), erhalten wir eine Ableitung,
     die eine ausführbare Datei ‘/gnu/store/…-list-files’ generiert,
     ungefähr so:

          #!/gnu/store/…-guile-2.0.11/bin/guile -ds
          !#
          (execl "/gnu/store/…-coreutils-8.22"/bin/ls" "ls")

 -- Scheme-Prozedur: program-file NAME G-AUSDRUCK [#:guile #f]
          [#:module-path %load-path] Liefert ein Objekt, das eine
     ausführbare Store-Datei NAME repräsentiert, die den G-AUSDRUCK
     ausführt. GUILE ist das zu verwendende Guile-Paket, mit dem das
     Skript ausgeführt werden kann. Importierte Module des G-AUSDRUCKs
     werden im Modulpfad MODULE-PATH gesucht.

     Dies ist das deklarative Gegenstück zu ‘gexp->script’.

 -- Monadische Prozedur: gexp->file NAME G-AUSDRUCK [#:set-load-path?
          #t] [#:module-path %load-path]  [#:splice? #f]  [#:guile
     (default-guile)] Liefert eine Ableitung, die eine Datei NAME
     erstellen wird, deren Inhalt der G-AUSDRUCK ist. Ist SPLICE? wahr,
     dann wird G-AUSDRUCK stattdessen als eine Liste von mehreren
     G-Ausdrücken behandelt, die alle in die resultierende Datei
     gespleißt werden.

     Ist SET-LOAD-PATH? wahr, wird in die resultierende Datei Code
     hinzugefügt, der den Ladepfad ‘%load-path’ und den Ladepfad für
     kompilierte Dateien ‘%load-compiled-path’ festlegt, die für die
     importierten Module des G-AUSDRUCKs nötig sind. Die Module des
     G-AUSDRUCKs werden im Modulpfad MODULE-PATH gesucht.

     Die resultierende Datei referenziert alle Abhängigkeiten des
     G-AUSDRUCKs oder eine Teilmenge davon.

 -- Scheme-Prozedur: scheme-file NAME AUSDRUCK [#:splice? #f]
          [#:set-load-path? #t] Liefert ein Objekt, das die
     Scheme-Datei NAME mit dem G-AUSDRUCK als Inhalt repräsentiert.

     Dies ist das deklarative Gegenstück zu ‘gexp->file’.

 -- Monadische Prozedur: text-file* NAME TEXT …
     Liefert eine Ableitung als monadischen Wert, welche eine Textdatei
     erstellt, in der der gesamte TEXT enthalten ist. TEXT kann eine
     Folge nicht nur von Zeichenketten, sondern auch Objekten beliebigen
     Typs sein, die in einem G-Ausdruck benutzt werden können, also
     Paketen, Ableitungen, Objekte lokaler Dateien und so weiter. Die
     resultierende Store-Datei referenziert alle davon.

     Diese Variante sollte gegenüber ‘text-file’ bevorzugt verwendet
     werden, wann immer die zu erstellende Datei Objekte im Store
     referenzieren wird. Typischerweise ist das der Fall, wenn eine
     Konfigurationsdatei erstellt wird, die Namen von Store-Dateien
     enthält, so wie hier:

          (define (profile.sh)
            ;; Liefert den Namen eines Shell-Skripts im Store,
            ;; welcher die Umgebungsvariable „PATH“ initialisiert.
            (text-file* "profile.sh"
                        "export PATH=" coreutils "/bin:"
                        grep "/bin:" sed "/bin\n"))

     In diesem Beispiel wird die resultierende Datei
     ‘/gnu/store/…-profile.sh’ sowohl COREUTILS, GREP als auch SED
     referenzieren, so dass der Müllsammler diese nicht löscht, während
     die resultierende Datei noch lebendig ist.

 -- Scheme-Prozedur: mixed-text-file NAME TEXT …
     Liefert ein Objekt, was die Store-Datei NAME repräsentiert, die
     TEXT enthält. TEXT ist dabei eine Folge von Zeichenketten und
     dateiartigen Objekten wie zum Beispiel:

          (mixed-text-file "profile"
                           "export PATH=" coreutils "/bin:" grep "/bin")

     Dies ist das deklarative Gegenstück zu ‘text-file*’.

 -- Scheme-Prozedur: file-union NAME DATEIEN
     Liefert ein ‘<computed-file>’, das ein Verzeichnis mit allen
     DATEIEN enthält. Jedes Objekt in DATEIEN muss eine zweielementige
     Liste sein, deren erstes Element der im neuen Verzeichnis zu
     benutzende Dateiname ist und deren zweites Element ein G-Ausdruck
     ist, der die Zieldatei benennt. Hier ist ein Beispiel:

          (file-union "etc"
                      `(("hosts" ,(plain-file "hosts"
                                              "127.0.0.1 localhost"))
                        ("bashrc" ,(plain-file "bashrc"
                                               "alias ls='ls --color=auto'"))))

     Dies liefert ein Verzeichnis ‘etc’, das zwei Dateien enthält.

 -- Scheme-Prozedur: directory-union NAME DINGE
     Liefert ein Verzeichnis, was die Vereinigung (englisch „Union“) der
     DINGE darstellt, wobei DINGE eine Liste dateiartiger Objekte sein
     muss, die Verzeichnisse bezeichnen. Zum Beispiel:

          (directory-union "guile+emacs" (list guile emacs))

     Das liefert ein Verzeichnis, welches die Vereinigung der Pakete
     ‘guile’ und ‘emacs’ ist.

 -- Scheme-Prozedur: file-append OBJEKT SUFFIX …
     Liefert ein dateiartiges Objekt, das zur Aneinanderreihung von
     OBJEKT und SUFFIX umgeschrieben wird, wobei das OBJEKT ein
     herunterbrechbares Objekt und jedes SUFFIX eine Zeichenkette sein
     muss.

     Betrachten Sie zum Beispiel diesen G-Ausdruck:

          (gexp->script "uname-ausfuehren"
                        #~(system* #$(file-append coreutils
                                                  "/bin/uname")))

     Denselben Effekt könnte man erreichen mit:

          (gexp->script "uname-ausfuehren"
                        #~(system* (string-append #$coreutils
                                                  "/bin/uname")))

     Es gibt jedoch einen Unterschied, nämlich enthält das resultierende
     Skript bei ‘file-append’ tatsächlich den absoluten Dateinamen als
     Zeichenkette, während im anderen Fall das resultierende Skript
     einen Ausdruck ‘(string-append …)’ enthält, der den Dateinamen erst
     _zur Laufzeit_ zusammensetzt.

 -- Scheme-Syntax: let-system SYSTEM RUMPF…
 -- Scheme-Syntax: let-system (SYSTEM ZIELSYSTEM) RUMPF…
     SYSTEM an das System binden, für das momentan erstellt wird — z.B.
     ‘"x86_64-linux"’ —, während der RUMPF ausgeführt wird.

     In der zweiten Form wird zusätzlich das ZIEL an das aktuelle Ziel
     („Target“) bei der Cross-Kompilierung gebunden. Dabei handelt es
     sich um ein GNU-Tripel wie z.B. ‘"arm-linux-gnueabihf"’ — oder um
     ‘#f’, wenn nicht cross-kompiliert wird.

     ‘let-system’ zu benutzen, bietet sich dann an, wenn einmal das in
     den G-Ausdruck gespleißte Objekt vom Zielsystem abhängen sollte,
     wie in diesem Beispiel:

          #~(system*
             #+(let-system system
                 (cond ((string-prefix? "armhf-" system)
                        (file-append qemu "/bin/qemu-system-arm"))
                       ((string-prefix? "x86_64-" system)
                        (file-append qemu "/bin/qemu-system-x86_64"))
                       (else
                        (error "weiß nicht!"))))
             "-net" "user" #$image)

 -- Scheme-Syntax: with-parameters ((PARAMETER WERT) …) AUSDRUCK
     Mit diesem Makro verhält es sich ähnlich wie mit der
     ‘parameterize’-Form für dynamisch gebundene “Parameter” (siehe
     *note (guile)Parameters::). Der Hauptunterschied ist, dass es sich
     erst auswirkt, wenn das vom AUSDRUCK zurückgelieferte dateiartige
     Objekt auf eine Ableitung oder ein Store-Objekt heruntergebrochen
     wird.

     Eine typische Anwendung von ‘with-parameters’ ist, den für ein
     bestimmtes Objekt geltenden Systemtyp zwingend festzulegen:

          (with-parameters ((%current-system "i686-linux"))
            coreutils)

     Obiges Beispiel liefert ein Objekt, das der Erstellung von
     Coreutils für die i686-Architektur entspricht, egal was der
     aktuelle Wert von ‘%current-system’ ist.

   Natürlich gibt es zusätzlich zu in „wirtsseitigem“ Code eingebetteten
G-Ausdrücken auch Module mit „erstellungsseitig“ nutzbaren Werkzeugen.
Um klarzustellen, dass sie dafür gedacht sind, in der Erstellungsschicht
benutzt zu werden, bleiben diese Module im Namensraum ‘(guix build …)’.

   Intern werden hochsprachliche, abstrakte Objekte mit ihrem Compiler
entweder zu Ableitungen oder zu Store-Objekten “heruntergebrochen”. Wird
zum Beispiel ein Paket heruntergebrochen, bekommt man eine Ableitung,
während ein ‘plain-file’ zu einem Store-Objekt heruntergebrochen wird.
Das wird mit der monadischen Prozedur ‘lower-object’ bewerkstelligt.

 -- Monadische Prozedur: lower-object OBJEKT [SYSTEM] [#:target #f]
          Liefert die Ableitung oder das Store-Objekt, das dem
     OBJEKT für SYSTEM als Wert in der Store-Monade ‘%store-monad’
     entspricht, cross-kompiliert für das Zieltripel TARGET, wenn TARGET
     wahr ist. Das OBJEKT muss ein Objekt sein, für das es einen mit ihm
     assoziierten G-Ausdruck-Compiler gibt, wie zum Beispiel ein
     ‘<package>’.

   ---------- Footnotes ----------

   (1) Der Begriff “Schicht”, englisch Stratum, wurde in diesem Kontext
von Manuel Serrano et al. in ihrer Arbeit an Hop geprägt. Oleg Kiselyov,
der aufschlussreiche Essays und Code zu diesem Thema
(http://okmij.org/ftp/meta-programming/#meta-scheme) geschrieben hat,
nennt diese Art der Code-Generierung “Staging”, deutsch etwa
Inszenierung bzw. Aufführung.


File: guix.de.info,  Node: Aufruf von guix repl,  Prev: G-Ausdrücke,  Up: Programmierschnittstelle

8.11 ‘guix repl’ aufrufen
=========================

Der Befehl ‘guix repl’ erleichtert es, Guix von Guile aus zu
programmieren. Dazu startet er eine Guile-REPL (“Read-Eval-Print Loop”,
kurz REPL, deutsch Lese-Auswerten-Schreiben-Schleife) zur interaktiven
Programmierung (siehe *note (guile)Using Guile Interactively::) oder er
führt Guile-Skripts aus (siehe *note (guile)Running Guile Scripts::). Im
Vergleich dazu, einfach den Befehl ‘guile’ aufzurufen, garantiert ‘guix
repl’, dass alle Guix-Module und deren Abhängigkeiten im Suchpfad
verfügbar sind.

   Die allgemeine Syntax lautet:

     guix repl OPTIONEN [DATEI ARGUMENTE]

   Wird ein DATEI-Argument angegeben, wird die angegebene DATEI als
Guile-Skript ausgeführt.

     guix repl my-script.scm

   Um Argumente an das Skript zu übergeben, geben Sie davor ‘--’ an,
damit Sie nicht als Argumente an ‘guix repl’ verstanden werden:

     guix repl -- my-script.scm --input=foo.txt

   Wenn Sie möchten, dass ein Skript direkt aus der Shell heraus
ausgeführt werden kann und diejenige ausführbare Datei von Guix benutzt
wird, die sich im Suchpfad des Benutzers befindet, dann fügen Sie die
folgenden zwei Zeilen ganz oben ins Skript ein.

     #!/usr/bin/env -S guix repl --
     !#

   Ohne einen Dateinamen als Argument wird eine Guile-REPL gestartet:

     $ guix repl
     scheme@(guile-user)> ,use (gnu packages base)
     scheme@(guile-user)> coreutils
     $1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

   ‘guix repl’ implementiert zusätzlich ein einfaches maschinenlesbares
Protokoll für die REPL, das von ‘(guix inferior)’ benutzt wird, um mit
“Untergeordneten” zu interagieren, also mit getrennten Prozessen einer
womöglich anderen Version von Guix.

   Folgende OPTIONEN gibt es:

‘--type=TYP’
‘-t TYP’
     Startet eine REPL des angegebenen TYPs, der einer der Folgenden
     sein darf:

     ‘guile’
          Die Voreinstellung, mit der eine normale, voll funktionsfähige
          Guile-REPL gestartet wird.
     ‘machine’
          Startet eine REPL, die ein maschinenlesbares Protokoll
          benutzt. Dieses Protokoll wird vom Modul ‘(guix inferior)’
          gesprochen.

‘--listen=ENDPUNKT’
     Der Vorgabe nach würde ‘guix repl’ von der Standardeingabe lesen
     und auf die Standardausgabe schreiben. Wird diese
     Befehlszeilenoption angegeben, lauscht die REPL stattdessen auf dem
     ENDPUNKT auf Verbindungen. Hier sind Beispiele gültiger
     Befehlszeilenoptionen:

     ‘--listen=tcp:37146’
          Verbindungen mit dem „localhost“ auf Port 37146 akzeptieren.

     ‘--listen=unix:/tmp/socket’
          Verbindungen zum Unix-Socket ‘/tmp/socket’ akzeptieren.

‘--load-path=VERZEICHNIS’
‘-L VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für Skript oder REPL sichtbar sind.

‘-q’
     Das Laden der ‘~/.guile’-Datei unterdrücken. Nach Voreinstellung
     würde diese Konfigurationsdatei beim Erzeugen einer REPL für
     ‘guile’ geladen.


File: guix.de.info,  Node: Zubehör,  Next: Systemkonfiguration,  Prev: Programmierschnittstelle,  Up: Top

9 Zubehör
*********

Dieser Abschnitt beschreibt die Befehlszeilenwerkzeuge von Guix. Manche
davon richten sich hauptsächlich an Entwickler und solche Nutzer, die
neue Paketdefinitionen schreiben, andere sind auch für ein breiteres
Publikum nützlich. Sie ergänzen die Scheme-Programmierschnittstelle um
bequeme Befehle.

* Menu:

* Aufruf von guix build::    Pakete aus der Befehlszeile heraus erstellen.
* Aufruf von guix edit::     Paketdefinitionen bearbeiten.
* Aufruf von guix download::  Eine Datei herunterladen und ihre
                                Hash-Prüfsumme ausgeben.
* Aufruf von guix hash::     Die kryptografische Prüfsumme 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


File: guix.de.info,  Node: Aufruf von guix build,  Next: Aufruf von guix edit,  Up: Zubehör

9.1 Aufruf von ‘guix build’
===========================

Der Befehl ‘guix build’ lässt Pakete oder Ableitungen samt ihrer
Abhängigkeiten erstellen und gibt die resultierenden Pfade im Store aus.
Beachten Sie, dass das Nutzerprofil dadurch nicht modifiziert wird —
eine solche Installation bewirkt der Befehl ‘guix package’ (siehe *note
Aufruf von guix package::). ‘guix build’ wird also hauptsächlich von
Entwicklern der Distribution benutzt.

   Die allgemeine Syntax lautet:

     guix build OPTIONEN PAKET-ODER-ABLEITUNG…

   Zum Beispiel wird mit folgendem Befehl die neueste Version von Emacs
und von Guile erstellt, das zugehörige Erstellungsprotokoll angezeigt
und letztendlich werden die resultierenden Verzeichnisse ausgegeben:

     guix build emacs guile

   Folgender Befehl erstellt alle Pakete, die zur Verfügung stehen:

     guix build --quiet --keep-going \
       $(guix package -A | cut -f1,2 --output-delimiter=@)

   Als PAKET-ODER-ABLEITUNG muss entweder der Name eines in der
Software-Distribution zu findenden Pakets, wie etwa ‘coreutils’ oder
‘coreutils@8.20’, oder eine Ableitung wie
‘/gnu/store/…-coreutils-8.19.drv’ sein. Im ersten Fall wird nach einem
Paket mit entsprechendem Namen (und optional der entsprechenden Version)
in den Modulen der GNU-Distribution gesucht (siehe *note Paketmodule::).

   Alternativ kann die Befehlszeilenoption ‘--expression’ benutzt
werden, um einen Scheme-Ausdruck anzugeben, der zu einem Paket
ausgewertet wird; dies ist nützlich, wenn zwischen mehreren
gleichnamigen Paketen oder Paket-Varianten unterschieden werden muss.

   Null oder mehr OPTIONEN können angegeben werden. Zur Verfügung stehen
die in den folgenden Unterabschnitten beschriebenen
Befehlszeilenoptionen.

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


File: guix.de.info,  Node: Gemeinsame Erstellungsoptionen,  Next: Paketumwandlungsoptionen,  Up: Aufruf von guix build

9.1.1 Gemeinsame Erstellungsoptionen
------------------------------------

Einige dieser Befehlszeilenoptionen zur Steuerung des Erstellungsprozess
haben ‘guix build’ und andere Befehle, mit denen Erstellungen ausgelöst
werden können, wie ‘guix package’ oder ‘guix archive’, gemeinsam. Das
sind folgende:

‘--load-path=VERZEICHNIS’
‘-L VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar
     sind.

‘--keep-failed’
‘-K’
     Den Verzeichnisbaum, in dem fehlgeschlagene Erstellungen
     durchgeführt wurden, behalten. Wenn also eine Erstellung
     fehlschlägt, bleibt ihr Erstellungsbaum in ‘/tmp’ erhalten. Der
     Name dieses Unterverzeichnisses wird am Ende dem
     Erstellungsprotokolls ausgegeben. Dies hilft bei der Suche nach
     Fehlern in Erstellungen. Der Abschnitt *note Fehlschläge beim
     Erstellen untersuchen:: zeigt Ihnen Hinweise und Tricks, wie
     Erstellungsfehler untersucht werden können.

     Diese Option impliziert ‘--no-offload’ und sie hat keine
     Auswirkungen, wenn eine Verbindung zu einem entfernten Daemon über
     eine ‘guix://’-URI verwendet wurde (siehe *note die
     ‘GUIX_DAEMON_SOCKET’-Variable: Der Store.).

‘--keep-going’
‘-k’
     Weitermachen, auch wenn ein Teil der Erstellungen fehlschlägt. Das
     bedeutet, dass der Befehl erst terminiert, wenn alle Erstellungen
     erfolgreich oder mit Fehler durchgeführt wurden.

     Das normale Verhalten ist, abzubrechen, sobald eine der angegebenen
     Ableitungen fehlschlägt.

‘--dry-run’
‘-n’
     Die Ableitungen nicht erstellen.

‘--fallback’
     Wenn das Substituieren vorerstellter Binärdateien fehlschlägt,
     diese ersatzweise lokal selbst erstellen (siehe *note Fehler bei
     der Substitution::).

‘--substitute-urls=URLS’
     Die URLS als durch Leerraumzeichen getrennte Liste von Quell-URLs
     für Substitute anstelle der vorgegebenen URL-Liste für den
     ‘guix-daemon’ verwenden (siehe *note ‘guix-daemon’ URLs:
     daemon-substitute-urls.).

     Das heißt, die Substitute dürfen von den URLS heruntergeladen
     werden, sofern sie mit einem durch den Systemadministrator
     autorisierten Schlüssel signiert worden sind (siehe *note
     Substitute::).

     Wenn als URLS eine leere Zeichenkette angegeben wurde, verhält es
     sich, als wären Substitute abgeschaltet.

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

‘--no-grafts’
     Pakete nicht „veredeln“ (engl. „graft“). Praktisch heißt das, dass
     als Veredelungen verfügbare Paketaktualisierungen nicht angewandt
     werden. Der Abschnitt *note Sicherheitsaktualisierungen:: hat
     weitere Informationen zu Veredelungen.

‘--rounds=N’
     Jede Ableitung N-mal nacheinander erstellen und einen Fehler
     melden, wenn die aufeinanderfolgenden Erstellungsergebnisse nicht
     Bit für Bit identisch sind.

     Das ist eine nützliche Methode, um nicht-deterministische
     Erstellungsprozesse zu erkennen. Nicht-deterministische
     Erstellungsprozesse sind ein Problem, weil Nutzer dadurch praktisch
     nicht _verifizieren_ können, ob von Drittanbietern bereitgestellte
     Binärdateien unverfälscht sind. Der Abschnitt *note Aufruf von guix
     challenge:: erklärt dies genauer.

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

‘--no-offload’
     Nicht versuchen, an andere Maschinen ausgelagerte Erstellungen zu
     benutzen (siehe *note Auslagern des Daemons einrichten::). Somit
     wird lokal erstellt, statt Erstellungen auf entfernte Maschinen
     auszulagern.

‘--max-silent-time=SEKUNDEN’
     Wenn der Erstellungs- oder Substitutionsprozess länger als
     SEKUNDEN-lang keine Ausgabe erzeugt, wird er abgebrochen und ein
     Fehler beim Erstellen gemeldet.

     Standardmäßig wird die Einstellung für den Daemon benutzt (siehe
     *note ‘--max-silent-time’: Aufruf des guix-daemon.).

‘--timeout=SEKUNDEN’
     Entsprechend wird hier der Erstellungs- oder Substitutionsprozess
     abgebrochen und als Fehlschlag gemeldet, wenn er mehr als
     SEKUNDEN-lang dauert.

     Standardmäßig wird die Einstellung für den Daemon benutzt (siehe
     *note ‘--timeout’: Aufruf des guix-daemon.).

‘-v STUFE’
‘--verbosity=STUFE’
     Die angegebene Ausführlichkeitsstufe verwenden. Als STUFE muss eine
     ganze Zahl angegeben werden. Wird 0 gewählt, wird keine Ausgabe zur
     Fehlersuche angezeigt, 1 bedeutet eine knappe Ausgabe, 2 ist wie 1,
     aber zeigt zusätzlich an, von welcher URL heruntergeladen wird, und
     3 lässt alle Erstellungsprotokollausgaben auf die
     Standardfehlerausgabe schreiben.

‘--cores=N’
‘-c N’
     Die Nutzung von bis zu N Prozessorkernen für die Erstellungen
     gestatten. Der besondere Wert ‘0’ bedeutet, dass so viele wie
     möglich benutzt werden.

‘--max-jobs=N’
‘-M N’
     Höchstens N gleichzeitige Erstellungsaufträge erlauben. Im
     Abschnitt *note ‘--max-jobs’: Aufruf des guix-daemon. finden Sie
     Details zu dieser Option und der äquivalenten Option des
     ‘guix-daemon’.

‘--debug=STUFE’
     Ein Protokoll zur Fehlersuche ausgeben, das vom Erstellungsdaemon
     kommt. Als STUFE muss eine ganze Zahl zwischen 0 und 5 angegeben
     werden; höhere Zahlen stehen für ausführlichere Ausgaben. Stufe 4
     oder höher zu wählen, kann bei der Suche nach Fehlern, wie der
     Erstellungs-Daemon eingerichtet ist, helfen.

   Intern ist ‘guix build’ im Kern eine Schnittstelle zur Prozedur
‘package-derivation’ aus dem Modul ‘(guix packages)’ und zu der Prozedur
‘build-derivations’ des Moduls ‘(guix derivations)’.

   Neben auf der Befehlszeile übergebenen Optionen beachten ‘guix build’
und andere ‘guix’-Befehle, die Erstellungen durchführen lassen, die
Umgebungsvariable ‘GUIX_BUILD_OPTIONS’.

 -- Umgebungsvariable: GUIX_BUILD_OPTIONS
     Nutzer können diese Variable auf eine Liste von
     Befehlszeilenoptionen definieren, die automatisch von ‘guix build’
     und anderen ‘guix’-Befehlen, die Erstellungen durchführen lassen,
     benutzt wird, wie in folgendem Beispiel:

          $ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

     Diese Befehlszeilenoptionen werden unabhängig von den auf der
     Befehlszeile übergebenen Befehlszeilenoptionen grammatikalisch
     analysiert und das Ergebnis an die bereits analysierten auf der
     Befehlszeile übergebenen Befehlszeilenoptionen angehängt.


File: guix.de.info,  Node: Paketumwandlungsoptionen,  Next: Zusätzliche Erstellungsoptionen,  Prev: Gemeinsame Erstellungsoptionen,  Up: Aufruf von guix build

9.1.2 Paketumwandlungsoptionen
------------------------------

Eine weitere Gruppe von Befehlszeilenoptionen, die ‘guix build’ und auch
‘guix package’ unterstützen, sind “Paketumwandlungsoptionen”. Diese
Optionen ermöglichen es, “Paketvarianten” zu definieren — zum Beispiel
können Pakete aus einem anderen Quellcode als normalerweise erstellt
werden. Damit ist es leicht, angepasste Pakete schnell zu erstellen,
ohne die vollständigen Definitionen von Paketvarianten einzutippen
(siehe *note Pakete definieren::).

   Paketumwandlungsoptionen bleiben über Aktualisierungen hinweg
erhalten: ‘guix upgrade’ versucht, Umwandlungsoptionen, die vorher zur
Erstellung des Profils benutzt wurden, auf die aktualisierten Pakete
anzuwenden.

   Im Folgenden finden Sie die verfügbaren Befehlszeilenoptionen. Die
meisten Befehle unterstützen sie ebenso wie eine Option
‘--help-transform’, mit der all die verfügbaren Optionen und je eine
Kurzbeschreibung dazu angezeigt werden. (Diese Optionen werden der Kürze
wegen nicht in der Ausgabe von ‘--help’ aufgeführt.)

‘--with-source=QUELLE’
‘--with-source=PAKET=QUELLE’
‘--with-source=PAKET@VERSION=QUELLE’
     Den Paketquellcode für das PAKET von der angegebenen QUELLE holen
     und die VERSION als seine Versionsnummer verwenden. Die QUELLE muss
     ein Dateiname oder eine URL sein wie bei ‘guix download’ (siehe
     *note Aufruf von guix download::).

     Wird kein PAKET angegeben, wird als Paketname derjenige auf der
     Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende
     der QUELLE passt — wenn z.B. als QUELLE die Datei
     ‘/src/guile-2.0.10.tar.gz’ angegeben wurde, entspricht das dem
     ‘guile’-Paket.

     Ebenso wird, wenn keine VERSION angegeben wurde, die Version als
     Zeichenkette aus der QUELLE abgeleitet; im vorherigen Beispiel wäre
     sie ‘2.0.10’.

     Mit dieser Option können Nutzer versuchen, eine andere Version
     ihres Pakets auszuprobieren, als die in der Distribution enthaltene
     Version. Folgendes Beispiel lädt ‘ed-1.7.tar.gz’ von einem
     GNU-Spiegelserver herunter und benutzt es als Quelle für das
     ‘ed’-Paket:

          guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

     Für Entwickler wird es einem durch ‘--with-source’ leicht gemacht,
     „Release Candidates“, also Vorabversionen, zu testen:

          guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

     … oder ein Checkout eines versionskontrollierten Repositorys in
     einer isolierten Umgebung zu erstellen:

          $ git clone git://git.sv.gnu.org/guix.git
          $ guix build guix --with-source=guix@1.0=./guix

‘--with-input=PAKET=ERSATZ’
     Abhängigkeiten vom PAKET durch eine Abhängigkeit vom ERSATZ-Paket
     ersetzen. Als PAKET muss ein Paketname angegeben werden und als
     ERSATZ eine Paketspezifikation wie ‘guile’ oder ‘guile@1.8’.

     Mit folgendem Befehl wird zum Beispiel Guix erstellt, aber statt
     der aktuellen stabilen Guile-Version hängt es von der alten
     Guile-Version ‘guile@2.0’ ab:

          guix build --with-input=guile=guile@2.0 guix

     Die Ersetzung ist rekursiv und umfassend. In diesem Beispiel würde
     nicht nur ‘guix’, sondern auch seine Abhängigkeit ‘guile-json’ (was
     auch von ‘guile’ abhängt) für ‘guile@2.0’ neu erstellt.

     Implementiert wird das alles mit der Scheme-Prozedur
     ‘package-input-rewriting’ (siehe *note ‘package-input-rewriting’:
     Pakete definieren.).

‘--with-graft=PAKET=ERSATZ’
     Dies verhält sich ähnlich wie mit ‘--with-input’, aber mit dem
     wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette
     neu erstellt wird, sondern das ERSATZ-Paket erstellt und die
     ursprünglichen Binärdateien, die auf das PAKET verwiesen haben,
     damit “veredelt” werden. Im Abschnitt *note
     Sicherheitsaktualisierungen:: finden Sie weitere Informationen über
     Veredelungen.

     Zum Beispiel veredelt folgender Befehl Wget und alle Abhängigkeiten
     davon mit der Version 3.5.4 von GnuTLS, indem Verweise auf die
     ursprünglich verwendete GnuTLS-Version ersetzt werden:

          guix build --with-graft=gnutls=gnutls@3.5.4 wget

     Das hat den Vorteil, dass es viel schneller geht, als alles neu zu
     erstellen. Die Sache hat aber einen Haken: Veredelung funktioniert
     nur, wenn das PAKET und sein ERSATZ miteinander streng kompatibel
     sind — zum Beispiel muss, wenn diese eine Programmbibliothek zur
     Verfügung stellen, deren Binärschnittstelle („Application Binary
     Interface“, kurz ABI) kompatibel sein. Wenn das ERSATZ-Paket auf
     irgendeine Art inkompatibel mit dem PAKET ist, könnte das
     Ergebnispaket unbrauchbar sein. Vorsicht ist also geboten!

‘--with-debug-info=PAKET’
     Das PAKET auf eine Weise erstellen, die Informationen zur
     Fehlersuche enthält, und von ihm abhängige Pakete damit veredeln.
     Das ist nützlich, wenn das PAKET noch keine Fehlersuchinformationen
     als installierbare ‘debug’-Ausgabe enthält (siehe *note Dateien zur
     Fehlersuche installieren::).

     Als Beispiel nehmen wir an, Inkscape stürzt bei Ihnen ab und Sie
     möchten wissen, was dabei in GLib passiert. Die GLib-Bibliothek
     liegt tief im Abhängigkeitsgraphen von Inkscape und verfügt nicht
     über eine ‘debug’-Ausgabe; das erschwert die Fehlersuche.
     Glücklicherweise können Sie GLib mit Informationen zur Fehlersuche
     neu erstellen und an Inkscape anheften:

          guix install inkscape --with-debug-info=glib

     Nur GLib muss neu kompiliert werden, was in vernünftiger Zeit
     möglich ist. Siehe *note Dateien zur Fehlersuche installieren:: für
     mehr Informationen.

          Anmerkung: Intern funktioniert diese Option, indem
          ‘#:strip-binaries? #f’ an das Erstellungssystem des
          betreffenden Pakets übergeben wird (siehe *note
          Erstellungssysteme::). Die meisten Erstellungssysteme
          unterstützen diese Option, manche aber nicht. In diesem Fall
          wird ein Fehler gemeldet.

          Auch wenn ein in C/C++ geschriebenes Paket ohne ‘-g’ erstellt
          wird (was selten der Fall ist), werden Informationen zur
          Fehlersuche weiterhin fehlen, obwohl ‘#:strip-binaries?’ auf
          falsch steht.

‘--with-c-toolchain=PAKET=TOOLCHAIN’
     Mit dieser Befehlszeilenoption wird die Kompilierung des PAKETs und
     aller davon abhängigen Objekte angepasst, so dass mit der TOOLCHAIN
     statt der vorgegebenen GNU-Toolchain für C/C++ erstellt wird.

     Betrachten Sie dieses Beispiel:

          guix build octave-cli \
            --with-c-toolchain=fftw=gcc-toolchain@10 \
            --with-c-toolchain=fftwf=gcc-toolchain@10

     Mit dem obigen Befehl wird eine Variante der Pakete ‘fftw’ und
     ‘fftwf’ mit Version 10 der ‘gcc-toolchain’ anstelle der
     vorgegebenen Toolchain erstellt, um damit anschließend eine diese
     benutzende Variante des GNU-Octave-Befehlszeilenprogramms zu
     erstellen. Auch GNU Octave selbst wird mit ‘gcc-toolchain@10’
     erstellt.

     Das zweite Beispiel bewirkt eine Erstellung der „Hardware
     Locality“-Bibliothek (‘hwloc’) sowie ihrer abhängigen Objekte bis
     einschließlich ‘intel-mpi-benchmarks’ mit dem Clang-C-Compiler:

          guix build --with-c-toolchain=hwloc=clang-toolchain \
                     intel-mpi-benchmarks

          Anmerkung: Es kann vorkommen, dass die
          Anwendungsbinärschnittstellen („Application Binary
          Interfaces“, kurz ABIs) der Toolchains inkompatibel sind. Das
          tritt vor allem bei der C++-Standardbibliothek und
          Bibliotheken zur Laufzeitunterstützung wie denen von OpenMP
          auf. Indem alle abhängigen Objekte mit derselben Toolchain
          erstellt werden, minimiert ‘--with-c-toolchain’ das Risiko,
          dass es zu Inkompatibilitäten kommt, aber es kann nicht ganz
          ausgeschlossen werden. Bedenken Sie, für welches PAKET Sie
          dies benutzen.

‘--with-git-url=PAKET=URL’
     Das PAKET aus dem neuesten Commit im ‘master’-Branch des unter der
     URL befindlichen Git-Repositorys erstellen. Git-Submodule des
     Repositorys werden dabei rekursiv geladen.

     Zum Beispiel erstellt der folgende Befehl die
     NumPy-Python-Bibliothek unter Verwendung des neuesten Commits von
     Python auf dessen „master“-Branch.

          guix build python-numpy \
            --with-git-url=python=https://github.com/python/cpython

     Diese Befehlszeilenoption kann auch mit ‘--with-branch’ oder
     ‘--with-commit’ kombiniert werden (siehe unten).

     Da es den neuesten Commit auf dem verwendeten Branch benutzt,
     ändert sich das Ergebnis natürlich mit der Zeit. Nichtsdestoweniger
     ist es eine bequeme Möglichkeit, ganze Softwarestapel auf dem
     neuesten Commit von einem oder mehr Paketen aufbauen zu lassen. Es
     ist besonders nützlich im Kontext Kontinuierlicher Integration
     (englisch „Continuous Integration“, kurz CI).

     Checkouts bleiben zwischengespeichert als
     ‘~/.cache/guix/checkouts’, damit danach schneller auf dasselbe
     Repository zugegriffen werden kann. Eventuell möchten Sie das
     Verzeichnis ab und zu bereinigen, um Plattenplatz zu sparen.

‘--with-branch=PAKET=BRANCH’
     Das PAKET aus dem neuesten Commit auf dem BRANCH erstellen. Wenn
     das ‘source’-Feld des PAKETs ein origin-Objekt mit der Methode
     ‘git-fetch’ (siehe *note „origin“-Referenz::) oder ein
     ‘git-checkout’-Objekt ist, wird die URL des Repositorys vom
     ‘source’-Feld genommen. Andernfalls müssen Sie die
     Befehlszeilenoption ‘--with-git-url’ benutzen, um die URL des
     Git-Repositorys anzugeben.

     Zum Beispiel wird mit dem folgenden Befehl ‘guile-sqlite3’ aus dem
     neuesten Commit seines ‘master’-Branches erstellt und anschließend
     ‘guix’ (was von ‘guile-sqlite3’ abhängt) und ‘cuirass’ (was von
     ‘guix’ abhängt) unter Nutzung genau dieser
     ‘guile-sqlite3’-Erstellung erstellt:

          guix build --with-branch=guile-sqlite3=master cuirass

‘--with-commit=PAKET=COMMIT’
     Dies verhält sich ähnlich wie ‘--with-branch’, außer dass es den
     angegebenen COMMIT benutzt statt die Spitze eines angegebenen
     Branches. Als COMMIT muss ein gültiger SHA1-Bezeichner oder ein Tag
     für einen Git-Commit angegeben werden.

‘--with-patch=PAKET=DATEI’
     Die DATEI zur Liste der auf das PAKET anzuwendenden Patches
     hinzufügen. Als PAKET muss eine Spezifikation wie ‘python@3.8’ oder
     ‘glibc’ benutzt werden. In der DATEI muss ein Patch enthalten sein;
     er wird mit den im Ursprung (‘origin’) des PAKETs angegebenen
     Befehlszeilenoptionen angewandt (siehe *note „origin“-Referenz::).
     Die vorgegebenen Optionen enthalten ‘-p1’ (siehe *note
     (diffutils)patch Directories::).

     Zum Beispiel wird mit dem folgenden Befehl für die Neuerstellung
     von Coreutils die GNU-C-Bibliothek (glibc) wie angegeben gepatcht:

          guix build coreutils --with-patch=glibc=./glibc-frob.patch

     In diesem Beispiel wird glibc selbst und alles, was im
     Abhängigkeitsgraphen auf dem Weg zu Coreutils liegt, neu erstellt.

‘--with-latest=PAKET’
     Sie hätten gerne das Neueste vom Neuen? Dann ist diese
     Befehlszeilenoption das Richtige für Sie! Damit wird jedes
     Vorkommen von PAKET im Abhängigkeitsgraphen durch dessen neueste
     angebotene Version ersetzt, wie sie auch von ‘guix refresh’
     gemeldet würde (siehe *note Aufruf von guix refresh::).

     Dazu wird die neueste angebotene Version des PAKETs ermittelt (wenn
     möglich), heruntergeladen und, _wenn_ eine OpenPGP-Signatur mit
     dabei ist, es damit authentifiziert.

     Zum Beispiel wird durch folgenden Befehl Guix mit der neuesten
     Version von Guile-JSON erstellt:

          guix build guix --with-latest=guile-json

     Es gibt jedoch Einschränkungen. Erstens gehen Sie in dem Fall, dass
     das Werkzeug nicht in der Lage ist oder nicht weiß, wie es den
     Quellcode authentifiziert, das Risiko ein, dass bösartiger Code
     ausgeführt wird; Ihnen wird dann eine Warnung angezeigt. Zweitens
     wird mit dieser Option einfach der Quellcode ausgetauscht und die
     übrige Paketdefinition bleibt erhalten. Manchmal reicht das nicht;
     es könnte sein, dass neue Abhängigkeiten hinzugefügt oder neue
     Patches angewandt werden müssen oder dass ganz allgemein Arbeiten
     zur Qualitätssicherung, die Guix-Entwickler normalerweise leisten,
     fehlen werden.

     Sie sind gewarnt worden! Wenn aber kein Problem auftritt, können
     Sie das Paket zackig auf den neuesten Stand bringen. Wir ermutigen
     Sie dazu, Patches einzureichen, die die eigentliche Paketdefinition
     aktualisieren, sobald Sie die neue Version erfolgreich getestet
     haben (siehe *note Mitwirken::).

‘--without-tests=PAKET’
     Das PAKET erstellen, ohne seine Tests zu durchlaufen. Das erweist
     sich als nützlich, wenn Sie Testkataloge überspringen möchten, die
     viel Zeit in Anspruch nehmen, oder wenn der Testkatalog eines
     Pakets nichtdeterministisch fehlschlägt. Dies sollte mit Bedacht
     eingesetzt werden, denn das Ausführen des Testkatalogs sichert zu,
     dass ein Paket wie gewollt funktioniert.

     Wenn die Tests abgeschaltet werden, ergibt sich ein anderes
     Store-Objekt. Dadurch muss, wenn diese Option benutzt wird, auch
     alles, was vom Paket abhängt, neu erstellt werden, wie Sie in
     diesem Beispiel sehen können:

          guix install --without-tests=python python-notebook

     Mit obigem Befehl wird ‘python-notebook’ für ein ‘python’
     installiert, dessen Testkatalog nicht ausgeführt wurde. Dazu wird
     auch alles neu erstellt, was von ‘python’ abhängt, einschließlich
     ‘python-notebook’.

     Intern funktioniert ‘--without-tests’, indem es die Option
     ‘#:tests?’ der ‘check’-Phase eines Pakets abändert (siehe *note
     Erstellungssysteme::). Beachten Sie, dass manche Pakete eine
     angepasste ‘check’-Phase benutzen, die eine Einstellung wie
     ‘#:tests? #f’ nicht berücksichtigt. Deshalb wirkt sich
     ‘--without-tests’ auf diese Pakete nicht aus.

   Sie fragen sich sicher, wie Sie dieselbe Wirkung mit Scheme-Code
erzielen können, zum Beispiel wenn Sie Ihr Manifest oder eine eigene
Paketumwandlung schreiben? Siehe *note Paketvarianten definieren:: für
eine Übersicht über verfügbare Programmierschnittstellen.


File: guix.de.info,  Node: Zusätzliche Erstellungsoptionen,  Next: Fehlschläge beim Erstellen untersuchen,  Prev: Paketumwandlungsoptionen,  Up: Aufruf von guix build

9.1.3 Zusätzliche Erstellungsoptionen
-------------------------------------

Die unten aufgeführten Befehlszeilenoptionen funktionieren nur mit ‘guix
build’.

‘--quiet’
‘-q’
     Schweigend erstellen, ohne das Erstellungsprotokoll anzuzeigen —
     dies ist äquivalent zu ‘--verbosity=0’. Nach Abschluss der
     Erstellung ist das Protokoll in ‘/var’ (oder einem entsprechenden
     Ort) einsehbar und kann jederzeit mit der Befehlszeilenoption
     ‘--log-file’ gefunden werden.

‘--file=DATEI’
‘-f DATEI’
     Das Paket, die Ableitung oder das dateiähnliche Objekt erstellen,
     zu dem der Code in der DATEI ausgewertet wird (siehe *note
     dateiartige Objekte: G-Ausdrücke.).

     Zum Beispiel könnte in der DATEI so eine Paketdefinition stehen
     (siehe *note Pakete definieren::):

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

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

     Die DATEI darf auch eine JSON-Darstellung von einer oder mehreren
     Paketdefinitionen sein. Wenn wir ‘guix build -f’ auf einer
     ‘hello.json’-Datei mit dem folgenden Inhalt ausführen würden,
     würden die Pakete ‘myhello’ und ‘greeter’ erstellt werden:

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

‘--manifest=MANIFEST’
‘-m MANIFEST’
     Alle Pakete erstellen, die im angegebenen MANIFEST stehen (siehe
     *note ‘--manifest’: profile-manifest.).

‘--expression=AUSDRUCK’
‘-e AUSDRUCK’
     Das Paket oder die Ableitung erstellen, zu der der AUSDRUCK
     ausgewertet wird.

     Zum Beispiel kann der AUSDRUCK ‘(@ (gnu packages guile) guile-1.8)’
     sein, was diese bestimmte Variante der Version 1.8 von Guile
     eindeutig bezeichnet.

     Alternativ kann der AUSDRUCK ein G-Ausdruck sein. In diesem Fall
     wird er als Erstellungsprogramm an ‘gexp->derivation’ übergeben
     (siehe *note G-Ausdrücke::).

     Zudem kann der AUSDRUCK eine monadische Prozedur mit null
     Argumenten bezeichnen (siehe *note Die Store-Monade::). Die
     Prozedur muss eine Ableitung als monadischen Wert zurückliefern,
     die dann durch ‘run-with-store’ laufen gelassen wird.

‘--source’
‘-S’
     Die Quellcode-Ableitung der Pakete statt die Pakete selbst
     erstellen.

     Zum Beispiel liefert ‘guix build -S gcc’ etwas in der Art von
     ‘/gnu/store/…-gcc-4.7.2.tar.bz2’, also den Tarball mit dem
     GCC-Quellcode.

     Der gelieferte Quell-Tarball ist das Ergebnis davon, alle Patches
     und Code-Schnipsel aufzuspielen, die im ‘origin’-Objekt des Pakets
     festgelegt wurden (siehe *note Pakete definieren::).

     Wie andere Arten von Ableitung kann auch das Ergebnis einer
     Quellcode-Ableitung mit der Befehlszeilenoption ‘--check’ geprüft
     werden (siehe *note build-check::). Das ist nützlich, um zu
     überprüfen, ob ein (vielleicht bereits erstellter oder
     substituierter, also zwischengespeicherter) Paketquellcode zu ihrer
     deklarierten Hash-Prüfsumme passt.

     Beachten Sie, dass ‘guix build -S’ nur für die angegebenen Pakete
     den Quellcode herunterlädt. Dazu gehört _nicht_ der Quellcode
     statisch gebundener Abhängigkeiten und der Quellcode alleine reicht
     nicht aus, um die Pakete zu reproduzieren.

‘--sources’
     Den Quellcode für PAKET-ODER-ABLEITUNG und alle Abhängigkeiten
     davon rekursiv herunterladen und zurückliefern. Dies ist eine
     praktische Methode, eine lokale Kopie des gesamten Quellcodes zu
     beziehen, der nötig ist, um die Pakete zu erstellen, damit Sie
     diese später auch ohne Netzwerkzugang erstellen lassen können. Es
     handelt sich um eine Erweiterung der Befehlszeilenoption
     ‘--source’, die jeden der folgenden Argumentwerte akzeptiert:

     ‘package’
          Mit diesem Wert verhält sich die Befehlszeilenoption
          ‘--sources’ auf genau die gleiche Weise wie die
          Befehlszeilenoption ‘--source’.

     ‘all’
          Erstellt die Quellcode-Ableitungen aller Pakete einschließlich
          allen Quellcodes, der als Teil der Eingaben im ‘inputs’-Feld
          aufgelistet ist. Dies ist der vorgegebene Wert, wenn sonst
          keiner angegeben wird.

               $ guix build --sources tzdata
               Folgende Ableitungen werden erstellt:
                  /gnu/store/…-tzdata2015b.tar.gz.drv
                  /gnu/store/…-tzcode2015b.tar.gz.drv

     ‘transitive’
          Die Quellcode-Ableitungen aller Pakete sowie aller transitiven
          Eingaben der Pakete erstellen. Damit kann z.B. Paket-Quellcode
          vorab heruntergeladen und später offline erstellt werden.

               $ guix build --sources=transitive tzdata
               Folgende Ableitungen werden erstellt:
                  /gnu/store/…-tzcode2015b.tar.gz.drv
                  /gnu/store/…-findutils-4.4.2.tar.xz.drv
                  /gnu/store/…-grep-2.21.tar.xz.drv
                  /gnu/store/…-coreutils-8.23.tar.xz.drv
                  /gnu/store/…-make-4.1.tar.xz.drv
                  /gnu/store/…-bash-4.3.tar.xz.drv
               …

‘--system=SYSTEM’
‘-s SYSTEM’
     Versuchen, für das angegebene SYSTEM — z.B. ‘i686-linux’ — statt
     für denselben Systemtyp wie auf dem Wirtssystem zu erstellen. Beim
     Befehl ‘guix build’ können Sie diese Befehlszeilenoption mehrmals
     wiederholen, wodurch für jedes angegebene System eine Erstellung
     durchgeführt wird; andere Befehle ignorieren überzählige
     ‘-s’-Befehlszeilenoptionen.

          Anmerkung: Die Befehlszeilenoption ‘--system’ dient der
          _nativen_ Kompilierung (nicht zu verwechseln mit
          Cross-Kompilierung). Siehe ‘--target’ unten für Informationen
          zur Cross-Kompilierung.

     Ein Beispiel sind Linux-basierte Systeme, die verschiedene
     Persönlichkeiten emulieren können. Zum Beispiel können Sie
     ‘--system=i686-linux’ auf einem ‘x86_64-linux’-System oder
     ‘--system=armhf-linux’ auf einem ‘aarch64-linux’-System angeben, um
     Pakete in einer vollständigen 32-Bit-Umgebung zu erstellen.

          Anmerkung: Das Erstellen für ein ‘armhf-linux’-System ist
          ungeprüft auf allen ‘aarch64-linux’-Maschinen aktiviert,
          obwohl bestimmte aarch64-Chipsätze diese Funktionalität nicht
          unterstützen, darunter auch ThunderX.

     Ebenso können Sie, wenn transparente Emulation mit QEMU und
     ‘binfmt_misc’ aktiviert sind (siehe *note
     ‘qemu-binfmt-service-type’: Virtualisierungsdienste.), für jedes
     System Erstellungen durchführen, für das ein
     QEMU-‘binfmt_misc’-Handler installiert ist.

     Erstellungen für ein anderes System, das nicht dem System der
     Maschine, die Sie benutzen, entspricht, können auch auf eine
     entfernte Maschine mit der richtigen Architektur ausgelagert
     werden. Siehe *note Auslagern des Daemons einrichten:: für mehr
     Informationen über das Auslagern.

‘--target=TRIPEL’
     Lässt für das angegebene TRIPEL cross-erstellen. Dieses muss ein
     gültiges GNU-Tripel wie z.B. ‘"aarch64-linux-gnu"’ sein (siehe
     *note GNU-Konfigurationstripel: (autoconf)Specifying Target
     Triplets.).

‘--check’
     PAKET-ODER-ABLEITUNG erneut erstellen, wenn diese bereits im Store
     verfügbar ist, und einen Fehler melden, wenn die
     Erstellungsergebnisse nicht Bit für Bit identisch sind.

     Mit diesem Mechanismus können Sie überprüfen, ob zuvor installierte
     Substitute unverfälscht sind (siehe *note Substitute::) oder auch
     ob das Erstellungsergebnis eines Pakets deterministisch ist. Siehe
     *note Aufruf von guix challenge:: für mehr Hintergrundinformationen
     und Werkzeuge.

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

‘--repair’
     Versuchen, die angegebenen Store-Objekte zu reparieren, wenn sie
     beschädigt sind, indem sie neu heruntergeladen oder neu erstellt
     werden.

     Diese Operation ist nicht atomar und nur der Administratornutzer
     ‘root’ kann sie verwenden.

‘--derivations’
‘-d’
     Liefert die Ableitungspfade und _nicht_ die Ausgabepfade für die
     angegebenen Pakete.

‘--root=DATEI’
‘-r DATEI’
     Die DATEI zu einer symbolischen Verknüpfung auf das Ergebnis machen
     und als Müllsammlerwurzel registrieren.

     Dadurch wird das Ergebnis dieses Aufrufs von ‘guix build’ vor dem
     Müllsammler geschützt, bis die DATEI gelöscht wird. Wird diese
     Befehlszeilenoption _nicht_ angegeben, können Erstellungsergebnisse
     vom Müllsammler geholt werden, sobald die Erstellung abgeschlossen
     ist. Siehe *note Aufruf von guix gc:: für mehr Informationen zu
     Müllsammlerwurzeln.

‘--log-file’
     Liefert die Dateinamen oder URLs der Erstellungsprotokolle für das
     angegebene PAKET-ODER-ABLEITUNG oder meldet einen Fehler, falls
     Protokolldateien fehlen.

     Dies funktioniert, egal wie die Pakete oder Ableitungen angegeben
     werden. Zum Beispiel sind folgende Aufrufe alle äquivalent:

          guix build --log-file $(guix build -d guile)
          guix build --log-file $(guix build guile)
          guix build --log-file guile
          guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

     Wenn ein Protokoll lokal nicht verfügbar ist und sofern
     ‘--no-substitutes’ nicht übergeben wurde, sucht der Befehl nach
     einem entsprechenden Protokoll auf einem der Substitutserver (die
     mit ‘--substitute-urls’ angegeben werden können).

     Stellen Sie sich zum Beispiel vor, sie wollten das
     Erstellungsprotokoll von GDB auf einem MIPS-System sehen, benutzen
     aber selbst eine ‘x86_64’-Maschine:

          $ guix build --log-file gdb -s aarch64-linux
          https://ci.guix.gnu.org/log/…-gdb-7.10

     So haben Sie umsonst Zugriff auf eine riesige Bibliothek von
     Erstellungsprotokollen!


File: guix.de.info,  Node: Fehlschläge beim Erstellen untersuchen,  Prev: Zusätzliche Erstellungsoptionen,  Up: Aufruf von guix build

9.1.4 Fehlschläge beim Erstellen untersuchen
--------------------------------------------

Wenn Sie ein neues Paket definieren (siehe *note Pakete definieren::),
werden Sie sich vermutlich einige Zeit mit der Fehlersuche beschäftigen
und die Erstellung so lange anpassen, bis sie funktioniert. Dazu müssen
Sie die Erstellungsbefehle selbst in einer Umgebung benutzen, die der,
die der Erstellungsdaemon aufbaut, so ähnlich wie möglich ist.

   Das Erste, was Sie dafür tun müssen, ist die Befehlszeilenoption
‘--keep-failed’ oder ‘-K’ von ‘guix build’ einzusetzen, wodurch
Verzeichnisbäume fehlgeschlagener Erstellungen in ‘/tmp’ oder dem von
Ihnen als ‘TMPDIR’ ausgewiesenen Verzeichnis erhalten und nicht gelöscht
werden (siehe *note ‘--keep-failed’: Gemeinsame Erstellungsoptionen.).

   Im Anschluss können Sie mit ‘cd’ in die Verzeichnisse dieses
fehlgeschlagenen Erstellungsbaums wechseln und mit ‘source’ dessen
‘environment-variables’-Datei laden, die alle
Umgebungsvariablendefinitionen enthält, die zum Zeitpunkt des
Fehlschlags der Erstellung galten. Sagen wir, Sie suchen Fehler in einem
Paket ‘foo’, dann würde eine typische Sitzung so aussehen:

     $ guix build foo -K
     … Erstellung schlägt fehl
     $ cd /tmp/guix-build-foo.drv-0
     $ source ./environment-variables
     $ cd foo-1.2

   Nun können Sie Befehle (fast) so aufrufen, als wären Sie der Daemon,
und Fehlerursachen in Ihrem Erstellungsprozess ermitteln.

   Manchmal passiert es, dass zum Beispiel die Tests eines Pakets
erfolgreich sind, wenn Sie sie manuell aufrufen, aber scheitern, wenn
der Daemon sie ausführt. Das kann passieren, weil der Daemon
Erstellungen in isolierten Umgebungen („Containern“) durchführt, wo,
anders als in der obigen Umgebung, kein Netzwerkzugang möglich ist,
‘/bin/sh’ nicht exisiert usw. (siehe *note Einrichten der
Erstellungsumgebung::).

   In solchen Fällen müssen Sie den Erstellungsprozess womöglich aus
einer zu der des Daemons ähnlichen isolierten Umgebung heraus
ausprobieren:

     $ guix build -K foo
     …
     $ cd /tmp/guix-build-foo.drv-0
     $ guix environment --no-grafts -C foo --ad-hoc strace gdb
     [env]# source ./environment-variables
     [env]# cd foo-1.2

   Hierbei erzeugt ‘guix environment -C’ eine isolierte Umgebung und
öffnet darin eine Shell (siehe *note Aufruf von guix environment::). Der
Teil mit ‘--ad-hoc strace gdb’ fügt die Befehle ‘strace’ und ‘gdb’ zur
isolierten Umgebung hinzu, die Sie gut gebrauchen können, während Sie
Fehler suchen. Wegen der Befehlszeilenoption ‘--no-grafts’ bekommen Sie
haargenau dieselbe Umgebung ohne veredelte Pakete (siehe *note
Sicherheitsaktualisierungen:: für mehr Informationen zu Veredelungen).

   Um der isolierten Umgebung des Erstellungsdaemons noch näher zu
kommen, können wir ‘/bin/sh’ entfernen:

     [env]# rm /bin/sh

   (Keine Sorge, das ist harmlos: All dies passiert nur in der zuvor von
‘guix environment’ erzeugten Wegwerf-Umgebung.)

   Der Befehl ‘strace’ befindet sich wahrscheinlich nicht in Ihrem
Suchpfad, aber wir können ihn so benutzen:

     [env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

   Auf diese Weise haben Sie nicht nur die Umgebungsvariablen, die der
Daemon benutzt, nachgebildet, sondern lassen auch den Erstellungsprozess
in einer isolierten Umgebung ähnlich der des Daemons laufen.


File: guix.de.info,  Node: Aufruf von guix edit,  Next: Aufruf von guix download,  Prev: Aufruf von guix build,  Up: Zubehör

9.2 ‘guix edit’ aufrufen
========================

So viele Pakete, so viele Quelldateien! Der Befehl ‘guix edit’
erleichtert das Leben von sowohl Nutzern als auch Paketentwicklern,
indem er Ihren Editor anweist, die Quelldatei mit der Definition des
jeweiligen Pakets zu bearbeiten. Zum Beispiel startet dies:

     guix edit gcc@4.9 vim

das mit der Umgebungsvariablen ‘VISUAL’ oder ‘EDITOR’ angegebene
Programm und lässt es das Rezept von GCC 4.9.3 und von Vim anzeigen.

   Wenn Sie ein Git-Checkout von Guix benutzen (siehe *note Erstellung
aus dem Git::) oder Ihre eigenen Pakete im ‘GUIX_PACKAGE_PATH’ erstellt
haben (siehe *note Paketmodule::), werden Sie damit die Paketrezepte
auch bearbeiten können. Andernfalls werden Sie zumindest in die Lage
versetzt, die nur lesbaren Rezepte für sich im Moment im Store
befindliche Pakete zu untersuchen.

   Statt ‘GUIX_PACKAGE_PATH’ zu benutzen, können Sie mit der
Befehlszeilenoption ‘--load-path=VERZEICHNIS’ (oder kurz ‘-L
VERZEICHNIS’) das VERZEICHNIS vorne an den Paketmodul-Suchpfad anhängen
und so Ihre eigenen Pakete sichtbar machen.


File: guix.de.info,  Node: Aufruf von guix download,  Next: Aufruf von guix hash,  Prev: Aufruf von guix edit,  Up: Zubehör

9.3 ‘guix download’ aufrufen
============================

Wenn Entwickler einer Paketdefinition selbige schreiben, müssen diese
normalerweise einen Quellcode-Tarball herunterladen, seinen SHA256-Hash
als Prüfsumme berechnen und diese in der Paketdefinition eintragen
(siehe *note Pakete definieren::). Das Werkzeug ‘guix download’ hilft
bei dieser Aufgabe: Damit wird eine Datei von der angegebenen URI
heruntergeladen, in den Store eingelagert und sowohl ihr Dateiname im
Store als auch ihr SHA256-Hash als Prüfsumme angezeigt.

   Dadurch, dass die heruntergeladene Datei in den Store eingefügt wird,
wird Bandbreite gespart: Wenn der Entwickler schließlich versucht, das
neu definierte Paket mit ‘guix build’ zu erstellen, muss der
Quell-Tarball nicht erneut heruntergeladen werden, weil er sich bereits
im Store befindet. Es ist auch eine bequeme Methode, Dateien temporär
aufzubewahren, die letztlich irgendwann gelöscht werden (siehe *note
Aufruf von guix gc::).

   Der Befehl ‘guix download’ unterstützt dieselben URIs, die in
Paketdefinitionen verwendet werden. Insbesondere unterstützt er
‘mirror://’-URIs. ‘https’-URIs (HTTP über TLS) werden unterstützt,
_vorausgesetzt_ die Guile-Anbindungen für GnuTLS sind in der Umgebung
des Benutzers verfügbar; wenn nicht, wird ein Fehler gemeldet. Siehe
*note how to install the GnuTLS bindings for Guile: (gnutls-guile)Guile
Preparations, hat mehr Informationen.

   Mit ‘guix download’ werden HTTPS-Serverzertifikate verifiziert, indem
die Zertifikate der X.509-Autoritäten in das durch die Umgebungsvariable
‘SSL_CERT_DIR’ bezeichnete Verzeichnis heruntergeladen werden (siehe
*note X.509-Zertifikate::), außer ‘--no-check-certificate’ wird benutzt.

   Folgende Befehlszeilenoptionen stehen zur Verfügung:

‘--hash=ALGORITHMUS’
‘-H ALGORITHMUS’
     Einen Hash mit dem angegebenen ALGORITHMUS berechnen. Siehe *note
     Aufruf von guix hash:: für weitere Informationen.

‘--format=FORMAT’
‘-f FORMAT’
     Die Hash-Prüfsumme im angegebenen FORMAT ausgeben. Für weitere
     Informationen, was gültige Werte für das FORMAT sind, siehe *note
     Aufruf von guix hash::.

‘--no-check-certificate’
     X.509-Zertifikate von HTTPS-Servern _nicht_ validieren.

     Wenn Sie diese Befehlszeilenoption benutzen, haben Sie _keinerlei
     Garantie_, dass Sie tatsächlich mit dem authentischen Server, der
     für die angegebene URL verantwortlich ist, kommunizieren. Das macht
     Sie anfällig gegen sogenannte „Man-in-the-Middle“-Angriffe.

‘--output=DATEI’
‘-o DATEI’
     Die heruntergeladene Datei _nicht_ in den Store, sondern in die
     angegebene DATEI abspeichern.


File: guix.de.info,  Node: Aufruf von guix hash,  Next: Aufruf von guix import,  Prev: Aufruf von guix download,  Up: Zubehör

9.4 ‘guix hash’ aufrufen
========================

Der Befehl ‘guix hash’ berechnet den Hash einer Datei. Er ist primär ein
Werkzeug, dass es bequemer macht, etwas zur Distribution beizusteuern:
Damit wird die kryptografische Hash-Prüfsumme berechnet, die bei der
Definition eines Pakets benutzt werden kann (siehe *note Pakete
definieren::).

   Die allgemeine Syntax lautet:

     guix hash OPTION DATEI

   Wird als DATEI ein Bindestrich ‘-’ angegeben, berechnet ‘guix hash’
den Hash der von der Standardeingabe gelesenen Daten. ‘guix hash’
unterstützt die folgenden Optionen:

‘--hash=ALGORITHMUS’
‘-H ALGORITHMUS’
     Mit dem angegebenen ALGORITHMUS einen Hash berechnen. Die Vorgabe
     ist, ‘sha256’ zu benutzen.

     ALGORITHMUS muss der Name eines durch Libgcrypt über Guile-Gcrypt
     zur Verfügung gestellten kryptografischen Hashalgorithmus sein,
     z.B. ‘sha512’ oder ‘sha3-256’ (siehe *note (guile-gcrypt)Hash
     Functions::).

‘--format=FORMAT’
‘-f FORMAT’
     Gibt die Prüfsumme im angegebenen FORMAT aus.

     Unterstützte Formate: ‘base64’, ‘nix-base32’, ‘base32’, ‘base16’
     (‘hex’ und ‘hexadecimal’ können auch benutzt werden).

     Wird keine Befehlszeilenoption ‘--format’ angegeben, wird ‘guix
     hash’ die Prüfsumme im ‘nix-base32’-Format ausgeben. Diese
     Darstellung wird bei der Definition von Paketen benutzt.

‘--recursive’
‘-r’
     Die Prüfsumme der DATEI rekursiv berechnen.

     In diesem Fall wird die Prüfsumme eines Archivs berechnet, das die
     DATEI enthält, und auch ihre Kinder, wenn es sich um ein
     Verzeichnis handelt. Einige der Metadaten der DATEI sind Teil
     dieses Archivs. Zum Beispiel unterscheidet sich die berechnete
     Prüfsumme, wenn die DATEI eine reguläre Datei ist, je nachdem, ob
     die DATEI ausführbar ist oder nicht. Metadaten wie der Zeitstempel
     haben keinen Einfluss auf die Prüfsumme (siehe *note Aufruf von
     guix archive::).

‘--exclude-vcs’
‘-x’
     Wenn dies zusammen mit der Befehlszeilenoption ‘--recursive’
     angegeben wird, werden Verzeichnisse zur Versionskontrolle (‘.bzr’,
     ‘.git’, ‘.hg’, etc.) vom Archiv ausgenommen.

     Zum Beispiel würden Sie auf diese Art die Prüfsumme eines
     Git-Checkouts berechnen, was nützlich ist, wenn Sie die Prüfsumme
     für die Methode ‘git-fetch’ benutzen (siehe *note
     „origin“-Referenz::):

          $ git clone http://example.org/foo.git
          $ cd foo
          $ guix hash -rx .


File: guix.de.info,  Node: Aufruf von guix import,  Next: Aufruf von guix refresh,  Prev: Aufruf von guix hash,  Up: Zubehör

9.5 ‘guix import’ aufrufen
==========================

Der Befehl ‘guix import’ ist für Leute hilfreich, die ein Paket gerne
mit so wenig Arbeit wie möglich zur Distribution hinzufügen würden — ein
legitimer Anspruch. Der Befehl kennt ein paar Sammlungen, aus denen mit
ihm Paketmetadaten „importiert“ werden können. Das Ergebnis ist eine
Paketdefinition oder eine Vorlage dafür in dem uns bekannten Format
(siehe *note Pakete definieren::).

   Die allgemeine Syntax lautet:

     guix import IMPORTER OPTIONEN…

   Der IMPORTER gibt die Quelle an, aus der Paketmetadaten importiert
werden, und die OPTIONEN geben eine Paketbezeichnung und andere vom
IMPORTER abhängige Daten an.

   Manche Importer setzen voraus, dass der Befehl ‘gpgv’ ausgeführt
werden kann. Sie funktionieren nur, wenn GnuPG installiert und im
‘$PATH’ enthalten ist; falls nötig können Sie ‘guix install gnupg’
ausführen.

   Derzeit sind folgende „Importer“ verfügbar:

‘gnu’
     Metadaten für das angegebene GNU-Paket importieren. Damit wird eine
     Vorlage für die neueste Version dieses GNU-Pakets zur Verfügung
     gestellt, einschließlich der Prüfsumme seines Quellcode-Tarballs,
     seiner kanonischen Zusammenfassung und seiner Beschreibung.

     Zusätzliche Informationen wie Paketabhängigkeiten und seine Lizenz
     müssen noch manuell ermittelt werden.

     Zum Beispiel liefert der folgende Befehl eine Paketdefinition für
     GNU Hello:

          guix import gnu hello

     Speziell für diesen Importer stehen noch folgende
     Befehlszeilenoptionen zur Verfügung:

     ‘--key-download=RICHTLINIE’
          Die Richtlinie zum Umgang mit fehlenden OpenPGP-Schlüsseln
          beim Verifizieren der Paketsignatur (auch „Beglaubigung“
          genannt) festlegen, wie bei ‘guix refresh’. Siehe *note
          ‘--key-download’: Aufruf von guix refresh.

‘pypi’
     Metadaten aus dem Python Package Index (https://pypi.python.org/)
     importieren. Informationen stammen aus der JSON-formatierten
     Beschreibung, die unter ‘pypi.python.org’ verfügbar ist, und
     enthalten meistens alle relevanten Informationen einschließlich der
     Abhängigkeiten des Pakets. Für maximale Effizienz wird empfohlen,
     das Hilfsprogramm ‘unzip’ zu installieren, damit der Importer
     „Python Wheels“ entpacken und daraus Daten beziehen kann.

     Der folgende Befehl importiert Metadaten für das Python-Paket
     namens ‘itsdangerous’:

          guix import pypi itsdangerous

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

‘gem’
     Metadaten von RubyGems (https://rubygems.org/) importieren.
     Informationen kommen aus der JSON-formatierten Beschreibung, die
     auf ‘rubygems.org’ verfügbar ist, und enthält die relevantesten
     Informationen einschließlich der Laufzeitabhängigkeiten. Dies hat
     aber auch Schattenseiten — die Metadaten unterscheiden nicht
     zwischen Zusammenfassungen und Beschreibungen, daher wird dieselbe
     Zeichenkette für beides eingesetzt. Zudem fehlen Informationen zu
     nicht in Ruby geschriebenen Abhängigkeiten, die benötigt werden, um
     native Erweiterungen zu in Ruby geschriebenem Code zu erstellen.
     Diese herauszufinden bleibt dem Paketentwickler überlassen.

     Der folgende Befehl importiert Metadaten aus dem Ruby-Paket
     ‘rails’.

          guix import gem rails

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

‘cpan’
     Importiert Metadaten von MetaCPAN (https://www.metacpan.org/).
     Informationen werden aus den JSON-formatierten Metadaten genommen,
     die über die Programmierschnittstelle („API“) von MetaCPAN
     (https://fastapi.metacpan.org/) angeboten werden, und enthalten die
     relevantesten Informationen wie zum Beispiel Modulabhängigkeiten.
     Lizenzinformationen sollten genau nachgeprüft werden. Wenn Perl im
     Store verfügbar ist, wird das Werkzeug ‘corelist’ benutzt, um
     Kernmodule in der Abhängigkeitsliste wegzulassen.

     Folgender Befehl importiert Metadaten für das Perl-Modul
     Acme::Boolean:

          guix import cpan Acme::Boolean

‘cran’
     Metadaten aus dem CRAN (https://cran.r-project.org/) importieren,
     der zentralen Sammlung für die statistische und grafische Umgebung
     GNU R (https://r-project.org).

     Informationen werden aus der Datei namens ‘DESCRIPTION’ des Pakets
     extrahiert.

     Der folgende Befehl importiert Metadaten für das Cairo-R-Paket:

          guix import cran Cairo

     Wird zudem ‘--recursive’ angegeben, wird der Importer den
     Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv
     durchlaufen und Paketausdrücke für all die Pakete erzeugen, die
     noch nicht Teil von Guix sind.

     Wird ‘--style=specification’ angegeben, wird der Importer
     Paketdefinitionen erzeugen, deren Eingaben als Paketspezifikationen
     statt als Referenzen auf Paketvariable vorliegen. Das ist nützlich,
     wenn die erzeugten Paketdefinitionen in bestehende, nutzereigene
     Module eingefügt werden, weil dann die Liste der benutzten
     Paketmodule nicht angepasst werden muss. Die Vorgabe ist
     ‘--style=variable’.

     Wird ‘--archive=bioconductor’ angegeben, werden Metadaten vom
     Bioconductor (https://www.bioconductor.org/) importiert, einer
     Sammlung von R-Paketen zur Analyse und zum Verständnis von großen
     Mengen genetischer Daten in der Bioinformatik.

     Informationen werden aus der Datei namens ‘DESCRIPTION’ im Archiv
     des Pakets extrahiert.

     Der folgende Befehl importiert Metadaten für das R-Paket
     GenomicRanges:

          guix import cran --archive=bioconductor GenomicRanges

     Schließlich können Sie auch solche R-Pakete importieren, die noch
     nicht auf CRAN oder im Bioconductor veröffentlicht wurden, solange
     sie in einem Git-Repository stehen. Benutzen Sie ‘--archive=git’
     gefolgt von der URL des Git-Repositorys.

          guix import cran --archive=git https://github.com/immunogenomics/harmony

‘texlive’
     Metadaten aus CTAN (https://www.ctan.org/), dem umfassenden
     TeX-Archivnetzwerk, herunterladen, was für TeX-Pakete benutzt wird,
     die Teil der TeX-Live-Distribution (https://www.tug.org/texlive/)
     sind.

     Informationen über das Paket werden über die von CTAN angebotene
     XML-Programmierschnittstelle bezogen, wohingegen der Quellcode aus
     dem SVN-Repository des TeX-Live-Projekts heruntergeladen wird. Das
     wird so gemacht, weil CTAN keine versionierten Archive vorhält.

     Der folgende Befehl importiert Metadaten für das TeX-Paket
     ‘fontspec’:

          guix import texlive fontspec

     Wenn ‘--archive=VERZEICHNIS’ angegeben wird, wird der Quellcode
     _nicht_ aus dem Unterverzeichnis ‘latex’ des
     ‘texmf-dist/source’-Baums im SVN-Repository von TeX Live
     heruntergeladen, sondern aus dem angegebenen Schwester-VERZEICHNIS
     im selben Wurzelverzeichnis.

     Der folgende Befehl importiert Metadaten für das Paket ‘ifxetex’
     aus CTAN und lädt die Quelldateien aus dem Verzeichnis
     ‘texmf/source/generic’:

          guix import texlive --archive=generic ifxetex

‘json’
     Paketmetadaten aus einer lokalen JSON-Datei importieren. Betrachten
     Sie folgende Beispiel-Paketdefinition im JSON-Format:

          {
            "name": "hello",
            "version": "2.10",
            "source": "mirror://gnu/hello/hello-2.10.tar.gz",
            "build-system": "gnu",
            "home-page": "https://www.gnu.org/software/hello/",
            "synopsis": "Hello, GNU world: An example GNU package",
            "description": "GNU Hello prints a greeting.",
            "license": "GPL-3.0+",
            "native-inputs": ["gettext"]
          }

     Die Felder sind genauso benannt wie bei einem
     ‘<package>’-Verbundstyp (siehe *note Pakete definieren::).
     Referenzen zu anderen Paketen stehen darin als JSON-Liste von mit
     Anführungszeichen quotierten Zeichenketten wie ‘guile’ oder
     ‘guile@2.0’.

     Der Importer unterstützt auch eine ausdrücklichere Definition der
     Quelldateien mit den üblichen Feldern eines ‘<origin>’-Verbunds:

          {
            …
            "source": {
              "method": "url-fetch",
              "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
              "sha256": {
                "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
              }
            }
            …
          }

     Der folgende Befehl liest Metadaten aus der JSON-Datei ‘hello.json’
     und gibt einen Paketausdruck aus:

          guix import json hello.json

‘hackage’
     Metadaten aus Hackage (https://hackage.haskell.org/), dem zentralen
     Paketarchiv der Haskell-Gemeinde, importieren. Informationen werden
     aus Cabal-Dateien ausgelesen. Darin sind alle relevanten
     Informationen einschließlich der Paketabhängigkeiten enthalten.

     Speziell für diesen Importer stehen noch folgende
     Befehlszeilenoptionen zur Verfügung:

     ‘--stdin’
     ‘-s’
          Eine Cabal-Datei von der Standardeingabe lesen.
     ‘--no-test-dependencies’
     ‘-t’
          Keine Abhängigkeiten übernehmen, die nur von Testkatalogen
          benötigt werden.
     ‘--cabal-environment=ALISTE’
     ‘-e ALISTE’
          ALISTE muss eine assoziative Liste der
          Scheme-Programmiersprache sein, die die Umgebung definiert, in
          der bedingte Ausdrücke von Cabal ausgewertet werden. Dabei
          werden folgende Schlüssel akzeptiert: ‘os’, ‘arch’, ‘impl’ und
          eine Zeichenkette, die dem Namen einer Option (einer „Flag“)
          entspricht. Der mit einer „Flag“ assoziierte Wert muss
          entweder das Symbol ‘true’ oder ‘false’ sein. Der anderen
          Schlüsseln zugeordnete Wert muss mit der Definition des
          Cabal-Dateiformats konform sein. Der vorgegebene Wert zu den
          Schlüsseln ‘os’, ‘arch’ and ‘impl’ ist jeweils ‘linux’,
          ‘x86_64’ bzw. ‘ghc’.
     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

     Der folgende Befehl importiert Metadaten für die neuste Version des
     Haskell-„HTTP“-Pakets, ohne Testabhängigkeiten zu übernehmen und
     bei Übergabe von ‘false’ als Wert der Flag ‘network-uri’:

          guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

     Eine ganz bestimmte Paketversion kann optional ausgewählt werden,
     indem man nach dem Paketnamen anschließend ein At-Zeichen und eine
     Versionsnummer angibt wie in folgendem Beispiel:

          guix import hackage mtl@2.1.3.1

‘stackage’
     Der ‘stackage’-Importer ist ein Wrapper um den ‘hackage’-Importer.
     Er nimmt einen Paketnamen und schaut dafür die Paketversion nach,
     die Teil einer Stackage-Veröffentlichung (https://www.stackage.org)
     mit Langzeitunterstützung (englisch „Long-Term Support“, kurz LTS)
     ist, deren Metadaten er dann mit dem ‘hackage’-Importer bezieht.
     Beachten Sie, dass es Ihre Aufgabe ist, eine LTS-Veröffentlichung
     auszuwählen, die mit dem von Guix benutzten GHC-Compiler kompatibel
     ist.

     Speziell für diesen Importer stehen noch folgende
     Befehlszeilenoptionen zur Verfügung:

     ‘--no-test-dependencies’
     ‘-t’
          Keine Abhängigkeiten übernehmen, die nur von Testkatalogen
          benötigt werden.
     ‘--lts-version=VERSION’
     ‘-l VERSION’
          VERSION ist die gewünschte Version der LTS-Veröffentlichung.
          Wird keine angegeben, wird die neueste benutzt.
     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

     Der folgende Befehl importiert Metadaten für dasjenige
     Haskell-„HTTP“-Paket, das in der LTS-Stackage-Veröffentlichung mit
     Version 7.18 vorkommt:

          guix import stackage --lts-version=7.18 HTTP

‘elpa’
     Metadaten aus der Paketsammlung „Emacs Lisp Package Archive“ (ELPA)
     importieren (siehe *note (emacs)Packages::).

     Speziell für diesen Importer stehen noch folgende
     Befehlszeilenoptionen zur Verfügung:

     ‘--archive=REPO’
     ‘-a REPO’
          Mit REPO wird die Archiv-Sammlung (ein „Repository“)
          bezeichnet, von dem die Informationen bezogen werden sollen.
          Derzeit sind die unterstützten Repositorys und ihre
          Bezeichnungen folgende:
             - GNU (https://elpa.gnu.org/packages), bezeichnet mit
               ‘gnu’. Dies ist die Vorgabe.

               Pakete aus ‘elpa.gnu.org’ wurden mit einem der Schlüssel
               im GnuPG-Schlüsselbund in
               ‘share/emacs/25.1/etc/package-keyring.gpg’ (oder einem
               ähnlichen Pfad) des ‘emacs’-Pakets signiert (siehe *note
               ELPA-Paketsignaturen: (emacs)Package Installation.).

             - MELPA-Stable (https://stable.melpa.org/packages),
               bezeichnet mit ‘melpa-stable’.

             - MELPA (https://melpa.org/packages), bezeichnet mit
               ‘melpa’.

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

‘crate’
     Metadaten aus der Paketsammlung crates.io für Rust importieren
     crates.io (https://crates.io), wie Sie in diesem Beispiel sehen:

          guix import crate blake2-rfc

     Mit dem Crate-Importer können Sie auch eine Version als
     Zeichenkette angeben:

          guix import crate constant-time-eq@0.1.0

     Zu den zusätzlichen Optionen gehören:

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.

‘opam’
     Metadaten aus der Paketsammlung OPAM (https://opam.ocaml.org/) der
     OCaml-Gemeinde importieren.

     Zu den zusätzlichen Optionen gehören:

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.
     ‘--repo’
          Die angegebene Paketsammlung benutzen (anzugeben ist der
          Repository-Name). Zu den möglichen Werten gehören:
             • ‘opam’, das standardmäßige opam-Repository,
             • ‘coq’ oder ‘coq-released’, die stabile Paketsammlung von
               coq-Paketen.
             • ‘coq-core-dev’, die Paketsammlung mit
               Entwicklungsversionen von coq.
             • ‘coq-extra-dev’, die Paketsammlung mit
               Entwicklungsversionen von coq-Paketen.

‘go’
     Metadaten für ein Go-Modul von proxy.golang.org
     (https://proxy.golang.org) importieren.

          guix import go gopkg.in/yaml.v2

     Es ist möglich, bei der Paketspezifikation ein Suffix ‘@VERSION’
     anzugeben, um diese bestimmte Version zu importieren.

     Zu den zusätzlichen Optionen gehören:

     ‘--recursive’
     ‘-r’
          Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter
          rekursiv durchlaufen und Paketausdrücke für alle solchen
          Pakete erzeugen, die es in Guix noch nicht gibt.
     ‘--pin-versions’
          Wenn Sie diese Option verwenden, behält der Importer genau
          diese Version der Go-Modul-Abhängigkeiten bei, statt die
          neuesten verfügbaren Versionen zu benutzen. Das kann hilfreich
          sein, wenn Sie versuchen, Pakete zu importieren, die für deren
          Erstellung rekursiv von alten Versionen ihrer selbst abhängen.
          Wenn Sie diesen Modus nutzen, wird das Symbol für das Paket
          durch Anhängen der Versionsnummer an seinen Namen gebildet,
          damit mehrere Versionen desselben Pakets gleichzeitig
          existieren können.

   ‘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 *note Mitwirken::).


File: guix.de.info,  Node: Aufruf von guix refresh,  Next: Aufruf von guix lint,  Prev: Aufruf von guix import,  Up: Zubehör

9.6 ‘guix refresh’ aufrufen
===========================

Die Zielgruppe des Befehls ‘guix refresh’ zum Auffrischen von Paketen
sind in erster Linie Paketautoren. Als Nutzer könnten Sie an der
Befehlszeilenoption ‘--with-latest’ Interesse haben, die auf ‘guix
refresh’ aufbaut, um Ihnen Superkräfte bei der Paketaktualisierung zu
verleihen (siehe *note ‘--with-latest’: Paketumwandlungsoptionen.). Nach
Vorgabe werden mit ‘guix refresh’ alle Pakete in der Distribution
gemeldet, die nicht der neuesten Version des Anbieters entsprechen,
indem Sie dies ausführen:

     $ guix refresh
     gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
     gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

   Alternativ können die zu betrachtenden Pakete dabei angegeben werden,
was zur Ausgabe einer Warnung führt, wenn es für Pakete kein
Aktualisierungsprogramm gibt:

     $ guix refresh coreutils guile guile-ssh
     gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
     gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

   ‘guix refresh’ durchsucht die Paketsammlung beim Anbieter jedes
Pakets und bestimmt, was die höchste Versionsnummer ist, zu der es dort
eine Veröffentlichung gibt. Zum Befehl gehören Aktualisierungsprogramme,
mit denen bestimmte Typen von Paketen automatisch aktualisiert werden
können: GNU-Pakete, ELPA-Pakete usw. — siehe die Dokumentation von
‘--type’ unten. Es gibt jedoch auch viele Pakete, für die noch keine
Methode enthalten ist, um das Vorhandensein einer neuen Veröffentlichung
zu prüfen. Der Mechanismus ist aber erweiterbar, also können Sie gerne
mit uns in Kontakt treten, wenn Sie eine neue Methode hinzufügen
möchten!

‘--recursive’
     Hiermit werden die angegebenen Pakete betrachtet und außerdem alle
     Pakete, von denen sie abhängen.

          $ guix refresh --recursive coreutils
          gnu/packages/acl.scm:40:13: acl would be upgraded from 2.2.53 to 2.3.1
          gnu/packages/m4.scm:30:12: 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: 6.1.2 is already the latest version of gmp
          …

   Manchmal unterscheidet sich der vom Anbieter benutzte Name von dem
Paketnamen, der in Guix verwendet wird, so dass ‘guix refresh’ etwas
Unterstützung braucht. Die meisten Aktualisierungsprogramme folgen der
Eigenschaft ‘upstream-name’ in Paketdefinitionen, die diese
Unterstützung bieten kann.

     (define-public network-manager
       (package
         (name "network-manager")
         ;; …
         (properties '((upstream-name . "NetworkManager")))))

   Wenn ‘--update’ übergeben wird, werden die Quelldateien der
Distribution verändert, so dass für diese Paketrezepte die aktuelle
Version und die aktuelle Hash-Prüfsumme des Quellcode-Tarballs
eingetragen wird (siehe *note Pakete definieren::). Dazu werden der
neueste Quellcode-Tarball jedes Pakets sowie die jeweils zugehörige
OpenPGP-Signatur heruntergeladen; mit Letzterer wird der
heruntergeladene Tarball gegen seine Signatur mit ‘gpgv’ authentifiziert
und schließlich dessen Hash berechnet. Beachten Sie, dass GnuPG dazu
installiert sein und in ‘$PATH’ vorkommen muss. Falls dies nicht der
Fall ist, führen Sie ‘guix install gnupg’ aus.

   Wenn der öffentliche Schlüssel, mit dem der Tarball signiert wurde,
im Schlüsselbund des Benutzers fehlt, wird versucht, ihn automatisch von
einem Schlüssel-Server zu holen. Wenn das klappt, wird der Schlüssel zum
Schlüsselbund des Benutzers hinzugefügt, ansonsten meldet ‘guix refresh’
einen Fehler.

   Die folgenden Befehlszeilenoptionen werden unterstützt:

‘--expression=AUSDRUCK’
‘-e AUSDRUCK’
     Als Paket benutzen, wozu der AUSDRUCK ausgewertet wird.

     Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren,
     wie in diesem Beispiel:

          guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

     Dieser Befehls listet auf, was alles von der „endgültigen“
     Erstellung von libc abhängt (praktisch alle Pakete).

‘--update’
‘-u’
     Die Quelldateien der Distribution (die Paketrezepte) werden direkt
     „in place“ verändert. Normalerweise führen Sie dies aus einem
     Checkout des Guix-Quellbaums heraus aus (siehe *note Guix vor der
     Installation ausführen::):

          $ ./pre-inst-env guix refresh -s non-core -u

     Siehe *note Pakete definieren:: für mehr Informationen zu
     Paketdefinitionen.

‘--select=[TEILMENGE]’
‘-s TEILMENGE’
     Wählt alle Pakete aus der TEILMENGE aus, die entweder ‘core’ oder
     ‘non-core’ sein muss.

     Die ‘core’-Teilmenge bezieht sich auf alle Pakete, die den Kern der
     Distribution ausmachen, d.h. Pakete, aus denen heraus „alles
     andere“ erstellt wird. Dazu gehören GCC, libc, Binutils, Bash und
     so weiter. In der Regel ist die Folge einer Änderung an einem
     dieser Pakete in der Distribution, dass alle anderen neu erstellt
     werden müssen. Daher sind solche Änderungen unangenehm für Nutzer,
     weil sie einiges an Erstellungszeit oder Bandbreite investieren
     müssen, um die Aktualisierung abzuschließen.

     Die ‘non-core’-Teilmenge bezieht sich auf die übrigen Pakete. Sie
     wird typischerweise dann benutzt, wenn eine Aktualisierung der
     Kernpakete zu viele Umstände machen würde.

‘--manifest=DATEI’
‘-m DATEI’
     Wählt alle Pakete im in der DATEI stehenden Manifest aus. Das ist
     nützlich, um zu überprüfen, welche Pakete aus dem Manifest des
     Nutzers aktualisiert werden können.

‘--type=AKTUALISIERUNGSPROGRAMM’
‘-t AKTUALISIERUNGSPROGRAMM’
     Nur solche Pakete auswählen, die vom angegebenen
     AKTUALISIERUNGSPROGRAMM behandelt werden. Es darf auch eine
     kommagetrennte Liste mehrerer Aktualisierungsprogramme angegeben
     werden. Zurzeit kann als AKTUALISIERUNGSPROGRAMM eines der
     folgenden angegeben werden:

     ‘gnu’
          Aktualisierungsprogramm für GNU-Pakete,
     ‘savannah’
          Aktualisierungsprogramm auf Savannah
          (https://savannah.gnu.org) angebotener Pakete,
     ‘sourceforge’
          Aktualisierungsprogramm auf SourceForge
          (https://sourceforge.net) angebotener Pakete,
     ‘gnome’
          Aktualisierungsprogramm für GNOME-Pakete,
     ‘kde’
          Aktualisierungsprogramm für KDE-Pakete,
     ‘xorg’
          Aktualisierungsprogramm für X.org-Pakete,
     ‘kernel.org’
          Aktualisierungsprogramm auf kernel.org angebotener Pakete,
     ‘elpa’
          Aktualisierungsprogramm für ELPA-Pakete
          (https://elpa.gnu.org/),
     ‘cran’
          Aktualisierungsprogramm für CRAN-Pakete
          (https://cran.r-project.org/),
     ‘bioconductor’
          Aktualisierungsprogramm für R-Pakete vom Bioconductor
          (https://www.bioconductor.org/),
     ‘cpan’
          Aktualisierungsprogramm für CPAN-Pakete
          (https://www.cpan.org/),
     ‘pypi’
          Aktualisierungsprogramm für PyPI-Pakete
          (https://pypi.python.org),
     ‘gem’
          Aktualisierungsprogramm für RubyGems-Pakete
          (https://rubygems.org).
     ‘github’
          Aktualisierungsprogramm für GitHub-Pakete
          (https://github.com).
     ‘hackage’
          Aktualisierungsprogramm für Hackage-Pakete
          (https://hackage.haskell.org).
     ‘stackage’
          Aktualisierungsprogramm für Stackage-Pakete
          (https://www.stackage.org).
     ‘crate’
          Aktualisierungsprogramm für Crates-Pakete (https://crates.io).
     ‘launchpad’
          Aktualisierungsprogramm für Launchpad (https://launchpad.net).
     ‘generic-html’
          allgemeines Aktualisierungsprogramm, das mit einem Webcrawler
          die HTML-Seite, auf der der Quell-Tarball des Pakets angeboten
          wird, falls vorhanden, durchsucht.

     Zum Beispiel prüft folgender Befehl nur auf mögliche
     Aktualisierungen von auf ‘elpa.gnu.org’ angebotenen Emacs-Paketen
     und von CRAN-Paketen:

          $ guix refresh --type=elpa,cran
          gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
          gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9

‘--list-updaters’
‘-L’
     Eine Liste verfügbarer Aktualisierungsprogramme anzeigen und
     terminieren (siehe ‘--type’ oben).

     Für jedes Aktualisierungsprogramm den Anteil der davon betroffenen
     Pakete anzeigen; zum Schluss wird der Gesamtanteil von irgendeinem
     Aktualisierungsprogramm betroffener Pakete angezeigt.

   An ‘guix refresh’ können auch ein oder mehrere Paketnamen übergeben
werden wie in diesem Beispiel:

     $ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8

Der Befehl oben aktualisiert speziell das ‘emacs’- und das
‘idutils’-Paket. Eine Befehlszeilenoption ‘--select’ hätte dann keine
Wirkung. Vielleicht möchten Sie auch die Definitionen zu den in Ihr
Profil installierten Paketen aktualisieren:

     $ ./pre-inst-env guix refresh -u \
            $(guix package --list-installed | cut -f1)

   Wenn Sie sich fragen, ob ein Paket aktualisiert werden sollte oder
nicht, kann es helfen, sich anzuschauen, welche Pakete von der
Aktualisierung betroffen wären und auf Kompatibilität hin geprüft werden
sollten. Dazu kann die folgende Befehlszeilenoption zusammen mit einem
oder mehreren Paketnamen an ‘guix refresh’ übergeben werden:

‘--list-dependent’
‘-l’
     Auflisten, welche abhängigen Pakete auf oberster Ebene neu erstellt
     werden müssten, wenn eines oder mehrere Pakete aktualisiert würden.

     Siehe *note den ‘reverse-package’-Typ von ‘guix graph’: Aufruf von
     guix graph. für Informationen dazu, wie Sie die Liste der
     Abhängigen eines Pakets visualisieren können.

   Bedenken Sie, dass die Befehlszeilenoption ‘--list-dependent’ das
Ausmaß der nach einer Aktualisierungen benötigten Neuerstellungen nur
_annähert_. Es könnten auch unter Umständen mehr Neuerstellungen
anfallen.

     $ guix refresh --list-dependent flex
     Building the following 120 packages would ensure 213 dependent packages are rebuilt:
     hop@2.4.0 geiser@0.4 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 …

   Der oben stehende Befehl gibt einen Satz von Paketen aus, die Sie
erstellen wollen könnten, um die Kompatibilität einer Aktualisierung des
‘flex’-Pakets beurteilen zu können.

‘--list-transitive’
     Die Pakete auflisten, von denen eines oder mehrere Pakete abhängen.

          $ guix refresh --list-transitive flex
          flex@2.6.4 depends on the following 25 packages: perl@5.28.0 help2man@1.47.6
          bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 …

   Der oben stehende Befehl gibt einen Satz von Paketen aus, die, wenn
sie geändert würden, eine Neuerstellung des ‘flex’-Pakets auslösen
würden.

   Mit den folgenden Befehlszeilenoptionen können Sie das Verhalten von
GnuPG anpassen:

‘--gpg=BEFEHL’
     Den BEFEHL als GnuPG-2.x-Befehl einsetzen. Der BEFEHL wird im
     ‘$PATH’ gesucht.

‘--keyring=DATEI’
     Die DATEI als Schlüsselbund mit Anbieterschlüsseln verwenden. Die
     DATEI muss im “Keybox-Format” vorliegen. Keybox-Dateien haben
     normalerweise einen Namen, der auf ‘.kbx’ endet. Sie können mit
     Hilfe von GNU Privacy Guard (GPG) bearbeitet werden (siehe *note
     ‘kbxutil’: (gnupg)kbxutil. für Informationen über ein Werkzeug zum
     Bearbeiten von Keybox-Dateien).

     Wenn diese Befehlszeilenoption nicht angegeben wird, benutzt ‘guix
     refresh’ die Keybox-Datei ‘~/.config/guix/upstream/trustedkeys.kbx’
     als Schlüsselbund für Signierschlüssel von Anbietern.
     OpenPGP-Signaturen werden mit Schlüsseln aus diesem Schlüsselbund
     überprüft; fehlende Schlüssel werden auch in diesen Schlüsselbund
     heruntergeladen (siehe ‘--key-download’ unten).

     Sie können Schlüssel aus Ihrem normalerweise benutzten
     GPG-Schlüsselbund in eine Keybox-Datei exportieren, indem Sie
     Befehle wie diesen benutzen:

          gpg --export rms@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx

     Ebenso können Sie wie folgt Schlüssel in eine bestimmte
     Keybox-Datei herunterladen:

          gpg --no-default-keyring --keyring mykeyring.kbx \
            --recv-keys 27D586A4F8900854329FF09F1260E46482E63562

     Siehe *note ‘--keyring’: (gnupg)GPG Configuration Options. für mehr
     Informationen zur Befehlszeilenoption ‘--keyring’ von GPG.

‘--key-download=RICHTLINIE’
     Fehlende OpenPGP-Schlüssel gemäß dieser RICHTLINIE behandeln, für
     die eine der Folgenden angegeben werden kann:

     ‘always’
          Immer fehlende OpenPGP-Schlüssel herunterladen und zum
          GnuPG-Schlüsselbund des Nutzers hinzufügen.

     ‘never’
          Niemals fehlende OpenPGP-Schlüssel herunterladen, sondern
          einfach abbrechen.

     ‘interactive’
          Ist ein Paket mit einem unbekannten OpenPGP-Schlüssel
          signiert, wird der Nutzer gefragt, ob der Schlüssel
          heruntergeladen werden soll oder nicht. Dies entspricht dem
          vorgegebenen Verhalten.

‘--key-server=HOST’
     Den mit HOST bezeichneten Rechner als Schlüsselserver für OpenPGP
     benutzen, wenn ein öffentlicher Schlüssel importiert wird.

‘--load-path=VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar
     sind.

   Das ‘github’-Aktualisierungsprogramm benutzt die
GitHub-Programmierschnittstelle (https://developer.github.com/v3/) (die
„Github-API“), um Informationen über neue Veröffentlichungen einzuholen.
Geschieht dies oft, z.B. beim Auffrischen aller Pakete, so wird GitHub
irgendwann aufhören, weitere API-Anfragen zu beantworten. Normalerweise
sind 60 API-Anfragen pro Stunde erlaubt, für eine vollständige
Auffrischung aller GitHub-Pakete in Guix werden aber mehr benötigt. Wenn
Sie sich bei GitHub mit Ihrem eigenen API-Token authentisieren, gelten
weniger einschränkende Grenzwerte. Um einen API-Token zu benutzen,
setzen Sie die Umgebungsvariable ‘GUIX_GITHUB_TOKEN’ auf einen von
<https://github.com/settings/tokens> oder anderweitig bezogenen
API-Token.


File: guix.de.info,  Node: Aufruf von guix lint,  Next: Aufruf von guix size,  Prev: Aufruf von guix refresh,  Up: Zubehör

9.7 ‘guix lint’ aufrufen
========================

Den Befehl ‘guix lint’ gibt es, um Paketentwicklern beim Vermeiden
häufiger Fehler und bei der Einhaltung eines konsistenten Code-Stils zu
helfen. Er führt eine Reihe von Prüfungen auf einer angegebenen Menge
von Paketen durch, um in deren Definition häufige Fehler aufzuspüren. Zu
den verfügbaren “Prüfern” gehören (siehe ‘--list-checkers’ für eine
vollständige Liste):

‘synopsis’
‘description’
     Überprüfen, ob bestimmte typografische und stilistische Regeln in
     Paketbeschreibungen und -zusammenfassungen eingehalten wurden.

‘inputs-should-be-native’
     Eingaben identifizieren, die wahrscheinlich native Eingaben sein
     sollten.

‘source’
‘home-page’
‘mirror-url’
‘github-url’
‘source-file-name’
     Die URLs für die Felder ‘home-page’ und ‘source’ anrufen und nicht
     erreichbare URLs melden. Wenn passend, wird eine ‘mirror://’-URL
     vorgeschlagen. Wenn die Quell-URL auf eine GitHub-URL weiterleitet,
     wird eine Empfehlung ausgegeben, direkt letztere zu verwenden. Es
     wird geprüft, dass der Quell-Dateiname aussagekräftig ist, dass er
     also z.B. nicht nur aus einer Versionsnummer besteht oder als
     „git-checkout“ angegeben wurde, ohne dass ein ‘Dateiname’
     deklariert wurde (siehe *note „origin“-Referenz::).

‘source-unstable-tarball’
     Analysiert die ‘source’-URL, um zu bestimmen, ob der Tarball von
     GitHub automatisch generiert wurde oder zu einer Veröffentlichung
     gehört. Leider werden GitHubs automatisch generierte Tarballs
     manchmal neu generiert.

‘Ableitung’
     Prüft, ob die Ableitung der angegebenen Pakete auf allen
     unterstützten Systmen erfolgreich berechnet werden kann (siehe
     *note Ableitungen::).

‘profile-collisions’
     Prüft, ob die Installation der angegebenen Pakete in ein Profil zu
     Kollisionen führen würde. Kollisionen treten auf, wenn mehrere
     Pakete mit demselben Namen aber anderer Versionsnummer oder anderem
     Store-Dateinamen propagiert werden. Siehe *note
     ‘propagated-inputs’: „package“-Referenz. für weitere Informationen
     zu propagierten Eingaben.

‘archival’
     Überprüft, ob der Quellcode des Pakets bei der Software Heritage
     (https://www.softwareheritage.org) archiviert ist.

     Wenn der noch nicht archivierte Quellcode aus einem
     Versionskontrollsystem („Version Control System“, VCS) stammt, wenn
     er also z.B. mit ‘git-fetch’ bezogen wird, wird eine Anfrage an
     Software Heritage gestellt, diesen zu speichern („Save“), damit sie
     ihn irgendwann in deren Archiv aufnehmen. So wird gewährleistet,
     dass der Quellcode langfristig verfügbar bleibt und Guix notfalls
     auf Software Heritage zurückgreifen kann, falls der Quellcode bei
     seinem ursprünglichen Anbieter verschwindet. Der Status kürzlicher
     Archivierungsanfragen kann online eingesehen werden
     (https://archive.softwareheritage.org/save/#requests).

     Wenn der Quellcode in Form eines über ‘url-fetch’ zu beziehenden
     Tarballs vorliegt, wird bloß eine Nachricht ausgegeben, wenn er
     nicht archiviert ist. Zum Zeitpunkt, wo dies geschrieben wurde,
     ermöglicht Software Heritage keine Anfragen, beliebige Tarballs zu
     archivieren; wir arbeiten an Möglichkeiten wie auch _nicht_
     versionskontrollierter Quellcode archiviert werden kann.

     Software Heritage beschränkt
     (https://archive.softwareheritage.org/api/#rate-limiting), wie
     schnell dieselbe IP-Adresse Anfragen stellen kann. Ist das Limit
     erreicht, gibt ‘guix lint’ eine Mitteilung aus und der
     ‘archival’-Prüfer steht so lange still, bis die Beschränkung wieder
     zurückgesetzt wurde.

‘cve’
     Bekannte Sicherheitslücken melden, die in den Datenbanken der
     „Common Vulnerabilities and Exposures“ (CVE) aus diesem und dem
     letzten Jahr vorkommen, wie sie von der US-amerikanischen NIST
     veröffentlicht werden (https://nvd.nist.gov/vuln/data-feeds).

     Um Informationen über eine bestimmte Sicherheitslücke angezeigt zu
     bekommen, besuchen Sie Webseiten wie:

        • 
          ‘https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD’
        • ‘https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD’

     wobei Sie statt ‘CVE-YYYY-ABCD’ die CVE-Kennnummer angeben — z.B.
     ‘CVE-2015-7554’.

     Paketentwickler können in ihren Paketrezepten den Namen und die
     Version des Pakets in der Common Platform Enumeration (CPE)
     (https://nvd.nist.gov/products/cpe) angeben, falls sich diese von
     dem in Guix benutzten Namen und der Version unterscheiden, zum
     Beispiel so:

          (package
            (name "grub")
            ;; …
            ;; CPE bezeichnet das Paket als "grub2".
            (properties '((cpe-name . "grub2")
                          (cpe-version . "2.3"))))

     Manche Einträge in der CVE-Datenbank geben die Version des Pakets
     nicht an, auf das sie sich beziehen, und würden daher bis in alle
     Ewigkeit Warnungen auslösen. Paketentwickler, die CVE-Warnmeldungen
     gefunden und geprüft haben, dass diese ignoriert werden können,
     können sie wie in diesem Beispiel deklarieren:

          (package
            (name "t1lib")
            ;; …
            ;; Diese CVEs treffen nicht mehr zu und können bedenkenlos ignoriert
            ;; werden.
            (properties `((lint-hidden-cve . ("CVE-2011-0433"
                                              "CVE-2011-1553"
                                              "CVE-2011-1554"
                                              "CVE-2011-5244")))))

‘Formatierung’
     Offensichtliche Fehler bei der Formatierung von Quellcode melden,
     z.B. Leerraum-Zeichen am Zeilenende oder Nutzung von
     Tabulatorzeichen.

   Die allgemeine Syntax lautet:

     guix lint OPTIONEN PAKETE…

   Wird kein Paket auf der Befehlszeile angegeben, dann werden alle
Pakete geprüft, die es gibt. Als OPTIONEN können null oder mehr der
folgenden Befehlszeilenoptionen übergeben werden:

‘--list-checkers’
‘-l’
     Alle verfügbaren Prüfer für die Pakete auflisten und beschreiben.

‘--checkers’
‘-c’
     Nur die Prüfer aktivieren, die hiernach in einer kommagetrennten
     Liste aus von ‘--list-checkers’ aufgeführten Prüfern vorkommen.

‘--exclude’
‘-x’
     Nur die Prüfer deaktivieren, die hiernach in einer kommagetrennten
     Liste aus von ‘--list-checkers’ aufgeführten Prüfern vorkommen.

‘--no-network’
‘-n’
     Nur die Prüfer aktivieren, die keinen Internetzugang benötigen.

‘--load-path=VERZEICHNIS’
‘-L VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar
     sind.


File: guix.de.info,  Node: Aufruf von guix size,  Next: Aufruf von guix graph,  Prev: Aufruf von guix lint,  Up: Zubehör

9.8 ‘guix size’ aufrufen
========================

Der Befehl ‘guix size’ hilft Paketentwicklern dabei, den
Plattenplatzverbrauch von Paketen zu profilieren. Es ist leicht, die
Auswirkungen zu unterschätzen, die das Hinzufügen zusätzlicher
Abhängigkeiten zu einem Paket hat oder die das Verwenden einer einzelnen
Ausgabe für ein leicht aufteilbares Paket ausmacht (siehe *note Pakete
mit mehreren Ausgaben.::). Das sind typische Probleme, auf die ‘guix
size’ aufmerksam machen kann.

   Dem Befehl können eine oder mehrere Paketspezifikationen wie
‘gcc@4.8’ oder ‘guile:debug’ übergeben werden, oder ein Dateiname im
Store. Betrachten Sie dieses Beispiel:

     $ guix size coreutils
     Store-Objekt                            Gesamt   Selbst
     /gnu/store/…-gcc-5.5.0-lib           60.4    30.1  38.1%
     /gnu/store/…-glibc-2.27              30.3    28.8  36.6%
     /gnu/store/…-coreutils-8.28          78.9    15.0  19.0%
     /gnu/store/…-gmp-6.1.2               63.1     2.7   3.4%
     /gnu/store/…-bash-static-4.4.12       1.5     1.5   1.9%
     /gnu/store/…-acl-2.2.52              61.1     0.4   0.5%
     /gnu/store/…-attr-2.4.47             60.6     0.2   0.3%
     /gnu/store/…-libcap-2.25             60.5     0.2   0.2%
     Gesamt: 78.9 MiB

   Die hier aufgelisteten Store-Objekte bilden den “transitiven
Abschluss” der Coreutils — d.h. die Coreutils und all ihre
Abhängigkeiten und deren Abhängigkeiten, rekursiv —, wie sie hiervon
angezeigt würden:<f

     $ guix gc -R /gnu/store/…-coreutils-8.23

   Hier zeigt die Ausgabe neben den Store-Objekten noch drei Spalten.
Die erste Spalte namens „Gesamt“ gibt wieder, wie viele Mebibytes (MiB)
der Abschluss des Store-Objekts groß ist — das heißt, dessen eigene
Größe plus die Größe all seiner Abhängigkeiten. Die nächste Spalte,
bezeichnet mit „Selbst“, zeigt die Größe nur dieses Objekts an. Die
letzte Spalte zeigt das Verhältnis der Größe des Objekts zur Gesamtgröße
aller hier aufgelisteten Objekte an.

   In diesem Beispiel sehen wir, dass der Abschluss der Coreutils 79 MiB
schwer ist, wovon das meiste durch libc und die Bibliotheken zur
Laufzeitunterstützung von GCC ausgemacht wird. (Dass libc und die
Bibliotheken vom GCC einen großen Anteil am Abschluss ausmachen, ist
aber an sich noch kein Problem, weil es Bibliotheken sind, die auf dem
System sowieso immer verfügbar sein müssen.)

   Weil der Befehl auch Namen von Store-Dateien akzeptiert, kann man
damit auch die Größe eines Erstellungsergebnisses ermitteln:

     guix size $(guix system build config.scm)

   Wenn das oder die Paket(e), die an ‘guix size’ übergeben wurden, im
Store verfügbar sind(1), beauftragen Sie mit ‘guix size’ den Daemon, die
Abhängigkeiten davon zu bestimmen und deren Größe im Store zu messen,
ähnlich wie es mit ‘du -ms --apparent-size’ geschehen würde (siehe *note
(coreutils)du invocation::).

   Wenn die übergebenen Pakete _nicht_ im Store liegen, erstattet ‘guix
size’ Bericht mit Informationen, die aus verfügbaren Substituten
herausgelesen werden (siehe *note Substitute::). Dadurch kann die
Plattenausnutzung von Store-Objekten profiliert werden, die gar nicht
auf der Platte liegen und nur auf entfernten Rechnern vorhanden sind.

   Sie können auch mehrere Paketnamen angeben:

     $ guix size coreutils grep sed bash
     Store-Objekt                            Gesamt   Selbst
     /gnu/store/…-coreutils-8.24          77.8    13.8  13.4%
     /gnu/store/…-grep-2.22               73.1     0.8   0.8%
     /gnu/store/…-bash-4.3.42             72.3     4.7   4.6%
     /gnu/store/…-readline-6.3            67.6     1.2   1.2%
     …
     Gesamt: 102.3 MiB

In diesem Beispiel sehen wir, dass die Kombination der vier Pakete
insgesamt 102,3 MiB Platz verbraucht, was wesentlich weniger als die
Summe der einzelnen Abschlüsse ist, weil diese viele Abhängigkeiten
gemeinsam verwenden.

   Wenn Sie sich das von ‘guix size’ gelieferte Profil anschauen, fragen
Sie sich vielleicht, warum ein bestimmtes Paket überhaupt darin
auftaucht. Den Grund erfahren Sie, wenn Sie ‘guix graph --path -t
references’ benutzen, um sich den kürzesten Pfad zwischen zwei Paketen
anzeigen zu lassen (siehe *note Aufruf von guix graph::).

   Die verfügbaren Befehlszeilenoptionen sind:

‘--substitute-urls=URLS’
     Substitutinformationen von den URLS benutzen. Siehe *note dieselbe
     Option bei ‘guix build’: client-substitute-urls.

‘--sort=SCHLÜSSEL’
     Zeilen anhand des SCHLÜSSELs sortieren, der eine der folgenden
     Alternativen sein muss:

     ‘self’
          die Größe jedes Objekts (die Vorgabe),
     ‘Abschluss’
          die Gesamtgröße des Abschlusses des Objekts.

‘--map-file=DATEI’
     Eine grafische Darstellung des Plattenplatzverbrauchs als eine
     PNG-formatierte Karte in die DATEI schreiben.

     Für das Beispiel oben sieht die Karte so aus:

[image src="images/coreutils-size-map.png" alt="Karte der Plattenausnutzung der
Coreutils"]

     Diese Befehlszeilenoption setzt voraus, dass Guile-Charting
     (https://wingolog.org/software/guile-charting/) installiert und im
     Suchpfad für Guile-Module sichtbar ist. Falls nicht, schlägt ‘guix
     size’ beim Versuch fehl, dieses Modul zu laden.

‘--system=SYSTEM’
‘-s SYSTEM’
     Pakete für dieses SYSTEM betrachten — z.B. für ‘x86_64-linux’.

‘--load-path=VERZEICHNIS’
‘-L VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar
     sind.

   ---------- Footnotes ----------

   (1) Genauer gesagt braucht ‘guix size’ die _nicht veredelte_ Variante
des angegebenen Pakets bzw. der Pakete, wie ‘guix build PAKET
--no-grafts’ sie liefert. Siehe *note Sicherheitsaktualisierungen:: für
Informationen über Veredelungen.


File: guix.de.info,  Node: Aufruf von guix graph,  Next: Aufruf von guix publish,  Prev: Aufruf von guix size,  Up: Zubehör

9.9 ‘guix graph’ aufrufen
=========================

Pakete und ihre Abhängigkeiten bilden einen “Graphen”, genauer gesagt
einen gerichteten azyklischen Graphen (englisch „Directed Acyclic
Graph“, kurz DAG). Es kann schnell schwierig werden, ein Modell eines
Paket-DAGs vor dem geistigen Auge zu behalten, weshalb der Befehl ‘guix
graph’ eine visuelle Darstellung des DAGs bietet. Das vorgegebene
Verhalten von ‘guix graph’ ist, eine DAG-Darstellung im Eingabeformat
von Graphviz (https://www.graphviz.org/) auszugeben, damit die Ausgabe
direkt an den Befehl ‘dot’ aus Graphviz weitergeleitet werden kann. Es
kann aber auch eine HTML-Seite mit eingebettetem JavaScript-Code
ausgegeben werden, um ein Sehnendiagramm (englisch „Chord Diagram“) in
einem Web-Browser anzuzeigen, mit Hilfe der Bibliothek d3.js
(https://d3js.org/), oder es können Cypher-Anfragen ausgegeben werden,
mit denen eine die Anfragesprache openCypher
(https://www.opencypher.org/) unterstützende Graph-Datenbank einen
Graphen konstruieren kann. Wenn Sie ‘--path’ angeben, zeigt Guix Ihnen
einfach nur den kürzesten Pfad zwischen zwei Paketen an. Die allgemeine
Syntax ist:

     guix graph OPTIONEN PAKETE…

   Zum Beispiel erzeugt der folgende Befehl eine PDF-Datei, die den
Paket-DAG für die GNU Core Utilities darstellt, welcher ihre
Abhängigkeiten zur Erstellungszeit anzeigt:

     guix graph coreutils | dot -Tpdf > dag.pdf

   Die Ausgabe sieht so aus:

[image src="images/coreutils-graph.png" alt="Abhängigkeitsgraph der GNU Coreutils"]

   Ein netter, kleiner Graph, oder?

   Vielleicht ist es Ihnen aber lieber, den Graphen interaktiv mit dem
‘xdot’-Programm anzuschauen (aus dem Paket ‘xdot’):

     guix graph coreutils | xdot -

   Aber es gibt mehr als eine Art von Graph! Der Graph oben ist kurz und
knapp: Es ist der Graph der Paketobjekte, ohne implizite Eingaben wie
GCC, libc, grep und so weiter. Oft möchte man einen knappen Graphen
sehen, aber manchmal will man auch mehr Details sehen. ‘guix graph’
unterstützt mehrere Typen von Graphen; Sie können den Detailgrad
auswählen.

‘package’
     Der vorgegebene Typ aus dem Beispiel oben. Er zeigt den DAG der
     Paketobjekte ohne implizite Abhängigkeiten. Er ist knapp, filtert
     aber viele Details heraus.

‘reverse-package’
     Dies zeigt den _umgekehrten_ DAG der Pakete. Zum Beispiel liefert

          guix graph --type=reverse-package ocaml

     … den Graphen der Pakete, die _explizit_ von OCaml abhängen (wenn
     Sie auch an Fällen interessiert sind, bei denen OCaml eine
     implizite Abhängigkeit ist, siehe ‘reverse-bag’ weiter unten).

     Beachten Sie, dass für Kernpakete damit gigantische Graphen
     entstehen können. Wenn Sie nur die Anzahl der Pakete wissen wollen,
     die von einem gegebenen Paket abhängen, benutzen Sie ‘guix refresh
     --list-dependent’ (siehe *note ‘--list-dependent’: Aufruf von guix
     refresh.).

‘bag-emerged’
     Dies ist der Paket-DAG _einschließlich_ impliziter Eingaben.

     Zum Beispiel liefert der folgende Befehl

          guix graph --type=bag-emerged coreutils

     … diesen größeren Graphen:

[image src="images/coreutils-bag-graph.png" alt="Detaillierter Abhängigkeitsgraph der
GNU Coreutils"]

     Am unteren Rand des Graphen sehen wir alle impliziten Eingaben des
     GNU-BUILD-SYSTEM (siehe *note ‘gnu-build-system’:
     Erstellungssysteme.).

     Beachten Sie dabei aber, dass auch hier die Abhängigkeiten dieser
     impliziten Eingaben — d.h. die “Bootstrap-Abhängigkeiten” (siehe
     *note Bootstrapping::) — nicht gezeigt werden, damit der Graph
     knapper bleibt.

‘bag’
     Ähnlich wie ‘bag-emerged’, aber diesmal mit allen
     Bootstrap-Abhängigkeiten.

‘bag-with-origins’
     Ähnlich wie ‘bag’, aber auch mit den Ursprüngen und deren
     Abhängigkeiten.

‘reverse-bag’
     Dies zeigt den _umgekehrten_ DAG der Pakete. Anders als
     ‘reverse-package’ werden auch implizite Abhängigkeiten
     berücksichtigt. Zum Beispiel liefert

          guix graph -t reverse-bag dune

     … den Graphen aller Pakete, die von Dune direkt oder indirekt
     abhängen. Weil Dune eine _implizite_ Abhängigkeit von vielen
     Paketen über das ‘dune-build-system’ ist, zeigt er eine große Zahl
     von Paketen, während bei ‘reverse-package’ nur sehr wenige bis gar
     keine zu sehen sind.

‘Ableitung’
     Diese Darstellung ist am detailliertesten: Sie zeigt den DAG der
     Ableitungen (siehe *note Ableitungen::) und der einfachen
     Store-Objekte. Verglichen mit obiger Darstellung sieht man viele
     zusätzliche Knoten einschließlich Erstellungs-Skripts, Patches,
     Guile-Module usw.

     Für diesen Typ Graph kann auch der Name einer ‘.drv’-Datei anstelle
     eines Paketnamens angegeben werden, etwa so:

          guix graph -t derivation $(guix system build -d my-config.scm)

‘Modul’
     Dies ist der Graph der “Paketmodule” (siehe *note Paketmodule::).
     Zum Beispiel zeigt der folgende Befehl den Graphen für das
     Paketmodul an, das das ‘guile’-Paket definiert:

          guix graph -t module guile | xdot -

   Alle oben genannten Typen entsprechen _Abhängigkeiten zur
Erstellungszeit_. Der folgende Graphtyp repräsentiert die
_Abhängigkeiten zur Laufzeit_:

‘references’
     Dies ist der Graph der “Referenzen” einer Paketausgabe, wie ‘guix
     gc --references’ sie liefert (siehe *note Aufruf von guix gc::).

     Wenn die angegebene Paketausgabe im Store nicht verfügbar ist,
     versucht ‘guix graph’, die Abhängigkeitsinformationen aus
     Substituten zu holen.

     Hierbei können Sie auch einen Store-Dateinamen statt eines
     Paketnamens angeben. Zum Beispiel generiert der Befehl unten den
     Referenzgraphen Ihres Profils (der sehr groß werden kann!):

          guix graph -t references $(readlink -f ~/.guix-profile)

‘referrers’
     Dies ist der Graph der ein Store-Objekt “referenzierenden” Objekte,
     wie ‘guix gc --referrers’ sie liefern würde (siehe *note Aufruf von
     guix gc::).

     Er basiert ausschließlich auf lokalen Informationen aus Ihrem
     Store. Nehmen wir zum Beispiel an, dass das aktuelle Inkscape in 10
     Profilen verfügbar ist, dann wird ‘guix graph -t referrers
     inkscape’ einen Graph zeigen, der bei Inkscape gewurzelt ist und
     Kanten zu diesen 10 Profilen hat.

     Ein solcher Graph kann dabei helfen, herauszufinden, weshalb ein
     Store-Objekt nicht vom Müllsammler abgeholt werden kann.

   Oftmals passt der Graph des Pakets, für das Sie sich interessieren,
nicht auf Ihren Bildschirm, und überhaupt möchten Sie ja nur wissen,
_warum_ das Paket von einem anderen abhängt, das scheinbar nichts damit
zu tun hat. Die Befehlszeilenoption ‘--path’ weist ‘guix graph’ an, den
kürzesten Pfad zwischen zwei Paketen (oder Ableitungen, Store-Objekten
etc.) anzuzeigen:

     $ guix graph --path emacs libunistring
     emacs@26.3
     mailutils@3.9
     libunistring@0.9.10
     $ guix graph --path -t derivation emacs libunistring
     /gnu/store/…-emacs-26.3.drv
     /gnu/store/…-mailutils-3.9.drv
     /gnu/store/…-libunistring-0.9.10.drv
     $ guix graph --path -t references emacs libunistring
     /gnu/store/…-emacs-26.3
     /gnu/store/…-libidn2-2.2.0
     /gnu/store/…-libunistring-0.9.10

   Folgendes sind die verfügbaren Befehlszeilenoptionen:

‘--type=TYP’
‘-t TYP’
     Eine Graph-Ausgabe dieses TYPs generieren. Dieser TYP muss einer
     der oben genannten Werte sein.

‘--list-types’
     Die unterstützten Graph-Typen auflisten.

‘--backend=BACKEND’
‘-b BACKEND’
     Einen Graph mit Hilfe des ausgewählten BACKENDs generieren.

‘--list-backends’
     Die unterstützten Graph-Backends auflisten.

     Derzeit sind die verfügbaren Backends Graphviz und d3.js.

‘--path’
     Den kürzesten Pfad zwischen zwei Knoten anzeigen, die den mit
     ‘--type’ angegebenen Typ aufweisen. Im Beispiel unten wird der
     kürzeste Pfad zwischen ‘libreoffice’ und ‘llvm’ anhand der
     Referenzen von ‘libreoffice’ angezeigt:

          $ guix graph --path -t references libreoffice llvm
          /gnu/store/…-libreoffice-6.4.2.2
          /gnu/store/…-libepoxy-1.5.4
          /gnu/store/…-mesa-19.3.4
          /gnu/store/…-llvm-9.0.1

‘--expression=AUSDRUCK’
‘-e AUSDRUCK’
     Als Paket benutzen, wozu der AUSDRUCK ausgewertet wird.

     Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren,
     wie in diesem Beispiel:

          guix graph -e '(@@ (gnu packages commencement) gnu-make-final)'

‘--system=SYSTEM’
‘-s SYSTEM’
     Den Graphen für das SYSTEM anzeigen — z.B. ‘i686-linux’.

     Der Abhängigkeitsgraph ist größtenteils von der Systemarchitektur
     unabhängig, aber ein paar architekturabhängige Teile können Ihnen
     mit dieser Befehlszeilenoption visualisiert werden.

‘--load-path=VERZEICHNIS’
‘-L VERZEICHNIS’
     Das VERZEICHNIS vorne an den Suchpfad für Paketmodule anfügen
     (siehe *note Paketmodule::).

     Damit können Nutzer dafür sorgen, dass ihre eigenen
     selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar
     sind.

   Hinzu kommt, dass ‘guix graph’ auch all die üblichen
Paketumwandlungsoptionen unterstützt (siehe *note
Paketumwandlungsoptionen::). Somit ist es kein Problem, die Folgen einer
den Paketgraphen umschreibenden Umwandlung wie ‘--with-input’ zu
erkennen. Zum Beispiel gibt der folgende Befehl den Graphen von ‘git’
aus, nachdem ‘openssl’ an allen Stellen im Graphen durch ‘libressl’
ersetzt wurde:

     guix graph git --with-input=openssl=libressl

   Ihrem Vergnügen sind keine Grenzen gesetzt!


File: guix.de.info,  Node: Aufruf von guix publish,  Next: Aufruf von guix challenge,  Prev: Aufruf von guix graph,  Up: Zubehör

9.10 ‘guix publish’ aufrufen
============================

Der Zweck von ‘guix publish’ ist, es Nutzern zu ermöglichen, ihren Store
auf einfache Weise mit anderen zu teilen, die ihn dann als
Substitutserver einsetzen können (siehe *note Substitute::).

   Wenn ‘guix publish’ ausgeführt wird, wird dadurch ein HTTP-Server
gestartet, so dass jeder mit Netzwerkzugang davon Substitute beziehen
kann. Das bedeutet, dass jede Maschine, auf der Guix läuft, auch als
Erstellungsfarm fungieren kann, weil die HTTP-Schnittstelle mit Cuirass,
der Software, mit der die offizielle Erstellungsfarm ‘ci.guix.gnu.org’
betrieben wird, kompatibel ist.

   Um Sicherheit zu gewährleisten, wird jedes Substitut signiert, so
dass Empfänger dessen Authentizität und Integrität nachprüfen können
(siehe *note Substitute::). Weil ‘guix publish’ den Signierschlüssel des
Systems benutzt, der nur vom Systemadministrator gelesen werden kann,
muss es als der Administratornutzer „root“ gestartet werden. Mit der
Befehlszeilenoption ‘--user’ werden Administratorrechte bald nach dem
Start wieder abgelegt.

   Das Schlüsselpaar zum Signieren muss erzeugt werden, bevor ‘guix
publish’ gestartet wird. Dazu können Sie ‘guix archive --generate-key’
ausführen (siehe *note Aufruf von guix archive::).

   Wird die Befehlszeilenoption ‘--advertise’ übergeben, teilt der
Server anderen Rechnern im lokalen Netzwerk seine Verfügbarkeit mit,
über Multicast-DNS (mDNS) und DNS-Service-Discovery (DNS-SD), zurzeit
mittels Guile-Avahi (siehe *note (guile-avahi)Top::).

   Die allgemeine Syntax lautet:

     guix publish OPTIONEN…

   Wird ‘guix publish’ ohne weitere Argumente ausgeführt, wird damit ein
HTTP-Server gestartet, der auf Port 8080 lauscht:

     guix publish

   Sobald ein Server zum Veröffentlichen autorisiert wurde, kann der
Daemon davon Substitute herunterladen. Siehe *note Substitute von
anderen Servern holen::.

   Nach den Voreinstellungen komprimiert ‘guix publish’ Archive erst
dann, wenn sie angefragt werden. Dieser „dynamische“ Modus bietet sich
an, weil so nichts weiter eingerichtet werden muss und er direkt
verfügbar ist. Wenn Sie allerdings viele Clients bedienen wollen,
empfehlen wir, dass Sie die Befehlszeilenoption ‘--cache’ benutzen, die
das Zwischenspeichern der komprimierten Archive aktiviert, bevor diese
an die Clients geschickt werden — siehe unten für Details. Mit dem
Befehl ‘guix weather’ haben Sie eine praktische Methode zur Hand, zu
überprüfen, was so ein Server anbietet (siehe *note Aufruf von guix
weather::).

   Als Bonus dient ‘guix publish’ auch als inhaltsadressierbarer
Spiegelserver für Quelldateien, die in ‘origin’-Verbundsobjekten
eingetragen sind (siehe *note „origin“-Referenz::). Wenn wir zum
Beispiel annehmen, dass ‘guix publish’ auf ‘example.org’ läuft, liefert
folgende URL die rohe ‘hello-2.10.tar.gz’-Datei mit dem angegebenen
SHA256-Hash als ihre Prüfsumme (dargestellt im ‘nix-base32’-Format,
siehe *note Aufruf von guix hash::):

     http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1…ndq1i

   Offensichtlich funktionieren diese URLs nur mit solchen Dateien, die
auch im Store vorliegen; in anderen Fällen werden sie 404 („Nicht
gefunden“) zurückliefern.

   Erstellungsprotokolle sind unter ‘/log’-URLs abrufbar:

     http://example.org/log/gwspk…-guile-2.2.3

Ist der ‘guix-daemon’ so eingestellt, dass er Erstellungsprotokolle
komprimiert abspeichert, wie es voreingestellt ist (siehe *note Aufruf
des guix-daemon::), liefern ‘/log’-URLs das unveränderte komprimierte
Protokoll, mit einer entsprechenden ‘Content-Type’- und/oder
‘Content-Encoding’-Kopfzeile. Wir empfehlen dabei, dass Sie den
‘guix-daemon’ mit ‘--log-compression=gzip’ ausführen, weil Web-Browser
dieses Format automatisch dekomprimieren können, was bei
Bzip2-Kompression nicht der Fall ist.

   Folgende Befehlszeilenoptionen stehen zur Verfügung:

‘--port=PORT’
‘-p PORT’
     Auf HTTP-Anfragen auf diesem PORT lauschen.

‘--listen=HOST’
     Auf der Netzwerkschnittstelle für den angegebenen HOST, also der
     angegebenen Rechneradresse, lauschen. Vorgegeben ist, Verbindungen
     mit jeder Schnittstelle zu akzeptieren.

‘--user=BENUTZER’
‘-u BENUTZER’
     So früh wie möglich alle über die Berechtigungen des BENUTZERs
     hinausgehenden Berechtigungen ablegen — d.h. sobald der
     Server-Socket geöffnet und der Signierschlüssel gelesen wurde.

‘--compression[=METHODE[:STUFE]]’
‘-C [METHODE[:STUFE]]’
     Daten auf der angegebenen Kompressions-STUFE mit der angegebenen
     METHODE komprimieren. Als METHODE kann entweder ‘lzip’, ‘zstd’ oder
     ‘gzip’ angegeben werden. Wird keine METHODE angegeben, wird ‘gzip’
     benutzt.

     Daten auf der angegebenen Kompressions-STUFE komprimieren. Wird als
     STUFE null angegeben, wird Kompression deaktiviert. Der Bereich von
     1 bis 9 entspricht unterschiedlichen Kompressionsstufen: 1 ist am
     schnellsten, während 9 am besten komprimiert (aber den Prozessor
     mehr auslastet). Der Vorgabewert ist 3.

     Normalerweise ist die Kompression mit ‘lzip’ wesentlich besser als
     bei ‘gzip’, dafür wird der Prozessor geringfügig stärker
     ausgelastet; siehe Vergleichswerte auf dem Webauftritt von lzip
     (https://nongnu.org/lzip/lzip_benchmark.html). ‘lzip’ erreicht
     jedoch nur einen niedrigen Durchsatz bei der Dekompression (in der
     Größenordnung von 50 MiB/s auf moderner Hardware), was einen
     Engpass beim Herunterladen über schnelle Netzwerkverbindungen
     darstellen kann.

     Das Kompressionsverhältnis von ‘zstd’ liegt zwischen dem von ‘lzip’
     und dem von ‘gzip’; sein größter Vorteil ist eine hohe
     Geschwindigkeit bei der Dekompression
     (https://facebook.github.io/zstd/).

     Wenn ‘--cache’ nicht übergeben wird, werden Daten dynamisch immer
     erst dann komprimiert, wenn sie abgeschickt werden; komprimierte
     Datenströme landen in keinem Zwischenspeicher. Um also die
     Auslastung der Maschine, auf der ‘guix publish’ läuft, zu
     reduzieren, kann es eine gute Idee sein, eine niedrige
     Kompressionsstufe zu wählen, ‘guix publish’ einen Proxy mit
     Zwischenspeicher (einen „Caching Proxy“) voranzuschalten, oder
     ‘--cache’ zu benutzen. ‘--cache’ zu benutzen, hat den Vorteil, dass
     ‘guix publish’ damit eine ‘Content-Length’-HTTP-Kopfzeile seinen
     Antworten beifügen kann.

     Wenn diese Befehlszeilenoption mehrfach angegeben wird, wird jedes
     Substitut mit allen ausgewählten Methoden komprimiert und jede
     davon wird bei Anfragen mitgeteilt. Das ist nützlich, weil
     Benutzer, bei denen nicht alle Kompressionsmethoden unterstützt
     werden, die passende wählen können.

‘--cache=VERZEICHNIS’
‘-c VERZEICHNIS’
     Archive und Metadaten (‘.narinfo’-URLs) in das VERZEICHNIS
     zwischenspeichern und nur solche Archive versenden, die im
     Zwischenspeicher vorliegen.

     Wird diese Befehlszeilenoption weggelassen, dann werden Archive und
     Metadaten „dynamisch“ erst auf eine Anfrage hin erzeugt. Dadurch
     kann die verfügbare Bandbreite reduziert werden, besonders wenn
     Kompression aktiviert ist, weil die Operation dann durch die
     Prozessorleistung beschränkt sein kann. Noch ein Nachteil des
     voreingestellten Modus ist, dass die Länge der Archive nicht im
     Voraus bekannt ist, ‘guix publish’ also keine
     ‘Content-Length’-HTTP-Kopfzeile an seine Antworten anfügt, wodurch
     Clients nicht wissen können, welche Datenmenge noch heruntergeladen
     werden muss.

     Im Gegensatz dazu löst, wenn ‘--cache’ benutzt wird, die erste
     Anfrage nach einem Store-Objekt (über dessen ‘.narinfo’-URL) den
     Start eines Hintergrundprozesses aus, der das Archiv in den
     Zwischenspeicher einlagert (auf Englisch sagen wir „bake the
     archive“), d.h. seine ‘.narinfo’ wird berechnet und das Archiv,
     falls nötig, komprimiert. Sobald das Archiv im VERZEICHNIS
     zwischengespeichert wurde, werden nachfolgende Anfragen erfolgreich
     sein und direkt aus dem Zwischenspeicher bedient, der garantiert,
     dass Clients optimale Bandbreite genießen.

     Die erste Anfrage nach einer ‘.narinfo’ wird trotzdem 200
     zurückliefern, wenn das angefragte Store-Objekt „klein genug“ ist,
     also kleiner als der Schwellwert für die Zwischenspeicherumgehung,
     siehe ‘--cache-bypass-threshold’ unten. So müssen Clients nicht
     darauf warten, dass das Archiv eingelagert wurde. Bei größeren
     Store-Objekten liefert die erste ‘.narinfo’-Anfrage 404 zurück, was
     bedeutet, dass Clients warten müssen, bis das Archiv eingelagert
     wurde.

     Der Prozess zum Einlagern wird durch Worker-Threads umgesetzt. Der
     Vorgabe entsprechend wird dazu pro Prozessorkern ein Thread
     erzeugt, aber dieses Verhalten kann angepasst werden. Siehe
     ‘--workers’ weiter unten.

     Wird ‘--ttl’ verwendet, werden zwischengespeicherte Einträge
     automatisch gelöscht, sobald die dabei angegebene Zeit abgelaufen
     ist.

‘--workers=N’
     Wird ‘--cache’ benutzt, wird die Reservierung von N Worker-Threads
     angefragt, um Archive einzulagern.

‘--ttl=TTL’
     ‘Cache-Control’-HTTP-Kopfzeilen erzeugen, die eine Time-to-live
     (TTL) von TTL signalisieren. Für TTL muss eine Dauer (mit dem
     Anfangsbuchstaben der Maßeinheit der Dauer im Englischen) angegeben
     werden: ‘5d’ bedeutet 5 Tage, ‘1m’ bedeutet 1 Monat und so weiter.

     Das ermöglicht es Guix, Substitutinformationen TTL lang
     zwischenzuspeichern. Beachten Sie allerdings, dass ‘guix publish’
     selbst _nicht_ garantiert, dass die davon angebotenen Store-Objekte
     so lange verfügbar bleiben, wie es die TTL vorsieht.

     Des Weiteren können bei Nutzung von ‘--cache’ die
     zwischengespeicherten Einträge gelöscht werden, wenn auf sie TTL
     lang nicht zugegriffen wurde und kein ihnen entsprechendes Objekt
     mehr im Store existiert.

‘--cache-bypass-threshold=GRÖSSE’
     Wird dies in Verbindung mit ‘--cache’ angegeben, werden
     Store-Objekte kleiner als die GRÖSSE sofort verfügbar sein, obwohl
     sie noch nicht in den Zwischenspeicher eingelagert wurden. Die
     GRÖSSE gibt die Größe in Bytes an oder ist mit einem Suffix ‘M’ für
     Megabyte und so weiter versehen. Die Vorgabe ist ‘10M’.

     Durch diese „Zwischenspeicherumgehung“ lässt sich die Verzögerung
     bis zur Veröffentlichung an Clients reduzieren, auf Kosten
     zusätzlicher Ein-/Ausgaben und CPU-Auslastung für den Server. Je
     nachdem, welche Zugriffsmuster Clients haben, werden diese
     Store-Objekte vielleicht mehrfach zur Einlagerung vorbereitet, ehe
     eine Kopie davon im Zwischenspeicher verfügbar wird.

     Wenn ein Anbieter nur wenige Nutzer unterhält, kann es helfen, den
     Schwellwert zu erhöhen, oder auch wenn garantiert werden soll, dass
     es auch für wenig beliebte Store-Objekte Substitute gibt.

‘--nar-path=PFAD’
     Den PFAD als Präfix für die URLs von „nar“-Dateien benutzen (siehe
     *note Normalisierte Archive: Aufruf von guix archive.).

     Vorgegeben ist, dass Nars unter einer URL mit
     ‘/nar/gzip/…-coreutils-8.25’ angeboten werden. Mit dieser
     Befehlszeilenoption können Sie den ‘/nar’-Teil durch den
     angegebenen PFAD ersetzen.

‘--public-key=DATEI’
‘--private-key=DATEI’
     Die angegebenen DATEIen als das Paar aus öffentlichem und privatem
     Schlüssel zum Signieren veröffentlichter Store-Objekte benutzen.

     Die Dateien müssen demselben Schlüsselpaar entsprechen (der private
     Schlüssel wird zum Signieren benutzt, der öffentliche Schlüssel
     wird lediglich in den Metadaten der Signatur aufgeführt). Die
     Dateien müssen Schlüssel im kanonischen („canonical“)
     S-Ausdruck-Format enthalten, wie es von ‘guix archive
     --generate-key’ erzeugt wird (siehe *note Aufruf von guix
     archive::). Vorgegeben ist, dass ‘/etc/guix/signing-key.pub’ und
     ‘/etc/guix/signing-key.sec’ benutzt werden.

‘--repl[=PORT]’
‘-r [PORT]’
     Einen Guile-REPL-Server (siehe *note (guile)REPL Servers::) auf
     diesem PORT starten (37146 ist voreingestellt). Dies kann zur
     Fehlersuche auf einem laufenden „‘guix publish’“-Server benutzt
     werden.

   ‘guix publish’ auf einem „Guix System“-System zu aktivieren ist ein
Einzeiler: Instanziieren Sie einfach einen
‘guix-publish-service-type’-Dienst im ‘services’-Feld Ihres
‘operating-system’-Objekts zur Betriebssystemdeklaration (siehe *note
‘guix-publish-service-type’: guix-publish-service-type.).

   Falls Sie Guix aber auf einer „Fremddistribution“ laufen lassen,
folgen Sie folgenden Anweisungen:

   • Wenn Ihre Wirtsdistribution systemd als „init“-System benutzt:

          # ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service \
                  /etc/systemd/system/
          # systemctl start guix-publish && systemctl enable guix-publish

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

          # ln -s ~root/.guix-profile/lib/upstart/system/guix-publish.conf /etc/init/
          # start guix-publish

   • Verfahren Sie andernfalls auf die gleiche Art für das
     „init“-System, das Ihre Distribution verwendet.

