Nächste: Aufruf von guix lint, Vorige: Aufruf von guix import, Nach oben: Zubehör [Inhalt][Index]
guix refresh
aufrufenDie 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.
Nächste: Aufruf von guix lint, Vorige: Aufruf von guix import, Nach oben: Zubehör [Inhalt][Index]