Suivant: , Précédent: , Monter: Utilitaires   [Table des matières][Index]


7.6 Invoquer guix refresh

La commande guix refresh s’adresse avant tout aux personnes qui développent la distribution logicielle GNU. Par défaut, elle 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

Autrement, on peut spécifier les paquets à considérer, auquel cas un avertissement est émis pour les paquets qui n’ont pas de gestionnaire de mise à jour associé :

$ 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: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
…

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 honorent 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")))))

When passed --update, it modifies distribution source files to update the version numbers and source tarball hashes of those package recipes (voir Définition des paquets). This is achieved by downloading each package’s latest source tarball and its associated OpenPGP signature, authenticating the downloaded tarball against its signature using gpgv, and finally computing its hash—note that GnuPG must be installed and in $PATH; run guix install gnupg if needed.

When the public key used to sign the tarball is missing from the user’s keyring, an attempt is made to automatically retrieve it from a public key server; when this is successful, the key is added to the user’s keyring; otherwise, guix refresh reports an error.

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 paquets qui dépendent de la libc « finale » (en gros 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 ;

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 ;

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

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

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 au-dessus met à jour spécifiquement les paquets emacs et idutils. L’option --select n’aurait aucun effet dans ce cas.

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

Liste les gestionnaires de mise à jour et quitte (voir l’option --type plus haut).

Pour chaque gestionnaire, affiche le pourcentage de paquets qu’il couvre ; à la fin, affiche le pourcentage de paquets couverts par tous les gestionnaires.

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

Soyez conscients que l’option --list-dependent ne fait qu’approximer les reconstructions qui seraient requises par une mise à jour. Plus de reconstructions pourraient être requises dans certaines circonstances.

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

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 porte-clefs pour les clefs de signature amont. Les signatures OpenPGP sont vérifiées avec ces clefs ; les clefs manquantes sont aussi téléchargées dans ce porte-clefs (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

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

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 l’API de GitHub pour faire des requêtes sur les nouvelles versions. Lorsqu’elle est utilisé de manière répétée, p. ex. 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 requiert 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: , Précédent: , Monter: Utilitaires   [Table des matières][Index]