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 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.
Siehe guix build --dependents
, for a convenient
way to build all the dependents of a package.
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.
Nächste: guix style
aufrufen, Vorige: guix import
aufrufen, Nach oben: Zubehör [Inhalt][Index]