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