8.3 Invoquer guix pack

Parfois vous voulez passer un logiciel à des gens qui n’ont pas (encore !) la chance d’utiliser Guix. Vous leur diriez bien de lancer guix package -i quelque chose mais ce n’est pas possible dans ce cas. C’est là que guix pack entre en jeu.

Remarque : Si vous cherchez comment échanger des binaires entre des machines où Guix est déjà installé, voir Invoquer guix copy, Invoquer guix publish, et Invoquer guix archive.

La commande guix pack crée un pack ou lot de logiciels : elle crée une archive tar ou un autre type d’archive contenant les binaires pour le logiciel qui vous intéresse ainsi que ses dépendances. L’archive qui en résulte peut être utilisée sur toutes les machines qui n’ont pas Guix et les gens peuvent lancer exactement les mêmes binaires que ceux que vous avez avec Guix. Le pack lui-même est créé d’une manière reproductible au bit près, pour que n’importe qui puisse vérifier qu’il contient bien les résultats que vous prétendez proposer.

Par exemple, pour créer un lot contenant Guile, Emacs, Geiser et toutes leurs dépendances, vous pouvez lancer :

$ guix pack guile emacs emacs-geiser
…
/gnu/store/…-pack.tar.gz

Le résultat ici est une archive tar contenant un répertoire /gnu/store avec tous les paquets nécessaires. L’archive qui en résulte contient un profil avec les trois paquets qui vous intéressent ; le profil est le même qui celui qui aurait été créé avec guix package -i. C’est ce mécanisme qui est utilisé pour créer les archives tar binaires indépendantes de Guix (voir Installation binaire).

Les utilisateurs de ce pack devraient lancer /gnu/store/…-profile/bin/guile pour lancer Guile, ce qui n’est pas très pratique. Pour éviter cela, vous pouvez créer, disons, un lien symbolique /opt/gnu/bin vers le profil :

guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser

De cette façon, les utilisateurs peuvent joyeusement taper /opt/gnu/bin/guile et profiter.

Et si le destinataire de votre pack n’a pas les privilèges root sur sa machine, et ne peut donc pas le décompresser dans le système de fichiers root ? Dans ce cas, vous pourriez utiliser l’option --relocatable (voir plus bas). Cette option produit des binaires repositionnables, ce qui signifie qu’ils peuvent être placés n’importe où dans l’arborescence du système de fichiers : dans l’exemple au-dessus, les utilisateur·rice·s peuvent décompresser votre archive dans leur répertoire personnel et lancer directement ./opt/gnu/bin/guile.

Autrement, vous pouvez produire un pack au format d’image Docker avec la commande suivante :

guix pack -f docker -S /bin=bin guile guile-readline

Le résultat est une archive tar qui peut être passée à la commande docker load, puis à docker run :

docker load < file
docker run -ti guile-guile-readline /bin/guile

où fichier est l’image renvoyée par guix pack et guile-guile-readline est son « tag d’image ». Voir la documentation de Docker pour plus d’informations.

Autrement, vous pouvez produire une image SquashFS avec la commande suivante :

guix pack -f squashfs bash guile emacs emacs-geiser

Le résultat est une image de système de fichiers SquashFS qui peut soit être montée directement soit être utilisée comme image de conteneur de système de fichiers avec l’Singularity container execution environment, avec des commandes comme singularity shell ou singularity exec.

Diverses options en ligne de commande vous permettent de personnaliser votre pack :

--format=format

-f format

Produire un pack dans le format donné.

Les formats disponibles sont :

tarball

C’est le format par défaut. Il produit une archive tar contenant tous les binaires et les liens symboliques spécifiés.

docker

Cela produit une archive tar qui suit la spécification des images Docker. Le « nom de dépôt » qui apparaît dans la sortie de la commande docker images est calculé à partir des noms des paquets passés sur la ligne de commande ou dans le fichier manifeste.

squashfs

Cela produit une image SquashFS contenant tous les binaires et liens symboliques spécifiés, ainsi que des points de montages vides pour les systèmes de fichiers virtuels comme procfs.

Remarque : Singularity requiert que vous fournissiez /bin/sh dans l’image. Pour cette raison, guix pack -f squashfs implique toujours -S /bin=bin. Ainsi, votre invocation guix pack doit toujours commencer par quelque chose comme :

guix pack -f squashfs bash …

Si vous oubliez le paquet bash (ou similaire), singularity run et singularity exec vont échouer avec un message « no such file or directory » peu utile.

deb

Cela produit une archive Debian (un paquet avec l’extension ‘.deb’) contenant tous les binaires et les liens symboliques spécifiés, qui peut être installée sur n’importe quelle distribution GNU(/Linux) basée sur dpkg. Vous trouverez des options avancées avec l’option --help-deb-format. Elles permettent d’insérer des fichiers control pour un contrôle plus fin, comme pour activer des trigger ou fournir un script de configuration pour mainteneur pour lancer du code de configuration arbitraire à l’installation.

guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello

Remarque : Comme les archives produites par guix pack contiennent une collection d’objets du dépôt et comme chaque paquet dpkg ne doit pas avoir de conflits de fichiers, en pratique cela signifie que vous ne pourrez sans doute pas installer plus d’une archive de ce genre sur un système donné.

Attention : dpkg prendra possession de tout fichier contenu dans le pack qu’il ne connaît pas. Il est peu avisé d’installer des fichiers ‘.deb’ produits par Guix sur un système où /gnu/store est partagé avec un autre logiciel, comme une installation de Guix ou d’autres packs non deb.

--relocatable

-R

Produire des binaires repositionnables — c.-à-d. des binaires que vous pouvez placer n’importe où dans l’arborescence du système de fichiers et les lancer à partir de là.

Lorsque vous passez cette option une fois, les binaires qui en résultent demandent le support des espaces de nom utilisateurs dans le noyau Linux ; lorsque vous la passez deux fois¹⁸, les binaires repositionnables utilisent PRoot si les espaces de noms ne sont pas utilisables, et ça fonctionne à peu près partout — voir plus bas pour comprendre les implications.

Par exemple, si vous créez un pack contenant Bash avec :

guix pack -RR -S /mybin=bin bash

… vous pouvez copier ce pack sur une machine qui n’a pas Guix et depuis votre répertoire personnel en tant qu’utilisateur non-privilégié, lancer :

tar xf pack.tar.gz
./mybin/sh

Dans ce shell, si vous tapez ls /gnu/store, vous remarquerez que /gnu/store apparaît et contient toutes les dépendances de bash, même si la machine n’a pas du tout de /gnu/store ! C’est sans doute la manière la plus simple de déployer du logiciel construit avec Guix sur une machine sans Guix.

Remarque : Par défaut ,les binaires repositionnables s’appuient sur les espaces de noms utilisateurs du noyau Linux, qui permet à des utilisateurs non-privilégiés d’effectuer des montages et de changer de racine. Les anciennes versions de Linux ne le supportait pas et certaines distributions GNU/Linux le désactive.

Pour produire des binaires repositionnables qui fonctionnent même sans espace de nom utilisatrice·eur, passez --relocatable ou -R deux fois. Dans ce cas, les binaires testeront la prise en charge des espaces de noms utilisatrice·eur·s et utiliseront PRoot s’ils ne sont pas pris en charge. Les moteurs d’exécution suivants sont pris en charge :

default

Essayez les espaces de noms utilisateur·rice·s et revenez à PRoot si les espaces de noms utilisateur·rice·s ne sont pas pris en charge (voir ci-dessous).

performance

Essayez les espaces de noms utilisateur·rice·s et revenez à Fakechroot si les espaces de noms utilisateur·rice·s ne sont pas pris en charge (voir ci-dessous).

users

Lance le programme à travers les espaces de nom utilisateur·rice et échoue s’ils ne sont pas supportés.

proot

Passez à travers PRoot. Le programme PRoot fournit la prise en charge nécessaire pour la virtualisation du système de fichier. Il y parvient en utilisant l’appel système ptrace sur le programme courant. Cette approche a l’avantage de fonctionner sans demander de support spécial de la part du noyau, mais occasionne un coût supplémentaire en temps pour chaque appel système effectué.

fakechroot

Passez à travers Fakechroot. Fakechroot virtualise les accès au système de fichier en interceptant les appels vers les fonctions de la bibliothèque C telles que open, stat, exec, et ainsi de suite. Contrairement à PRoot, il n’engendre que très peu de coûts généraux. Cependant, il ne fonctionne pas encore tout-à-fait : par exemple, certains accès au système de fichier effectués à partir de la bibliothèque C ne sont pas interceptés, et les accès au système de fichier effectués via les appels système directs ne sont pas non plus interceptés, conduisant à un comportement erratique.

Lors de l’exécution d’un programme complet, vous pouvez demander explicitement l’un des moteurs d’exécution énumérés ci-dessus en définissant en conséquence la variable d’environnement GUIX_EXECUTION_ENGINE.

--entry-point=commande

Utiliser commande comme point d’entrée du paquet résultant, si le format du paquet le supporte–actuellement docker et squashfs (Singularity) la supportent. command doit être relatif au profil contenu dans le pack.

Le point d’entrée spécifie la commande que des outils comme docker run or singularity run lancent automatiquement par défaut. Par exemple, vous pouvez faire :

guix pack -f docker --entry-point=bin/guile guile

Le pack résultant peut être facilement chargé et docker run sans arguments supplémentaires engendrera bin/guile :

docker load -i pack.tar.gz
docker run image-id

--expression=expr

-e expr

Considérer le paquet évalué par expr.

Cela a le but identique que l’option de même nom de guix build (voir --expression dans guix build).

--manifest=fichier

-m fichier

Utiliser les paquets contenus dans l’objet manifeste renvoyé par le code Scheme dans fichier. Vous pouvez répéter cette option plusieurs fois, auquel cas les manifestes sont concaténés.

Elle a un but similaire à l’option de même nom dans guix package (voir --manifest) et utilise les mêmes fichiers manifeste. Ils vous permettent de définir une collection de paquets une fois et de l’utiliser aussi bien pour créer des profils que pour créer des archives pour des machines qui n’ont pas Guix d’installé. Remarquez que vous pouvez spécifier soit un fichier manifeste, soit une liste de paquet, mais pas les deux.

Voir Écrire un manifeste pour des informations sur l’écriture d’un manifeste. Voir guix shell --export-manifest, pour des informations sur la « conversion » des options de la ligne de commande en un manifeste.

--system=système

-s système

Tenter de construire pour le système — p. ex. i686-linux — plutôt que pour le type de système de l’hôte de construction.

--target=triplet ¶

Effectuer une compilation croisée pour triplet qui doit être un triplet GNU valide, comme ""aarch64-linux-gnu"" (voir GNU configuration triplets dans Autoconf).

--compression=outil

-C outil

Compresser l’archive résultante avec outil — l’un des outils parmi gzip, zstd, bzip2, xz, lzip, ou none pour aucune compression.

--symlink=spec

-S spec

Ajouter les liens symboliques spécifiés par spec dans le pack. Cette option peut apparaître plusieurs fois.

spec a la forme source=cible, où source est le lien symbolique qui sera créé et cible est la cible du lien.

Par exemple, -S /opt/gnu/bin=bin crée un lien symbolique /opt/gnu/bin qui pointe vers le sous-répertoire bin du profil.

--save-provenance

Sauvegarder les informations de provenance des paquets passés sur la ligne de commande. Les informations de provenance contiennent l’URL et le commit des canaux utilisés (voir Canaux).

Les informations de provenance sont sauvegardées dans le fichier /gnu/store/…-profile/manifest du pack, avec les métadonnées de paquets habituelles — le nom et la version de chaque paquet, leurs entrées propagées, etc. Ce sont des informations utiles pour le destinataire du pack, qui sait alors comment le pack a (normalement) été obtenu.

Cette option n’est pas activée par défaut car, comme l’horodatage, les informations de provenance ne contribuent en rien au processus de construction. En d’autres termes, il y a une infinité d’URL et d’ID de commit qui permettent d’obtenir le même pack. Enregistrer de telles métadonnées « silencieuses » dans la sortie casse donc éventuellement la propriété de reproductibilité au bit près.

--root=fichier ¶

-r fichier

Fait de fichier un lien symbolique vers le résultat, et l’enregistre en tant que racine du ramasse-miettes.

--localstatedir

--profile-name=nom

Inclus le « répertoire d’état local », /var/guix, dans le lot qui en résulte, et notamment le profil /var/guix/profiles/per-user/root/nom — par défaut nom est guix-profile, ce qui correspond à ~root/.guix-profile.

/var/guix contient la base de données du dépôt (voir Le dépôt) ainsi que les racines du ramasse-miettes (voir Invoquer guix gc). Le fournir dans le pack signifie que le dépôt et « complet » et gérable par Guix ; ne pas le fournir dans le pack signifie que le dépôt est « mort » : aucun élément ne peut être ajouté ni enlevé après l’extraction du pack.

Un cas d’utilisation est l’archive binaire indépendante de Guix (voir Installation binaire).

--derivation

-d

Affiche le nom de la dérivation que le pack construit.

--bootstrap

Utiliser les programmes d’amorçage pour construire le pack. Cette option n’est utile que pour les personnes qui développent Guix.

En plus, guix pack supporte toutes les options de construction communes (voir Options de construction communes) et toutes les options de transformation de paquets (voir Options de transformation de paquets).