---

8.2.1 package-Referenz

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

Datentyp: package

Dieser Datentyp steht für ein Paketrezept.

name

Der Name des Pakets als Zeichenkette.

version

Die Version des Pakets als Zeichenkette. Siehe Versionsnummern, wo erklärt wird, worauf Sie achten müssen.

source

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

build-system

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

arguments (Vorgabe: '())

Die Argumente, die an das Erstellungssystem übergeben werden sollen (siehe Erstellungssysteme). Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren wie in diesem Beispiel:

(package
  (name "beispiel")
  ;; hier würden noch ein paar Felder stehen
  (arguments
    (list #:tests? #f                     ;Tests überspringen
          #:make-flags #~'("VERBOSE=1")   ;Optionen für 'make'
          #:configure-flags #~'("--enable-frobbing"))))

Welche Schlüsselwortargumente genau unterstützt werden, hängt vom jeweiligen Erstellungssystem ab (siehe Erstellungssysteme), doch werden Sie feststellen, dass fast alle #:configure-flags, #:make-flags, #:tests? und #:phases berücksichtigen. Insbesondere können Sie mit dem Schlüsselwort #:phases den Satz von Erstellungsphasen, der für Ihr Paket zum Einsatz kommt, ändern (siehe Erstellungsphasen).

Auf der REPL können Sie sich mit speziellen Befehlen interaktiv anzeigen lassen, welchen Wert einige dieser Argumente haben, um Ihnen bei der Fehlersuche zu helfen (siehe Interaktiv mit Guix arbeiten).

Anmerkung zur Kompatibilität: Bis Version 1.3.0 hat man im arguments-Feld üblicherweise quote (') oder quasiquote (`) geschrieben, statt G-Ausdrücke zu verwenden, etwa so:

(package
  ;; hier würden noch ein paar Felder stehen
  (arguments   ;quotierte Argumente, die im alten Stil benutzt wurden
   '(#:tests? #f
     #:configure-flags '("--enable-frobbing"))))

Um ein Paket vom diesem Stil in den darüber umzuwandeln, können Sie guix style -S arguments Paket ausführen (siehe guix style aufrufen).

inputs (Vorgabe: '()) ¶

native-inputs (Vorgabe: '())

propagated-inputs (Vorgabe: '())

In diesen Feldern wird eine Liste der Abhängigkeiten des Pakets aufgeführt. Dabei ist jedes Listenelement ein „package“-, „origin“- oder sonstiges dateiartiges Objekt (siehe G-Ausdrücke). Um die zu benutzende Ausgabe zu benennen, übergeben Sie eine zweielementige Liste mit der Ausgabe als zweitem Element (siehe Pakete mit mehreren Ausgaben. für mehr Informationen zu Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt:

(list libffi libunistring
      `(,glib "bin"))      ;Ausgabe "bin" von GLib

Im obigen Beispiel wird die Ausgabe "out" für libffi und libunistring benutzt.

Anmerkung zur Kompatibilität: Bis Version 1.3.0 waren Eingabelisten noch Listen von Tupeln, wobei jedes Tupel eine Bezeichnung für die Eingabe (als Zeichenkette) als erstes Element, dann ein „package“-, „origin“- oder „derivation“-Objekt (Paket, Ursprung oder Ableitung) als zweites Element und optional die Benennung der davon zu benutzenden Ausgabe umfasste; letztere hatte als Vorgabewert "out". Im folgenden Beispiel wird dasselbe wie oben angegeben, aber im alten Stil für Eingaben:

;; Alter Eingabenstil (veraltet).
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;Ausgabe "bin" von GLib

Dieser Stil gilt als veraltet. Er wird bislang unterstützt, aber er wird in einer zukünftigen Version entfernt werden. Man sollte ihn nicht für neue Paketdefinitionen gebrauchen. Siehe guix style aufrufen für eine Erklärung, wie Sie zum neuen Stil migrieren.

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

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

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

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

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

outputs (Vorgabe: '("out"))

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

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

search-paths (Vorgabe: '())

Eine Liste von search-path-specification-Objekten, die Umgebungsvariable für von diesem Paket beachtete Suchpfade („search paths“) beschreiben. Siehe Suchpfade, wenn Sie mehr über Suchpfadspezifikationen erfahren möchten.

Wie auch bei Eingaben wird zwischen native-search-paths und search-paths nur dann ein Unterschied gemacht, wenn Sie cross-kompilieren. Beim Cross-Kompilieren bezieht sich native-search-paths ausschließlich auf native Eingaben, wohingegen sich die search-paths ausschließlich auf Eingaben für den „Host“ genannten Rechner beziehen.

Für Pakete wie z.B. Cross-Compiler sind die Ziel-Eingaben wichtig, z.B. hat unser (angepasster) GCC-Cross-Compiler einen Eintrag für CROSS_C_INCLUDE_PATH in search-paths, damit er .h-Dateien für das Zielsystem auswählt und nicht die aus nativen Eingaben. Für die meisten Pakete ist aber einzig native-search-paths von Bedeutung.

replacement (Vorgabe: #f)

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

synopsis

Eine einzeilige Beschreibung des Pakets.

description

Eine ausführlichere Beschreibung des Pakets, als eine Zeichenkette in Texinfo-Syntax.

license ¶

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

home-page

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

supported-systems (Vorgabe: %supported-systems)

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

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

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

Makro: 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)
                     (list this-package)
                     '())))

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

Die folgenden Hilfsprozeduren sind für den Umgang mit Paketeingaben gedacht.

Prozedur: lookup-package-input Paket Name

Prozedur: lookup-package-native-input Paket Name

Prozedur: lookup-package-propagated-input Paket Name

Prozedur: lookup-package-direct-input Paket Name

Name unter den (nativen, propagierten, direkten) Eingaben von Paket suchen und die Eingabe zurückliefern, wenn sie gefunden wird, ansonsten #f.

name is the name of a package or the file name of an origin depended on. Here’s how you might use it:

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

(lookup-package-direct-input coreutils "gmp")
⇒ #<package gmp@6.2.1 …>

In diesem Beispiel erhalten wir das gmp-Paket, das zu den direkten Eingaben von coreutils gehört.

When looking up an origin, use the name that appears in the origin’s file-name field or its default file name—e.g., "foo-1.2.tar.gz".

Manchmal werden Sie die Liste der zur Entwicklung an einem Paket nötigen Eingaben brauchen, d.h. alle Eingaben, die beim Kompilieren des Pakets sichtbar gemacht werden. Diese Liste wird von der Prozedur package-development-inputs geliefert.

Prozedur: package-development-inputs Paket [System] [#:target #f]

Liefert die Liste derjenigen Eingaben, die das Paket zu Entwicklungszwecken für System braucht. Wenn target wahr ist, muss dafür ein Ziel wie das GNU-Tripel "aarch64-linux-gnu" übergeben werden, damit die Eingaben zum Cross-Kompilieren von Paket zurückgeliefert werden.

Beachten Sie, dass dazu sowohl explizite als auch implizite Eingaben gehören. Mit impliziten Eingaben meinen wir solche, die vom Erstellungssystem automatisch hinzugefügt werden (siehe Erstellungssysteme). Nehmen wir das Paket hello zur Illustration:

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

hello
⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

(package-direct-inputs hello)
⇒ ()

(package-development-inputs hello)
⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)

Für dieses Beispiel liefert package-direct-inputs die leere Liste zurück, weil hello keinerlei explizite Abhängigkeiten hat. Zu package-development-inputs gehören auch durch gnu-build-system implizit hinzugefügte Eingaben, die für die Erstellung von hello gebraucht werden, nämlich tar, gzip, GCC, libc, Bash und weitere. Wenn Sie sich das anschauen wollen, zeigt Ihnen guix graph hello die expliziten Eingaben, dagegen zeigt guix graph -t bag hello auch die impliziten Eingaben (siehe guix graph aufrufen).

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

Prozedur: package-with-c-toolchain Paket Toolchain

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

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

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

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