Results of 1 - 1 of about 98 for keyserver (0.003 sec.)
- guix.fr.txt
- #score: 12976
- @digest: 72bf3da824e05c7f52980c5b053daa53
- @id: 74063
- @mdate: 2019-05-01T21:32:08Z
- @size: 1352824
- @type: text/plain
- #keywords: invoquer (98271), substituts (91655), paquets (81732), ‘/ (56150), ‘-- (54425), construction (48176), profil (44714), commande (44019), systeme (42669), paquet (42569), demon (39800), guix (38662), fichiers (37231), installe (36998), depot (35842), environnement (32761), fichier (32203), processus (30849), generations (29275), lancer (28885), lorsque (26947), defaut (26876), repertoire (25326), construire (23416), constructions (22756), utiliser (20764), exemple (19169), utilisateur (18529), contient (17876), pour (17391), utilisateurs (17053), serveur (17020)
- GNU Guix 1 Introduction 1.1 Gérer ses logiciels avec Guix 1.2 Distribution GNU 2 Installation 2.1 Installation binaire 2.2 Prérequis 2.3 Lancer la suite de tests 2.4 Paramétrer le démon 2.4.1 Réglages de l'environnement de construction 2.4.2 Utiliser le dispositif de déchargement 2.4.3 Support de SELinux 2.4.3.1 Installer la politique SELinux 2.4.3.2 Limitations 2.5 Invoquer ‘guix-daemon' 2.6 Réglages applicatifs 2.6.1 Régionalisation 2.6.2 Name Service Switch 2.6.3 Polices X11 2.6.4 Certificats X.509 2.6.5 Paquets emacs 2.6.6 La chaîne d'outils GCC 3 Installation du système 3.1 Limitations 3.2 Considérations matérielles 3.3 Installation depuis une clef USB ou un DVD Copie sur une clef USB Graver sur un DVD Démarrage 3.4 Préparer l'installation 3.5 Installation graphique guidée 3.6 Installation manuelle 3.6.1 Disposition du clavier réseau et partitionnement 3.6.1.1 Disposition du clavier 3.6.1.2 Réseau 3.6.1.3 Partitionnement 3.6.2 Effectuer l'installation 3.7 Après l'installation du système 3.8 Installer Guix sur une machine virtuelle 3.9 Construire l'image d'installation 3.10 Construire l'image d'installation pour les cartes ARM 4 Gestion de paquets 4.1 Fonctionnalités 4.2 Invoquer ‘guix package' 4.3 Substituts 4.3.1 Serveur de substituts officiel 4.3.2 Autoriser un serveur de substituts 4.3.3 Authentification des substituts 4.3.4 Paramètres de serveur mandataire 4.3.5 Échec de substitution 4.3.6 De la confiance en des binaires 4.4 Des paquets avec plusieurs résultats 4.5 Invoquer ‘guix gc' 4.6 Invoquer ‘guix pull' 4.7 Canaux 4.7.1 Utiliser un canal Guix personnalisé 4.7.2 Spécifier des canaux supplémentaires 4.7.3 Déclarer des dépendances de canaux 4.7.4 Répliquer Guix 4.8 Inférieurs 4.9 Invoquer ‘guix describe' 4.10 Invoquer ‘guix archive' 5 Développement 5.1 Invoquer ‘guix environment' 5.2 Invoquer ‘guix pack' 6 Interface de programmation 6.1 Modules de paquets 6.2 Définition des paquets 6.2.1 Référence de ‘package' 6.2.2 Référence de ‘origin' 6.3 Systèmes de construction 6.4 Le dépôt 6.5 Dérivations 6.6 La monade du dépôt 6.7 G-Expressions 6.8 Invoquer ‘guix repl' 7 Utilitaires 7.1 Invoquer ‘guix build' 7.1.1 Options de construction communes 7.1.2 Options de transformation de paquets 7.1.3 Options de construction supplémentaires 7.1.4 Débogage des échecs de construction 7.2 Invoquer ‘guix edit' 7.3 Invoquer ‘guix download' 7.4 Invoquer ‘guix hash' 7.5 Invoquer ‘guix import' 7.6 Invoquer ‘guix refresh' 7.7 Invoquer ‘guix lint' 7.8 Invoquer ‘guix size' 7.9 Invoque ‘guix graph' 7.10 Invoquer ‘guix publish' 7.11 Invoquer ‘guix challenge' 7.12 Invoquer ‘guix copy' 7.13 Invoquer ‘guix container' 7.14 Invoquer ‘guix weather' 7.15 Invoquer ‘guix processes' 8 Configuration système 8.1 Utiliser le système de configuration Bootloader Paquets visibles sur tout le système Services systèmes Instancier le système L'interface de programmation 8.2 Référence de ‘operating-system' 8.3 Systèmes de fichiers 8.4 Périphériques mappés 8.5 Comptes utilisateurs 8.6 Disposition du clavier 8.7 Régionalisation 8.7.1 Considérations sur la compatibilité des données linguistiques 8.8 Services 8.8.1 Services de base 8.8.2 Exécution de tâches planifiées 8.8.3 Rotation des journaux 8.8.4 Services réseau 8.8.5 Système de fenêtrage X 8.8.6 Services d'impression 8.8.7 Services de bureaux 8.8.8 Services de son 8.8.9 Services de bases de données 8.8.10 Services de courriels 8.8.11 Services de messagerie 8.8.12 Services de téléphonie 8.8.13 Services de surveillance 8.8.14 Services Kerberos 8.8.15 Services LDAP 8.8.16 Services web 8.8.17 Services de certificats 8.8.18 Services DNS 8.8.19 Services VPN 8.8.20 Système de fichiers en réseau 8.8.21 Intégration continue 8.8.22 Services de gestion de l'énergie 8.8.23 Services audio 8.8.24 services de virtualisation 8.8.25 Services de contrôle de version 8.8.26 Services de jeu 8.8.27 Services divers 8.8.28 Services de dictionnaires 8.9 Programmes setuid 8.10 Certificats X.509 8.11 Name Service Switch 8.12 Disque de RAM initial 8.13 Configuration du chargeur d'amorçage 8.14 Invoquer ‘guix system' 8.15 Exécuter Guix sur une machine virtuelle 8.15.1 Se connecter par SSH 8.15.2 Utiliser ‘virt-viewer' avec Spice 8.16 Définir des services 8.16.1 Composition de services 8.16.2 Types service et services 8.16.3 Référence de service 8.16.4 Services Shepherd 9 Documentation 10 Installer les fichiers de débogage 11 Mises à jour de sécurité 12 Bootstrapping Se préparer à utiliser les binaires de bootstrap Construire les outils de construction Construire les binaires de bootstrap Réduire l'ensemble des binaires de bootstrap 13 Porter vers une nouvelle plateforme 14 Contribuer 14.1 Construire depuis Git 14.2 Lancer Guix avant qu'il ne soit installé 14.3 La configuration parfaite 14.4 Consignes d'empaquetage 14.4.1 Liberté logiciel 14.4.2 Conventions de nommage 14.4.3 Numéros de version 14.4.4 Synopsis et descriptions 14.4.5 Modules python 14.4.5.1 Spécifier les dépendances 14.4.6 Modules perl 14.4.7 Paquets java 14.4.8 Polices de caractères 14.5 Style de code 14.5.1 Paradigme de programmation 14.5.2 Modules 14.5.3 Types de données et reconnaissance de motif 14.5.4 Formatage du code 14.6 Envoyer des correctifs Envoyer une série de correctifs 15 Remerciements Annexe A La licence GNU Free Documentation Index des concepts Index de programmation GNU Guix ******** Cette documentation décrit GNU Guix version 1.0.0, un outil de gestion de paquets fonctionnel écrit pour le système GNU. Ce manuel est aussi disponible en anglais (*note (guix)Top::), en allemand (*note (guix.de)Top::), en chinois simplifié (*note (guix.zh_CN)Top::) et en espagnol (*note (guix.es)Top::). Si vous souhaitez nous aider à traduire ce manuel en français, vous pouvez nous rejoindre sur le projet de traduction (https://translationproject.org/domain/guix-manual.html) et sur la liste de diffusion traduc@traduc.org (https://listes.traduc.org/mailman/listinfo/traduc/). 1 Introduction ************** GNU Guix(1) est un outil de gestion de paquets et une distribution pour le système GNU. Guix facilite pour les utilisateurs non privilégiés l'installation, la mise à jour et la suppression de paquets, la restauration à un ensemble de paquets précédent, la construction de paquets depuis les sources et plus généralement aide à la création et à la maintenance d'environnements logiciels. Vous pouvez installer GNU Guix sur un système GNU/Linux existant pour compléter les outils disponibles sans interférence (*note Installation::) ou vous pouvez l'utiliser comme distribution système indépendante, “Guix System”(2). *Note Distribution GNU::. ---------- Footnotes ---------- (1) « Guix » se prononce comme « geeks » (en prononçant le « s »), ou « ɡiːks » dans l'alphabet phonétique international (API). (2) Nous appelions le système Guix « la distribution système Guix » ou « GuixSD ». nous considérons maintenant qu'il est plus pertinent de regrouper tout sous la bannière de « Guix » comme, après tout, Guix System est directement disponible sous la commande ‘guix system', meme si vous utilisez une autre distro en dessous ! 1.1 Gérer ses logiciels avec Guix ================================= Guix fournit une interface de gestion des paquets par la ligne de commande (*note Gestion de paquets::), des outils pour aider au développement logiciel (*note Développement::), des utilitaires en ligne de commande pour des utilisations plus avancées (*note Utilitaires::) ainsi que des interfaces de programmation Scheme (*note Interface de programmation::). Son “démon de construction” est responsable de la construction des paquets pour les utilisateurs (*note Paramétrer le démon::) et du téléchargement des binaires pré-construits depuis les sources autorisées (*note Substituts::). Guix contient de nombreuses définitions de paquet GNU et non-GNU qui respectent tous les libertés de l'utilisateur (https://www.gnu.org/philosophy/free-sw.fr.html). Il est _extensible_ : les utilisateurs peuvent écrire leurs propres définitions de paquets (*note Définition des paquets::) et les rendre disponibles dans des modules de paquets indépendants (*note Modules de paquets::). Il est aussi _personnalisable_ : les utilisateurs peuvent _dériver_ des définitions de paquets spécialisées à partir de définitions existantes, même depuis la ligne de commande (*note Options de transformation de paquets::). Sous le capot, Guix implémente la discipline de “gestion de paquet fonctionnel” inventé par Nix (*note 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” (*note 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 et le ramassage de miettes pour les paquets (*note Fonctionnalités::). 1.2 Distribution GNU ==================== Guix fournit aussi une distribution du système GNU contenant uniquement des logiciels libres(1). On peut installer la distribution elle-même (*note Installation du système::), mais on peut aussi installer Guix comme gestionnaire de paquets par dessus un système GNU/Linux déjà installé (*note 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 (http://www.gnu.org/software/guix/packages) ou en lançant ‘guix package' (*note 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 à exercer ses libertés. Les paquets sont actuellement disponibles pour les plateformes suivantes : ‘x86_64-linux' l'architecture Intel et AMD ‘x86_64' avec le noyau Linux-libre ; ‘i686-linux' l'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 ARMv8-A 64-bits en little-endian avec le noyau Linux-libre. Le support est actuellement expérimental et limité. *Note Contribuer::, pour savoir comment aider ! ‘mips64el-linux' les processeurs MIPS 64-bits little-endian, spécifiquement la série Loongson, ABI n32, avec le noyau Linux-libre. 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 (*note Configuration système::). Guix System utilise le noyau Linux-libre, le système d'initialisation Shepherd (*note (shepherd)Introduction::), 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'. Pour des informations sur comment porter vers d'autres architectures et d'autres noyau, *note Porter::. La construction de cette distribution est un effort collaboratif et nous vous invitons à nous rejoindre ! *Note Contribuer::, pour des informations sur la manière de nous aider. ---------- Footnotes ---------- (1) Le terme « libre » se réfère ici bien sûr à la liberté offerte à l'utilisateur de ces logiciels (http://www.gnu.org/philosophy/free-sw.fr.html). 2 Installation ************** Remarque : Nous vous recommandons d'utiliser ce script shell d'installation (https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh) pour installer Guix sur un système GNU/Linux fonctionnel, que nous appelons une “distro externe”(1). Le script automatise le téléchargement, l'installation et la configuration initiale de Guix. Vous devez l'exécuter en tant qu'utilisateur root. Lorsqu'il est installé sur une distro externe, GNU Guix complète les outils disponibles sans interférence. Ses données se trouvent exclusivement dans deux répertoires, typiquement ‘/gnu/store' et ‘/var/guix' ; les autres fichiers de votre système comme ‘/etc' sont laissés intacts. Une fois installé, Guix peut être mis à jour en lançant ‘guix pull' (*note Invoquer guix pull::). Si vous préférez effectuer les étapes d'installation manuellement ou si vous voulez les personnaliser, vous trouverez les sections suivantes utile. Elles décrivent les prérequis logiciels pour Guix, ainsi que la manière de l'installer manuellement et de se préparer à l'utiliser. ---------- Footnotes ---------- (1) Cette section s'occupe de l'installation du gestionnaire de paquet, ce qui peut se faire sur un système GNU/Linux existant. Si vous voulez plutôt installer le système d'exploitation GNU complet, *note Installation du système::. 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 vous recommandons d'utiliser ce script d'installation shell (https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh). Ce script automatise le téléchargement, l'installation et les étapes de configuration initiales décrites plus bas. Vous devriez le lancer en tant qu'utilisateur root. L'installation se comme ceci : 1. Téléchargez l'archive binaire depuis ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.SYSTÈME.tar.xz', où SYSTÈME est ‘x86_64-linux' pour une machine ‘x86_64' sur laquelle tourne déjà le noyau Linux, etc. 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.0.0.SYSTÈME.tar.xz.sig $ gpg --verify guix-binary-1.0.0.SYSTÈME.tar.xz.sig Si cette commande échoue parce que vous n'avez pas la clef publique requise, lancez cette commande pour l'importer : $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 et relancez la commande ‘gpg --verify'. 2. Maintenant, vous devez devenir l'utilisateur ‘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 \ guix-binary-1.0.0.SYSTÈME.tar.xz # mv var/guix /var/ && mv gnu / Cela crée ‘/gnu/store' (*note Le dépôt::) and ‘/var/guix'. Ce deuxième dossier 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' s'assure que GNU tar ne produise pas d'avertissement disant que « l'horodatage est trop vieux pour être plausible » (ces avertissements étaient produits par GNU tar 1.26 et précédents ; les versions récentes n'ont pas ce problème). Cela vient du fait que les fichiers de l'archive ont pour date de modification zéro (ce qui signifie le 1er janvier 1970). C'est fait exprès pour s'assurer que le contenu de l'archive ne dépende pas de la date de création, ce qui la rend reproductible. 3. Rendez le profil disponible sous ‘~root/.config/guix/current', qui est l'emplacement où ‘guix pull' installera les mises à jour (*note Invoquer guix pull::) : # mkdir -p ~root/.config/guix # ln -sf /var/guix/profiles/per-user/root/current-guix \ ~root/.config/guix/current Sourcez ‘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 utilisateurs pour les utilisateurs de construction comme expliqué plus loin (*note 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/guix-daemon.service \ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon Si votre distribution hôte utilise le système d'initialisation Upstart : # initctl reload-configuration # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \ /etc/init/ # start guix-daemon Sinon, vous pouvez toujours démarrer le démon manuellement avec : # ~root/.config/guix/current/bin/guix-daemon \ --build-users-group=guixbuild 6. Rendez la commande ‘guix' disponible pour les autres utilisateurs 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 Comme cela, en supposant que ‘/usr/local/share/info' est dans le chemin de recherche, lancer ‘info guix' ouvrira ce manuel (*note (texinfo)Other Info Directories::, pour plus de détails sur comment changer le chemin de recherche de Info). 7. Pour utiliser les substituts de ‘ci.guix.gnu.org' ou l'un de ses miroirs (*note Substituts::), autorisez-les : # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub 8. Chaque utilisateur peut avoir besoin d'effectuer des étapes supplémentaires pour que leur environnement Guix soit prêt à être utilisé, *note 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 *Note 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 (http://gnu.org/software/guile/), version 2.2.x, • Guile-Gcrypt (https://notabug.org/cwebber/guile-gcrypt), version 0.1.0 ou supérieure, • GnuTLS (http://gnutls.org/), en particulier ses liaisons Guile (*note how to install the GnuTLS bindings for Guile: (gnutls-guile)Guile Preparations.), • Guile-SQLite3 (https://notabug.org/guile-sqlite3/guile-sqlite3), version 0.1.0 ou supérieure, • Guile-Git (https://gitlab.com/guile-git/guile-git), d'août 2017 ou ultérieur, • Guile-JSON (https://savannah.nongnu.org/projects/guile-json/), • zlib (http://zlib.net), • GNU Make (http://www.gnu.org/software/make/). Les dépendances suivantes sont facultatives : • Le support pour la décharge de construction (*note Réglages du délestage du démon::) et ‘guix copy' (*note Invoquer guix copy::) dépend de Guile-SSH (https://github.com/artyom-poptsov/guile-ssh), version 0.10.2 ou ultérieure. • Lorsque libbz2 (http://www.bzip.org) est disponible, ‘guix-daemon' peut l'utiliser pour compresser les journaux de construction. À moins que ‘--disable-daemon' ne soit passé à ‘configure', les paquets suivants sont aussi requis : • GNU libgcrypt (http://gnupg.org/), • SQLite 3 (http://sqlite.org), • GCC's g++ (http://gcc.gnu.org), 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' (*note ‘localstatedir': (standards)Directory Variables.). Le script ‘configure' vous protège des mauvaises configurations involontaires de LOCALSTATEDIR pour éviter que vous ne corrompiez votre dépôt (*note Le dépôt::). Lorsque vous avez une installation fonctionnelle du gestionnaire de paquets Nix (http://nixos.org/nix/), vous pouvez configurer Guix avec ‘--disable-daemon'. Dan ce cas, Nix remplace les trois dépendances au dessus. Guix est compatible avec Nix, donc il est possible de partager le même dépôt entre les deux. Pour cela, vous devez passer à ‘configure' non seulement la même valeur de ‘--with-store-dir' mais aussi la même valeur de ‘--localstatedir'. Cette dernière est nécessaires car elle spécifie l'emplacement de la base de données qui stocke les métadonnées sur le dépôt, entre autres choses. Les valeurs par défaut pour Nix sont ‘--with-store-dir=/nix/store' et ‘--localstatedir=/nix/var'. Remarquez que ‘--disable-daemon' n'est pas requis si votre but est de partager le dépôt avec Nix. 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" 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 (*note 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 (*note 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 *note Substituts:: pour apprendre comment permettre le téléchargement de binaires pré-construits. 2.4.1 Réglages de l'environnement de construction ------------------------------------------------- Dans une installation standard multi-utilisateurs, Guix et son démon — le programme ‘guix-daemon' — sont installé par l'administrateur système ; ‘/gnu/store' appartient à ‘root' et ‘guix-daemon' est lancé en ‘root'. Les utilisateurs non-privilégiés peuvent utiliser les outils Guix pour construire des paquets ou accéder au dépôt et le démon le fera pour leur compte en s'assurant que le dépôt garde un état cohérent et permet le partage des paquets déjà construits entre les utilisateurs. Alors que ‘guix-daemon' tourne en ‘root', vous n'avez pas forcément envie que les processus de construction de paquets tournent aussi en ‘root', pour des raisons de sécurité évidentes. Pour éviter cela, vous devriez créer une réserve spéciale d'“utilisateurs de construction” que les processus de construction démarrés par le démon utiliseront. Ces utilisateurs de construction n'ont pas besoin d'un shell ou d'un répertoire personnel ; ils seront seulement utilisés quand le démon délaissera ses privilèges ‘root' dans les processus de construction. En ayant plusieurs de ces utilisateurs, vous permettez au démon de lancer des processus de construction distincts sous des UID différent, ce qui garanti qu'aucune interférence n'ait lieu entre les uns et les autres — une fonctionnalité essentielle puisque les constructions sont supposées être des fonctions pures (*note Introduction::). Sur un système GNU/Linux, on peut créer une réserve d'utilisateurs de construction comme ceci (avec la syntaxe Bash et les commandes ‘shadow') : # groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \ -d /var/empty -s `which nologin` \ -c "Utilisateur de construction Guix $i" --system \ guixbuilder$i; done Le nombre d'utilisateurs de construction détermine le nombre de tâches de constructions qui peuvent tourner en parallèle, tel que spécifié par l'option ‘--max-jobs' (*note ‘--max-jobs': Invoquer guix-daemon.). Pour utiliser ‘guix system vm' et les commandes liées, vous devrez ajouter les utilisateurs de construction au groupe ‘kvm' pour qu'ils puissent accéder à ‘/dev/kvm' avec ‘-G guixbuild,kvm' plutôt que ‘-G guixbuild' (*note Invoquer guix system::). Le programme ‘guix-daemon' peut ensuite être lancé en ‘root' avec la commande suivante(1) : # guix-daemon --build-users-group=guixbuild De cette façon, le démon démarre les processus de construction dans un chroot, sous un des utilisateurs ‘guixbuilder'. Sur GNU/Linux par défaut, l'environnement chroot ne contient rien d'autre que : • un répertoire ‘/dev' minimal, créé presque indépendamment du ‘/dev' de l'hôte(2) ; • le répertoire ‘/proc' ; il ne montre que les processus du conteneur car on utilise une espace de nom séparé pour les PID ; • ‘/etc/passwd' avec une entrée pour l'utilisateur actuel et une entrée pour l'utilisateur ‘nobody' ; • ‘/etc/group' avec une entrée pour le groupe de l'utilisateur ; • ‘/etc/hosts' avec une entrée qui fait correspondre ‘localhost' à ‘127.0.0.1' ; • un répertoire ‘/tmp' inscriptible. Vous pouvez influencer le répertoire où le démon stocke les arbres de construction via la variable d'environnement ‘TMPDIR'. Cependant, l'arbre de construction dans le chroot sera toujours appelé ‘/tmp/guix-build-NOM.drv-0', où NOM est le nom de la dérivation — p. ex. ‘coreutils-8.24'. De cette façon, la valeur de ‘TMPDIR' ne fuite pas à l'intérieur des environnements de construction, ce qui évite des différences lorsque le processus de construction retient le nom de leur répertoire de construction. Le démon tient aussi compte de la variable d'environnement ‘http_proxy' pour ses téléchargements HTTP, que ce soit pour les dérivations à sortie fixes (*note Dérivations::) ou pour les substituts (*note Substituts::). Si vous installez Guix en tant qu'utilisateur non-privilégié, il est toujours possible de lancer ‘guix-daemon' si vous passez ‘--disable-chroot'. Cependant, les processus de construction ne seront pas isolés les uns des autres ni du reste du système. Ainsi les processus de construction peuvent interférer les uns avec les autres, et peuvent accéder à des programmes, des bibliothèques et d'autres fichiers présents sur le système — ce qui rend plus difficile de les voir comme des fonctions _pures_. ---------- Footnotes ---------- (1) Si votre machine utilise le système d'initialisation systemd, copiez le fichier ‘PREFIX/lib/systemd/system/guix-daemon.service' dans ‘/etc/systemd/system' pour vous assurer que ‘guix-daemon' est démarré automatiquement. De même, si votre machine utilise le système d'initialisation Upstart, copiez le fichier ‘PREFIX/lib/upstart/system/guix-daemon.conf' dans ‘/etc/init'. (2) « presque », parce que même si l'ensemble des fichiers qui apparaissent dans le ‘/dev' du chroot sont déterminés à l'avance, la plupart de ces fichiers ne peut pas être créée si l'hôte ne les a pas. 2.4.2 Utiliser le dispositif de déchargement -------------------------------------------- Si vous le souhaitez, le démon de construction peut “décharger” des constructions de dérivations sur d'autres machines Guix avec le “crochet de construction” ‘offload'(1). Lorsque cette fonctionnalité est activée, Guix lit une liste de machines de constructions spécifiée par l'utilisateur dans ‘/etc/guix/machines.scm' ; à chaque fois qu'une construction est demandée, par exemple par ‘guix build', le démon essaie de la décharger sur une des machines qui satisfont les contraintes de la dérivation, en particulier le type de système, p. ex. ‘x86_64-linux'. Les prérequis manquants pour la construction sont copiés par SSH sur la machine de construction qui procède ensuite à la construction ; si elle réussi, les sorties de la construction sont copiés vers la machine de départ. Le fichier ‘/etc/guix/machines.scm' ressemble typiquement à cela : (list (build-machine (name "eightysix.example.org") (system "x86_64-linux") (host-key "ssh-ed25519 AAAAC3Nza...") (user "bob") (speed 2.)) ;très rapide ! (build-machine (name "meeps.example.org") (system "mips64el-linux") (host-key "ssh-rsa AAAAB3Nza...") (user "alice") (private-key (string-append (getenv "HOME") "/.ssh/identity-for-guix")))) Dans l'exemple ci-dessus nous spécifions une liste de deux machines de construction, une pour l'architecture ‘x86_64' et une pour l'architecture ‘mips64el'. En fait, ce fichier est — et ça ne devrait pas vous surprendre ! — un fichier Scheme qui est évalué au démarrage du crochet ‘offload'. Sa valeur de retour doit être une liste d'objets ‘build-machine'. Même si cet exemple montre une liste fixée de machines de construction, on pourrait imaginer par exemple utiliser DNS-SD pour renvoyer une liste de machines de constructions potentielles découvertes sur le réseau local (*note Guile-Avahi: (guile-avahi)Introduction.). Le type de données ‘build-machine' est détaillé plus bas. -- Type de données : build-machine Ce type de données représente les machines de construction sur lesquelles le démon peut décharger des constructions. Les champs importants sont : ‘name' Le nom d'hôte de la machine distante. ‘system' Le type de système de la machine distante, p. ex. ‘"x86_64-linux"'. ‘user' Le compte utilisateur à utiliser lors de la connexion à la machine distante par SSH. Remarquez que la paire de clef SSH ne doit _pas_ être protégée par mot de passe pour permettre des connexions non-interactives. ‘host-key' Cela doit être la “clef d'hôte SSH publique” de la machine au format OpenSSH. Elle est utilisée pour authentifier la machine lors de la connexion. C'est une longue chaîne qui ressemble à cela : ssh-ed25519 AAAAC3NzaC...mde+UhL hint@example.org Si la machine utilise le démon OpenSSH, ‘sshd', la clef d'hôte se trouve dans un fichier comme ‘/etc/ssh/ssh_host_ed25519_key.pub'. Si la machine utilise le démon SSH de GNU lsh, la clef d'hôte est dans ‘/etc/lsh/host-key.pub' ou un fichier similaire. Elle peut être convertie au format OpenSSH avec ‘lsh-export-key' (*note (lsh)Converting keys::) : $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV... Il y a un certain nombre de champs facultatifs que vous pouvez remplir : ‘port' (par défaut : ‘22') Numéro de port du serveur SSH sur la machine. ‘private-key' (par défaut : ‘~root/.ssh/id_rsa') Le fichier de clef privée SSH à utiliser lors de la connexion à la machine, au format OpenSSH. Cette clef ne doit pas être protégée par phrase de passe. Remarquez que la valeur par défaut est la clef privée _du compte root_. Assurez-vous qu'elle existe si vous utilisez la valeur par défaut. ‘compression' (par défaut : ‘"zlib@openssh.com,zlib"') ‘compression-level' (par défaut : ‘3') Les méthodes de compression au niveau SSH et le niveau de compression demandé. Remarquez que le déchargement utilise la compression SSH pour réduire la bande passante utilisée lors du transfert vers et depuis les machines de construction. ‘daemon-socket' (par défaut : ‘"/var/guix/daemon-socket/socket"') Le nom de fichier du socket Unix-domain sur lequel ‘guix-daemon' écoute sur cette machine. ‘parallel-builds' (par défaut : ‘1') Le nombre de constructions qui peuvent tourner simultanément sur la machine. ‘speed' (par défaut : ‘1.0') Un « facteur de vitesse relatif ». L'ordonnanceur des constructions tendra à préférer les machines avec un plus grand facteur de vitesse. ‘features' (par défaut : ‘'()') Une liste de chaînes qui contient les fonctionnalités spécifiques supportées par la machine. Un exemple est ‘"kvm"' pour les machines qui ont le module Linux KVM et le support matériel correspondant. Les dérivations peuvent demander des fonctionnalités par leur nom et seront orchestrées sur les machines de construction correspondantes. La commande ‘guix' doit être dans le chemin de recherche des machines de construction. Vous pouvez vérifier si c'est le cas en lançant : ssh build-machine guix repl --version Il reste une dernière chose à faire maintenant que ‘machines.scm' est en place. Comme expliqué ci-dessus, lors du déchargement les fichiers sont transférés entre les dépôts des machines. Pour que cela fonctionne, vous devez d'abord générer une paire de clef sur chaque machine pour permettre au démon d'exporter des archives signées des fichiers de son dépôt (*note Invoquer guix archive::) : # guix archive --generate-key Chaque machine de construction doit autoriser la clef de la machine maîtresse pour qu'ils acceptent les éléments de dépôt de celle-ci : # guix archive --authorize < master-public-key.txt De même, la machine maîtresse doit autoriser les clefs de chaque machine de construction. Toute cette histoire de clefs permet d'exprimer la confiance mutuelle deux-à-deux entre le maître et les machines de construction. Concrètement, lorsque le maître reçoit des fichiers d'une machine de construction (et vice-versa), son démon de construction s'assure qu'ils sont authentiques, n'ont pas été modifiés par un tiers et qu'il sont signés par un clef autorisée. Pour tester que votre paramétrage fonctionne, lancez cette commande sur le nœud maître : # guix offload test Cela essaiera de se connecter à toutes les machines de construction spécifiées dans ‘/etc/guix/machines.scm', s'assurera que Guile et les modules Guix sont disponibles sur toutes les machines et tentera d'exporter vers la machine et d'importer depuis elle, et rapportera toute erreur survenu pendant le processus. Si vous souhaitez tester un fichier de machines différent, spécifiez-le sur la ligne de commande : # guix offload test machines-qualif.scm Enfin, vous pouvez tester un sous-ensemble de machines dont le nom correspond à une expression rationnelle comme ceci : # guix offload test machines.scm '\.gnu\.org$' Pour afficher la charge actuelle de tous les hôtes de construction, lancez cette commande sur le nœud principal : # guix offload status ---------- Footnotes ---------- (1) Cette fonctionnalité n'est disponible que si Guile-SSH (https://github.com/artyom-poptsov/guile-ssh) est présent. 2.4.3 Support de SELinux ------------------------ Guix inclus un fichier de politique SELinux dans ‘etc/guix-daemon.cil' qui peut être installé sur un système où SELinux est activé pour que les fichiers Guix soient étiquetés et pour spécifier le comportement attendu du démon. Comme Guix System ne fournit pas de politique SELinux de base, la politique du démon ne peut pas être utilisée sur le système Guix. 2.4.3.1 Installer la politique SELinux ...................................... Pour installer la politique, lancez cette commande en root : semodule -i etc/guix-daemon.cil Puis ré-étiquetez le système de fichier avec ‘restorecon' ou par un mécanisme différent fournit par votre système. Une fois la politique installée, le système de fichier ré-étiqueté et le démon redémarré, il devrait être lancé dans le contexte ‘guix_daemon_t'. Vous pouvez le confirmer avec la commande suivante : ps -Zax | grep guix-daemon Surveillez les fichiers journaux de SELinux pendant que vous lancez une commande comme ‘guix build hello' pour vous convaincre que SELniux permet toutes les opérations nécessaires. 2.4.3.2 Limitations ................... La politique n'est pas parfaite. Voici une liste de limitations et de bizarreries qui vous devriez prendre en compte avant de déployer la politique SELinux fournie pour le démon Guix. 1. ‘guix_daemon_socket_t' n'est pas vraiment utilisé. Aucune des opérations sur les sockets n'impliquent de contextes qui ont quoi que ce soit à voir avec ‘guix_daemon_socket_t'. Ça ne fait pas de mal d'avoir une étiquette inutilisée, mais il serait préférable de définir des règles sur les sockets uniquement pour cette étiquette. 2. ‘guix gc' ne peut pas accéder à n'importe quel lien vers les profils. Par conception, l'étiquette de fichier de la destination d'un lien symbolique est indépendant de l'étiquette du lien lui-même. Bien que tous les profils sous $localstatedir aient une étiquette, les liens vers ces profils héritent de l'étiquette du répertoire dans lequel ils se trouvent. Pour les liens dans le répertoire personnel cela sera ‘user_home_t'. Mais pour les liens du répertoire personnel de l'utilisateur root, ou ‘/tmp', ou du répertoire de travail du serveur HTTP, etc, cela ne fonctionnera pas. SELinux empêcherait ‘guix gc' de lire et de suivre ces liens. 3. La fonctionnalité du démon d'écouter des connexions TCP pourrait ne plus fonctionner. Cela demande des règles supplémentaires car SELinux traite les sockets réseau différemment des fichiers. 4. Actuellement tous les fichiers qui correspondent à l'expression rationnelle ‘/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon' reçoivent l'étiquette ‘guix_daemon_exec_t' ; cela signifie que _tout_ fichier avec ce nom dans n'importe quel profil serait autorisé à se lancer dans le domaine ‘guix_daemon_t'. Ce n'est pas idéal. Un attaquant pourrait construire un paquet qui fournit cet exécutable et convaincre un utilisateur de l'installer et de le lancer, ce qui l'élève dans le domaine ‘guix_daemon_t'. À ce moment SELinux ne pourrait pas l'empêcher d'accéder à des fichiers autorisés pour les processus de ce domaine. Nous pourrions générer une politique bien plus restrictive à l'installation, pour que seuls les noms de fichiers _exacts_ de l'exécutable ‘guix-daemon' actuellement installé soit étiqueté avec ‘guix_daemon_exec_t', plutôt que d'utiliser une expression rationnelle plus large. L'inconvénient c'est que root devrait installer ou mettre à jour la politique à l'installation à chaque fois que le paquet Guix qui fournit l'exécutable ‘guix-daemon' effectivement exécuté est mis à jour. 2.5 Invoquer ‘guix-daemon' ========================== Le programme ‘guix-daemon' implémente toutes les fonctionnalités d'accès au dépôt. Cela inclus le lancement des processus de construction, le lancement du ramasse-miettes, la demande de disponibilité des résultats de construction, etc. Il tourne normalement en ‘root' comme ceci : # guix-daemon --build-users-group=guixbuild Pour des détails sur son paramétrage, *note Paramétrer le démon::. Par défaut, ‘guix-daemon' lance les processus de construction sous différents UID 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 (*note dérivation: Interface de programmation.), 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, elle a un espace de montage séparé, son propre espace de PID, son espace de réseau, etc. Cela aide à obtenir des constructions reproductibles (*note Fonctionnalités::). Lorsque le démon effectue une construction pour le compte de l'utilisateur, il crée un répertoire sous ‘/tmp' ou sous le répertoire spécifié par sa variable d'environnement ‘TMPDIR'. Ce répertoire est partagé avec le conteneur pendant la durée de la construction, bien que dans le conteneur, l'arborescence de construction est toujours appelée ‘/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' (*note ‘--keep-failed': Invoquer guix build.). 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 actif. *Note Invoquer guix processes:: pour plus d'informations. Les options en ligne de commande suivantes sont disponibles : ‘--build-users-group=GROUPE' Prendre les utilisateurs de GROUP pour lancer les processus de construction (*note utilisateurs de construction: Paramétrer le démon.). ‘--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 (*note Substituts::). Lorsque le démon tourne avec ‘--no-substitutes', les clients peuvent toujours activer explicitement la substitution via l'appel de procédure distante ‘set-build-options' (*note Le dépôt::). ‘--substitute-urls=URLS' Considérer URLS comme la liste séparée par des espaces des URL des sources de substituts par défaut. Lorsque cette option est omise, ‘https://ci.guix.gnu.org' est utilisé. Cela signifie que les substituts sont téléchargés depuis les URLS, tant qu'ils sont signés par une signature de confiance (*note Substituts::). ‘--no-build-hook' Ne pas utiliser le “crochet de construction”. Le crochet de construction est un programme d'aide qui le démon peut démarrer et auquel soumettre les requêtes de construction. Ce mécanisme est utilisé pour décharger les constructions à d'autres machines (*note Réglages du délestage du démon::). ‘--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é. *Note 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 modifiée par les clients comme avec l'option ‘--cores' de ‘guix build' (*note 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 (*note Réglages du délestage du démon::) ou échouera. ‘--max-silent-time=SECONDES' Lorsque le processus de construction ou de substitution restent silencieux pendant plus de SECONDES, le terminer et rapporter une erreur de construction. La valeur par défaut est ‘0', ce qui désactive le délai. La valeur spécifiée ici peut être modifiée par les clients (*note ‘--max-silent-time': Options de construction communes.). ‘--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 modifiée par les clients (*note ‘--timeout': Options de construction communes.). ‘--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' (*note 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 modifiée par les clients, par exemple par l'option ‘--verbosity' de ‘guix build' (*note 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 en tant qu'utilisateur non privilégié. ‘--log-compression=TYPE' Compresser les journaux de construction suivant le TYPE, parmi ‘gzip', ‘bzip2' ou ‘none'. À moins que ‘--lose-logs' ne soit utilisé, tous les journaux de construction sont gardés dans LOCALSTATEDIR. Pour gagner de la place, le démon les compresse automatiquement avec bzip2 par défaut. ‘--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'elle est à « yes », le GC gardera les sorties de toutes les dérivations — les fichiers ‘.drv' — accessibles dans le dépôt. La valeur par défaut est « no », ce qui signifie que les sorties des dérivations ne sont gardées que si elles sont accessibles à partir d'une racine du GC. *Note Invoquer guix gc:: pour plus d'informations sur les racines du GC. ‘--gc-keep-derivations[=yes|no]' Dire si le ramasse-miettes (GC) doit garder les dérivations correspondant à des sorties utilisées. Lorsqu'elle est à « 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 aux utilisateurs 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, avec ‘--gc-keep-derivations' à « yes », l'accessibilité des sorties s'étend des sorties aux dérivations et avec ‘--gc-keep-outputs' à « yes », elle s'étend des dérivations aux sorties. Quand les deux options sont à « yes », le GC gardera tous les prérequis de construction (les sources, le compilateur, les bibliothèques, et les autres outils de construction) des objets accessibles dans le dépôt, indépendamment du fait qu'ils soient ou non accessibles depuis une racine du GC. Cela est pratique pour les développeurs car ça leur fait gagner du temps de reconstruction et de téléchargement. ‘--impersonate-linux-2.6' Sur les système basés sur Linux, se faire passer pour Linux 2.6. Cela signifie que l'appel système du noyau ‘uname' rapportera 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 toutes les extrémités spécifiées. Les utilisateurs peuvent dire aux commandes clientes à quelle extrémité se connecter en paramétrant la variable d'environnement ‘GUIX_DAEMON_SOCKET' (*note ‘GUIX_DAEMON_SOCKET': Le dépôt.). Remarque : Le protocole du démon est _non authentifié et non chiffré_. Utiliser ‘--listen=HOST' est adapté sur des réseaux locaux, comme pour des grappes de serveurs, où seuls des nœuds de confiance peuvent se connecter au démon de construction. Dans les autres cas où l'accès à distance au démon est requis, nous conseillons d'utiliser un socket Unix-domain avec SSH. Lorsque ‘--listen' est omis, ‘guix-daemon' écoute les connexions sur le socket Unix-domain situé à ‘LOCALSTATEDIR/guix/daemon-socket/socket'. 2.6 Réglages applicatifs ======================== Lorsque vous utilisez Guix par dessus une distribution GNU/Linux qui n'est pas Guix System — ce qu'on appelle une “distro externe” — quelques étapes supplémentaires sont requises pour que tout soit en place. En voici certaines. 2.6.1 Régionalisation --------------------- Les paquets installés via Guix n'utiliseront pas les données de régionalisation du système hôte. À la place, vous devrez d'abord installer l'un des paquets linguistiques disponibles dans Guix puis définir la variable d'environnement ‘GUIX_LOCPATH' : $ guix install glibc-locales $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale Remarquez que le paquet ‘glibc-locales' contient les données pour tous les environnement linguistiques supportés par la GNU libc et pèse environ 110 Mo. Autrement, les ‘glibc-utf8-locales' est plus petit mais limité à quelques environnements UTF-8. La variable ‘GUIX_LOCPATH' joue un rôle similaire à ‘LOCPATH' (*note ‘LOCPATH': (libc)Locale Names.). Il y a deux différences importantes cependant : 1. ‘GUIX_LOCPATH' n'est compris que par la libc dans Guix et pas par la libc fournie par les distros externes. Ainsi, utiliser ‘GUIX_LOCPATH' vous permet de vous assurer que les programmes de la distro externe ne chargeront pas de données linguistiques incompatibles. 2. La libc ajoute un suffixe ‘/X.Y' à chaque entrée de ‘GUIX_LOCPATH', où ‘X.Y' est la version de la libc — p. ex. ‘2.22'. Cela signifie que, si votre profile Guix contient un mélange de programmes liés avec des versions différentes de la libc, chaque version de la libc essaiera de charger les environnements linguistiques dans le bon format. Cela est important car le format des données linguistiques utilisés par différentes version de la libc peuvent être incompatibles. 2.6.2 Name Service Switch ------------------------- Lorsque vous utilisez Guix sur une distro externe, nous _recommandons fortement_ que ce système fasse tourner le “démon de cache de service de noms” de la bibliothèque C de GNU, ‘nscd', qui devrait écouter sur le socket ‘/var/run/nscd/socket'. Sans cela, les applications installées avec Guix peuvent échouer à résoudre des noms d'hôtes ou d'utilisateurs, ou même planter. Les paragraphes suivants expliquent pourquoi. La bibliothèque C de GNU implémente un “name service switch” (NSS), qui est un mécanisme d'extension pour les « résolutions de noms » en général : résolution de nom d'hôte, de compte utilisateur et plus (*note (libc)Name Service Switch::). Comme il est extensible, NSS supporte des “greffons” qui fournissent une nouvelle implémentation de résolution de nom : par exemple le greffon ‘nss-mdns' permet la résolution de noms d'hôtes en ‘.local', le greffon ‘nis' permet la résolution de comptes utilisateurs avec le Network Information Service (NIS), etc. Ces « services de recherches » supplémentaires sont configurés au niveau du système dans ‘/etc/nsswitch.conf', et tous les programmes qui tournent sur ce système honorent ces paramètres (*note (libc)NSS Configuration File::) Lorsqu'ils essayent d'effectuer une résolution de nom — par exemple en appelant la fonction ‘getaddrinfo' en C — les applications essayent d'abord de se connecter au nscd ; en cas de réussite, nscd effectue la résolution de nom pour eux. Si le nscd ne tourne pas, alors ils effectuent la résolution eux-mêmes, en changeant les service de résolution dans leur propre espace d'adressage et en le lançant. Ce services de résolution de noms — les fichiers ‘libnns_*.so' — sont ‘dlopen'és mais ils peuvent provenir de la bibliothèque C du système, plutôt que de la bibliothèque C à laquelle l'application est liée (la bibliothèque C de Guix). Et c'est là que se trouve le problème : si votre application est liée à la bibliothèque C de Guix (disons, glibc-2.24) et essaye de charger les greffons NSS d'une autre bibliothèque C (disons, ‘libnss_mdns.so' pour glibc-2.22), il est très probable qu'elle plante ou que sa résolution de nom échoue de manière inattendue. Lancer ‘nscd' sur le système, entre autres avantages, élimine ce problème d'incompatibilité binaire car ces fichiers ‘libnss_*.so' sont chargés par le processus ‘nscd', pas par l'application elle-même. 2.6.3 Polices X11 ----------------- La majorité des applications graphiques utilisent fontconfig pour trouver et charger les police et effectuer le rendu côté client X11. Le paquet ‘fontconfig' dans Guix cherche les polices dans ‘$HOME/.guix-profile' par défaut. Ainsi, pour permettre aux applications graphiques installées avec Guix d'afficher des polices, vous devez aussi installer des polices avec Guix. Les paquets de polices essentiels sont ‘gs-fonts', ‘font-dejavu' et ‘font-gnu-freefont-ttf'. Pour afficher des textes écrits en chinois, en japonais ou en coréen dans les applications graphiques, installez ‘font-adobe-source-han-sans' ou ‘font-wqy-zenhei'. Le premier a plusieurs sorties, une par famille de langue (*note Des paquets avec plusieurs résultats::). Par exemple, la commande suivante installe les polices pour le chinois : guix install font-adobe-source-han-sans:cn Les vieux programmes comme ‘xterm' n'utilisent pas fontconfig et s'appuient sur le rendu du côté du serveur. Ces programmes ont besoin de spécifier le nom complet de la police en utilisant XLFD (X Logical Font Description), comme ceci : -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1 Pour pouvoir utiliser ces noms complets avec les polices TrueType installées dans votre profil Guix, vous devez étendre le chemin des polices du serveur X : xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir)) Ensuite, vous pouvez lancer ‘xlsfonts' (du paquet ‘xlsfonts') pour vous assurer que vos polices TrueType y sont listées. Après l'installation des polices vous devrez peut-être rafraîchir le cache des polices pour pouvoir les utiliser dans les applications. Ça s'applique aussi lorsque les applications installées avec Guix n'ont pas l'air de trouver les polices. Pour forcer la reconstruction du cache de polices lancez ‘fc-cache -f'. La commande ‘fc-cache' est fournie par le paquet ‘fontconfig'. 2.6.4 Certificats X.509 ----------------------- Le paquet ‘nss-certs' fournit les certificats X.509 qui permettent aux programmes d'authentifier les serveurs web par HTTPS. Lorsque vous utilisez Guix sur une distribution externe, vous pouvez installer ce paquet et définir les variables d'environnement adéquates pour que les paquets sachent où trouver les certificats. *Note Certificats X.509::, pour des informations détaillées. 2.6.5 Paquets emacs ------------------- Lorsque vous installez les paquets Emacs avec Guix, les fichiers elisp peuvent être placés soit dans ‘$HOME/.guix-profile/share/emacs/site-lisp/' soit dans des sous-répertoires de ‘$HOME/.guix-profile/share/emacs/site-lisp/guix.d/'. Ce dernier existe car il existe potentiellement des milliers de paquets Emacs et stocker leurs fichiers dans un seul répertoire peut ne pas être fiable (à cause de conflits de noms). Donc on pense qu'utiliser un répertoire séparé est une bonne idée. C'est très similaire à la manière dont le système de paquet d'Emacs organise la structure de fichiers (*note (emacs)Package Files::). Par défaut, Emacs (installé avec Guix) « sait » où ces paquets ce trouvent, donc vous n'avez pas besoin de le configurer. Si, pour quelque raison que ce soit, vous souhaitez éviter de charger automatiquement les paquets Emacs installés avec Guix, vous pouvez le faire en lançant Emacs avec l'option ‘--no-site-file' (*note (emacs)Init File::). 2.6.6 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, vous avez en fait besoin du paquet ‘gcc-toolchain'. Ce paquet fournit une chaîne d'outils 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 une enveloppe 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 le véritable éditeur de liens avec ce nouvel ensemble d'arguments. Vous pouvez dire à l'enveloppe 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'. 3 Installation du système ************************* Cette section explique comment installer Guix System sur une machine. Guix, en tant que gestionnaire de paquets, peut aussi être installé sur un système GNU/Linux déjà installé, *note Installation::. Remarque : Vous lisez cette documentation avec un lecteur Info. Pour des détails sur son utilisation, appuyez sur la touche <ENTRÉE> (« Entrée » ou « à la ligne ») sur le lien suivant : *note Info reader: (info-stnd)Top. Appuyez ensuite sur ‘l' pour revenir ici. Autrement, lancez ‘info info' dans un autre tty pour garder ce manuel ouvert. 3.1 Limitations =============== Nous considérons Guix System comme prêt pour une grande variété de cas d'utilisation pour le « bureau » et le serveur. Les garantis de fiabilité qu'il fournit — les mises à jour transactionnelles, les retours en arrières et la reproductibilité — en font une solide fondation. Néanmoins, avant de procéder à l'installation, soyez conscient de ces limitations les plus importantes qui s'appliquent à la version 1.0.0 : • LVM (gestionnaire de volumes logiques) n'est pas supporté. • De plus en plus de services systèmes sont fournis (*note Services::) mais certains manquent toujours cruellement. • GNOME, Xfce, LXDE et Enlightenment sont disponibles (*note 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. *Note Contribuer::, pour plus d'info. 3.2 Considérations matérielles ============================== GNU Guix se concentre sur le respect des libertés de ses utilisateurs. 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 produit dont les fabricants refusent de laisser le contrôle aux utilisateurs 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 (*note ‘firmware': Référence de système d'exploitation.). La Free Software Foundation (https://www.fsf.org/) a un programme de certification nommé “Respects Your Freedom” (https://www.fsf.org/ryf) (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 (https://www.h-node.org/). 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 ============================================== Vous pouvez télécharger une image d'installation ISO-9660 depuis ‘https://https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.SYSTÈME.iso.xz' et vous pouvez l'écrire sur une clef USB ou la graver sur un DVD, où SYSTÈME est l'une de ces valeurs : ‘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.0.0.SYSTEM.iso.xz.sig $ gpg --verify guix-system-install-1.0.0.SYSTEM.iso.xz.sig Si cette commande échoue parce que vous n'avez pas la clef publique requise, lancez cette commande pour l'importer : $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 et relancez la commande ‘gpg --verify'. 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 ---------------------- Pour copier l'image sur une clef USB, suivez ces étapes : 1. Décompressez l'image avec la commande ‘xz' : xz -d guix-system-install-1.0.0.SYSTÈME.iso.xz 2. Insérez la clef USB de 1 Gio ou plus dans votre machine et déterminez son nom d'appareil. En supposant que la clef usb est connue sous le nom de ‘/dev/sdX', copiez l'image avec : dd if=guix-system-install-1.0.0.SYSTÈME.iso of=/dev/sdX sync Accéder à ‘/dev/sdX' requiert généralement les privilèges super-utilisateur. Graver sur un DVD ----------------- Pour copier l'image sur un DVD, suivez ces étapes : 1. Décompressez l'image avec la commande ‘xz' : xz -d guix-system-install-1.0.0.SYSTÈME.iso.xz 2. Insérez un DVD vierge dans votre machine et déterminez son nom d'appareil. En supposant que le DVD soit connu sont le nom de ‘/dev/srX', copiez l'image avec : growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.0.0.SYSTÈME.iso Accéder à ‘/dev/srX' requiert généralement les privilèges super-utilisateur. Démarrage --------- Une fois que c'est fait, vous devriez pouvoir redémarrer le système et démarrer depuis la clef USB ou le DVD. Pour cela, vous devrez généralement entrer dans le menu de démarrage BIOS ou UEFI, où vous pourrez choisir de démarrer sur la clef USB. *Note Installer Guix dans une VM::, si, à la place, vous souhaitez installer Guix System dans une machine virtuelle (VM). 3.4 Préparer l'installation =========================== Une fois que vous avez démarré, vous pouvez utiliser l'installateur graphique, qui rend facile la prise en main (*note Installation graphique guidée::). Autrement, si vous êtes déjà familier avec GNU/Linux et que vous voulez plus de contrôle que ce que l'installateur graphique ne fournit, vous pouvez choisir le processus d'installation « manuel » (*note 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 (*note (info-stnd)Top::). 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. [paramétrage du réseau avec l'installateur graphique] 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. [partitionnement du disque avec l'installateur graphique] 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. [reprise du processus d'installation] Une fois que vous avez fini, l'installateur produit une configuration de système d'exploitation et vous la montre (*note 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. *Note 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 (*note Installation graphique guidée::). Le système d'installation fournit des shells root sur les TTY 3 à 6 ; appuyez sur ‘ctrl-alt-f3', ‘ctrl-alt-f4' etc pour y accéder. Il inclus plusieurs outils usuels pour requis pour cette tâche. Mais c'est aussi un système Guix complet, ce qui signifie que vous pouvez installer des paquets supplémentaires si vous en avez besoin, avec ‘guix package' (*note Invoquer guix package::). 3.6.1 Disposition du clavier réseau et partitionnement ------------------------------------------------------ Avant que vous ne puissiez installer le système, vous voudrez sans doute ajuster la disposition du clavier, paramétrer le réseau et partitionner le disque dur cible. Cette section vous guidera à travers tout cela. 3.6.1.1 Disposition du clavier .............................. L'image d'installation utilise la disposition clavier qwerty (US). Si vous voulez la changer, vous pouvez utiliser la commande ‘loadkeys'. Par exemple, la commande suivante sélectionne la disposition Dvorak : loadkeys dvorak Consultez les fichiers dans ‘/run/current-system/profile/share/keymaps' pour trouver une liste des dispositions disponibles. Lancez ‘man loadkey' pour plus d'informations. 3.6.1.2 Réseau .............. Lancez la commande suivante pour voir comment vos interfaces réseau sont appelées : ifconfig -a ... ou, avec la commande spécifique à GNU/Linux ‘ip' : ip a Les interfaces filaires ont un nom qui commence par ‘e' ; par exemple, l'interface qui correspond au premier contrôleur Ethernet sur la carte mère est appelé ‘eno1'. Les interfaces sans-fil ont un nom qui commence par ‘w', comme ‘w1p2s0'. Connexion filaire Pour configure une connexion filaire, lancez la commande suivante, en remplaçant INTERFACE par le nom de l'interface filaire que vous voulez utiliser. ifconfig INTERFACE up Connexion sans-fil Pour configurer le réseau sans-fil, vous pouvez créer un fichier de configuration pour l'outil de configuration ‘wpa_supplicant' (son emplacement importe peu) avec l'un des éditeurs de texte disponibles comme ‘nano' : nano wpa_supplicant.conf Par exemple, la déclaration qui suit peut aller dans ce fichier et fonctionnera pour plusieurs réseaux sans-fil, si vous donnez le vrai SSID et la phrase de passe pour le réseau auquel vous vous connectez : network={ ssid="MON-SSID" key_mgmt=WPA-PSK psk="la phrase de passe secrète du réseau" } Démarrez le service sans-fil et lancez-le en tache de fond avec la commande suivante (en remplaçant INTERFACE par le nom de l'interface réseau que vous voulez utiliser) : wpa_supplicant -c wpa_supplicant.conf -i INTERFACE -B Lancez ‘man wpa_supplicant' pour plus d'informations. À partir de ce moment, vous avez besoin d'une adresse IP. Sur les réseaux où les IP sont automatiquement attribuée par DHCP, vous pouvez lancer : dhclient -v INTERFACE Essayez de pinger un serveur pour voir si le réseau fonctionne : ping -c 3 gnu.org Mettre en place un accès réseau est presque toujours une nécessité parce que l'image ne contient pas tous les logiciels et les outils dont vous pourriez avoir besoin. Si vous le souhaitez, vous pouvez continuer l'installation à distance en démarrant un serveur SSH : herd start ssh-daemon Assurez-vous soit de définir un mot de passe avec ‘passwd', soit de configurer l'authentification par clef OpenSSH avant de vous connecter. 3.6.1.3 Partitionnement ....................... À moins que vous ne l'ayez déjà fait, l'étape suivante consiste à partitionner le disque puis à formater les partitions cibles. L'image d'installation inclus plusieurs outils de partitionnement, dont Parted (*note (parted)Overview::), ‘fdisk', et ‘cfdisk'. Lancez-en un et paramétrez votre disque avec le partitionnement qui vous convient : cfdisk Si votre disque utilise le format des tables de partitions GUID (GPT) et que vous souhaitez installer un GRUB pour système BIOS (c'est le cas par défaut), assurez-vous de créer qu'une partition de démarrage BIOS soit bien disponible (*note (grub)BIOS installation::). Si vous souhaitez à la place utilise GRUB pour système EFI, vous devrez avoir une “partition système EFI” (ESP) en FAT32. Cette partition peut être montée dans ‘/boot/efi' par exemple et doit avoir le drapeau ‘esp'. P. ex. pour ‘parted' : parted /dev/sda set 1 esp on Remarque : Vous n'êtes pas sûr de savoir si vous devez utiliser un GRUB EFI ou BIOS ? Si le répertoire ‘/sys/firmware/efi' existe sur l'image d'installation, vous devriez probablement effectuer une installation EFI, avec ‘grub-efi-bootloader'. Sinon, vous devriez utiliser le GRUB en BIOS, ‘grub-bootloader'. *Note Configuration du chargeur d'amorçage:: pour plus d'information sur le chargeur d'amorçage. Une fois que vous avez fini le partitionnement du disque dur cible, vous devez créer un système de fichier sur les partitions(1). Pour l'ESP, si vous en avez une et en supposant que ce soit ‘/dev/sda1', lancez : mkfs.fat -F32 /dev/sda1 Préférez assigner une étiquette au système de fichier pour que vous puissiez vous y référer de manière fiable dans la déclaration ‘file-system' (*note Systèmes de fichiers::). On le fait habituellement avec l'option ‘-L' de ‘mkfs.ext4' et des commandes liées. Donc, en supposant que la partition racine soit sur ‘/dev/sda2', on peut créer un système de fichier avec pour étiquette ‘my-root' avec : mkfs.ext4 -L my-root /dev/sda2 Si vous voulez plutôt chiffrer la partition racine, vous pouvez utiliser les utilitaires Cryptsetup et LUKS pour cela (voir ‘man cryptsetup' pour plus d'informations). En supposant que vous voulez stocker la partition racine sur ‘/dev/sda2', la séquence de commandes suivante vous mènerait à ce résultat : cryptsetup luksFormat /dev/sda2 cryptsetup open --type luks /dev/sda2 my-partition mkfs.ext4 -L my-root /dev/mapper/my-partition Une fois cela effectué, montez le système de fichier cible dans ‘/mnt' avec une commande comme (de nouveau, en supposant que ‘my-root' est l'étiquette du système de fichiers racine) : mount LABEL=my-root /mnt Montez aussi tous les systèmes de fichiers que vous voudriez utiliser sur le système cible relativement à ce chemin. Si vous avez choisi d'avoir un ‘/boot/efi' comme point de montage EFI par exemple, montez-la sur ‘/mnt/boot/efi' maintenant pour qu'elle puisse être trouvée par ‘guix system init' ensuite. Enfin, si vous souhaitez utiliser une ou plusieurs partitions de swap (*note swap space: (libc)Memory Concepts.), assurez-vous de les initialiser avec ‘mkswap'. En supposant que vous avez une partition de swap sur ‘/dev/sda3', vous pouvez lancer : mkswap /dev/sda3 swapon /dev/sda3 Autrement, vous pouvez utiliser un fichier de swap. Par exemple, en supposant que dans le nouveau système vous voulez utiliser le fichier ‘/swapfile' comme fichier de swap, vous lanceriez(2) : # Cela représente 10 Gio d'espace d'échange. Ajustez « count » pour changer la taille. dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240 # Par sécurité, laissez le fichier en lecture et en écriture uniquement pour root. chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile Remarquez que si vous avez chiffré la partition racine et créé un fichier d'échange dans son système de fichier comme décrit ci-dessus, alors le chiffrement protégera aussi le fichier d'échange, comme n'importe quel fichier de ce système de fichiers. ---------- Footnotes ---------- (1) Actuellement Guix System ne supporte que les systèmes de fichiers ext4 et btrfs. En particulier, le code qui lit les UUID des systèmes de fichiers et les étiquettes ne fonctionne que pour ces types de systèmes de fichiers. (2) Cet exemple fonctionnera sur plusieurs types de systèmes de fichiers (p. ex. ext4). Cependant, pour les systèmes de fichiers qui utilisent la copie sur écriture (COW) comme btrfs, les étapes requises peuvent varier. Pour plus de détails, regardez les pages de manuel de ‘mkswap' et ‘swapon'. 3.6.2 Effectuer l'installation ------------------------------ Lorsque la partition cible est prête et que les autres partitions sont montées, on est prêt à commencer l'installation. Commencez par : herd start cow-store /mnt Cela rend ‘/gnu/store' capable de faire de la copie sur écriture, de sorte que les paquets ajoutés pendant l'installation sont écrits sur le disque cible sur ‘/mnt' plutôt que gardés en mémoire. Cela est nécessaire parce que la première phase de la commande ‘guix system init' (voir plus bas) implique de télécharger ou de construire des éléments de ‘/gnu/store' qui est initialement un système de fichiers en mémoire. Ensuite, vous devrez modifier un fichier et fournir la déclaration du système à installer. Pour cela, le système d'installation propose trois éditeurs de texte. Nous recommandons GNU nano (*note (nano)Top::), qui supporte la coloration syntaxique la correspondance de parenthèses ; les autres éditeurs sont GNU Zile (un clone d'Emacs) et nvi (un clone de l'éditeur ‘vi' original de BSD). Nous recommandons vivement de stocker ce fichier sur le système de fichier racine cible, disons en tant que ‘/mnt/etc/config.scm'. Sinon, vous perdrez votre fichier de configuration une fois que vous aurez redémarré sur votre nouveau système. *Note Utiliser le système de configuration::, pour un aperçu de comment créer votre fichier de configuration. Les exemples de configuration dont on parle dans cette section sont disponibles dans ‘/etc/configuration' sur l'image d'installation. Ainsi, pour commencer avec une configuration du système qui fournit un serveur d'affichage graphique (un système de « bureau »), vous pouvez lancer ce qui suit : # mkdir /mnt/etc # cp /etc/configuration/desktop.scm /mnt/etc/config.scm # nano /mnt/etc/config.scm Vous devriez faire attention à ce que contient votre fichier de configuration, en particulier : • Assurez-vous que la forme ‘bootloader-configuration' se réfère à la cible où vous voulez installer GRUB. Elle devrait aussi mentionner ‘grub-bootloader' si vous installer GRUB en mode BIOS (ou « legacy ») ou ‘grub-efi-bootloader' pour les système UEFI plus récents. Pour les anciens systèmes, le champs ‘target' contient un périphérique comme ‘/dev/sda' ; pour les systèmes UEFI il contient un chemin vers une partition EFI montée, comme ‘/boot/efi', et assurez-vous bien que ce chemin est monté et qu'il y a une entrée ‘file-system' dans votre configuration. • Assurez-vous que les étiquettes de vos systèmes de fichiers correspondent aux valeurs de leur champs ‘device' dans votre configuration ‘file-system', en supposant que la configuration ‘file-system' utilise la procédure ‘file-system-label' dans son champ ‘device'. • Si vous avez des partitions RAID ou chiffrées, assurez-vous d'ajouter un champ ‘mapped-device' pour les décrire (*note Périphériques mappés::). Une fois que vous avez fini les préparatifs sur le fichier de configuration, le nouveau système peut être initialisé (rappelez-vous que le système de fichiers racine cible est dans ‘/mnt') : guix system init /mnt/etc/config.scm /mnt Cela copie tous les fichiers nécessaires et installe GRUB sur ‘/dev/sdX' à moins que vous ne passiez l'option ‘--no-bootloader'. Pour plus d'informations, *note Invoquer guix system::. Cette commande peut engendrer des téléchargements ou des constructions pour les paquets manquants, ce qui peut prendre du temps. Une fois que cette commande a terminé — et on l'espère réussi ! — vous pouvez lancer ‘reboot' et démarrer sur votre nouveau système. Le mot de passe ‘root' est d'abord vide ; les mots de passe des autres utilisateurs doivent être initialisés avec la commande ‘passwd' en tant que ‘root', à mois que votre configuration ne spécifie autre chose (*note mot de passe des comptes utilisateurs: user-account-password.). *Note Après l'installation du système::, pour la suite ! 3.7 Après l'installation du système =================================== Bravo ! Vous avez maintenant redémarré sur votre système Guix ! À partir de maintenant, vous pouvez mettre à jour le système quand vous voudrez, avec : guix pull sudo guix system reconfigure /etc/config.scm Cela crée une nouvelle génération du système avec les derniers paquets et services (*note 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é (*note Mises à jour de sécurité::). Remarque : Remarquez que ‘sudo guix' exécute la commande ‘guix' de votre utilisateur et _non_ celle de root, parce que ‘sudo' ne change pas ‘PATH'. Pour utiliser explicitement le ‘guix' de root, tapez ‘sudo -i guix ...'. Rejoignez-nous sur ‘#guix' sur le réseau IRC Freenode 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 (http://qemu.org/) 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 (*note 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 guixsd.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 \ -net user -net nic,model=virtio -boot menu=on \ -drive file=guix-system-install-1.0.0.SYSTÈME.iso \ -drive file=guixsd.img L'ordre des périphérique est important. Dans la console de la VM, appuyez rapidement sur ‘F12' pour entrer dans le menu de démarrage. Ensuite appuyez sur ‘2' et la touche ‘Entrée' pour valider votre choix. 4. Vous êtes maintenant root dans la VM, continuez en suivant la procédure d'installation. *Note Préparer l'installation::, et suivez les instructions. Une fois l'installation terminée, vous pouvez démarrer le système dans votre image ‘guixsd.img'. *Note Lancer Guix dans une VM::, pour une manière de faire. 3.9 Construire l'image d'installation ===================================== L'image d'installation décrite plus haut a été construite avec la commande ‘guix system', plus précisément : guix system disk-image --file-system-type=iso9660 \ gnu/system/install.scm Regardez le fichier ‘gnu/system/install.scm' dans l'arborescence des sources et regardez aussi *note 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 (http://www.denx.de/wiki/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 disk-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 Gestion de paquets ******************** Le but de GNU Guix est de permettre à ses utilisateurs d'installer, mettre à jour et supprimer facilement des paquets logiciels sans devoir connaître leur procédure de construction ou leurs dépendances. Guix va aussi plus loin que ces fonctionnalités évidentes. Ce chapitre décrit les principales fonctionnalités de Guix, ainsi que des outils de gestion des paquets qu'il fournit. En plus de l'interface en ligne de commande décrite en dessous de (*note ‘guix package': Invoquer guix package.), vous pouvez aussi utiliser l'interface Emacs-Guix (*note (emacs-guix)Top::), après avoir installé le paquet ‘emacs-guix' (lancez la commande ‘M-x guix-help' pour le démarrer) : guix install emacs-guix 4.1 Fonctionnalités =================== 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 utilisateurs ont leur propre “profil” qui pointe vers les paquets qu'ils veulent vraiment utiliser. Ces profils sont stockés dans le répertoire personnel de chaque utilisateur 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 (*note Invoquer guix package::). Il opère sur les profils utilisateurs et peut être utilisé avec les _privilèges utilisateurs 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éussi, 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 de l'utilisateur 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 (*note Utiliser le système de configuration::). Tous les paquets 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 utilisateurs et supprimer ceux qui ne sont plus référencés de manière prouvable (*note Invoquer guix gc::). Les utilisateurs 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 (*note 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 utilisateurs 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 à de forte chances de donner des fichiers identiques bit-à-bit lorsqu'elle est effectuée sur des machines différents (*note container: Invoquer guix-daemon.). 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 (*note 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 (*note Invoquer guix challenge::). Le contrôle de l'environnement de construction est aussi une fonctionnalité utile pour les développeurs. La commande ‘guix environment' permet aux développeurs d'un paquet de mettre en place rapidement le bon environnement de développement pour leur paquet, sans avoir à installer manuellement les dépendances du paquet dans leur profil (*note Invoquer guix environment::). La totalité de Guix et des définitions de paquets sont placés sous contrôle de version, et ‘guix pull' vous permet de « voyager dans le temps » de l'historique de Guix lui-même (*note 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. 4.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. Elle n'opère que dans le profil de l'utilisateur et fonctionne avec les privilèges utilisateurs normaux (*note 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 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', • et ‘guix upgrade' est un alias de ‘guix package -u', 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ù l'utilisateur spécifie l'ensemble exact des paquets qui doivent être disponibles le passe via l'option ‘--manifest' (*note ‘--manifest': profile-manifest.). Pour chaque utilisateur, un lien symbolique vers le profil par défaut de cet utilisateur est automatiquement créé dans ‘$HOME/.guix-profile'. Ce lien symbolique pointe toujours vers la génération actuelle du profil par défaut de l'utilisateur. Ainsi, les utilisateurs peuvent ajouter ‘$HOME/.guix-profile/bin' à leur variable d'environnement ‘PATH' etc. Si vous n'utilisez pas la distribution système Guix, vous devriez ajouter les lignes suivantes à votre ‘~/.bash_profile' (*note (bash)Bash Startup Files::) pour que les shells créés ensuite aient tous les bonnes définitions des variables d'environnement : GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" Dans un environnement multi-utilisateur, les profils utilisateurs sont stockés comme une “racine du ramasse-miettes”, vers laquelle pointe ‘$HOME/.guix-profile' (*note Invoquer guix gc::). Ce répertoire est normalement ‘LOCALSTATEDIR/guix/profiles/per-user/UTILISATEUR', où LOCALSTATEDIR est la valeur passée à ‘configure' avec ‘--localstatedir' et UTILISATEUR le nom d'utilisateur. Le répertoire ‘per-user' est créé lorsque ‘guix-daemon' est démarré et sous-répertoire UTILISATEUR est créé par ‘guix package'. Les OPTIONS peuvent être les suivante : ‘--install=PAQUET ...' ‘-i PAQUET ...' Installer les PAQUETs spécifiés. Chaque PAQUET peut spécifier soit un simple nom de paquet, comme ‘guile' ou un nom de paquet suivi d'un arobase et d'un numéro de version, comme ‘guile@1.8.8' ou simplement ‘guile@1.8' (dans ce dernier cas, la version la plus récente commençant par ‘1.8' est utilisée). Si aucun numéro de version n'est spécifié, la version la plus récente disponible est choisie. En plus, PAQUET peut contenir un deux-points, suivi du nom d'une des sorties du paquet, comme dans ‘gcc:doc' ou ‘binutils@2.22:lib' (*note 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 (*note Modules de paquets::). Parfois les paquets ont des “entrées propagées” : ce sont des dépendances qui sont installées automatiquement avec le paquet demandé (*note ‘propagated-inputs' in ‘package' objects: package-propagated-inputs. 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. D'autre part, les paquets dépendent parfois de la définition de variables d'environnement pour leur chemin de recherche (voir les explications sur ‘--search-paths' plus bas). Toute définition de variable d'environnement manquante ou possiblement incorrecte est rapporté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 (*note 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+)) Les développeurs peuvent trouver utile d'inclure un tel fichier ‘guix.scm' à la racine de l'arborescence des sources de leur projet qui pourrait être utilisé pour tester des versions de développement et créer des environnements de développement reproductibles (*note Invoquer guix environment::). ‘--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 une REGEXP ou plus est spécifiée, la mise à jour n'installera que les paquets dont le nom correspond à REGEXP. Voyez aussi l'option ‘--do-not-upgrade' en 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' (*note Invoquer guix pull::). ‘--do-not-upgrade[=REGEXP ...]' Lorsqu'elle est utilisée 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. 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 retourner un objet “manifest” qui est en gros une liste de paquets : (use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Utiliser une sortie spécifique d'un paquet. (list guile-2.0 "debug"))) Dans cet exemple on doit savoir quels modules définissent les variables ‘emacs' et ‘guile-2.0' pour fournir la bonne ligne ‘use-package-modules' ce qui peut être embêtant. On peut à la place fournir des spécifications de paquets normales et laisser ‘specifications->manifest' rechercher les objets de paquets correspondants, comme ceci : (specifications->manifest '("emacs" "guile@2.2" "guile@2.2:debug")) ‘--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', cette option revient en arrière 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 zéroième génération, 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 (*note (gcc)Environment Variables::). Si GCC et, disons, la bibliothèque C sont installés dans le profil, alors ‘--search-paths' suggérera d'initialiser ces variables à ‘PROFIL/include' et ‘PROFIL/lib', respectivement. Le cas d'utilisation typique est de définir ces variables d'environnement dans le shell : $ eval `guix package --search-paths` GENRE peut être l'une des valeurs ‘exact', ‘prefix' ou ‘suffix', ce qui signifie que les définitions des variables d'environnement retournées seront soit les paramètres exactes, ou placés avant ou après la valeur actuelle de ces paramètres. Lorsqu'il est omis, GENRE a pour valeur par défaut ‘exact'. Cette option peut aussi être utilisé pour calculer les chemins de recherche _combinés_ de plusieurs profils. Regardez cet exemple : $ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths La dernière commande ci-dessus montre la variable ‘GUILE_LOAD_PATH' bien que, pris individuellement, ni ‘foo' ni ‘bar' n'auraient donné cette recommandation. ‘--profile=PROFIL' ‘-p PROFIL' Utiliser le PROFIL à la place du profil par défaut de l'utilisateur. ‘--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 que pour les développeurs de 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' (*note GNU recutils databases: (recutils)Top.). 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 : key_board_). 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 *Note (recutils)Selection Expressions:: 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' (*note GNU recutils databases: (recutils)Top.). $ guix package --show=python | recsel -p name,version name: python version: 2.7.6 name: python version: 3.3.5 Vous pouvez aussi spécifier le nom complet d'un paquet pour n'avoir que les détails concernant une version spécifique : $ guix package --show=python@3.4 | recsel -p name,version name: python version: 3.4.3 ‘--list-installed[=REGEXP]' ‘-I [REGEXP]' Liste les paquets actuellement installés dans le profil spécifié, avec les paquets les plus récemment installés en dernier. Lorsque REGEXP est spécifié, liste uniquement les paquets installés dont le nom correspond à REGEXP. Pour chaque paquet installé, affiche les éléments suivants, séparés par des tabulations : le nom du paquet, sa version, la partie du paquet qui est installé (par exemple, ‘out' pour la sortie par défaut, ‘include' pour ses en-têtes, etc) et le chemin du paquet dans le dépôt. ‘--list-available[=REGEXP]' ‘-A [REGEXP]' Lister les paquets actuellement disponibles dans la distribution pour ce système (*note Distribution GNU::). Lorsque REGEXP est spécifié, liste 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 (*note 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 (*note 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 à des numéros de version. 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é. Aucune espace ni virgule surnuméraire n'est permise. • _Des intervalles_. ‘--list-generations=2..9' affiche les générations demandées et tout ce qui se trouvent 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 moins 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é, supprimer les générations correspondante. Lorsque MOTIF spécifie une durée, les générations _plus vieilles_ 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. Enfin, comme ‘guix package' peut démarrer des processus de construction, elle supporte les options de construction communes (*note Options de construction communes::). Elle supporte aussi les options de transformation de paquets comme ‘--with-source' (*note Options de transformation de paquets::). Cependant, remarquez que les transformations de paquets sont perdues à la mise à jour ; pour les préserver à travers les mises à jours, vous devriez définir vos propres variantes des paquets dans une module Guile et l'ajouter à ‘GUIX_PACKAGE_PATH' (*note Définition des paquets::). 4.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 (*note 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. 4.3.1 Serveur de substituts officiel ------------------------------------ Le serveur ‘ci.guix.gnu.org' est une interface à la ferme de construction officielle qui construit des paquets pour Guix continuellement pour certaines architectures et les rend disponibles en tant que substituts. C'est la source par défaut des substituts ; elle peut être modifiée en passant l'option ‘--substitute-urls' soit à ‘guix-daemon' (*note ‘guix-daemon --substitute-urls': daemon-substitute-urls.) soit aux outils clients comme ‘guix package' (*note client ‘--substitute-urls' option: client-substitute-urls.). Les URL des substituts peuvent être soit en HTTP soit en HTTPS. Le HTTPS est recommandé parce que les communications sont chiffrées ; à l'inverse HTTP rend les communications visibles pour un espion qui peut utiliser les informations accumulées sur vous pour déterminer par exemple si votre système a des vulnérabilités de sécurités non corrigées. Les substituts de la ferme de construction officielle sont activés par défaut dans la distribution système Guix (*note Distribution GNU::). Cependant, ils sont désactivés par défaut lorsque vous utilisez Guix sur une distribution externe, à moins que vous ne les ayez explicitement activés via l'une des étapes d'installation recommandées (*note Installation::). Les paragraphes suivants décrivent comment activer ou désactiver les substituts pour la ferme de construction officielle ; la même procédure peut être utilisée pour activer les substituts de n'importe quel autre serveur de substituts. 4.3.2 Autoriser un serveur de substituts ---------------------------------------- Pour permettre à Guix de télécharger les substituts depuis ‘ci.guix.gnu.org' ou un miroir, vous devez ajouter sa clef publique à la liste de contrôle d'accès (ACL) des imports d'archives, avec la commande ‘guix archive' (*note Invoquer guix archive::). Cela implique que vous faîtes confiance à ‘ci.guix.gnu.org' pour ne pas être compromis et vous servir des substituts authentiques. La clef publique pour ‘ci.guix.gnu.org' est installée avec Guix, dans ‘PRÉFIXE/share/guix/ci.guix.gnu.org.pub', où PRÉFIXE est le préfixe d'installation de Guix. Si vous avez installé Guix depuis les sources, assurez-vous d'avoir vérifié la signature GPG de ‘guix-1.0.0.tar.gz' qui contient ce fichier de clef publique. Ensuite vous pouvez lancer quelque chose comme ceci : # guix archive --authorize < PREFIX/share/guix/ci.guix.gnu.org.pub Remarque : De même, le fichier ‘hydra.gnu.org.pub' contient la clef publique d'une ferme de construction indépendante qui appartient aussi au projet, disponible sur ‘https://mirror.hydra.gnu.org'. Une fois que cela est en place, la sortie d'une commande comme ‘guix build' devrait changer de quelque chose comme : $ guix build emacs --dry-run Les dérivations suivantes seraient construites : /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv ... à quelque chose comme : $ guix build emacs --dry-run 112.3 Mo seraient téléchargés : /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3 /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16 /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7 ... Cela indique que les substituts de ‘ci.guix.gnu.org' sont utilisables et seront téléchargés, si possible, pour les futures constructions. Le mécanisme de substitution peut être désactivé globalement en lançant ‘guix-daemon' avec ‘--no-substitutes' (*note Invoquer guix-daemon::). Il peut aussi être désactivé temporairement en passant l'option ‘--no-substitutes' à ‘guix package', ‘guix build' et aux autres outils en ligne de commande. 4.3.3 Authentification des substituts ------------------------------------- Guix détecte et lève une erreur lorsqu'il essaye d'utiliser un substituts qui a été modifié. De même, il ignore les substituts qui ne sont pas signés ou qui ne sont pas signés par l'une des clefs listés dans l'ACL. Il y a une exception cependant : si un serveur non autorisé fournit des substituts qui sont _identiques bit-à-bit_ à ceux fournis par un serveur autorisé, alors le serveur non autorisé devient disponible pour les téléchargements. Par exemple en supposant qu'on a choisi deux serveurs de substituts avec cette option : --substitute-urls="https://a.example.org https://b.example.org" Si l'ACL contient uniquement la clef de ‘b.example.org', et si ‘a.example.org' sert _exactement les mêmes_ substituts, alors Guix téléchargera les substituts de ‘a.example.org' parce qu'il vient en premier dans la liste et peut être considéré comme un miroir de ‘b.example.org'. En pratique, des machines de constructions produisent souvent les mêmes binaires grâce à des construction reproductibles au bit près (voir plus bas). Lorsque vous utilisez HTTPS, le certificat X.509 du serveur n'est _pas_ validé (en d'autre termes, le serveur n'est pas authentifié), contrairement à ce que des clients HTTPS comme des navigateurs web font habituellement. Cela est dû au fait que Guix authentifie les informations sur les substituts eux-mêmes, comme expliqué plus haut, ce dont on se soucie réellement (alors que les certificats X.509 authentifie la relation entre nom de domaine et clef publique). 4.3.4 Paramètres de serveur mandataire -------------------------------------- Les substituts sont téléchargés par HTTP ou HTTPS. La variable d'environnement ‘http_proxy' peut être initialisée dans l'environnement de ‘guix-daemon' et est respectée pour le téléchargement des substituts. Remarquez que la valeur de ‘http_proxy' dans l'environnement où tournent ‘guix build', ‘guix package' et les autres clients n'a _absolument aucun effet_. 4.3.5 Échec de substitution --------------------------- Même lorsqu'un substitut pour une dérivation est disponible, la substitution échoue parfois. Cela peut arriver pour plusieurs raisons : le serveur de substitut peut être hors ligne, le substitut a récemment été supprimé du serveur, la connexion peut avoir été interrompue, etc. Lorsque les substituts sont activés et qu'un substitut pour une dérivation est disponible, mais que la tentative de substitution échoue, Guix essaiera de construire la dérivation localement si ‘--fallback' a été passé en argument (*note common build option ‘--fallback': option de repli.). Plus spécifiquement, si cet option n'a pas été passée en argument, alors aucune construction locale n'est effectuée et la dérivation est considérée comme étant en échec. Cependant, si ‘--fallback' est passé en argument, alors Guix essaiera de construire la dérivation localement et l'échec ou le succès de la dérivation dépend de l'échec ou du succès de la construction locale. Remarquez que lorsque les substituts sont désactivés ou qu'aucun substitut n'est disponible pour la dérivation en question, une construction locale sera _toujours_ effectuée, indépendamment du fait que l'argument ‘--fallback' ait été ou non passé. Pour se donner une idée du nombre de substituts disponibles maintenant, vous pouvez essayer de lancer la commande ‘guix weather' (*note Invoquer guix weather::). Cette command fournit des statistiques sur les substituts fournis par un serveur. 4.3.6 De la confiance en des binaires ------------------------------------- De nos jours, le contrôle individuel sur son utilisation propre de l'informatique est à la merci d'institutions, de sociétés et de groupes avec assez de pouvoir et de détermination pour contourner les infrastructures informatiques et exploiter leurs faiblesses. Bien qu'utiliser les substituts de ‘ci.guix.gnu.org' soit pratique, nous encourageons les utilisateurs à construire aussi par eux-mêmes, voir à faire tourner leur propre ferme de construction, pour que ‘ci.guix.gnu.org' devienne une cible moins intéressante. Une façon d'aider est de publier les logiciels que vous construisez avec ‘guix publish' pour que les autres aient plus de choix de serveurs où télécharger les substituts (*note Invoquer guix publish::). Guix possède les fondations pour maximiser la reproductibilité logicielle (*note Fonctionnalités::). Dans la plupart des cas, des constructions indépendantes d'un paquet donnée ou d'une dérivation devrait donner des résultats identiques au bit près. Ainsi, à travers un ensemble de constructions de paquets indépendantes il est possible de renforcer l'intégrité du système. La commande ‘guix challenge' a pour but d'aider les utilisateurs à tester les serveurs de substituts et à aider les développeurs à trouver les constructions de paquets non-déterministes (*note Invoquer guix challenge::). De même, l'option ‘--check' de ‘guix build' permet aux utilisateurs de vérifier si les substituts précédemment installés sont authentiques en les reconstruisant localement (*note ‘guix build --check': vérification de la construction.). Dans le futur, nous aimerions que Guix puisse publier et recevoir des binaires d'autres utilisateurs, d'une manière pair-à-pair. Si vous voulez discuter de ce projet, rejoignez-nous sur <guix-devel@gnu.org>. 4.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 (*note Invoquer guix size::). ‘guix graph' peut aussi être utile (*note Invoquer guix graph::). Il y a plusieurs paquets à sorties multiples dans la distribution GNU. D'autres noms de sorties conventionnels sont ‘lib' pour les bibliothèques et éventuellement les fichiers d'en-tête, ‘bin' pour les programmes indépendants et ‘debug' pour les informations de débogage (*note 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' (*note Invoquer guix package::). 4.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 (*note 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' (*note 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 (*note 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 command ‘guix gc' a trois modes d'opération : il peut être utilisé 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 pour être un nombre d'octets ou inclure un suffixe d'unité, comme ‘MiB' pour mébioctet et ‘GB' pour gigaoctet (*note size specifications: (coreutils)Block size.). Lorsque MIN est omis, tout glaner. ‘--free-space=LIBRE' ‘-F LIBRE' Glaner jusqu'à ce que LIBRE espace soit disponible dans ‘/gnu/store' si possible ; LIBRE est une quantité de stockage comme ‘500MiB' comme décrit ci-dessus. Lorsque LIBRE ou plus est disponible dans ‘/gnu/store' ne rien faire et s'arrêter immédiatement. ‘--delete-generations[=DURÉE]' ‘-d [DURÉE]' Avant de commencer le glanage, supprimer toutes les générations plus vielles que DURÉE, pour tous les profils utilisateurs ; lorsque cela est lancé en root, cela s'applique à tous les profils _de tous les utilisateurs_. Par exemple, cette commande supprime toutes les générations de tous vos profils plus vieilles que 2 mois (sauf s'il s'agit de la génération actuelle) puis libère de l'espace jusqu'à atteindre au moins 10 Go d'espace libre : guix gc -d 2m -F 10G ‘--delete' ‘-D' Essayer de supprimer tous les fichiers et les répertoires du dépôt spécifiés en argument. Cela échoue si certains des fichiers ne sont pas dans le dépôt ou s'ils sont toujours utilisés. ‘--list-failures' Lister les éléments du dépôt qui correspondent à des échecs de construction. Cela n'affiche rien à moins que le démon n'ait été démarré avec ‘--cache-failures' (*note ‘--cache-failures': Invoquer guix-daemon.). ‘--list-roots' Lister les racines du GC appartenant à l'utilisateur ; lorsque la commande est lancée en root, lister _toutes_ les racines du GC. ‘--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. *Note Invoquer guix size:: pour un outil pour surveiller la taille de la closure d'un élément. *Note Invoquer guix graph:: pour un outil pour visualiser le graphe des références. ‘--derivers' Renvoie les dérivations menant aux éléments du dépôt donnés (*note Dérivations::). Par exemple cette commande : guix gc --derivers `guix 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
...
-
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/fr/guix.fr.txt
- [detail]
- [similar]
PREV
NEXT