Results of 0 - 1 of about 0 (0.002 sec.)
- Manuel de référence de GNU Guix
- @digest: dfe91559d4b02c97bf70cf1c0dfb97f8
- @id: 74062
- @mdate: 2019-05-19T21:18:24Z
- @size: 1994423
- @type: text/html
- content-type: text/html; charset=utf-8
- description: Manuel de référence de GNU Guix
- distribution: global
- generator: makeinfo
- keywords: Manuel de référence de GNU Guix
- resource-type: document
- #keywords: substituts (150961), invoquer (131965), paquets (102672), construction (52391), demon (51506), systeme (50490), matieres (47391), paquet (44117), profil (43272), monter (42894), guix (40912), commande (40191), environnement (39131), lancer (36107), installe (35765), voir (34977), processus (31844), fichier (30190), construire (29524), depot (29517), precedent (28237), fichiers (26746), serveur (25531), repertoire (24482), generations (24396), defaut (24119), utiliser (22876), constructions (22750), lorsque (22458), installation (21358), reseau (20878), installer (19828)
- Manuel de référence de GNU Guix Table des matières 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 Suivant: Introduction , Monter: (dir) [ Table des matières ][ Index ] GNU Guix Cette documentation décrit GNU Guix version 1.0.1, un outil de gestion de paquets fonctionnel écrit pour le système GNU. This manual is also available in Simplified Chinese (voir GNU Guix参考手册 ), French (voir Manuel de référence de GNU Guix ), German (voir Referenzhandbuch zu GNU Guix ), Spanish (voir Manual de referencia de GNU Guix ), and Russian (voir Руководство GNU Guix ). If you would like to translate it in your native language, consider joining the Translation Project . • Introduction : Qu'est-ce que Guix ? • Installation : Installer Guix. • Installation du système : Installer le système d'exploitation complet. • Gestion de paquets : Installation des paquets, mises à jour, etc. • Développement : Développement logiciel simplifié par Guix. • Interface de programmation : Utiliser Guix en Scheme. • Utilitaires : Commandes de gestion de paquets. • Configuration système : Configurer le système d'exploitation. • Documentation : Visualiser les manuels d'utilisateur des logiciels. • Installer les fichiers de débogage : Nourrir le débogueur. • Mises à jour de sécurité : Déployer des correctifs de sécurité rapidement. • Bootstrapping : GNU/Linux depuis zéro. • Porter : Cibler une autre plateforme ou un autre noyau. • Contribuer : Nous avons besoin de votre aide ! • Remerciements : Merci ! • La licence GNU Free Documentation : La licence de ce manuel. • Index des concepts : Les concepts. • Index de programmation : Types de données, fonctions et variables. — Liste détaillée des nœuds — Introduction • Gérer ses logiciels avec Guix : Ce qui est spécial. • Distribution GNU : Les paquets et les outils. Installation • Installation binaire : Commencer à utiliser Guix en un rien de temps ! • Prérequis : Logiciels requis pour construire et lancer Guix. • Lancer la suite de tests : Tester Guix. • Paramétrer le démon : Préparer l'environnement du démon de construction. • Invoquer guix-daemon : Lancer le démon de construction. • Réglages applicatifs : Réglages spécifiques pour les application. Paramétrer le démon • Réglages de l'environnement de construction : Préparer l'environnement de construction isolé. • Réglages du délestage du démon : Envoyer des constructions à des machines distantes. • Support de SELinux : Utiliser une politique SELinux pour le démon. Installation du système • Limitations : Ce à quoi vous attendre. • Considérations matérielles : Matériel supporté. • Installation depuis une clef USB ou un DVD : Préparer le média d'installation. • Préparer l'installation : Réseau, partitionnement, etc. • Installation graphique guidée : Installation graphique facile. • Installation manuelle : Installation manuelle pour les sorciers. • Après l'installation du système : Une fois que l'installation a réussi. • Installer Guix dans une VM : Jouer avec le système Guix. • Construire l'image d'installation : D'où vient tout cela. Installation manuelle • Disposition du clavier réseau et partitionnement : Paramètres initiaux. • Effectuer l'installation : Installer. Gestion de paquets • Fonctionnalités : Comment Guix va rendre votre vie plus heureuse. • Invoquer guix package : Installation, suppression, etc. de paquets. • Substituts : Télécharger des binaire déjà construits. • Des paquets avec plusieurs résultats : Un seul paquet source, plusieurs résultats. • Invoquer guix gc : Lancer le ramasse-miettes. • Invoquer guix pull : Récupérer la dernière version de Guix et de la distribution. • Canaux : Personnaliser la collection des paquets. • Inférieurs : Interagir avec une autre révision de Guix. • Invoquer guix describe : Affiche des informations sur la révision Guix actuelle. • Invoquer guix archive : Exporter et importer des fichiers du dépôt. Substituts • Serveur de substituts officiel : Une source particulière de substituts. • Autoriser un serveur de substituts : Comment activer ou désactiver les substituts. • Authentification des substituts : Comment Guix vérifie les substituts. • Paramètres de serveur mandataire : Comment récupérer des substituts à travers un serveur mandataire. • Échec de substitution : Qu'arrive-t-il quand la substitution échoue. • De la confiance en des binaires : Comment pouvez-vous avoir confiance en un paquet binaire ? Développement • Invoquer guix environment : Mettre en place des environnements de développement. • Invoquer guix pack : Créer des lots de logiciels. Interface de programmation • Modules de paquets : Les paquets du point de vu du programmeur. • Définition des paquets : Définir de nouveaux paquets. • Systèmes de construction : Spécifier comment construire les paquets. • Le dépôt : Manipuler le dépôt de paquets. • Dérivations : Interface de bas-niveau avec les dérivations de paquets. • La monade du dépôt : Interface purement fonctionnelle avec le dépôt. • G-Expressions : Manipuler les expressions de construction. • Invoquer guix repl : S'amuser avec Guix de manière interactive. Définition des paquets • Référence des paquets : Le type de donnée des paquets. • Référence des origines : Le type de données d'origine. Utilitaires • Invoquer guix build : Construire des paquets depuis la ligne de commande. • Invoquer guix edit : Modifier les définitions de paquets. • Invoquer guix download : Télécharger un fichier et afficher son hash. • Invoquer guix hash : Calculer le hash cryptographique d'un fichier. • Invoquer guix import : Importer des définitions de paquets. • Invoquer guix refresh : Mettre à jour les définitions de paquets. • Invoquer guix lint : Trouver des erreurs dans les définitions de paquets. • Invoquer guix size : Profiler l'utilisation du disque. • Invoquer guix graph : Visualiser le graphe des paquets. • Invoquer guix publish : Partager des substituts. • Invoquer guix challenge : Défier les serveurs de substituts. • Invoquer guix copy : Copier vers et depuis un dépôt distant. • Invoquer guix container : Isolation de processus. • Invoquer guix weather : Mesurer la disponibilité des substituts. • Invoquer guix processes : Lister les processus clients. Invoquer guix build • Options de construction communes : Options de construction pour la plupart des commandes. • Options de transformation de paquets : Créer des variantes de paquets. • Options de construction supplémentaires : Options spécifiques à « guix build ». • Débogage des échecs de construction : La vie d'un empaqueteur. Configuration système • Utiliser le système de configuration : Personnaliser votre système GNU. • Référence de système d'exploitation : Détail sur la déclaration de système d'exploitation. • Systèmes de fichiers : Configurer les montages de systèmes de fichiers. • Périphériques mappés : Gestion des périphériques de bloc. • Comptes utilisateurs : Spécifier des comptes utilisateurs. • Disposition du clavier : La manière dont le système interprète les touches du clavier. • Régionalisation : Paramétrer la langue et les conventions culturelles. • Services : Spécifier les services du système. • Programmes setuid : Programmes tournant avec les privilèges root. • Certificats X.509 : Authentifier les serveurs HTTPS. • Name Service Switch : Configurer le « name service switch » de la libc. • Disque de RAM initial : Démarrage de Linux-Libre. • Configuration du chargeur d'amorçage : Configurer le chargeur d'amorçage. • Invoquer guix system : Instantier une configuration du système. • Lancer Guix dans une VM : Comment lancer Guix dans une machine virtuelle. • Définir des services : Ajouter de nouvelles définitions de services. Services • Services de base : Services systèmes essentiels. • Exécution de tâches planifiées : Le service mcron. • Rotation des journaux : Le service rottlog. • Services réseau : Paramètres réseau, démon SSH, etc. • Système de fenêtrage X : Affichage graphique. • Services d'impression : Support pour les imprimantes locales et distantes. • Services de bureaux : D-Bus et les services de bureaux. • Services de son : Services ALSA et Pulseaudio. • Services de bases de données : Bases SQL, clefs-valeurs, etc. • Services de courriels : IMAP, POP3, SMTP, et tout ça. • Services de messagerie : Services de messagerie. • Services de téléphonie : Services de téléphonie. • Services de surveillance : Services de surveillance. • Services Kerberos : Services Kerberos. • Services web : Services web. • Services de certificats : Certificats TLS via Let's Encrypt. • Services DNS : Démons DNS. • Services VPN : Démons VPN. • Système de fichiers en réseau : Services liés à NFS. • Intégration continue : Le service Cuirass. • Services de gestion de l'énergie : Augmenter la durée de vie de la batterie. • Services audio : MPD. • Services de virtualisation : Services de virtualisation. • Services de contrôle de version : Fournit des accès distants à des dépôts Git. • Services de jeu : Serveurs de jeu. • Services divers : D'autres services. Définir des services • Composition de services : Le modèle de composition des services. • Types service et services : Types et services. • Référence de service : Référence de l'API. • Services Shepherd : Un type de service particulier. Suivant: Installation , Précédent: Top , Monter: Top [ Table des matières ][ Index ] 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 (voir Installation ) ou vous pouvez l'utiliser comme distribution système indépendante, Guix System 2 . Voir Distribution GNU . • Gérer ses logiciels avec Guix : Ce qui est spécial. • Distribution GNU : Les paquets et les outils. Suivant: Distribution GNU , Monter: Introduction [ Table des matières ][ Index ] 1.1 Gérer ses logiciels avec Guix Guix fournit une interface de gestion des paquets par la ligne de commande (voir Gestion de paquets ), des outils pour aider au développement logiciel (voir Développement ), des utilitaires en ligne de commande pour des utilisations plus avancées (voir Utilitaires ) ainsi que des interfaces de programmation Scheme (voir Interface de programmation ). Son démon de construction est responsable de la construction des paquets pour les utilisateurs (voir Paramétrer le démon ) et du téléchargement des binaires pré-construits depuis les sources autorisées (voir Substituts ). Guix contient de nombreuses définitions de paquet GNU et non-GNU qui respectent tous les libertés de l'utilisateur . Il est extensible : les utilisateurs peuvent écrire leurs propres définitions de paquets (voir Définition des paquets ) et les rendre disponibles dans des modules de paquets indépendants (voir Modules de paquets ). Il est aussi personnalisable : 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 (voir Options de transformation de paquets ). Sous le capot, Guix implémente la discipline de gestion de paquet fonctionnel inventé par Nix (voir Remerciements ). Dans Guix le processus de construction et d'installation des paquets est vu comme une fonction dans le sens mathématique du terme. Cette fonction a des entrées (comme des scripts de construction, un compilateur et des bibliothèques) et renvoie un paquet installé. En tant que fonction pure, son résultat ne dépend que de ses entrées. Par exemple, il ne peut pas faire référence à des logiciels ou des scripts qui n'ont pas été explicitement passés en entrée. Une fonction de construction produit toujours le même résultat quand on lui donne le même ensemble d'entrée. Elle ne peut pas modifier l'environnement du système en cours d'exécution d'aucune manière ; par exemple elle ne peut pas créer, modifier ou supprimer des fichiers en dehors de ses répertoires de construction et d'installation. Ce résultat s'obtient en lançant les processus de construction dans des environnements isolés (ou des conteneurs ) où seules les entrées explicites sont visibles. Le résultat des fonctions de construction de paquets est mis en cache dans le système de fichier, dans répertoire spécial appelé le dépôt (voir Le dépôt ). Chaque paquet est installé dans son répertoire propre dans le dépôt — par défaut dans /gnu/store . Le nom du répertoire contient un hash de toutes les entrées utilisées pour construire le paquet ; ainsi, changer une entrée donnera un nom de répertoire différent. Cette approche est le fondement des fonctionnalités les plus importante de Guix : le support des mises à jour des paquets et des retours en arrière transactionnels, l'installation différenciée par utilisateur et le ramassage de miettes pour les paquets (voir Fonctionnalités ). Précédent: Gérer ses logiciels avec Guix , Monter: Introduction [ Table des matières ][ Index ] 1.2 Distribution GNU Guix fournit aussi une distribution du système GNU contenant uniquement des logiciels libres 3 . On peut installer la distribution elle-même (voir Installation du système ), mais on peut aussi installer Guix comme gestionnaire de paquets par dessus un système GNU/Linux déjà installé (voir Installation ). Pour distinguer ces deux cas, on appelle la distribution autonome le « système Guix » ou Guix System. La distribution fournit les paquets cœur de GNU comme la GNU libc, GCC et Binutils, ainsi que de nombreuses applications GNU et non-GNU. La liste complète des paquets disponibles se trouve en ligne ou en lançant guix package (voir Invoquer guix package ) : guix package --list-available Notre but est de fournir une distribution logicielle entièrement libre de GNU/Linux et d'autres variantes de GNU, en se concentrant sur la promotion et l'intégration étroite des composants GNU en insistant sur les programmes et les outils qui aident l'utilisateur à 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 little-endian 64-bit ARMv8-A processors, Linux-Libre kernel. mips64el-linux little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, the project's build farms no longer provide substitutes for this architecture. Avec Guix System, vous déclarez tous les aspects de la configuration du système d'exploitation et guix s'occupe d'instancier la configuration de manière transactionnelle, reproductible et sans état (voir Configuration système ). Guix System utilise le noyau Linux-libre, le système d'initialisation Shepherd (voir Introduction dans The GNU Shepherd Manual ), les outils GNU et la chaîne d'outils familière ainsi que l'environnement graphique et les services systèmes de votre choix. Guix System est disponible sur toutes les plateformes ci-dessus à part mips64el-linux . Pour des informations sur comment porter vers d'autres architectures et d'autres noyau, voir Porter . La construction de cette distribution est un effort collaboratif et nous vous invitons à nous rejoindre ! Voir Contribuer , pour des informations sur la manière de nous aider. Suivant: Installation du système , Précédent: Introduction , Monter: Top [ Table des matières ][ Index ] 2 Installation Remarque : Nous vous recommandons d'utiliser ce script shell d'installation pour installer Guix sur un système GNU/Linux fonctionnel, que nous appelons une distro externe 4 . 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 (voir Invoquer guix pull ). Si vous préférez effectuer les étapes d'installation manuellement ou si vous voulez les personnaliser, vous trouverez les sections suivantes utile. Elles décrivent les prérequis logiciels pour Guix, ainsi que la manière de l'installer manuellement et de se préparer à l'utiliser. • Installation binaire : Commencer à utiliser Guix en un rien de temps ! • Prérequis : Logiciels requis pour construire et lancer Guix. • Lancer la suite de tests : Tester Guix. • Paramétrer le démon : Préparer l'environnement du démon de construction. • Invoquer guix-daemon : Lancer le démon de construction. • Réglages applicatifs : Réglages spécifiques pour les application. Suivant: Prérequis , Monter: Installation [ Table des matières ][ Index ] 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 . 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 : Téléchargez l'archive binaire depuis ‘ https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1. 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.1. système .tar.xz.sig $ gpg --verify guix-binary-1.0.1. 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 . 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.1. système .tar.xz # mv var/guix /var/ && mv gnu / Cela crée /gnu/store (voir 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. Rendez le profil disponible sous ~root/.config/guix/current , qui est l'emplacement où guix pull installera les mises à jour (voir Invoquer guix pull ) : # mkdir -p ~root/.config/guix # ln -sf /var/guix/profiles/per-user/root/current-guix \ ~root/.config/guix/current 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 Créez le groupe et les comptes utilisateurs pour les utilisateurs de construction comme expliqué plus loin (voir Réglages de l'environnement de construction ). 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 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 (voir Other Info Directories dans GNU Texinfo , pour plus de détails sur comment changer le chemin de recherche de Info). Pour utiliser les substituts de ci.guix.gnu.org ou l'un de ses miroirs (voir Substituts ), autorisez-les : # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub Chaque utilisateur peut avoir besoin d'effectuer des étapes supplémentaires pour que leur environnement Guix soit prêt à être utilisé, voir Réglages applicatifs . Voilà, l'installation est terminée ! Vous pouvez confirmer que Guix fonctionne en installant un paquet d'exemple dans le profil de root : # guix install hello L'archive d'installation binaire peut être (re)produite et vérifiée simplement en lançant la commande suivante dans l'arborescence des sources de Guix : make guix-binary. system .tar.xz … ce qui à son tour lance : guix pack -s system --localstatedir \ --profile-name=current-guix guix Voir Invoquer guix pack , pour plus d'info sur cet outil pratique. Suivant: Lancer la suite de tests , Précédent: Installation binaire , Monter: Installation [ Table des matières ][ Index ] 2.2 Prérequis Cette section dresse la liste des prérequis pour la construction de Guix depuis les sources. La procédure de construction pour Guix est la même que pour les autres logiciels GNU, et n'est pas expliquée ici. Regardez les fichiers README et INSTALL dans l'arborescence des sources de Guix pour plus de détails. GNU Guix est disponible au téléchargement depuis son site web sur http://www.gnu.org/software/guix/ . GNU Guix dépend des paquets suivants : GNU Guile , version 2.2.x, Guile-Gcrypt , version 0.1.0 ou supérieure, GnuTLS , en particulier ses liaisons Guile (voir how to install the GnuTLS bindings for Guile dans GnuTLS-Guile ), Guile-SQLite3 , version 0.1.0 ou supérieure, Guile-Git , d'août 2017 ou ultérieur, Guile-JSON , zlib , GNU Make . Les dépendances suivantes sont facultatives : Le support pour la décharge de construction (voir Réglages du délestage du démon ) et guix copy (voir Invoquer guix copy ) dépend de Guile-SSH , version 0.10.2 ou ultérieure. Lorsque libbz2 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 , SQLite 3 , GCC's g++ , avec le support pour le standard C++11. Lorsque vous configurez Guix sur un système qui a déjà une installation de Guix, assurez-vous de spécifier le même répertoire d'état que l'installation existante avec l'option --localstatedir du script configure (voir localstatedir dans GNU Coding Standards ). Le script configure vous protège des mauvaises configurations involontaires de localstatedir pour éviter que vous ne corrompiez votre dépôt (voir Le dépôt ). Lorsque vous avez une installation fonctionnelle du gestionnaire de paquets 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. Suivant: Paramétrer le démon , Précédent: Prérequis , Monter: Installation [ Table des matières ][ Index ] 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 (voir Prérequis ) dans votre message. Guix possède aussi une suite de tests de systèmes complets qui test des instances complètes du système Guix. Elle ne peut être lancée qui sur un système où Guix est déjà installé, avec : make check-system ou, de nouveau, en définissant TESTS pour choisir un sous-ensemble des tests à lancer : make check-system TESTS="basic mcron" Ces tests systèmes sont définis dans les modules (gnu tests …) . Ils fonctionnent en lançant les systèmes d'exploitation sous test avec une instrumentation légère dans une machine virtuelle (VM). Ils peuvent être intenses en terme de calculs ou plutôt rapides en fonction de la disponibilité des substituts de leurs dépendances (voir Substituts ). Certains requièrent beaucoup d'espace disque pour contenir les images des VM. De nouveau, en cas d'échec, envoyez tous les détails à bug-guix@gnu.org . Suivant: Invoquer guix-daemon , Précédent: Lancer la suite de tests , Monter: Installation [ Table des matières ][ Index ] 2.4 Paramétrer le démon Les opérations comme la construction d'un paquet ou le lancement du ramasse-miettes sont toutes effectuées par un processus spécialisé, le démon de construction , pour le compte des clients. Seul le démon peut accéder au dépôt et à sa base de données associée. Ainsi, toute opération manipulant le dépôt passe par le démon. Par exemple, les outils en ligne de commande comme guix package et guix build communiquent avec le démon ( via des appels de procédures distantes) pour lui dire quoi faire. Les sections suivantes expliquent comment préparer l'environnement du démon de construction. Voir aussi Substituts pour apprendre comment permettre le téléchargement de binaires pré-construits. • Réglages de l'environnement de construction : Préparer l'environnement de construction isolé. • Réglages du délestage du démon : Envoyer des constructions à des machines distantes. • Support de SELinux : Utiliser une politique SELinux pour le démon. Suivant: Réglages du délestage du démon , Monter: Paramétrer le démon [ Table des matières ][ Index ] 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 (voir 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 (voir --max-jobs ). 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 (voir Invoquer guix system ). Le programme guix-daemon peut ensuite être lancé en root avec la commande suivante 5 : # 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 6 ; 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 (voir Dérivations ) ou pour les substituts (voir 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 . Suivant: Support de SELinux , Précédent: Réglages de l'environnement de construction , Monter: Paramétrer le démon [ Table des matières ][ Index ] 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 7 . 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 (voir Guile-Avahi dans Using Avahi in Guile Scheme Programs ). Le type de données build-machine est détaillé plus bas. Type de données : build-machine Ce type de données représente les machines de construction sur lesquelles le démon peut décharger des constructions. Les champs importants sont : name Le nom d'hôte de la machine distante. 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 (voir Converting keys dans LSH Manual ) : $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV… Il y a un certain nombre de champs facultatifs que vous pouvez remplir : port (par défaut : 22 ) Numéro de port du serveur SSH sur la machine. private-key (par défaut : ~root/.ssh/id_rsa ) Le fichier de clef privée SSH à utiliser lors de la connexion à la machine, au format OpenSSH. Cette clef ne doit pas être protégée par phrase de passe. Remarquez que la valeur par défaut est la clef privée du compte root . Assurez-vous qu'elle existe si vous utilisez la valeur par défaut. compression (par défaut : "zlib@openssh.com,zlib" ) compression-level (par défaut : 3 ) Les méthodes de compression au niveau SSH et le niveau de compression demandé. Remarquez que le déchargement utilise la compression SSH pour réduire la bande passante utilisée lors du transfert vers et depuis les machines de construction. daemon-socket (par défaut : "/var/guix/daemon-socket/socket" ) Le nom de fichier du socket Unix-domain sur lequel guix-daemon écoute sur cette machine. parallel-builds (par défaut : 1 ) Le nombre de constructions qui peuvent tourner simultanément sur la machine. speed (par défaut : 1.0 ) Un « facteur de vitesse relatif ». L'ordonnanceur des constructions tendra à préférer les machines avec un plus grand facteur de vitesse. features (par défaut : '() ) Une liste de chaînes qui contient les fonctionnalités spécifiques supportées par la machine. Un exemple est "kvm" pour les machines qui ont le module Linux KVM et le support matériel correspondant. Les dérivations peuvent demander des fonctionnalités par leur nom et seront orchestrées sur les machines de construction correspondantes. La commande guix doit être dans le chemin de recherche des machines de construction. Vous pouvez vérifier si c'est le cas en lançant : ssh build-machine guix repl --version Il reste une dernière chose à faire maintenant que machines.scm est en place. Comme expliqué ci-dessus, lors du déchargement les fichiers sont transférés entre les dépôts des machines. Pour que cela fonctionne, vous devez d'abord générer une paire de clef sur chaque machine pour permettre au démon d'exporter des archives signées des fichiers de son dépôt (voir Invoquer guix archive ) : # guix archive --generate-key Chaque machine de construction doit autoriser la clef de la machine maîtresse pour qu'ils acceptent les éléments de dépôt de celle-ci : # guix archive --authorize < master-public-key.txt De même, la machine maîtresse doit autoriser les clefs de chaque machine de construction. Toute cette histoire de clefs permet d'exprimer la confiance mutuelle deux-à-deux entre le maître et les machines de construction. Concrètement, lorsque le maître reçoit des fichiers d'une machine de construction (et vice-versa), son démon de construction s'assure qu'ils sont authentiques, n'ont pas été modifiés par un tiers et qu'il sont signés par un clef autorisée. Pour tester que votre paramétrage fonctionne, lancez cette commande sur le nœud maître : # guix offload test Cela essaiera de se connecter à toutes les machines de construction spécifiées dans /etc/guix/machines.scm , s'assurera que 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 Précédent: Réglages du délestage du démon , Monter: Paramétrer le démon [ Table des matières ][ Index ] 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. 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. 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. 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. 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. Suivant: Réglages applicatifs , Précédent: Paramétrer le démon , Monter: Installation [ Table des matières ][ Index ] 2.5 Invoquer guix-daemon Le programme guix-daemon implémente toutes les fonctionnalités d'accès au dépôt. Cela inclus le lancement des processus de construction, le lancement du ramasse-miettes, la demande de disponibilité des résultats de construction, etc. Il tourne normalement en root comme ceci : # guix-daemon --build-users-group=guixbuild Pour des détails sur son paramétrage, voir Paramétrer le démon . Par défaut, guix-daemon lance les processus de construction sous différents 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 (voir dérivation ), plus un ensemble de répertoires systèmes spécifiques. Par défaut ce dernier contient /dev et /dev/pts . De plus, sous GNU/Linux, l'environnement de construction est un conteneur : en plus d'avoir sa propre arborescence du système de fichier, 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 (voir 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 (voir --keep-failed ). Le démon écoute les connexions et démarre un sous-processus pour chaque session démarrée par un client (l'une des sous-commandes de guix ). La commande guix processes vous permet d'obtenir un aperçu de l'activité sur votre système en affichant chaque session et client actif. Voir 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 (voir utilisateurs de construction ). --no-substitutes Ne pas utiliser de substitut pour les résultats de la construction. C'est-à-dire, toujours construire localement plutôt que de permettre le téléchargement de binaires pré-construits (voir Substituts ). Lorsque le démon tourne avec --no-substitutes , les clients peuvent toujours activer explicitement la substitution via l'appel de procédure distante set-build-options (voir Le dépôt ). --substitute-urls= urls Considérer urls comme la liste séparée par des espaces des URL des sources de substituts par défaut. Lorsque cette option est omise, ‘ https://ci.guix.gnu.org ' est utilisé. Cela signifie que les substituts sont téléchargés depuis les urls , tant qu'ils sont signés par une signature de confiance (voir Substituts ). --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 (voir 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é. Voir Invoquer guix gc . --cores= n -c n Utiliser n cœurs CPU pour construire chaque dérivation ; 0 signifie autant que possible. La valeur par défaut est 0 , mais elle peut être modifiée par les clients comme avec l'option --cores de guix build (voir Invoquer guix build ). L'effet est de définir la variable d'environnement NIX_BUILD_CORES dans le processus de construction, qui peut ensuite l'utiliser pour exploiter le parallélisme en interne — par exemple en lançant make -j$NIX_BUILD_CORES . --max-jobs= n -M n Permettre au plus n travaux de construction en parallèle. La valeur par défaut est 1 . La mettre à 0 signifie qu'aucune construction ne sera effectuée localement ; à la place, le démon déchargera les constructions (voir Réglages du délestage du démon ) ou échouera. --max-silent-time= secondes Lorsque le processus de construction ou de substitution restent silencieux pendant plus de secondes , le terminer et rapporter une erreur de construction. La valeur par défaut est 0 , ce qui désactive le délai. La valeur spécifiée ici peut être modifiée par les clients (voir --max-silent-time ). --timeout= secondes De même, lorsque le processus de construction ou de substitution dure plus de secondes , le terminer et rapporter une erreur de construction. La valeur par défaut est 0 , ce qui désactive le délai. La valeur spécifiée ici peut être modifiée par les clients (voir --timeout ). --rounds= N Construire chaque dérivations N fois à la suite, et lever une erreur si les résultats de construction consécutifs ne sont pas identiques bit-à-bit. Remarquez que ce paramètre peut être modifié par les clients comme guix build (voir Invoquer guix build ). Lorsqu'utilisé avec --keep-failed , la sortie différente est gardée dans le dépôt sous /gnu/store/…-check . Cela rend plus facile l'étude des différences entre les deux résultats. --debug Produire une sortie de débogage. Cela est utile pour déboguer des problèmes de démarrage du démon, mais ensuite elle peut être modifiée par les clients, par exemple par l'option --verbosity de guix build (voir Invoquer guix build ). --chroot-directory= rép Ajouter rép au chroot de construction. Cela peut changer le résultat d'un processus de construction — par exemple s'il utilise une dépendance facultative trouvée dans rép lorsqu'elle est disponible ou pas sinon. Pour cette raison, il n'est pas recommandé d'utiliser cette option. À la place, assurez-vous que chaque dérivation déclare toutes les entrées dont elle a besoin. --disable-chroot Désactive les constructions dans un chroot. Utiliser cette option n'est pas recommandé car, de nouveau, elle permet aux processus de construction d'accéder à des dépendances non déclarées. Elle est nécessaire cependant lorsque guix-daemon tourne 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. Voir 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 (voir GUIX_DAEMON_SOCKET ). Remarque : Le protocole du démon est non authentifié et non chiffré . Utiliser --listen= host est adapté sur des réseaux locaux, comme pour des grappes de serveurs, où seuls des nœuds de confiance peuvent se connecter au démon de construction. Dans les autres cas où l'accès à distance au démon est requis, nous conseillons d'utiliser un socket Unix-domain avec SSH. Lorsque --listen est omis, guix-daemon écoute les connexions sur le socket Unix-domain situé à localstatedir /guix/daemon-socket/socket . Précédent: Invoquer guix-daemon , Monter: Installation [ Table des matières ][ Index ] 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 (voir LOCPATH dans The GNU C Library Reference Manual ). Il y a deux différences importantes cependant : 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. 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 (voir Name Service Switch dans The GNU C Library Reference Manual ). Comme il est extensible, NSS supporte des greffons qui fournissent une nouvelle implémentation de résolution de nom : par exemple le greffon nss-mdns permet la résolution de noms d'hôtes en .local , le greffon nis permet la résolution de comptes 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 (voir NSS Configuration File dans The GNU C Reference Manual ) Lorsqu'ils essayent d'effectuer une résolution de nom — par exemple en appelant la fonction getaddrinfo en C — les applications essayent d'abord de se connecter au nscd ; en cas de réussite, nscd effectue la résolution de nom pour eux. Si le nscd ne tourne pas, alors ils effectuent la résolution eux-mêmes, en changeant les service de résolution dans leur propre espace d'adressage et en le lançant. Ce services de résolution de noms — les fichiers libnns_*.so — sont dlopen és mais ils peuvent provenir de la bibliothèque C du système, plutôt que de la bibliothèque C à laquelle l'application est liée (la bibliothèque C de Guix). Et c'est là que se trouve le problème : si votre application est liée à la bibliothèque C de Guix (disons, glibc-2.24) et essaye de charger les greffons NSS d'une autre bibliothèque C (disons, libnss_mdns.so pour glibc-2.22), il est très probable qu'elle plante ou que sa résolution de nom échoue de manière inattendue. Lancer nscd sur le système, entre autres avantages, élimine ce problème d'incompatibilité binaire car ces fichiers libnss_*.so sont chargés par le processus nscd , pas par l'application elle-même. 2.6.3 Polices X11 La majorité des applications graphiques utilisent fontconfig pour trouver et charger les 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 (voir Des paquets avec plusieurs résultats ). Par exemple, la commande suivante installe les polices pour le chinois : guix install font-adobe-source-han-sans:cn Les vieux programmes comme xterm n'utilisent pas fontconfig et s'appuient sur le rendu du côté du serveur. Ces programmes ont besoin de spécifier le nom complet de la police en utilisant XLFD (X Logical Font Description), comme ceci : -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1 Pour pouvoir utiliser ces noms complets avec les polices TrueType installées dans votre profil Guix, vous devez étendre le chemin des polices du serveur X : xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir)) Ensuite, vous pouvez lancer xlsfonts (du paquet xlsfonts ) pour vous assurer que vos polices TrueType y sont listées. 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. Voir 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 (voir Package Files dans The GNU Emacs Manual ). 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 (voir Init File dans The GNU Emacs Manual ). 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 . Suivant: Gestion de paquets , Précédent: Installation , Monter: Top [ Table des matières ][ Index ] 3 Installation du système Cette section explique comment installer Guix System sur une machine. Guix, en tant que gestionnaire de paquets, peut aussi être installé sur un système GNU/Linux déjà installé, voir Installation . • Limitations : Ce à quoi vous attendre. • Considérations matérielles : Matériel supporté. • Installation depuis une clef USB ou un DVD : Préparer le média d'installation. • Préparer l'installation : Réseau, partitionnement, etc. • Installation graphique guidée : Installation graphique facile. • Installation manuelle : Installation manuelle pour les sorciers. • Après l'installation du système : Une fois que l'installation a réussi. • Installer Guix dans une VM : Jouer avec le système Guix. • Construire l'image d'installation : D'où vient tout cela. Suivant: Considérations matérielles , Monter: Installation du système [ Table des matières ][ Index ] 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.1 : LVM (gestionnaire de volumes logiques) n'est pas supporté. De plus en plus de services systèmes sont fournis (voir Services ) mais certains manquent toujours cruellement. GNOME, Xfce, LXDE et Enlightenment sont disponibles (voir Services de bureaux ), ainsi qu'un certain nombre de gestionnaires de fenêtres X11. Cependant, il manque actuellement KDE. Plus qu'un avertissement, c'est une invitation à rapporter les problèmes (et vos succès !) et à nous rejoindre pour améliorer la distribution. Voir Contribuer , pour plus d'info. Suivant: Installation depuis une clef USB ou un DVD , Précédent: Limitations , Monter: Installation du système [ Table des matières ][ Index ] 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 (voir firmware ). La Free Software Foundation a un programme de certification nommé Respects Your Freedom (RYF), pour les produits matériels qui respectent votre liberté et votre vie privée en s'assurant que vous avez le contrôle sur l'appareil. Nous vous encourageons à vérifier la liste des appareils certifiés par RYF. Une autre ressource utile est le site web H-Node . Il contient un catalogue d'appareils avec des informations sur leur support dans GNU/Linux. Suivant: Préparer l'installation , Précédent: Considérations matérielles , Monter: Installation du système [ Table des matières ][ Index ] 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.1. 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.1. system .iso.xz.sig $ gpg --verify guix-system-install-1.0.1. 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 : Décompressez l'image avec la commande xz : xz -d guix-system-install-1.0.1. système .iso.xz 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.1. 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 : Décompressez l'image avec la commande xz : xz -d guix-system-install-1.0.1. système .iso.xz 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.1. 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. Voir Installer Guix dans une VM , si, à la place, vous souhaitez installer Guix System dans une machine virtuelle (VM). Suivant: Installation graphique guidée , Précédent: Installation depuis une clef USB ou un DVD , Monter: Installation du système [ Table des matières ][ Index ] 3.4 Préparer l'installation Une fois que vous avez démarré, vous pouvez utiliser l'installateur graphique, qui rend facile la prise en main (voir Installation graphique guidée ). 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 » (voir Installation manuelle ). L'installateur graphique est disponible sur le TTY1. Vous pouvez obtenir des shells root sur les TTY 3 à 6 en tapant ctrl-alt-f3 , ctrl-alt-f4 etc. Le TTY2 affiche cette documentation que vous pouvez atteindre avec ctrl-alt-f2 . On peut naviguer dans la documentation avec les commandes du lecteur Info (voir Stand-alone GNU Info ). Le démon de souris GPM tourne sur le système d'installation, ce qui vous permet de sélectionner du texte avec le bouton gauche de la souris et de le coller en appuyant sur la molette. Remarque : L'installation nécessite un accès au réseau pour que les dépendances manquantes de votre configuration système puissent être téléchargées. Voyez la section « réseau » plus bas. Suivant: Installation manuelle , Précédent: Préparer l'installation , Monter: Installation du système [ Table des matières ][ Index ] 3.5 Installation graphique guidée L'installateur graphique est une interface utilisateur en mode texte. Il vous guidera, avec des boîtes de dialogue, le long des étapes requises pour installer GNU Guix System. La première boîte de dialogue vous permet de paramétrer le système comme vous le souhaitez pendant l'installation : vous pouvez choisir la langue, la disposition du clavier et paramétrer le réseau, qui sera utilisé pendant l'installation. L'image ci-dessous montre le dialogue pour le réseau. Les étapes suivantes vous permettent de partitionner votre disque dur, comme le montre l'image ci-dessous, de choisir si vous voulez ou non utiliser des systèmes de fichiers chiffrés, de saisir le nom d'hôte et le mot de passe root et de créer un compte supplémentaire, entre autres choses. Remarquez que, à tout moment, l'installateur vous permet de sortir de l'étape d'installation actuelle et de recommencer une étape précédente, comme le montre l'image ci-dessous. Une fois que vous avez fini, l'installateur produit une configuration de système d'exploitation et vous la montre (voir Utiliser le système de configuration ). À ce moment, vous pouvez appuyer sur « OK » et l'installation continuera. Lorsqu'elle aura réussi, vous pourrez redémarrer sur le nouveau système et vous amuser. Voir Après l'installation du système , pour la suite des festivités ! Suivant: Après l'installation du système , Précédent: Installation graphique guidée , Monter: Installation du système [ Table des matières ][ Index ] 3.6 Installation manuelle Cette section décrit comme vous pourriez installe « manuellement » GNU Guix System sur votre machine. Cette option nécessite que vous soyez familier avec GNU/Linux, le shell et avec les outils d'administration usuels. Si vous pensez que ce n'est pas pour vous, pensez à utiliser l'installateur graphique (voir Installation graphique guidée ). Le système d'installation fournit des shells root sur les TTY 3 à 6 ; appuyez sur ctrl-alt-f3 , ctrl-alt-f4 etc pour y accéder. Il inclus plusieurs outils usuels pour requis pour cette tâche. Mais c'est aussi un système Guix complet, ce qui signifie que vous pouvez installer des paquets supplémentaires si vous en avez besoin, avec guix package (voir Invoquer guix package ). • Disposition du clavier réseau et partitionnement : Paramètres initiaux. • Effectuer l'installation : Installer. Suivant: Effectuer l'installation , Monter: Installation manuelle [ Table des matières ][ Index ] 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 (voir Overview dans GNU Parted User Manual ), fdisk , et cfdisk . Lancez-en un et paramétrez votre disque avec le partitionnement qui vous convient : cfdisk Si votre disque utilise le format des tables de partitions GUID (GPT) et que vous souhaitez installer un GRUB pour système BIOS (c'est le cas par défaut), assurez-vous de créer qu'une partition de démarrage BIOS soit bien disponible (voir BIOS installation dans GNU GRUB manual ). Si vous souhaitez à la place utilise GRUB pour système EFI, vous devrez avoir une partition système EFI (ESP) en FAT32. Cette partition peut être montée dans /boot/efi par exemple et doit avoir le drapeau esp . P. ex. pour parted : parted /dev/sda set 1 esp on Remarque : Vous n'êtes pas sûr de savoir si vous devez utiliser un GRUB EFI ou BIOS ? Si le répertoire /sys/firmware/efi existe sur l'image d'installation, vous devriez probablement effectuer une installation EFI, avec grub-efi-bootloader . Sinon, vous devriez utiliser le GRUB en BIOS, grub-bootloader . Voir Configuration du chargeur d'amorçage pour plus d'information sur le chargeur d'amorçage. Une fois que vous avez fini le partitionnement du disque dur cible, vous devez créer un système de fichier sur les partitions 8 . 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 (voir Systèmes de fichiers ). On le fait habituellement avec l'option -L de mkfs.ext4 et des commandes liées. Donc, en supposant que la partition racine soit sur /dev/sda2 , on peut créer un système de fichier avec pour étiquette my-root avec : mkfs.ext4 -L my-root /dev/sda2 Si vous voulez plutôt chiffrer la partition 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 (voir swap space dans The GNU C Library Reference Manual ), assurez-vous de les initialiser avec mkswap . En supposant que vous avez une partition de swap sur /dev/sda3 , vous pouvez lancer : mkswap /dev/sda3 swapon /dev/sda3 Autrement, vous pouvez utiliser un fichier de swap. Par exemple, en supposant que dans le nouveau système vous voulez utiliser le fichier /swapfile comme fichier de swap, vous lanceriez 9 : # 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. Précédent: Disposition du clavier réseau et partitionnement , Monter: Installation manuelle [ Table des matières ][ Index ] 3.6.2 Effectuer l'installation Lorsque la partition cible est prête et que les autres partitions sont montées, on est prêt à commencer l'installation. Commencez par : herd start cow-store /mnt Cela rend /gnu/store capable de faire de la copie sur écriture, de sorte que les paquets ajoutés pendant l'installation sont écrits sur le disque cible sur /mnt plutôt que gardés en mémoire. Cela est nécessaire parce que la première phase de la commande guix system init (voir plus bas) implique de télécharger ou de construire des éléments de /gnu/store qui est initialement un système de fichiers en mémoire. Ensuite, vous devrez modifier un fichier et fournir la déclaration du système à installer. Pour cela, le système d'installation propose trois éditeurs de texte. Nous recommandons GNU nano (voir GNU nano Manual ), qui supporte la coloration syntaxique la correspondance de parenthèses ; les autres éditeurs sont GNU Zile (un clone d'Emacs) et nvi (un clone de l'éditeur vi original de BSD). Nous recommandons vivement de stocker ce fichier sur le système de fichier racine cible, disons en tant que /mnt/etc/config.scm . Sinon, vous perdrez votre fichier de configuration une fois que vous aurez redémarré sur votre nouveau système. Voir Utiliser le système de configuration , pour un aperçu de comment créer votre fichier de configuration. Les exemples de configuration dont on parle dans cette section sont disponibles dans /etc/configuration sur l'image d'installation. Ainsi, pour commencer avec une configuration du système qui fournit un serveur d'affichage graphique (un système de « bureau »), vous pouvez lancer ce qui suit : # mkdir /mnt/etc # cp /etc/configuration/desktop.scm /mnt/etc/config.scm # nano /mnt/etc/config.scm Vous devriez faire attention à ce que contient votre fichier de configuration, en particulier : Assurez-vous que la forme bootloader-configuration se réfère à la cible où vous voulez installer GRUB. Elle devrait aussi mentionner grub-bootloader si vous installer GRUB en mode BIOS (ou « legacy ») ou grub-efi-bootloader pour les système UEFI plus récents. Pour les anciens systèmes, le champs target contient un périphérique comme /dev/sda ; pour les systèmes UEFI il contient un chemin vers une partition EFI montée, comme /boot/efi , et assurez-vous bien que ce chemin est monté et qu'il y a une entrée file-system dans votre configuration. Assurez-vous que les étiquettes de vos systèmes de fichiers correspondent aux valeurs de leur champs device dans votre configuration file-system , en supposant que la configuration file-system utilise la procédure file-system-label dans son champ device . Si vous avez des partitions RAID ou chiffrées, assurez-vous d'ajouter un champ mapped-device pour les décrire (voir Périphériques mappés ). Une fois que vous avez fini les préparatifs sur le fichier de configuration, le nouveau système peut être initialisé (rappelez-vous que le système de fichiers racine cible est dans /mnt ) : guix system init /mnt/etc/config.scm /mnt Cela copie tous les fichiers nécessaires et installe GRUB sur /dev/sdX à moins que vous ne passiez l'option --no-bootloader . Pour plus d'informations, voir Invoquer guix system . Cette commande peut engendrer des téléchargements ou des constructions pour les paquets manquants, ce qui peut prendre du temps. Une fois que cette commande a terminé — et on l'espère réussi ! — vous pouvez lancer reboot et démarrer sur votre nouveau système. Le mot de passe root est d'abord vide ; les mots de passe des autres utilisateurs doivent être initialisés avec la commande passwd en tant que root , à mois que votre configuration ne spécifie autre chose (voir mot de passe des comptes utilisateurs ). Voir Après l'installation du système , pour la suite ! Suivant: Installer Guix dans une VM , Précédent: Installation manuelle , Monter: Installation du système [ Table des matières ][ Index ] 3.7 Après l'installation du système Bravo ! Vous avez maintenant redémarré sur votre système Guix ! À partir de maintenant, vous pouvez mettre à jour le système quand vous voudrez, avec : guix pull sudo guix system reconfigure /etc/config.scm Cela crée une nouvelle génération du système avec les derniers paquets et services (voir Invoquer guix system ). Nous vous recommandons de le faire régulièrement pour que votre système inclue les dernières misse à jour de sécurité (voir Mises à jour de sécurité ). Remarque : Remarquez que sudo guix exécute la commande guix de votre 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 ! Suivant: Construire l'image d'installation , Précédent: Après l'installation du système , Monter: Installation du système [ Table des matières ][ Index ] 3.8 Installer Guix sur une machine virtuelle Si vous souhaitez installer Guix System sur une machine virtuelle (VM) ou un serveur privé virtuel (VPS) plutôt que sur votre machine chérie, cette section est faite pour vous. Pour démarrer une VM QEMU pour installer Guix System sur une image disque, suivez ces étapes : Tout d'abord récupérez et décompressez l'image d'installation du système Guix comme décrit précédemment (voir Installation depuis une clef USB ou un DVD ). 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. 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.1. 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. Vous êtes maintenant root dans la VM, continuez en suivant la procédure d'installation. Voir Préparer l'installation , et suivez les instructions. Une fois l'installation terminée, vous pouvez démarrer le système dans votre image guixsd.img . Voir Lancer Guix dans une VM , pour une manière de faire. Précédent: Installer Guix dans une VM , Monter: Installation du système [ Table des matières ][ Index ] 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 Invoquer guix system pour plus d'informations sur l'image d'installation. 3.10 Construire l'image d'installation pour les cartes ARM De nombreuses cartes ARM requièrent une variante spécifique du chargeur d'amorçage U-Boot . Si vous construisez une image disque et que le chargeur d'amorçage n'est pas disponible autrement (sur un autre périphérique d'amorçage etc), il est recommandé de construire une image qui inclus le chargeur d'amorçage, plus précisément : guix system 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. Suivant: Développement , Précédent: Installation du système , Monter: Top [ Table des matières ][ Index ] 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 (voir guix package ), vous pouvez aussi utiliser l'interface Emacs-Guix (voir Le manuel de référence de emacs-guix ), après avoir installé le paquet emacs-guix (lancez la commande M-x guix-help pour le démarrer) : guix install emacs-guix • Fonctionnalités : Comment Guix va rendre votre vie plus heureuse. • Invoquer guix package : Installation, suppression, etc. de paquets. • Substituts : Télécharger des binaire déjà construits. • Des paquets avec plusieurs résultats : Un seul paquet source, plusieurs résultats. • Invoquer guix gc : Lancer le ramasse-miettes. • Invoquer guix pull : Récupérer la dernière version de Guix et de la distribution. • Canaux : Personnaliser la collection des paquets. • Inférieurs : Interagir avec une autre révision de Guix. • Invoquer guix describe : Affiche des informations sur la révision Guix actuelle. • Invoquer guix archive : Exporter et importer des fichiers du dépôt. Suivant: Invoquer guix package , Monter: Gestion de paquets [ Table des matières ][ Index ] 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 (voir 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 (voir 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 (voir 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 (voir Introduction ). Chaque nom de répertoire de paquet dans /gnu/store contient un hash de toutes les entrées qui ont été utilisées pendant la construction de ce paquet — le compilateur, les bibliothèques, les scripts de construction, etc. Cette correspondance directe permet aux 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 (voir container ). Ce fondement permet à Guix de supporter le déploiement transparent de binaire ou source . Lorsqu'une binaire pré-construit pour une entrée de /gnu/store est disponible depuis une source externe (un substitut ), Guix le télécharge simplement et le décompresse ; sinon, il construit le paquet depuis les sources localement (voir Substituts ). Comme les résultats des constructions sont généralement reproductibles au bit près, si vous n'avez pas besoin de faire confiance aux serveurs qui fournissent les substituts : vous pouvez forcer une construction locale et défier les fournisseurs (voir Invoquer guix challenge ). Le contrôle de l'environnement de construction est aussi une fonctionnalité utile pour les développeurs. La commande guix environment permet aux développeurs d'un paquet de mettre en place rapidement le bon environnement de développement pour leur paquet, sans avoir à installer manuellement les dépendances du paquet dans leur profil (voir Invoquer guix environment ). La totalité de Guix et des définitions de paquets sont placés sous contrôle de version, et guix pull vous permet de « voyager dans le temps » de l'historique de Guix lui-même (voir Invoquer guix pull ). Cela est rend possible la réplication d'une instance Guix sur une machine différente ou plus tard, ce qui vous permet de répliquer des environnements logiciels complets , tout en garantissant un suivi de provenance précis des logiciels. Suivant: Substituts , Précédent: Fonctionnalités , Monter: Gestion de paquets [ Table des matières ][ Index ] 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 (voir Fonctionnalités ). Sa syntaxe est : guix package options options spécifie d'abord les opérations à effectuer pendant la transaction. À la fin, une nouvelle génération du profil est créée mais les générations précédentes du profil restent disponibles si l'utilisateur 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 (voir --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 (voir Bash Startup Files dans The GNU Bash Reference Manual ) pour que les shells créés ensuite aient tous les bonnes définitions des variables d'environnement : GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$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 (voir 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 paquet s 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 (voir Des paquets avec plusieurs résultats ). Des paquets avec un nom correspondant et (éventuellement une version) sont recherchés dans les modules de la distribution GNU (voir Modules de paquets ). Parfois les paquets ont des entrées propagées : ce sont des dépendances qui sont installées automatiquement avec le paquet demandé (voir propagated-inputs in package objects pour plus d'informations sur les entrées propagées dans les définitions des paquets). Un exemple est la bibliothèque MPC de GNU : ses fichiers d'en-tête C se réfèrent à ceux de la bibliothèque MPFR de GNU, qui se réfèrent en retour à ceux de la bibliothèque GMP. Ainsi, lorsqu'on installe MPC, les bibliothèques MPFR et GMP sont aussi installées dans le profil ; supprimer MPC supprimera aussi MPFR et GMP — à moins qu'ils n'aient été aussi installés explicitement par l'utilisateur. 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 (voir Définition des paquets ) : (use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+)) 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 (voir Invoquer guix environment ). --remove= paquet … -r paquet … Supprimer les paquet s 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 (voir 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 (voir Environment Variables dans Using the GNU Compiler Collection (GCC) ). Si GCC et, disons, la bibliothèque C sont installés dans le profil, alors --search-paths suggérera d'initialiser ces variables à profil /include et profil /lib , respectivement. Le cas d'utilisation typique est de définir ces variables d'environnement dans le shell : $ eval `guix package --search-paths` genre peut être l'une des valeurs exact , prefix ou suffix , ce qui signifie que les définitions des variables d'environnement 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 (voir GNU recutils databases dans GNU recutils manual ). Cela permet à des champs spécifiques d'être extraits avec la commande recsel , par exemple : $ guix package -s malloc | recsel -p name,version,relevance name: jemalloc version: 4.5.0 relevance: 6 name: glibc version: 2.25 relevance: 1 name: libgc version: 7.6.0 relevance: 1 De manière similaire, pour montrer le nom de tous les paquets disponibles sous license GNU LGPL version 3 : $ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"' name: elfutils name: gmp … Il est aussi possible de raffiner les résultats de la recherche en donnant plusieurs options -s à guix package , ou plusieurs arguments à guix search . Par exemple, la commande suivante renvoie la liste des jeux de plateau (cette fois-ci avec l'alias guix search ) : $ guix search '\<board\>' game | recsel -p name name: gnubg … Si on avait oublié -s game , on aurait aussi eu les paquets logiciels qui s'occupent de circuits imprimés (en anglais : circuit board) ; supprimer les chevrons autour de board aurait aussi ajouté les paquets qui parlent de clavier (en anglais : 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 Voir Selection Expressions dans GNU recutils manual pour plus d'information sur les expressions de sélection pour recsel -e . --show= paquet Afficher les détails du paquet dans la liste des paquets disponibles, au format recutils (voir GNU recutils databases dans GNU recutils manual ). $ guix package --show=python | recsel -p name,version name: python version: 2.7.6 name: python version: 3.3.5 Vous pouvez aussi spécifier le nom complet d'un paquet pour n'avoir que les détails concernant une version spécifique : $ 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 (voir 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 (voir Des paquets avec plusieurs résultats ), et l'emplacement de sa définition. --list-generations[= motif ] -l [ motif ] Renvoyer la liste des générations avec leur date de création ; pour chaque génération, montre les paquets installés avec les paquets installés les plus récemment en dernier. Remarquez que la zéroième génération n'est jamais montrée. Pour chaque paquet installé, afficher les éléments suivants, séparés par des tabulations : le nom du paquet, sa version, la partie du paquet qui a été installée (voir Des paquets avec plusieurs résultats ), et l'emplacement du paquet dans le dépôt. Lorsque motif est utilisé, la commande ne renvoie que les générations correspondantes. Les motifs valides sont : Des entiers et des entiers séparés par des virgules . Les deux motifs correspondent à 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 (voir Options de construction communes ). Elle supporte aussi les options de transformation de paquets comme --with-source (voir 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 (voir Définition des paquets ). Suivant: Des paquets avec plusieurs résultats , Précédent: Invoquer guix package , Monter: Gestion de paquets [ Table des matières ][ Index ] 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 (voir Dérivations ). Bien sûr dans le cas général, il s'agit de paquets binaires pré-construits, mais les archives des sources par exemple résultent aussi de la construction d'une dérivation qui peut aussi être disponible en tant que substitut. • Serveur de substituts officiel : Une source particulière de substituts. • Autoriser un serveur de substituts : Comment activer ou désactiver les substituts. • Authentification des substituts : Comment Guix vérifie les substituts. • Paramètres de serveur mandataire : Comment récupérer des substituts à travers un serveur mandataire. • Échec de substitution : Qu'arrive-t-il quand la substitution échoue. • De la confiance en des binaires : Comment pouvez-vous avoir confiance en un paquet binaire ? Suivant: Autoriser un serveur de substituts , Monter: Substituts [ Table des matières ][ Index ] 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 (voir guix-daemon --substitute-urls ) soit aux outils clients comme guix package (voir client --substitute-urls option ). Les URL des substituts peuvent être soit en HTTP soit en HTTPS. Le HTTPS est recommandé parce que les communications sont chiffrées ; à l'inverse HTTP rend les communications visibles pour un espion qui peut utiliser les informations accumulées sur vous pour déterminer par exemple si votre système a des vulnérabilités de sécurités non corrigées. Les substituts de la ferme de construction officielle sont activés par défaut dans la distribution système Guix (voir Distribution GNU ). Cependant, ils sont désactivés par défaut lorsque vous utilisez Guix sur une distribution externe, à moins que vous ne les ayez explicitement activés via l'une des étapes d'installation recommandées (voir Installation ). Les paragraphes suivants décrivent comment activer ou désactiver les substituts pour la ferme de construction officielle ; la même procédure peut être utilisée pour activer les substituts de n'importe quel autre serveur de substituts. Suivant: Authentification des substituts , Précédent: Serveur de substituts officiel , Monter: Substituts [ Table des matières ][ Index ] 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 (voir Invoquer guix archive ). Cela implique que vous faîtes confiance à ci.guix.gnu.org pour ne pas être compromis et vous servir des substituts authentiques. 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.1.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 (voir Invoquer guix-daemon ). Il peut aussi être désactivé temporairement en passant l'option --no-substitutes à guix package , guix build et aux autres outils en ligne de commande. Suivant: Paramètres de serveur mandataire , Précédent: Autoriser un serveur de substituts , Monter: Substituts [ Table des matières ][ Index ] 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). Suivant: Échec de substitution , Précédent: Authentification des substituts , Monter: Substituts [ Table des matières ][ Index ] 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 . Suivant: De la confiance en des binaires , Précédent: Paramètres de serveur mandataire , Monter: Substituts [ Table des matières ][ Index ] 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 (voir common build option --fallback ). Plus spécifiquement, si cet option n'a pas été passée en argument, alors aucune construction locale n'est effectuée et la dérivation est considérée comme étant en échec. Cependant, si --fallback est passé en argument, alors Guix essaiera de construire la dérivation localement et l'échec ou le succès de la dérivation dépend de l'échec ou du succès de la construction locale. Remarquez que lorsque les substituts sont désactivés ou qu'aucun substitut n'est disponible pour la dérivation en question, une construction locale sera toujours effectuée, indépendamment du fait que l'argument --fallback ait été ou non passé. Pour se donner une idée du nombre de substituts disponibles maintenant, vous pouvez essayer de lancer la commande guix weather (voir Invoquer guix weather ). Cette command fournit des statistiques sur les substituts fournis par un serveur. Précédent: Échec de substitution , Monter: Substituts [ Table des matières ][ Index ] 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 (voir Invoquer guix publish ). Guix possède les fondations pour maximiser la reproductibilité logicielle (voir Fonctionnalités ). Dans la plupart des cas, des constructions indépendantes d'un paquet donnée ou d'une dérivation devrait donner des résultats identiques au bit près. Ainsi, à travers un ensemble de constructions de paquets indépendantes il est possible de renforcer l'intégrité du système. La commande guix challenge a pour but d'aider les utilisateurs à tester les serveurs de substituts et à aider les développeurs à trouver les constructions de paquets non-déterministes (voir 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 (voir guix build --check ). 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 . Suivant: Invoquer guix gc , Précédent: Substituts , Monter: Gestion de paquets [ Table des matières ][ Index ] 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
...
-
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/fr/guix.fr.html
- [detail]
- [similar]
PREV
NEXT