Manuel de référence de GNU Guix

Table des matières

GNU Guix

Cette documentation décrit GNU Guix version 1.3.0, un outil de gestion de paquets fonctionnel écrit pour le système GNU.

Ce manuel est aussi disponible en anglais (voir GNU Guix Reference Manual), en allemand (voir Referenzhandbuch zu GNU Guix), en chinois simplifié (voir GNU Guix参考手册), en espagnol (voir Manual de referencia de GNU Guix) et en russe (voir Руководство GNU Guix). Si vous souhaitez nous aider à traduire ce manuel en français, vous pouvez nous rejoindre sur Weblate et sur la liste de diffusion traduc@traduc.org.

 — Liste détaillée des nœuds —



Introduction

Installation

Paramétrer le démon

Installation du système

Installation manuelle

Gestion de paquets

Substituts

Canaux

Développement

Interface de programmation

Définition des paquets

Utilitaires

Invoquer guix build

Configuration du système

Services

Définir des services

Installer les fichiers de débogage

Bootstrapping

1 Introduction

GNU Guix¹ est un outil de gestion de paquets et une distribution pour le système GNU. Guix facilite pour les utilisateur·rice·s non privilégié·e·s l’installation, la mise à jour et la suppression de paquets, la restauration à un ensemble de paquets précédent, la construction de paquets depuis les sources et plus généralement aide à la création et à la maintenance d’environnements logiciels.

Vous pouvez installer GNU Guix sur un système GNU/Linux existant pour compléter les outils disponibles sans interférence (voir Installation) ou vous pouvez l’utiliser comme distribution système indépendante, Guix System². Voir Distribution GNU.

1.1 Gérer ses logiciels avec Guix

Guix fournit une interface de gestion des paquets par la ligne de commande (voir Gestion de paquets), des outils pour aider au développement logiciel (voir Développement), des utilitaires en ligne de commande pour des utilisations plus avancées (voir Utilitaires) ainsi que des interfaces de programmation Scheme (voir Interface de programmation). Son démon de construction est responsable de la construction des paquets pour les utilisateur·rice·s (voir Paramétrer le démon) et du téléchargement des binaires pré-construits depuis les sources autorisées (voir Substituts).

Guix contient de nombreuses définitions de paquet GNU et non-GNU qui respectent tous les libertés de l’utilisateur ou utilisatrice. Il est extensible  : chacun·e peut écrire ses propres définitions de paquets (voir Définition des paquets) et les rendre disponibles dans des modules de paquets indépendants (voir Modules de paquets). Il est aussi personnalisable : on peut dériver des définitions de paquets spécialisées à partir de définitions existantes, même depuis la ligne de commande (voir Options de transformation de paquets).

Sous le capot, Guix implémente la discipline de gestion de paquet fonctionnel inventé par Nix (voir Remerciements). Dans Guix le processus de construction et d’installation des paquets est vu comme une fonction dans le sens mathématique du terme. Cette fonction a des entrées (comme des scripts de construction, un compilateur et des bibliothèques) et renvoie un paquet installé. En tant que fonction pure, son résultat ne dépend que de ses entrées. Par exemple, il ne peut pas faire référence à des logiciels ou des scripts qui n’ont pas été explicitement passés en entrée. Une fonction de construction produit toujours le même résultat quand on lui donne le même ensemble d’entrée. Elle ne peut pas modifier l’environnement du système en cours d’exécution d’aucune manière ; par exemple elle ne peut pas créer, modifier ou supprimer des fichiers en dehors de ses répertoires de construction et d’installation. Ce résultat s’obtient en lançant les processus de construction dans des environnements isolés (ou des conteneurs) où seules les entrées explicites sont visibles.

Le résultat des fonctions de construction de paquets est mis en cache dans le système de fichier, dans répertoire spécial appelé le dépôt (voir Le dépôt). Chaque paquet est installé dans son répertoire propre dans le dépôt — par défaut dans /gnu/store. Le nom du répertoire contient un hash de toutes les entrées utilisées pour construire le paquet ; ainsi, changer une entrée donnera un nom de répertoire différent.

Cette approche est le fondement des fonctionnalités les plus importante de Guix : le support des mises à jour des paquets et des retours en arrière transactionnels, l’installation différenciée par utilisateur·rice et le ramassage de miettes pour les paquets (voir Fonctionnalités).

1.2 Distribution GNU

Guix fournit aussi une distribution du système GNU contenant uniquement des logiciels libres³. On peut installer la distribution elle-même (voir Installation du système), mais on peut aussi installer Guix comme gestionnaire de paquets par dessus un système GNU/Linux déjà installé (voir Installation). Pour distinguer ces deux cas, on appelle la distribution autonome le « système Guix » ou Guix System.

La distribution fournit les paquets cœur de GNU comme la GNU libc, GCC et Binutils, ainsi que de nombreuses applications GNU et non-GNU. La liste complète des paquets disponibles se trouve en ligne ou en lançant guix package (voir Invoquer guix package) :

guix package --list-available

Notre but est de fournir une distribution logicielle entièrement libre de GNU/Linux et d’autres variantes de GNU, en se concentrant sur la promotion et l’intégration étroite des composants GNU en insistant sur les programmes et les outils qui aident l’utilisateur·rice à exercer ses libertés.

Les paquets sont actuellement disponibles pour les plateformes suivantes :

x86_64-linux

Intel/AMD x86_64 avec le noyau Linux-libre.

i686-linux

Architecture Intel 32 bits (IA32) avec le noyau Linux-libre.

armhf-linux

L’architecture ARMv7-A avec gestion des flottants matérielle, Thumb-2 et NEON, avec l’interface binaire applicative (ABI) EABI hard-float et le noyau Linux-libre.

aarch64-linux

les processeurs 64 bits ARMv8-A en little-endian, avec le noyau Linux-libre.

i586-gnu

GNU/Hurd sur l’architecture Intel 32-bit (IA32).

Cette configuration en cours de développement est expérimentale. La manière la plus facile pour vous de l’essayer est de créer une instance hurd-vm-service-type sur votre machine GNU/Linux (voir hurd-vm-service-type). Voir Contribuer, sur la façon d’aider !

mips64el-linux (obsolète)

les processeurs MIPS 64 bits little-endian, en particulier la série Loongson, l’ABI n32 et le noyau Linux-Libre. Cette configuration n’est plus entièrement prise en charge ; en particulier, il n’y a pas de travaux en cours pour s’assurer que cette architecture fonctionne encore. Si quelqu’un décide de faire revivre cette architecture, le code est toujours disponible.

powerpc64le-linux

Les processeurs little-endian et le noyau linux-Libre. Cela couvre les systèmes POWER9 comme la carte mère Talos II certifiée RYF. Cette plateforme est disponible en tant que « démonstrateur technique » : bien qu’elle soit prise en charge, les substituts ne sont pas encore disponibles dans notre ferme de construction (voir Substituts) et certains paquets peuvent ne pas construire (voir Suivi des bogues et des correctifs). Cela dit, la communauté Guix travaille activement à améliorer cette prise en charge et c’est donc maintenant le bon moment pour l’essayer et participer !

Avec Guix System, vous déclarez tous les aspects de la configuration du système d’exploitation et guix s’occupe d’instancier la configuration de manière transactionnelle, reproductible et sans état (voir Configuration du système). Guix System utilise le noyau Linux-libre, le système d’initialisation Shepherd (voir Introduction dans The GNU Shepherd Manual), les outils GNU et la chaîne d’outils familière ainsi que l’environnement graphique et les services systèmes de votre choix.

Guix System est disponible sur toutes les plateformes ci-dessus à part mips64el-linux et powerpc64le-linux.

Pour des informations sur comment porter vers d’autres architectures et d’autres noyau, voir Porter.

La construction de cette distribution est un effort collaboratif et nous vous invitons à nous rejoindre ! Voir Contribuer, pour des informations sur la manière de nous aider.

2 Installation

Remarque : Nous vous recommandons d’utiliser ce script shell d’installation pour installer Guix sur un système GNU/Linux fonctionnel, que nous appelons une distro externe⁴. Le script automatise le téléchargement, l’installation et la configuration initiale de Guix. Vous devez l’exécuter en tant que root.

Lorsqu’il est installé sur une distro externe, GNU Guix complète les outils disponibles sans interférence. Ses données se trouvent exclusivement dans deux répertoires, typiquement /gnu/store et /var/guix ; les autres fichiers de votre système comme /etc sont laissés intacts.

Une fois installé, Guix peut être mis à jour en lançant guix pull (voir Invoquer guix pull).

Si vous préférez effectuer les étapes d’installation manuellement ou si vous voulez les personnaliser, vous trouverez les sections suivantes utile. Elles décrivent les prérequis logiciels pour Guix, ainsi que la manière de l’installer manuellement et de se préparer à l’utiliser.

2.1 Installation binaire

Cette section décrit comment installer Guix sur un système quelconque depuis un archive autonome qui fournit les binaires pour Guix et toutes ses dépendances. C’est souvent plus rapide que d’installer depuis les sources, ce qui est décrit dans les sections suivantes. Le seul prérequis est d’avoir GNU tar et Xz.

Remarque : Nous recommandons l’utilisation de ce script d’installation du shell. Ce script automatise les étapes de téléchargement, d’installation et de configuration initiale décrites ci-dessous. Il doit être exécuté sous l’utilisateur root. Vous pouvez donc l’exécuter en tant que root :

cd /tmp
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh

Lorsque vous aurez terminé, voir Réglages applicatifs pour la configuration supplémentaire dont vous pourriez avoir besoin, et Pour démarrer pour vos premiers pas !

L’installation se comme ceci :

1. Télécharger le tarball binaire à partir de ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz’, où x86_64-linux peut être remplacé par i686-linux pour une i686 (32-bits) machine fonctionnant déjà avec le noyau Linux, et autres (voir Distribution GNU).

   Assurez-vous de télécharger le fichier .sig associé et de vérifier l’authenticité de l’archive avec, comme ceci :

   $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz.sig
   $ gpg --verify guix-binary-1.3.0.x86_64-linux.tar.xz.sig
   

   Si cette commande échoue parce que vous n’avez pas la clef publique requise, lancez cette commande pour l’importer :

   $ wget 'https://sv.gnu.org/people/viewgpg.php?user_id=127547' \
         -qO - | gpg --import -
   

   et relancez la commande gpg --verify.

   Remarquez qu’un avertissement du type « Cette clef n’est pas certifiée par une signature de confiance ! » est normal.

2. Maintenant, vous devez devenir root. En fonction de votre distribution, vous devrez lancer su - ou sudo -i. En tant que root, lancez :

   # cd /tmp
   # tar --warning=no-timestamp -xf \
        /chemin/vers/guix-binary-1.3.0.x86_64-linux.tar.xz
   # mv var/guix /var/ && mv gnu /
   

   Cela crée /gnu/store (voir Le dépôt) and /var/guix. Ce dernier contient un profil prêt à être utilisé pour root (voir les étapes suivantes).

   Ne décompressez pas l’archive sur un système Guix lancé car cela écraserait ses propres fichiers essentiels.

   L’option --warning=no-timestamp permet de s’assurer que GNU tar n’émet pas d’avertissements concernant des « horodatages manifestement anciens » (de tels avertissements ont été déclenchés par GNU tar 1.26 et plus anciens ; les versions récentes conviennent). Ils proviennent du fait que tous les fichiers de l’archive ont leur heure de modification fixée à un (ce qui signifie le 1er janvier 1970). Ceci est fait exprès pour s’assurer que le contenu de l’archive est indépendant de son temps de création, la rendant ainsi reproductible.

3. Rendez le profil disponible sous ~root/.config/guix/current, qui est l’emplacement où guix pull installera les mises à jour (voir Invoquer guix pull) :

   # mkdir -p ~root/.config/guix
   # ln -sf /var/guix/profiles/per-user/root/current-guix \
            ~root/.config/guix/current
   

   Agrémentez etc/profile pour augmenter PATH et les autres variables d’environnement nécessaires :

   # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
     source $GUIX_PROFILE/etc/profile
   

4. Créez le groupe et les comptes utilisés pour la construction comme expliqué plus loin (voir Réglages de l'environnement de construction).
5. Lancez le démon et paramétrez-le pour démarrer automatiquement au démarrage.

   Si votre distribution hôte utilise le système d’initialisation systemd, cela peut se faire avec ces commandes :

   # cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \
        ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
        /etc/systemd/system/
   # systemctl enable --now gnu-store.mount guix-daemon
   

   Si votre distribution hôte utilise le système d’initialisation Upstart :

   # initctl reload-configuration
   # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
        /etc/init/
   # start guix-daemon
   

   Sinon, vous pouvez toujours démarrer le démon manuellement avec :

   # ~root/.config/guix/current/bin/guix-daemon \
          --build-users-group=guixbuild
   

6. Rendez la commande guix disponible pour les autres personnes sur la machine, par exemple avec :

   # mkdir -p /usr/local/bin
   # cd /usr/local/bin
   # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
   

   C’est aussi une bonne idée de rendre la version Info de ce manuel disponible ici :

   # mkdir -p /usr/local/share/info
   # cd /usr/local/share/info
   # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
     do ln -s $i ; done
   

   Ainsi, en supposant que /usr/local/share/info se trouve dans le chemin de recherche, l’exécution de info guix ouvrira ce manuel (voir (GNU Texinfo)texinfo, pour plus de détails sur la modification du chemin de recherche Info).

7. Pour utiliser les substituts de ci.guix.gnu.org ou l’un de ses miroirs (voir Substituts), autorisez-les :

   # guix archive --authorize < \
        ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
   

8. On peut avoir besoin d’effectuer des étapes supplémentaires pour que son environnement Guix soit prêt à être utilisé, voir Réglages applicatifs.

Voilà, l’installation est terminée !

Vous pouvez confirmer que Guix fonctionne en installant un paquet d’exemple dans le profil de root :

# guix install hello

L’archive d’installation binaire peut être (re)produite et vérifiée simplement en lançant la commande suivante dans l’arborescence des sources de Guix :

make guix-binary.system.tar.xz

… ce qui à son tour lance :

guix pack -s system --localstatedir \
  --profile-name=current-guix guix

Voir Invoquer guix pack, pour plus d’info sur cet outil pratique.

2.2 Prérequis

Cette section dresse la liste des prérequis pour la construction de Guix depuis les sources. La procédure de construction pour Guix est la même que pour les autres logiciels GNU, et n’est pas expliquée ici. Regardez les fichiers README et INSTALL dans l’arborescence des sources de Guix pour plus de détails.

GNU Guix est disponible au téléchargement depuis son site web sur http://www.gnu.org/software/guix/.

GNU Guix dépend des paquets suivants :

• GNU Guile, version 3.0.x ou 2.2.x ;
• Guile-Gcrypt, version 0.1.0 ou supérieure ;
• GnuTLS, en particulier ses liaisons Guile (voir how to install the GnuTLS bindings for Guile dans GnuTLS-Guile) ;
• Guile-SQLite3, version 0.1.0 ou supérieure ;
• Guile-zlib, version 0.1.0 ou supérieure ;
• Guile-lzlib ;
• Guile-Avahi ;
• Guile-Git, version 0.3.0 ou supérieure ;
• Guile-JSON 4.3.0 ou plus récent ;
• GNU Make.

Les dépendances suivantes sont facultatives :

• Traitement du déchargement des builds (voir Réglages du délestage du démon) et guix copy (voir Invoquer guix copy) dépend de Guile-SSH, version 0.13.0 ou ultérieure.
• Guile-zstd, pour la compression et la décompression zstd dans guix publish et pour les substituts (voir Invoquer guix publish).
• Guile-Semver pour l’importateur crate (voir Invoquer guix import).
• Guile-Lib pour l’importateur go (voir Invoquer guix import) et pour certains programmes de mise à jour .(voir Invoquer guix refresh).
• Lorsque libbz2 est disponible, guix-daemon peut l’utiliser pour compresser les journaux de construction.

Sauf si --disable-daemon a été passé à configure, les paquets suivants sont également nécessaires :

• GNU libgcrypt ;
• SQLite 3 ;
• GCC’s g++, avec le support pour le Standard C++11.

Lorsque vous configurez Guix sur un système qui a déjà une installation de Guix, assurez-vous de spécifier le même répertoire d’état que l’installation existante avec l’option --localstatedir du script configure (voir localstatedir dans GNU Coding Standards). Habituellement cette option localstatedir est initialisée à /var. Le script configure vous protège des configurations involontaires de localstatedir pour éviter que vous ne corrompiez votre dépôt (voir Le dépôt).

2.3 Lancer la suite de tests

Après avoir lancé configure et make correctement, c’est une bonne idée de lancer la suite de tests. Elle peut aider à trouver des erreurs avec la configuration ou l’environnement, ou des bogues dans Guix lui-même — et vraiment, rapporter des échecs de tests est une bonne manière d’aider à améliorer le logiciel. Pour lancer la suite de tests, tapez :

make check

Les cas de tests peuvent être lancés en parallèle : vous pouvez utiliser l’option -j de GNU make pour accélérer les choses. Le premier lancement peut prendre plusieurs minutes sur une machine récente ; les lancements suivants seront plus rapides car le dépôt créé pour les tests aura déjà plusieurs choses en cache.

Il est aussi possible de lancer un sous-ensemble des tests en définissant la variable makefile TESTS comme dans cet exemple :

make check TESTS="tests/store.scm tests/cpio.scm"

Par défaut, les résultats des tests sont affichés au niveau du fichier. Pour voir les détails de chaque cas de test individuel, il est possible de définir la variable makefile SCM_LOG_DRIVER_FLAGS comme dans cet exemple :

make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"

Le pilote de tests Automake personnalisé avec SRFI 64 utilisé pour la suite de tests « check » (située dans build-aux/test-driver.scm) permet aussi de choisir les cas de test à lancer à plus fine granularité, via ses options --select et --exclude. Voici un exemple, pour lancer tous les cas de tests du fichier de tests tests/packages.scm dont les noms commencent par « transaction-upgrade-entry » :

export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry"
make check TESTS="tests/packages.scm"

Pour celles et ceux qui veulent inspecter les résultats des tests échoués directement depuis la ligne de commande, il est possible d’ajouter l’option --errors-only=yes à la variable SCM_LOG_DRIVER_FLAGS du Makefile et d’initialiser la variable Automake du Makefile VERBOSE, de cette manière :

make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1

L’option --show-duration=yes peut être utilisée pour afficher la durée des cas de test individuels, en combinaison avec --brief=no :

make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"

Voir Parallel Test Harness dans GNU Automake pour plus d’information sur le banc de tests parallèle d’Automake.

Après un échec, envoyez un courriel à bug-guix@gnu.org et attachez le fichier test-suite.log. Précisez la version de Guix utilisée ainsi que les numéros de version de ses dépendances (voir Prérequis) dans votre message.

Guix possède aussi une suite de tests de systèmes complets qui test des instances complètes du système Guix. Elle ne peut être lancée qui sur un système où Guix est déjà installé, avec :

make check-system

ou, de nouveau, en définissant TESTS pour choisir un sous-ensemble des tests à lancer :

make check-system TESTS="basic mcron"

Ces tests systèmes sont définis dans les modules (gnu tests …). Ils fonctionnent en lançant les systèmes d’exploitation sous test avec une instrumentation légère dans une machine virtuelle (VM). Ils peuvent être intenses en terme de calculs ou plutôt rapides en fonction de la disponibilité des substituts de leurs dépendances (voir Substituts). Certains requièrent beaucoup d’espace disque pour contenir les images des VM.

De nouveau, en cas d’échec, envoyez tous les détails à bug-guix@gnu.org.

2.4 Paramétrer le démon

Les opérations comme la construction d’un paquet ou le lancement du ramasse-miettes sont toutes effectuées par un processus spécialisé, le démon de construction, pour le compte des clients. Seul le démon peut accéder au dépôt et à sa base de données associée. Ainsi, toute opération manipulant le dépôt passe par le démon. Par exemple, les outils en ligne de commande comme guix package et guix build communiquent avec le démon (via des appels de procédures distantes) pour lui dire quoi faire.

Les sections suivantes expliquent comment préparer l’environnement du démon de construction. Voir aussi Substituts pour apprendre comment permettre le téléchargement de binaires pré-construits.

2.4.1 Réglages de l’environnement de construction

Dans une installation standard multi-utilisateur·rice·s, Guix et son démon — le programme guix-daemon — sont installés par la personne qui administre le système ; /gnu/store appartient à root et guix-daemon est lancé en root. Les utilisateur·rice·s non-privilégié·e·s peuvent utiliser les outils Guix pour construire des paquets ou accéder au dépôt et le démon le fera pour leur compte en s’assurant que le dépôt garde un état cohérent et permet le partage des paquets déjà construits entre les utilisateur·rice·s.

Alors que guix-daemon tourne en root, vous n’avez pas forcément envie que les processus de construction de paquets tournent aussi en root, pour des raisons de sécurité évidentes. Pour éviter cela, vous devriez créer une réserve spéciale de comptes de construction que les processus de construction démarrés par le démon utiliseront. Ces comptes de construction n’ont pas besoin d’un shell ou d’un répertoire personnel ; ils seront seulement utilisés quand le démon délaissera ses privilèges root dans les processus de construction. En ayant plusieurs de ces comptes, vous permettez au démon de lancer des processus de construction distincts sous des UID différent, ce qui garanti qu’aucune interférence n’ait lieu entre les uns et les autres — une fonctionnalité essentielle puisque les constructions sont supposées être des fonctions pures (voir Introduction).

Sur un système GNU/Linux, on peut créer une réserve de comptes de construction comme ceci (avec la syntaxe Bash et les commandes shadow) :

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)    \
            -c "Compte de construction Guix $i" --system    \
            guixbuilder$i;
  done

Le nombre de comptes de construction détermine le nombre de tâches de constructions qui peuvent tourner en parallèle, tel que spécifié par l’option --max-jobs (voir --max-jobs). Pour utiliser guix system vm et les commandes liées, vous devrez ajouter les comptes de construction au groupe kvm pour qu’ils puissent accéder à /dev/kvm avec -G guixbuild,kvm plutôt que -G guixbuild (voir Invoquer guix system).

Le programme guix-daemon peut ensuite être lancé en root avec la commande suivante⁵ :

# guix-daemon --build-users-group=guixbuild

De cette façon, le démon démarre les processus de construction dans un chroot, sous un des comptes guixbuilder. Sur GNU/Linux par défaut, l’environnement chroot ne contient rien d’autre que :

• un répertoire /dev minimal, créé presque indépendamment du /dev de l’hôte⁶ ;
• le répertoire /proc ; il ne montre que les processus du conteneur car on utilise une espace de nom séparé pour les PID ;
• /etc/passwd avec une entrée pour le compte actuel et une entrée pour le compte nobody ;
• /etc/group avec une entrée pour le groupe de ce compte ;
• /etc/hosts avec une entrée qui fait correspondre localhost à 127.0.0.1 ;
• un répertoire /tmp inscriptible.

Vous pouvez influencer le répertoire où le démon stocke les arbres de construction via la variable d’environnement TMPDIR. Cependant, l’arbre de construction dans le chroot sera toujours appelé /tmp/guix-build-nom.drv-0, où nom est le nom de la dérivation — p.ex., coreutils-8.24. De cette façon, la valeur de TMPDIR ne fuite pas à l’intérieur des environnements de construction, ce qui évite des différences lorsque le processus de construction retient le nom de leur répertoire de construction.

Le démon prend en compte aussi la variable d’environnement https_proxy pour ses téléchargements HTTP et HTTPS, que ce soit pour les dérivations à sortie fixes (voir Dérivations) ou pour les substituts (voir Substituts).

Si vous installez Guix en tant qu’utilisateur·rice non privilégié·ée, il est toujours possible d’exécuter guix-daemon à condition de passer --disable-chroot. Cependant, les processus de compilation ne seront pas isolés les uns des autres, ni du reste du système. Ainsi, les processus de compilation peuvent interférer les uns avec les autres, et peuvent accéder à des programmes, des bibliothèques et d’autres fichiers disponibles sur le système - ce qui rend beaucoup plus difficile de les considérer comme des fonctions pures.

2.4.2 Utiliser le dispositif de déchargement

Si vous le souhaitez, le démon de construction peut décharger des constructions de dérivation sur d’autres machines Guix avec le crochet de construction offload⁷. Lorsque cette fonctionnalité est activée, Guix lit une liste de machines de constructions spécifiée par l’utilisateur·rice dans /etc/guix/machines.scm ; à chaque fois qu’une construction est demandée, par exemple par guix build, le démon essaie de la décharger sur une des machines qui satisfont les contraintes de la dérivation, en particulier le type de système, p. ex. x86_64-linux. Une même machine peut avoir plusieurs types de systèmes, soit parce que son architecture le supporte nativement, soit par émulation (voir Émulation transparente avec QEMU), soit les deux. Les prérequis manquants pour la construction sont copiés par SSH sur la machine de construction qui procède ensuite à la construction ; si elle réussit, les sorties de la construction sont copiés vers la machine de départ. Le dispsitif de déchargement est dotée d’un scheduler de base qui tente de sélectionner la meilleure machine. La meilleure machine est choisie parmi les machines disponibles sur la base de critères tels que :

1. La disponibilité d’un créneau de construction. Une machine de construction peut avoir autant de slots de construction (connexions) que la valeur du champ parallel-builds de son objet build-machine.
2. Sa vitesse relative, telle que définie dans le champ speed de son objet build-machine.
3. Sa charge. La charge normalisée de la machine doit être inférieure à une valeur seuil, configurable via le champ overload-threshold de son objet build-machine.
4. Disponibilité de l’espace disque. Plus de 100 Mio doivent être disponibles.

Le fichier /etc/guix/machines.scm ressemble typiquement à cela :

(list (build-machine
        (name "eightysix.example.org")
        (system "x86_64-linux")
        (host-key "ssh-ed25519 AAAAC3Nza…")
        (user "bob")
        (speed 2.))     ;incroyablement rapide !

      (build-machine
        (name "armeight.example.org")
        (system "list "aarch64-linux")
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")
        (private-key
         (string-append (getenv "HOME")
                        "/.ssh/identity-for-guix"))))

Dans l’exemple ci-dessus nous spécifions une liste de deux machines de construction, une pour l’architecture x86_64 et i686et une pour l’architecture aarch64.

En fait, ce fichier est — et ça ne devrait pas vous surprendre ! — un fichier Scheme qui est évalué au démarrage du crochet offload. Sa valeur de retour doit être une liste d’objets build-machine. Même si cet exemple montre une liste fixée de machines de construction, on pourrait imaginer par exemple utiliser DNS-SD pour renvoyer une liste de machines de constructions potentielles découvertes sur le réseau local (voir Guile-Avahi dans Using Avahi in Guile Scheme Programs). Le type de données build-machine est détaillé plus bas.

Type de données : build-machine

Ce type de données représente les machines de construction sur lesquelles le démon peut décharger des constructions. Les champs importants sont :

name

Le nom d’hôte de la machine distante.

systèmes

Le type de système de la machine distante, p. ex., (list "x86_64-linux" "i686-linux").

user

Le compte à utiliser lors de la connexion à la machine distante par SSH. Remarquez que la paire de clef SSH ne doit pas être protégée par mot de passe pour permettre des connexions non-interactives.

host-key

Cela doit être la clef d’hôte SSH publique de la machine au format OpenSSH. Elle est utilisée pour authentifier la machine lors de la connexion. C’est une longue chaîne qui ressemble à cela :

ssh-ed25519 AAAAC3NzaC…mde+UhL hint@example.org

Si la machine utilise le démon OpenSSH, sshd, la clef d’hôte se trouve dans un fichier comme /etc/ssh/ssh_host_ed25519_key.pub.

Si la machine utilise le démon SSH de GNU lsh, la clef d’hôte est dans /etc/lsh/host-key.pub ou un fichier similaire. Elle peut être convertie au format OpenSSH avec lsh-export-key (voir Converting keys dans LSH Manual) :

$ lsh-export-key --openssh < /etc/lsh/host-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV…

Il y a un certain nombre de champs facultatifs que vous pouvez remplir :

port (par défaut : 22)

Numéro de port du serveur SSH sur la machine.

private-key (par défaut : ~root/.ssh/id_rsa)

Le fichier de clef privée SSH à utiliser lors de la connexion à la machine, au format OpenSSH. Cette clef ne doit pas être protégée par phrase de passe.

Remarquez que la valeur par défaut est la clef privée du compte root. Assurez-vous qu’elle existe si vous utilisez la valeur par défaut.

compression (par défaut : "zlib@openssh.com,zlib")

compression-level (par défaut : 3)

Les méthodes de compression au niveau SSH et le niveau de compression demandé.

Remarquez que le déchargement utilise la compression SSH pour réduire la bande passante utilisée lors du transfert vers et depuis les machines de construction.

daemon-socket (par défaut : "/var/guix/daemon-socket/socket")

Le nom de fichier du socket Unix-domain sur lequel guix-daemon écoute sur cette machine.

overload-threshold (par défaut : 0.6)

Le seuil de charge au-dessus duquel une machine de déchargement potentielle est ignorée par le programme de déchargement. Cette valeur se traduit approximativement par l’utilisation totale du processeur de la machine de construction, allant de 0,0 (0%) à 1,0 (100%). Elle peut également être désactivée en réglant overload-threshold sur #f.

parallel-builds (par défaut : 1)

Le nombre de constructions qui peuvent tourner simultanément sur la machine.

speed (par défaut : 1.0)

Un « facteur de vitesse relatif ». L’ordonnanceur des constructions tendra à préférer les machines avec un plus grand facteur de vitesse.

features (par défaut : '())

Une liste de chaînes qui contient les fonctionnalités spécifiques supportées par la machine. Un exemple est "kvm" pour les machines qui ont le module Linux KVM et le support matériel correspondant. Les dérivations peuvent demander des fonctionnalités par leur nom et seront orchestrées sur les machines de construction correspondantes.

La commande guix doit être dans le chemin de recherche des machines de construction. Vous pouvez vérifier si c’est le cas en lançant :

ssh build-machine guix repl --version

Il reste une dernière chose à faire maintenant que machines.scm est en place. Comme expliqué ci-dessus, lors du déchargement les fichiers sont transférés entre les dépôts des machines. Pour que cela fonctionne, vous devez d’abord générer une paire de clef sur chaque machine pour permettre au démon d’exporter des archives signées des fichiers de son dépôt (voir Invoquer guix archive) :

# guix archive --generate-key

Chaque machine de construction doit autoriser la clef de la machine maîtresse pour qu’ils acceptent les éléments de dépôt de celle-ci :

# guix archive --authorize < master-public-key.txt

De même, la machine maîtresse doit autoriser les clefs de chaque machine de construction.

Toute cette histoire de clefs permet d’exprimer la confiance mutuelle deux-à-deux entre le maître et les machines de construction. Concrètement, lorsque le maître reçoit des fichiers d’une machine de construction (et vice-versa), son démon de construction s’assure qu’ils sont authentiques, n’ont pas été modifiés par un tiers et qu’il sont signés par un clef autorisée.

Pour tester que votre paramétrage fonctionne, lancez cette commande sur le nœud maître :

# guix offload test

Cela essaiera de se connecter à toutes les machines de construction spécifiées dans /etc/guix/machines.scm, s’assurera que Guix est disponible sur toutes les machines et tentera d’exporter vers la machine et d’importer depuis elle, et rapportera toute erreur survenu pendant le processus.

Si vous souhaitez tester un fichier de machines différent, spécifiez-le sur la ligne de commande :

# guix offload test machines-qualif.scm

Enfin, vous pouvez tester un sous-ensemble de machines dont le nom correspond à une expression rationnelle comme ceci :

# guix offload test machines.scm '\.gnu\.org$'

Pour afficher la charge actuelle de tous les hôtes de construction, lancez cette commande sur le nœud principal :

# guix offload status

2.4.3 Support de SELinux

Guix inclus un fichier de politique SELinux dans etc/guix-daemon.cil qui peut être installé sur un système où SELinux est activé pour que les fichiers Guix soient étiquetés et pour spécifier le comportement attendu du démon. Comme Guix System ne fournit pas de politique SELinux de base, la politique du démon ne peut pas être utilisée sur le système Guix.

2.4.3.1 Installer la politique SELinux

Pour installer la politique, lancez cette commande en root :

semodule -i etc/guix-daemon.cil

Puis ré-étiquetez le système de fichier avec restorecon ou par un mécanisme différent fournit par votre système.

Une fois la politique installée, le système de fichier ré-étiqueté et le démon redémarré, il devrait être lancé dans le contexte guix_daemon_t. Vous pouvez le confirmer avec la commande suivante :

ps -Zax | grep guix-daemon

Surveillez les fichiers journaux de SELinux pendant que vous lancez une commande comme guix build hello pour vous convaincre que SELniux permet toutes les opérations nécessaires.

2.4.3.2 Limitations

La politique n’est pas parfaite. Voici une liste de limitations et de bizarreries qui vous devriez prendre en compte avant de déployer la politique SELinux fournie pour le démon Guix.

1. guix_daemon_socket_t n’est pas vraiment utilisé. Aucune des opérations sur les sockets n’impliquent de contextes qui ont quoi que ce soit à voir avec guix_daemon_socket_t. Ça ne fait pas de mal d’avoir une étiquette inutilisée, mais il serait préférable de définir des règles sur les sockets uniquement pour cette étiquette.
2. guix gc ne peut pas accéder à n’importe quel lien vers les profils. Par conception, l’étiquette de fichier de la destination d’un lien symbolique est indépendant de l’étiquette du lien lui-même. Bien que tous les profils sous $localstatedir aient une étiquette, les liens vers ces profils héritent de l’étiquette du répertoire dans lequel ils se trouvent. Pour les liens dans le répertoire personnel cela sera user_home_t. Mais pour les liens du répertoire personnel de root, ou /tmp, ou du répertoire de travail du serveur HTTP, etc, cela ne fonctionnera pas. SELinux empêcherait guix gc de lire et de suivre ces liens.
3. La fonctionnalité du démon d’écouter des connexions TCP pourrait ne plus fonctionner. Cela demande des règles supplémentaires car SELinux traite les sockets réseau différemment des fichiers.
4. Actuellement tous les fichiers qui correspondent à l’expression rationnelle /gnu/store/.+-(guix-.+|profile)/bin/guix-daemon reçoivent l’étiquette guix_daemon_exec_t ; cela signifie que tout fichier avec ce nom dans n’importe quel profil serait autorisé à se lancer dans le domaine guix_daemon_t. Ce n’est pas idéal. Un attaquant pourrait construire un paquet qui fournit cet exécutable et convaincre un·e utilisateur·rice de l’installer et de le lancer, ce qui l’élève dans le domaine guix_daemon_t. À ce moment SELinux ne pourrait pas l’empêcher d’accéder à des fichiers autorisés pour les processus de ce domaine.

   Vous devrez renommer le répertoire du dépôt après chaque mise à jour de guix-daemon, par exemple après avoir lancé guix pull. En supposant que le dépôt est dans /gnu, vous pouvez le faire avec restorecon -vR /gnu, ou par d’autres moyens fournis par votre système d’exploitation.

   Nous pourrions générer une politique bien plus restrictive à l’installation, pour que seuls les noms de fichiers exacts de l’exécutable guix-daemon actuellement installé soit étiqueté avec guix_daemon_exec_t, plutôt que d’utiliser une expression rationnelle plus large. L’inconvénient c’est que root devrait installer ou mettre à jour la politique à l’installation à chaque fois que le paquet Guix qui fournit l’exécutable guix-daemon effectivement exécuté est mis à jour.

2.5 Invoquer guix-daemon

Le programme guix-daemon implémente toutes les fonctionnalités d’accès au dépôt. Cela inclus le lancement des processus de construction, le lancement du ramasse-miettes, la demande de disponibilité des résultats de construction, etc. Il tourne normalement en root comme ceci :

# guix-daemon --build-users-group=guixbuild

Pour des détails sur son paramétrage, voir Paramétrer le démon.

Par défaut, guix-daemon lance les processus de construction sous différents UIDs récupérés depuis le groupe de construction spécifié avec --build-users-group. En plus, chaque processus de construction est lancé dans un environnement chroot qui ne contient que le sous-ensemble du dépôt dont le processus de construction dépend, tel que spécifié par sa dérivation (voir dérivation), plus un ensemble de répertoires systèmes spécifiques. Par défaut ce dernier contient /dev et /dev/pts. De plus, sous GNU/Linux, l’environnement de construction est un conteneur : en plus d’avoir sa propre arborescence du système de fichier, il a un espace de nom de montage séparé, son propre espace de nom PID, son espace de nom de réseau, etc. Cela aide à obtenir des constructions reproductibles (voir Fonctionnalités).

Lorsque le démon effectue une construction pour le compte de l’utilisateur·rice, il crée un répertoire de construction sous /tmp ou sous le répertoire spécifié par sa variable d’environnement TMPDIR. Ce répertoire est partagé avec le conteneur pendant toute la durée de la construction, bien que dans le conteneur, l’arbre de compilation soit toujours appelé /tmp/guix-build-name.drv-0.

Le répertoire de construction est automatiquement supprimé à la fin, à moins que la construction n’ait échoué et que le client ait spécifié --keep-failed (voir --keep-failed).

Le démon écoute les connexions et démarre un sous-processus pour chaque session démarrée par un client (l’une des sous-commandes de guix). La commande guix processes vous permet d’obtenir un aperçu de l’activité sur votre système en affichant chaque session et client actifs. Voir Invoquer guix processes pour plus d’informations.

Les options en ligne de commande suivantes sont disponibles :

--build-users-group=groupe

Utiliser les comptes du groupe pour lancer les processus de construction (voir comptes de construction).

--no-substitutes

Ne pas utiliser de substitut pour les résultats de la construction. C’est-à-dire, toujours construire localement plutôt que de permettre le téléchargement de binaires pré-construits (voir Substituts).

Lorsque le démon est lancé avec --no-substitutes, les clients peuvent toujours activer explicitement la substitution via l’appel de procédure distante set-build-options (voir Le dépôt).

--substitute-urls=urls

Considérer urls comme la liste séparée par des espaces des URL des sources de substituts par défaut. Lorsque cette option est omise, ‘https://ci.guix.gnu.org’ est utilisé.

Cela signifie que les substituts sont téléchargés depuis les urls, tant qu’ils sont signés par une signature de confiance (voir Substituts).

Voir Récupérer des substituts d'autres serveurs, pour plus d’information sur la configuration du démon pour récupérer des substituts d’autres serveurs.

--no-offload

N’essaye pas de décharger les constructions vers d’autres machines (voir Réglages du délestage du démon). C’est-à-dire que tout sera construit localement au lieu de décharger les constructions à une machine distante.

--cache-failures

Mettre les échecs de construction en cache. Par défaut, seules les constructions réussies sont mises en cache.

Lorsque cette option est utilisée, guix gc --list-failures peut être utilisé pour demander l’ensemble des éléments du dépôt marqués comme échoués ; guix gc --clear-failures vide la liste des éléments aillant échoué. Voir Invoquer guix gc.

--cores=n

-c n

Utiliser n cœurs CPU pour construire chaque dérivation ; 0 signifie autant que possible.

La valeur par défaut est 0, mais elle peut être annulée par les clients, comme avec l’option --cores de guix build (voir Invoquer guix build).

L’effet est de définir la variable d’environnement NIX_BUILD_CORES dans le processus de construction, qui peut ensuite l’utiliser pour exploiter le parallélisme en interne — par exemple en lançant make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Permettre au plus n travaux de construction en parallèle. La valeur par défaut est 1. La mettre à 0 signifie qu’aucune construction ne sera effectuée localement ; à la place, le démon déchargera les constructions (voir Réglages du délestage du démon) ou échouera.

--max-silent-time=secondes

Lorsque le processus de construction ou de substitution restent silencieux pendant plus de secondes, le terminer et rapporter une erreur de construction.

La valeur par défaut est 0, ce qui désactive le délai.

La valeur spécifiée ici peut être annulée par les clients (voir --max-silent-time).

--timeout=secondes

De même, lorsque le processus de construction ou de substitution dure plus de secondes, le terminer et rapporter une erreur de construction.

La valeur par défaut est 0, ce qui désactive le délai.

La valeur spécifiée ici peut être annulée par les clients (voir --timeout).

--rounds=N

Construire chaque dérivations N fois à la suite, et lever une erreur si les résultats de construction consécutifs ne sont pas identiques bit-à-bit. Remarquez que ce paramètre peut être modifié par les clients comme guix build (voir Invoquer guix build).

Lorsqu’utilisé avec --keep-failed, la sortie différente est gardée dans le dépôt sous /gnu/store/…-check. Cela rend plus facile l’étude des différences entre les deux résultats.

--debug

Produire une sortie de débogage.

Cela est utile pour déboguer des problèmes de démarrage du démon, mais ensuite elle peut être annulée par les clients, par exemple par l’option --verbosity de guix build (voir Invoquer guix build).

--chroot-directory=rép

Ajouter rép au chroot de construction.

Cela peut changer le résultat d’un processus de construction — par exemple s’il utilise une dépendance facultative trouvée dans rép lorsqu’elle est disponible ou pas sinon. Pour cette raison, il n’est pas recommandé d’utiliser cette option. À la place, assurez-vous que chaque dérivation déclare toutes les entrées dont elle a besoin.

--disable-chroot

Désactive les constructions dans un chroot.

Utiliser cette option n’est pas recommandé car, de nouveau, elle permet aux processus de construction d’accéder à des dépendances non déclarées. Elle est nécessaire cependant lorsque guix-daemon tourne sans privilèges.

--log-compression=type

Compresser les journaux de construction suivant le type, parmi gzip, bzip2 ou none.

À moins que --lose-logs ne soit utilisé, tous les journaux de construction sont gardés dans localstatedir. Pour gagner de la place, le démon les compresse automatiquement avec bzip2 par défaut.

--discover[=yes|no]

Indique s’il faut découvrir les serveurs de substitut sur le réseau local avec mDNS et DNS-SD.

Cette fonction est encore expérimentale. Cependant, voici quelques réflexions sur le sujet.

1. Cela peut être plus rapide ou moins cher que la récupération depuis des serveurs distants ;
2. Il n’y a pas de risque de sécurité, seuls des substituts authentiques seront utilisés (voir Authentification des substituts) ;
3. Un·e attaquant·e qui publierait guix publish sur votre LAN ne peut pas vous proposer de binaire malveillants, mais il ou elle pourrait apprendre quels logiciels vous installez ;
4. Les serveurs peuvent servir des substituts en HTTP, sans chiffrement, donc n’importe qui sur votre LAN peut voir quels logiciels vous installez.

Il est aussi possible d’activer ou de désactiver la découverte de serveurs de substituts à l’exécution en lançant :

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication

Désactiver la « déduplication » automatique des fichiers dans le dépôt.

Par défaut, les fichiers ajoutés au dépôt sont automatiquement « dédupliqués » : si un nouveau fichier est identique à un autre fichier trouvé dans le dépôt, le démon en fait un lien en dur vers l’autre fichier. Cela réduit considérablement l’utilisation de l’espace disque au prix d’une charge en entrée/sortie plus grande à la fin d’un processus de construction. Cette option désactive cette optimisation.

--gc-keep-outputs[=yes|no]

Dire si le ramasse-miettes (GC) doit garder les sorties des dérivations utilisées.

Lorsqu’il est réglé sur yes, le GC conservera les sorties de toute dérivation active disponibles dans le dépôt—les fichiers .drv. La valeur par défaut est no, ce qui signifie que les sorties des dérivations ne sont conservées que si elles sont accessibles à partir d’une racine GC. Voir Invoquer guix gc, pour en savoir plus sur les racines GC.

--gc-keep-derivations[=yes|no]

Dire si le ramasse-miettes (GC) doit garder les dérivations correspondant à des sorties utilisées.

Lorsqu’il est réglé à « yes », comme c’est le cas par défaut, le GC garde les dérivations — c.-à-d. les fichiers .drv — tant qu’au moins une de leurs sorties est utilisée. Cela permet de garder une trace de l’origine des éléments du dépôt. Le mettre à no préserve un peu d’espace disque.

De cette manière, le réglage de l’option --gc-keep-derivations sur yes étend le résultat des sorties aux dérivations, et le réglage de l’option --gc-keep-outputs sur yes étend le résultat des dérivations aux sorties. Lorsque les deux sont réglés sur yes, l’effet est de conserver tous les prérequis de construction (les sources, le compilateur, les bibliothèques et autres outils de construction) des objets actifs dans le dépôt, que ces prérequis soient accessibles ou non depuis une racine GC. Cela est pratique pour les développeurs car cela permet d’éviter les reconstructions ou les téléchargements.

--impersonate-linux-2.6

Sur les systèmes basés sur Linux, imiter Linux 2.6. Cela signifie que l’appel système uname du noyau indiquera 2.6 comme numéro de version.

Cela peut être utile pour construire des programmes qui dépendent (généralement sans fondement) du numéro de version du noyau.

--lose-logs

Ne pas garder les journaux de construction. Par défaut ils sont gardés dans localstatedir/guix/log.

--system=système

Supposer que système est le type de système actuel. Par défaut c’est la paire architecture-noyau trouvée à la configuration, comme x86_64-linux.

--listen=extrémité

Écouter les connexions sur extrémité. extrémité est interprété comme un nom de fichier d’un socket Unix-domain s’il commence par / (barre oblique). Sinon, extrémité est interprété comme un nom de domaine ou d’hôte et un port sur lequel écouter. Voici quelques exemples :

--listen=/gnu/var/daemon

Écouter les connexions sur le socket Unix-domain /gnu/var/daemon en le créant si besoin.

--listen=localhost

Écouter les connexions TCP sur l’interface réseau correspondant à localhost sur le port 44146.

--listen=128.0.0.42:1234

Écouter les connexions TCP sur l’interface réseau correspondant à 128.0.0.42 sur le port 1234.

Cette option peut être répétée plusieurs fois, auquel cas guix-daemon accepte des connexions sur tous les paramètres spécifiés. On peut indiquer aux commandes clientes à quoi se connecter en paramétrant la variable d’environnement GUIX_DAEMON_SOCKET (voir GUIX_DAEMON_SOCKET).

Remarque : Le protocole du démon est non authentifié et non chiffré. Utiliser --listen=host est adapté sur des réseaux locaux, comme pour des grappes de serveurs, où seuls des nœuds de confiance peuvent se connecter au démon de construction. Dans les autres cas où l’accès à distance au démon est requis, nous conseillons d’utiliser un socket Unix-domain avec SSH.

Lorsque --listen est omis, guix-daemon écoute les connexions sur le socket Unix-domain situé à localstatedir/guix/daemon-socket/socket.

2.6 Réglages applicatifs

Lorsque vous utilisez Guix par dessus une distribution GNU/Linux qui n’est pas Guix System — ce qu’on appelle une distro externe — quelques étapes supplémentaires sont requises pour que tout soit en place. En voici certaines.

2.6.1 Régionalisation

Les paquets installés via Guix n’utiliseront pas les données de régionalisation du système hôte. À la place, vous devrez d’abord installer l’un des paquets linguistiques disponibles dans Guix puis définir la variable d’environnement GUIX_LOCPATH :

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

Remarquez que le paquet glibc-locales contient les données pour tous les environnement linguistiques supportés par la GNU libc et pèse environ 917 Mo. Autrement, les glibc-utf8-locales est plus petit mais limité à quelques environnements UTF-8.

La variable GUIX_LOCPATH joue un rôle similaire à LOCPATH (voir LOCPATH dans The GNU C Library Reference Manual). Il y a deux différences importantes cependant :

1. GUIX_LOCPATH n’est compris que par la libc dans Guix et pas par la libc fournie par les distros externes. Ainsi, utiliser GUIX_LOCPATH vous permet de vous assurer que les programmes de la distro externe ne chargeront pas de données linguistiques incompatibles.
2. la libc ajoute un suffixe /X.Y à chaque entrée de GUIX_LOCPATH, où X.Y est la version de la libc — p. ex. 2.22. Cela signifie que, si votre profile Guix contient un mélange de programmes liés avec des versions différentes de la libc, chaque version de la libc essaiera de charger les environnements linguistiques dans le bon format.

Cela est important car le format des données linguistiques utilisés par différentes version de la libc peuvent être incompatibles.

2.6.2 Name Service Switch

Lorsque vous utilisez Guix sur une distro externe, nous recommandons fortement que ce système fasse tourner le démon de cache de service de noms de la bibliothèque C de GNU, nscd, qui devrait écouter sur le socket /var/run/nscd/socket. Sans cela, les applications installées avec Guix peuvent échouer à résoudre des noms d’hôtes ou de comptes, ou même planter. Les paragraphes suivants expliquent pourquoi.

La bibliothèque C de GNU implémente un name service switch (NSS), qui est un mécanisme d’extension pour les « résolutions de noms » en général : résolution de nom d’hôte, de compte utilisateur·rice et plus (voir Name Service Switch dans The GNU C Library Reference Manual).

Comme il est extensible, NSS supporte des greffons qui fournissent une nouvelle implémentation de résolution de nom : par exemple le greffon nss-mdns permet la résolution de noms d’hôtes en .local, le greffon nis permet la résolution de comptes avec le Network Information Service (NIS), etc. Ces « services de recherches » supplémentaires sont configurés au niveau du système dans /etc/nsswitch.conf, et tous les programmes qui tournent sur ce système honorent ces paramètres (voir NSS Configuration File dans The GNU C Reference Manual).

Lorsqu’ils essayent d’effectuer une résolution de nom — par exemple en appelant la fonction getaddrinfo en C — les applications essayent d’abord de se connecter au nscd ; en cas de réussite, nscd effectue la résolution de nom pour eux. Si le nscd ne tourne pas, alors ils effectuent la résolution eux-mêmes, en changeant les service de résolution dans leur propre espace d’adressage et en le lançant. Ce services de résolution de noms — les fichiers libnns_*.so — sont dlopenés mais ils peuvent provenir de la bibliothèque C du système, plutôt que de la bibliothèque C à laquelle l’application est liée (la bibliothèque C de Guix).

Et c’est là que se trouve le problème : si votre application est liée à la bibliothèque C de Guix (disons, glibc-2.24) et essaye de charger les greffons NSS d’une autre bibliothèque C (disons, libnss_mdns.so pour glibc-2.22), il est très probable qu’elle plante ou que sa résolution de nom échoue de manière inattendue.

Lancer nscd sur le système, entre autres avantages, élimine ce problème d’incompatibilité binaire car ces fichiers libnss_*.so sont chargés par le processus nscd, pas par l’application elle-même.

2.6.3 Polices X11

La majorité des applications graphiques utilisent fontconfig pour trouver et charger les polices et effectuer le rendu côté client X11. Le paquet fontconfig dans Guix cherche les polices dans $HOME/.guix-profile par défaut. Ainsi, pour permettre aux applications graphiques installées avec Guix d’afficher des polices, vous devez aussi installer des polices avec Guix. Les paquets de polices essentiels sont gs-fonts, font-dejavu et font-gnu-freefont-ttf.

Lorsque vous installez ou supprimez des polices, ou lorsque vous remarquez qu’une application ne trouve pas les polices, vous pouvez avoir besoin d’installer Fontconfig et de forcer un rafraîchissement de son cache de police avec :

guix install fontconfig
fc-cache -rv

Pour afficher des textes écrits en chinois, en japonais ou en coréen dans les applications graphiques, installez font-adobe-source-han-sans ou font-wqy-zenhei. Le premier a plusieurs sorties, une par famille de langue (voir Des paquets avec plusieurs résultats). Par exemple, la commande suivante installe les polices pour le chinois :

guix install font-adobe-source-han-sans:cn

Les vieux programmes comme xterm n’utilisent pas fontconfig et s’appuient sur le rendu du côté du serveur. Ces programmes ont besoin de spécifier le nom complet de la police en utilisant XLFD (X Logical Font Description), comme ceci :

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

Pour pouvoir utiliser ces noms complets avec les polices TrueType installées dans votre profil Guix, vous devez étendre le chemin des polices du serveur X :

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

Ensuite, vous pouvez lancer xlsfonts (du paquet xlsfonts) pour vous assurer que vos polices TrueType y sont listées.

2.6.4 Certificats X.509

Le paquet nss-certs fournit les certificats X.509 qui permettent aux programmes d’authentifier les serveurs web par HTTPS.

Lorsque vous utilisez Guix sur une distribution externe, vous pouvez installer ce paquet et définir les variables d’environnement adéquates pour que les paquets sachent où trouver les certificats. Voir Certificats X.509, pour des informations détaillées.

2.6.5 Paquets emacs

Quand vous installez des paquets Emacs avec Guix, les fichiers Elips sont placés dans le répertoire share/emacs/site-lisp/ du profil dans lequel ils sont installés. Les bibliothèques Elisp sont rendues disponibles dans Emacs avec la variable d’environnement EMACSLOADPATH, qui est initialisée à l’installation d’Emacs lui-même.

En plus, des définitions autoload sont automatiquement évaluées au démarrage d’Emacs, par la procédure guix-emacs-autoload-packages de Guix. Si, pour quelque raison que ce soit, vous souhaitez éviter de charger automatiquement les paquets Emacs installés avec Guix, vous pouvez le faire en lançant Emacs avec l’option --no-site-file (voir Init File dans The GNU Emacs Manual).

2.7 Mettre à niveau Guix

Pour mettre Guix à niveau, lancez :

guix pull

Voir Invoquer guix pull, pour plus d’informations.

Sur une distribution externe, vous pouvez mettre à jour le démon de construction en lançant :

sudo -i guix pull

suivi de (dans le cas où votre distribution utilise l’outil de gestion de services Systemd) :

systemctl restart guix-daemon.service

Sur Guix System, la mise à jour du démon est effectuée par la reconfiguration du système (voir guix system reconfigure).

3 Installation du système

Cette section explique comment installer Guix System sur une machine. Guix, en tant que gestionnaire de paquets, peut aussi être installé sur un système GNU/Linux déjà installé, voir Installation.

3.1 Limitations

Nous considérons Guix System comme prêt pour une grande variété de cas d’utilisation pour le « bureau » et le serveur. Les garantis de fiabilité qu’il fournit — les mises à jour transactionnelles, les retours en arrières et la reproductibilité — en font une solide fondation.

Néanmoins, avant de procéder à l’installation, soyez conscient de ces limitations les plus importantes qui s’appliquent à la version 1.3.0 :

• De plus en plus de services systèmes sont fournis (voir Services) mais certains manquent toujours cruellement.
• GNOME, Xfce, LXDE et Enlightenment sont disponibles (voir Services de bureaux), ainsi qu’un certain nombre de gestionnaires de fenêtres X11. Cependant, il manque actuellement KDE.

Plus qu’un avertissement, c’est une invitation à rapporter les problèmes (et vos succès !) et à nous rejoindre pour améliorer la distribution. Voir Contribuer, pour plus d’info.

3.2 Considérations matérielles

GNU Guix se concentre sur le respect des libertés de ses utilisateurs et utilisatrices. Il est construit autour du noyau Linux-libre, ce qui signifie que seuls les matériels pour lesquels des pilotes logiciels et des microgiciels libres sont disponibles sont pris en charge. De nos jours, une grande gamme de matériel qu’on peut acheter est prise en charge par GNU/Linux-libre — des claviers aux cartes graphiques en passant par les scanners et les contrôleurs Ethernet. Malheureusement, il reste des produits dont les fabricants refusent de laisser le contrôle aux utilisateur·rice·s sur leur propre utilisation de l’ordinateur, et ces matériels ne sont pas pris en charge par Guix System.

L’un des types de matériels où les pilotes ou les microgiciels sont le moins disponibles sont les appareils WiFi. Les appareils WiFi connus pour fonctionner sont ceux qui utilisent des puces Atheros (AR9271 et AR7010) qui correspondent au pilote ath9k de Linux-libre, et ceux qui utilisent des puces Broadcom/AirForce (BCM43xx avec la révision Wireless-Core 5), qui correspondent au pilote b43-open de Linux-libre. Des microgiciels libres existent pour les deux et sont disponibles directement sur Guix System, dans %base-firmware (voir firmware).

La Free Software Foundation a un programme de certification nommé Respects Your Freedom (RYF), pour les produits matériels qui respectent votre liberté et votre vie privée en s’assurant que vous avez le contrôle sur l’appareil. Nous vous encourageons à vérifier la liste des appareils certifiés par RYF.

Une autre ressource utile est le site web H-Node. Il contient un catalogue d’appareils avec des informations sur leur support dans GNU/Linux.

3.3 Installation depuis une clef USB ou un DVD

Une image d’installation ISO-9660 qui peut être écrite sur une clé USB ou être gravée sur un DVD est téléchargeable à partir de ‘https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso’, où vous pouvez remplacer x86_64-linux par l’un des éléments suivants :

x86_64-linux

pour un système GNU/Linux sur un CPU compatible Intel/AMD 64-bits ;

i686-linux

pour un système GNU/Linux sur un CPU compatible Intel 32-bits.

Assurez-vous de télécharger les fichiers .sig associés et de vérifier l’authenticité de l’image avec, de cette manière :

$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig

Si cette commande échoue parce que vous n’avez pas la clef publique requise, lancez cette commande pour l’importer :

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=127547 \
      -qO - | gpg --import -

et relancez la commande gpg --verify.

Remarquez qu’un avertissement du type « Cette clef n’est pas certifiée par une signature de confiance ! » est normal.

Cette image contient les outils nécessaires à l’installation. Elle est faite pour être copiée telle quelle sur une clef USB assez grosse ou un DVD.

Copie sur une clef USB

Insérez la clef USB de 1 Gio ou plus dans votre machine et déterminez son nom d’appareil. En supposant que la clef usb est connue sous le nom de /dev/sdX, copiez l’image avec :

dd if=guix-system-install-1.3.0.x86_64-linux.iso of=/dev/sdX status=progress
sync

Accéder à /dev/sdX requiert généralement les privilèges d’administration.

Graver sur un DVD

Insérez un DVD vierge dans votre machine et déterminez son nom d’appareil. En supposant que le DVD soit connu sont le nom de /dev/srX, copiez l’image avec :

growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.3.0.x86_64-linux.iso

Accéder à /dev/srX requiert généralement les privilèges root.

Démarrage

Une fois que c’est fait, vous devriez pouvoir redémarrer le système et démarrer depuis la clé USB ou le DVD. Pour cela, vous devrez généralement entrer dans le menu de démarrage BIOS ou UEFI, où vous pourrez choisir de démarrer sur la clé USB. Pour démarrer depuis Libreboot, passez en mode de commande en appuyant sur la touche c et en tapant search grub usb.

Voir Installer Guix dans une VM, si, à la place, vous souhaitez installer Guix System dans une machine virtuelle (VM).

3.4 Préparer l’installation

Une fois que vous avez démarré, vous pouvez utiliser l’installateur graphique, qui rend facile la prise en main (voir Installation graphique guidée). Sinon, si vous êtes déjà familier avec GNU/Linux et que vous voulez plus de contrôle que ce que l’installateur graphique propose, vous pouvez choisir le processus d’installation « manuel » (voir Installation manuelle).

L’installateur graphique est disponible sur le TTY1. Vous pouvez obtenir des shells root sur les TTY 3 à 6 en tapant ctrl-alt-f3, ctrl-alt-f4 etc. Le TTY2 affiche cette documentation que vous pouvez atteindre avec ctrl-alt-f2. On peut naviguer dans la documentation avec les commandes du lecteur Info (voir Stand-alone GNU Info). Le démon de souris GPM tourne sur le système d’installation, ce qui vous permet de sélectionner du texte avec le bouton gauche de la souris et de le coller en appuyant sur la molette.

Remarque : L’installation nécessite un accès au réseau pour que les dépendances manquantes de votre configuration système puissent être téléchargées. Voyez la section « réseau » plus bas.

3.5 Installation graphique guidée

L’installateur graphique est une interface utilisateur en mode texte. Il vous guidera, avec des boîtes de dialogue, le long des étapes requises pour installer GNU Guix System.

La première boîte de dialogue vous permet de paramétrer le système comme vous le souhaitez pendant l’installation : vous pouvez choisir la langue, la disposition du clavier et paramétrer le réseau, qui sera utilisé pendant l’installation. L’image ci-dessous montre le dialogue pour le réseau.

Les étapes suivantes vous permettent de partitionner votre disque dur, comme le montre l’image ci-dessous, de choisir si vous voulez ou non utiliser des systèmes de fichiers chiffrés, de saisir le nom d’hôte et le mot de passe root et de créer un compte supplémentaire, entre autres choses.

Remarquez que, à tout moment, l’installateur vous permet de sortir de l’étape d’installation actuelle et de recommencer une étape précédente, comme le montre l’image ci-dessous.

Une fois que vous avez fini, l’installateur produit une configuration de système d’exploitation et vous la montre (voir Utiliser le système de configuration). À ce moment, vous pouvez appuyer sur « OK » et l’installation continuera. Lorsqu’elle aura réussi, vous pourrez redémarrer sur le nouveau système et vous amuser. Voir Après l'installation du système, pour la suite des festivités !

3.6 Installation manuelle

Cette section décrit comme vous pourriez installe « manuellement » GNU Guix System sur votre machine. Cette option nécessite que vous soyez familier avec GNU/Linux, le shell et avec les outils d’administration usuels. Si vous pensez que ce n’est pas pour vous, pensez à utiliser l’installateur graphique (voir Installation graphique guidée).

Le système d’installation fournit des shells root sur les TTY 3 à 6 ; appuyez sur ctrl-alt-f3, ctrl-alt-f4 etc pour y accéder. Il inclus plusieurs outils usuels pour requis pour cette tâche. Mais c’est aussi un système Guix complet, ce qui signifie que vous pouvez installer des paquets supplémentaires si vous en avez besoin, avec guix package (voir Invoquer guix package).

3.6.1 Disposition du clavier réseau et partitionnement

Avant que vous ne puissiez installer le système, vous voudrez sans doute ajuster la disposition du clavier, paramétrer le réseau et partitionner le disque dur cible. Cette section vous guidera à travers tout cela.

3.6.1.1 Disposition du clavier

L’image d’installation utilise la disposition clavier qwerty (US). Si vous voulez la changer, vous pouvez utiliser la commande loadkeys. Par exemple, la commande suivante sélectionne la disposition Dvorak :

loadkeys dvorak

Consultez les fichiers dans /run/current-system/profile/share/keymaps pour trouver une liste des dispositions disponibles. Lancez man loadkey pour plus d’informations.

3.6.1.2 Réseau

Lancez la commande suivante pour voir comment vos interfaces réseau sont appelées :

ifconfig -a

… ou, avec la commande spécifique à GNU/Linux ip :

ip address

Les interfaces filaires ont un nom qui commence par ‘e’ ; par exemple, l’interface qui correspond au premier contrôleur Ethernet sur la carte mère est appelé ‘eno1’. Les interfaces sans-fil ont un nom qui commence par ‘w’, comme ‘w1p2s0’.

Connexion filaire

Pour configure une connexion filaire, lancez la commande suivante, en remplaçant interface par le nom de l’interface filaire que vous voulez utiliser.

ifconfig interface up

… ou, avec la commande spécifique à GNU/Linux ip :

ip link set interface up

Connexion sans-fil

Pour configurer le réseau sans-fil, vous pouvez créer un fichier de configuration pour l’outil de configuration wpa_supplicant (son emplacement importe peu) avec l’un des éditeurs de texte disponibles comme nano :

nano wpa_supplicant.conf

Par exemple, la déclaration qui suit peut aller dans ce fichier et fonctionnera pour plusieurs réseaux sans-fil, si vous donnez le vrai SSID et la phrase de passe pour le réseau auquel vous vous connectez :

network={
  ssid="mon-ssid"
  key_mgmt=WPA-PSK
  psk="la phrase de passe secrète du réseau"
}

Démarrez le service sans-fil et lancez-le en tache de fond avec la commande suivante (en remplaçant interface par le nom de l’interface réseau que vous voulez utiliser) :

wpa_supplicant -c wpa_supplicant.conf -i interface -B

Lancez man wpa_supplicant pour plus d’informations.

À partir de ce moment, vous avez besoin d’une adresse IP. Sur les réseaux où les IP sont automatiquement attribuée par DHCP, vous pouvez lancer :

dhclient -v interface

Essayez de pinger un serveur pour voir si le réseau fonctionne :

ping -c 3 gnu.org

Mettre en place un accès réseau est presque toujours une nécessité parce que l’image ne contient pas tous les logiciels et les outils dont vous pourriez avoir besoin.

Si vous avez besoin d’un accès HTTP et HTTPS pour passer à travers un proxy, lancez la commande suivante :

herd set-http-proxy guix-daemon URL

où URL est l’URL du proxy, par exemple http://example.org:8118.

Si vous le souhaitez, vous pouvez continuer l’installation à distance en démarrant un serveur SSH :

herd start ssh-daemon

Assurez-vous soit de définir un mot de passe avec passwd, soit de configurer l’authentification par clef OpenSSH avant de vous connecter.

3.6.1.3 Partitionnement

À moins que vous ne l’ayez déjà fait, l’étape suivante consiste à partitionner le disque puis à formater les partitions cibles.

L’image d’installation inclus plusieurs outils de partitionnement, dont Parted (voir Overview dans GNU Parted User Manual), fdisk, et cfdisk. Lancez-en un et paramétrez votre disque avec le partitionnement qui vous convient :

cfdisk

Si votre disque utilise le format des tables de partitions GUID (GPT) et que vous souhaitez installer un GRUB pour système BIOS (c’est le cas par défaut), assurez-vous de créer qu’une partition de démarrage BIOS soit bien disponible (voir BIOS installation dans GNU GRUB manual).

Si vous souhaitez à la place utilise GRUB pour système EFI, vous devrez avoir une partition système EFI (ESP) en FAT32. Cette partition peut être montée dans /boot/efi par exemple et doit avoir le drapeau esp. P. ex. pour parted :

parted /dev/sda set 1 esp on

Remarque : Vous n’êtes pas sûr de savoir si vous devez utiliser un GRUB EFI ou BIOS ? Si le répertoire /sys/firmware/efi existe sur l’image d’installation, vous devriez probablement effectuer une installation EFI, avec grub-efi-bootloader. Sinon, vous devriez utiliser le GRUB en BIOS, grub-bootloader. Voir Configuration du chargeur d'amorçage pour plus d’information sur le chargeur d’amorçage.

Une fois que vous avez fini le partitionnement du disque dur cible, vous devez créer un système de fichier sur les partitions⁸. Pour l’ESP, si vous en avez une et en supposant que ce soit /dev/sda1, lancez :

mkfs.fat -F32 /dev/sda1

Concernant le système de fichier root, ext4 est le format le plus largement utilisé. D’autres systèmes de fichiers, comme Btrfs, supportent la compression, laquelle est reportée pour compléter agréablement la dédupplication que le démon réalise indépendamment du système de fichier (voir deduplication).

Préférez assigner une étiquette au système de fichier pour que vous puissiez vous y référer de manière fiable dans la déclaration file-system (voir Systèmes de fichiers). On le fait habituellement avec l’option -L de mkfs.ext4 et des commandes liées. Donc, en supposant que la partition racine soit sur /dev/sda2, on peut créer un système de fichier avec pour étiquette my-root avec :

mkfs.ext4 -L my-root /dev/sda2

Si vous voulez plutôt chiffrer la partition root, vous pouvez utiliser les utilitaires Cryptsetup et LUKS pour celà (voir man cryptsetup pour plus d’informations). En supposant que vous voulez stocker la partition root sur /dev/sda2, la séquence de commandes suivante vous mènerait à ce résultat :

cryptsetup luksFormat /dev/sda2
cryptsetup open --type luks /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

Une fois cela effectué, montez le système de fichier cible dans /mnt avec une commande comme (de nouveau, en supposant que my-root est l’étiquette du système de fichiers racine) :

mount LABEL=my-root /mnt

Montez aussi tous les systèmes de fichiers que vous voudriez utiliser sur le système cible relativement à ce chemin. Si vous avez choisi d’avoir un /boot/efi comme point de montage EFI par exemple, montez-la sur /mnt/boot/efi maintenant pour qu’elle puisse être trouvée par guix system init ensuite.

Enfin, si vous souhaitez utiliser une ou plusieurs partitions de swap (voir swap space dans The GNU C Library Reference Manual), assurez-vous de les initialiser avec mkswap. En supposant que vous avez une partition de swap sur /dev/sda3, vous pouvez lancer :

mkswap /dev/sda3
swapon /dev/sda3

Autrement, vous pouvez utiliser un fichier de swap. Par exemple, en supposant que dans le nouveau système vous voulez utiliser le fichier /swapfile comme fichier de swap, vous lanceriez⁹ :

# Cela représente 10 Gio d'espace d'échange. Ajustez « count » pour changer la taille.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# Par sécurité, laissez le fichier en lecture et en écriture uniquement pour root.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

Remarquez que si vous avez chiffré la partition racine et créé un fichier d’échange dans son système de fichier comme décrit ci-dessus, alors le chiffrement protégera aussi le fichier d’échange, comme n’importe quel fichier de ce système de fichiers.

3.6.2 Effectuer l’installation

Lorsque la partition cible est prête et que les autres partitions sont montées, on est prêt à commencer l’installation. Commencez par :

herd start cow-store /mnt

Cela rend /gnu/store capable de faire de la copie sur écriture, de sorte que les paquets ajoutés pendant l’installation sont écrits sur le disque cible sur /mnt plutôt que gardés en mémoire. Cela est nécessaire parce que la première phase de la commande guix system init (voir plus bas) implique de télécharger ou de construire des éléments de /gnu/store qui est initialement un système de fichiers en mémoire.

Ensuite, vous devrez modifier un fichier et fournir la déclaration du système à installer. Pour cela, le système d’installation propose trois éditeurs de texte. Nous recommandons GNU nano (voir GNU nano Manual), qui supporte la coloration syntaxique la correspondance de parenthèses ; les autres éditeurs sont GNU Zile (un clone d’Emacs) et nvi (un clone de l’éditeur vi original de BSD). Nous recommandons vivement de stocker ce fichier sur le système de fichier racine cible, disons en tant que /mnt/etc/config.scm. Sinon, vous perdrez votre fichier de configuration une fois que vous aurez redémarré sur votre nouveau système.

Voir Utiliser le système de configuration, pour un aperçu de comment créer votre fichier de configuration. Les exemples de configuration dont on parle dans cette section sont disponibles dans /etc/configuration sur l’image d’installation. Ainsi, pour commencer avec une configuration du système qui fournit un serveur d’affichage graphique (un système de « bureau »), vous pouvez lancer ce qui suit :

# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm

Vous devriez faire attention à ce que contient votre fichier de configuration, en particulier :

• Assurez-vous que la forme bootloader-configuration se réfère à la cible où vous voulez installer GRUB. Elle devrait aussi mentionner grub-bootloader si vous installer GRUB en mode BIOS (ou « legacy ») ou grub-efi-bootloader pour les système UEFI plus récents. Pour les anciens systèmes, le champs target contient un périphérique comme /dev/sda ; pour les systèmes UEFI il contient un chemin vers une partition EFI montée, comme /boot/efi, et assurez-vous bien que ce chemin est monté et qu’il y a une entrée file-system dans votre configuration.
• Assurez-vous que les étiquettes de vos systèmes de fichiers correspondent aux valeurs de leur champs device dans votre configuration file-system, en supposant que la configuration file-system utilise la procédure file-system-label dans son champ device.
• Si vous avez des partitions RAID ou chiffrées, assurez-vous d’ajouter un champ mapped-device pour les décrire (voir Périphériques mappés).

Une fois que vous avez fini les préparatifs sur le fichier de configuration, le nouveau système peut être initialisé (rappelez-vous que le système de fichiers racine cible est dans /mnt) :

guix system init /mnt/etc/config.scm /mnt

Cela copie tous les fichiers nécessaires et installe GRUB sur /dev/sdX à moins que vous ne passiez l’option --no-bootloader. Pour plus d’informations, voir Invoquer guix system. Cette commande peut engendrer des téléchargements ou des constructions pour les paquets manquants, ce qui peut prendre du temps.

Une fois que cette commande a terminé — et on l’espère réussi ! — vous pouvez lancer reboot et démarrer sur votre nouveau système. Le mot de passe root est d’abord vide ; les mots de passe des autres comptes doivent être initialisés avec la commande passwd en tant que root, à mois que votre configuration ne spécifie autre chose (voir mot de passe des comptes). Voir Après l'installation du système, pour la suite !

3.7 Après l’installation du système

Bravo ! Vous avez maintenant redémarré sur votre système Guix ! À partir de maintenant, vous pouvez mettre à jour le système quand vous voudrez, avec :

guix pull
sudo guix system reconfigure /etc/config.scm

Cela crée une nouvelle génération du système avec les derniers paquets et services (voir Invoquer guix system). Nous vous recommandons de le faire régulièrement pour que votre système inclue les dernières misse à jour de sécurité (voir Mises à jour de sécurité).

Remarque : Remarquez que sudo guix exécute la commande guix de votre compte et non celle de root, parce que sudo ne change pas PATH. Pour utiliser explicitement le guix de root, tapez sudo -i guix ….

La différence est importante ici, car guix pull met à jour la commande guix et les définitions de paquets uniquement pour l’utilisateur sous lequel elle est exécutée. Cela signifie que si vous choisissez d’utiliser la commande guix system reconfigure dans le shell de connexion de root, vous devrez utiliser séparément la commande guix pull.

Maintenant, voir Pour démarrer, et rejoignez-nous sur #guix sur le réseau IRC Libera Chat ou sur guix-devel@gnu.org pour partager votre expérience !

3.8 Installer Guix sur une machine virtuelle

Si vous souhaitez installer Guix System sur une machine virtuelle (VM) ou un serveur privé virtuel (VPS) plutôt que sur votre machine chérie, cette section est faite pour vous.

Pour démarrer une VM QEMU pour installer Guix System sur une image disque, suivez ces étapes :

1. Tout d’abord récupérez et décompressez l’image d’installation du système Guix comme décrit précédemment (voir Installation depuis une clef USB ou un DVD).
2. Créez une image disque qui contiendra le système installé. Pour créer une image qcow2, utilise la commande qemu-img :

   qemu-img create -f qcow2 guix-system.img 50G
   

   Le fichier qui en résulte sera bien plus petit que les 50 Go (habituellement moins de 1 Mo) mais il grossira au fur et à mesure que le stockage virtuel grossira.

3. Démarrez l’image d’installation USB dans une VM :

   qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
     -nic user,model=virtio-net-pci -boot menu=on,order=d \
     -drive file=guix-system.img \
     -drive media=cdrom,file=guix-system-install-1.3.0.système.iso
   

   -enable-kvm est facultatif, mais améliore nettement les performances, voir Lancer Guix dans une VM.

4. Vous êtes maintenant root dans la VM, continuez en suivant la procédure d’installation. Voir Préparer l'installation, et suivez les instructions.

Une fois l’installation terminée, vous pouvez démarrer le système dans votre image guix-system.img. Voir Lancer Guix dans une VM, pour une manière de faire.

3.9 Construire l’image d’installation

L’image d’installation décrite plus haut a été construite avec la commande guix system, plus précisément :

guix system image -t iso9660 gnu/system/install.scm

Regardez le fichier gnu/system/install.scm dans l’arborescence des sources et regardez aussi Invoquer guix system pour plus d’informations sur l’image d’installation.

3.10 Construire l’image d’installation pour les cartes ARM

De nombreuses cartes ARM requièrent une variante spécifique du chargeur d’amorçage U-Boot.

Si vous construisez une image disque et que le chargeur d’amorçage n’est pas disponible autrement (sur un autre périphérique d’amorçage etc), il est recommandé de construire une image qui inclus le chargeur d’amorçage, plus précisément :

guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 est le nom de la carte. Si vous spécifiez une carte invalide, une liste de cartes possibles sera affichée.

4 Pour démarrer

Vous êtes certainement arrivé·e à cette section parce que vous avez installé Guix sur une autre distribution (voir Installation), ou bien vous avez installé Guix System (voir Installation du système). Il est temps pour vous de commencer à utiliser Guix et cette section est là pour vous aider à le faire et vous donner une idée de ce que c’est.

Guix est, entre autres, un programme d’installation de logiciels, donc la première chose que vous voudrez probablement faire est de chercher un logiciel. Disons que vous cherchez un éditeur de texte, vous pouvez lancer :

guix search text editor

Cette commande vous montre un certain nombre de paquets correspondants, en indiquant à chaque fois le nom du paquet, sa version, une description et des informations supplémentaires. Une fois que vous avez trouvé celui que vous voulez utiliser, disons Emacs (ah ha !), vous pouvez l’installer (lancez cette commande en tant qu’ utilisateur·rice, pas besoin des privilèges d’administration !) :

guix install emacs

Vous avez installé votre premier paquet, félicitations ! Le paquet est maintenant visible dans votre profil par défaut, $HOME/.guix-profile — un profil est un répertoire contenant les paquets installés. Vous avez probablement remarqué que Guix a téléchargé des binaires pré-compilés ; ou bien, si vous vous êtes dit : non, pas de binaires pré-compilés, alors Guix est probablement encore en train de construire un logiciel (voir Substituts, pour plus d’informations).

À moins que vous utilisiez Guix System, la commande guix install doit avoir affiché cet indice :

conseil : pensez à définir les variables d'environnement nécessaires en exécutant :

     GUIX_PROFILE="$HOME/.guix-profile"
     . "$GUIX_PROFILE/etc/profile"

Vous pouvez également consulter `guix package --search-paths -p "$HOME/.guix-profile"'.

En effet, vous devez maintenant indiquer à votre shell où se trouvent emacs et les autres programmes installés avec Guix. En collant les deux lignes ci-dessus, c’est exactement ce que vous ferez : vous ajouterez $HOME/.guix-profile/bin — qui est l’endroit où se trouve le paquet installé — à la variable d’environnement PATH. Vous pouvez coller ces deux lignes dans votre shell pour qu’elles prennent effet immédiatement, mais surtout vous devez les ajouter à ~/.bash_profile (ou un fichier équivalent si vous n’utilisez pas Bash) afin que les variables d’environnement soient définies la prochaine fois que vous lancerez un shell. Vous n’avez besoin de le faire qu’une seule fois et les autres variables d’environnement des chemins de recherche seront traitées de la même manière — par exemple, si vous installez les bibliothèques python et Python, PYTHONPATH sera définie.

Vous pouvez continuer à installer des paquets à votre guise. Pour lister les paquets installés, lancez :

guix package --list-installed

Pour supprimer un paquet, sans surprise, lancez guix remove. Une caractéristique distinctive est la possibilité de faire revenir en arrière toute opération que vous avez effectuée — installation, suppression, mise à niveau — en tapant simplement :

guix package --roll-back

C’est parce que chaque opération est en fait une transaction qui crée une nouvelle génération. Les générations et leurs différences entre elles peuvent être affichées en lançant :

guix package --list-generations

Vous connaissez maintenant les bases de la gestion des paquets !

Aller plus loin : Voir Gestion de paquets, pour en savoir plus sur la gestion des paquets. Vous pouvez aimer la gestion declarative des paquets avec guix package --manifest, la gestion de profils séparés avec --profil, la suppression des anciennes générations, le ramasse-miettes et d’autres fonctionnalités astucieuses qui vous seront utiles à mesure que vous vous familiariserez avec Guix. Si vous développez du code, voir Développement pour des outils supplémentaires. Et si vous êtes curieux·euse, voir Fonctionnalités, pour jeter un coup d’œil sous le capot.

Une fois que vous avez installé un ensemble de paquets, vous voudrez périodiquement faire une mise à jour à la dernière version flambant neuve. Pour cela, vous devez d’abord récupérer la dernière révision de Guix et de sa collection de paquets :

guix pull

Le résultat final est une nouvelle commande guix, sous ~/.config/guix/current/bin. A moins que vous ne soyez sous Guix System, la première fois que vous lancez guix pull, assurez-vous de suivre le conseil que la commande affiche et, comme nous l’avons vu ci-dessus, collez ces deux lignes dans votre terminal et dans .bash_profile :

GUIX_PROFILE="$HOME/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"

Vous devez aussi informer votre shell de pointer sur ce nouveau guix :

hash guix

A ce stade, vous pilotez un Guix tout neuf. Vous pouvez donc aller de l’avant et mettre effectivement à jour tous les paquets que vous avez installés précédemment :

guix upgrade

En exécutant cette commande, vous verrez que des binaires sont téléchargés (ou peut-être que certains paquets sont construits), et vous finirez par obtenir les paquets mis à jour. Si l’un de ces paquets n’est pas à votre goût, n’oubliez pas que vous pouvez toujours revenir en arrière !

Vous pouvez afficher la révision exacte de Guix actuellement en cours d’exécution en lançant :

guix describe

L’information affichée est tout ce qu’il faut pour reproduire exactement le même Guix, que ce soit à un moment différent ou sur une machine différente.

Aller plus loin : Voir Invoquer guix pull, pour plus d’informations. Voir Canaux, sur la façon de spécifier des canaux supplémentaires pour extraire des paquets, sur la façon de répliquer Guix, et plus encore. Vous pouvez également trouver time-machine pratique (voir Invoquer guix time-machine).

Si vous avez installé Guix System, une des premières choses que vous voudrez faire est de le mettre à jour. Une fois que vous avez lancé guix pull pour obtenir le dernier Guix, vous pouvez mettre à jour le système comme ceci :

sudo guix system reconfigure /etc/config.scm

Ceci terminé, le système exécute les dernières versions de ses logiciels. Lorsque vous redémarrez, vous remarquerez un sous-menu dans le chargeur d’amorçage qui indique « Old system generations » : c’est ce qui vous permet de démarrer une ancienne génération de votre système, si la dernière génération est « cassée » ou insatisfaisante. Tout comme pour les paquets, vous pouvez toujours revenir à une génération précédente de l’ensemble du système :

sudo guix system roll-back

Il y a beaucoup de choses que vous voudrez probablement modifier sur votre système : ajouter de nouveaux comptes utilisateur·rice·s, ajouter de nouveaux services système, modifier la configuration de ces services, etc. La configuration du système est entièrement décrite dans le fichier /etc/config.scm. Voir Utiliser le système de configuration, pour apprendre à le modifier.

Maintenant, vous en savez assez pour commencer !

Ressources : Le reste de ce manuel constitue une référence pour tout ce qui concerne Guix. Voici quelques ressources supplémentaires que vous pourriez trouver utiles :

• Voir The GNU Guix Cookbook, pour une liste de recettes de style "how-to" pour une variété d’applications.
• La GNU Guix Reference Card énumère en deux pages la plupart des commandes et options dont vous aurez besoin.
• Le site web contient des vidéos instructives couvrant des sujets tels que l’utilisation quotidienne de Guix, comment obtenir de l’aide et comment devenir un·e contributeur·rice.
• Voir Documentation, pour savoir comment accéder à la documentation sur votre ordinateur.

Nous espérons que vous apprécierez Guix autant que la communauté a de plaisir à le construire !

5 Gestion de paquets

Le but de GNU Guix est de permettre à ses utilisatrices et utilisateurs d’installer, mettre à jour et supprimer facilement des paquets logiciels sans devoir connaître leur procédure de construction ou leurs dépendances. Guix va aussi plus loin que ces fonctionnalités évidentes.

Ce chapitre décrit les principales fonctionnalités de Guix, ainsi que des outils de gestion des paquets qu’il fournit. En plus de l’interface en ligne de commande décrite en dessous de (voir guix package), vous pouvez aussi utiliser l’interface Emacs-Guix (voir Le manuel de référence de emacs-guix), après avoir installé le paquet emacs-guix (lancez la commande M-x guix-help pour le démarrer) :

guix install emacs-guix

5.1 Fonctionnalités

Ici, nous supposons que vous avez déjà fait vos premiers pas avec Guix voir Pour démarrer) et que vous voulez avoir un aperçu de ce qui se passe sous le capot.

Lorsque vous utilisez Guix, chaque paquet arrive dans dépôt des paquets, dans son propre répertoire — quelque chose comme /gnu/store/xxx-paquet-1.2, où xxx est une chaîne en base32.

Plutôt que de se rapporter à ces répertoires, les utilisateur·rice·s ont leur propre profil qui pointe vers les paquets qu’ils ou elles veulent vraiment utiliser. Ces profils sont stockés dans le répertoire personnel de chacun·e dans $HOME/.guix-profile.

Par exemple, alice installe GCC 4.7.2. Il en résulte que /home/alice/.guix-profile/bin/gcc pointe vers /gnu/store/…-gcc-4.7.2/bin/gcc. Maintenant, sur la même machine, bob a déjà installé GCC 4.8.0. Le profil de bob continue simplement de pointer vers /gnu/store/…-gcc-4.8.0/bin/gcc — c.-à-d. les deux versions de GCC coexistent surs le même système sans aucune interférence.

La commande guix package est l’outil central pour gérer les paquets (voir Invoquer guix package). Il opère sur les profils de chaque utilisateur·rice et peut être utilisé avec les privilèges normaux.

La commande fournit les opérations évidentes d’installation, de suppression et de mise à jour. Chaque invocation est en fait une transaction : soit l’opération demandée réussit, soit rien ne se passe. Ainsi, si le processus guix package est terminé pendant la transaction ou si une panne de courant arrive pendant la transaction, le profil reste dans son état précédent et reste utilisable.

En plus, il est possible d’annuler toute transaction sur les paquets. Donc si par exemple un mise à jour installe une nouvelle version d’un paquet qui révèle un bogue sérieux, vous pouvez revenir en arrière à l’instance précédente de votre profil que vous saviez bien fonctionner. De même, la configuration globale du système dans Guix est sujette aux mises à jour transactionnelles et aux annulations (voir Utiliser le système de configuration).

Tout paquet du dépôt des paquets peut être glané. Guix peut déterminer quels paquets sont toujours référencés par les profils des utilisateur·rice·s et supprimer ceux qui ne sont de tout évidence plus référencés (voir Invoquer guix gc). Les utilisateur·rice·s peuvent toujours explicitement supprimer les anciennes générations de leur profil pour que les paquets auxquels elles faisaient référence puissent être glanés.

Guix prend une approche purement fonctionnelle de la gestion de paquets, telle que décrite dans l’introduction (voir Introduction). Chaque nom de répertoire de paquet dans /gnu/store contient un hash de toutes les entrées qui ont été utilisées pendant la construction de ce paquet — le compilateur, les bibliothèques, les scripts de construction, etc. Cette correspondance directe permet aux utilisateur·rice·s de s’assurer que l’installation d’un paquet donné correspond à l’état actuel de leur distribution. Elle aide aussi à maximiser la reproductibilité : grâce aux environnements de construction utilisés, une construction donnée a de forte chances de donner des fichiers identiques bit-à-bit lorsqu’elle est effectuée sur des machines différentes (voir container).

Ce fondement permet à Guix de supporter le déploiement transparent de binaire ou source. Lorsqu’une binaire pré-construit pour une entrée de /gnu/store est disponible depuis une source externe (un substitut), Guix le télécharge simplement et le décompresse ; sinon, il construit le paquet depuis les sources localement (voir Substituts). Comme les résultats des constructions sont généralement reproductibles au bit près, si vous n’avez pas besoin de faire confiance aux serveurs qui fournissent les substituts : vous pouvez forcer une construction locale et défier les fournisseurs (voir Invoquer guix challenge).

Le contrôle de l’environnement de construction est aussi une fonctionnalité utile pour les développeurs. La commande guix environment permet aux développeurs d’un paquet de mettre en place rapidement le bon environnement de développement pour leur paquet, sans avoir à installer manuellement les dépendances du paquet dans leur profil (voir Invoquer guix environment).

La totalité de Guix et des définitions de paquets sont placés sous contrôle de version, et guix pull vous permet de « voyager dans le temps » de l’historique de Guix lui-même (voir Invoquer guix pull). Cela est rend possible la réplication d’une instance Guix sur une machine différente ou plus tard, ce qui vous permet de répliquer des environnements logiciels complets, tout en garantissant un suivi de provenance précis des logiciels.

5.2 Invoquer guix package

La commande guix package est l’outil qui permet d’installer, mettre à jour et supprimer les paquets ainsi que de revenir à une configuration précédente. Ces opérations fonctionnent sur un profil utilisateur—un répertoire avec les paquets installés. Chaque utilisateur a un profile par défaut dans $HOME/.guix-profile. La commande n’opère que dans le profil de l’utilisateur·rice et fonctionne avec les privilèges normaux (voir Fonctionnalités). Sa syntaxe est :

guix package options

options spécifie d’abord les opérations à effectuer pendant la transaction. À la fin, une nouvelle génération du profil est créée mais les générations précédentes du profil restent disponibles si l’utilisateur·rice souhaite y revenir.

Par exemple, pour supprimer lua et installer guile et guile-cairo en une seule transaction :

guix package -r lua -i guile guile-cairo

Parce que c’est pratique, nous fournissons aussi les alias suivants :

• guix search est un alias de guix package -s,
• guix install est un alias de guix package -i,
• guix remove est un alias de guix package -r,
• guix upgrade est un alias de guix package -u,
• et guix search est un alias de guix package -s.

Ces alias sont moins expressifs que guix package et fournissent moins d’options, donc dans certains cas vous devrez probablement utiliser guix package directement.

guix package supporte aussi une approche déclarative où on spécifie l’ensemble exact des paquets qui doivent être disponibles que l’on passe via l’option --manifest (voir --manifest).

Pour chaque utilisateur·rice, un lien symbolique vers son profil par défaut est automatiquement créé dans $HOME/.guix-profile. Ce lien symbolique pointe toujours vers la génération actuelle du profil par défaut du compte. Ainsi, on peut ajouter $HOME/.guix-profile/bin à sa variable d’environnement PATH etc. Si vous n’utilisez pas la distribution système Guix, vous devriez ajouter les lignes suivantes à votre ~/.bash_profile (voir Bash Startup Files dans The GNU Bash Reference Manual) pour que les shells créés ensuite aient tous les bonnes définitions des variables d’environnement :

GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$GUIX_PROFILE/etc/profile"

Dans un environnement multi-utilisateur·rice, les profils des utilisateur·rice·s sont stockés dans un emplacement enregistré comme garbage-collector root, vers lequel $HOME/.guix-profile pointe (voir Invoquer guix gc). Ce répertoire est normalement localstatedir/guix/profiles/per-user/user, où localstatedir est la valeur passée à configure comme --localstatedir, et user est le nom d’utilisateur·rice. Le répertoire per-user est créé au démarrage de guix-daemon, et le sous-répertoire user est créé par guix package.

Les options peuvent être les suivante :

--install=paquet …

-i paquet …

Installer les paquets spécifiés.

Chaque paquet peut spécifier soit un simple nom de paquet, tel que guile, soit un nom de paquet suivi d’un at-sign et d’un numéro de version, tel que guile@1.8.8 ou simplement guile@1.8. (dans ce dernier cas, la version la plus récente préfixée par 1.8 est sélectionnée).

Si aucun numéro de version n’est spécifié, la version la plus récente disponible est choisie. En plus, paquet peut contenir un deux-points, suivi du nom d’une des sorties du paquet, comme dans gcc:doc ou binutils@2.22:lib (voir Des paquets avec plusieurs résultats). Des paquets avec un nom correspondant et (éventuellement une version) sont recherchés dans les modules de la distribution GNU (voir Modules de paquets).

Parfois les paquets ont des entrées propagées : ce sont des dépendances qui sont installées automatiquement avec le paquet demandé (voir propagated-inputs in package objects pour plus d’informations sur les entrées propagées dans les définitions des paquets).

Un exemple est la bibliothèque MPC de GNU : ses fichiers d’en-tête C se réfèrent à ceux de la bibliothèque MPFR de GNU, qui se réfèrent en retour à ceux de la bibliothèque GMP. Ainsi, lorsqu’on installe MPC, les bibliothèques MPFR et GMP sont aussi installées dans le profil ; supprimer MPC supprimera aussi MPFR et GMP — à moins qu’ils n’aient été aussi installés explicitement par l’utilisateur·rice.

En outre, les paquets s’appuient parfois sur la définition de variables d’environnement pour leurs chemins de recherche (voir l’explication de l’--chemins de recherche ci-dessous). Toute définition de variable d’environnement manquante ou éventuellement incorrecte est reportée ici.

--install-from-expression=exp

-e exp

Installer le paquet évalué par exp.

exp doit être une expression Scheme qui s’évalue en un objet <package>. Cette option est notamment utile pour distinguer les variantes d’un paquet avec le même nom, avec des expressions comme (@ (gnu packages base) guile-final).

Remarquez que cette option installe la première sortie du paquet, ce qui peut être insuffisant lorsque vous avez besoin d’une sortie spécifique d’un paquet à plusieurs sorties.

--install-from-file=fichier

-f fichier

Installer le paquet évalué par le code dans le fichier.

Par exemple, fichier peut contenir une définition comme celle-ci (voir Définition des paquets) :

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Lorsqu’on développe, on peut trouver utile d’inclure un tel fichier guix.scm à la racine de l’arborescence des sources de son projet qui pourrait être utilisé pour tester des versions de développement et créer des environnements de développement reproductibles (voir Invoquer guix environment).

Le fichier peut aussi contenir une représentation JSON d’une ou de plusieurs définitions de paquets. L’exécution de guix package -f sur hello.json avec le contenu suivant entraînerait l’installation du paquet greeter après la construction de myhello :

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    }
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "https://example.com/greeter-1.0.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false,
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]

--remove=paquet …

-r paquet …

Supprimer les paquets spécifiés.

Comme pour --install, chaque paquet peut spécifier un numéro de version ou un nom de sortie en plus du nom du paquet. Par exemple, ‘-r glibc:debug’ supprimerait la sortie debug de glibc.

--upgrade[=regexp …]

-u [regexp …]

Mettre à jour tous les paquets installés. Si un ou plusieurs regexp sont spécifiés, la mise à jour n’installera que les paquets dont le nom correspond à regexp. Voir aussi l’option --do-not-upgrade ci-dessous.

Remarquez que cela met à jour vers la dernière version des paquets trouvée dans la distribution actuellement installée. Pour mettre à jour votre distribution, vous devriez lancer régulièrement guix pull (voir Invoquer guix pull).

Quand une mise à jour est en cours d’exécution, les transformations de paquets initialement appliquées lors de la création du profil sont automatiquement réappliquées (voir Options de transformation de paquets). Par exemple, supposons que vous ayez d’abord installé Emacs depuis l’extrémité de sa branche de développement avec :

guix install emacs-next --with-branch=emacs-next=master

La prochaine fois que vous lancerez guix upgrade, Guix va à nouveau extraire l’extrémité de la branche de développement Emacs et construira emacs-next à partir de ce checkout.

Notez que les options de transformation comme --with-branch et --with-source dépendent de l’état exterieur ; c’est à vous de vous assurer qu’elles fonctionnent comme souhaité. Vous pouvez également écarter une transformation qui s’applique à un paquet en lançant :

$ guix install paquet

--do-not-upgrade[=regexp …]

Lors d’une utilisation conjointe avec l’option --upgrade, ne pas mettre à jour les paquets dont le nom correspond à regexp. Par exemple, pour mettre à jour tous les paquets du profil actuel à l’exception de ceux qui contiennent la chaîne « emacs » :

$ guix package --upgrade . --do-not-upgrade emacs

--manifest=fichier

-m fichier

Créer une nouvelle génération du profil depuis l’objet manifeste renvoyé par le code Scheme dans fichier. Cette option peut être répétée plusieurs fois, auquel cas les manifestes sont concaténés.

Cela vous permet de déclarer le contenu du profil plutôt que de le construire avec une série de --install et de commandes similaires. L’avantage étant que le fichier peut être placé sous contrôle de version, copié vers d’autres machines pour reproduire le même profil, etc.

fichier doit renvoyer un objet manifest qui est en gros une liste de paquets :

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Utiliser une sortie spécifique d'un paquet.
       (list guile-2.0 "debug")))

Dans cet exemple on doit savoir quels modules définissent les variables emacs et guile-2.0 pour fournir la bonne ligne use-package-modules ce qui peut être embêtant. On peut à la place fournir des spécifications de paquets normales et laisser specifications->manifest rechercher les objets de paquets correspondants, comme ceci :

(specifications->manifest
 '("emacs" "guile@2.2" "guile@2.2:debug"))

Voir --export-manifest, pour apprendre à obtenir un fichier manifeste depuis un profil existant.

--roll-back

Revenir à la génération précédente du profil c.-à-d. défaire la dernière transaction.

Lorsqu’elle est combinée avec des options comme --install, Le retour en arrière se produit avant toute autre action.

Lorsque vous revenez de la première génération qui contient des fichiers, le profil pointera vers la zéroième génération qui ne contient aucun fichier en dehors de ses propres métadonnées.

Après être revenu en arrière, l’installation, la suppression et la mise à jour de paquets réécrit les futures générations précédentes. Ainsi, l’historique des générations dans un profil est toujours linéaire.

--switch-generation=motif

-S motif

Basculer vers une génération particulière définie par le motif.

Le motif peut être soit un numéro de génération soit un nombre précédé de « + » ou « - ». Ce dernier signifie : se déplacer en avant ou en arrière d’un nombre donné de générations. Par exemple, si vous voulez retourner à la dernière génération après --roll-back, utilisez --switch-generation=+1.

La différence entre --roll-back et --switch-generation=-1 est que --switch-generation ne vous amènera pas à la génération initiale, donc si la génération demandée n’existe pas la génération actuelle ne changera pas.

--search-paths[=genre]

Rapporter les définitions des variables d’environnement dans la syntaxe Bash qui peuvent être requises pour utiliser l’ensemble des paquets installés. Ces variables d’environnement sont utilisées pour spécifier les chemins de recherche de fichiers utilisés par les paquets installés.

Par exemple, GCC a besoin des variables d’environnement CPATH et LIBRARY_PATH pour trouver les en-têtes et les bibliothèques dans le profil de l’utilisateur·rice (voir Environment Variables dans Using the GNU Compiler Collection (GCC)). Si GCC et, disons, la bibliothèque C sont installés dans le profil, alors --search-paths suggérera d’initialiser ces variables à profil/include et profil/lib, respectivement.

Le cas d’utilisation typique est de définir ces variables d’environnement dans le shell :

$ eval `guix package --search-paths`

genre peut être l’une des valeurs exact, prefix ou suffix, ce qui signifie que les définitions des variables d’environnement renvoyées seront soit les paramètres exacts, soit placés avant ou après la valeur actuelle de ces paramètres. Lorsqu’il est omis, genre a pour valeur par défaut exact.

Cette option peut aussi être utilisé pour calculer les chemins de recherche combinés de plusieurs profils. Regardez cet exemple :

$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths

La dernière commande ci-dessus montre la variable GUILE_LOAD_PATH bien que, pris individuellement, ni foo ni bar n’auraient donné cette recommandation.

--profile=profil

-p profil

Utiliser le profil à la place du profil par défaut du compte.

profil doit être le nom d’un fichier qui sera créé une fois terminé. Concrètement, profil sera un simple lien symbolique (« symlink ») pointant vers le profil réel où les paquets sont installés :

$ guix install hello -p ~/code/my-profile
…
$ ~/code/my-profile/bin/hello
Hello, world!

Tout ce qu’il faut pour se débarrasser du profil est de supprimer ce lien symbolique et ses frères et sœurs qui pointent vers des générations spécifiques :

$ rm ~/code/my-profile ~/code/my-profile-*-link

--list-profiles

Liste tous les profils utilisateur·rice :

$ guix package --list-profiles
/home/charlie/.guix-profile
/home/charlie/code/my-profile
/home/charlie/code/devel-profile
/home/charlie/tmp/test

En cours d’exécution sous root, liste tous les profils de tou·te·s les utilisateur·rice·s.

--allow-collisions

Permettre des collisions de paquets dans le nouveau profil. À utiliser à vos risques et périls !

Par défaut, guix package rapporte les collisions dans le profil comme des erreurs. Les collisions ont lieu quand deux version ou variantes d’un paquet donné se retrouvent dans le profil.

--bootstrap

Utiliser le programme d’amorçage Guile pour compiler le profil. Cette option n’est utile qu’aux personnes qui développent la distribution.

En plus de ces actions, guix package supporte les options suivantes pour demander l’état actuel d’un profil ou la disponibilité des paquets :

--search=regexp

-s regexp

Lister les paquets disponibles dont le nom, le synopsis ou la description correspondent à la regexp (en étant insensible à la casse), triés par pertinence. Afficher toutes les métadonnées des paquets correspondants au format recutils (voir GNU recutils databases dans GNU recutils manual).

Cela permet à des champs spécifiques d’être extraits avec la commande recsel, par exemple :

$ guix package -s malloc | recsel -p name,version,relevance
name: jemalloc
version: 4.5.0
relevance: 6

name: glibc
version: 2.25
relevance: 1

name: libgc
version: 7.6.0
relevance: 1

De manière similaire, pour montrer le nom de tous les paquets disponibles sous license GNU LGPL version 3 :

$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils

name: gmp
…

Il est aussi possible de raffiner les résultats de la recherche en donnant plusieurs options -s à guix package, ou plusieurs arguments à guix search. Par exemple, la commande suivante renvoie la liste des jeux de plateau (cette fois-ci avec l’alias guix search) :

$ guix search '\<board\>' game | recsel -p name
name: gnubg
…

Si on avait oublié -s game, on aurait aussi eu les paquets logiciels qui s’occupent de circuits imprimés (en anglais : circuit board) ; supprimer les chevrons autour de board aurait aussi ajouté les paquets qui parlent de clavier (en anglais : keyboard).

Et maintenant un exemple plus élaboré. La commande suivante recherche les bibliothèques cryptographiques, retire les bibliothèques Haskell, Perl, Python et Ruby et affiche le nom et le synopsis des paquets correspondants :

$ guix search crypto library | \
    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

Voir Selection Expressions dans GNU recutils manual pour plus d’information sur les expressions de sélection pour recsel -e.

--show=paquet

Afficher les détails du paquet dans la liste des paquets disponibles, au format recutils (voir GNU recutils databases dans GNU recutils manual).

$ guix package --show=python | recsel -p name,version
name: python
version: 2.7.6

name: python
version: 3.3.5

Vous pouvez aussi spécifier le nom complet d’un paquet pour n’avoir que les détails concernant une version spécifique (cette fois-ci avec l’alias guix show) :

$ guix show python@3.4 | recsel -p name,version
name: python
version: 3.4.3

--list-installed[=regexp]

-I [regexp]

Liste les paquets actuellement installés dans le profil spécifié, avec les paquets les plus récemment installés en dernier. Lorsque regexp est spécifié, liste uniquement les paquets installés dont le nom correspond à regexp.

Pour chaque paquet installé, affiche les éléments suivants, séparés par des tabulations : le nom du paquet, sa version, la partie du paquet qui est installé (par exemple, out pour la sortie par défaut, include pour ses en-têtes, etc) et le chemin du paquet dans le dépôt.

--list-available[=regexp]

-A [regexp]

Lister les paquets actuellement disponibles dans la distribution pour ce système (voir Distribution GNU). Lorsque regexp est spécifié, lister uniquement les paquets dont le nom correspond à regexp.

Pour chaque paquet, affiche les éléments suivants séparés par des tabulations : son nom, sa version, les parties du paquet (voir Des paquets avec plusieurs résultats), et l’emplacement de sa définition.

--list-generations[=motif]

-l [motif]

Renvoyer la liste des générations avec leur date de création ; pour chaque génération, montre les paquets installés avec les paquets installés les plus récemment en dernier. Remarquez que la zéroième génération n’est jamais montrée.

Pour chaque paquet installé, afficher les éléments suivants, séparés par des tabulations : le nom du paquet, sa version, la partie du paquet qui a été installée (voir Des paquets avec plusieurs résultats), et l’emplacement du paquet dans le dépôt.

Lorsque motif est utilisé, la commande ne renvoie que les générations correspondantes. Les motifs valides sont :

• Des entiers et des entiers séparés par des virgules. Les deux motifs correspondent numéros de génération. Par exemple, --list-generations=1 renvoie la première.

  Et --list-generations=1,8,2 renvoie les trois générations dans l’ordre spécifié. Aucun espace ni virgule surnuméraire ne sont permis.

• Ranges. --list-generations=2..9 affiche les générations demandées et tout ce qui se trouve entre elles. Remarquez que le début d’un intervalle doit être plus petit que sa fin.

  Il est aussi possible d’omettre le numéro final. Par exemple, --list-generations=2.. renvoie toutes les générations à partir de la deuxième.

• Des durées. Vous pouvez aussi récupérer les derniers N jours, semaines, ou mois en passant un entier avec la première lettre de la durée (en anglais : d, w ou m). Par exemple --list-generations=20d liste les générations qui sont âgées d’au plus 20 jours.

--delete-generations[=motif]

-d [motif]

Lorsque motif est omis, supprimer toutes les générations en dehors de l’actuelle.

Cette commande accepte les même motifs que --list-generations. Lorsque motif est spécifié, supprime les générations correspondantes. Lorsque motif spécifie une durée, les générations plus anciennes que la durée spécifiée correspondent. Par exemple --delete-generations=1m supprime les générations vieilles de plus d’un mois.

Si la génération actuelle correspond, elle n’est pas supprimée. La zéroième génération n’est elle non plus jamais supprimée.

Remarquez que supprimer des générations empêche de revenir en arrière vers elles. Ainsi, cette commande doit être utilisée avec précaution.

--export-manifest

Écrire un manifeste vers la sortie standard utilisable avec --manifest et qui correspond à un ou plusieurs profils choisis.

Cette option est conçue pour vous aider à migre du mode de fonctionnement « impératif » — lancer guix install, guix upgrade, etc — au mode déclaratif offert par --manifest.

Soyez conscient que le manifeste qui est résulte est une approximation de ce que votre profil contient vraiment ; par exemple, en fonction de la manière dont votre profil a été créé, il peut se référer à des paquets ou des versions de paquets qui ne sont pas exactement ce que vous avez spécifié.

Gardez en tête qu’un manifeste est purement symbolique : il ne contient que des noms de paquets et éventuellement des versions, et leur signification varie avec le temps. Si vous voulez « épingler » des canaux aux révisions qui ont été utilisées pour construire les profils, voir --export-channels plus bas.

--export-channels

Écrit sur la sortie standard la liste des canaux utilisés par les profils choisi, dans un format convenable pour guix pull --channels ou guix time-machine --channels (voir Canaux).

Avec --export-manifest, cette option fournit les informations qui vous permettent de répliquer le profil actuel (voir Répliquer Guix).

Cependant, remarquez que la sortie de cette commande est une approximation de ce qui a vraiment été utilisé pour construire le profil. En particulier, a profil unique peut avoir été construit à partir de plusieurs révisions du même canal. Dans ce cas, --export-manifest choisi la dernière et écrit la liste des autres révisions dans un commentaire. Si vous avez vraiment besoin de choisir des paquets à partir d’autres révisions des canaux, vous pouvez utiliser des inférieurs dans votre manifeste pour cela (voir Inférieurs).

Avec --export-manifest, c’est un bon point de départ si vous voulez migrer du modèle « impératif » au modèle complètement déclaratif qui consiste en un fichier manifeste et un fichier de canaux qui épingle les révisions exactes des canaux que vous voulez.

Enfin, comme guix package peut démarrer des processus de construction, il supporte les options de construction communes (voir Options de construction communes). Il prend aussi en charge les options de transformation de paquets comme --with-source, et les préserve à travers les mises à jour (voir Options de transformation de paquets).

5.3 Substituts

Guix gère le déploiement depuis des binaires ou des sources de manière transparente ce qui signifie qu’il peut aussi bien construire localement que télécharger des éléments pré-construits depuis un serveur ou les deux. Nous appelons ces éléments pré-construits des substituts — ils se substituent aux résultats des constructions locales. Dans la plupart des cas, télécharger un substitut est bien plus rapide que de construire les choses localement.

Les substituts peuvent être tout ce qui résulte d’une construction de dérivation (voir Dérivations). Bien sûr dans le cas général, il s’agit de paquets binaires pré-construits, mais les archives des sources par exemple résultent aussi de la construction d’une dérivation qui peut aussi être disponible en tant que substitut.

5.3.1 Serveur de substituts officiel

Le serveur ci.guix.gnu.org est une interface à la ferme de construction officielle qui construit des paquets pour Guix continuellement pour certaines architectures et les rend disponibles en tant que substituts. C’est la source par défaut des substituts ; elle peut être modifiée en passant l’option --substitute-urls soit à guix-daemon (voir guix-daemon --substitute-urls) soit aux outils clients comme guix package (voir client --substitute-urls option).

Les URL des substituts peuvent être soit en HTTP soit en HTTPS. Le HTTPS est recommandé parce que les communications sont chiffrées ; à l’inverse HTTP rend les communications visibles pour un espion qui peut utiliser les informations accumulées sur vous pour déterminer par exemple si votre système a des vulnérabilités de sécurités non corrigées.

Les substituts de la ferme de construction officielle sont activés par défaut dans la distribution système Guix (voir Distribution GNU). Cependant, ils sont désactivés par défaut lorsque vous utilisez Guix sur une distribution externe, à moins que vous ne les ayez explicitement activés via l’une des étapes d’installation recommandées (voir Installation). Les paragraphes suivants décrivent comment activer ou désactiver les substituts pour la ferme de construction officielle ; la même procédure peut être utilisée pour activer les substituts de n’importe quel autre serveur de substituts.

5.3.2 Autoriser un serveur de substituts

Pour permettre à Guix de télécharger les substituts depuis ci.guix.gnu.org ou un miroir, vous devez ajouter sa clef publique à la liste de contrôle d’accès (ACL) des imports d’archives, avec la commande guix archive (voir Invoquer guix archive). Cela implique que vous faîtes confiance à ci.guix.gnu.org pour ne pas être compromis et vous servir des substituts authentiques.

Remarque : Si vous utilisez le système Guix, vous pouvez sauter cette section : le système Guix autorise les substituts de ci.guix.gnu.org par défaut.

La clef publique pour ci.guix.gnu.org est installée avec Guix, dans préfixe/share/guix/ci.guix.gnu.org.pub, où préfixe est le préfixe d’installation de Guix. Si vous avez installé Guix depuis les sources, assurez-vous d’avoir vérifié la signature GPG de guix-1.3.0.tar.gz qui contient ce fichier de clef publique. Ensuite vous pouvez lancer quelque chose comme ceci :

# guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub

Une fois que cela est en place, la sortie d’une commande comme guix build devrait changer de quelque chose comme :

$ guix build emacs --dry-run
Les dérivations suivantes seraient construites :
   /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
   /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
   /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
   /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
…

à quelque chose comme :

$ guix build emacs --dry-run
112.3 Mo seraient téléchargés :
   /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
   /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
   /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
   /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
…

Le texte a changé de « Les dérivations suivantes seront construites » à « 112,3 Mio seront téléchargés ». Cela indique que les substituts de ci.guix.gnu.org sont utilisables et seront téléchargés, si possible, pour les futures constructions.

Le mécanisme de substitution peut être désactivé globalement en lançant guix-daemon avec --no-substitutes (voir Invoquer guix-daemon). Il peut aussi être désactivé temporairement en passant l’option --no-substitutes à guix package, guix build et aux autres outils en ligne de commande.

5.3.3 Récupérer des substituts d’autres serveurs

Guix peut chercher et récupérer des substituts à partir de plusieurs serveurs. C’est utile si vous utilisez des paquets de canaux supplémentaires pour lesquels le serveur officiel n’a pas de substituts mais que d’autres serveurs les fournissent. Une autre situation où cela est utile est si vous souhaitez télécharger depuis les serveurs de substituts de votre organisation, en utilisant le serveur officiel en dernier recours, ou en ne l’utilisant pas du tout.

Vous pouvez donner à Guix une liste d’URL de serveurs de substituts et il les vérifiera dans l’ordre indiqué. Vous devez aussi explicitement autoriser les clés publiques des serveurs de substituts pour dire à Guix d’accepter les substituts qu’ils signent.

Sur le système Guix, cela se fait en modifiant la configuration du service guix. Comme le service guix fait partie des services par défaut, %base-services et %desktop-services, vous pouvez utiliser modify-services pour changer sa configuration et ajouter les URL et les clés des serveurs de substituts que vous voulez (voir modify-services).

Par exemple, supposons que vous vouliez récupérer les substituts de guix.example.org et autoriser la clé de signature de ce serveur, en plus du serveur ci.guix.gnu.org par défaut. La configuration du système d’exploitation qui en résulte ressemblera à :

(operating-system
  ;; …
  (services
    ;; Supposons qu'on commence à partir de '%desktop-services'.  Remplaçons-le
    ;; par la liste des services qu'on utilise vraiment.
    (modify-services %desktop-services
      (guix-service-type config =>
                        (guix-configuration
                          (inherit config)
                          (substitute-urls
                            (append (list "https://guix.example.org")
                                    %default-substitute-urls))
                          (authorized-keys
                            (append (list (local-file "./key.pub"))
                                    %default-authorized-guix-keys)))))))

Cela suppose que le fichier key.pub contient la clé de signature de guix.example.org. Avec ce changement dans le fichier de configuration de votre système d’exploitation (disons /etc/config.scm), vous pouvez reconfigurer et redémarrer le service guix-daemon ou redémarrer pour que les changements prennent effet :

$ sudo guix system reconfigure /etc/config.scm
$ sudo herd restart guix-daemon

Si vous utilisez Guix sur une « distro externe », vous suivrez plutôt les étapes suivantes pour avoir des substituts de serveurs supplémentaires :

1. Modifier le fichier de configuration du service guix-daemon ; pour systemd, c’est normalement /etc/systemd/system/guix-daemon.service. Ajouter l’option --substitute-urls à la ligne de command guix-daemon et listez les URL qui vous intéressent (voir guix-daemon --substitute-urls) :

   … --substitute-urls='https://guix.example.org https://ci.guix.gnu.org'
   

2. Redémarrez le démon. Pour systemd, cela ressemble à :

   systemctl daemon-reload
   systemctl restart guix-daemon.service
   

3. Autorisez la clé du nouveau serveur (voir Invoquer guix archive) :

   guix archive --authorize < key.pub
   

   De nouveau, cela suppose que key.pub contient la clé publique que guix.example.org utilise pour signer les substituts.

Maintenant vous êtes paré ! Les substituts seront téléchargés de préférence à partir de https://guix.example.org, avec ci.guix.gnu.org en réserve. Évidemment vous pouvez lister autant de serveurs de substituts que vous voulez, avec l’inconvénient que la recherche de substituts sera ralentie si vous devez contacter trop de serveurs.

Remarquez qu’il à des situations où vous pourriez vouloir ajouter l’URL d’un serveur de substitut sans autoriser sa clé. Voir Authentification des substituts, pour comprendre ce point délicat.

5.3.4 Authentification des substituts

Guix détecte et lève une erreur lorsqu’il essaye d’utiliser un substitut qui a été modifié. De même, il ignore les substituts qui ne sont pas signés ou qui ne sont pas signés par l’une des clefs listées dans l’ACL.

Il y a une exception cependant : si un serveur non autorisé fournit des substituts qui sont identiques bit-à-bit à ceux fournis par un serveur autorisé, alors le serveur non autorisé devient disponible pour les téléchargements. Par exemple en supposant qu’on a choisi deux serveurs de substituts avec cette option :

--substitute-urls="https://a.example.org https://b.example.org"

Si l’ACL contient uniquement la clef de ‘b.example.org’, et si ‘a.example.org’ sert exactement les mêmes substituts, alors Guix téléchargera les substituts de ‘a.example.org’ parce qu’il vient en premier dans la liste et peut être considéré comme un miroir de ‘b.example.org’. En pratique, les machines de construction indépendantes produisent généralement les mêmes binaires, grâce à des constructions reproductibles au bit près (voir ci-dessous).

Lorsque vous utilisez HTTPS, le certificat X.509 du serveur n’est pas validé (en d’autre termes, le serveur n’est pas authentifié), contrairement à ce que des clients HTTPS comme des navigateurs web font habituellement. Celà est dû au fait que Guix authentifie les informations sur les substituts eux-mêmes, comme expliqué plus haut, ce dont on se soucie réellement (alors que les certificats X.509 authentifient la relation entre nom de domaine et clef publique).

5.3.5 Paramètres de serveur mandataire

Les substituts sont téléchargés par HTTP ou HTTPS. Les variables d’environnement http_proxy et https_proxy peuvent être initialisées dans l’environnement de guix-daemon et sont respectées pour le téléchargement des substituts. Remarquez que la valeur de ces variables d’environnement dans l’environnement où sont exécutés guix build, guix package, et d’autres commandes client n’a absolument aucun effet.

5.3.6 Échec de substitution

Même lorsqu’un substitut pour une dérivation est disponible, la substitution échoue parfois. Cela peut arriver pour plusieurs raisons : le serveur de substitut peut être hors ligne, le substitut a récemment été supprimé du serveur, la connexion peut avoir été interrompue, etc.

Lorsque les substituts sont activés et qu’un substitut pour une dérivation est disponible, mais que la tentative de substitution échoue, Guix essaiera de construire la dérivation localement si --fallback a été passé en argument (voir common build option --fallback). Plus spécifiquement, si cet option n’a pas été passée en argument, alors aucune construction locale n’est effectuée et la dérivation est considérée comme étant en échec. Cependant, si --fallback est passé en argument, alors Guix essaiera de construire la dérivation localement et l’échec ou le succès de la dérivation dépend de l’échec ou du succès de la construction locale. Remarquez que lorsque les substituts sont désactivés ou qu’aucun substitut n’est disponible pour la dérivation en question, une construction locale sera toujours effectuée, indépendamment du fait que l’argument --fallback ait été ou non passé.

Pour se donner une idée du nombre de substituts disponibles maintenant, vous pouvez essayer de lancer la commande guix weather (voir Invoquer guix weather). Cette command fournit des statistiques sur les substituts fournis par un serveur.

5.3.7 De la confiance en des binaires

De nos jours, le contrôle individuel sur son utilisation propre de l’informatique est à la merci d’institutions, de sociétés et de groupes avec assez de pouvoir et de détermination pour contourner les infrastructures informatiques et exploiter leurs faiblesses. Bien qu’utiliser les substituts de ci.guix.gnu.org soit pratique, nous encourageons chacun·e à construire aussi par soi-même, voire à faire tourner sa propre ferme de construction, pour que ci.guix.gnu.org devienne une cible moins intéressante. Une façon d’aider est de publier les logiciels que vous construisez avec guix publish pour que les autres aient plus de choix de serveurs où télécharger les substituts (voir Invoquer guix publish).

Guix possède les fondations pour maximiser la reproductibilité logicielle (voir Fonctionnalités). Dans la plupart des cas, des constructions indépendantes d’un paquet donnée ou d’une dérivation devrait donner des résultats identiques au bit près. Ainsi, à travers un ensemble de constructions de paquets indépendantes il est possible de renforcer l’intégrité du système. La commande guix challenge a pour but d’aider les utilisateur·rice·s à tester les serveurs de substituts et à aider les développeur·euse·s à trouver les constructions de paquets non-déterministes (voir Invoquer guix challenge). De même, l’option --check de guix build permet à chaque personne de vérifier si les substituts précédemment installés sont authentiques en les reconstruisant localement (voir guix build --check).

À l’avenir, nous aimerions que Guix puisse publier et recevoir des binaires d’autres personnes, de manière pair-à-pair. Si vous voulez discuter de ce projet, rejoignez-nous sur guix-devel@gnu.org.

5.4 Des paquets avec plusieurs résultats

Souvent, les paquets définis dans Guix ont une seule sortie — c.-à-d. que le paquet source conduit à exactement un répertoire dans le dépôt. Lorsque vous lancez guix install glibc, vous installez la sortie par défaut du paquet GNU libc ; la sortie par défaut est appelée out mais son nom peut être omis comme le montre cette commande. Dans ce cas particulier, la sortie par défaut de glibc contient tous les fichiers d’en-tête C, les bibliothèques partagées, les bibliothèques statiques, la documentation Info et les autres fichiers de support.

Parfois il est plus approprié de séparer les divers types de fichiers produits par un même paquet source en plusieurs sorties. Par exemple, la bibliothèque C GLib (utilisée par GTK+ et des paquets associés) installe plus de 20 Mo de documentation de référence dans des pages HTML. Pour préserver l’espace disque des utilisateurs qui n’en ont pas besoin, la documentation va dans une sortie séparée nommée doc. Pour installer la sortie principale de GLib, qui contient tout sauf la documentation, on devrait lancer :

guix install glib

La commande pour installer la documentation est :

guix install glib:doc

Certains paquets installent des programmes avec des « empreintes dépendances » différentes. Par exemple le paquet WordNet installe à la fois les outils en ligne de commande et les interfaces graphiques (GUI). La première ne dépend que de la bibliothèque C, alors que cette dernière dépend de Tcl/Tk et des bibliothèques X sous-jacentes. Dans ce cas, nous laissons les outils en ligne de commande dans la sortie par défaut et l’interface graphique dans une sortie séparée. Cela permet aux utilisateurs qui n’ont pas besoin d’interface graphique de gagner de la place. La commande guix size peut aider à trouver ces situations (voir Invoquer guix size). guix graph peut aussi être utile (voir Invoquer guix graph).

Il y a plusieurs paquets à sorties multiples dans la distribution GNU. D’autres noms de sorties conventionnels sont lib pour les bibliothèques et éventuellement les fichiers d’en-tête, bin pour les programmes indépendants et debug pour les informations de débogage (voir Installer les fichiers de débogage). Les sorties d’un paquet sont listés dans la troisième colonne de la sortie de guix package --list-available (voir Invoquer guix package).

5.5 Invoquer guix gc

Les paquets qui sont installés mais pas utilisés peuvent être glanés. La commande guix gc permet aux utilisateurs de lancer explicitement le ramasse-miettes pour récupérer de l’espace dans le répertoire /gnu/store. C’est la seule manière de supprimer des fichiers de /gnu/store — supprimer des fichiers ou des répertoires à la main peut le casser de manière impossible à réparer !

Le ramasse-miettes a un ensemble de racines connues : tout fichier dans /gnu/store atteignable depuis une racine est considéré comme utilisé et ne peut pas être supprimé ; tous les autres fichiers sont considérés comme inutilisés et peuvent être supprimés. L’ensemble des racines du ramasse-miettes (ou « racines du GC » pour faire court) inclue les profils par défaut des utilisateurs ; par défaut les liens symboliques sous /var/guix/gcroots représentent ces racines du GC. De nouvelles racines du GC peuvent être ajoutées avec la guix build -- root par exemple (voir Invoquer guix build). La commande guix gc --list-roots permet de les lister.

Avant de lancer guix gc --collect-garbage pour faire de la place, c’est souvent utile de supprimer les anciennes génération des profils utilisateurs ; de cette façon les anciennes constructions de paquets référencées par ces générations peuvent être glanées. Cela se fait en lançant guix package --delete-generations (voir Invoquer guix package).

Nous recommandons de lancer le ramasse-miettes régulièrement ou lorsque vous avez besoin d’espace disque. Par exemple pour garantir qu’au moins 5 Go d’espace reste libre sur votre disque, lancez simplement :

guix gc -F 5G

Il est parfaitement possible de le lancer comme une tâche périodique non-interactive (voir Exécution de tâches planifiées pour apprendre comment paramétrer une telle tâche). Lancer guix gc sans argument ramassera autant de miettes que possible mais ça n’est pas le plus pratique : vous pourriez vous retrouver à reconstruire ou re-télécharger des logiciels « inutilisés » du point de vu du GC mais qui sont nécessaires pour construire d’autres logiciels — p. ex. la chaîne de compilation.

La commande guix gc a trois modes d’opération : elle peut être utilisée pour glaner des fichiers inutilisés (par défaut), pour supprimer des fichiers spécifiques (l’option --delete), pour afficher des informations sur le ramasse-miettes ou pour des requêtes plus avancées. Les options du ramasse-miettes sont :

--collect-garbage[=min]

-C [min]

Ramasse les miettes — c.-à-d. les fichiers inaccessibles de /gnu/store et ses sous-répertoires. C’est l’opération par défaut lorsqu’aucune option n’est spécifiée.

Lorsque min est donné, s’arrêter une fois que min octets ont été collectés. min peut être un nombre d’octets ou inclure un suffixe d’unité, comme MiB pour mébioctet et GB pour gigaoctet (voir size specifications dans GNU Coreutils).

Lorsque min est omis, tout glaner.

--free-space=libre

-F libre

Glaner jusqu’à ce que libre espace soit disponible dans /gnu/store si possible ; libre est une quantité de stockage comme 500MiB comme décrit ci-dessus.

Lorsque libre ou plus est disponible dans /gnu/store ne rien faire et s’arrêter immédiatement.

--delete-generations[=durée]

-d [durée]

Avant de commencer le glanage, supprimer toutes les générations plus vielles que durée, pour tous les profils utilisateurs ; lorsque cela est lancé en root, cela s’applique à tous les profils de tous les utilisateurs.

Par exemple, cette commande supprime toutes les générations de tous vos profils plus vieilles que 2 mois (sauf s’il s’agit de la génération actuelle) puis libère de l’espace jusqu’à atteindre au moins 10 Go d’espace libre :

guix gc -d 2m -F 10G

--delete

-D

Essayer de supprimer tous les fichiers et les répertoires du dépôt spécifiés en argument. Cela échoue si certains des fichiers ne sont pas dans le dépôt ou s’ils sont toujours utilisés.

--list-failures

Lister les éléments du dépôt qui correspondent à des échecs de construction.

Cela n’affiche rien à moins que le démon n’ait été démarré avec --cache-failures (voir --cache-failures).

--list-roots

Lister les racines du GC appartenant à l’utilisateur ; lorsque la commande est lancée en root, lister toutes les racines du GC.

--list-busy

Liste des éléments de stockage utilisés par les processus en cours d’exécution. Ces éléments de stockage sont effectivement considérés comme des racines GC : ils ne peuvent pas être supprimés.

--clear-failures

Supprimer les éléments du dépôt spécifiés du cache des constructions échouées.

De nouveau, cette option ne fait de sens que lorsque le démon est démarré avec --cache-failures. Autrement elle ne fait rien.

--list-dead

Montrer la liste des fichiers et des répertoires inutilisés encore présents dans le dépôt — c.-à-d. les fichiers et les répertoires qui ne sont plus atteignables par aucune racine.

--list-live

Montrer la liste des fichiers et des répertoires du dépôt utilisés.

En plus, les références entre les fichiers existants du dépôt peuvent être demandés :

--references

--referrers

Lister les références (respectivement les référents) des fichiers du dépôt en argument.

--requisites

-R

Lister les prérequis des fichiers du dépôt passés en argument. Les prérequis sont le fichier du dépôt lui-même, leur références et les références de ces références, récursivement. En d’autre termes, la liste retournée est la closure transitive des fichiers du dépôt.

Voir Invoquer guix size pour un outil pour surveiller la taille de la closure d’un élément. Voir Invoquer guix graph pour un outil pour visualiser le graphe des références.

--derivers

Renvoie les dérivations menant aux éléments du dépôt donnés (voir Dérivations).

Par exemple cette commande :

guix gc --derivers $(uix package -I ^emacs$ | cut -f4)

renvoie les fichiers .drv menant au paquet emacs installé dans votre profil.

Remarquez qu’il peut n’y avoir aucun fichier .drv par exemple quand ces fichiers ont été glanés. Il peut aussi y avoir plus d’un fichier .drv correspondant à cause de dérivations à sortie fixées.

Enfin, les options suivantes vous permettent de vérifier l’intégrité du dépôt et de contrôler l’utilisation du disque.

--verify[=options]

Vérifier l’intégrité du dépôt.

Par défaut, s’assurer que tous les éléments du dépôt marqués comme valides dans la base de données du démon existent bien dans /gnu/store.

Lorsqu’elle est fournie, l’option doit être une liste séparée par des virgule de l’un ou plus parmi contents et repair.

Lorsque vous passez --verify=contents, le démon calcul le hash du contenu de chaque élément du dépôt et le compare au hash de sa base de données. Les différences de hash sont rapportées comme des corruptions de données. Comme elle traverse tous les fichiers du dépôt, cette commande peut prendre très longtemps pour terminer, surtout sur un système avec un disque lent.

Utiliser --verify=repair ou --verify=contents,repair fait que le démon essaie de réparer les objets du dépôt corrompus en récupérant leurs substituts (voir Substituts). Comme la réparation n’est pas atomique et donc potentiellement dangereuse, elle n’est disponible que pour l’administrateur système. Une alternative plus légère lorsque vous connaissez exactement quelle entrée est corrompue consiste à lancer guix build --repair (voir Invoquer guix build).

--optimize

Optimiser le dépôt en liant en dur les fichiers identiques — c’est la déduplication.

Le démon effectue une déduplication après chaque import d’archive ou construction réussie, à moins qu’il n’ait été lancé avec --disable-deduplication (voir --disable-deduplication). Ainsi, cette option est surtout utile lorsque le démon tourne avec --disable-deduplication.

5.6 Invoquer guix pull

Les paquets sont installés ou mis à jour vers la dernière version disponible dans la distribution active sur votre machine locale. Pour mettre à jour cette distribution, en même temps que les outils Guix, vous devez lancer guix pull ; la commande télécharge le dernier code source de Guix ainsi que des descriptions de paquets, et le déploie. Le code source est téléchargé depuis un dépôt Git, par défaut le dépôt officiel de GNU Guix, bien que cela puisse être personnalisé. guix pull garantit que le code téléchargé est authentique en vérifiant que les commits sont signés par les développeur·euse·s de Guix.

Spécifiquement, guix pull télécharge le code depuis les canaux (voir voir Canaux) spécifiés par un des points suivants, dans cet ordre :

1. l’option --channels ;
2. le fichier utilisateur·rice ~/.config/guix/channels.scm ;
3. le fichier de l’ensemble du système /etc/guix/channels.scm ;
4. les canaux intégrés par défaut spécifiés dans la variable %default-channels.

À la fin, guix package utilisera les paquets et les versions des paquets de la copie de Guix tout juste récupérée. Non seulement ça, mais toutes les commandes Guix et les modules Scheme seront aussi récupérés depuis la dernière version. Les nouvelles sous-commandes de guix ajoutés par la mise à jour sont aussi maintenant disponibles.

Chaque utilisateur peut mettre à jour sa copie de Guix avec guix pull et l’effet est limité à l’utilisateur qui a lancé guix pull. Par exemple, lorsque l’utilisateur root lance guix pull, cela n’a pas d’effet sur la version de Guix que voit alice et vice-versa.

Le résultat après avoir lancé guix pull est un profil disponible sous ~/.config/guix/current contenant la dernière version de Guix. Ainsi, assurez-vous de l’ajouter au début de votre chemin de recherche pour que vous utilisiez la dernière version. Le même conseil s’applique au manuel Info (voir Documentation) :

export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

L’option --list-generations ou -l liste les anciennes générations produites par guix pull, avec des détails sur leur origine :

$ guix pull -l
Génération 1	10 juin 2018 00:18:18
  guix 65956ad
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche : origin/master
    commit : 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Génération 2	11 juin 2018 11:02:49
  guix e0cc7f6
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche : origin/master
    commit : e0cc7f669bec22c37481dd03a7941c7d11a64f1d
  2 nouveaux paquets : keepalived, libnfnetlink
  6 paquets mis à jour : emacs-nix-mode@2.0.4,
    guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac,
    heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4

Génération 3	13 juin 2018 23:31:07	(actuelle)
  guix 844cc1c
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche : origin/master
    commit : 844cc1c8f394f03b404c5bb3aee086922373490c
  28 nouveaux paquets : emacs-helm-ls-git, emacs-helm-mu, …
  69 paquets mis à jour : borg@1.1.6, cheese@3.28.0, …

Voir guix describe, pour d’autres manières de décrire le statut actuel de Guix.

Ce profil ~/.config/guix/current fonctionne comme les profils créés par guix package (voir Invoquer guix package). C’est-à-dire que vous pouvez lister les générations, revenir en arrière à une génération précédente — c.-à-d. la version de Guix précédente — etc. :

$ guix pull --roll-back
passé de la génération 3 à 2
$ guix pull --delete-generations=1
supperssion de /var/guix/profiles/per-user/charlie/current-guix-1-link

Vous pouvez aussi utiliser guix package (voir Invoquer guix package) pour contrôler le profil en le nommant explicitement :

$ guix package -p ~/.config/guix/current --roll-back
passé de la génération 3 à 2
$ guix package -p ~/.config/guix/current --delete-generations=1
suppression de /var/guix/profiles/per-user/charlie/current-guix-1-link

La commande guix pull est typiquement invoquée sans arguments mais elle prend en charge les options suivantes :

--url=url

--commit=commit

--branch=branche

Télécharger le code pour le canal guix depuis l’url spécifié, au commit donné (un commit Git valide représenté par une chaîne hexadécimale) ou à la branche branch.

Ces options sont fournies pour votre confort, mais vous pouvez aussi spécifier votre configuration dans le fichier ~/.config/guix/channels.scm ou en utilisant l’option --channels (voir plus bas).

--channels=file

-C file

Lit la liste des canaux dans file plutôt que dans ~/.config/guix/channels.scm ou /etc/guix/channels.scm. file doit contenir un code Scheme qui s’évalue en une liste d’objets de canaux. Voir Canaux pour plus d’informations.

--news

-N

Afficher la liste des paquets ajoutés ou mis à jour depuis la génération précédente, ainsi que, occasionnellement, les nouvelles écrites par les auteur·e·s des chaînes pour leurs utilisateur·rice·s (voir Writing Channel News).

Les informations sur les paquets sont les mêmes que celles présentées à la fin de guix pull, mais sans les points de suspension, et sont aussi similaires à celles présentées par guix pull -l pour la dernière génération (voir plus bas).

--list-generations[=motif]

-l [motif]

Liste toutes les générations de ~/.config/guix/current ou, si motif est fournit, le sous-ensemble des générations qui correspondent à motif. La syntaxe de motif est la même qu’avec guix package --list-generations (voir Invoquer guix package).

--roll-back

Revenir à la génération précédente de ~/.config/guix/current c.-à-d. défaire la dernière transaction.

--switch-generation=motif

-S motif

Basculer vers une génération particulière définie par le motif.

Le motif peut être soit un numéro de génération soit un nombre précédé de « + » ou « - ». Ce dernier signifie : se déplacer en avant ou en arrière d’un nombre donné de générations. Par exemple, si vous voulez retourner à la dernière génération après --roll-back, utilisez --switch-generation=+1.

--delete-generations[=motif]

-d [motif]

Lorsque motif est omis, supprimer toutes les générations en dehors de l’actuelle.

Cette commande accepte les même motifs que --list-generations. Lorsque motif est spécifié, supprime les générations correspondantes. Lorsque motif spécifie une durée, les générations plus anciennes que la durée spécifiée correspondent. Par exemple --delete-generations=1m supprime les générations vieilles de plus d’un mois.

Si la génération actuelle correspond, elle n’est pas supprimée.

Remarquez que supprimer des générations empêche de revenir en arrière vers elles. Ainsi, cette commande doit être utilisée avec précaution.

Voir Invoquer guix describe, pour une manière d’afficher des informations sur la génération actuelle uniquement.

--profile=profil

-p profil

Utiliser le profil à la place de ~/.config/guix/current.

--dry-run

-n

Montrer quels commits des canaux seraient utilisés et ce qui serait construit ou substitué mais ne pas le faire vraiment.

--allow-downgrades

Permet d’extraire des révisions de canaux plus anciennes ou sans rapport avec celles qui sont actuellement utilisées.

Par défaut, guix pull protège contre les attaques dites de "downgrade", par lesquelles le dépôt Git d’un canal serait réinitialisé à une révision antérieure ou sans rapport avec lui-même, ce qui pourrait vous conduire à installer des versions plus anciennes de paquets logiciels, ou connues pour être vulnérables.

Remarque : Assurez-vous de comprendre les implications de sa sécurité avant d’utiliser --allow-downgrades.

--disable-authentication

Permet de "tirer" le code du canal sans l’authentifier.

Par défaut, guix pull authentifie le code téléchargé depuis les canaux en vérifiant que ses commits sont signés par les développeur·euse·s, et renvoie une erreur si ce n’est pas le cas. Cette option lui enjoint de ne pas effectuer une telle vérification.

Remarque : Assurez-vous de comprendre les implications de sa sécurité avant d’utiliser --disable-authentication.

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

--bootstrap

Utiliser le programme d’amorçage Guile pour construire la dernière version de Guix. Cette option n’est utile qu’aux personnes qui développent Guix.

Le mécanisme de canaux vous permet de dire à guix pull quels répertoires et branches récupérer, ainsi que les dépôts supplémentaires contenant des modules de paquets qui devraient être déployés. Voir Canaux pour plus d’information.

En plus, guix pull supporte toutes les options de construction communes (voir Options de construction communes).

5.7 Invoquer guix time-machine

La commande guix time-machine donne accès à d’autres révisions de Guix, par exemple pour installer d’anciennes versions de paquets, ou pour reproduire un calcul dans un environnement identique. La révision de Guix à utiliser est définie par un commit ou par un fichier de description de canal créé par guix describe (voir Invoquer guix describe).

La syntaxe générale est :

guix time-machine options… -- commande arg…

où command et arg… sont passés sans modification à la commande guix de la révision spécifiée. Les options qui définissent cette révision sont les mêmes que pour la commande guix pull (voir Invoquer guix pull) :

--url=url

--commit=commit

--branch=branche

Utiliser le canal guix depuis l’url spécifiée, au commit donné (un commit Git valide représenté par une chaîne hexadécimale) ou à la branche branch.

--channels=file

-C file

Lit la liste des canaux dans file. file doit contenir un code Scheme qui s’évalue en une liste d’objets de canaux. Voir Canaux pour plus d’informations.

Quant à guix pull, l’absence d’options signifie que le dernier commit sur la branche master sera utilisé. La commande

guix time-machine -- build hello

va donc construire le paquet hello tel que défini dans la branche master, qui est en général une révision de Guix plus récente que celle que vous avez installée. Le voyage dans le temps fonctionne dans les deux sens !

Remarquez que guix time-machine peut lancer des constructions de canaux et de leurs dépendances, et qu’elles peuvent être contrôlées avec les options de construction communes (voir Options de construction communes).

5.8 Inférieurs

Remarque : La fonctionnalité décrite ici est un « démonstrateur technique » à la version 1.3.0. Ainsi, l’interface est sujette à changements.

Parfois vous pourriez avoir à mélanger des paquets de votre révision de Guix avec des paquets disponibles dans une révision différente de Guix. Les inférieurs de Guix vous permettent d’accomplir cette tâche en composant différentes versions de Guix de manière arbitraire.

Techniquement, un « inférieur » est surtout un processus Guix séparé connecté à votre processus Guix principal à travers un REPL (voir Invoquer guix repl). Le module (guix inferior) vous permet de créer des inférieurs et de communiquer avec eux. Il fournit aussi une interface de haut-niveau pour naviguer dans les paquets d’un inférieur — des paquets inférieurs — et les manipuler.

Lorsqu’on les combine avec des canaux (voir Canaux), les inférieurs fournissent une manière simple d’interagir avec un révision de Guix séparée. Par exemple, disons que vous souhaitiez installer dans votre profil le paquet guile actuel, avec le guile-json d’une ancienne révision de Guix — peut-être parce que la nouvelle version de guile-json a une API incompatible et que vous voulez lancer du code avec l’ancienne API. Pour cela, vous pourriez écrire un manifeste à utiliser avec guix package --manifest (voir Invoquer guix package) ; dans ce manifeste, vous créeriez un inférieur pour l’ancienne révision de Guix qui vous intéresse et vous chercheriez le paquet guile-json dans l’inférieur :

(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;pour « first »

(define channels
  ;; L'ancienne révision depuis laquelle on veut
  ;; extraire guile-json.
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; Un inférieur représentant la révision ci-dessus.
  (inferior-for-channels channels))

;; Maintenant on crée un manifeste avec le paquet « guile » actuel
;; et l'ancien paquet « guile-json ».
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

Durant la première exécution, guix package --manifest pourrait avoir besoin de construire le canal que vous avez spécifié avant de créer l’inférieur ; les exécutions suivantes seront bien plus rapides parce que la révision de Guix sera déjà en cache.

Le module (guix inferior) fournit les procédures suivantes pour ouvrir un inférieur :

Procédure Scheme : inferior-for-channels channels [#:cache-directory] [#:ttl]

Renvoie un inférieur pour channels, une liste de canaux. Elle utilise le cache dans cache-directory, où les entrées peuvent être glanées après ttl secondes. Cette procédure ouvre une nouvelle connexion au démon de construction.

Elle a pour effet de bord de construire ou de substituer des binaires pour channels, ce qui peut prendre du temps.

Procédure Scheme : open-inferior directory [#:command "bin/guix"]

Ouvre le Guix inférieur dans directory et lance directory/command repl ou équivalent. Renvoie #f si l’inférieur n’a pas pu être lancé.

Les procédures listées plus bas vous permettent d’obtenir et de manipuler des paquets inférieurs.

Procédure Scheme : inferior-packages inferior

Renvoie la liste des paquets connus de l’inférieur inferior.

Procédure Scheme : lookup-inferior-packages inferior name [version]

Renvoie la liste triée des paquets inférieurs qui correspondent à name dans inferior, avec le plus haut numéro de version en premier. Si version est vrai, renvoie seulement les paquets avec un numéro de version préfixé par version.

Procédure Scheme : inferior-package? obj

Renvoie vrai si obj est un paquet inférieur.

Procédure Scheme : inferior-package-name package

Procédure Scheme : inferior-package-version package

Procédure Scheme : inferior-package-synopsis package

Procédure Scheme : inferior-package-description package

Procédure Scheme : inferior-package-home-page package

Procédure Scheme : inferior-package-location package

Procédure Scheme : inferior-package-inputs package

Procédure Scheme : inferior-package-native-inputs package

Procédure Scheme : inferior-package-propagated-inputs package

Procédure Scheme : inferior-package-transitive-propagated-inputs package

Procédure Scheme : inferior-package-native-search-paths package

Procédure Scheme : inferior-package-transitive-native-search-paths package

Procédure Scheme : inferior-package-search-paths package

Ces procédures sont la contrepartie des accesseurs des enregistrements de paquets (voir référence de package). La plupart fonctionne en effectuant des requêtes à l’inférieur dont provient package, donc l’inférieur doit toujours être disponible lorsque vous appelez ces procédures.

Les paquets inférieurs peuvent être utilisés de manière transparente comme tout autre paquet ou objet simili-fichier dans des G-expressions (voir G-Expressions). Ils sont aussi gérés de manière transparente par la procédure packages->manifest, qui est typiquement utilisée dans des manifestes (voir l’option --manifest de guix package). Ainsi, vous pouvez insérer un paquet inférieur à peu près n’importe où vous utiliseriez un paquet normal : dans des manifestes, dans le champ packages de votre déclaration operating-system, etc.

5.9 Invoquer guix describe

Souvent vous voudrez répondre à des questions comme « quelle révision de Guix j’utilise ? » ou « quels canaux est-ce que j’utilise ? ». C’est une information utile dans de nombreuses situations : si vous voulez répliquer un environnement sur une machine différente ou un compte utilisateur, si vous voulez rapporter un bogue ou pour déterminer quel changement dans les canaux que vous utilisez l’a causé ou si vous voulez enregistrer l’état de votre système pour le reproduire. La commande guix describe répond à ces questions.

Lorsqu’elle est lancée depuis un guix mis à jour avec guix pull, guix describe affiche les canaux qui ont été construits, avec l’URL de leur dépôt et l’ID de leur commit (voir Canaux) :

$ guix describe
Generation 10	03 sep. 2018 17:32:44	(actuelle)
  guix e0fa68c
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche : master
    commit : e0fa68c7718fffd33d81af415279d6ddb518f727

Si vous connaissez bien le système de contrôle de version Git, cela ressemble en essence à git describe ; la sortie est aussi similaire à celle de guix pull --list-generations, mais limitée à la génération actuelle (voir l’option --list-generations). Comme l’ID de commit de Git ci-dessus se réfère sans aucune ambiguïté à un instantané de Guix, cette information est tout ce dont vous avez besoin pour décrire la révision de Guix que vous utilisez et pour la répliquer.

Pour rendre plus facile la réplication de Guix, guix describe peut aussi renvoyer une liste de canaux plutôt que la description lisible par un humain au-dessus :

$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (commit
          "e0fa68c7718fffd33d81af415279d6ddb518f727")))
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
              "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

Vous pouvez sauvegarder ceci dans un fichier et le donner à guix pull -C sur une autre machine ou plus tard, ce qui instantiera exactement la même révision de Guix (voir l’option -C). À partir de là, comme vous pouvez déployer la même révision de Guix, vous pouvez aussi bien répliquer un environnement logiciel complet. Nous pensons humblement que c’est génial, et nous espérons que vous aimerez ça aussi !

Voici les détails des options supportées par guix describe :

--format=format

-f format

Produire la sortie dans le format donné, parmi :

human

produire une sortie lisible par un humain ;

canaux

produire une liste de spécifications de canaux qui peut être passée à guix pull -C ou installée dans ~/.config/guix/channels.scm (voir Invoquer guix pull) ;

channels-sans-intro

comme canaux, mais oubliez le champ introduction ; utilisez-le pour produire une spécification de canal adaptée à la version 1.1.0 ou antérieure de Guix–le champ introduction concerne l’authentification des canaux (voir Channel Authentication) et n’est pas pris en charge par ces versions antérieures ;

json

produire une liste de spécifications de canaux dans le format JSON ;

recutils

produire une liste de spécifications de canaux dans le format Recutils.

--list-formats

Affiche les formats disponibles pour l’option --format.

--profile=profil

-p profil

Afficher les informations sur le profil.

5.10 Invoquer guix archive

La commande guix archive permet aux utilisateurs d’exporter des fichiers du dépôt dans une simple archive puis ensuite de les importer sur une machine qui fait tourner Guix. En particulier, elle permet de transférer des fichiers du dépôt d’une machine vers le dépôt d’une autre machine.

Remarque : Si vous chercher une manière de produire des archives dans un format adapté pour des outils autres que Guix, voir Invoquer guix pack.

Pour exporter des fichiers du dépôt comme une archive sur la sortie standard, lancez :

guix archive --export options spécifications...

spécifications peut être soit des noms de fichiers soit des spécifications de paquets, comme pour guix package (voir Invoquer guix package). Par exemple, la commande suivante crée une archive contenant la sortie gui du paquet git et la sortie principale de emacs :

guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar

Si les paquets spécifiés ne sont pas déjà construits, guix archive les construit automatiquement. Le processus de construction peut être contrôlé avec les options de construction communes (voir Options de construction communes).

Pour transférer le paquet emacs vers une machine connectée en SSH, on pourrait lancer :

guix archive --export -r emacs | ssh la-machine guix archive --import

De même, on peut transférer un profil utilisateur complet d’une machine à une autre comme cela :

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh the-machine guix archive --import

Toutefois, il faut noter que, dans les deux exemples, tous les emacs et le profil, ainsi que toutes leurs dépendances sont transférés (en raison de l’-r), indépendamment de ce qui est déjà disponible dans le dépôt sur la machine cible. L’option --missing peut aider à déterminer quels sont les éléments manquants dans le dépôt cible. La commande guix copy simplifie et optimise tout ce processus, c’est donc probablement ce que vous devriez utiliser dans ce cas (voir Invoquer guix copy).

Chaque élément du dépôt est écrit dans le format archive normalisée ou nar (décrit ci-dessous), et la sortie de guix archive --export (et entrée de guix archive --import) est un nar bundle.

Le format nar est comparable dans l’esprit au format "tar", mais avec des différences qui le rendent plus approprié à nos objectifs. Premièrement, plutôt que d’enregistrer toutes les métadonnées Unix pour chaque fichier, le format nar ne mentionne que le type de fichier (régulier, répertoire ou lien symbolique) ; les autorisations Unix et le propriétaire/groupe sont rejetés. Deuxièmement, l’ordre dans lequel les entrées de répertoire sont stockées, suit toujours celui des noms de fichiers selon leur vérification de concordance des locales C. Cela rend la production d’archives entièrement déterministe.

Ce format de lot nar est surtout la concaténation de zéro, un ou plusieurs nar avec des métadonnées pour chaque élément du dépôt qu’il contient : son nom de fichier, ses références, la dérivation correspondante et une signature numérique.

Lors de l’export, le démon signe numériquement le contenu de l’archive et cette signature est ajoutée à la fin du fichier. Lors de l’import, le démon vérifie la signature et rejette l’import en cas de signature invalide ou si la clef de signature n’est pas autorisée.

Les principales options sont :

--export

Exporter les fichiers ou les paquets spécifiés du dépôt (voir plus bas). Écrire l’archive résultante sur la sortie standard.

Les dépendances ne sont pas incluses dans la sortie à moins que --recursive ne soit passé.

-r

--recursive

En combinaison avec --export, cette option demande à guix archive d’inclure les dépendances des éléments donnés dans l’archive. Ainsi, l’archive résultante est autonome : elle contient la fermeture des éléments de dépôt exportés.

--import

Lire une archive depuis l’entrée standard et importer les fichiers inclus dans le dépôt. Annuler si l’archive a une signature invalide ou si elle est signée par une clef publique qui ne se trouve pas dans le clefs autorisées (voir --authorize plus bas).

--missing

Liste une liste de noms de fichiers du dépôt sur l’entrée standard, un par ligne, et écrit sur l’entrée standard le sous-ensemble de ces fichiers qui manquent dans le dépôt.

--generate-key[=paramètres]

Génére une nouvelle paire de clefs pour le démon. C’ est un prérequis avant que les archives ne puissent être exportées avec --export. Cette opération est habituellement instantanée mais elle peut prendre du temps parce qu’elle doit récupérer suffisamment d’entropie pour générer la paire de clefs. Sur Guix System, guix-service-typeprend soin de générer cette paire de clés au premier démarrage.

La paire de clés générée est typiquement stockée dans /etc/guix, dans signing-key.pub (clé publique) et signing-key.sec (clé privée, qui doit rester secrète). Lorsque paramètres est omis, une clé ECDSA utilisant la courbe Ed25519 est générée, ou pour les version de libgcrypt avant 1.6.0, une clé RSA de 4096 bits. Autrement, paramètres peut spécifier les paramètres genkey adaptés pour libgcrypt (voir gcry_pk_genkey dans The Libgcrypt Reference Manual).

--authorize

Autoriser les imports signés par la clef publique passée sur l’entrée standard. La clef publique doit être au « format avancé s-expression » — c.-à-d. le même format que le fichier signing-key.pub.

La liste des clés autorisées est gardée dans un fichier modifiable par des humains dans /etc/guix/acl. Le fichier contient des « s-expressions au format avancé » et est structuré comme une liste de contrôle d’accès dans l’infrastructure à clefs publiques simple (SPKI).

--extract=répertoire

-x répertoire

Lit une archive à un seul élément telle que servie par un serveur de substituts (voir Substituts) et l’extrait dans répertoire. C’est une opération de bas niveau requise seulement dans de rares cas d’usage ; voir plus loin.

Par exemple, la commande suivante extrait le substitut pour Emacs servi par ci.guix.gnu.org dans /tmp/emacs :

$ wget -O - \
  https://ci.guix.gnu.org/nar/gzip/…-emacs-24.5 \
  | gunzip | guix archive -x /tmp/emacs

Les archives à un seul élément sont différentes des archives à plusieurs éléments produites par guix archive --export ; elles contiennent un seul élément du dépôt et elles n’embarquent pas de signature. Ainsi cette opération ne vérifie pas de signature et sa sortie devrait être considérée comme non sûre.

Le but principal de cette opération est de faciliter l’inspection du contenu des archives venant de serveurs auxquels on ne fait potentiellement pas confiance. (voir Invoquer guix challenge).

--list

-t

Lit une archive à un seul élément telle que servie par un serveur de substituts (voir Substituts) et affiche la liste des fichiers qu’elle contient, comme dans cet exemple :

$ wget -O - \
  https://ci.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

6 Canaux

Guix et sa collection de paquets sont mis à jour en lançant guix pull (voir Invoquer guix pull). Par défaut guix pull télécharge et déploie Guix lui-même depuis le dépôt officiel de GNU Guix. Cela peut être personnalisé en définissant des canaux dans le fichier ~/.config/guix/channels.scm. Un canal spécifie l’URL et la branche d’un répertoire Git à déployer et on peut demander à guix pull de récupérer un ou plusieurs canaux. En d’autres termes, les canaux peuvent être utilisés pour personnaliser et pour étendre Guix, comme on le verra plus bas. Guix est en mesure de prendre en compte les préoccupations de sécurité et de traiter les mises à jour authentifiées.

6.1 Spécifier des canaux supplémentaires

Vous pouvez spécifier des canaux supplémentaires à utiliser. Pour utiliser un canal, écrivez dans ~/.config/guix/channels.scm pour dire à guix pull de récupérer votre canal personnel en plus des canaux par défaut de Guix :

;; Ajouter des variantes de paquets à ceux fournis par Guix.
(cons (channel
        (name 'my-personal-packages)
        (url "https://example.org/personal-packages.git"))
      %default-channels)

Remarquez que le bout de code au-dessus est (comme toujours !) du code Scheme ; nous utilisons cons pour ajouter un canal à la liste des canaux que la variable %default-channels représente (voir cons and lists dans GNU Guile Reference Manual). Avec ce fichier en place, guix pull construit non seulement Guix mais aussi les modules de paquets de votre propre dépôt. Le résultat dans ~/.config/guix/current est l’union de Guix et de vos propres modules de paquets :

$ guix pull --list-generations
…
Génération 19	Aug 27 2018 16:20:48
  guix d894ab8
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche : master
    commit : d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  variant-packages dd3df5e
    URL du dépôt : https://example.org/personal-packages.git
    branche : master
    commit : dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
  11 nouveaux paquets : variant-gimp, variant-emacs-with-cool-features, …
  4 paquets mis à jour : emacs-racket-mode@0.0.2-2.1b78827, …

La sortie de guix pull ci-dessus montre que la génération 19 contient aussi bien Guix que les paquets du canal variant-packages. Parmi les nouveaux paquets et les paquets mis à jour qui sont listés, certains comme variant-gimp et variant-emacs-with-cool-features peuvent provenir de variant-packages, tandis que d’autres viennent du canal par défaut de Guix.

6.2 Utiliser un canal Guix personnalisé

Le canal nommé guix spécifie où Guix lui-même — ses outils en ligne de commande ainsi que sa collection de paquets — seront téléchargés. Par exemple, supposons que vous voulez effectuer les mises à jour depuis votre propre copie du dépôt Guix sur example.org, et plus particulièrement depuis la branche super-hacks. Vous pouvez écrire cette spécification dans ~/.config/guix/channels.scm :

;; Dit à « guix pull » d'utiliser un autre dépôt.
(list (channel
        (name 'guix)
        (url "https://example.org/my-guix.git")
        (branch "super-hacks")))

Maintenant, guix pull récupérera le code depuis la branche super-hacks du dépôt sur example.org. La question de l’authentification est traitée ci-dessous ((voir Authentification des canaux).

6.3 Répliquer Guix

La sortie de guix pull --list-generations ci-dessus montre précisément quels commits ont été utilisés pour construire cette instance de Guix. Nous pouvons donc la répliquer, disons sur une autre machine, en fournissant une spécification de canal dans ~/.config/guix/channels.scm qui est « épinglé » à ces commits :

;; Déployer des commits précis de mes canaux préférés.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "6298c3ffd9654d3231a6f25390b056483e8f407c"))
      (channel
       (name 'variant-packages)
       (url "https://example.org/variant-packages.git")
       (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

La commande guix describe --format=channels peut même générer cette liste de canaux directement (voir Invoquer guix describe). Le fichier qui en résulte peut être utilisé avec l’option -C de guix pull (voir Invoquer guix pull) ou guix time-machine (voir Invoquer guix time-machine).

À ce moment les deux machines font tourner exactement le même Guix, avec l’accès exactement aux même paquets. La sortie de guix build gimp sur une machine sera exactement la même, au bit près, que la sortie de la même commande sur l’autre machine. Cela signifie aussi que les deux machines ont accès à tous les codes sources de Guix, et transitivement, à tous les codes sources de tous les paquets qu’il définit.

Cela vous donne des super-pouvoirs, ce qui vous permet de suivre la provenance des artefacts binaires avec un grain très fin et de reproduire les environnements logiciels à volonté — une sorte de capacité de « méta-reproductibilité », si vous voulez. Voir Inférieurs, pour une autre manière d’utiliser ces super-pouvoirs.

6.4 Authentification des canaux

Les commandes guix pull et guix time-machine authenticate téléchargent et contrôlent le code récupéré sur les canaux : elles s’assurent que chaque commit récupéré est signé par un·e développeur·euse autorisé·e. L’objectif est de protéger contre les modifications non autorisées du canal qui conduiraient les utilisateur·rice·s à exécuter du code malveillant.

En tant qu’utilisateur, vous devez fournir une introduction de canal dans votre fichier de canaux afin que Guix sache comment authentifier son premier commit. Une spécification de canal, y compris son introduction, ressemble à quelque chose de ce genre :

(channel
  (name 'some-channel)
  (url "https://example.org/some-channel.git")
  (introduction
   (make-channel-introduction
    "6f0d8cc0d88abb59c324b2990bfee2876016bb86"
    (openpgp-fingerprint
     "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))

La spécification ci-dessus indique le nom et l’URL du canal. L’appel à make-channel-introduction ci-dessus spécifie que l’authentification de ce canal commence au commit 6f0d8cc…, qui est signé par la clé OpenPGP avec l’empreinte digitale CABB A931….

Pour le canal principal, appelé guix, vous obtenez automatiquement cette information à partir de votre installation de Guix. Pour les autres canaux, incluez l’introduction du canal fournie par les auteurs du canal dans votre fichier channels.scm. Assurez-vous de récupérer l’introduction du canal à partir d’une source fiable, car c’est la base de votre confiance.

Si vous êtes curieux·euse à propos des mécanismes d’authentification, lisez !

6.5 Canaux avec des substituts

Lorsque vous lancez guix pull, Guix compilera d’abord les définitions de tous les paquets disponibles. C’est une opération coûteuse pour laquelle des substituts (voir Substituts) peuvent être disponibles. L’extrait de code suivant dans channels.scm s’assure que guix pull utilise le dernier commit pour lequel des substituts sont disponibles pour les définitions des paquets : pour cela, on demande au serveur d’intégration continue https://ci.guix.gnu.org.

(use-modules (guix ci))

(list (channel-with-substitutes-available
       %default-guix-channel
       "https://ci.guix.gnu.org"))

Remarquez que cela ne signifie pas que tous les paquets que vous installerez après avoir lancé guix pull auront des substituts. Cela s’assure uniquement que guix pull n’essaiera pas de compiler les définitions des paquets. C’est particulièrement pratique si vous utilisez une machine avec des ressources limitées.

6.6 Écrire de nouveaux de canaux

Disons que vous avez un ensemble de paquets personnels ou de variantes personnalisées dont vous pensez qu’il ne vaudrait pas le coup de contribuer au projet Guix, mais que vous voudriez pouvoir utiliser de manière transparente sur la ligne de commande : vous écririez d’abord des modules contenant ces définitions de paquets (voir Modules de paquets), en les maintenant dans un dépôt Git, puis vous ou n’importe qui d’autre pourrait l’utiliser comme un canal supplémentaire où trouver ces paquets. Sympa, non ?

Attention : Avant que vous, cher utilisateur, ne vous exclamiez « Oh mais c’est super génial ! » et que vous ne publiez vos canaux personnels publiquement, nous voudrions vous donner quelques avertissements :

• Avant de publier un canal, envisagez de contribuer vos définitions de paquets dans Guix (voir Contribuer). Guix en tant que projet est ouvert à tous les logiciels libres de toutes sortes, et les paquets dans Guix sont déjà disponibles à tous les utilisateurs de Guix et bénéficient des processus d’assurance qualité du projet.
• Lorsque vous maintenez des définitions de paquets en dehors de Guix, nous, les développeur·euse·s de Guix, considérons que la charge de la compatibilité vous incombe. Rappelez-vous que les modules de paquets et les définitions de paquets ne sont que du code Scheme qui utilise diverses interfaces de programmation (API). Nous souhaitons rester libres de changer ces API pour continuer à améliorer Guix, éventuellement d’une manière qui casse votre canal. Nous ne changeons jamais l’API gratuitement, mais nous ne nous engageons pas à geler les API non plus.
• Corollaire : si vous utilisez un canal externe et que le canal est cassé, merci de rapporter le problème à l’auteur du canal, pas au projet Guix.

Vous avez été prévenus ! Maintenant, nous pensons que des canaux externes sont une manière pratique d’exercer votre liberté pour augmenter la collection de paquets de Guix et de partager vos améliorations, qui sont les principes de bases du logiciel libre. Contactez-nous par courriel sur guix-devel@gnu.org si vous souhaitez discuter à ce propos.

Pour créer un canal, créez un dépôt Git contenant vos propres modules de paquets et rendez-le disponible. Le dépôt peut contenir tout ce que vous voulez, mais un canal utile contiendra des modules Guile qui exportent des paquets. Une fois que vous avez démarré un canal, Guix se comportera comme si le répertoire de la racine du dépôt Git de ce canal était ajouté au chemin de chargement de Guile (voir Load Paths dans GNU Guile Reference Manual). Par exemple, si votre canal contient un fichier mes-paquets/mes-outils.scm qui définit un module Guile, le module sera disponible sous le nom de (mes-paquets mes-outils) et vous pourrez l’utiliser comme les autres modules (voir Modules dans GNU Guile Reference Manual).

En tant qu’auteur.e d’un canal, envisagez de regrouper le nécessaire d’authentification avec votre canal afin que les utilisatrice·eur·s puissent l’authentifier. Voir Authentification des canaux, et Spécifier les autorisations des canaux, pour savoir comment les utiliser.

6.7 Modules de paquets dans un sous-répertoire

En tant qu’auteur.e d’un canal, vous voudriez garder vos modules de canal dans un sous-répertoire. Si vos modules sont dans le sous-répertoire guix, vous devez ajouter un fichier de métadonnées .guix-channel qui contient :

(channel
  (version 0)
  (directory "guix"))

6.8 Déclarer des dépendances de canaux

Les auteurs de canaux peuvent décider d’augmenter une collection de paquets fournie par d’autres canaux. Ils peuvent déclarer leur canal comme dépendant d’autres canaux dans le fichier de métadonnées .guix-channel qui doit être placé à la racine de dépôt du canal.

Le fichier de métadonnées devrait contenir une S-expression simple comme cela :

(channel
 (version 0)
 (dependencies
  (channel
   (name some-collection)
   (url "https://example.org/first-collection.git")

   ;; La partie « introduction » ci-dessous est facultative : vous la
   ;; fournissez pour les dépendances qui peuvent être authentifiées.
   (introduction
    (channel-introduction
      (version 0)
      (commit "a8883b58dc82e167c96506cf05095f37c2c2c6cd")
      (signer "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))
  (channel
   (name some-other-collection)
   (url "https://example.org/second-collection.git")
   (branch "testing"))))

Dans l’exemple ci-dessus, ce canal est déclaré comme dépendant de deux autres canaux, qui seront récupérés automatiquement. Les modules fournis par le canal seront compilés dans un environnement où les modules de tous les canaux déclarés sont disponibles.

Pour des raisons de fiabilité et de maintenabilité, vous devriez éviter d’avoir des dépendances sur des canaux que vous ne maîtrisez pas et vous devriez ajouter le minimum de dépendances possible.

6.9 Spécifier les autorisations des canaux

Comme nous l’avons vu plus haut, Guix garantit le code source qu’il récupère depuis les canaux venant de développeur·euse·s autorisé·e·s. En tant qu’auteur.e, vous devez spécifiez la liste des développeur·euse·s autorisé·e·s dans le fichier .guix-authorizations dans le dépôt Git des canaux. Le rôle de l’authentification est simple : chaque commit doit être signé par une clé listée dans le fichier .guix-authorizations de son (ses) commit(s) parent(s)¹⁰ Le fichier .guix-authorizations ressemble à ceci :

;; Fichier d'exemple '.guix-authorizations'.

(authorizations
 (version 0)               ;version actuelle du format de fichier

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alice"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "bob"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "charlie"))))

Chaque empreinte digitale est suivie de paires de clés/valeurs facultatives, comme dans l’exemple ci-dessus. Actuellement, ces paires clé/valeur sont ignorées.

Ce rôle d’authentification crée un problème de poule-et-oeuf : comment authentifions-nous le premier commit ? Relatif à celà : comment traiter les canaux dont l’historique du dépôt contient des commits non signés et qui n’ont pas de.guix-authorisations ? Et comment bifurquer des canaux existants ?

Les présentations de canaux répondent à ces questions en décrivant le premier commit d’un canal qui doit être authentifiée. La première fois qu’un canal est récupéré avec guix pull ou guix time-machine, la commande recherche le commit d’introduction et vérifie qu’il est signé par la clé OpenPGP spécifiée. Elle authentifie ensuite les commits selon la règle ci-dessus.

De plus, votre canal doit fournir toutes les clés OpenPGP qui ont été mentionnées dans les fichiers .guix-authorizations, stockés dans les fichiers .key, qui peuvent être soit binaires soit "blindés ASCII". Par défaut, ces fichiers .key sont recherchés dans la branche nommée keyring, mais vous pouvez spécifier un nom de branche différent dans .guix-channel de cette façon :

(channel
  (version 0)
  (keyring-reference "my-keyring-branch"))

En résumé, en tant qu’auteur.e d’une chaîne, il y a trois choses que vous devez faire pour permettre aux utilisateur·rice·s d’authentifier votre code :

1. Exporter les clés OpenPGP des committers passés et présents avec gpg -export et les stocker dans des fichiers .key, par défaut dans une branche nommée keyring (nous recommandons d’en faire une branche orpheline).
2. Introduisez un fichier .guix-authorisations initial dans le dépôt du canal. Faites cela dans un commit signé (voir Accès en commit, pour savoir comment signer les commit Git).
3. Annoncez l’introduction du canal, par exemple sur la page web de votre canal. L’introduction du canal, comme nous l’avons vu ci-dessus, est la paire de clés commit—c’est-à-dire le commit qui a introduit .guix-authorizations, et l’empreinte digitale de l’OpenPGP utilisé pour le signer.

Avant de pousser vers votre dépôt Git public, vous pouvez lancer guix git-authenticate pour vérifier que vous avez bien signé tous les commits que vous allez pousser avec une clé autorisée :

guix git authenticate commit signer

où commit et signer sont votre présentation de canal. Voir Invoquer guix git authenticate, pour plus de détails.

Publier un canal signé demande de la discipline : toute faute, comme un commit non signé ou un commit signée par une clé non autorisée, vont empêcher les utilisateur·rice·s de récupérer depuis votre canal—bref, c’est tout l’intérêt de l’authentification ! Faites particulièrement attention aux merges : les merge commits sont considérés comme authentiques si et seulement s’ils sont signés par une clé présente dans le fichier .guix-authorizations des branches both.

6.10 URL primaire

Les auteur.e.s de canaux peuvent indiquer l’URL principale de leur dépôt Git de canal dans le fichier .guix-channel comme ceci :

(channel
  (version 0)
  (url "https://example.org/guix.git"))

Cela permet à guix pull de déterminer si elle récupère du code d’un miroir du canal ; lorsque c’est le cas, elle avertit l’utilisateur·rice que le miroir pourrait être périmé et affiche l’URL primaire. De cette façon, les utilisateur·rice·s ne peuvent pas être amené·e·s à extraire du code d’un miroir périmé qui ne reçoit pas les mises à jour de sécurité.

Cette fonctionnalité n’a de sens que pour les dépôts authentifiés, tels que le canal officiel guix, pour lequel guix pull garantit l’authenticité du code qu’il récupère.

6.11 Écrire des nouveautés de canaux

Les auteur.e.s de canaux peuvent occasionnellement vouloir communiquer à leurs utilisateur·rice·s des informations au sujet de changements importants dans le canal. Vous pourriez leur envoyer un courriel, mais ce n’est pas pratique.

Au lieu de celà, les canaux peuvent fournir un fichier de nouvelles ; lorsque les utilisateur·rice·s du canal exécutent guix pull, ce fichier de nouvelles est automatiquement lu et guix pull --news peut afficher les annonces qui correspondent aux nouveaux commits qui ont été récupérés, le cas échéant.

Pour faire celà, les auteur.e.s de canal doivent en premier lieu déclarer le nom du fichier de nouvelles dans leur fichier .guix-channel :

(channel
  (version 0)
  (news-file "etc/news.txt"))

Le fichier de nouvelles lui-même, etc/news.txt dans cet exemple, doit ressembler à quelque chose comme ceci :

(channel-news
  (version 0)
  (entry (tag "the-bug-fix")
         (title (en "Fixed terrible bug")
                (fr "Oh la la"))
         (body (en "@emph{Good news}!  It's fixed!")
               (eo "Certe ĝi pli bone funkcias nun!")))
  (entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
         (title (en "Added a great package")
                (ca "Què vol dir guix?"))
         (body (en "Don't miss the @code{hello} package!"))))

Tandis que le fichier de nouvelles utilise la syntaxe Scheme, évitez de le nommer avec une extension .scm, sinon il sera récupéré lors de la construction du canal et produira une erreur puisqu’il ne s’agit pas d’un module valide. Vous pouvez également déplacer le module du canal dans un sous-répertoire et stocker le fichier de nouvelles dans un autre répertoire.

Le fichier consiste en une liste de news entries. Chaque entrée est associée à un commit ou un tag : elle décrit les changements faits dans ce commit, éventuellement dans les commits précédents comme il faut. Les utilisateur·rice·s ne voient les entrées que la première fois qu’il·elle·s obtiennent le commit auquel l’entrée se réfère.

Le titre doit être un résumé d’une ligne tandis que body peut être arbitrairement long, et les deux peuvent contenir des balises Texinfo (voir Overview dans GNU Texinfo). Le titre et le corps sont tous deux une liste de tuples de balises/messages de langue, ce qui permet à guix pull d’afficher les nouvelles dans la langue qui correspond à la locale de l’utilisateur.

Si vous souhaitez traduire des actualités en utilisant un déroulement basé sur gettext, vous pouvez extraire des chaînes traduisibles avec xgettext (voir xgettext Invocation dans GNU Gettext Utilities). Par exemple, en supposant que vous écriviez d’abord les entrées de nouvelles en anglais, la commande ci-dessous crée un fichier PO contenant les chaînes à traduire :

xgettext -o news.po -l scheme -ken etc/news.txt

Pour résumer, oui, vous pourriez utiliser votre chaîne comme un blog. Mais attention, ce n’est pas tout à fait ce à quoi vos utilisateur·rice·s pourraient s’attendre.

7 Développement

Si vous êtes développeur de logiciels, Guix fournit des outils que vous devriez trouver utiles — indépendamment du langage dans lequel vous développez. C’est ce dont parle ce chapitre.

La commande guix environment permet de créer des environnements de développement confortables contenant toutes les dépendances et les outils nécessaires pour travailler sur le paquet logiciel de votre choix. La commande guix pack vous permet de créer des lots applicatifs qui peuvent facilement être distribués à des utilisateurs qui n’utilisent pas Guix.

7.1 Invoquer guix environment

Le but de guix environment est d’assister les hackers dans la création d’environnements de développement reproductibles sans polluer leur profil de paquets. L’outil guix environment prend un ou plusieurs paquets, construit leurs entrées et crée un environnement shell pour pouvoir les utiliser.

La syntaxe générale est :

guix environment options paquet…

L’exemple suivant crée un nouveau shell préparé pour le développement de GNU Guile :

guix environment guile

Si les dépendances requises ne sont pas déjà construites, guix environment les construit automatiquement. L’environnement du nouveau shell est une version améliorée de l’environnement dans lequel guix environment a été lancé. Il contient les chemins de recherche nécessaires à la construction du paquet donné en plus des variables d’environnement existantes. Pour créer un environnement « pur », dans lequel les variables d’environnement de départ ont été nettoyées, utilisez l’option --pure¹¹.

Sortir d’un environnement Guix est comme sortir du shell, et cela vous replacera dans l’ancien environnement avant d’avoir invoqué la commande guix environment. Au prochain lancement du ramasse-miettes (voir Invoquer guix gc), les paquets installés pour l’environnement seront supprimés et ne seront plus disponibles en dehors de celui-ci.

guix environment définie la variable GUIX_ENVIRONMENT dans le shell qu’il crée ; sa valeur est le nom de fichier du profil de cet environnement. Cela permet aux utilisatrice·eur·s, disons, de définir un prompt spécifique pour les environnement de développement dans leur .bashrc (voir Bash Startup Files dans The GNU Bash Reference Manual) :

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

… ou de naviguer dans le profil :

$ ls "$GUIX_ENVIRONMENT/bin"

De surcroît, plus d’un paquet peut être spécifié, auquel cas l’union des entrées des paquets données est utilisée. Par exemple, la commande ci-dessous crée un shell où toutes les dépendances de Guile et Emacs sont disponibles :

guix environment guile emacs

Parfois, une session shell interactive est inutile. On peut invoquer une commande arbitraire en plaçant le jeton -- pour séparer la commande du reste des arguments :

guix environment guile -- make -j4

Dans d’autres situations, il est plus pratique de spécifier la liste des paquets requis dans l’environnement. Par exemple, la commande suivante lance python dans un environnement contenant Python 2.7 et NumPy :

guix environment --ad-hoc python2-numpy python-2.7 -- python

En plus, on peut vouloir les dépendance d’un paquet et aussi des paquets supplémentaires qui ne sont pas des dépendances à l’exécution ou à la construction, mais qui sont utiles au développement tout de même. À cause de cela, le tag --ad-hoc est positionnel. Les paquets qui apparaissent avant --ad-hoc sont interprétés comme les paquets dont les dépendances seront ajoutées à l’environnement. Les paquets qui apparaissent après --ad-hoc sont interprétés comme les paquets à ajouter à l’environnement directement. Par exemple, la commande suivante crée un environnement de développement pour Guix avec les paquets Git et strace en plus :

guix environment --pure guix --ad-hoc git strace

Parfois il est souhaitable d’isoler l’environnement le plus possible, pour une pureté et une reproductibilité maximale. En particulier, lorsque vous utilisez Guix sur une distribution hôte qui n’est pas le système Guix, il est souhaitable d’éviter l’accès à /usr/bin et d’autres ressources du système depuis les environnements de développement. Par exemple, la commande suivante crée un REPL Guile dans un « conteneur » où seuls le dépôt et le répertoire de travail actuel sont montés :

guix environment --ad-hoc --container guile -- guile

Remarque : L’option --container requiert Linux-libre 3.19 ou supérieur.

Un autre cas d’usage typique pour les conteneurs est de lancer des applications sensibles à la sécurité, comme un navigateur web. Pour faire fonctionner Eolie, nous devons exposer et partager certains fichiers et répertoires ; nous incluons nss-certs et exposons /etc/ssl/certs/ pour l’authentification HTTPS ; enfin, nous préservons la variable d’environnement DISPLAY puisque les applications graphiques conteneurisées ne s’afficheront pas sans elle.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

Les options disponibles sont résumées ci-dessous.

--root=fichier

-r fichier

Fait de fichier un lien symbolique vers le profil de cet environnement, et l’enregistre comme une racine du ramasse-miettes.

C’est utile si vous souhaitez protéger votre environnement du ramasse-miettes, pour le rendre « persistent ».

Lorsque cette option est omise, l’environnement n’est protégé du ramasse-miettes que le temps de la session guix environment. Cela signifie que la prochaine fois que vous créerez le même environnement, vous pourriez avoir à reconstruire ou télécharger des paquets. Voir Invoquer guix gc, pour plus d’informations sur les racines du GC.

--expression=expr

-e expr

Crée un environnement pour le paquet ou la liste de paquets en lesquels s’évalue expr.

Par exemple, lancer :

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

démarre un shell avec l’environnement pour cette variante spécifique du paquet PETSc.

Lancer :

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

démarre un shell où tous les paquets de base du système sont disponibles.

Les commande au-dessus n’utilisent que les sorties par défaut des paquets donnés. Pour choisir d’autres sorties, on peut spécifier des pairs :

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=fichier

-l fichier

Crée un environnement pour le paquet ou la liste de paquets en lesquels fichier s’évalue.

Par exemple, fichier peut contenir une définition comme celle-ci (voir Définition des paquets) :

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package (inherit gdb)
  (native-inputs `(("autoconf" ,autoconf-2.64)
                   ("automake" ,automake)
                   ("texinfo" ,texinfo)
                   ,@(package-native-inputs gdb))))

--manifest=fichier

-m fichier

Crée un environnement pour 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.

C’est similaire à l’option de même nom de guix package (voir --manifest) et utilise les même fichiers manifestes.

--ad-hoc

Inclut tous les paquets spécifiés dans l’environnement qui en résulte, comme si un paquet ad hoc était spécifié, avec ces paquets comme entrées. Cette option est utile pour créer un environnement rapidement sans avoir à écrire une expression de paquet contenant les entrées désirées.

Par exemple la commande :

guix environment --ad-hoc guile guile-sdl -- guile

lance guile dans un environnement où Guile et Guile-SDDL sont disponibles.

Remarquez que cet exemple demande implicitement la sortie par défaut de guile et guile-sdl, mais il est possible de demander une sortie spécifique — p. ex. glib:bin demande la sortie bin de glib (voir Des paquets avec plusieurs résultats).

Cette option peut être composée avec le comportement par défaut de guix environment. Les paquets qui apparaissent avant --ad-hoc sont interprétés comme les paquets dont les dépendances seront ajoutées à l’environnement, le comportement par défaut. Les paquets qui apparaissent après --ad-hoc sont interprétés comme les paquets à ajouter à l’environnement directement.

--pure

Réinitialisation des variables d’environnement existantes lors de la construction du nouvel environnement, sauf celles spécifiées avec l’option --preserve. (voir ci-dessous). Cela a pour effet de créer un environnement dans lequel les chemins de recherche ne contiennent que des entrées de paquets.

--preserve=regexp

-E regexp

Lorsque vous utilisez --pure, préserver les variables d’environnement qui correspondent à regexp — en d’autres termes, cela les met en « liste blanche » de variables d’environnement qui doivent être préservées. Cette option peut être répétée plusieurs fois.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

Cet exemple exécute mpirun dans un contexte où les seules variables d’environnement définies sont PATH, les variables d’environnement dont le nom commence par ‘SLURM’, ainsi que les variables « importantes » habituelles (HOME, USER, etc.).

--search-paths

Affiche les définitions des variables d’environnement qui composent l’environnement.

--system=système

-s système

Essaye de construire pour système — p. ex. i686-linux.

--container

-C

Lance commande dans un conteneur isolé. Le répertoire de travail actuel en dehors du conteneur est monté dans le conteneur. En plus, à moins de le changer avec --user, un répertoire personnel fictif est créé pour correspondre à celui de l’utilisateur·rice actuel·le et /etc/passwd est configuré en conséquence.

Le processus de création s’exécute en tant qu’utilisateur·rice actuel·le à l’extérieur du conteneur. À l’intérieur du conteneur, il possède les mêmes UID et GID que l’utilisateur·rice actuel·le, sauf si l’option --user est passée (voir ci-dessous).

--network

-N

Pour les conteneurs, partage l’espace de nom du réseau avec le système hôte. Les conteneurs créés sans cette option n’ont accès qu’à l’interface de boucle locale.

--link-profile

-P

Pour les conteneurs, liez le profil d’environnement à ~/.guix-profile à l’intérieur du conteneur et définissez GUIX_ENVIRONNEMENT à cet endroit. Cela équivaut à faire de ~/.guix-profile un lien symbolique vers le profil réel à l’intérieur du conteneur. La liaison échouera et interrompra l’environnement si le répertoire existe déjà, ce qui sera certainement le cas si guix environment a été invoqué dans le répertoire personnel de l’utilisateur·rice.

Certains paquets sont configurés pour chercher des fichiers de configuration et des données dans ~/.guix-profile ; ¹² ; --link-profile permet à ces programmes de se comporter comme attendu dans l’environnement.

--user=utilisateur

-u utilisateur

Pour les conteneurs, utilise le nom d’utilisateur utilisateur à la place de l’utilisateur actuel. L’entrée générée dans /etc/passwd dans le conteneur contiendra le nom utilisateur ; le répertoire personnel sera /home/utilisateur ; et aucune donnée GECOS ne sera copiée. En plus, l’UID et le GID dans le conteneur seront 1000. user n’a pas besoin d’exister sur le système.

En plus, tous les chemins partagés ou exposés (voir --share et --expose respectivement) dont la cible est dans le répertoire personnel de l’utilisateur·rice seront remontés relativement à /home/USER ; cela comprend le montage automatique du répertoire de travail actuel.

# exposera les chemins comme /home/foo/wd, /home/foo/test et /home/foo/target
cd $HOME/wd
guix environment --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Bien que cela limite la fuite de l’identité de l’utilisateur à travers le chemin du répertoire personnel et des champs de l’utilisateur, ce n’est qu’un composant utile pour une solution d’anonymisation ou de préservation de la vie privée — pas une solution en elle-même.

--no-cwd

Pour les conteneurs, le comportement par défaut est de partager le répertoire de travail actuel avec le conteneur isolé et de passer immédiatement à ce répertoire à l’intérieur du conteneur. Si cela n’est pas souhaitable, --no-cwd fera en sorte que le répertoire de travail courant soit automatiquement partagé not et passera au répertoire personnel de l’utilisateur·rice dans le conteneur à la place. Voir aussi --user.

--expose=source[=cible]

--share=source[=cible]

Pour les conteneurs, --expose (resp. --share) expose le système de fichiers source du système hôte comme un système de fichiers target en lecture seule (resp. en lecture-écriture) dans le conteneur. Si target n’est pas spécifiée, source est utilisé comme point de montage dans le conteneur.

L’exemple ci-dessous crée un REPL Guile dans un conteneur dans lequel le répertoire personnel de l’utilisateur est accessible en lecture-seule via le répertoire /exchange :

guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile

En plus, guix environment prend en charge toutes les options de construction communes prises en charge par guix build (voir Options de construction communes) et toutes les options de transformation de paquets (voir Options de transformation de paquets).

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

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

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

7.3 La chaîne d’outils GCC

Guix offre des paquets de compilateurs individuels comme gcc mais si vous avez besoin d’une chaîne de compilation complète pour compiler et lier du code source, utilisez le paquet gcc-toolchain. Ce paquet fournit une chaîne d’outils complète GCC pour le développement C/C++, dont GCC lui-même, la bibliothèque C de GNU (les en-têtes et les binaires, plus les symboles de débogage dans la sortie debug), Binutils et un wrapper pour l’éditeur de liens.

Le rôle de l’enveloppe est d’inspecter les paramètres -L et -l passés à l’éditeur de liens, d’ajouter des arguments -rpath correspondants et d’invoquer l’actuel éditeur de liens avec ce nouvel ensemble d’arguments. Vous pouvez dire au wrapper de refuser de lier les programmes à des bibliothèques en dehors du dépôt en paramétrant la variable d’environnement GUIX_LD_WRAPPER_ALLOW_IMPURITIES sur no.

Le paquet gfortran-toolchain fournit une chaîne d’outils GCC complète pour le développement en Fortran. Pour d’autres langages, veuillez utiliser ‘guix search gcc toolchain’ (voir Invoquer guix package).

7.4 Invoquer guix git authenticate

La commande guix git authenticate authentifie un checkout Git en suivant la même règle que pour les canaux (voir channel authentication). C’est-à-dire qu’à partir d’un commit donné, il s’assure que tous les commit suivants sont signés par une clé OpenPGP dont l’empreinte digitale apparaît dans le fichier .guix-authorizations de son ou ses commit(s) parent(s).

Vous allez trouver cette commande utile si vous maintenez un canal. Mais en fait, ce mécanisme d’authentification est utile dans un contexte plus large, Vous pourriez donc vouloir l’utiliser pour des dépôts Git qui n’ont rien à voir avec Guix.

La syntaxe générale est :

guix git authenticate commit signer [options…]

Par défaut, cette commande authentifie le chekout Git dans le répertoire courant ; il ne produit rien et sort avec le code de sortie zéro en cas de succès et non zéro en cas d’échec. commit ci-dessus désigne le premier commit où l’authentification a lieu, et signer est l’empreinte OpenPGP de la clé publique utilisée pour signer commit. Ensemble, ils forment une «introduction de canal» (voir introduction de canal). Les options ci-dessous vous permettent d’affiner le processus.

--repository=répertoire

-r répertoire

Ouvre le dépôt Git dans directory au lieu du répertoire courant.

--keyring=référence

-k féférence

Chargez le porte-clés OpenPGP à partir de référence, la référence d’une branche telle que origin/keyring ou my-keyring. La branche doit contenir des clés publiques OpenPGP dans des fichiers .key, soit sous forme binaire, soit "blindée ASCII". Par défaut, le porte-clés est chargé à partir de la branche nommée keyring.

--stats

Affiche les statistiques sur les signatures de commits à l’issue de la procédure.

--cache-key=key

Les commits préalablement authentifiés sont mis en cache dans un fichier sous ~/.cache/guix/authentication. Cette option force le cache à être stocké dans le fichier key de ce répertoire.

--historical-authorizations=fichier

Par défaut, tout commit dont le(s) commit(s) parent(s) ne contient(nt) pas le fichier .guix-authorizations est considéré comme non authentique. En revanche, cette option considère les autorisations dans file pour tout commit dont le fichier .guix-authorizations est manquant. Le format de file est le même que celui de .guix-authorizations (au format voir .guix-autorizations).

8 Interface de programmation

GNU Guix fournit diverses interface de programmation Scheme (API) qui pour définir, construire et faire des requêtes sur des paquets. La première interface permet aux utilisateurs d’écrire des définitions de paquets de haut-niveau. Ces définitions se réfèrent à des concepts de création de paquets familiers, comme le nom et la version du paquet, son système de construction et ses dépendances. Ces définitions peuvent ensuite être transformées en actions concrètes lors de la construction.

Les actions de construction sont effectuées par le démon Guix, pour le compte des utilisateur·rice·s. Dans un environnement standard, le démon possède les droits en écriture sur le dépôt — le répertoire /gnu/store — mais pas les utilisateur·rice·s. La configuration recommandée permet aussi au démon d’effectuer la construction dans des chroots, à l’adresse des utilisateur·rice·s de construction spécifiques, pour minimiser les interférences avec le reste du système.

Il y a des API de plus bas niveau pour interagir avec le démon et le dépôt. Pour demander au démon d’effectuer une action de construction, les utilisateurs lui donnent en fait une dérivation. Une dérivation est une représentation à bas-niveau des actions de construction à entreprendre et l’environnement dans lequel elles devraient avoir lieu — les dérivations sont aux définitions de paquets ce que l’assembleur est aux programmes C. Le terme de « dérivation » vient du fait que les résultats de la construction en dérivent.

Ce chapitre décrit toutes ces API tour à tour, à partir des définitions de paquets à haut-niveau.

8.1 Modules de paquets

D’un point de vue programmatique, les définitions de paquets de la distribution GNU sont fournies par des modules Guile dans l’espace de noms (gnu packages …)¹⁴ (voir Guile modules dans GNU Guile Reference Manual). Par exemple, le module (gnu packages emacs) exporte une variable nommée emacs, qui est liée à un objet <package> (voir Définition des paquets).

L’espace de nom (gnu packages …) est automatiquement scanné par les outils en ligne de commande. Par exemple, lorsque vous lancez guix install emacs, tous les modules (gnu packages …) sont scannés jusqu’à en trouver un qui exporte un objet de paquet dont le nom est emacs. Cette capacité à chercher des paquets est implémentée dans le module (gnu packages).

Les utilisateur·rice·s peuvent stocker les définitions de paquets dans des modules ayant des noms différents—par exemple, (my-packages emacs)¹⁵. Il y a deux façons de rendre ces définitions de paquets visibles pour les interfaces utilisateur·rice :

1. En ajoutant le répertoire contenant vos modules de paquets au chemin de recherche avec le tag -L de guix package et des autres commandes (voir Options de construction communes) ou en indiquant la variable d’environnement GUIX_PACKAGE_PATH décrite plus bas.
2. En définissant un canal et en configurant guix pull pour qu’il l’utilise. Un canal est en substance un dépôt Git contenant des modules de paquets. Voir Canaux, pour plus d’informations sur comment définir et utiliser des canaux.

GUIX_PACKAGE_PATH fonctionne comme les autres variables de chemins de recherche :

Variable d'environnement : GUIX_PACKAGE_PATH

C’est une liste séparée par des deux-points de répertoires dans lesquels trouver des modules de paquets supplémentaires. Les répertoires listés dans cette variable sont prioritaires par rapport aux paquets de la distribution.

La distribution est entièrement bootstrappée et auto-contenue : chaque paquet est construit uniquement à partir d’autres paquets de la distribution. La racine de ce graphe de dépendance est un petit ensemble de binaires de bootstrap fournis par le module (gnu packages bootstrap). Pour plus d’informations sur le bootstrap, voir Bootstrapping.

8.2 Définition des paquets

L’interface de haut-niveau pour les définitions de paquets est implémentée dans les modules (guix packages) et (guix build-system). Par exemple, la définition du paquet, ou la recette, du paquet GNU Hello ressemble à cela :

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs `(("gawk" ,gawk)))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Sans être expert·e en Scheme, on peut comprendre la signification des différents champs présents. Cette expression lie la variable hello à un objet <package>, qui est en substance un enregistrement (voir Scheme records dans GNU Guile Reference Manual). On peut inspecter cet objet de paquet avec les procédures qui se trouvent dans le module (guix packages) ; par exemple, (package-name hello) renvoie — ô surprise ! — "hello".

Avec un peu de chance, vous pourrez importer tout ou partie de la définition du paquet qui vous intéresse depuis un autre répertoire avec la commande guix import (voir Invoquer guix import).

Dans l’exemple précédent, hello est défini dans un module à part, (gnu packages hello). Techniquement, cela n’est pas strictement nécessaire, mais c’est pratique : tous les paquets définis dans des modules sous (gnu packages …) sont automatiquement connus des outils en ligne de commande (voir Modules de paquets).

Il y a quelques points à remarquer dans la définition de paquet précédente :

• Le champ source du paquet est un objet <origin> (voir référence de origin, pour la référence complète). Ici, on utilise la méthode url-fetch de (guix download), ce qui signifie que la source est un fichier à télécharger par FTP ou HTTP.

  Le préfixe mirror://gnu demande à url-fetch d’utiliser l’un des miroirs GNU définis dans (guix download).

  Le champ sha256 spécifie le hash SHA256 attendu pour le fichier téléchargé. Il est requis et permet à Guix de vérifier l’intégrité du fichier. La forme (base32 …) introduit a représentation en base32 du hash. Vous pouvez obtenir cette information avec guix download (voir Invoquer guix download) et guix hash (voir Invoquer guix hash).

  Lorsque cela est requis, la forme origin peut aussi avec un champ patches qui liste les correctifs à appliquer et un champ snippet qui donne une expression Scheme pour modifier le code source.

• Le champ build-system spécifie la procédure pour construire le paquet (voir Systèmes de construction). Ici, gnu-build-system représente le système de construction GNU familier, où les paquets peuvent être configurés, construits et installés avec la séquence ./configure && make && make check && make install habituelle.

  Lorsque vous commencez à empaqueter des logiciels non triviaux, vous pouvez avoir besoin d’outils pour manipuler ces phases de construction, manipuler des fichiers, etc. Voir Utilitaires de construction, pour en savoir plus.

• Le champ arguments spécifie des options pour le système de construction (voir Systèmes de construction). Ici il est interprété par gnu-build-system comme une demande de lancer configure avec le tag --enable-silent-rules.

  Que sont ces apostrophes (') ? C’est de la syntaxe Scheme pour introduire une liste ; ' est synonyme de la fonction quote. Voir quoting dans GNU Guile Reference Manual, pour des détails. Ice la valeur du champ arguments est une liste d’arguments passés au système de construction plus tard, comme avec apply (voir apply dans GNU Guile Reference Manual).

  La séquence dièse-deux-points (#:) définie un mot-clef Scheme (voir Keywords dans GNU Guile Reference Manual), et #:configure-flags est un mot-clef utilisé pour passer un argument au système de construction (voir Coding With Keywords dans GNU Guile Reference Manual).

• Le champ inputs spécifie les entrées du processus de construction — c.-à-d. les dépendances à la construction ou à l’exécution du paquet. Ici, nous définissons une entrée appelée "gawk" dont la valeur est celle de la variable gawk ; gawk est lui-même lié à un objet <package>.

  De nouveau, ` (un accent grave, synonyme de la fonction quasiquote) nous permet d’introduire une liste littérale dans le champ inputs, tandis que , (une virgule, synonyme de la fonction unquote) nous permet d’insérer une valeur dans cette liste (voir unquote dans GNU Guile Reference Manual).

  Remarquez que GCC, Coreutils, Bash et les autres outils essentiels n’ont pas besoin d’être spécifiés en tant qu’entrées ici. À la place, le gnu-build-system est en mesure de s’assurer qu’ils sont présents (voir Systèmes de construction).

  Cependant, toutes les autres dépendances doivent être spécifiées dans le champ inputs. Toute dépendance qui ne serait pas spécifiée ici sera simplement indisponible pour le processus de construction, ce qui peut mener à un échec de la construction.

Voir référence de package, pour une description complète des champs possibles.

Lorsqu’une définition de paquet est en place, le paquet peut enfin être construit avec l’outil en ligne de commande guix build (voir Invoquer guix build), pour résoudre les échecs de construction que vous pourriez rencontrer (voir Débogage des échecs de construction). Vous pouvez aisément revenir à la définition du paquet avec la commande guix edit (voir Invoquer guix edit). Voir Consignes d'empaquetage, pour plus d’informations sur la manière de tester des définitions de paquets et Invoquer guix lint, pour des informations sur la manière de vérifier que la définition respecte les conventions de style. Enfin, voir Canaux pour des informations sur la manière d’étendre la distribution en ajoutant vos propres définitions de paquets dans un « canal ».

Finalement, la mise à jour de la définition du paquet à une nouvelle version amont peut en partie s’automatiser avec la commande guix refresh (voir Invoquer guix refresh).

Sous le capot, une dérivation qui correspond à un objet <package> est d’abord calculé par la procédure package-derivation. Cette dérivation est stockée dans un fichier .drv dans /gnu/store. Les actions de construction qu’il prescrit peuvent ensuite être réalisées par la procédure build-derivation (voir Le dépôt).

Procédure Scheme : package-derivation store package [system]

Renvoie l’objet <derivation> du paquet pour le système (voir Dérivations).

paquet doit être un objet <package> valide et système une chaîne indiquant le type de système cible — p. ex. "x86_64-linux" pour un système GNU x86_64 basé sur Linux. dépôt doit être une connexion au démon, qui opère sur les dépôt (voir Le dépôt).

De manière identique, il est possible de calculer une dérivation qui effectue une compilation croisée d’un paquet pour un autre système :

Procédure Scheme : package-cross-derivation store paquet cible [système] renvoie l'objet <derivation>

du paquet construit depuis système pour cible.

cible doit être un triplet GNU valide indiquant le matériel cible et le système d’exploitation, comme "aarch64-linux-gnu" (voir Specifying Target Triplets dans Autoconf).

Une fois qu’on a une définition de paquet, on peut facilement définir des variantes du paquet. Voir Définition de variantes de paquets, pour plus d’informations.

8.2.1 Référence de package

Cette section résume toutes les options disponibles dans les déclarations package (voir Définition des paquets).

Type de données : package

C’est le type de donnée représentant une recette de paquets.

name

Le nom du paquet, comme une chaîne de caractères.

version

La version du paquet, comme une chaîne de caractères.

source

Un objet qui indique comment le code source du paquet devrait être récupéré. La plupart du temps, c’est un objet origin qui indique un fichier récupéré depuis internet (voir référence de origin). Il peut aussi s’agir de tout autre objet « simili-fichier » comme un local-file qui indique un fichier du système de fichier local (voir local-file).

build-system

Le système de construction qui devrait être utilisé pour construire le paquet (voir Systèmes de construction).

arguments (par défaut : '())

Les arguments à passer au système de construction. C’est une liste qui contient typiquement une séquence de paires de clefs-valeurs.

inputs (par défaut : '())

native-inputs (par défaut : '())

propagated-inputs (par défaut : '())

Ces champs listent les dépendances du paquet. Chacune est une liste de tuples, où chaque tuple a une étiquette pour une entrée (une chaîne de caractères) comme premier élément, un paquet, une origine ou une dérivation comme deuxième élément et éventuellement le nom d’une sortie à utiliser qui est "out" par défaut (voir Des paquets avec plusieurs résultats, pour plus d’informations sur les sorties des paquets). Par exemple, la liste suivante spécifie trois entrées :

`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;la sortie "bin" de Glib

La distinction entre native-inputs et inputs est nécessaire lorsqu’on considère la compilation croisée. Lors d’une compilation croisée, les dépendances listées dans inputs sont construites pour l’architecture cible ; inversement, les dépendances listées dans native-inputs sont construites pour l’architecture de la machine de construction.

native-inputs est typiquement utilisé pour lister les outils requis à la construction mais pas à l’exécution, comme Autoconf, Automake, pkg-config, Gettext ou Bison. guix lint peut rapporter des erreurs de ce type (voir Invoquer guix lint).

Enfin, propagated-inputs est similaire à inputs, mais les paquets spécifiés seront automatiquement installés sur les profils (voir le rôle des profils dans Guix) à côté du paquet auquel ils appartiennent (voir guix package, pour savoir comment guix package traite les entrées propagées).

Par exemple, cela est nécessaire lors de l’empaquetage d’une bibliothèque C/C++ qui a besoin des en-têtes d’une autre bibliothèque pour se compiler, ou lorsqu’un fichier pkg-config fait référence à un autre via son champ Requires.

Un autre exemple où le propagated-inputs est utile, c’est pour les langues qui ne disposent pas de la possibilité d’enregistrer le chemin de recherche à l’exécution comme le RUNPATH des fichiers ELF ; cela inclut Guile, Python, Perl, et plus encore. Lors de l’empaquetage de bibliothèques écrites dans ces langages, assurez-vous qu’elles peuvent trouver le code de bibliothèque dont elles dépendent au moment de l’exécution en listant les dépendances d’exécution dans propagated-inputs plutôt que inputs.

outputs (par défaut : '("out"))

La liste des noms de sorties du paquet. Voir Des paquets avec plusieurs résultats, pour des exemples typiques d’utilisation de sorties supplémentaires.

native-search-paths (par défaut : '())

search-paths (par défaut : '())

Une liste d’objets search-path-specification décrivant les variables d’environnement de recherche de chemins que ce paquet utilise.

replacement (par défaut : #f)

Ce champ doit être soit #f soit un objet de paquet qui sera utilisé comme remplaçant de ce paquet. Voir grafts, pour plus de détails.

synopsis

Une description sur une ligne du paquet.

description

Une description plus détaillée du paquet.

license

La licence du paquet ; une valeur tirée de (guix licenses) ou une liste de ces valeurs.

home-page

L’URL de la page d’accueil du paquet, en tant que chaîne de caractères.

supported-systems (par défaut : %supported-systems)

La liste des systèmes supportés par le paquet, comme des chaînes de caractères de la forme architecture-noyau, par exemple "x86_64-linux".

location (par défaut : emplacement de la source de la forme package)

L’emplacement de la source du paquet. C’est utile de le remplacer lorsqu’on hérite d’un autre paquet, auquel cas ce champ n’est pas automatiquement corrigé.

Syntaxe Scheme : this-package

Lorsque vous l’utilisez dans la portée lexicale du champ d’une définition de paquet, cet identifiant est résolu comme étant le paquet définit.

L’exemple ci-dessous montre l’ajout d’un paquet comme entrée native de lui-même pour la compilation croisée :

(package
  (name "guile")
  ;; ...

  ;; Lors de la compilation croisée, Guile par exemple dépend
  ;; d'une version native de lui-même. On l'ajoute ici.
  (native-inputs (if (%current-target-system)
                     `(("self" ,this-package))
                     '())))

C’est une erreur que de se référer à this-package en dehors de la définition d’un paquet.

Comme les paquets sont des objets Scheme réguliers qui capturent un graphe de dépendance complet et les procédures de construction associées, il est souvent utile d’écrire des procédures qui prennent un paquet et renvoient une version modifiée de celui-ci en fonction de certains paramètres. En voici quelques exemples.

Procédure Scheme : package-with-c-toolchain package toolchain

Renvoie une variante de package qui utilise toolchain au lieu de la chaîne d’outils GNU C/C++ par défaut. toolchain doit être une liste d’entrées (tuples label/package) fournissant une fonctionnalité équivalente, comme le paquet gcc-toolchain.

L’exemple ci-dessous renvoie une variante du paquet hello construit avec GCC 10.x et le reste de la chaîne d’outils GNU (Binutils et la bibliothèque C GNU) au lieu de la chaîne d’outils par défaut :

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

La chaîne d’outils de construction fait partie des entrées implicites des paquets— elle n’est généralement pas listée comme faisant partie des différents champs "entrées" et est à la place récupérée par le système de construction. Par conséquent, cette procédure fonctionne en modifiant le système de compilation de paquet de sorte qu’il utilise toolchain au lieu des valeurs par défaut. Systèmes de construction, pour en savoir plus sur les systèmes de construction.

8.2.2 Référence de origin

Cette section documente origins. Une déclaration origin spécifie les données qui doivent être "produites" – téléchargées, généralement – et dont le contenu est connu à l’avance. Les origines sont principalement utilisées pour représenter le code source des paquets (voir Définition des paquets). Pour cette raison, le formulaire origin permet de déclarer des correctifs à appliquer au code source original ainsi que des bribes de code pour le modifier.

Type de données : origin

C’est le type de donnée qui représente l’origine d’un code source.

uri

Un objet contenant l’URI de la source. Le type d’objet dépend de la method (voir plus bas). Par exemple, avec la méthode url-fetch de (guix download), les valeurs valide d’uri sont : une URL représentée par une chaîne de caractères, ou une liste de chaînes de caractères.

method

Une procédure monadique qui gère l’URI donné. La procédure doit accepter au moins trois arguments : la valeur du champ uri et l’algorithme de hachage et la valeur de hachage spécifiée par le champ hash. Elle doit renvoyer un élément du dépôt ou une dérivation dans la monade du dépôt (voir La monade du dépôt) ; la plupart des méthodes renvoient une dérivation à sortie fixe (voir Dérivations).

Les méthodes couramment utilisées comprennent url-fetch, qui récupère les données à partir d’une URL, et git-fetch, qui récupère les données à partir d’un dépôt Git (voir ci-dessous).

sha256

Un bytevector contenant le hachage SHA-256 de la source. Cela équivaut à fournir un content-hash Objet SHA256 dans le champ hash décrit ci-dessous.

hash

L’objet content-hash de la source–voir ci-dessous pour savoir comment utiliser content-hash.

Vous pouvez obtenir cette information avec guix download (voir Invoquer guix download) ou guix hash (voir Invoquer guix hash).

file-name (par défaut : #f)

Le nom de fichier à utiliser pour sauvegarder le fichier. Lorsqu’elle est à #f, une valeur par défaut raisonnable est utilisée dans la plupart des cas. Dans le cas où la source est récupérée depuis une URL, le nom de fichier est celui de l’URL. Pour les sources récupérées depuis un outil de contrôle de version, il est recommandé de fournir un nom de fichier explicitement parce que le nom par défaut n’est pas très descriptif.

patches (par défaut : '())

Une liste de noms de fichiers, d’origines ou d’objets simili-fichiers (voir file-like objects) qui pointent vers des correctifs à appliquer sur la source.

Cette liste de correctifs doit être inconditionnelle. En particulier, elle ne peut pas dépendre des valeurs de %current-system ou %current-target-system.

snippet (par défaut : #f)

Une G-expression (voir G-Expressions) ou une S-expression qui sera lancée dans le répertoire des sources. C’est une manière pratique de modifier la source, parfois plus qu’un correctif.

patch-flags (par défaut : '("-p1"))

Une liste de drapeaux à passer à la commande patch.

patch-inputs (par défaut : #f)

Paquets d’entrées ou dérivations pour le processus de correction. Lorsqu’elle est à #f, l’ensemble d’entrées habituellement nécessaire pour appliquer des correctifs est fournit, comme GNU Patch.

modules (par défaut : '())

Une liste de modules Guile qui devraient être chargés pendant le processus de correction et pendant que le lancement du code du champ snippet.

patch-guile (par défaut : #f)

Le paquet Guile à utiliser dans le processus de correction. Lorsqu’elle est à #f, une valeur par défaut raisonnable est utilisée.

Data Type : content-hash value [algorithm]

Construire un objet de hash de contenu pour l’algorithme donné, et avec valeur comme valeur de hachage. Lorsque algorithme est omis, on suppose qu’il s’agit de sha256.

value peut être une chaîne littérale, auquel cas elle est décodée en base32, ou il peut s’agir d’un bytevecteur.

Les options suivantes sont équivalentes :

(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
              sha256)
(content-hash (base32
               "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
(content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
              sha256)

Techniquement, le content-hash est actuellement mis en œuvre sous forme de macro. Il effectue des contrôles de bon sens au moment de l’expansion de la macro, lorsque cela est possible, en s’assurant par exemple que valeur a la bonne taille pour algorithme.

Comme nous l’avons vu plus haut, la manière dont les données auxquelles une origine se réfère exactement sont récupérées est déterminée par son champ method. Le module (guix download) fournit la méthode la plus courante, url-fetch, décrite ci-dessous.

Procédure Scheme : url-fetch url hash-algo hash [name] [#:executable ? #f] Renvoie une dérivation à sortie fixe qui récupère

les données de url (une chaîne de caractères, ou une liste de chaînes de caractères désignant des URLs alternatives), qui est censée avoir un hash hash de type hash-algo (un symbole). Par défaut, le nom du fichier est le nom de base de l’URL ; en option, nom peut spécifier un nom de fichier différent. Lorsque executable? est vrai, rendez le fichier téléchargé exécutable.

Lorsque l’une des URL commence par mirror://, sa partie hôte est alors interprétée comme le nom d’un schéma de miroir, tiré de %mirror-file.

Alternativement, lorsque l’URL commence par file://, renvoie le nom du fichier correspondant dans le dépôt.

De même, le module (guix git-download) définit la méthode d’origine git-download, qui récupère les données d’un dépôt de contrôle de version Git, et le type de données git-reference pour décrire le dépôt et la révision à récupérer.

Procédure Scheme : git-fetch ref hash-algo hash

Renvoie une dérivation à sortie fixe qui va chercher ref, un objet <git-reference>. La sortie est censée avoir un hash récursif hash de type hash-algo (un symbole). Utilisez name comme nom de fichier, ou un nom générique si #f.

Type de données : git-reference

Ce type de données représente une référence Git pour le git-fetch à récupérer.

url

L’URL du dépôt Git à cloner.

commit

Cette chaîne indique soit le commit à récupérer (une chaîne hexadécimale, soit le commit SHA1 complet ou une chaîne de commit "courte" ; cette dernière n’est pas recommandée), soit le tag à récupérer.

recursive? (par défaut : #f)

Ce booléen indique s’il faut aller chercher récursivement les sous-modules de Git.

L’exemple ci-dessous indique la balise v2.10 du dépôt GNU Hello :

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "v2.10"))

C’est équivalent à la référence ci-dessous, qui nomme explicitement le commit :

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "dc7dc56a00e48fe6f231a58f6537139fe2908fb9"))