Options de transformation de paquets (Manuel de référence de GNU Guix)

10.1.2 Options de transformation de paquets

Un autre ensemble d’options de la ligne de commande supportés par guix build et aussi guix package sont les options de transformation de paquets. Ce sont des options qui rendent possible la définition de variantes de paquets — par exemple, des paquets construit à partir de sources différentes. C’est une manière simple de créer des paquets personnalisés à la volée sans avoir à taper les définitions de variantes de paquets (voir Définition des paquets).

Les options de transformation des paquets sont préservées dans les mises à jour : guix upgrade tente d’appliquer aux paquets mis à jour les options de transformation initialement utilisées lors de la création du profil.

Les options disponibles sont énumérées ci-dessous. La plupart des commandes les prennent en charge, ainsi qu’une option --help-transform qui liste toutes les options disponibles et un synopsis (ces options ne sont pas affichées dans la sortie --help par souci de concision).

--tune[=cpu]

Utilise les versions des paquets marqués comme « réglables » optimisées pour cpu. Lorsque cpu est native, ou s’il est omis, règle pour le CPU sur lequel la commande guix est lancée.

Les noms de cpu valides sont ceux reconnus par le compilateur sous-jacent, par défaut la collection de compilateurs de GNU (GCC). Sur les processurs x86_64, cela comprend les noms des CPU comme nehalem, haswell et skylake (voir -march dans Using the GNU Compiler Collection (GCC)).

Au fur et à mesure de la sortie de nouvelles générations de CPU, de nouvelles instructions sont ajoutées à l’ensemble d’instruction standard de l’architecture (ISA), en particulier des instructions pour le calcul parallèle instruction-unique/données-multiples (SIMD). Par exemple, alors que les CPU Core2 et Skylake implémentent tous deux l’ISA x86_64, seul ce dernier prend en charge les instructions SIMD AVX2.

Le principal bénéfice attendu de --tune est que les programmes peuvent utiliser ces fonctionnalités SIMD et qu’ils n’ont pas déjà un mécanisme pour choisir le bon code optimisé à l’exécution. Les paquets qui possèdent la propriété tunable? sont considérés comme des paquets réglables par l’option --tune ; une définition de paquet avec la bonne propriété ressemble à ceci :

(package
  (name "hello-simd")
  ;; ...

  ;; Ce paquet peut bénéficier des extensions SIMD donc
  ;; on le marque « réglable ».
  (properties '((tunable? . #t))))

Les autres paquets ne sont pas considérés comme réglables. Cela permet à Guix d’utiliser des binaires génériques dans le cas où le réglage pour un CPU particulier ne donnera probablement aucun avantage.

Les paquets réglés sont construits avec -march=CPU ; sous le capot, l’option -march est passée à l’enveloppe par une enveloppe du compilateur. Comme la machine de construction peut ne pas être capable de lancer du code pour la micro-architecture CPU cible, la suite de tests n’est pas lancée lors de la construction d’un paquet réglé.

Pour réduire les reconstructions au minimum, les paquets réglés sont greffés sur les paquets qui en dépendent (voir grafts). Ainsi, utiliser --no-grafts annule l’effet de --tune.

Nous appelons cette technique le multi-versionement des paquets : on peut construire plusieurs variantes d’un paquet réglable, une pour chaque variante de CPU. C’est la contrepartie à gros grain du multi-versionement fonctionnel implémenté par la chaine d’outils de GNU (voir Function Multiversioning dans Using the GNU Compiler Collection (GCC)).

--with-source=source

--with-source=paquet=source

--with-source=paquet@version=source

Utilise source comme la source de paquet, et version comme son numéro de version. source doit être un nom de fichier ou une URL, comme pour guix download (voir Invoquer guix download).

Lorsque paquet est omis, la commande utilisera le nom de paquet spécifié par la base de source — p. ex. si source est /src/guix-2.0.10.tar.gz, le paquet correspondant est guile.

De même, lorsque version est omis, la chaîne de version est inférée à partir de source ; dans l’exemple précédent, il s’agit de 2.0.10.

Cette option permet aux utilisateurs d’essayer des version des paquets différentes de celles fournies par la distribution. L’exemple ci-dessous télécharge ed-1.7.tar.g depuis un miroir GNU et l’utilise comme source pour le paquet ed :

guix build ed --with-source=mirror://gnu/ed/ed-1.4.tar.gz

En tant que développeur·euse, --with-source permet de tester facilement des version bêta, et même de vérifier leur impact sur les paquets qui en dépendent :

guix build elogind --with-source=…/shepherd-0.9.0rc1.tar.gz

… ou pour construire un dépôt de gestion de version dans un environnement vierge :

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix

--with-input=paquet=remplaçant

Remplace la dépendance sur paquet par une dépendance à remplaçant. paquet doit être un nom de paquet et remplaçant doit être une spécification de paquet comme guile ou guile@1.8.

Par exemple, la commande suivante construit Guix, mais remplace sa dépendance à la version stable actuelle de Guile par une dépendance à une ancienne version de Guile, guile@2.0 :

guix build --with-input=guile=guile@2.0 guix

C’est un remplacement récursif profond. Donc dans cet exemple, à la fois guix et ses dépendances guile-json (qui dépend aussi de guile) sont reconstruits avec guile@2.0.

Cette option est implémentée avec la procédure Scheme package-input-rewriting (voir package-input-rewriting).

--with-graft=paquet=remplaçant

Cette option est similaire à --with-input mais avec une différence importante : plutôt que de reconstruire la chaîne de dépendance complète, remplaçant est construit puis greffé sur les binaires qui référençaient initialement paquet. Voir Mises à jour de sécurité, pour plus d’information sur les greffes.

Par exemple, la commande ci-dessous greffe la version 3.5.4 de GnuTLS sur Wget et toutes ses dépendances, en remplaçant les références à la version actuelle de GnuTLS à laquelle ils se réfèrent actuellement :

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Cela a l’avantage d’être bien plus rapide que de tout reconstruire. Mais il y a un piège : cela ne fonctionne que si paquet et remplaçant sont strictement compatibles — par exemple, s’ils fournissent une bibliothèque, l’interface binaire applicative (ABI) de ces bibliothèques doivent être compatibles. Si remplaçant est incompatible avec paquet, alors le paquet qui en résulte peut devenir inutilisable. À utiliser avec précaution !

--with-debug-info=paquet

Construire paquet de manière à préserver ses informations de débogage et les greffer sur les paquets qui en dépendent. Cela est utile si paquet ne fournit pas déjà les informations de débogage sous forme de sortie debug (voir Installer les fichiers de débogage).

Par exemple, supposons que vous subissiez un plantage de Inkscape et que vous vouliez voir ce qui se passe dans GLib, une bibliothèque au fond du graphe de dépendance d’Inkscape. GLib n’a pas de sortie debug, donc le débogage est difficile. Heureusement, vous reconstruisez la GLib avec les informations de débogage et vous l’installez dans Inkscape :

guix install inkscape --with-debug-info=glib

Seule GLib doit être recompilée, ce qui prend un temps raisonnable. Voir Installer les fichiers de débogage, pour plus d’informations.

Remarque : Sous le capot, cette option fonctionne en passant par le ‘#:strip-binaries ? #f’ au système de construction du paquet qui nous intéresse (voir Systèmes de construction). La plupart des systèmes de compilation supportent cette option, mais certains ne le font pas. Dans ce cas, une erreur se produit.

De même, si un paquet C/C++ est construit sans -g (ce qui est rarement le cas), les informations de débogage resteront indisponibles même si #:strip-binaries? est faux.

--with-c-toolchain=package=toolchain

Cette option modifie la compilation de package et de tout ce qui en dépend afin qu’ils soient construits avec toolchain au lieu de la chaîne d’outils GNU par défaut pour C/C++.

Regardez cet exemple :

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

La commande ci-dessus construit une variante des paquets fftw et fftwf en utilisant la version 10 de gcc-toolchain au lieu de la chaîne d’outils par défaut, puis construit une variante de l’interface en ligne de commande GNU Octave en les utilisant. GNU Octave lui-même est également construit avec gcc-toolchain@10.

Cet autre exemple construit la bibliothèque Hardware Locality (hwloc) et ses dépendances jusqu’à intel-mpi-benchmarks avec le compilateur Clang C :

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Remarque : Il peut y avoir des incompatibilités d’interface binaire d’application (ABI) entre les chaînes d’outils. Cela est particulièrement vrai pour la bibliothèque standard C++ et les bibliothèques de support d’exécution telles que celle d’OpenMP. En reconstruisant toutes les dépendances avec la même chaîne d’outils, --with-c-toolchain minimise les risques d’incompatibilité mais ne peut pas les éliminer entièrement. Choisissez package judicieusement.

--with-git-url=paquet=url ¶

Construire paquet depuis le dernier commit de la branche master du dépôt sur url. Les sous-modules Git du dépôt sont récupérés, récursivement.

Par exemple, la commande suivante construit la bibliothèque Python NumPy avec le dernier commit de la branche master de Python lui-même :

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Cette option peut aussi être combinée avec --with-branch ou --with-commit (voir plus bas).

Évidemment, comme cela utilise le dernier commit d’une branche donnée, le résultat d’une telle commande varie avec le temps. Néanmoins c’est une manière pratique pour reconstruire des piles logicielles entières avec le dernier commit d’un ou plusieurs paquets. C’est particulièrement pratique dans le contexte d’une intégration continue.

Les clones sont gardés dans un cache dans ~/.cache/guix/checkouts pour accélérer les accès consécutifs au même dépôt. Vous pourriez vouloir le nettoyer de temps en temps pour récupérer de l’espace disque.

--with-branch=paquet=branche

Construire paquet à partir du dernier commit de la branche. Si le champ source de paquet est une origine avec la méthode git-fetch (voir Référence de origin) ou un objet git-checkout, l’URL du dépôt est récupérée à partir de cette source. Sinon, vous devez utiliser --with-git-url pour spécifier l’URL du dépôt Git.

Par exemple, la commande suivante construit guile-sqlite3 à partir du dernier commit de sa branche master, puis construit guix (qui en dépend) et cuirass (qui dépend de guix) avec cette construction spécifique de guile-sqlite3 :

guix build --with-branch=guile-sqlite3=master cuirass

--with-commit=paquet=commit

Cela est similaire à --with-branch, sauf qu’elle construite à partir de commit au lieu du sommet d’une branche. commit doit être un identifiant SHA1 de commit Git valide, un tag ou un identifiant dans le style de git describe comme 1.0-3-gabc123.

--with-patch=paquet=fichier

Ajoute fichier à la liste des correctifs appliqués à paquet, où paquet est une spécification comme python@3.8 ou glibc. fichier doit contenir un correctif ; il est appliqué avec les drapeaux spécifiés dans l’origin de paquet (voir Référence de origin), qui par défaut inclus -p1 voir patch Directories dans Comparing and Merging Files).

Par exemple, la commande ci-dessous reconstruit Coreutils avec la bibliothèque C de GNU (glibc) corrigée avec le correctif donné :

guix build coreutils --with-patch=glibc=./glibc-frob.patch

Dans cet exemple, glibc lui-meme ainsi que tout ce qui mène à Coreutils dans le graphe des dépendances est reconstruit.

--with-latest=paquet

Alors vous aimez les toutes dernières technologies ? Cette option est faite pour vous ! Elle remplace les occurence de paquet dans le graphe des dépendances avec sa toute dernière version en amont, telle que rapportée par guix refresh (voir Invoquer guix refresh).

Elle fait cela en déterminant la dernière version publiée en amont (si possible), en la téléchargeant et en l’authentifiant si elle propose une signature OpenPGP.

Par exemple, la commande ci-dessous construit Guix avec la dernière version de Guile-JSON :

guix build guix --with-latest=guile-json

Il y a des limites. Déjà, dans les cas où l’outil ne peut pas ou ne sait pas comment authentifier le code source, vous risquez de charger du code malveillant ; un avertissement est émis dans ce cas. Ensuite, cette option change simplement la source utilisée dans les définitions existantes des paquets, ce qui n’est pas toujours suffisant : il peut y avoir des dépendances supplémentaires qui doivent être ajoutées, des correctifs à appliquer, et plus généralement tout le travail d’assurance qualité que les développeurs de Guix font habituellement sera absent.

On vous aura prévenu ! Dans tous les autres cas, c’est une méthode pour rester à la hauteur qui a du punch ! Nous vous encourageons à soumettre des correctifs pour les définitions des paquets quand vous aurez testé une mise à jour (voir Contribuer).

--without-tests=paquet

Construire paquet sans lancer la suite de tests. Cela peut être utile dans les situations où vous voulez éviter la longue série de tests d’un paquet intermédiaire, ou si une suite de tests de paquet échoue dans un mode non déterministe. Il doit être utilisé avec précaution car l’exécution de la suite de tests est un bon moyen de s’assurer qu’un paquet fonctionne comme prévu.

L’arrêt des tests conduit à un autre élément du dépôt. Par conséquent, lorsque vous utilisez cette option, tout ce qui dépend de paquet doit être reconstruit, comme dans cet exemple :

guix install --without-tests=python python-notebook

La commande ci-dessus installe python-notebook par dessus python, construit sans exécuter sa suite de tests. Pour ce faire, elle reconstruit également tout ce qui dépend de python, y compris python-notebook lui-même.

En interne, --without-tests repose sur le changement de l’option #:tests? de la phase check d’un paquet (voir Systèmes de construction). Notez que certains paquets utilisent une phase check personnalisée qui ne respecte pas le paramètre #:tests? #f. Par conséquent, --without-tests n’a aucun effet sur ces paquets.

Vous vous demandez comme faire la même chose dans du code Scheme, par exemple dans votre manifeste, ou comme écrire votre propre transformation de paquets ? Voir Définition de variantes de paquets, pour un aperçu des interfaces de programmation disponibles.