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