Aufruf von guix refresh (Referenzhandbuch zu GNU Guix)

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 --with-latest). Nach Vorgabe werden mit guix refresh alle Pakete in der Distribution gemeldet, die nicht der neuesten Version des Anbieters entsprechen, indem Sie dies ausführen:

$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

Alternativ können die zu betrachtenden Pakete dabei angegeben werden, was zur Ausgabe einer Warnung führt, wenn es für Pakete kein Aktualisierungsprogramm gibt:

$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

guix refresh durchsucht die Paketsammlung beim Anbieter jedes Pakets und bestimmt, was die höchste Versionsnummer ist, zu der es dort eine Veröffentlichung gibt. Zum Befehl gehören Aktualisierungsprogramme, mit denen bestimmte Typen von Paketen automatisch aktualisiert werden können: GNU-Pakete, ELPA-Pakete usw. – siehe die Dokumentation von --type unten. Es gibt jedoch auch viele Pakete, für die noch keine Methode enthalten ist, um das Vorhandensein einer neuen Veröffentlichung zu prüfen. Der Mechanismus ist aber erweiterbar, also können Sie gerne mit uns in Kontakt treten, wenn Sie eine neue Methode hinzufügen möchten!

--recursive

Hiermit werden die angegebenen Pakete betrachtet und außerdem alle Pakete, von denen sie abhängen.

$ guix refresh --recursive coreutils
gnu/packages/acl.scm:40:13: acl würde von 2.2.53 auf 2.3.1 aktualisiert
gnu/packages/m4.scm:30:12: 1.4.18 ist bereits die neuste Version von m4
gnu/packages/xml.scm:68:2: Warnung: Kein Aktualisierungsprogramm für expat
gnu/packages/multiprecision.scm:40:12: 6.1.2 ist bereits die neuste Version von gmp
…

Wenn Sie aus irgendeinem Grund auf eine ältere Version aktualisieren möchten, geht das auch, indem Sie nach der Paketspezifikation ein Gleichheitszeichen und die gewünschte Versionsnummer schreiben. Allerdings können nicht alle Aktualisierungsprogramme damit umgehen; wenn es das Aktualisieren auf die bestimmte Version nicht unterstützt, meldet das Aktualisierungsprogramm einen Fehler.

$ guix refresh trytond-party
gnu/packages/guile.scm:392:2: guile würde von 3.0.3 auf 3.0.5 aktualisiert
$ guix refresh -u guile=3.0.4
…
gnu/packages/guile.scm:392:2: guile: Aktualisiere von Version 3.0.3 auf Version 3.0.4 …
…
$ guix refresh -u guile@2.0=2.0.12
…
gnu/packages/guile.scm:147:2: guile: Aktualisiere von Version 2.0.10 auf Version 2.0.12 …
…

In bestimmten Fällen möchte man viele Pakete, die man über ein Manifest oder eine Modulauswahl angibt, alle zusammen aktualisieren. Für so etwas gibt es die Befehlszeilenoption --target-version, mit der alle auf die gleiche Version gebracht werden können, wie in diesen Beispielen hier:

$ guix refresh qtbase qtdeclarative --target-version=6.5.2
gnu/packages/qt.scm:1248:13: qtdeclarative würde von 6.3.2 auf 6.5.2 aktualisiert
gnu/packages/qt.scm:584:2: qtbase würde von 6.3.2 auf 6.5.2 aktualisiert

$ guix refresh --manifest=qt5-manifest.scm --target-version=5.15.10
gnu/packages/qt.scm:1173:13: qtxmlpatterns würde von 5.15.8 auf 5.15.10 aktualisiert
gnu/packages/qt.scm:1202:13: qtdeclarative würde von 5.15.8 auf 5.15.10 aktualisiert
gnu/packages/qt.scm:1762:13: qtserialbus würde von 5.15.8 auf 5.15.10 aktualisiert
gnu/packages/qt.scm:2070:13: qtquickcontrols2 würde von 5.15.8 auf 5.15.10 aktualisiert
…

Manchmal unterscheidet sich der vom Anbieter benutzte Name von dem Paketnamen, der in Guix verwendet wird, so dass guix refresh etwas Unterstützung braucht. Die meisten Aktualisierungsprogramme folgen der Eigenschaft upstream-name in Paketdefinitionen, die diese Unterstützung bieten kann.

(define-public network-manager
  (package
    (name "network-manager")
    ;; …
    (properties '((upstream-name . "NetworkManager")))))

Wenn --update übergeben wird, werden die Quelldateien der Distribution verändert, so dass für diese Paketdefinitionen und, wenn möglich, für deren Eingaben die aktuelle Version und die aktuelle Hash-Prüfsumme des Quellcodes eingetragen wird (siehe Pakete definieren). Dazu werden der neueste Quellcode-Tarball jedes Pakets sowie die jeweils zugehörige OpenPGP-Signatur heruntergeladen; mit Letzterer wird der heruntergeladene Tarball gegen seine Signatur mit gpgv authentifiziert und schließlich dessen Hash berechnet. Beachten Sie, dass GnuPG dazu installiert sein und in $PATH vorkommen muss. Falls dies nicht der Fall ist, führen Sie guix install gnupg aus.

Wenn der öffentliche Schlüssel, mit dem der Tarball signiert wurde, im Schlüsselbund des Benutzers fehlt, wird versucht, ihn automatisch von einem Schlüssel-Server zu holen. Wenn das klappt, wird der Schlüssel zum Schlüsselbund des Benutzers hinzugefügt, ansonsten meldet guix refresh einen Fehler.

Die folgenden Befehlszeilenoptionen werden unterstützt:

--expression=Ausdruck

-e Ausdruck

Als Paket benutzen, wozu der Ausdruck ausgewertet wird.

Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in diesem Beispiel:

guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

Dieser Befehls listet auf, was alles von der „endgültigen“ Erstellung von libc abhängt (praktisch alle Pakete).

--update

-u

Die Quelldateien der Distribution (die Paketdefinitionen) werden direkt „in place“ verändert. Normalerweise führen Sie dies aus einem Checkout des Guix-Quellbaums heraus aus (siehe Guix vor der Installation ausführen):

./pre-inst-env guix refresh -s non-core -u

Siehe Pakete definieren für mehr Informationen zu Paketdefinitionen. Sie können es auch auf Paketen eines Drittanbieterkanals ausführen.

guix refresh -L /pfad/zum/kanal -u Paket

Siehe Einen Kanal erstellen für Informationen, wie Sie einen Kanal anlegen.

Mit diesem Befehl bringen Sie die Version und die Hash-Prüfsumme des Quellcodes in dem Paket auf den neuesten Stand. Je nachdem, welches Aktualisierungsprogramm dafür eingesetzt wird, kann es sogar die Eingaben im Feld ‘inputs’ des Pakets aktualisieren. Es kommt vor, dass sich dabei Fehler in die Eingaben einschleichen – vielleicht fehlt eine zusätzliche notwendige Eingabe oder es wird eine hinzugefügt, die nicht erwünscht ist.

Um damit leichter umzugehen, können Paketautoren die Eingaben, die außer den vom Aktualisierungsprogramm gefundenen Eingaben in Guix noch zusätzlich nötig sind, oder solche, die ignoriert werden sollen, in den Eigenschaften des Pakets hinterlegen: Es gibt die Eigenschaften updater-extra-inputs und updater-ignored-inputs, wenn es um „normale“ Abhängigkeiten geht, und entsprechende Eigenschaften für native-inputs und propagated-inputs. Folgendes Beispiel zeigt, wie das Aktualisierungsprogramm auf ‘openmpi’ als eine zusätzliche Eingabe hingewiesen wird:

(define-public python-mpi4py
  (package
    (name "python-mpi4py")
    ;; …
    (inputs (list openmpi))
    (properties
     '((updater-extra-inputs . ("openmpi"))))))

So wird bei guix refresh -u python-mpi4py die Eingabe ‘openmpi’ nicht mehr entfernt, obwohl es keine der Eingaben ist, die von sich aus hinzugefügt würden.

--select=[Teilmenge]

-s Teilmenge

Wählt alle Pakete aus der Teilmenge aus, die entweder core, non-core oder module:Name sein muss.

Die core-Teilmenge bezieht sich auf alle Pakete, die den Kern der Distribution ausmachen, d.h. Pakete, aus denen heraus „alles andere“ erstellt wird. Dazu gehören GCC, libc, Binutils, Bash und so weiter. In der Regel ist die Folge einer Änderung an einem dieser Pakete in der Distribution, dass alle anderen neu erstellt werden müssen. Daher sind solche Änderungen unangenehm für Nutzer, weil sie einiges an Erstellungszeit oder Bandbreite investieren müssen, um die Aktualisierung abzuschließen.

Die non-core-Teilmenge bezieht sich auf die übrigen Pakete. Sie wird typischerweise dann benutzt, wenn eine Aktualisierung der Kernpakete zu viele Umstände machen würde.

Wenn als Teilmenge module:Name angegeben wird, werden alle Pakete in dem angegebenen Guile-Modul ausgewählt. Das Modul kann als z.B. module:guile oder module:(gnu packages guile) angegeben werden, erstere ist die Kurzform für die andere.

--manifest=Datei

-m Datei

Wählt alle Pakete im in der Datei stehenden Manifest aus. Das ist nützlich, um zu überprüfen, welche Pakete aus dem Manifest des Nutzers aktualisiert werden können.

--type=Aktualisierungsprogramm

-t Aktualisierungsprogramm

Nur solche Pakete auswählen, die vom angegebenen Aktualisierungsprogramm behandelt werden. Es darf auch eine kommagetrennte Liste mehrerer Aktualisierungsprogramme angegeben werden. Zurzeit kann als Aktualisierungsprogramm eines der folgenden angegeben werden:

gnu

Aktualisierungsprogramm für GNU-Pakete,

savannah

Aktualisierungsprogramm auf Savannah angebotener Pakete,

sourceforge

Aktualisierungsprogramm auf SourceForge angebotener Pakete,

gnome

Aktualisierungsprogramm für GNOME-Pakete,

kde

Aktualisierungsprogramm für KDE-Pakete,

xorg

Aktualisierungsprogramm für X.org-Pakete,

kernel.org

Aktualisierungsprogramm auf kernel.org angebotener Pakete,

egg

Aktualisierungsprogramm für Egg-Pakete,

elpa

Aktualisierungsprogramm für ELPA-Pakete,

cran

Aktualisierungsprogramm für CRAN-Pakete,

bioconductor

Aktualisierungsprogramm für R-Pakete vom Bioconductor,

cpan

Aktualisierungsprogramm für CPAN-Pakete,

pypi

Aktualisierungsprogramm für PyPI-Pakete,

gem

Aktualisierungsprogramm für RubyGems-Pakete.

github

Aktualisierungsprogramm für GitHub-Pakete.

hackage

Aktualisierungsprogramm für Hackage-Pakete.

stackage

Aktualisierungsprogramm für Stackage-Pakete.

crate

Aktualisierungsprogramm für Crates-Pakete.

launchpad

Aktualisierungsprogramm für Launchpad.

generic-html

allgemeines Aktualisierungsprogramm, das mit einem Webcrawler die HTML-Seite, auf der der Quell-Tarball des Pakets angeboten wird, falls vorhanden, durchsucht. Wenn das Paket über die Eigenschaft release-monitoring-url verfügt, wird stattdessen diese URL durchsucht.

generic-git

allgemeines Aktualisierungsprogramm, das auf in Git-Repositorys angebotene Pakete anwendbar ist. Es wird versucht, Versionen anhand der Namen von Git-Tags zu erkennen, aber wenn Tag-Namen nicht korrekt zerteilt und verglichen werden, können Anwender die folgenden Eigenschaften im Paket festlegen.

release-tag-prefix: einen regulären Ausdruck, der zum Präfix des Tag-Namens passt.
release-tag-suffix: einen regulären Ausdruck, der zum Suffix des Tag-Namens passt.
release-tag-version-delimiter: eine Zeichenkette, die im Tag-Namen die Zahlen trennt, aus denen sich die Version zusammensetzt.
accept-pre-releases: ob Vorabveröffentlichungen berücksichtigt werden sollen. Vorgegeben ist, sie zu ignorieren. Setzen Sie dies auf #t, um sie hinzuzunehmen.

(package
  (name "foo")
  ;; …
  (properties
    '((release-tag-prefix . "^release0-")
      (release-tag-suffix . "[a-z]?$")
      (release-tag-version-delimiter . ":"))))

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

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 den reverse-package-Typ von guix graph für Informationen dazu, wie Sie die Liste der Abhängigen eines Pakets visualisieren können.

Bedenken Sie, dass die Befehlszeilenoption --list-dependent das Ausmaß der nach einer Aktualisierungen benötigten Neuerstellungen nur annähert. Es könnten auch unter Umständen mehr Neuerstellungen anfallen.

$ guix refresh --list-dependent flex
Die folgenden 120 Pakete zu erstellen, würde zur Folge haben, dass 213 abhängige Pakete neu erstellt werden:
hop@2.4.0 emacs-geiser@0.13 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

-T

Die Pakete auflisten, von denen eines oder mehrere Pakete abhängen.

$ guix refresh --list-transitive flex
flex@2.6.4 hängt von den folgenden 25 Paketen ab: perl@5.28.0 help2man@1.47.6
bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 …

Der oben stehende Befehl gibt einen Satz von Paketen aus, die, wenn sie geändert würden, eine Neuerstellung des flex-Pakets auslösen würden.

Mit den folgenden Befehlszeilenoptionen können Sie das Verhalten von GnuPG anpassen:

--gpg=Befehl

Den Befehl als GnuPG-2.x-Befehl einsetzen. Der Befehl wird im $PATH gesucht.

--keyring=Datei

Die Datei als Schlüsselbund mit Anbieterschlüsseln verwenden. Die Datei muss im Keybox-Format vorliegen. Keybox-Dateien haben normalerweise einen Namen, der auf .kbx endet. Sie können mit Hilfe von GNU Privacy Guard (GPG) bearbeitet werden (siehe kbxutil in Using the GNU Privacy Guard für Informationen über ein Werkzeug zum Bearbeiten von Keybox-Dateien).

Wenn diese Befehlszeilenoption nicht angegeben wird, benutzt guix refresh die Keybox-Datei ~/.config/guix/upstream/trustedkeys.kbx als Schlüsselbund für Signierschlüssel von Anbietern. OpenPGP-Signaturen werden mit Schlüsseln aus diesem Schlüsselbund überprüft; fehlende Schlüssel werden auch in diesen Schlüsselbund heruntergeladen (siehe --key-download unten).

Sie können Schlüssel aus Ihrem normalerweise benutzten GPG-Schlüsselbund in eine Keybox-Datei exportieren, indem Sie Befehle wie diesen benutzen:

gpg --export rms@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx

Ebenso können Sie wie folgt Schlüssel in eine bestimmte Keybox-Datei herunterladen:

gpg --no-default-keyring --keyring mykeyring.kbx \
  --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

Siehe --keyring in Using the GNU Privacy Guard für mehr Informationen zur Befehlszeilenoption --keyring von GPG.

--key-download=Richtlinie

Fehlende OpenPGP-Schlüssel gemäß dieser Richtlinie behandeln, für die eine der Folgenden angegeben werden kann:

always: Immer fehlende OpenPGP-Schlüssel herunterladen und zum GnuPG-Schlüsselbund des Nutzers hinzufügen.
never: Niemals fehlende OpenPGP-Schlüssel herunterladen, sondern einfach abbrechen.
interactive: Ist ein Paket mit einem unbekannten OpenPGP-Schlüssel signiert, wird der Nutzer gefragt, ob der Schlüssel heruntergeladen werden soll oder nicht. Dies entspricht dem vorgegebenen Verhalten.

--key-server=Host

Den mit Host bezeichneten Rechner als Schlüsselserver für OpenPGP benutzen, wenn ein öffentlicher Schlüssel importiert wird.

--load-path=Verzeichnis

-L Verzeichnis

Das Verzeichnis vorne an den Suchpfad für Paketmodule anfügen (siehe Paketmodule).

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

Das github-Aktualisierungsprogramm benutzt die GitHub-Programmierschnittstelle (die „Github-API“), um Informationen über neue Veröffentlichungen einzuholen. Geschieht dies oft, z.B. beim Auffrischen aller Pakete, so wird GitHub irgendwann aufhören, weitere API-Anfragen zu beantworten. Normalerweise sind 60 API-Anfragen pro Stunde erlaubt, für eine vollständige Auffrischung aller GitHub-Pakete in Guix werden aber mehr benötigt. Wenn Sie sich bei GitHub mit Ihrem eigenen API-Token authentisieren, gelten weniger einschränkende Grenzwerte. Um einen API-Token zu benutzen, setzen Sie die Umgebungsvariable GUIX_GITHUB_TOKEN auf einen von https://github.com/settings/tokens oder anderweitig bezogenen API-Token.

9.6 guix refresh aufrufen

9.6 `guix refresh` aufrufen