9.6 guix refresh aufrufen

Die Zielgruppe des Befehls guix refresh zum Auffrischen von Paketen sind in erster Linie Entwickler der GNU-Software-Distribution. Nach Vorgabe werden damit alle Pakete in der Distribution gemeldet, die nicht der neuesten Version des Anbieters entsprechen, indem Sie dies ausführen:

$ 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:35:2: warning: no updater for acl
gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4
gnu/packages/xml.scm:68:2: warning: no updater for expat
gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp
…

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 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 Guix vor der Installation ausführen):

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

Siehe 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

Select all the packages from the manifest in file. This is useful to check if any packages of the user manifest can be updated.

--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,

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,

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.

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

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.

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

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

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.