Suivant: Invoquer guix style
, Précédent: Invoquer guix import
, Monter: Utilitaires [Table des matières][Index]
guix refresh
La commande guix refresh
s’adresse avant tout aux personnes qui
écrivent des paquets. En tant qu’utilisateur·rice, vous pourriez être
intéressé·e par l’option --with-latest qui peut vous conférer les
superpouvoirs de mettre à jour les paquets, et qui est construite à partir
de guix refresh
(voir --with-latest). Par défaut, guix refresh
rapporte les
paquets fournis par la distribution qui sont en retard par rapport aux
dernières versions disponibles en amont, comme ceci :
$ guix refresh gnu/packages/gettext.scm :29 :13 : gettext serait mis à jour de 0.18.1.1 à 0.18.2.1 gnu/packages/glib.scm :77:12 : glib serait mis à jour de 2.34.3 à 2.37.0
On peut aussi spécifier des paquets à prendre en compte, auquel cas un avertissement est émis pour les paquets qui ne sont pas mis à jour :
$ guix refresh coreutils guile guile-ssh gnu/packages/ssh.scm:205:2 : avertissement : aucun gestionnaire de mise à jour pour guile-ssh gnu/packages/guile.scm:136:12 : guile serait mis à jour de 2.0.12 à 2.0.13
guix refresh
navigue le dépôt amont de chaque paquet et détermine
le numéro de version le plus élevé parmi les versions publiées. La commande
sait comment mettre à jour certains types de paquets : les paquets GNU, les
paquets ELPA, etc. — voir la documentation pour --type ci-dessous.
Il y a beaucoup de paquet cependant pour lesquels il manque une méthode pour
déterminer si une nouvelle version est disponible en amont. Cependant, le
mécanisme est extensible, alors n’hésitez pas à nous contacter pour ajouter
une nouvelle méthode !
--recursive
Considère les paquets spécifiés et tous les paquets dont ils dépendent.
$ 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 …
Parfois les noms en amont diffèrent du nom de paquet utilisé par Guix et
guix refresh
a besoin d’un peu d’aide. La plupart des
gestionnaires de mise à jour prennent en compte la propriété
upstream-name
dans les définitions de paquets, ce qui peut être
utilisé à cette fin :
(define-public network-manager
(package
(name "network-manager")
;; …
(properties '((upstream-name . "NetworkManager")))))
Quand l’option --update est utilisée, elle modifie les fichiers
sources de la distribution pour mettre à jour les numéros de version et les
hash de l’archive source de ces recettes de paquets (voir Définition des paquets). Pour ce faire, il télécharge la dernière archive source de
chaque paquet et sa signature OpenPGP associée, authentifiant l’archive
téléchargée par rapport à sa signature en utilisant gpgv
, et enfin
calcule son hash—notez que GnuPG doit être installé et dans $PATH
;
lancez guix install gnupg
si nécessaire.
Quand la clé publique utilisée pour signer l’archive est manquante depuis le
trousseau de clés utilisateur·rice, une tentative est faite de la récupérer
automatiquement depuis un serveur de clé publique ; en cas de succès, la clé
est ajoutée au trousseau de l’utilisateur·rice ; sinon, guix
refresh
renvoie une erreur.
Les options suivantes sont supportées :
--expression=expr
-e expr
Considérer le paquet évalué par expr.
C’est utile pour précisément se référer à un paquet, comme dans cet exemple :
guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'
Cette commande liste les dépendances de la libc « finale » (presque tous les paquets).
--update
-u
Met à jour les fichiers source de la distribution (les recettes de paquets) en place. Cette option est généralement utilisée depuis une copie du dépôt git de Guix (voir Lancer Guix avant qu’il ne soit installé) :
$ ./pre-inst-env guix refresh -s non-core -u
Voir Définition des paquets, pour plus d’information sur les définitions des paquets.
--select=[subset]
-s subset
Choisi tous les paquets dans subset, entre core
et
non-core
.
Le sous-ensemble core
se réfère à tous les paquets du cœur de la
distribution — c.-à-d. les paquets qui sont utilisés pour construire «
tout le reste ». Cela comprend GCC, libc, Binutils, Bash, etc.
Habituellement, changer l’un de ces paquets dans la distribution implique de
reconstruire tous les autres. Ainsi, ces mises à jour sont une nuisance
pour les utilisateurs, en terme de temps de compilation et de bande passante
utilisés pour effectuer la mise à jour.
Le sous-ensemble non-core
se réfère au reste des paquets. C’est
habituellement utile dans les cas où une mise à jour des paquets du cœur
serait dérangeante.
--manifest=fichier
-m fichier
Choisi tous les paquets du manifeste dans file. C’est utile pour vérifier qu’aucun des paquets du manifeste utilisateur ne peut être mis à jour.
--type=updater
-t updater
Chois uniquement les paquets pris en charge par updater (éventuellement une liste de gestionnaires de mise à jour séparés par des virgules). Actuellement, updater peut être l’une des valeurs suivantes :
gnu
le gestionnaire de mise à jour pour les paquets GNU ;
savannah
le gestionnaire de mise à jour pour les paquets hébergés sur Savannah ;
sourceforge
le gestionnaire de mise à jour pour les paquets hébergés sur SourceForge ;
gnome
le gestionnaire de mise à jour pour les paquets GNOME ;
kde
le gestionnaire de mise à jour pour les paquets KDE ;
xorg
le gestionnaire de mise à jour pour les paquets X.org ;
kernel.org
le gestionnaire de mise à jour pour les paquets hébergés sur kernel.org ;
egg
le gestionnaire de mise à jour pour les paquets Egg ;
elpa
le gestionnaire de mise à jour pour les paquets ELPA ;
cran
le gestionnaire de mise à jour pour les paquets CRAN ;
bioconductor
le gestionnaire de mise à jour pour les paquets Bioconductor ;
cpan
le gestionnaire de mise à jour pour les paquets CPAN ;
pypi
le gestionnaire de mise à jour pour les paquets PyPI.
gem
le gestionnaire de mise à jour pour les paquets RubyGems.
github
le gestionnaire de mise à jour pour les paquets GitHub.
hackage
le gestionnaire de mise à jour pour les paquets Hackage.
stackage
le gestionnaire de mise à jour pour les paquets Stackage.
crate
le gestionnaire de mise à jour pour les paquets Crates.
launchpad
le gestionnaire de mise à jour pour les paquets Launchpad.
generic-html
un gestionnaire de mise à jour qui visite la page HTML où l’archive des sources est hébergée, lorsque c’est possible.
generic-git
un gestionnarie de mise à jour générique pour les paquets hébergés sur des dépôts Git. Il essaye d’analyser les noms de tag Git de manière astucieuse, mais s’il ne parvient pas à analyser le nom d’un tag et à comparer les tags correctement, il est possible de définir les propriétés suivantes pour un paquet.
release-tag-prefix
: une expression régulière pour repérer le préfixe dans
le nom d’un tag.
release-tag-suffix
: une expression régulière pour repérer le suffixe dans
le nom d’un tag.
release-tag-version-delimiter
: une chaîne de caractères utilisée comme délimitation dans
le nom d’un tag pour séparer les numéros de version.
accept-pre-releases
: par défaut, le gestionnaire de mise à jour ignorera
les pré-versions ; pour lui faire chercher aussi les pré-versions, assignez
à cette propriété la valeur #t
.
(package
(name "toto")
;; ...
(properties
'((release-tag-prefix . "^release0-")
(release-tag-suffix . "[a-z]?$")
(release-tag-version-delimiter . ":"))))
Par exemple, la commande suivante ne vérifie que les mises à jour des
paquets Emacs hébergés sur elpa.gnu.org
et les paquets CRAN :
$ guix refresh --type=elpa,cran gnu/packages/statistics.scm:819:13 : r-testthat serait mis à jour de 0.10.0 à 0.11.0 gnu/packages/emacs.scm:856:13 : emacs-auctex serait mis à jour de 11.88.6 à 11.88.9
--list-updaters
Liste les gestionnaires de mises à jour disponibles et quitte (voir --type ci-dessus).
Pour chaque gestionnaire, affiche le pourcentage de paquets qu’il couvre ; à la fin, affiche le pourcentage de paquets couverts par tous les gestionnaires.
En plus, on peut passer à guix refresh
un ou plusieurs noms de
paquets, comme dans cet exemple :
$ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8
La commande ci-dessus met à jour spécifiquement les paquets emacs
et
idutils
. L’option --select n’aurait aucun effet dans ce
cas. Vous voudrez aussi sans doute mettre à jour les définitions qui
correspondent aux paquets installés dans votre profil :
$ ./pre-inst-env guix refresh -u \ $(guix package --list-installed | cut -f1)
Pour déterminer s’il faut mettre à jour un paquet, il est parfois pratique
de savoir quels paquets seraient affectés par la mise à jour pour pouvoir
vérifier la compatibilité. Pour cela l’option suivante peut être utilisée
avec un ou plusieurs noms de paquets passés à guix refresh
:
--list-dependent
-l
Liste les paquets de plus haut-niveau qui devraient être reconstruits après la mise à jour d’un ou plusieurs paquets.
Voir le type reverse-package
de guix
graph
, pour des informations sur la manière de visualiser la liste des
paquets dépendant d’un autre.
Sachez que l’option --list-dependent n’a qu’une approche approximative sur les reconstructions qui seraient nécessaires à la suite d’une mise à jour. D’autres reconstructions peuvent être nécessaires dans certaines circonstances.
$ guix refresh --list-dependent flex Construire les 120 paquets suivants s'assure que les 213 paquets dépendants sont reconstruits : hop@2.4.0 emacs-geiser@0.13 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 …
La commande ci-dessus liste un ensemble de paquets qui peuvent être
construits pour vérifier la compatibilité d’une mise à jour de flex
.
--list-transitive
Lister tous les paquets dont un paquet ou plus dépendent.
$ 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 …
La commande ci-dessus liste un ensemble de paquets qui, lorsqu’ils sont
modifiés, causent la reconstruction de flex
.
Les options suivante peuvent être utilisées pour personnaliser les opérations avec GnuPG :
--gpg=commande
Utilise commande comme la commande de GnuPG 2.x. commande est
recherchée dans PATH
.
--keyring=fichier
Utilise fichier comme porte-clefs pour les clefs amont. fichier
doit être dans le format keybox. Les fichiers Keybox ont d’habitude
un nom qui fini par .kbx et GNU Privacy Guard (GPG) peut
manipuler ces fichiers (voir kbxutil
dans Using the
Privacy Guard, pour plus d’informations sur un outil pour manipuler des
fichiers keybox).
Lorsque cette option est omise, guix refresh
utilise
~/.config/guix/upstream/trustedkeys.kbx comme trousseau pour les clés
de signature en amont. Les signatures OpenPGP sont vérifiées avec ces clés
; les clés manquantes sont aussi téléchargées dans ce trousseau (voir
--key-download plus bas).
Vous pouvez exporter les clefs de votre porte-clefs GPG par défaut dans un fichier keybox avec une commande telle que :
gpg --export rms@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx
De même, vous pouvez récupérer des clefs dans un fichier keybox spécifique comme ceci :
gpg --no-default-keyring --keyring mykeyring.kbx \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
Voir --keyring dans Using the GNU Privacy Guard pour plus d’informations sur l’option --keyring de GPG.
--key-download=politique
Gère les clefs OpenPGP manquantes d’après la politique, qui peut être l’une des suivantes :
always
Toujours télécharger les clefs manquantes depuis un serveur de clefs et les ajouter au porte-clefs de l’utilisateur.
never
Ne jamais essayer de télécharger les clefs OpenPGP manquante. Quitter à la place.
interactive
Lorsqu’on rencontre un paquet signé par une clef OpenPGP inconnue, demander à l’utilisateur s’il souhaite la télécharger ou non. C’est le comportement par défaut.
--key-server=host
Utiliser host comme serveur de clefs OpenPGP lors de l’importe d’une clef publique.
--load-path=répertoire
-L répertoire
Ajoute répertoire au début du chemin de recherche de module de paquets (voir Modules de paquets).
Cela permet à des utilisateurs de définir leur propres paquets et les rendre disponibles aux outils en ligne de commande.
Le gestionnaire de mises à jour github
utilise
GitHub API pour faire des requêtes
sur les nouvelles versions. Lorsqu’elle est utilisé de manière répétée, par
exemple lorsque vous vérifiez tous les paquets, GitHub finira par refuser de
répondre à d’autres requêtes de l’API. Par défaut 60 requêtes à l’heure
sont autorisées, et une vérification complète de tous les paquets GitHub
dans Guix demande bien plus que cela. L’authentification avec GitHub à
travers l’utilisation d’un jeton d’API lève ces limites. Pour utiliser un
jeton de l’API, initialisez la variable d’environnement
GUIX_GITHUB_TOKEN
avec un jeton que vous vous serez procuré sur
https://github.com/settings/tokens ou autrement.
Suivant: Invoquer guix style
, Précédent: Invoquer guix import
, Monter: Utilitaires [Table des matières][Index]