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 (non pris en charge)

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.

powerpc-linux (non pris en charge)

les processeurs PowerPC 32 bits big-endian, en particulier PowerPC G4 avec la prise en charge d’AltVec et le noyau Linux-Libre. Cette configuration n’est pas entièrement prise en charge et il n’y a pas de travaux en cours pour s’assurer que cette architecture fonctionne.

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 !

riscv64-linux

Les processeurs RISC-V petit-boutistes, en particulier RV64GC, et le noyau linux-Libre. 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, powerpc-linux, powerpc64le-linux et riscv64-linux.

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

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

Si vous utilisez Debian ou une dérivée comme Ubuntu, vous pouvez plutôt installer le paquet (il se peut qu’il soit plus vieux que 1.4.0 mais vous pourrez le mettre à jour en lançant ‘guix pull’) :

sudo apt install guix

De même sur openSUSE :

sudo zypper install guix

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 déroule comme ceci :

1. Télécharger le tarball binaire à partir de ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.4.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.4.0.x86_64-linux.tar.xz.sig
   $ gpg --verify guix-binary-1.4.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=15145' \
         -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.4.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
   

   Vous pourriez aussi vouloir faire en sorte que guix gc soit lancé périodiquement :

   # cp ~root/.config/guix/current/lib/systemd/system/guix-gc.service \
        ~root/.config/guix/current/lib/systemd/system/guix-gc.timer \
        /etc/systemd/system/
   # systemctl enable --now guix-gc.timer
   

   Vous voudrez peut-être éditer guix-gc.service pour ajuster la ligne de commande à vos besoins (voir Invoquer guix gc).

   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, bordeaux.guix.gnu.org ou l’un de leurs miroirs (voir Substituts), autorisez-les :

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

   Remarque : Si vous n’activez pas les substituts, Guix va tout compiler depuis les sources sur votre machine, rendant très coûteuse chaque installation et chaque mise à jour. Voir De la confiance en des binaires, pour une discussion des raisons pour lesquelles on pourrait vouloir désactiver les substituts.

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 ; version 3.0.3 ou supérieure ;
• Guile-Gcrypt, version 0.1.0 ou supérieure ;
• Guile-GnuTLS (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.5.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 Utiliser le dispositif de déchargement) 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.

• Réglages de l’environnement de construction
• Utiliser le dispositif de déchargement
• Support de SELinux

# 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

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

(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")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")

        ;; Rappelez-vous que « guix offload » est démarré par
        ;; « guix-daemon » en root.
        (private-key "/root/.ssh/identité-pour-guix")))

ssh build-machine guix repl --version

# guix archive --generate-key

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

# guix offload test

# guix offload test machines-qualif.scm

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

# guix offload status

semodule -i etc/guix-daemon.cil

ps -Zax | grep guix-daemon

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

Ce démon peut aussi être démarré avec le protocole d’« activation par socket » de systemd (voir make-systemd-constructor dans le manuel de GNU Shepherd).

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 https://bordeaux.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 Utiliser le dispositif de déchargement). 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 Utiliser le dispositif de déchargement) 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 gzip 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.

• Régionalisation
• Name Service Switch
• Polices X11
• Certificats X.509
• Paquets Emacs

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

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-locales"))

guix install fontconfig
fc-cache -rv

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

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

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

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.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 garanties 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.4.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).

L’installateur vous averti rapidement s’il détecte des périphériques connus pour ne pas marcher à cause du manque de micrologiciel ou de pilote libre.

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.4.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.4.0.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-1.4.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=15145 \
      -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
• Graver sur un DVD
• Démarrage

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

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

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. Cela signifie que vous pouvez installer des paquets supplémentaires si vous en avez besoin, avec guix package (voir Invoquer guix package).

• Disposition du clavier réseau et partitionnement
• Effectuer l’installation

loadkeys dvorak

ifconfig -a

ip address

dhclient -v interface

ping -c 3 gnu.org

herd set-http-proxy guix-daemon URL

herd start ssh-daemon

cfdisk

parted /dev/sda set 1 esp on

mkfs.fat -F32 /dev/sda1

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

cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sda2
cryptsetup open /dev/sda2 ma-partition
mkfs.ext4 -L my-root /dev/mapper/ma-partition

mount LABEL=my-root /mnt

mkswap /dev/sda3
swapon /dev/sda3

# 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

herd start cow-store /mnt

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

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

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.4.0.système.iso
   

   -enable-kvm est facultatif, mais améliore nettement les performances, voir Exécuter Guix sur une machine virtuelle.

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 Exécuter Guix sur une machine virtuelle, 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.1 Chrooter dans un système existant

Cette section explique comment chrooter sur un système Guix déjà installé dans le but de le reconfigurer, par exemple pour corriger une installation défaillante de GRUB. Le processus est semblable à la manière de faire pour les autres systèmes GNU/Linux, mais il y a quelques particularités du système Guix comme le démon et les profils qui le rend utile à décrire ici.

1. Récupérez une image amorçable du système Guix. Nous vous recommandons d’utiliser le dernier instantané de développement pour que le noyau et les outils utilisés soient au moins aussi récents que le système installé ; vous pouvez le récupérer à partir de l’URL https://ci.guix.gnu.org. Suive la section voir Installation depuis une clef USB ou un DVD pour apprendre à le copier sur un média amorçable.
2. Démarrez l’image et suivez l’installateur graphique jusqu’à avoir configuré le réseau. Autrement, vous pouvez configurer le réseau manuellement en suivant la section manual-installation-networking. Si vous avez une erreur du type ‘RTNETLINK answers: Operation not possible due to RF-kill’, essayez ‘rfkill list’ suivi de ‘rfkill unblock 0’, où ‘0’ est l’identifiant de votre périphérique (ID).
3. Passez sur une console virtuelle (tty) si vous ne l’avez pas déjà fait en appuyant simultanément sur Control + Alt + F4. Montez votre système de fichier sur /mnt. En supposant que votre partition racine est /dev/sda2, vous feriez :

   mount /dev/sda2 /mnt
   

4. Montez les périphériques blocs spéciaux et les répertoires spécifiques à Linux :

   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   mount --bind /dev /mnt/dev
   

   Si votre système est basé sur EFI, vous devez aussi monter la partition ESP. En supposant qu’elle est sur /dev/sda1, vous pouvez le faire avec :

   mount /dev/sda1 /mnt/boot/efi
   

5. Entrez dans votre système avec chroot :

   chroot /mnt /bin/sh
   

6. Sourcez le profil système ainsi que votre profil utilisateur pour mettre en place l’environnement, où utilisateur est le nom d’utilisateur utilisé par le système Guix que vous essayez de réparer :

   source /var/guix/profiles/system/profile/etc/profile
   source /home/utilisateur/.guix-profile/etc/profile
   

   Pour vous assurer que vous travaillez avec la révision de Guix que vous utiliseriez en tant qu’utilisateur normal, sourcez aussi votre profil actuel de Guix :

   source /home/utilisateur/.config/guix/current/etc/profile
   

7. Démarrez un guix-daemon minimal en tâche de fond :

   guix-daemon --build-users-group=guixbuild --disable-chroot &
   

8. Modifiez votre configuration système comme vous le souhaitez, puis reconfigurez avec :

   guix system reconfigure votre-config.scm
   

9. Enfin, vous devriez pouvoir redémarrer le système pour tester votre correction.

6.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 shell 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 shell).

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.

6.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 un simple nom de paquet, tel que guile, éventuellement suivi d’un arobase et d’un numéro de version, tel que guile@3.0.7 ou simplement guile@3.0. (dans ce dernier cas, la version la plus récente préfixée par 3.0 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, une telle spécification de 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).

Autrement, un paquet peut directement spécifier un fichier du dépôt comme /gnu/store/...-guile-3.0.7, produit par exemple par guix build.

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

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

Voir Écrire un manifeste, pour des informations sur la manière d’écrire un manifeste. 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 (voir Chemins de recherche, pour des infos sur les spécifications de chemins de recherche associées aux paquets).

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 toto -i guile
$ guix package -p titi -i guile-json
$ guix package -p toto -p titi --search-paths

La dernière commande ci-dessus montre la variable GUILE_LOAD_PATH bien que, pris individuellement, ni toto ni titi 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=guile | recsel -p name,version
name: guile
version: 3.0.5

name: guile
version: 3.0.2

name: guile
version: 2.2.7
…

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 guile@3.0.5 | recsel -p name,version
name: guile
version: 3.0.5

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

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

• Serveur de substituts officiel
• Autoriser un serveur de substituts
• Récupérer des substituts d’autres serveurs
• Authentification des substituts
• Paramètres de serveur mandataire
• Échec de substitution
• De la confiance en des binaires

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

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

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

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

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

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

6.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 Invoque 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).

6.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 et générations de l’environnement personnel ; 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 Invoque 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.

--vacuum-database ¶

Guix utilise une base de données sqlite pour garder la trace des éléments du dépôt (voir Le dépôt). Avec le temps il est possible que la base de données grossisse et soit fragmentée. En conséquence, vous pourriez vouloir effacer l’espace libéré et recoller les pages partiellement utilisées dans la base de données laissées par la suppression des paquets ou après le lancement du ramasse-miettes. Lancer sudo guix gc --vacuum-database verrouillera la base de données et lancera un VACUUM du dépôt, pour défragmenter la base de données et libérer les pages vides, et déverrouillera la base une fois l’opération terminée.

6.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·euses 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

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

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 le nom d’une étiquette) 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

Affiche les nouvelles écrites par les auteurs des canaux pour leurs utilisateurs et utilisatrices depuis la génération précédente (voir Writing Channel News). Lorsque vous passez --details, affiche aussi les nouveaux paquets et les paquets mis à jour.

Vous pouvez consulter ces informations pour les générations précédentes avec guix pull -l.

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

Par défaut, cela affiche les informations sur les canaux utilisés à chaque révision et les nouvelles associées. Si vous passez l’option --details, cela affichera la liste des paquets ajoutés et mis à jour à chaque génération par rapport à la précédente.

--details

Demande à --list-generations ou --news d’afficher plus d’informations sur la différence entre les générations successives, voir plus haut.

--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·euses, 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).

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

Supposons que vous vouliez voyager en ces jours de novembre 2020 où la version 1.2.0 de Guix a été publiée et que, une fois que vous y êtes, vous lanciez le guile de cette époque :

guix time-machine --commit=v1.2.0 -- \
  environment -C --ad-hoc guile -- guile

La commande ci-dessus récupère Guix 1.2.0 et lance sa commande guix environment pour démarrer un environnement dans un conteneur qui lance guile (guix environment a depuis été remplacé par guix shell ; voir Invoquer guix shell). C’est comme conduire une DeLorean¹² ! La première invocation de guix time-machine peut être coûteuse. Elle doit télécharger voire construire un grand nombre de paquets. Heureusement le résultat est mis en cache et les commandes suivantes qui ciblent le même commit sont presque instantanées.

Remarque : L’histoire de Guix est immuable et guix time-machine fournit exactement les mêmes logiciels que ceux de la révision de Guix spécifique. Naturellement, aucun correctif de sécurité n’est fournit pour les anciennes versions de Guix ou ses canaux. Utiliser guix time-machine sans précaution ouvre la porte à des vulnérabilités de sécurité. Voir --allow-downgrades.

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 le nom d’une étiquette) 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).

6.8 Inférieurs

Remarque : La fonctionnalité décrite ici est un « démonstrateur technique » à la version 1.4.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 Écrire un manifeste) ; 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.

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

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

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

La sortie de guix describe ci-dessus montre que nous sommes maintenant à la génération 19 et qu’il contient à la fois Guix et les paquets du canal variant-personal-packages (voir Invoquer guix describe).

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

7.3 Répliquer Guix

La commande guix describe ci-dessus montre précisément quels commits ont été utilisés pour construire l’instance de Guix utilisée (voir Invoquer guix describe). Nous pouvons répliquer cette instance sur une autre machine ou plus tard, en fournissant une spécification de canal « épinglée » à ces commits et qui ressemble à ceci :

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

Pour obtenir cette spécification de canaux épinglée, le plus simple est de lancer guix describe et de sauvegarder sa sortie au format channels dans un fichier, comme ceci :

guix describe -f channels > channels.scm

Le fichier channels.scm qui en résulte peut être passé à l’option -C de guix pull (voir Invoquer guix pull) ou guix time-machine (voir Invoquer guix time-machine), comme dans cet exemple :

guix time-machine -C channels.scm -- shell python -- python3

Étant donné le fichier channels.scm, la commande ci-dessus récupérera toujours exactement la même instance de Guix, puis utilisera cette instance pour lancer exactement le même Python (voir Invoquer guix shell). Sur n’importe quelle machine, à n’importe quel moment, elle lance exactement le même binaire, bit à bit.

Les canaux épinglés répondent à un problème similaire à celui des « fichiers de verrouillage » implémentés par certains outils de déploiement — ils vous permettent d’épingler et de reproduire un ensemble de paquets. Dans le cas de Guix cependant, vous épinglez en fait l’entièreté de l’ensemble de paquets défini par les commits donnés des canaux ; en fait, vous épinglez l’ensemble de Guix, avec des modules cœurs et ses outils en ligne de commande. Vous gagnez aussi la garantie forte que vous obtenez, effectivement, exactement le même environnement logiciel.

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.

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

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

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

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

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

7.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·euses autorisé·es. En tant qu’auteur·e, vous devez spécifiez la liste des développeur·euses autorisé·es 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 d’œuf : comment authentifions-nous le premier commit ? Par rapport à cela : 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 ?

L’introduction des 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. L’authentification échoue si le commit cible n’est ni un descendant ni un ancêtre du commit d’introduction.

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.

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

7.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 cela, 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 cela, les auteur·e·s de canaux 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.

8.1 Invoquer guix shell

Le but de guix shell est de faciliter la création d’environnements logiciels à usage unique, sans changer votre profil. Vous l’utiliserez typiquement pour créer des environnement de développement ; c’est aussi une commande pratique pour lancer des applications sans « polluer » votre profil.

Remarque : La commande guix shell a été introduite récemment pour remplacer guix environment (voir Invoquer guix environment). Si vous connaissez déjà guix environment, vous remarquerez qu’elle est similaire mais aussi (on l’espère) plus pratique.

La syntaxe générale est :

guix shell [options] [paquet…]

L’exemple suivant crée un environnement contenant Python et NumPy, en construisant ou en téléchargeant les paquets manquants et lance la commande python3 dans cet environnement :

guix shell python python-numpy -- python3

Vous pouvez créer des environnements de développement comme dans l’exemple ci-dessous, qui ouvre un shell interactif contenant toutes les dépendance et les variables d’environnement requises pour travailler sur Inkscape :

guix shell --development inkscape

Sortir du shell vous replacera dans l’environnement de départ, avant d’avoir invoqué la commande guix shell. Au prochain lancement du ramasse-miettes (voir Invoquer guix gc), les paquets installés dans l’environnement et qui ne sont plus utilisés en dehors seront possiblement supprimés.

En plus, guix shell essayera de faire ce que vous espérez quand il est invoqué de manière interactive et sans arguments, comme ceci :

guix shell

S’il trouve un manifest.scm dans le répertoire de travail actuel ou dans l’un de ses parents, il utiliser ce manifeste comme s’il avait été passé avec --manifest. De la même manière, s’il trouve un guix.scm dans ces mêmes répertoire, il l’utilisera pour construire un profil de développement comme si --development et --file étaient présents. Dans tous les cas, le fichier ne sera chargé que s’il réside dans un répertoire listé dans ~/.config/guix/shell-authorized-directories. Cela permet de facilement définir, partager et entrer dans des environnements de développement.

Par défaut, la session shell ou la commande est lancée dans un environnement augmenté, où les nouveaux paquets sont ajoutés aux variables d’environnement de recherche comme PATH. Vous pouvez à la place créer un environnement isolé ne contenant rien d’autre que les paquets que vous avez demandé. Passez l’option --pure pour nettoyer les définitions des variables d’environnement qui se trouvent dans l’environnement parent¹⁴ ; en passant --container vous pouvez aller plus loin en démarrant un conteneur isolé du reste du système :

guix shell --container emacs gcc-toolchain

La commande ci-dessus démarre un shell interactif dans un conteneur avec rien d’autre que emacs, gcc-toolchain et leurs dépendances. Le conteneur n’a pas d’accès au réseau et ne partage pas les fichiers autres que ceux du répertoire de travail avec son environnement. C’est utile pour éviter d’accéder à des ressources systèmes comme /usr/bin sur les distributions externes.

Cette option --container peut aussi être utile si vous voulez lancer une application sensible en terme de sécurité, comme un navigateur web, dans un environnement isolé. Par exemple, la commande suivante lance Ungoogled-Chromium dans un environnement isolé, cette fois en partageant l’accès réseau de l’hôte et en préservant sa variable d’environnement DISPLAY, mais sans partager même le répertoire actuel :

guix shell --container --network --no-cwd ungoogled-chromium \
  --preserve='^DISPLAY$' -- chromium

guix shell 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"

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

--check

Met en place l’environnement et vérifie si le shell peut écraser les variables d’environnement. C’est une bonne idée d’utiliser cette option la première fois que vous lancez guix shell pour une session interactive pour vous assurer que votre configuration est correcte.

Par exemple, si le shell modifie la variable d’environnement PATH, cela sera rapporté car vous auriez un environnement différent de celui que vous avez demandé.

Ces problèmes indiquent en général que les fichiers de démarrage du shell modifient ces variables d’environnement de manière inattendue. Par exemple, si vous utilisez Bash, assurez-vous que les variables d’environnement sont définie ou modifiées dans ~/.bash_profile et non dans ~/.bashrc — ce premier est sourcé seulement par les shells de connexion. Voir Bash Startup Files dans le manuel de référence de Bash pour plus de détails sur les fichiers de démarrage de Bash.

--development

-D

Fait en sorte que guix shell ajoute à l’environnement les dépendances du paquet suivant au lieu du paquet lui-même. Vous pouvez combiner cette option avec d’autres paquets. Par exemple, la commande suivante démarre un shell interactif contenant les dépendances à la construction de GNU Guile, plus Autoconf, Automake et Libtool :

guix shell -D guile autoconf automake libtool

--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 shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

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

Lancer :

guix shell -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 shell -e '(list (@ (gnu packages bash) bash) "include")'

Voir package->development-manifest, pour apprendre à écrire un fichier manifeste ou l’environnement de développement d’un paquet.

--file=fichier

-f fichier

Crée un environnement contenant 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 (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.64 automake texinfo))))

Avec le fichier ci-dessus, vous pouvez entrer un environnement de développement pour GDB en lançant :

guix shell -D -f gdb-devel.scm

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

Voir Écrire un manifeste, pour des informations sur l’écriture d’un manifeste. Voir --export-manifest ci-dessous pour apprendre à obtenir un premier manifeste.

--export-manifest

Écrire un manifeste vers la sortie standard utilisable avec --manifest et qui correspond aux options de la ligne de commande données.

C’est une manière de « convertir » les arguments de la ligne de commande en un manifeste. Par exemple, imaginez que vous en ayez marre de taper de longues lignes et souhaitez avoir un manifeste équivalent à cette ligne de commande :

guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

Ajoutez l’option --export-manifest à la ligne de commande ci-dessus :

guix shell --export-manifest \
  -D guile git emacs emacs-geiser emacs-geiser-guile

... et vous obtiendrez un manifeste comme ceci :

(concatenate-manifests
  (list (specifications->manifest
          (list "git"
                "emacs"
                "emacs-geiser"
                "emacs-geiser-guile"))
        (package->development-manifest
          (specification->package "guile"))))

Vous pouvez l’enregistrer dans un fichier, disons manifest.scm, et ensuite le passer à guix shell ou n’importe quelle commande guix :

guix shell -m manifest.scm

Voilà, vous avez convertit une longue ligne de commande en un manifeste ! Ce processus de conversion prend en compte les options de transformation des paquets (voir Options de transformation de paquets) et ne devrait donc pas perdre d’information.

--profile=profil

-p profil

Crée un environnement contenant les paquets installés dans profile. Utilisez guix package (voir Invoquer guix package) pour créer et gérer les profils.

--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 shell --pure --preserve=^SLURM 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 shell 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/toto/wd, /home/toto/test et /home/toto/target
cd $HOME/wd
guix shell --container --user=toto \
     --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 shell --container --expose=$HOME=/exchange guile -- guile

--symlink=spec

-S spec

Pour les conteneurs, crée le lien symbolique spécifié par la spec, documenté dans pack-symlink-option.

--emulate-fhs

-F

Lorsqu’elle est utilisée avec --container, cette option émule une configuration qui respecte le standard de la hiérarchie des systèmes de fichiers (FHS) dans le conteneur, en fournissant /bin, /lib et d’autres répertoires et fichiers spécifiés par le FHS.

Comme Guix ne respecte pas les spécifications du FHS, cette option configure le conteneur pour mieux reproduire le comportement des autres distributions GNU/Linux. C’est utile pour reproduire d’autres environnements de développement, tester et utiliser des programmes qui s’attendent à ce que les spécifications du FHS soient suivies. Avec cette option, le conteneur inclura une version de glibc qui lira /etc/ld.so.cache dans le conteneur pour trouver le cache des bibliothèques partagées (au contraire de glibc dans l’utilisation normale de Guix) et configurera les répertoires attendu du FHS : /bin, /etc, /lib, /usr à partir du profil du conteneur.

--rebuild-cache ¶

La plupart du temps, guix shell met en cache l’environnement pour que les utilisations suivantes soient instantanées. Les entrées du cache utilisées le moins récemment sont régulièrement supprimées. Le cache est aussi invalidé lorsque vous utilisez --file ou --manifest à chaque fois que le fichier correspondant est modifié.

L’option --rebuild-cache force l’environnement en cache à être rafraîchi. C’est utile si vous utilisez les options --file ou --manifest et que les fichiers guix.scm ou manifest.scm ont des dépendances externes, ou si leur comportement dépend, disons, de variables d’environnements.

--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 vous n’utilisez pas cette option, guix shell met en cache les profils pour les utilisations suivantes du même environnement soient immédiates — vous pouvez comparer cela à l’utilisation de --root sauf que guix shell prend soin de régulièrement supprimer les racines du ramasse-miettes utilisées le moins récemment.

Dans certains cas, guix shell ne met pas les profils en cache – p. ex. si des options de transformations comme --with-latest sont utilisées. Dans ce cas, l’environnement n’est protégé du ramasse-miettes que le temps de la session guix shell. 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 en apprendre plus sur les racines du ramasse-miettes.

En plus, guix shell 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).

8.2 Invoquer guix environment

Le but de guix environment est de vous aider à créer des environnements de développement.

Avertissement d’obsolescence : La commande guix environment est obsolète et remplacée par guix shell, qui effectue les même tâches mais est plus pratique à utiliser. Voir Invoquer guix shell.

Étant obsolète, guix environment sera supprimée à un moment, mais le projet Guix s’engage à la garder jusqu’au premier mai 2023. Contactez-nous sur guix-devel@gnu.org si vous voulez en parler.

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 3 et NumPy :

guix environment --ad-hoc python-numpy python -- python3

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.

--check

Configure l’environnement et vérifie si le shell écraserait les variables d’environnement. Voir --check, pour plus d’informations.

--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 (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.64 automake texinfo))))

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

Voir guix shell --export-manifest, pour des informations sur la « conversion » des options de la ligne de commande en un manifeste.

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

--profile=profil

-p profil

Crée un environnement contenant les paquets installés dans profile. Utilisez guix package (voir Invoquer guix package) pour créer et gérer les profils.

--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/toto/wd, /home/toto/test et /home/toto/target
cd $HOME/wd
guix environment --container --user=toto \
     --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

--emulate-fhs

-F

Lorsqu’elle est utilisée avec --container, cette option émule une configuration qui respecte le standard de la hiérarchie des systèmes de fichiers (FHS) dans le conteneur, en fournissant /bin, /lib et d’autres répertoires et fichiers spécifiés par le FHS. Comme Guix ne respecte pas les spécifications du FHS, cette option configure le conteneur pour mieux reproduire le comportement des autres distributions GNU/Linux. C’est utile pour reproduire d’autres environnements de développement, tester et utiliser des programmes qui s’attendent à ce que les spécifications du FHS soient suivies. Avec cette option, le conteneur inclura une version de glibc qui lira /etc/ld.so.cache dans le conteneur pour trouver le cache des bibliothèques partagées (au contraire de glibc dans l’utilisation normale de Guix) et configurera les répertoires attendu du FHS : /bin, /etc, /lib, /usr à partir du profil du conteneur.

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

8.3 Invoquer guix pack

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

guix pack -f squashfs bash guile emacs emacs-geiser

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

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

--format=format

-f format

Produire un pack dans le format donné.

Les formats disponibles sont :

tarball

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

docker

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

squashfs

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

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

guix pack -f squashfs bash …

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

deb

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

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

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

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

--relocatable

-R

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

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

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

guix pack -RR -S /mybin=bin bash

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

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

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

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

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

default

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

performance

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

users

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

proot

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

fakechroot

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

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

--entry-point=commande

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

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

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

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

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

--expression=expr

-e expr

Considérer le paquet évalué par expr.

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

--manifest=fichier

-m fichier

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

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

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

--system=système

-s système

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

--target=triplet ¶

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

--compression=outil

-C outil

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

--symlink=spec

-S spec

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

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

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

--save-provenance

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

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

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

--root=fichier ¶

-r fichier

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

--localstatedir

--profile-name=nom

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

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

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

--derivation

-d

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

--bootstrap

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

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

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

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

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

9.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 (list 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. Parfois vous verrez aussi ` (un accent grave synonyme de quasiquote) et , (une virgule, synonyme de unquote). 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 ajoutons en entrée une référence à la variable gawk ; gawk est lui-même lié à un objet <package>.

  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.

Pour aller plus loin : Vous vous sentez intimidé·e par le langage Scheme ou vous êtes curieux·se de le découvrir ? Le livre de recettes a une petite section pour démarrer qui résume une partie de ce qui a été montré au-dessus et explique les bases. Voir Cours accéléré du langage Scheme dans le livre de recettes de GNU Guix, pour plus d’information.

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.

• Référence de package
• Référence de origin