advanced help
per page, with , order by , clip by
Results of 0 - 1 of about 0 (0.003 sec.)
Manuel de référence de GNU Guix
@digest: ac2e0fe6f2b08b2b44f3429b49cdbf6e
@id: 73519
@mdate: 2018-12-06T16:42:54Z
@size: 1835225
@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: invoquer (161446), substituts (156353), paquets (127665), demon (57359), construction (55062), depot (53862), paquet (53405), canaux (52961), profil (51900), guix (47009), environnement (40050), lancer (38514), generations (38058), commande (36363), matieres (36181), processus (33834), voir (33670), fichiers (31993), lorsque (30159), installe (29610), defaut (28922), construire (27488), systeme (27039), repertoire (25326), constructions (23739), inferior (23384), precedent (22777), serveur (22261), fichier (22141), depuis (19214), utiliser (19017), utilisateur (17630)
Manuel de référence de GNU Guix Table des matières 1 Introduction 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 Gestion de paquets 3.1 Fonctionnalités 3.2 Invoquer guix package 3.3 Substituts 3.3.1 Serveur de substituts officiel 3.3.2 Autoriser un serveur de substituts 3.3.3 Authentification des substituts 3.3.4 Paramètres de serveur mandataire 3.3.5 Échec de substitution 3.3.6 De la confiance en des binaires 3.4 Des paquets avec plusieurs résultats 3.5 Invoquer guix gc 3.6 Invoquer guix pull 3.7 Canaux 3.7.1 Utiliser un canal Guix personnalisé 3.7.2 Spécifier des canaux supplémentaires 3.7.3 Répliquer Guix 3.8 Inférieurs 3.9 Invoquer guix describe 3.10 Invoquer guix pack 3.11 Invoquer guix archive 4 Interface de programmation 4.1 Définition des paquets 4.1.1 Référence de package 4.1.2 Référence de origin 4.2 Systèmes de construction 4.3 Le dépôt 4.4 Dérivations 4.5 La monad du dépôt 4.6 G-Expressions 4.7 Invoquer guix repl 5 Utilitaires 5.1 Invoquer guix build 5.1.1 Options de construction communes 5.1.2 Options de transformation de paquets 5.1.3 Options de construction supplémentaires 5.1.4 Débogage des échecs de construction 5.2 Invoquer guix edit 5.3 Invoquer guix download 5.4 Invoquer guix hash 5.5 Invoquer guix import 5.6 Invoquer guix refresh 5.7 Invoquer guix lint 5.8 Invoquer guix size 5.9 Invoque guix graph 5.10 Invoquer guix environment 5.11 Invoquer guix publish 5.12 Invoquer guix challenge 5.13 Invoquer guix copy 5.14 Invoquer guix container 5.15 Invoquer guix weather 5.16 Invoquer guix processes 6 Distribution GNU 6.1 Installation du système 6.1.1 Limitations 6.1.2 Considérations matérielles 6.1.3 Installation depuis une clef USB ou un DVD Copie sur une clef USB Graver sur un DVD Démarrage 6.1.4 Préparer l'installation 6.1.4.1 Disposition du clavier 6.1.4.2 Réseau 6.1.4.3 Partitionnement 6.1.5 Effectuer l'installation 6.1.6 Installer GuixSD sur une machine virtuelle 6.1.7 Construire l'image d'installation 6.1.8 Construire l'image d'installation pour les cartes ARM 6.2 Configuration système 6.2.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 6.2.2 Référence de operating-system 6.2.3 Systèmes de fichiers 6.2.4 Périphériques mappés 6.2.5 Comptes utilisateurs 6.2.6 Régionalisation 6.2.6.1 Considérations sur la compatibilité des données linguistiques 6.2.7 Services 6.2.7.1 Services de base 6.2.7.2 Exécution de tâches planifiées 6.2.7.3 Rotation des journaux 6.2.7.4 Services réseau 6.2.7.5 Système de fenêtrage X 6.2.7.6 Services d'impression 6.2.7.7 Services de bureaux 6.2.7.8 Services de son 6.2.7.9 Services de bases de données 6.2.7.10 Services de courriels 6.2.7.11 Services de messagerie 6.2.7.12 Services de téléphonie 6.2.7.13 Services de surveillance 6.2.7.14 Services Kerberos 6.2.7.15 Services web 6.2.7.16 Services de certificats 6.2.7.17 Services DNS 6.2.7.18 Services VPN 6.2.7.19 Système de fichiers en réseau 6.2.7.20 Intégration continue 6.2.7.21 Services de gestion de l'énergie 6.2.7.22 Services audio 6.2.7.23 services de virtualisation 6.2.7.24 Services de contrôle de version 6.2.7.25 Services de jeu 6.2.7.26 Services divers 6.2.7.27 Dictionary Services 6.2.8 Programmes setuid 6.2.9 Certificats X.509 6.2.10 Name Service Switch 6.2.11 Disque de RAM initial 6.2.12 Configuration du chargeur d'amorçage 6.2.13 Invoquer guix system 6.2.14 Running GuixSD in a Virtual Machine 6.2.14.1 Connecting Through SSH 6.2.14.2 Using virt-viewer with Spice 6.2.15 Définir des services 6.2.15.1 Composition de services 6.2.15.2 Types service et services 6.2.15.3 Référence de service 6.2.15.4 Services Shepherd 6.3 Documentation 6.4 Installer les fichiers de débogage 6.5 Mises à jour de sécurité 6.6 Modules de paquets 6.7 Consignes d'empaquetage 6.7.1 Liberté logiciel 6.7.2 Conventions de nommage 6.7.3 Numéros de version 6.7.4 Synopsis et descriptions 6.7.5 Modules python 6.7.5.1 Specifying Dependencies 6.7.6 Modules perl 6.7.7 Paquets java 6.7.8 Polices de caractères 6.8 Bootstrapping Preparing to Use the Bootstrap Binaries Building the Build Tools Building the Bootstrap Binaries Reducing the Set of Bootstrap Binaries 6.9 Porter vers une nouvelle plateforme 7 Contribuer 7.1 Construire depuis Git 7.2 Lancer Guix avant qu'il ne soit installé 7.3 La configuration parfaite 7.4 Style de code 7.4.1 Paradigme de programmation 7.4.2 Modules 7.4.3 Types de données et reconnaissance de motif 7.4.4 Formatage du code 7.5 Envoyer des correctifs Envoyer une série de correctifs 8 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 0.16.0, un outil de gestion de paquets fonctionnel écrit pour le système GNU. Ce manuel est aussi disponible en anglais (voir GNU Guix Reference Manual ) et en allemand (voir Referenzhandbuch zu GNU Guix ). Si vous souhaitez nous aider à traduire ce manuel en français, vous pouvez nous rejoindre sur le projet de traduction et sur la liste de diffusion traduc@traduc.org . • Introduction : Qu'est-ce que Guix ? • Installation : Installer Guix. • Gestion de paquets : Installation des paquets, mises à jour, etc. • Interface de programmation : Utiliser Guix en Scheme. • Utilitaires : Commandes de gestion de paquets. • Distribution GNU : Des logiciels pour un système GNU convivial. • 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 — 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. 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 pack : Créer des lots de logiciels. • 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 : Coment 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 ? Interface de programmation • 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 monad 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 de paquet : Le type de donnée des paquets. • Référence d'origine : 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 environment : Mettre en place des environnements de développement. • 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. Distribution GNU • Installation du système : Installer le système d'exploitation complet. • 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. • Modules de paquets : Les paquets du point de vu du programmeur. • Consignes d'empaquetage : Faire grandir la distribution. • Bootstrapping : GNU/Linux depuis zéro. • Porter : Cibler une autre plateforme ou un autre noyau. 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. • Effectuer l'installation : Pour de vrai. • Installer GuixSD dans une VM : Jouer avec GuixSD. • Construire l'image d'installation : D'où vient tout cela. 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. • 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 GuixSD dans une VM : Comment lancer GuixSD 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. Consignes d'empaquetage • Liberté logiciel : Ce que la distribution peut contenir. • Conventions de nommage : Qu'est-ce qu'un bon nom ? • Numéros de version : Lorsque le nom n'est pas suffisant. • Synopsis et descriptions : Aider les utilisateurs à trouver le bon paquet. • Modules python : Un peu de comédie anglaise. • Modules perl : Petites perles. • Paquets java : Pause café. • Polices de caractères : À fond les fontes. Contribuer • Construire depuis Git : toujours le plus récent. • Lancer Guix avant qu'il ne soit installé : Astuces pour les hackers. • La configuration parfaite : Les bons outils. • Style de code : Hygiène du contributeur. • Envoyer des correctifs : Partager votre travail. Style de code • Paradigme de programmation : Comment composer vos éléments. • Modules : Où stocker votre code ? • Types de données et reconnaissance de motif : Implémenter des structures de données. • Formatage du code : Conventions d'écriture. 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 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. Guix fournit une interface de gestion des paquets par la ligne de commande (voir Invoquer guix package ), un ensemble d'utilitaires en ligne de commande (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 ). 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 à travers la Distribution Système Guix ou GuixSD (voir Distribution GNU ) distincte. Avec GNU GuixSD, vous déclarez tous les aspects de la configuration du système d'exploitation et Guix s'occupe de créer la configuration d'une manière transactionnelle, reproductible et sans état (voir Configuration système ). 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 ). Suivant: Gestion de paquets , Précédent: Introduction , Monter: Top [ Table des matières ][ Index ] 2 Installation GNU Guix est disponible au téléchargement depuis son site web sur http://www.gnu.org/software/guix/ . Cette section décrit les pré-requis logiciels de Guix ainsi que la manière de l'installer et de se préparer à l'utiliser. Remarquez que cette section concerne l'installation du gestionnaire de paquet, ce qui se fait sur un système GNU/Linux en cours d'exécution. Si vous souhaitez plutôt installer le système d'exploitation GNU complet, voir Installation du système . Lorsqu'il est installé sur un système GNU/Linux existant — ci-après nommé distro extérieure — 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 ). • 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 intaller 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. Nous fournissons un script script d'intallation shell qui automatise le téléchargement, l'installation et la configuration initiale de Guix. Il devrait être lancé en tant qu'utilisateur root. L'installation se comme ceci : Téléchargez l'archive binaire depuis ‘ https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0. système .tar.xz ', où système est x86_64-linux pour une machine x86_64 sur laquelle tourne déjà le noyau Linux, etc. Assurez-vous de télécharger le fichier .sig associé et de vérifier l'authenticité de l'archive avec, comme ceci : $ wget https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0. système .tar.xz.sig $ gpg --verify guix-binary-0.16.0. système .tar.xz.sig Si cette commande échoue parce que vous n'avez pas la clef publique requise, lancez cette commande pour l'importer : $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 et relancez la commande gpg --verify . 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-0.16.0. 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 pret à ê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 hydra.gnu.org ou l'un de ses mirroirs (voir Substituts ), autorisez-les : # guix archive --authorize < \ ~root/.config/guix/current/share/guix/hydra.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 package -i hello Le paquet guix doit rester disponible dans le profil de root ou il pourrait être sujet au ramassage de miettes — dans ce cas vous vous retrouveriez gravement handicapé par l'absence de la commande guix . En d'autres termes, ne supprimez pas guix en lançant guix package -r guix . L'archive d'installation binaire peut être (re)produite et vérifiée simplement en lançaint la commande suivante dans l'arborescence des sources de Guix : make guix-binary. system .tar.xz ... which, in turn, runs: 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 dépend des paquets suivants : GNU Guile , version 2.0.13 ou supérieure, dont 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, zlib , GNU Make . Les dépendances suivantes sont facultatives : Installer Guile-JSON vous permettra d'utiliser la commande guix import pypi (voir Invoquer guix import ). Il est surtout utile pour les développeurs et pas pour les utilisateurs occasionnels. 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 ullté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éfinire 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 d'exploitation GuixSD. 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 2 : # 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 3 ; 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 4 . 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 guile doit être dans le chemin de recherche des machines de construction. En plus, les modules Guix doivent se trouver dans $GUILE_LOAD_PATH sur la machine de construction. Vous pouvez vérifier si c'est le cas en lançant : ssh build-machine guile -c "'(use-modules (guix config))'" 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 SELniux 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 GuixSD ne fournit pas de politique SELniux de base, la politique du démon ne peut pas être utilisée sur GuixSD. 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'et 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://mirror.hydra.gnu.org https://hydra.gnu.org ' est utilisé ( mirror.hydra.gnu.org est un mirroire de hydra.gnu.org ). 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 sourtie 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 différente de GuixSD — 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 package -i 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 effectue la résolution eux-même, 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 package -i 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 utlisant 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çaint 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. Par défaut, l'enveloppe refuse de lier des bibliothèques en dehors du dépôt pour assure la « pureté ». Cela peut être embêtant lorsque vous utilisez la chaîne d'outils pour lier des bibliothèques locales. Pour permettre des références à des bibliothèques en dehors du dépôt, vous devrez définir la variable d'environnement GUIX_LD_WRAPPER_ALLOW_IMPURITIES . Suivant: Interface de programmation , Précédent: Installation , Monter: Top [ Table des matières ][ Index ] 3 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 package -i 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 pack : Créer des lots de logiciels. • 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 ] 3.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à intallé 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, les utilisateurs peuvent revenir en arrière à l'instance précédente de leur profil qui est connu pour bien fonctionner. De manière similaire, la configuration globale du système dans GuixSD 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 ] 3.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 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 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 recommendation. --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. --verbose Produire une sortie verbeuse. En particulier, fournir les journaux de construction de l'environnement sur le port d'erreur standard. --bootstrap Utiliser le programme d'amorçage Guile pour compiler le profil. Cette option n'est utile que pour les développeurs de la distriibution. 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 , 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 avec plusieurs options -s . Par exemple, la commande suivante renvoie la liste des jeux de plateau : $ guix package -s '\<board\>' -s 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 package -s crypto -s 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 interval . --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 interval 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 agé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 ] 3.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 : Coment 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 ] 3.3.1 Serveur de substituts officiel Le serveur mirror.hydra.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 de la ferme de construction ; 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 ] 3.3.2 Autoriser un serveur de substituts Pour permettre à Guix de télécharger les substituts depuis hydra.gnu.org ou un mirroir, 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 à hydra.gnu.org pour ne pas être compromis et vous servir des substituts authentiques. La clef publique pour hydra.gnu.org est installée avec Guix, dans préfixe /share/guix/hydra.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-0.16.0.tar.gz qui contient ce fichier de clef publique. Ensuite vous pouvez lancer quelque chose comme ceci : # guix archive --authorize < préfixe /share/guix/hydra.gnu.org.pub Remarque : De même, le fichier berlin.guixsd.org.pub contient la clef publique de la nouvelle ferme de construction du projet, disponible depuis ‘ https://berlin.guixsd.org '. Au moment où ces lignes sont écrites, berlin.guixsd.org est mis à niveau pour mieux passer à l'échelle, mais vous pourriez vouloir le tester. Il est associé à 20 nœuds de construction x86_64/i686 et pourrait fournir des substituts plus rapidement que 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 hydra.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 ] 3.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 mirroir 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ême, 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 ] 3.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 ] 3.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 ] 3.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 hydra.gnu.org soit pratique, nous encourageons les utilisateurs à construire aussi par eux-même, voir à faire tourner leur propre ferme de construction, pour que hydra.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 ] 3.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 package -i 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 particuliers, 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 package -i glib La commande pour installer la documentation est : guix package -i glib:doc Certains paquets installent des programmes avec des « empreintes dépendances » différentes. Par exemple le paquet WordNet installe à la fois les outils en ligne de commande et les interfaces graphiques (GUI). La première ne dépend que de la bibliothèque C, alors que cette dernière dépend de Tcl/Tk et des bibliothèques X sous-jacentes. Dans ce cas, nous laissons les outils en ligne de commande dans la sortie par défaut et l'interface graphique dans une sortie séparée. Cela permet aux utilisateurs qui n'ont pas besoin d'interface graphique de gagner de la place. La commande guix size peut aider à trouver ces situations (voir Invoquer guix size ). guix graph peut aussi être utile (voir Invoquer guix graph ). Il y a plusieurs paquets à sorties multiples dans la distribution GNU. D'autres noms de sorties conventionnels sont lib pour les bibliothèques et éventuellement les fichiers d'en-tête, bin pour les programmes indépendants et debug pour les informations de débogage (voir Installer les fichiers de débogage ). Les sorties d'un paquet sont listés dans la troisième colonne de la sortie de guix package --list-available (voir Invoquer guix package ). Suivant: Invoquer guix pull , Précédent: Des paquets avec plusieurs résultats , Monter: Gestion de paquets [ Table des matières ][ Index ] 3.5 Invoquer guix gc Les paquets qui sont installés mais pas utilisés peuvent être glanés . La commande guix gc permet aux utilisateurs de lancer explicitement le ramasse-miettes pour récupérer de l'espace dans le répertoire /gnu/store . C'est la seule manière de supprimer des fichiers de /gnu/store — supprimer des fichiers ou des répertoires à la main peut le casser de manière impossible à réparer ! Le ramasse-miettes a un ensemble de racines connues : tout fichier dans /gnu/store atteignable depuis une racine est considéré comme utilisé et ne peut pas être supprimé ; tous les autres fichiers sont considérés comme inutilisés et peuvent être supprimés. L'ensemble des racines du ramasse-miettes (ou « racines du GC » pour faire court) inclue les profils par défaut des utilisateurs ; par défaut les liens symboliques sous /var/guix/gcroots représentent ces racines du GC. De nouvelles racines du GC peuvent être ajoutées avec la guix build -- root par exemple (voir Invoquer guix build ). Avant de lancer guix gc --collect-garbage pour faire de la place, c'est souvent utile de supprimer les anciennes génération des profils utilisateurs ; de cette façon les anciennes constructions de paquets référencées par ces générations peuvent être glanées. Cela se fait en lançaint guix package --delete-generations (voir Invoquer guix package ). Nous recommandons de lancer le ramasse-miettes régulièrement ou lorsque vous avez besoin d'espace disque. Par exemple pour garantir qu'au moins 5 Go d'espace reste libre sur votre disque, lancez simplement : guix gc -F 5G Il est parfaitement possible de le lancer comme une tâche périodique non-interactive (voir Exécution de tâches planifiées pour apprendre comment paramétrer une telle tâche sur GuixSD). Lancer guix gc sans argument ramassera autant de miettes que possible mais ça n'est pas le plus pratique : vous pourriez vous retrouver à reconstruire ou re-télécharger des logiciels « inutilisés » du point de vu du GC mais qui sont nécessaires pour construire d'autres logiciels — p. ex. la chaîne de compilation. La command guix gc a trois modes d'opération : il peut être utilisé pour glaner des fichiers inutilisés (par défaut), pour supprimer des fichiers spécifiques (l'option --delete ), pour afficher des informations sur le ramasse-miettes ou pour des requêtes plus avancées. Les options du ramasse-miettes sont : --collect-garbage[= min ] -C [ min ] Ramasse les miettes — c.-à-d. les fichiers inaccessibles de /gnu/store et ses sous-répertoires. C'est l'opération par défaut lorsqu'aucune option n'est spécifiée. Lorsque min est donné, s'arrêter une fois que min octets ont été collectés. min pour être un nombre d'octets ou inclure un suffixe d'unité, comme MiB pour mébioctet et GB pour gigaoctet (voir size specifications dans GNU Coreutils ). Lorsque min est omis, tout glaner. --free-space= libre -F libre Glaner jusqu'à ce que libre espace soit disponible dans /gnu/store si possible ; libre est une quantité de stockage comme 500MiB comme décrit ci-dessus. Lorsque libre ou plus est disponible dans /gnu/store ne rien faire et s'arrêter immédiatement. --delete -d Essayer de supprimer tous les fichiers et les répertoires du dépôt spécifiés en argument. Cela échoue si certains des fichiers ne sont pas dans le dépôt ou s'ils sont toujours utilisés. --list-failures Lister les éléments du dépôt qui correspondent à des échecs de construction Cela n'affiche rien à moins que le démon n'ait été démarré avec --cache-failures (voir --cache-failures ). --clear-failures Supprimer les éléments du dépôt spécifiés du cache des constructions échouées. De nouveau, cette option ne fait de sens que lorsque le démon est démarré avec --cache-failures . Autrement elle ne fait rien. --list-dead Montrer la liste des fichiers et des répertoires inutilisés encore présents dans le dépôt — c.-à-d. les fichiers et les répertoires qui ne sont plus atteignables par aucune racine. --list-live Montrer la liste des fichiers et des répertoires du dépôt utilisés. En plus, les références entre les fichiers existants du dépôt peuvent être demandés : --references --referrers Lister les références (respectivement les référents) des fichiers du dépôt en argument. --requisites -R Lister les prérequis des fichiers du dépôt passés en argument. Les prérequis sont le fichier du dépôt lui-même, leur références et les références de ces références, récursivement. En d'autre termes, la liste retournée est la closure transitive des fichiers du dépôt. Voir Invoquer guix size pour un outil pour surveiller la taille de la closure d'un élément. Voir Invoquer guix graph pour un outil pour visualiser le graphe des références. --derivers Renvoie les dérivations menant aux éléments du dépôt donnés (voir Dérivations ). Par exemple cette commande : guix gc --derivers `guix package -I ^emacs$ | cut -f4` renvoie les fichiers .drv menant au paquet emacs installé dans votre profil. Remarquez qu'il peut n'y avoir aucun fichier .drv par exemple quand ces fichiers ont été glanés. Il peut aussi y avoir plus d'un fichier .drv correspondant à cause de dérivations à sortie fixées. Enfin, les options suivantes vous permettent de vérifier l'intégrité du dépôt et de contrôler l'utilisation du disque. --verify[= options ] Vérifier l'intégrité du dépôt. Par défaut, s'assurer que tous les éléments du dépôt marqués comme valides dans la base de données du démon existent bien dans /gnu/store . Lorsqu'elle est fournie, l' option doit être une liste séparée par des virgule de l'un ou plus parmi contents et repair . Lorsque vous passez --verify=contents , le démon calcul le hash du contenu de chaque élément du dépôt et le compare au hash de sa base de données. Les différences de hash sont rapportées comme des corruptions de données. Comme elle traverse tous les fichiers du dépôt , cette commande peut prendre très longtemps pour terminer, surtout sur un système avec un disque lent. Utiliser --verify=repair ou --verify=contents,repair fait que le démon essaie de réparer les objets du dépôt corrompus en récupérant leurs substituts (voir Substituts ). Comme la réparation n'est pas atomique et donc potentiellement dangereuse, elle n'est disponible que pour l'administrateur système. Une alternative plus légère lorsque vous connaissez exactement quelle entrée est corrompue consiste à lancer guix build --repair (voir Invoquer guix build ). --optimize Optimiser le dépôt en liant en dur les fichiers identiques — c'est la déduplication . Le démon effectue une déduplication à chaque construction réussie ou import d'archive à moins qu'il n'ait été démarré avec --disable-deduplication (voir --disable-deduplication ). Ainsi, cette option est surtout utile lorsque le démon tourne avec --disable-deduplication . Suivant: Canaux , Précédent: Invoquer guix gc , Monter: Gestion de paquets [ Table des matières ][ Index ] 3.6 Invoquer guix pull Les paquets sont installés ou mis à jour vers la dernière version disponible dans la distribution actuellement disponible sur votre machine locale. Pour mettre à jour cette distribution, en même temps que les outils Guix, vous devez lancer guix pull ; la commande télécharge le dernier code source de Guix et des descriptions de paquets et le déploie. Le code source est téléchargé depuis un dépôt Git , par défaut le dépôt officiel de GNU Guix, bien que cela puisse être personnalisé. À la fin, guix package utilisera les paquets et les versions des paquets de la copie de Guix tout juste récupérée. Non seulement ça, mais toutes les commandes Guix et les modules Scheme seront aussi récupérés depuis la dernière version. Les nouvelles sous-commandes de guix ajoutés par la mise à jour sont aussi maintenant disponibles. Chaque utilisateur peut mettre à jour sa copie de Guix avec guix pull et l'effet est limité à l'utilisateur qui a lancé guix pull . Par exemple, lorsque l'utilisateur root lance guix pull , cela n'a pas d'effet sur la version de Guix que vois alice et vice-versa Le résultat après avoir lancé guix pull est un profil disponible sous ~/.config/guix/current contenant la dernière version de Guix. Ainsi, assurez-vous de l'ajouter au début de votre chemin de recherche pour que vous utilisiez la dernière version. Le même conseil s'applique au manuel Info (voir Documentation ) : export PATH="$HOME/.config/guix/current/bin:$PATH" export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH" L'option --list-generations ou -l liste les anciennes générations produites par guix pull , avec des détails sur leur origine : $ guix pull -l Génération 1 10 juin 2018 00:18:18 guix 65956ad URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : origin/master commit : 65956ad3526ba09e1f7a40722c96c6ef7c0936fe Génération 2 11 juin 2018 11:02:49 guix e0cc7f6 URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : origin/master commit : e0cc7f669bec22c37481dd03a7941c7d11a64f1d 2 nouveaux paquets : keepalived, libnfnetlink 6 paquets mis à jour : emacs-nix-mode@2.0.4, guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac, heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4 Génération 3 13 juin 2018 23:31:07 (actuelle) guix 844cc1c URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : origin/master commit : 844cc1c8f394f03b404c5bb3aee086922373490c 28 nouveaux paquets : emacs-helm-ls-git, emacs-helm-mu, … 69 paquets mis à jour : borg@1.1.6, cheese@3.28.0, … guix describe pour d'autres manières de décrire le statut actuel de Guix. Ce profil ~/.config/guix/current fonctionne comme les autres profils créés par guix package (voir Invoquer guix package ). C'est-à-dire que vous pouvez lister les générations, revenir en arrière à une génération précédente — c.-à-d. la version de Guix précédente — etc : $ guix package -p ~/.config/guix/current --roll-back passé de la génération 3 à 2 $ guix package -p ~/.config/guix/current --delete-generations=1 suppression de /var/guix/profiles/per-user/charlie/current-guix-1-link La commande guix pull est typiquement invoquée sans arguments mais il supporte les options suivantes : --url= url --commit= commit --branch= branche Télécharger le code depuis l' url spécifié, au commit donné (un commit Git valide représenté par une chaîne hexadécimale) ou à la branche branch . Ces options sont fournies pour votre confort, mais vous pouvez aussi spécifier votre configuration dans le fichier ~/.config/guix/channels.scm ou en utilisant l'option --channels (voir plus bas). --channels= file -C file Lit la liste des canaux dans file plutôt que dans ~/.config/guix/channels.scm . file doit contenir un code Scheme qui s'évalue en une liste d'objets de canaux. Voir Canaux pour plus d'informations. --list-generations[= motif ] -l [ motif ] Liste toutes les générations de ~/.config/guix/current ou, si motif est fournit, le sous-ensemble des générations qui correspondent à motif . La syntaxe de motif est la même qu'avec guix package --list-generations (voir Invoquer guix package ). Invoquer guix describe , pour une manière d'afficher des informations sur la génération actuelle uniquement. --profile= profil -p profil Utiliser le profil à la place de ~/.config/guix/current . --dry-run -n Montrer quels commits des canaux seraient utilisés et ce qui serait construit ou substitué mais ne pas le faire vraiment. --verbose Produire une sortie verbeuse, en écrivant les journaux de construction sur la sortie d'erreur standard. --bootstrap Utiliser le programme d'amorçage Guile pour construire la dernière version de Guix. Cette option n'est utile que pour les développeurs de Guix. Le mécanisme de canaux vous permet de dire à guix pull quels répertoires et branches récupérer, ainsi que les dépôts supplémentaires contenant des modules de paquets qui devraient être déployés. Voir Canaux pour plus d'information. En plus, guix pull supporte toutes les options de construction communes (voir Options de construction communes ). Suivant: Inférieurs , Précédent: Invoquer guix pull , Monter: Gestion de paquets [ Table des matières ][ Index ] 3.7 Canaux Guix et sa collection de paquets sont mis à jour en lançant guix pull (voir Invoquer guix pull ). Par défaut guix pull télécharge et déploie Guix lui-même depuis le dépôt officiel de GNU Guix. Cela peut être personnalisé en définissant des canaux dans le fichier ~/.config/guix/channels.scm . Un canal spécifie l'URL et la branche d'un répertoire Git à déployer et on peut demander à guix pull de récupérer un ou plusieurs canaux. En d'autres termes, les canaux peuvent être utilisés pour personnaliser et pour étendre Guix, comme on le verra plus bas. 3.7.1 Utiliser un canal Guix personnalisé Le canal nommé guix spécifie où Guix lui-même — ses outils en ligne de commande ainsi que sa collection de paquets — sera téléchargé. Par exemple, supposons que vous voulez effectuer les mises à jour depuis votre propre copie du dépôt Guix sur example.org , et plus particulièrement depuis la branche super-hacks . Vous pouvez écrire cette spécification dans ~/.config/guix/channels.scm : ;; Dit à « guix pull » d'utiliser mon propre dépôt. (list (channel (name 'guix) (url "https://example.org/my-guix.git") (branch "super-hacks"))) Maintenant, guix pull récupérera le code depuis la branche super-hacks du dépôt sur example.org . 3.7.2 Spécifier des canaux supplémentaires Vous pouvez aussi spécifier des canaux supplémentaires à récupérer. Disons que vous avez un ensemble de paquets personnels ou de variantes personnalisées qu'il ne vaudrait pas le coup de contribuer au projet Guix, mais que vous voudriez pouvoir utiliser de manière transparente sur la ligne de commande. Vous écririez d'abord des modules contenant ces définitions de paquets (voir Modules de paquets ), en les maintenant dans un dépôt Git, puis vous ou n'importe qui d'autre pourrait l'utiliser comme un canal supplémentaire où trouver ces paquets. Sympa, non ? Attention : Avant que vous, cher utilisateur, ne vous exclamiez « Oh mais c'est super génial ! » et que vous ne publiez vos canaux personnels publiquement, nous voudrions vous donner quelques avertissements : Avant de publier un canal, envisagez de contribuer vos définitions de paquets dans Guix (voir Contribuer ). Guix en tant que projet est ouvert à tous les logiciels libres de toutes sortes, et les paquets dans Guix sont déjà disponibles à tous les utilisateurs de Guix et bénéficient des processus d'assurance qualité du projet. Lorsque vous maintenez des définitions de paquets en dehors de Guix, nous, les développeurs de Guix, considérons que la charge de la compatibilité vous incombe . Rappelez-vous que les modules de paquets et les définitions de paquets ne sont que du code Scheme qui utilise diverses interfaces de programmation (API). Nous souhaitons rester libres de changer ces API pour continuer à améliorer Guix, éventuellement d'une manière qui casse votre canal. Nous ne changeons jamais l'API gratuitement, mais nous ne nous engageons pas à geler les API non plus. Corollaire : si vous utilisez un canal externe et que le canal est cassé, merci de rapporter le problème à l'auteur du canal , pas au projet Guix. Vous avez été prévenus ! Maintenant, nous pensons que des canaux externes sont une manière pratique d'exercer votre liberté pour augmenter la collection de paquets de Guix et de partager vos améliorations, qui sont les principes de bases du logiciel libe . Contactez-nous par courriel sur guix-devel@gnu.org si vous souhaitez discuter à ce propos. Une fois que vous avez un dépôt Git contenant vos propres modules de paquets, vous pouvez écrire ~/.config/guix/channels.scm pour dire à guix pull de récupérer votre canal personnel en plus des canaux Guix par défaut : ;; Ajouter mes paquets personnels à ceux fournis par Guix. (cons (channel (name 'my-personal-packages) (url "https://example.org/personal-packages.git")) %default-channels) Note that the snippet above is (as always!) Scheme code; we use cons to add a channel the list of channels that the variable %default-channels is bound to (voir cons and lists dans GNU Guile Reference Manual ). With this file in place, guix pull builds not only Guix but also the package modules from your own repository. The result in ~/.config/guix/current is the union of Guix with your own package modules: $ guix pull --list-generations … Génération 19 Aug 27 2018 16:20:48 guix d894ab8 URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : master commit : d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300 my-personal-packages dd3df5e URL du dépôt : https://example.org/personal-packages.git branche : master commit : dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb 11 nouveaux paquets : my-gimp, my-emacs-with-cool-features, … 4 paquets mis à jour : emacs-racket-mode@0.0.2-2.1b78827, … La sortie de guix pull ci-dessus montre que la génération 19 contient aussi bien Guix que les paquets du canal my-personal-packages . Parmi les nouveaux paquets et les paquets mis à jour qui sont listés, certains comme my-gimp et my-emacs-with-cool-features peuvent provenir de my-personal-packages , tandis que d'autres viennent du canal par défaut de Guix. 3.7.3 Répliquer Guix La sortie de guix pull --list-generations ci-dessus montre précisément quels commits ont été utilisés pour construire cette instance de Guix. Nous pouvons donc la répliquer, disons sur une autre machine, en fournissant une spécification de canal dans ~/.config/guix/channels.scm qui est « épinglé » à ces commits : ;; Déployer des commits précis de mes canaux préférés. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300")) (channel (name 'my-personal-packages) (url "https://example.org/personal-packages.git") (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb"))) La commande guix describe --format=channels peut même générer cette liste de canaux directement (voir Invoquer guix describe ). À ce moment les deux machines font tourner exactement le même Guix , avec l'accès exactement aux même paquets . La sortie de guix build gimp sur une machine sera exactement la même, au bit près, que la sortie de la même commande sur l'autre machine. Cela signifie aussi que les deux machines ont accès à tous les codes sources de Guix, et transitivement, à tous les codes sources de tous les paquets qu'il définit. Cela vous donne des super-pouvoirs, ce qui vous permet de suivre la provenance des artefacts binaires avec un grain très fin et de reproduire les environnements logiciels à volonté — une sorte de capacité de « méta-reproductibilité », si vous voulez. Voir Inférieurs , pour une autre manière d'utiliser ces super-pouvoirs. Suivant: Invoquer guix describe , Précédent: Canaux , Monter: Gestion de paquets [ Table des matières ][ Index ] 3.8 Inférieurs Remarque : La fonctionnalité décrite ici est un « démonstrateur technique » à la version 0.16.0. Ainsi, l'interface est sujette à changements. Parfois vous pourriez avoir à mélanger des paquets de votre révision de Guix avec des paquets disponibles dans une révision différente de Guix. Les inférieurs de Guix vous permettent d'accomplir cette tâche en composant différentes versions de Guix de manière arbitraire. Techniquement, un « inférieur » est surtout un processus Guix séparé connecté à votre processus Guix principal à travers un REPL (voir Invoquer guix repl ). Le module (guix inferior) vous permet de créer des inférieurs et de communiquer avec eux. Il fournit aussi une interface de haut-niveau pour naviguer dans les paquets d'un inférieur — des paquets inférieurs — et les manipuler. Lorsqu'on les combine avec des canaux (voir Canaux ), les inférieurs fournissent une manière simple d'interagir avec un révision de Guix séparée. Par exemple, disons que vous souhaitiez installer dans votre profil le paquet guile actuel, avec le guile-json d'une ancienne révision de Guix — peut-être parce que la nouvelle version de guile-json a une API incompatible et que vous voulez lancer du code avec l'ancienne API. Pour cela, vous pourriez écrire un manifeste à utiliser avec guix package --manifest (voir Invoquer guix package ) ; dans ce manifeste, vous créeriez un inférieur pour l'ancienne révision de Guix qui vous intéresse et vous chercheriez le paquet guile-json dans l'inférieur : (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;pour « first » (define channels ;; L'ancienne révision depuis laquelle on veut ;; extraire guile-json. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; Un inférieur représentant la révision ci-dessus. (inferior-for-channels channels)) ;; Maintenant on crée un manifeste avec le paquet « guile » actuel ;; et l'ancien paquet « guile-json ». (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile"))) Durant la première exécution, guix package --manifest pourrait avoir besoin de construire le canal que vous avez spécifié avant de créer l'inférieur ; les exécutions suivantes seront bien plus rapides parce que la révision de Guix sera déjà en cache. Le module (guix inferior) fournit les procédures suivantes pour ouvrir un inférieur : Procédure Scheme : inferior-for-channels channels [#:cache-directory] [#:ttl] Renvoie un inférieur pour channels , une liste de canaux. Elle utilise le cache dans cache-directory , où les entrées peuvent être glanées après ttl secondes. Cette procédure ouvre une nouvelle connexion au démon de construction. Elle a pour effet de bord de construire ou de substituer des binaires pour channels , ce qui peut prendre du temps. Procédure Scheme : open-inferior directory [#:command "bin/guix"] Ouvre le Guix inférieur dans directory et lance directory / command repl ou équivalent. Renvoie #f si l'inférieur n'a pas pu être lancé. Les procédures listées plus bas vous permettent d'obtenir et de manipuler des paquets inférieurs. Procédure Scheme : inferior-packages inferior Renvoie la liste des paquets connus de l'inférieur inferior . Procédure Scheme : lookup-inferior-packages inferior name [ version ] Renvoie la liste triée des paquets inférieurs qui correspondent à name dans inferior , avec le plus haut numéro de version en premier. Si version est vrai, renvoie seulement les paquets avec un numéro de version préfixé par version . Procédure Scheme : inferior-package? obj Renvoie vrai si obj est un paquet inférieur. Procédure Scheme : inferior-package-name package Procédure Scheme : inferior-package-version package Procédure Scheme : inferior-package-synopsis package Procédure Scheme : inferior-package-description package Procédure Scheme : inferior-package-home-page package Procédure Scheme : inferior-package-location package Procédure Scheme : inferior-package-inputs package Procédure Scheme : inferior-package-native-inputs package Procédure Scheme : inferior-package-propagated-inputs package Procédure Scheme : inferior-package-transitive-propagated-inputs package Procédure Scheme : inferior-package-native-search-paths package Procédure Scheme : inferior-package-transitive-native-search-paths package Procédure Scheme : inferior-package-search-paths package Ces procédures sont la contrepartie des accesseurs des enregistrements de paquets (voir Référence de paquet ). La plupart fonctionne en effectuant des requêtes à l'inférieur dont provient package , donc l'inférieur doit toujours être disponible lorsque vous appelez ces procédures. Les paquets inférieurs peuvent être utilisés de manière transparente comme tout autre paquet ou objet simili-fichier dans des G-expressions (voir G-Expressions ). Ils sont aussi gérés de manière transparente par la procédure packages->manifest , qui est typiquement utilisée dans des manifestes (voir l'option --manifest de guix package ). Ainsi, vous pouvez insérer un paquet inférieur à peu près n'importe où vous utiliseriez un paquet normal : dans des manifestes, dans le champ packages de votre déclaration operating-system , etc. Suivant: Invoquer guix pack , Précédent: Inférieurs , Monter: Gestion de paquets [ Table des matières ][ Index ] 3.9 Invoquer guix describe Souvent vous voudrez répondre à des questions comme « quelle révision de Guix j'utilise ? » ou « quels canaux est-ce que j'utilise ? ». C'est une information utile dans de nombreuses situations : si vous voulez répliquer un environnement sur une machine différente ou un compte utilisateur, si vous voulez rapporter un bogue ou pour déterminer quel changement dans les canaux que vous utilisez l'a causé ou si vous voulez enregistrer l'état de votre système pour le reproduire. La commande guix describe répond à ces questions. Lorsqu'elle est lancée depuis un guix mis à jour avec guix pull , guix describe affiche les canaux qui ont été construits, avec l'URL de leur dépôt et l'ID de leur commit (voir Canaux ) : $ guix describe Generation 10 03 sep. 2018 17:32:44 (actuelle) guix e0fa68c URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : master commit : e0fa68c7718fffd33d81af415279d6ddb518f727 Si vous connaissez bien le système de contrôle de version Git, cela ressemble en essence à git describe ; la sortie est aussi similaire à celle de guix pull --list-generations , mais limitée à la génération actuelle (voir l'option --list-generations ). Comme l'ID de commit de Git ci-dessus se réfère sans aucune ambiguïté à un instantané de Guix, cette information est tout ce dont vous avez besoin pour décrire la révision de Guix que vous utilisez et pour la répliquer. Pour rendre plus facile la réplication de Guix, guix describe peut aussi renvoyer une liste de canaux plutôt que la description ...
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/de/guix.fr.html - [detail] - [similar]
PREV NEXT
Powered by Hyper Estraier 1.4.13, with 213332 documents and 1081151 words.