Mirror of GNU Guix
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

22491 lines
849 KiB

\input texinfo
@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================
@c -*-texinfo-*-
@c %**start of header
@setfilename guix.fr.info
@documentencoding UTF-8
@documentlanguage fr
@frenchspacing on
@settitle Manuel de référence de GNU Guix
@c %**end of header
@include version-fr.texi
@c Identifier of the OpenPGP key used to sign tarballs and such.
@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
@copying
Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018 Ludovic
Courtès@* Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@* Copyright
@copyright{} 2013 Nikita Karetnikov@* Copyright @copyright{} 2014, 2015,
2016 Alex Kost@* Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
Copyright @copyright{} 2014 Pierre-Antoine Rault@* Copyright @copyright{}
2015 Taylan Ulrich Bayırlı/Kammer@* Copyright @copyright{} 2015, 2016, 2017
Leo Famulari@* Copyright @copyright{} 2015, 2016, 2017, 2018 Ricardo
Wurmus@* Copyright @copyright{} 2016 Ben Woodcroft@* Copyright @copyright{}
2016, 2017, 2018 Chris Marusich@* Copyright @copyright{} 2016, 2017, 2018
Efraim Flashner@* Copyright @copyright{} 2016 John Darrington@* Copyright
@copyright{} 2016, 2017 Nils Gillmann@* Copyright @copyright{} 2016, 2017
Jan Nieuwenhuizen@* Copyright @copyright{} 2016 Julien Lepiller@* Copyright
@copyright{} 2016 Alex ter Weele@* Copyright @copyright{} 2017, 2018 Clément
Lassieur@* Copyright @copyright{} 2017 Mathieu Othacehe@* Copyright
@copyright{} 2017 Federico Beffa@* Copyright @copyright{} 2017 Carlo
Zancanaro@* Copyright @copyright{} 2017 Thomas Danckaert@* Copyright
@copyright{} 2017 humanitiesNerd@* Copyright @copyright{} 2017 Christopher
Allan Webber@* Copyright @copyright{} 2017 Marius Bakke@* Copyright
@copyright{} 2017 Hartmut Goebel@* Copyright @copyright{} 2017 Maxim
Cournoyer@* Copyright @copyright{} 2017, 2018 Tobias Geerinckx-Rice@*
Copyright @copyright{} 2017 George Clemmer@* Copyright @copyright{} 2017
Andy Wingo@* Copyright @copyright{} 2017, 2018 Arun Isaac@* Copyright
@copyright{} 2017 nee@* Copyright @copyright{} 2018 Rutger Helling@*
Copyright @copyright{} 2018 Oleg Pykhalov@* Copyright @copyright{} 2018 Mike
Gerwitz@* Copyright @copyright{} 2018 Pierre-Antoine Rouby
Vous avez la permission de copier, distribuer ou modifier ce document sous
les termes de la Licence GNU Free Documentation, version 1.3 ou toute
version ultérieure publiée par la Free Software Foundation ; sans section
invariante, texte de couverture et sans texte de quatrième de couverture.
Une copie de la licence est incluse dans la section intitulée « GNU Free
Documentation License ».
@end copying
@dircategory Administration système
@direntry
* Guix: (guix). Gérer les logiciels installés et la
configuration du système.
* guix package : (guix)Invoquer guix package. Intaller, supprimer et
mettre à jour des paquets.
* guix gc : (guix)Invoquer guix gc. Récupérer de l'espace disque
inutilisé.
* guix pull : (guix)Invoquer guix pull. Mettre à jour la liste des
paquets disponibles.
* guix system : (guix)Invoquer guix system. Gérer la configuration du
système d'exploitation.
@end direntry
@dircategory Développement logiciel
@direntry
* guix environment : (guix)Invoquer guix environment. Construire des
environnements de
construction avec
Guix.
* guix build : (guix)Invoquer guix build. Construire des paquets.
* guix pack : (guix) Invoquer guix pack. Créer des lots binaires.
@end direntry
@titlepage
@title Manuel de référence de GNU Guix
@subtitle Utiliser le gestionnaire de paquet fonctionnel GNU Guix
@author Les développeurs de GNU Guix
@page
@vskip 0pt plus 1filll
Édition @value{EDITION} @* @value{UPDATED} @*
@insertcopying
@end titlepage
@contents
@c *********************************************************************
@node Top
@top GNU Guix
Cette documentation décrit GNU Guix version @value{VERSION}, un outil de
gestion de paquets fonctionnel écrit pour le système GNU@.
@menu
* 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.
@detailmenu
--- 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.
* 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.
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 @command{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.
* Sound Services:: ALSA and Pulseaudio services.
* 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:: L'outil TLP@.
* 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.
@end detailmenu
@end menu
@c *********************************************************************
@node Introduction
@chapter Introduction
@cindex but
GNU Guix@footnote{« Guix » se prononce comme « geeks » (en prononçant le
« s »), ou « ɡiːks » dans l'alphabet phonétique international (API).} 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.
@cindex interfaces utilisateurs
Guix fournit une interface de gestion des paquets par la ligne de commande
(@pxref{Invoquer guix package}), un ensemble d'utilitaires en ligne de
commande (@pxref{Utilitaires}) ainsi que des interfaces de programmation
Scheme (@pxref{Interface de programmation}).
@cindex démon de construction
Son @dfn{démon de construction} est responsable de la construction des
paquets pour les utilisateurs (@pxref{Paramétrer le démon}) et du
téléchargement des binaires pré-construits depuis les sources autorisées
(@pxref{Substituts}).
@cindex extensibilité de la distribution
@cindex personnalisation, des paquets
Guix contient de nombreuses définitions de paquet GNU et non-GNU qui
respectent tous les @uref{https://www.gnu.org/philosophy/free-sw.fr.html,
libertés de l'utilisateur}. Il est @emph{extensible} : les utilisateurs
peuvent écrire leurs propres définitions de paquets (@pxref{Définition des paquets}) et les rendre disponibles dans des modules de paquets
indépendants (@pxref{Modules de paquets}). Il est aussi
@emph{personnalisable} : les utilisateurs peuvent @emph{dériver} des
définitions de paquets spécialisées à partir de définitions existantes, même
depuis la ligne de commande (@pxref{Options de transformation de paquets}).
@cindex Distribution Système Guix
@cindex GuixSD
Vous pouvez installer GNU@tie{}Guix sur un système GNU/Linux existant pour
compléter les outils disponibles sans interférence (@pxref{Installation}) ou
vous pouvez l'utiliser à travers la @dfn{Distribution Système Guix} ou
GuixSD (@pxref{Distribution GNU}) distincte. Avec GNU@tie{}GuixSD, vous
@emph{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 (@pxref{Configuration
système}).
@cindex gestion de paquet fonctionnelle
Sous le capot, Guix implémente la discipline de @dfn{gestion de paquet
fonctionnel} inventé par Nix (@pxref{Remerciements}). Dans Guix le
processus de construction et d'installation des paquets est vu comme une
@emph{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 @dfn{conteneurs}) où
seules les entrées explicites sont visibles.
@cindex dépôt
Le résultat des fonctions de construction de paquets est mis en @dfn{cache}
dans le système de fichier, dans répertoire spécial appelé le @dfn{dépôt}
(@pxref{Le dépôt}). Chaque paquet est installé dans son répertoire propre
dans le dépôt — par défaut dans @file{/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 (@pxref{Fonctionnalités}).
@c *********************************************************************
@node Installation
@chapter Installation
@cindex installer Guix
GNU Guix est disponible au téléchargement depuis son site web sur
@url{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,
@pxref{Installation du système}.
@cindex distro extérieure
Lorsqu'il est installé sur an système GNU/Linux existant — ci-après nommé
@dfn{distro extérieure} — GNU@tie{}Guix complète les outils disponibles sans
interférence. Ses données se trouvent exclusivement dans deux répertoires,
typiquement @file{/gnu/store} et @file{/var/guix} ; les autres fichiers de
votre système comme @file{/etc} sont laissés intacts.
Une fois installé, Guix peut être mis à jour en lançant @command{guix pull}
(@pxref{Invoquer guix pull}).
@menu
* 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.
@end menu
@node Installation binaire
@section Installation binaire
@cindex installer Guix depuis les binaires
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@tie{}tar et Xz.
Nous fournissons un script
@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
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 :
@enumerate
@item
@cindex téléchargement du Guix binaire
Téléchargez l'archive binaire depuis
@indicateurl{ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{système}.tar.xz},
où @var{système} est @code{x86_64-linux} pour une machine @code{x86_64} sur
laquelle tourne déjà le noyau Linux, etc.
@c The following is somewhat duplicated in ``System Installation''.
Assurez-vous de télécharger le fichier @file{.sig} associé et de vérifier
l'authenticité de l'archive avec, comme ceci :
@example
$ wget ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{système}.tar.xz.sig
$ gpg --verify guix-binary-@value{VERSION}.@var{système}.tar.xz.sig
@end example
Si cette commande échoue parce que vous n'avez pas la clef publique requise,
lancez cette commande pour l'importer :
@example
$ gpg --keyserver pgp.mit.edu --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
@end example
@noindent
@c end authentication part
et relancez la commande @code{gpg --verify}.
@item
Maintenant, vous devez devenir l'utilisateur @code{root}. En fonction de
votre distribution, vous devrez lancer @code{su -} ou @code{sudo -i}. En
tant que @code{root}, lancez :
@example
# cd /tmp
# tar --warning=no-timestamp -xf \
guix-binary-@value{VERSION}.@var{système}.tar.xz
# mv var/guix /var/ && mv gnu /
@end example
Cela crée @file{/gnu/store} (@pxref{Le dépôt}) and @file{/var/guix}. Ce
deuxième dossier contient un profil pret à être utilisé pour @code{root}
(voir les étapes suivantes).
Ne décompressez @emph{pas} l'archive sur un système Guix lancé car cela
écraserait ses propres fichiers essentiels.
L'option @code{--warning=no-timestamp} s'assure que GNU@tie{}tar ne produise
pas d'avertissement disant que « l'horodatage est trop vieux pour être
plausible » (ces avertissements étaient produits par GNU@tie{}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.
@item
Rendez le profil de @code{root} disponible sous @file{~root/.guix-profile} :
@example
# ln -sf /var/guix/profiles/per-user/root/guix-profile \
~root/.guix-profile
@end example
Sourcez @file{etc/profile} pour augmenter @code{PATH} et les autres
variables d'environnement nécessaires :
@example
# GUIX_PROFILE="`echo ~root`/.guix-profile" ; \
source $GUIX_PROFILE/etc/profile
@end example
@item
Créez le groupe et les comptes utilisateurs pour les utilisateurs de
construction comme expliqué plus loin (@pxref{Réglages de l'environnement de construction}).
@item
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 :
@c Versions of systemd that supported symlinked service files are not
@c yet widely deployed, so we should suggest that users copy the service
@c files into place.
@c
@c See this thread for more information:
@c http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html
@example
# cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \
/etc/systemd/system/
# systemctl start guix-daemon && systemctl enable guix-daemon
@end example
Si votre distribution hôte utilise le système d'initialisation Upstart :
@example
# initctl reload-configuration
# cp ~root/.guix-profile/lib/upstart/system/guix-daemon.conf /etc/init/
# start guix-daemon
@end example
Sinon, vous pouvez toujours démarrer le démon manuellement avec :
@example
# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild
@end example
@item
Rendez la commande @command{guix} disponible pour les autres utilisateurs
sur la machine, par exemple avec :
@example
# mkdir -p /usr/local/bin
# cd /usr/local/bin
# ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix
@end example
C'est aussi une bonne idée de rendre la version Info de ce manuel disponible
ici :
@example
# mkdir -p /usr/local/share/info
# cd /usr/local/share/info
# for i in /var/guix/profiles/per-user/root/guix-profile/share/info/* ;
do ln -s $i ; done
@end example
Comme cela, en supposant que @file{/usr/local/share/info} est dans le chemin
de recherche, lancer @command{info guix} ouvrira ce manuel (@pxref{Other
Info Directories,,, texinfo, GNU Texinfo}, pour plus de détails sur comment
changer le chemin de recherche de Info).
@item
@cindex substituts, autorisations
Pour utiliser les substituts de @code{hydra.gnu.org} ou l'un de ses mirroirs
(@pxref{Substituts}), autorisez-les :
@example
# guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub
@end example
@item
Chaque utilisateur peut avoir besoin d'effectuer des étapes supplémentaires
pour que leur environnement Guix soit prêt à être utilisé,
@pxref{Réglages applicatifs}.
@end enumerate
Voilà, l'installation est terminée !
Vous pouvez confirmer que Guix fonctionne en installant un paquet d'exemple
dans le profil de root :
@example
# guix package -i hello
@end example
Le paquet @code{guix} doit rester disponible dans le profil de @code{root}
ou il pourrait être sujet au ramassage de miettes — dans ce cas vous vous
retrouveriez gravement handicapé par l'absence de la commande
@command{guix}. En d'autres termes, ne supprimez pas @code{guix} en lançant
@code{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 :
@example
make guix-binary.@var{system}.tar.xz
@end example
@noindent
… ce qui à son tour lance :
@example
guix pack -s @var{system} --localstatedir guix
@end example
@xref{Invoquer guix pack}, pour plus d'info sur cet outil pratique.
@node Prérequis
@section 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 @file{README} et @file{INSTALL} dans l'arborescence des sources de
Guix pour plus de détails.
GNU Guix dépend des paquets suivants :
@itemize
@item @url{http://gnu.org/software/guile/, GNU Guile}, version 2.0.13 ou
ultérieure, dont 2.2.x,
@item @url{http://gnupg.org/, GNU libgcrypt},
@item
@uref{http://gnutls.org/, GnuTLS}, en particulier ses liaisons Guile
(@pxref{Guile Preparations, how to install the GnuTLS bindings for Guile,,
gnutls-guile, GnuTLS-Guile}),
@item
@c FIXME: Specify a version number once a release has been made.
@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, d'août 2017 ou
ultérieur,
@item @url{http://zlib.net, zlib},
@item @url{http://www.gnu.org/software/make/, GNU Make}.
@end itemize
Les dépendances suivantes sont facultatives :
@itemize
@item
Installer @url{http://savannah.nongnu.org/projects/guile-json/, Guile-JSON}
vous permettra d'utiliser la commande @command{guix import pypi}
(@pxref{Invoquer guix import}). Il est surtout utile pour les développeurs
et pas pour les utilisateurs occasionnels.
@item
@c Note: We need at least 0.10.2 for 'channel-send-eof'.
Le support pour la décharge de construction (@pxref{Réglages du délestage du démon})
et @command{guix copy} (@pxref{Invoquer guix copy}) dépend de
@uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH}, version
0.10.2 ou ulltérieure.
@item
Lorsque @url{http://www.bzip.org, libbz2} est disponible,
@command{guix-daemon} peut l'utiliser pour compresser les journaux de
construction.
@end itemize
À moins que @code{--disable-daemon} ne soit passé à @command{configure}, les
paquets suivants sont aussi requis :
@itemize
@item @url{http://sqlite.org, SQLite 3},
@item @url{http://gcc.gnu.org, GCC's g++}, avec le support pour le
standard C++11.
@end itemize
@cindex répertoire d'état
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 @code{--localstatedir} du script @command{configure}
(@pxref{Directory Variables, @code{localstatedir},, standards, GNU Coding
Standards}). Le script @command{configure} vous protège des mauvaises
configurations involontaires de @var{localstatedir} pour éviter que vous ne
corrompiez votre dépôt (@pxref{Le dépôt}).
@cindex Nix, compatibilité
Lorsque vous avez une installation fonctionnelle du
@url{http://nixos.org/nix/, gestionnaire de paquets Nix}, vous pouvez
configurer Guix avec @code{--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 à @command{configure} non
seulement la même valeur de @code{--with-store-dir} mais aussi la même
valeur de @code{--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
@code{--with-store-dir=/nix/store} et @code{--localstatedir=/nix/var}.
Remarquez que @code{--disable-daemon} n'est pas requis si votre but est de
partager le dépôt avec Nix.
@node Lancer la suite de tests
@section Lancer la suite de tests
@cindex suite de tests
Après avoir lancé @command{configure} et @code{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 :
@example
make check
@end example
Les cas de tests peuvent être lancés en parallèle : vous pouvez utiliser
l'option @code{-j} de GNU@tie{}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 @code{TESTS} comme dans cet exemple :
@example
make check TESTS="tests/store.scm tests/cpio.scm"
@end example
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 @code{SCM_LOG_DRIVER_FLAGS} comme dans cet
exemple :
@example
make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
@end example
Après un échec, envoyez un courriel à @email{bug-guix@@gnu.org} et attachez
le fichier @file{test-suite.log}. Précisez la version de Guix utilisée
ainsi que les numéros de version de ses dépendances (@pxref{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 :
@example
make check-system
@end example
@noindent
Ou, de nouveau, en définissant @code{TESTS} pour choisir un sous-ensemble
des tests à lancer :
@example
make check-system TESTS="basic mcron"
@end example
Ces tests systèmes sont définis dans les modules @code{(gnu tests
@dots{})}. 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 (@pxref{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 à
@email{bug-guix@@gnu.org}.
@node Paramétrer le démon
@section Paramétrer le démon
@cindex 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
@dfn{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 @command{guix package} et @command{guix build} communiquent
avec le démon (@i{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 @ref{Substituts} pour apprendre comment
permettre le téléchargement de binaires pré-construits.
@menu
* 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.
@end menu
@node Réglages de l'environnement de construction
@subsection Réglages de l'environnement de construction
@cindex environnement de construction
Dans une installation standard multi-utilisateurs, Guix et son démon — le
programme @command{guix-daemon} — sont installé par l'administrateur système
; @file{/gnu/store} appartient à @code{root} et @command{guix-daemon} est
lancé en @code{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.
@cindex utilisateurs de construction
Alors que @command{guix-daemon} tourne en @code{root}, vous n'avez pas
forcément envie que les processus de construction de paquets tournent aussi
en @code{root}, pour des raisons de sécurité évidentes. Pour éviter cela,
vous devriez créer une réserve spéciale d'@dfn{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 @code{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 (@pxref{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
@code{shadow}) :
@c See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html
@c for why `-G' is needed.
@example
# 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
@end example
@noindent
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 @option{--max-jobs} (@pxref{Invoquer guix-daemon,
@option{--max-jobs}}). Pour utiliser @command{guix system vm} et les
commandes liées, vous devrez ajouter les utilisateurs de construction au
groupe @code{kvm} pour qu'ils puissent accéder à @file{/dev/kvm} avec
@code{-G guixbuild,kvm} plutôt que @code{-G guixbuild} (@pxref{Invoquer guix system}).
Le programme @code{guix-daemon} peut ensuite être lancé en @code{root} avec
la commande suivante@footnote{Si votre machine utilise le système
d'initialisation systemd, copiez le fichier
@file{@var{prefix}/lib/systemd/system/guix-daemon.service} dans
@file{/etc/systemd/system} pour vous assurer que @command{guix-daemon} est
démarré automatiquement. De même, si votre machine utilise le système
d'initialisation Upstart, copiez le fichier
@file{@var{prefix}/lib/upstart/system/guix-daemon.conf} dans
@file{/etc/init}.} :
@example
# guix-daemon --build-users-group=guixbuild
@end example
@cindex chroot
@noindent
De cette façon, le démon démarre les processus de construction dans un
chroot, sous un des utilisateurs @code{guixbuilder}. Sur GNU/Linux par
défaut, l'environnement chroot ne contient rien d'autre que :
@c Keep this list in sync with libstore/build.cc! -----------------------
@itemize
@item
un répertoire @code{/dev} minimal, créé presque indépendamment du
@code{/dev} de l'hôte@footnote{« presque », parce que même si l'ensemble des
fichiers qui apparaissent dans le @code{/dev} du chroot sont déterminés à
l'avance, la plupart de ces fichiers ne peut pas être créée si l'hôte ne les
a pas.} ;
@item
le répertoire @code{/proc} ; il ne montre que les processus du conteneur car
on utilise une espace de nom séparé pour les PID ;
@item
@file{/etc/passwd} avec une entrée pour l'utilisateur actuel et une entrée
pour l'utilisateur @file{nobody} ;
@item
@file{/etc/group} avec une entrée pour le groupe de l'utilisateur ;
@item
@file{/etc/hosts} avec une entrée qui fait correspondre @code{localhost} à
@code{127.0.0.1} ;
@item
un répertoire @file{/tmp} inscriptible.
@end itemize
Vous pouvez influencer le répertoire où le démon stocke les arbres de
construction @i{via} la variable d'environnement @code{TMPDIR}. Cependant,
l'arbre de construction dans le chroot sera toujours appelé
@file{/tmp/guix-build-@var{nom}.drv-0}, où @var{nom} est le nom de la
dérivation — p.@: ex.@: @code{coreutils-8.24}. De cette façon, la valeur de
@code{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.
@vindex http_proxy
Le démon tient aussi compte de la variable d'environnement @code{http_proxy}
pour ses téléchargements HTTP, que ce soit pour les dérivations à sortie
fixes (@pxref{Dérivations}) ou pour les substituts (@pxref{Substituts}).
Si vous installez Guix en tant qu'utilisateur non-privilégié, il est
toujours possible de lancer @command{guix-daemon} si vous passez
@code{--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
@emph{pures}.
@node Réglages du délestage du démon
@subsection Utiliser le dispositif de déchargement
@cindex déchargement
@cindex crochet de construction
Si vous le souhaitez, le démon de construction peut @dfn{décharger} des
constructions de dérivations sur d'autres machines Guix avec le @dfn{crochet
de construction} @code{offload}@footnote{Cette fonctionnalité n'est
disponible que si @uref{https://github.com/artyom-poptsov/guile-ssh,
Guile-SSH} est présent.}. Lorsque cette fonctionnalité est activée, Guix
lit une liste de machines de constructions spécifiée par l'utilisateur dans
@file{/etc/guix/machines.scm} ; à chaque fois qu'une construction est
demandée, par exemple par @code{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.@: @file{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 @file{/etc/guix/machines.scm} ressemble typiquement à cela :
@example
(list (build-machine
(name "eightysix.example.org")
(system "x86_64-linux")
(host-key "ssh-ed25519 AAAAC3Nza@dots{}")
(user "bob")
(speed 2.)) ;très rapide !
(build-machine
(name "meeps.example.org")
(system "mips64el-linux")
(host-key "ssh-rsa AAAAB3Nza@dots{}")
(user "alice")
(private-key
(string-append (getenv "HOME")
"/.ssh/identity-for-guix"))))
@end example
@noindent
Dans l'exemple ci-dessus nous spécifions une liste de deux machines de
construction, une pour l'architecture @code{x86_64} et une pour
l'architecture @code{mips64el}.
En fait, ce fichier est — et ça ne devrait pas vous surprendre ! — un
fichier Scheme qui est évalué au démarrage du crochet @code{offload}. Sa
valeur de retour doit être une liste d'objets @code{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
(@pxref{Introduction, Guile-Avahi,, guile-avahi, Using Avahi in Guile Scheme
Programs}). Le type de données @code{build-machine} est détaillé plus bas.
@deftp {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 :
@table @code
@item name
Le nom d'hôte de la machine distante.
@item system
Le type de système de la machine distante, p.@: ex.@: @code{"x86_64-linux"}.
@item user
Le compte utilisateur à utiliser lors de la connexion à la machine distante
par SSH@. Remarquez que la paire de clef SSH ne doit @emph{pas} être
protégée par mot de passe pour permettre des connexions non-interactives.
@item host-key
Cela doit être la @dfn{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 :
@example
ssh-ed25519 AAAAC3NzaC@dots{}mde+UhL hint@@example.org
@end example
Si la machine utilise le démon OpenSSH, @command{sshd}, la clef d'hôte se
trouve dans un fichier comme @file{/etc/ssh/ssh_host_ed25519_key.pub}.
Si la machine utilise le démon SSH de GNU@tie{}lsh, la clef d'hôte est dans
@file{/etc/lsh/host-key.pub} ou un fichier similaire. Elle peut être
convertie au format OpenSSH avec @command{lsh-export-key}
(@pxref{Converting keys,,, lsh, LSH Manual}) :
@example
$ lsh-export-key --openssh < /etc/lsh/host-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV@dots{}
@end example
@end table
Il y a un certain nombre de champs facultatifs que vous pouvez remplir :
@table @asis
@item @code{port} (par défaut : @code{22})
Numéro de port du serveur SSH sur la machine.
@item @code{private-key} (par défaut : @file{~root/.ssh/id_rsa})
Le fichier de clef privée à utiliser lors de la connexion à la machine, au
format OpenSSH@.
Remarquez que la valeur par défaut est la clef privée @emph{du compte
root}. Assurez-vous qu'elle existe si vous utilisez la valeur par défaut.
@item @code{compression} (par défaut : @code{"zlib@@openssh.com,zlib"})
@itemx @code{compression-level} (par défaut : @code{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.
@item @code{daemon-socket} (par défaut : @code{"/var/guix/daemon-socket/socket"})
Le nom de fichier du socket Unix-domain sur lequel @command{guix-daemon}
écoute sur cette machine.
@item @code{parallel-builds} (par défaut : @code{1})
Le nombre de constructions qui peuvent tourner simultanément sur la machine.
@item @code{speed} (par défaut : @code{1.0})
Un « facteur de vitesse relatif ». L'ordonnanceur des constructions tendra
à préférer les machines avec un plus grand facteur de vitesse.
@item @code{features} (par défaut : @code{'()})
Une liste de chaînes qui contient les fonctionnalités spécifiques supportées
par la machine. Un exemple est @code{"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.
@end table
@end deftp
La commande @code{guile} doit être dans le chemin de recherche des machines
de construction. En plus, les modules Guix doivent se trouver dans
@code{$GUILE_LOAD_PATH} sur la machine de construction. Vous pouvez
vérifier si c'est le cas en lançant :
@example
ssh build-machine guile -c "'(use-modules (guix config))'"
@end example
Il reste une dernière chose à faire maintenant que @file{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
(@pxref{Invoquer guix archive}) :
@example
# guix archive --generate-key
@end example
@noindent
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 :
@example
# guix archive --authorize < master-public-key.txt
@end example
@noindent
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.
@cindex test du déchargement
Pour tester que votre paramétrage fonctionne, lancez cette commande sur le
nœud maître :
@example
# guix offload test
@end example
Cela essaiera de se connecter à toutes les machines de construction
spécifiées dans @file{/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 :
@example
# guix offload test machines-qualif.scm
@end example
Enfin, vous pouvez tester un sous-ensemble de machines dont le nom
correspond à une expression rationnelle comme ceci :
@example
# guix offload test machines.scm '\.gnu\.org$'
@end example
@cindex statut du déchargement
Pour afficher la charge actuelle de tous les hôtes de construction, lancez
cette commande sur le nœud principal :
@example
# guix offload status
@end example
@node Support de SELinux
@subsection Support de SELinux
@cindex SELinux, politique du démon
@cindex contrôle d'accès obligatoire, SELinux
@cindex sécurité, guix-daemon
Guix inclus un fichier de politique SELniux dans @file{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@.
@subsubsection Installer la politique SELinux
@cindex SELinux, installation de la politique
Pour installer la politique, lancez cette commande en root :
@example
semodule -i etc/guix-daemon.cil
@end example
Puis ré-étiquetez le système de fichier avec @code{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
@code{guix_daemon_t}. Vous pouvez le confirmer avec la commande suivante :
@example
ps -Zax | grep guix-daemon
@end example
Surveillez les fichiers journaux de SELinux pendant que vous lancez une
commande comme @code{guix build hello} pour vous convaincre que SELniux
permet toutes les opérations nécessaires.
@subsubsection Limitations
@cindex SELinux, limites
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.
@enumerate
@item
@code{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 @code{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.
@item
@code{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 @code{user_home_t}.
Mais pour les liens du répertoire personnel de l'utilisateur root, ou
@file{/tmp}, ou du répertoire de travail du serveur HTTP, etc, cela ne
fonctionnera pas. SELinux empêcherait @code{guix gc} de lire et de suivre
ces liens.
@item
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.
@item
Actuellement tous les fichiers qui correspondent à l'expression rationnelle
@code{/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon} reçoivent l'étiquette
@code{guix_daemon_exec_t} ; cela signifie que @emph{tout} fichier avec ce
nom dans n'importe quel profil serait autorisé à se lancer dans le domaine
@code{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
@code{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 @emph{exacts} de l'exécutable
@code{guix-daemon} actuellement installé soit étiqueté avec
@code{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 @code{guix-daemon} effectivement exécuté est mis à
jour.
@end enumerate
@node Invoquer guix-daemon
@section Invoquer @command{guix-daemon}
Le programme @command{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 @code{root} comme ceci :
@example
# guix-daemon --build-users-group=guixbuild
@end example
@noindent
Pour des détails sur son paramétrage, @pxref{Paramétrer le démon}.
@cindex chroot
@cindex conteneur, environnement de construction
@cindex environnement de construction
@cindex constructions reproductibles
Par défaut, @command{guix-daemon} lance les processus de construction sous
différents UID récupérés depuis le groupe de construction spécifié avec
@code{--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 (@pxref{Interface de programmation, dérivation}), plus un
ensemble de répertoires systèmes spécifiques. Par défaut ce dernier
contient @file{/dev} et @file{/dev/pts}. De plus, sous GNU/Linux,
l'environnement de construction est un @dfn{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 (@pxref{Fonctionnalités}).
Lorsque le démon effectue une construction pour le compte de l'utilisateur,
il crée un répertoire sous @file{/tmp} ou sous le répertoire spécifié par sa
variable d'environnement @code{TMPDIR}. Ce répertoire est partagé avec le
conteneur pendant la durée de la construction. Soyez conscient qu'utiliser
un répertoire différent de @file{/tmp} peut affecter les résultats de la
construction — par exemple avec un nom de répertoire plus long, un processus
de construction qui utiliserait des socket Unix-domain pourrait atteindre la
limite de longueur de nom de fichier pour @code{sun_path}, qu'il n'aurait
sinon pas atteinte.
Le répertoire de construction est automatiquement supprimé à la fin, à moins
que la construction n'ait échoué et que le client ait spécifié
@option{--keep-failed} (@pxref{Invoquer guix build,
@option{--keep-failed}}).
Les options en ligne de commande suivantes sont disponibles :
@table @code
@item --build-users-group=@var{groupe}
Prendre les utilisateurs de @var{group} pour lancer les processus de
construction (@pxref{Paramétrer le démon, utilisateurs de construction}).
@item --no-substitutes
@cindex substituts
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 (@pxref{Substituts}).
Lorsque le démon tourne avec @code{--no-substitutes}, les clients peuvent
toujours activer explicitement la substitution @i{via} l'appel de procédure
distante @code{set-build-options} (@pxref{Le dépôt}).
@item --substitute-urls=@var{urls}
@anchor{daemon-substitute-urls}
Considèrer @var{urls} comme la liste séparée par des espaces des URL des
sources de substituts par défaut. Lorsque cette option est omise,
@indicateurl{https://mirror.hydra.gnu.org https://hydra.gnu.org} est utilisé
(@code{mirror.hydra.gnu.org} est un mirroire de @code{hydra.gnu.org}).
Cela signifie que les substituts sont téléchargés depuis les @var{urls},
tant qu'ils sont signés par une signature de confiance (@pxref{Substituts}).
@cindex crochet de construction
@item --no-build-hook
Ne pas utiliser le @dfn{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 (@pxref{Réglages du délestage du démon}).
@item --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, @command{guix gc --list-failures} peut
être utilisé pour demander l'ensemble des éléments du dépôt marqués comme
échoués ; @command{guix gc --clear-failures} vide la liste des éléments
aillant échoué. @xref{Invoquer guix gc}.
@item --cores=@var{n}
@itemx -c @var{n}
Utiliser @var{n} cœurs CPU pour construire chaque dérivation ; @code{0}
signifie autant que possible.
La valeur par défaut est @code{0}, mais elle peut être modifiée par les
clients comme avec l'option @code{--cores} de @command{guix build}
(@pxref{Invoquer guix build}).
L'effet est de définir la variable d'environnement @code{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 @code{make
-j$NIX_BUILD_CORES}.
@item --max-jobs=@var{n}
@itemx -M @var{n}
Permettre au plus @var{n} travaux de construction en parallèle. La valeur
par défaut est @code{1}. La mettre à @code{0} signifie qu'aucune
construction ne sera effectuée localement ; à la place, le démon déchargera
les constructions (@pxref{Réglages du délestage du démon}) ou échouera.
@item --max-silent-time=@var{secondes}
Lorsque le processus de construction ou de substitution restent silencieux
pendant plus de @var{secondes}, le terminer et rapporter une erreur de
construction.
La valeur par défaut est @code{0}, ce qui désactive le délai.
La valeur spécifiée ici peut être modifiée par les clients (@pxref{Options de construction communes, @code{--max-silent-time}}).
@item --timeout=@var{secondes}
De même, lorsque le processus de construction ou de substitution dure plus
de @var{secondes}, le terminer et rapporter une erreur de construction.
La valeur par défaut est @code{0}, ce qui désactive le délai.
La valeur spécifiée ici peut être modifiée par les clients (@pxref{Options de construction communes, @code{--timeout}}).
@item --rounds=@var{N}
Construire chaque dérivations @var{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 @command{guix build} (@pxref{Invoquer guix build}).
Lorsqu'utilisé avec @option{--keep-failed}, la sourtie différente est gardée
dans le dépôt sous @file{/gnu/store/@dots{}-check}. Cela rend plus facile
l'étude des différences entre les deux résultats.
@item --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
@code{--verbosity} de @command{guix build} (@pxref{Invoquer guix build}).
@item --chroot-directory=@var{rép}
Ajouter @var{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 @var{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.
@item --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 @command{guix-daemon} tourne en tant
qu'utilisateur non privilégié.
@item --log-compression=@var{type}
Compresser les journaux de construction suivant le @var{type}, parmi
@code{gzip}, @code{bzip2} ou @code{none}.
À moins que @code{--lose-logs} ne soit utilisé, tous les journaux de
construction sont gardés dans @var{localstatedir}. Pour gagner de la place,
le démon les compresse automatiquement avec bzip2 par défaut.
@item --disable-deduplication
@cindex déduplication
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.
@item --gc-keep-outputs[=yes|no]
Dire si le ramasse-miettes (GC) doit garder les sorties des dérivations
utilisées.
@cindex racines du GC
@cindex racines du ramasse-miettes
Lorsqu'elle est à « yes », le GC gardera les sorties de toutes les
dérivations — les fichiers @code{.drv} — utilisées 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 s'il s'agit de racines du GC@. @xref{Invoquer guix gc}
pour plus d'informations sur les racines du GC@.
@item --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 @file{.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.
Remarquez qu'avec @code{--gc-keep-derivations} et @code{--gc-keep-outputs},
le GC gardera tous les prérequis de construction (les sources, le
compilateur, les bibliothèques, et les autres outils de construction) des
objets utilisés dans le dépôt, indépendamment du fait qu'ils soient ou non
utilisés. Cela est pratique pour les développeurs car ça leur fait gagner
du temps de reconstruction et de téléchargement.
@item --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 @code{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.
@item --lose-logs
Ne pas garder les journaux de construction. Par défaut ils sont gardés dans
@code{@var{localstatedir}/guix/log}.
@item --system=@var{système}
Supposer que @var{système} est le type de système actuel. Par défaut c'est
la paire architecture-noyau trouvée à la configuration, comme
@code{x86_64-linux}.
@item --listen=@var{extrémité}
Écouter les connexions sur @var{extrémité}. @var{extrémité} est interprété
comme un nom de fichier d'un socket Unix-domain s'il commence par @code{/}
(barre oblique). Sinon, @var{extrémité} est interprété comme un nom de
domaine ou d'hôte et un port sur lequel écouter. Voici quelques exemples :
@table @code
@item --listen=/gnu/var/daemon
Écouter les connexions sur le socket Unix-domain @file{/gnu/var/daemon} en
le créant si besoin.
@item --listen=localhost
@cindex démon, accès distant
@cindex accès distant au démon
@cindex démon, paramètres de grappes
@cindex grappes, paramètres du démon
Écouter les connexions TCP sur l'interface réseau correspondant à
@code{localhost} sur le port 44146.
@item --listen=128.0.0.42:1234
Écouter les connexions TCP sur l'interface réseau correspondant à
@code{128.0.0.42} sur le port 1234.
@end table
Cette option peut être répétée plusieurs fois, auquel cas
@command{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
@code{GUIX_DAEMON_SOCKET} (@pxref{Le dépôt, @code{GUIX_DAEMON_SOCKET}}).
@quotation Remarque
Le protocole du démon est @emph{non authentifié et non chiffré}. Utiliser
@code{--listen=@var{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@.
@end quotation
Lorsque @code{--listen} est omis, @command{guix-daemon} écoute les
connexions sur le socket Unix-domain situé à
@file{@var{localstatedir}/guix/daemon-socket/socket}.
@end table
@node Réglages applicatifs
@section Réglages applicatifs
@cindex distro extérieure
Lorsque vous utilisez Guix par dessus une distribution GNU/Linux différente
de GuixSD — ce qu'on appelle une @dfn{distro externe} — quelques étapes
supplémentaires sont requises pour que tout soit en place. En voici
certaines.
@subsection Régionalisation
@anchor{locales-and-locpath}
@cindex régionalisation, en dehors de GuixSD
@vindex LOCPATH
@vindex GUIX_LOCPATH
Les paquets installés @i{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 @code{GUIX_LOCPATH} :
@example
$ guix package -i glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
@end example
Remarquez que le paquet @code{glibc-locales} contient les données pour tous
les environnement linguistiques supportés par la GNU@tie{}libc et pèse
environ 110@tie{}Mo. Autrement, les @code{glibc-utf8-locales} est plus
petit mais limité à quelques environnements UTF-8.
La variable @code{GUIX_LOCPATH} joue un rôle similaire à @code{LOCPATH}
(@pxref{Locale Names, @code{LOCPATH},, libc, The GNU C Library Reference
Manual}). Il y a deux différences importantes cependant :
@enumerate
@item
@code{GUIX_LOCPATH} n'est compris que par la libc dans Guix et pas par la
libc fournie par les distros externes. Ainsi, utiliser @code{GUIX_LOCPATH}
vous permet de vous assurer que les programmes de la distro externe ne
chargeront pas de données linguistiques incompatibles.
@item
La libc ajoute un suffixe @code{/X.Y} à chaque entrée de
@code{GUIX_LOCPATH}, où @code{X.Y} est la version de la libc — p.@: ex.@:
@code{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.
@end enumerate
Cela est important car le format des données linguistiques utilisés par
différentes version de la libc peuvent être incompatibles.
@subsection Name Service Switch
@cindex name service switch, glibc
@cindex NSS (name service switch), glibc
@cindex nscd (name service caching daemon)
@cindex name service caching daemon (nscd)
Lorsque vous utilisez Guix sur une distro externe, nous @emph{recommandons
fortement} que ce système fasse tourner le @dfn{démon de cache de service de
noms} de la bibliothèque C de GNU, @command{nscd}, qui devrait écouter sur
le socket @file{/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.
@cindex @file{nsswitch.conf}
La bibliothèque C de GNU implémente un @dfn{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 (@pxref{Name Service Switch,,, libc, The GNU C Library Reference Manual}).
@cindex Network information service (NIS)
@cindex NIS (Network information service)
Comme il est extensible, NSS supporte des @dfn{greffons} qui fournissent une
nouvelle implémentation de résolution de nom : par exemple le greffon
@code{nss-mdns} permet la résolution de noms d'hôtes en @code{.local}, le
greffon @code{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
@file{/etc/nsswitch.conf}, et tous les programmes qui tournent sur ce
système honorent ces paramètres (@pxref{NSS Configuration File,,, libc, The
GNU C Reference Manual})
Lorsqu'ils essayent d'effectuer une résolution de nom — par exemple en
appelant la fonction @code{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 @file{libnns_*.so} — sont @code{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, @code{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 @command{nscd} sur le système, entre autres avantages, élimine ce
problème d'incompatibilité binaire car ces fichiers @code{libnss_*.so} sont
chargés par le processus @command{nscd}, pas par l'application elle-même.
@subsection Polices X11
@cindex polices
La majorité des applications graphiques utilisent fontconfig pour trouver et
charger les police et effectuer le rendu côté client X11. Le paquet
@code{fontconfig} dans Guix cherche les polices dans
@file{$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 @code{gs-fonts}, @code{font-dejavu} et
@code{font-gnu-freefont-ttf}.
Pour afficher des textes écrits en chinois, en japonais ou en coréen dans
les applications graphiques, installez @code{font-adobe-source-han-sans} ou
@code{font-wqy-zenhei}. Le premier a plusieurs sorties, une par famille de
langue (@pxref{Des paquets avec plusieurs résultats}). Par exemple, la commande
suivante installe les polices pour le chinois :
@example
guix package -i font-adobe-source-han-sans:cn
@end example
@cindex @code{xterm}
Les vieux programmes comme @command{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 :
@example
-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1
@end example
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 :
@c Note: 'xset' does not accept symlinks so the trick below arranges to
@c get at the real directory. See <https://bugs.gnu.org/30655>.
@example
xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))
@end example
@cindex @code{xlsfonts}
Ensuite, vous pouvez lancer @code{xlsfonts} (du paquet @code{xlsfonts}) pour
vous assurer que vos polices TrueType y sont listées.
@cindex @code{fc-cache}
@cindex cache de polices
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 @code{fc-cache -f}. La commande @code{fc-cache} est fournie par le
paquet @code{fontconfig}.
@subsection Certificats X.509
@cindex @code{nss-certs}
Le paquet @code{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. @xref{Certificats X.509}, pour des informations détaillées.
@subsection Paquets emacs
@cindex @code{emacs}
Lorsque vous installez les paquets Emacs avec Guix, les fichiers elisp
peuvent être placés soit dans
@file{$HOME/.guix-profile/share/emacs/site-lisp/} soit dans des
sous-répertoires de
@file{$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 (@pxref{Package Files,,, emacs,
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
@code{--no-site-file} (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
@subsection La chaîne d'outils GCC
@cindex GCC
@cindex ld-wrapper
Guix offre des paquets de compilateurs individuels comme @code{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 @code{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 @code{debug}), Binutils et une enveloppe
pour l'éditeur de liens.
@cindex tentative d'utiliser une bibliothèque impure, message d'erreur
Le rôle de l'enveloppe est d'inspecter les paramètres @code{-L} et @code{-l}
passés à l'éditeur de liens, d'ajouter des arguments @code{-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
@code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES}.
@c TODO What else?
@c *********************************************************************
@node Gestion de paquets
@chapter Gestion de paquets
@cindex 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 (@pxref{Invoquer guix package,
@code{guix package}}), vous pouvez aussi utiliser l'interface Emacs-Guix
(@pxref{Top,,, emacs-guix, Le manuel de référence de emacs-guix}), après
avoir installé le paquet @code{emacs-guix} (lancez la commande @kbd{M-x
guix-help} pour le démarrer) :
@example
guix package -i emacs-guix
@end example
@menu
* 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.
* Invoquer guix pack:: Créer des lots de logiciels.
* Invoquer guix archive:: Exporter et importer des fichiers du dépôt.
@end menu
@node Fonctionnalités
@section Fonctionnalités
Lorsque vous utilisez Guix, chaque paquet arrive dans @dfn{dépôt des
paquets}, dans son propre répertoire — quelque chose comme
@file{/gnu/store/xxx-paquet-1.2}, où @code{xxx} est une chaîne en base32.
Plutôt que de se rapporter à ces répertoires, les utilisateurs ont leur
propre @dfn{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 @code{$HOME/.guix-profile}.
Par exemple, @code{alice} installe GCC 4.7.2. Il en résulte que
@file{/home/alice/.guix-profile/bin/gcc} pointe vers
@file{/gnu/store/@dots{}-gcc-4.7.2/bin/gcc}. Maintenant, sur la même
machine, @code{bob} a déjà intallé GCC 4.8.0. Le profil de @code{bob}
continue simplement de pointer vers
@file{/gnu/store/@dots{}-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 @command{guix package} est l'outil central pour gérer les
paquets (@pxref{Invoquer guix package}). Il opère sur les profils
utilisateurs et peut être utilisé avec les @emph{privilèges utilisateurs
normaux}.
@cindex transactions
La commande fournit les opérations évidentes d'installation, de suppression
et de mise à jour. Chaque invocation est en fait une @emph{transaction} :
soit l'opération demandée réussi, soit rien ne se passe. Ainsi, si le
processus @command{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 @emph{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
(@pxref{Utiliser le système de configuration}).
Tous les paquets du dépôt des paquets peut être @emph{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 (@pxref{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.
@cindex reproductibilité
@cindex constructions reproductibles
Finalement, Guix prend une approche @dfn{purement fonctionnelle} de la
gestion de paquets, telle que décrite dans l'introduction
(@pxref{Introduction}). Chaque nom de répertoire de paquet dans
@file{/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 @dfn{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 (@pxref{Invoquer guix-daemon, container}).
@cindex substituts
Ce fondement permet à Guix de supporter le @dfn{déploiement transparent de
binaire ou source}. Lorsqu'une binaire pré-construit pour une entrée de
@file{/gnu/store} est disponible depuis une source externe (un
@dfn{substitut}), Guix le télécharge simplement et le décompresse ; sinon,
il construit le paquet depuis les sources localement (@pxref{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
@emph{défier} les fournisseurs (@pxref{Invoquer guix challenge}).
Le contrôle de l'environnement de construction est aussi une fonctionnalité
utile pour les développeurs. La commande @command{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 (@pxref{Invoquer guix environment}).
@node Invoquer guix package
@section Invoquer @command{guix package}
@cindex installer des paquets
@cindex supprimer des paquets
@cindex installation de paquets
@cindex suppression de paquets
La commande @command{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
(@pxref{Fonctionnalités}). Sa syntaxe est :
@example
guix package @var{options}
@end example
@cindex transactions
@var{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
@dfn{générations} précédentes du profil restent disponibles si l'utilisateur
souhaite y revenir.
Par exemple, pour supprimer @code{lua} et installer @code{guile} et
@code{guile-cairo} en une seule transaction :
@example
guix package -r lua -i guile guile-cairo
@end example
@command{guix package} supporte aussi une @dfn{approche déclarative} où
l'utilisateur spécifie l'ensemble exact des paquets qui doivent être
disponibles le passe @i{via} l'option @option{--manifest}
(@pxref{profile-manifest, @option{--manifest}}).
@cindex profil
Pour chaque utilisateur, un lien symbolique vers le profil par défaut de cet
utilisateur est automatiquement créé dans @file{$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
@file{$HOME/.guix-profile/bin} à leur variable d'environnement @code{PATH}
etc.
@cindex chemins de recherche
Si vous n'utilisez pas la distribution système Guix, vous devriez ajouter
les lignes suivantes à votre @file{~/.bash_profile} (@pxref{Bash Startup
Files,,, bash, The GNU Bash Reference Manual}) pour que les shells créés
ensuite aient les bonnes définitions des variables d'environnement :
@example
GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$HOME/.guix-profile/etc/profile"
@end example
Dans un environnement multi-utilisateur, les profils utilisateurs sont
stockés comme une @dfn{racine du ramasse-miettes}, vers laquelle pointe
@file{$HOME/.guix-profile} (@pxref{Invoquer guix gc}). Ce répertoire est
normalement
@code{@var{localstatedir}/guix/profiles/per-user/@var{utilisateur}}, où
@var{localstatedir} est la valeur passée à @code{configure} avec
@code{--localstatedir} et @var{utilisateur} le nom d'utilisateur. Le
répertoire @file{per-user} est créé lorsque @command{guix-daemon} est
démarré et sous-répertoire @var{utilisateur} est créé par @command{guix
package}.
Les @var{options} peuvent être les suivante :
@table @code
@item --install=@var{paquet} @dots{}
@itemx -i @var{paquet} @dots{}
Installer les @var{paquet}s spécifiés.
Chaque @var{paquet} peut spécifier soit un simple nom de paquet, comme
@code{guile} ou un nom de paquet suivi d'un arobase et d'un numéro de
version, comme @code{guile@@1.8.8} ou simplement @code{guile@@1.8} (dans ce
dernier cas, la version la plus récente commençant par @code{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, @var{paquet} peut contenir un deux-points,
suivi du nom d'une des sorties du paquet, comme dans @code{gcc:doc} ou
@code{binutils@@2.22:lib} (@pxref{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 (@pxref{Modules de paquets}).
@cindex entrées propagées
Parfois les paquets ont des @dfn{entrées propagées} : ce sont des
dépendances qui sont installées automatiquement avec le paquet demandé
(@pxref{package-propagated-inputs, @code{propagated-inputs} in
@code{package} objects} pour plus d'informations sur les entrées propagées
dans les définitions des paquets).
@anchor{package-cmd-propagated-inputs}
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
@code{--search-paths} plus bas). Toute définition de variable
d'environnement manquante ou possiblement incorrecte est rapportée ici.
@item --install-from-expression=@var{exp}
@itemx -e @var{exp}
Installer le paquet évalué par @var{exp}
@var{exp} doit être une expression Scheme qui s'évalue en un objet
@code{<package>}. Cette option est notamment utile pour distinguer les
variantes d'un paquet avec le même nom, avec des expressions comme @code{(@@
(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.
@item --install-from-file=@var{fichier}
@itemx -f @var{fichier}
Installer le paquet évalué par le code dans le @var{fichier}.
Par exemple, @var{fichier} peut contenir une définition comme celle-ci
(@pxref{Définition des paquets}) :
@example
@verbatiminclude package-hello.scm
@end example
Les développeurs peuvent trouver utile d'inclure un tel fichier
@file{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 (@pxref{Invoquer guix environment}).
@item --remove=@var{paquet} @dots{}
@itemx -r @var{paquet} @dots{}
Supprimer les @var{paquet}s spécifiés.
Comme pour @code{--install}, chaque @var{paquet} peut spécifier un numéro de
version ou un nom de sortie en plus du nom du paquet. Par exemple, @code{-r
glibc:debug} supprimerait la sortie @code{debug} de @code{glibc}.
@item --upgrade[=@var{regexp} @dots{}]
@itemx -u [@var{regexp} @dots{}]
@cindex mettre à jour des paquets
Mettre à jour tous les paquets installés. Si une @var{regexp} ou plus est
spécifiée, la mise à jour n'installera que les paquets dont le nom
correspond à @var{regexp}. Voyez aussi l'option @code{--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 @command{guix pull}
(@pxref{Invoquer guix pull}).
@item --do-not-upgrade[=@var{regexp} @dots{}]
Lorsqu'elle est utilisée avec l'option @code{--upgrade}, ne @emph{pas}
mettre à jour les paquets dont le nom correspond à @var{regexp}. Par
exemple, pour mettre à jour tous les paquets du profil actuel à l'exception
de ceux qui contiennent la chaîne « emacs » :
@example
$ guix package --upgrade . --do-not-upgrade emacs
@end example
@item @anchor{profile-manifest}--manifest=@var{fichier}
@itemx -m @var{fichier}
@cindex déclaration de profil
@cindex manifest de profil
Créer une nouvelle génération du profil depuis l'objet manifeste renvoyé par
le code Scheme dans @var{fichier}.
Cela vous permet de @emph{déclarer} le contenu du profil plutôt que de le
construire avec une série de @code{--install} et de commandes similaires.
L'avantage étant que le @var{fichier} peut être placé sous contrôle de
version, copié vers d'autres machines pour reproduire le même profil, etc.
@c FIXME: Add reference to (guix profile) documentation when available.
@var{fichier} doit retourner un objet @dfn{manifest} qui est en gros une
liste de paquets :
@findex packages->manifest
@example
(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")))
@end example
@findex specifications->manifest
Dans cet exemple on doit savoir quels modules définissent les variables
@code{emacs} et @code{guile-2.0} pour fournir la bonne ligne
@code{use-package-modules} ce qui peut être embêtant. On peut à la place
fournir des spécifications de paquets normales et laisser
@code{specifications->manifest} rechercher les objets de paquets
correspondants, comme ceci :
@example
(specifications->manifest
'("emacs" "guile@@2.2" "guile@@2.2:debug"))
@end example
@item --roll-back
@cindex revenir en arrière
@cindex défaire des transactions
@cindex transactions, défaire
Revenir à la @dfn{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 @code{--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 @dfn{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.
@item --switch-generation=@var{motif}
@itemx -S @var{motif}
@cindex générations
Basculer vers une génération particulière définie par le @var{motif}.
Le @var{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 @code{--roll-back}, utilisez
@code{--switch-generation=+1}.
La différence entre @code{--roll-back} et @code{--switch-generation=-1} est
que @code{--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.
@item --search-paths[=@var{genre}]
@cindex chemins de recherche
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 @dfn{chemins
de recherche} de fichiers utilisés par les paquets installés.
Par exemple, GCC a besoin des variables d'environnement @code{CPATH} et
@code{LIBRARY_PATH} pour trouver les en-têtes et les bibliothèques dans le
profil de l'utilisateur (@pxref{Environment Variables,,, gcc, Using the GNU
Compiler Collection (GCC)}). Si GCC et, disons, la bibliothèque C sont
installés dans le profil, alors @code{--search-paths} suggérera
d'initialiser ces variables à @code{@var{profil}/include} et
@code{@var{profil}/lib}, respectivement.
Le cas d'utilisation typique est de définir ces variables d'environnement
dans le shell :
@example
$ eval `guix package --search-paths`
@end example
@var{genre} peut être l'une des valeurs @code{exact}, @code{prefix} ou
@code{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,
@var{genre} a pour valeur par défaut @code{exact}.
Cette option peut aussi être utilisé pour calculer les chemins de recherche
@emph{combinés} de plusieurs profils. Regardez cet exemple :
@example
$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths
@end example
La dernière commande ci-dessus montre la variable @code{GUILE_LOAD_PATH}
bien que, pris individuellement, ni @file{foo} ni @file{bar} n'auraient
donné cette recommendation.
@item --profile=@var{profil}
@itemx -p @var{profil}
Utiliser le @var{profil} à la place du profil par défaut de l'utilisateur.
@cindex collisions, dans un profil
@cindex faire des collisions de paquets dans des profils
@cindex profil, collisions
@item --allow-collisions
Permettre des collisions de paquets dans le nouveau profil. À utiliser à
vos risques et périls !
Par défaut, @command{guix package} rapporte les @dfn{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.
@item --verbose
Produire une sortie verbeuse. En particulier, fournir les journaux de
construction de l'environnement sur le port d'erreur standard.
@item --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.
@end table
En plus de ces actions, @command{guix package} supporte les options
suivantes pour demander l'état actuel d'un profil ou la disponibilité des
paquets :
@table @option
@item --search=@var{regexp}
@itemx -s @var{regexp}
@cindex chercher des paquets
Lister les paquets disponibles dont le nom, le synopsis ou la description
correspondent à la @var{regexp}, triés par pertinence. Afficher toutes les
métadonnées des paquets correspondants au format @code{recutils}
(@pxref{Top, GNU recutils databases,, recutils, GNU recutils manual}).
Cela permet à des champs spécifiques d'être extraits avec la commande
@command{recsel}, par exemple :
@example
$ 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
@end example
De manière similaire, pour montrer le nom de tous les paquets disponibles
sous license GNU@tie{}LGPL version 3 :
@example
$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils
name: gmp
@dots{}
@end example
Il est aussi possible de raffiner les résultats de la recherche avec
plusieurs options @code{-s}. Par exemple, la commande suivante renvoie la
liste des jeux de plateau :
@example
$ guix package -s '\<board\>' -s game | recsel -p name
name: gnubg
@dots{}
@end example
Si on avait oublié @code{-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 @code{board} aurait aussi ajouté les paquets qui
parlent de clavier (en anglais : key@emph{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 :
@example
$ guix package -s crypto -s library | \
recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis
@end example
@noindent
@xref{Selection Expressions,,, recutils, GNU recutils manual} pour plus
d'information sur les @dfn{expressions de sélection} pour @code{recsel -e}.
@item --show=@var{paquet}
Afficher les détails du @var{paquet} dans la liste des paquets disponibles,
au format @code{recutils} (@pxref{Top, GNU recutils databases,, recutils,
GNU recutils manual}).
@example
$ guix package --show=python | recsel -p name,version
name: python
version: 2.7.6
name: python
version: 3.3.5
@end example
Vous pouvez aussi spécifier le nom complet d'un paquet pour n'avoir que les
détails concernant une version spécifique :
@example
$ guix package --show=python@@3.4 | recsel -p name,version
name: python
version: 3.4.3
@end example
@item --list-installed[=@var{regexp}]
@itemx -I [@var{regexp}]
List the currently installed packages in the specified profile, with the
most recently installed packages shown last. When @var{regexp} is
specified, list only installed packages whose name matches @var{regexp}.
For each installed package, print the following items, separated by tabs:
the package name, its version string, the part of the package that is
installed (for instance, @code{out} for the default output, @code{include}
for its headers, etc.), and the path of this package in the store.
@item --list-available[=@var{regexp}]
@itemx -A [@var{regexp}]
Lister les paquets actuellement disponibles dans la distribution pour ce
système (@pxref{Distribution GNU}). Lorsque @var{regexp} est spécifié,
liste uniquement les paquets dont le nom correspond à @var{regexp}.
For each package, print the following items separated by tabs: its name, its
version string, the parts of the package (@pxref{Des paquets avec plusieurs résultats}), and the source location of its definition.
@item --list-generations[=@var{motif}]
@itemx -l [@var{motif}]
@cindex générations
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 (@pxref{Des paquets avec plusieurs résultats}), et l'emplacement du
paquet dans le dépôt.
Lorsque @var{motif} est utilisé, la commande ne renvoie que les générations
correspondantes. Les motifs valides sont :
@itemize
@item @emph{Des entiers et des entiers séparés par des virgules}. Les deux motifs correspondent
à des numéros de version. Par exemple, @code{--list-generations=1} renvoie
la première.
Et @code{--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.
@item @emph{Des interval}. @code{--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,
@code{--list-generations=2..} renvoie toutes les générations à partir de la
deuxième.
@item @emph{Des durées}. Vous pouvez aussi récupérer les derniers @emph{N}@tie{}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 @code{--list-generations=20d} liste les
générations qui sont agées d'au plus 20 jours.
@end itemize
@item --delete-generations[=@var{motif}]
@itemx -d [@var{motif}]
Lorsque @var{motif} est omis, supprimer toutes les générations en dehors de
l'actuelle.
Cette commande accepte les même motifs que @option{--list-generations}.
Lorsque @var{motif} est spécifié, supprimer les générations correspondante.
Lorsque @var{motif} spécifie une durée, les générations @emph{plus vieilles}
que la durée spécifiée correspondent. Par exemple
@code{--delete-generations=1m} supprime les générations vieilles de plus
d'un mois.
Si la génération actuelle correspond, elle n'est @emph{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.
@end table
Enfin, comme @command{guix package} peut démarrer des processus de
construction, elle supporte les options de construction communes
(@pxref{Options de construction communes}). Elle supporte aussi les options de
transformation de paquets comme @option{--with-source} (@pxref{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 à @code{GUIX_PACKAGE_PATH} (@pxref{Définition des paquets}).
@node Substituts
@section Substituts
@cindex substituts
@cindex binaires pré-construits
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 @dfn{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 (@pxref{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.
@menu
* 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 ?
@end menu
@node Serveur de substituts officiel
@subsection Serveur de substituts officiel
@cindex hydra
@cindex ferme de construction
Le serveur @code{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 @option{--substitute-urls} soit à
@command{guix-daemon} (@pxref{daemon-substitute-urls,, @code{guix-daemon
--substitute-urls}}) soit aux outils clients comme @command{guix package}
(@pxref{client-substitute-urls,, client @option{--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 (@pxref{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 (@pxref{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.
@node Autoriser un serveur de substituts
@subsection Autoriser un serveur de substituts
@cindex sécurité
@cindex substituts, autorisations
@cindex liste de contrôle d'accès (ACL), pour les substituts
@cindex ACL (liste de contrôle d'accès), pour les substituts
Pour permettre à Guix de télécharger les substituts depuis
@code{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
@command{guix archive} (@pxref{Invoquer guix archive}). Cela implique que
vous faîtes confiance à @code{hydra.gnu.org} pour ne pas être compromis et
vous servir des substituts authentiques.
La clef publique pour @code{hydra.gnu.org} est installée avec Guix, dans
@code{@var{préfixe}/share/guix/hydra.gnu.org.pub}, où @var{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
@file{guix-@value{VERSION}.tar.gz} qui contient ce fichier de clef
publique. Ensuite vous pouvez lancer quelque chose comme ceci :
@example
# guix archive --authorize < @var{préfixe}/share/guix/hydra.gnu.org.pub
@end example
@quotation Remarque
De même, le fichier @file{berlin.guixsd.org.pub} contient la clef publique
de la nouvelle ferme de construction du projet, disponible depuis
@indicateurl{https://berlin.guixsd.org}.
Au moment où ces lignes sont écrites, @code{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 @code{mirror.hydra.gnu.org}
@end quotation
Une fois que cela est en place, la sortie d'une commande comme @code{guix
build} devrait changer de quelque chose comme :
@example
$ 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
@dots{}
@end example
@noindent
à quelque chose comme :
@example
$ 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
@dots{}
@end example
@noindent
Cela indique que les substituts de @code{hydra.gnu.org} sont utilisables et
seront téléchargés, si possible, pour les futures constructions.
@cindex substituts, comment les désactiver
Le mécanisme de substitution peut être désactivé globalement en lançant
@code{guix-daemon} avec @code{--no-substitutes} (@pxref{Invoquer guix-daemon}). Il peut aussi être désactivé temporairement en passant
l'option @code{--no-substitutes} à @command{guix package}, @command{guix
build} et aux autres outils en ligne de commande.
@node Authentification des substituts
@subsection Authentification des substituts
@cindex signatures numériques
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 @emph{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 :
@example
--substitute-urls="https://a.example.org https://b.example.org"
@end example
@noindent
@cindex constructions reproductibles
Si l'ACL contient uniquement la clef de @code{b.example.org}, et si
@code{a.example.org} sert @emph{exactement les mêmes} substituts, alors Guix
téléchargera les substituts de @code{a.example.org} parce qu'il vient en
premier dans la liste et peut être considéré comme un mirroir de
@code{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 @emph{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).
@node Paramètres de serveur mandataire
@subsection Paramètres de serveur mandataire
@vindex http_proxy
Les substituts sont téléchargés par HTTP ou HTTPS. La variable
d'environnement @code{http_proxy} peut être initialisée dans l'environnement
de @command{guix-daemon} et est respectée pour le téléchargement des
substituts. Remarquez que la valeur de @code{http_proxy} dans
l'environnement où tournent @command{guix build}, @command{guix package} et
les autres clients n'a @emph{absolument aucun effet}.
@node Échec de substitution
@subsection É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 @code{--fallback} a été passé en
argument (@pxref{fallback-option,, common build option @code{--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 @code{--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 @emph{toujours} effectuée, indépendamment du fait que l'argument
@code{--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 @command{guix weather} (@pxref{Invoquer guix weather}). Cette command fournit des statistiques sur les substituts
fournis par un serveur.
@node De la confiance en des binaires
@subsection De la confiance en des binaires
@cindex confiance, en des binaires pré-construits
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 @code{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 @code{hydra.gnu.org} devienne une
cible moins intéressante. Une façon d'aider est de publier les logiciels
que vous construisez avec @command{guix publish} pour que les autres aient
plus de choix de serveurs où télécharger les substituts (@pxref{Invoquer guix publish}).
Guix possède les fondations pour maximiser la reproductibilité logicielle
(@pxref{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 @command{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
(@pxref{Invoquer guix challenge}). De même, l'option @option{--check} de
@command{guix build} permet aux utilisateurs de vérifier si les substituts
précédemment installés sont authentiques en les reconstruisant localement
(@pxref{build-check, @command{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 @email{guix-devel@@gnu.org}.
@node Des paquets avec plusieurs résultats
@section Des paquets avec plusieurs résultats
@cindex paquets avec plusieurs résultats
@cindex sorties de paquets
@cindex sorties
Souvent, les paquets définis dans Guix ont une seule @dfn{sortie} —
c.-à-d.@: que le paquet source conduit à exactement un répertoire dans le
dépôt. Lorsque vous lancez @command{guix package -i glibc}, vous installez
la sortie par défaut du paquet GNU libc ; la sortie par défaut est appelée
@code{out} mais son nom peut être omis comme le montre cette commande. Dans
ce cas particuliers, la sortie par défaut de @code{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 @code{doc}. Pour installer
la sortie principale de GLib, qui contient tout sauf la documentation, on
devrait lancer :
@example
guix package -i glib
@end example
@cindex documentation
La commande pour installer la documentation est :
@example
guix package -i glib:doc
@end example
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 @command{guix
size} peut aider à trouver ces situations (@pxref{Invoquer guix size}). @command{guix graph} peut aussi être utile (@pxref{Invoquer guix graph}).
Il y a plusieurs paquets à sorties multiples dans la distribution GNU.
D'autres noms de sorties conventionnels sont @code{lib} pour les
bibliothèques et éventuellement les fichiers d'en-tête, @code{bin} pour les
programmes indépendants et @code{debug} pour les informations de débogage
(@pxref{Installer les fichiers de débogage}). Les sorties d'un paquet sont listés
dans la troisième colonne de la sortie de @command{guix package
--list-available} (@pxref{Invoquer guix package}).
@node Invoquer guix gc
@section Invoquer @command{guix gc}
@cindex ramasse-miettes
@cindex espace disque
Les paquets qui sont installés mais pas utilisés peuvent être @dfn{glanés}.
La commande @command{guix gc} permet aux utilisateurs de lancer
explicitement le ramasse-miettes pour récupérer de l'espace dans le
répertoire @file{/gnu/store}. C'est la @emph{seule} manière de supprimer
des fichiers de @file{/gnu/store} — supprimer des fichiers ou des
répertoires à la main peut le casser de manière impossible à réparer !
@cindex racines du GC
@cindex racines du ramasse-miettes
Le ramasse-miettes a un ensemble de @dfn{racines} connues : tout fichier
dans @file{/gnu/store} atteignable depuis une racine est considéré comme
@dfn{utilisé} et ne peut pas être supprimé ; tous les autres fichiers sont
considérés comme @dfn{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 @file{/var/guix/gcroots} représentent ces racines du GC. De nouvelles
racines du GC peuvent être ajoutées avec la @command{guix build -- root} par
exemple (@pxref{Invoquer guix build}).
Avant de lancer @code{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 @code{guix package --delete-generations} (@pxref{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@tie{}Go d'espace reste libre sur votre disque, lancez simplement :
@example
guix gc -F 5G
@end example
Il est parfaitement possible de le lancer comme une tâche périodique
non-interactive (@pxref{Exécution de tâches planifiées} pour apprendre comment
paramétrer une telle tâche sur GuixSD). Lancer @command{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 @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 @code{--delete}), pour afficher des
informations sur le ramasse-miettes ou pour des requêtes plus avancées. Les
options du ramasse-miettes sont :
@table @code
@item --collect-garbage[=@var{min}]
@itemx -C [@var{min}]
Ramasse les miettes — c.-à-d.@: les fichiers inaccessibles de
@file{/gnu/store} et ses sous-répertoires. C'est l'opération par défaut
lorsqu'aucune option n'est spécifiée.
Lorsque @var{min} est donné, s'arrêter une fois que @var{min} octets ont été
collectés. @var{min} pour être un nombre d'octets ou inclure un suffixe
d'unité, comme @code{MiB} pour mébioctet et @code{GB} pour gigaoctet
(@pxref{Block size, size specifications,, coreutils, GNU Coreutils}).
Lorsque @var{min} est omis, tout glaner.
@item --free-space=@var{libre}
@itemx -F @var{libre}
Glaner jusqu'à ce que @var{libre} espace soit disponible dans
@file{/gnu/store} si possible ; @var{libre} est une quantité de stockage
comme @code{500MiB} comme décrit ci-dessus.
Lorsque @var{libre} ou plus est disponible dans @file{/gnu/store} ne rien
faire et s'arrêter immédiatement.
@item --delete
@itemx -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.
@item --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
@option{--cache-failures} (@pxref{Invoquer guix-daemon,
@option{--cache-failures}}).
@item --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 @option{--cache-failures}. Autrement elle ne fait rien.
@item --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.
@item --list-live
Montrer la liste des fichiers et des répertoires du dépôt utilisés.
@end table
En plus, les références entre les fichiers existants du dépôt peuvent être
demandés :
@table @code
@item --references
@itemx --referrers
@cindex dépendances des paquets
Lister les références (respectivement les référents) des fichiers du dépôt
en argument.
@item --requisites
@itemx -R
@cindex closure
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 @dfn{closure transitive} des fichiers du dépôt.
@xref{Invoquer guix size} pour un outil pour surveiller la taille de la
closure d'un élément. @xref{Invoquer guix graph} pour un outil pour
visualiser le graphe des références.
@item --derivers
@cindex dérivation
Renvoie les dérivations menant aux éléments du dépôt donnés
(@pxref{Dérivations}).
Par exemple cette commande :
@example
guix gc --derivers `guix package -I ^emacs$ | cut -f4`
@end example
@noindent
renvoie les fichiers @file{.drv} menant au paquet @code{emacs} installé dans
votre profil.
Remarquez qu'il peut n'y avoir aucun fichier @file{.drv} par exemple quand
ces fichiers ont été glanés. Il peut aussi y avoir plus d'un fichier
@file{.drv} correspondant à cause de dérivations à sortie fixées.
@end table
Enfin, les options suivantes vous permettent de vérifier l'intégrité du
dépôt et de contrôler l'utilisation du disque.
@table @option
@item --verify[=@var{options}]
@cindex intégrité, du dépôt
@cindex vérification d'intégrité
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 @file{/gnu/store}.
Lorsqu'elle est fournie, l'@var{option} doit être une liste séparée par des
virgule de l'un ou plus parmi @code{contents} et @code{repair}.
Lorsque vous passez @option{--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 @emph{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.
@cindex réparer le dépôt
@cindex corruption, récupérer de
Utiliser @option{--verify=repair} ou @option{--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 (@pxref{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
@command{guix build --repair} (@pxref{Invoquer guix build}).
@item --optimize
@cindex déduplication
Optimiser le dépôt en liant en dur les fichiers identiques — c'est la
@dfn{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
@code{--disable-deduplication} (@pxref{Invoquer guix-daemon,
@code{--disable-deduplication}}). Ainsi, cette option est surtout utile
lorsque le démon tourne avec @code{--disable-deduplication}.
@end table
@node Invoquer guix pull
@section Invoquer @command{guix pull}
@cindex mettre à niveau Guix
@cindex mettre à jour Guix
@cindex @command{guix pull}
@cindex 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 @command{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 @uref{https://git-scm.com, Git}.
À la fin, @command{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 @command{guix}
ajoutés par la mise à jour sont aussi maintenant disponibles.
Chaque utilisateur peut mettre à jour sa copie de Guix avec @command{guix
pull} et l'effet est limité à l'utilisateur qui a lancé @command{guix
pull}. Par exemple, lorsque l'utilisateur @code{root} lance @command{guix
pull}, cela n'a pas d'effet sur la version de Guix que vois @code{alice} et
vice-versa@footnote{Sous le capot, @command{guix pull} met à jour le lien
symbolique @file{~/.config/guix/latest} pour qu'il pointe vers la dernière
version de Guix et la commande @command{guix} charge son code depuis cet
endroit. Actuellement la seule manière de revenir en arrière sur une
invocation de @command{guix pull} est de mettre à jour manuellement le lien
symbolique pour qu'il pointe vers une version précédente de Guix.}.
La commande @command{guix pull} est typiquement invoquée sans arguments mais
il supporte les options suivantes :
@table @code
@item --verbose
Produire une sortie verbeuse, en écrivant les journaux de construction sur
la sortie d'erreur standard.
@item --url=@var{url}
Télécharger Guix depuis le dépôt Git à @var{url}.
@vindex GUIX_PULL_URL
Par défaut, la source est récupérée depuis le dépôt Git canonique sur
@code{gnu.org}, pour la branche stable de Guix. Pour utiliser une autre
source, paramétrez la variable d'environnement @code{GUIX_PULL_URL}.
@item --commit=@var{commit}
Déployer de @var{commit}, un ID de commit Git valide représenté par une
chaîne hexadécimale.
@item --branch=@var{branche}
Déployer le haut de la @var{branche}, le nom d'une branche Git disponible
sur le répertoire à @var{url}.
@item --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.
@end table
En plus, @command{guix pull} supporte toutes les options de construction
communes (@pxref{Options de construction communes}).
@node Invoquer guix pack
@section Invoquer @command{guix pack}
Parfois vous voulez passer un logiciel à des gens qui n'ont pas (encore !)
la chance d'utiliser Guix. Vous leur diriez bien de lancer @command{guix
package -i @var{quelque chose}} mais ce n'est pas possible dans ce cas.
C'est là que @command{guix pack} entre en jeu.
@quotation Remarque
Si vous cherchez comment échanger des binaires entre des machines où Guix
est déjà installé, @pxref{Invoquer guix copy}, @ref{Invoquer guix publish},
et @ref{Invoquer guix archive}.
@end quotation
@cindex pack
@cindex lot
@cindex lot d'applications
@cindex lot de logiciels
La commande @command{guix pack} crée un @dfn{pack} ou @dfn{lot de logiciels}
: elle crée une archive tar ou un autre type d'archive contenunt les
binaires pour le logiciel qui vous intéresse ainsi que ses dépendances.
L'archive qui en résulte peut être utilisée sur toutes les machines qui
n'ont pas Guix et les gens peuvent lancer exactement les mêmes binaires que
ceux que vous avez avec Guix. Le pack lui-même est créé d'une manière
reproductible au bit près, pour que n'importe qui puisse vérifier qu'il
contient bien les résultats que vous prétendez proposer.
Par exemple, pour créer un lot contenant Guile, Emacs, Geiser et toutes
leurs dépendances, vous pouvez lancer :
@example
$ guix pack guile emacs geiser
@dots{}
/gnu/store/@dots{}-pack.tar.gz
@end example
Le résultat ici est une archive tar contenant un répertoire
@file{/gnu/store} avec tous les paquets nécessaires. L'archive qui en
résulte contient un @dfn{profil} avec les trois paquets qui vous intéressent
; le profil est le même qui celui qui aurait été créé avec @command{guix
package -i}. C'est ce mécanisme qui est utilisé pour créer les archives tar
binaires indépendantes de Guix (@pxref{Installation binaire}).
Les utilisateurs de ce pack devraient lancer
@file{/gnu/store/@dots{}-profile/bin/guile} pour lancer Guile, ce qui n'est
pas très pratique. Pour éviter cela, vous pouvez créer, disons, un lien
symbolique @file{/opt/gnu/bin} vers le profil :
@example
guix pack -S /opt/gnu/bin=bin guile emacs geiser
@end example
@noindent
De cette façon, les utilisateurs peuvent joyeusement taper
@file{/opt/gnu/bin/guile} et profiter.
@cindex relocatable binaries, with @command{guix pack}
What if the recipient of your pack does not have root privileges on their
machine, and thus cannot unpack it in the root file system? In that case,
you will want to use the @code{--relocatable} option (see below). This
option produces @dfn{relocatable binaries}, meaning they they can be placed
anywhere in the file system hierarchy: in the example above, users can
unpack your tarball in their home directory and directly run
@file{./opt/gnu/bin/guile}.
@cindex Docker, build an image with guix pack
Autrement, vous pouvez produire un pack au format d'image Docker avec la
commande suivante :
@example
guix pack -f docker guile emacs geiser
@end example
@noindent
Le résultat est une archive tar qui peut être passée à la commande
@command{docker load}. Voir la
@uref{https://docs.docker.com/engine/reference/commandline/load/,
documentation de Docker} pour plus d'informations.
@cindex Singularity, build an image with guix pack
@cindex SquashFS, build an image with guix pack
Yet another option is to produce a SquashFS image with the following
command:
@example
guix pack -f squashfs guile emacs geiser
@end example
@noindent
The result is a SquashFS file system image that can either be mounted or
directly be used as a file system container image with the
@uref{http://singularity.lbl.gov, Singularity container execution
environment}, using commands like @command{singularity shell} or
@command{singularity exec}.
Diverses options en ligne de commande vous permettent de personnaliser votre
pack :
@table @code
@item --format=@var{format}
@itemx -f @var{format}
Produire un pack dans le @var{format} donné.
Les formats disponibles sont :
@table @code
@item tarball
C'est le format par défaut. Il produit une archive tar contenant tous les
binaires et les liens symboliques spécifiés.
@item docker
Cela produit une archive tar qui suit la
@uref{https://github.com/docker/docker/blob/master/image/spec/v1.2.md,
spécification des images Docker}.
@item squashfs
This produces a SquashFS image containing all the specified binaries and
symlinks, as well as empty mount points for virtual file systems like
procfs.
@end table
@item --relocatable
@itemx -R
Produce @dfn{relocatable binaries}---i.e., binaries that can be placed
anywhere in the file system hierarchy and run from there. For example, if
you create a pack containing Bash with:
@example
guix pack -R -S /mybin=bin bash
@end example
@noindent
... you can copy that pack to a machine that lacks Guix, and from your home
directory as a normal user, run:
@example
tar xf pack.tar.gz
./mybin/sh
@end example
@noindent
In that shell, if you type @code{ls /gnu/store}, you'll notice that
@file{/gnu/store} shows up and contains all the dependencies of @code{bash},
even though the machine actually lacks @file{/gnu/store} altogether! That is
probably the simplest way to deploy Guix-built software on a non-Guix
machine.
There's a gotcha though: this technique relies on the @dfn{user namespace}
feature of the kernel Linux, which allows unprivileged users to mount or
change root. Old versions of Linux did not support it, and some GNU/Linux
distributions turn it off; on these systems, programs from the pack
@emph{will fail to run}, unless they are unpacked in the root file system.
@item --expression=@var{expr}
@itemx -e @var{expr}
Considérer le paquet évalué par @var{expr}.
Cela a le même but que l'option de même nom de @command{guix build}
(@pxref{Options de construction supplémentaires, @code{--expression} dans @command{guix
build}}).
@item --manifest=@var{fichier}
@itemx -m @var{fichier}
Utiliser les paquets contenus dans l'objet manifeste renvoyé par le code
Scheme dans @var{fichier}
Elle a un but similaire à l'option de même nom dans @command{guix package}
(@pxref{profile-manifest, @option{--manifest}}) et utilise les mêmes
fichiers manifeste. Ils vous permettent de définir une collection de
paquets une fois et de l'utiliser aussi bien pour créer des profils que pour
créer des archives pour des machines qui n'ont pas Guix d'installé.
Remarquez que vous pouvez spécifier @emph{soit} un fichier manifeste,
@emph{soit} une liste de paquet, mais pas les deux.
@item --system=@var{système}
@itemx -s @var{système}
Tenter de construire pour le @var{système} — p.@: ex.@: @code{i686-linux} —
plutôt que pour le type de système de l'hôte de construction.
@item --target=@var{triplet}
@cindex compilation croisée
Effectuer une compilation croisée pour @var{triplet} qui doit être un
triplet GNU valide, comme @code{"mips64el-linux-gnu"} (@pxref{Specifying
target triplets, GNU configuration triplets,, autoconf, Autoconf}).
@item --compression=@var{outil}
@itemx -C @var{outil}
Compresser l'archive résultante avec @var{outil} — l'un des outils parmi
@code{bzip2}, @code{xz}, @code{lzip} ou @code{none} pour aucune compression.
@item --symlink=@var{spec}
@itemx -S @var{spec}
Ajouter les liens symboliques spécifiés par @var{spec} dans le pack. Cette
option peut apparaître plusieurs fois.
@var{spec} a la forme @code{@var{source}=@var{cible}}, où @var{source} est
le lien symbolique qui sera créé et @var{cible} est la cible du lien.
Par exemple, @code{-S /opt/gnu/bin=bin} crée un lien symbolique
@file{/opt/gnu/bin} qui pointe vers le sous-répertoire @file{bin} du profil.
@item --localstatedir
Inclure le « répertoire d'état local », @file{/var/guix} dans le paquet
résultant.
@file{/var/guix} contient la base de données du dépôt (@pxref{Le dépôt})
ainsi que les racines du ramasse-miettes (@pxref{Invoquer guix gc}). Le
fournir dans le pack signifie que le dépôt et « complet » et gérable par
Guix ; ne pas le fournir dans le pack signifie que le dépôt est « mort » :
aucun élément ne peut être ajouté ni enlevé après l'extraction du pack.
Un cas d'utilisation est l'archive binaire indépendante de Guix
(@pxref{Installation binaire}).
@item --bootstrap
Utiliser les programmes d'amorçage pour construire le pack. Cette option
n'est utile que pour les développeurs de Guix.
@end table
En plus, @command{guix pack} supporte toutes les options de construction
communes (@pxref{Options de construction communes}) et toutes les options de
transformation de paquets (@pxref{Options de transformation de paquets}).
@node Invoquer guix archive
@section Invoquer @command{guix archive}
@cindex @command{guix archive}
@cindex archive
La commande @command{guix archive} permet aux utilisateurs d'@dfn{exporter}
des fichiers du dépôt dans une simple archive puis ensuite de les
@dfn{importer} sur une machine qui fait tourner Guix. En particulier, elle
permet de transférer des fichiers du dépôt d'une machine vers le dépôt d'une
autre machine.
@quotation Remarque
Si vous chercher une manière de produire des archives dans un format adapté
pour des outils autres que Guix, @pxref{Invoquer guix pack}.
@end quotation
@cindex exporter des éléments du dépôt
Pour exporter des fichiers du dépôt comme une archive sur la sortie
standard, lancez :
@example
guix archive --export @var{options} @var{spécifications}...
@end example
@var{spécifications} peut être soit des noms de fichiers soit des
spécifications de paquets, comme pour @command{guix package}
(@pxref{Invoquer guix package}). Par exemple, la commande suivante crée une
archive contenant la sortie @code{gui} du paquet @code{git} et la sortie
principale de @code{emacs} :
@example
guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar
@end example
Si les paquets spécifiés ne sont pas déjà construits, @command{guix archive}
les construit automatiquement. Le processus de construction peut être
contrôlé avec les options de construction communes (@pxref{Options de construction communes}).
Pour transférer le paquet @code{emacs} vers une machine connectée en SSH, on
pourrait lancer :
@example
guix archive --export -r emacs | ssh la-machine guix archive --import
@end example
@noindent
De même, on peut transférer un profil utilisateur complet d'une machine à
une autre comme cela :
@example
guix archive --export -r $(readlink -f ~/.guix-profile) | \
ssh la-machine guix-archive --import
@end example
@noindent
Cependant, remarquez que, dans les deux exemples, le paquet @code{emacs}, le
profil ainsi que toutes leurs dépendances sont transférées (à cause de
@code{-r}), indépendamment du fait qu'ils soient disponibles dans le dépôt
de la machine cible. L'option @code{--missing} peut vous aider à comprendre
les éléments qui manquent dans le dépôt de la machine cible. La commande
@command{guix copy} simplifie et optimise ce processus, c'est donc ce que
vous devriez utiliser dans ce cas (@pxref{Invoquer guix copy}).
@cindex nar, format d'archive
@cindex archive normalisée (nar)
Les archives sont stockées au format « archive normalisé » ou « nar », qui
est comparable dans l'esprit à « tar » mais avec des différences qui le
rendent utilisable pour ce qu'on veut faire. Tout d'abord, au lieu de
stocker toutes les métadonnées Unix de chaque fichier, le format nar ne
mentionne que le type de fichier (normal, répertoire ou lien symbolique) ;
les permissions Unix, le groupe et l'utilisateur ne sont pas mentionnés.
Ensuite, l'ordre dans lequel les entrées de répertoires sont stockés suit
toujours l'ordre des noms de fichier dans l'environnement linguistique C.
Cela rend la production des archives entièrement déterministe.
@c FIXME: Add xref to daemon doc about signatures.
Lors de l'export, le démon signe numériquement le contenu de l'archive et
cette signature est ajoutée à la fin du fichier. Lors de l'import, le démon
vérifie la signature et rejette l'import en cas de signature invalide ou si
la clef de signature n'est pas autorisée.
Les principales options sont :
@table @code
@item --export
Exporter les fichiers ou les paquets du dépôt (voir plus bas). Écrire
l'archive résultante sur la sortie standard.
Les dépendances ne sont @emph{pas} incluses dans la sortie à moins que
@code{--recursive} ne soit passé.
@item -r
@itemx --recursive
En combinaison avec @code{--export}, cette option demande à @command{guix
archive} d'inclure les dépendances des éléments donnés dans l'archive.
Ainsi, l'archive résultante est autonome : elle contient la closure des
éléments du dépôt exportés.
@item --import
Lire une archive depuis l'entrée standard et importer les fichiers inclus
dans le dépôt. Annuler si l'archive a une signature invalide ou si elle est
signée par une clef publique qui ne se trouve pas dans le clefs autorisées
(voir @code{--authorize} plus bas.)
@item --missing
Liste une liste de noms de fichiers du dépôt sur l'entrée standard, un par
ligne, et écrit sur l'entrée standard le sous-ensemble de ces fichiers qui
manquent dans le dépôt.
@item --generate-key[=@var{paramètres}]
@cindex signature, archives
Générer une nouvelle paire de clefs pour le démon. Cela est un prérequis
avant que les archives ne puissent être exportées avec @code{--export}.
Remarquez que cette opération prend généralement du temps parce qu'elle doit
récupère suffisamment d'entropie pour générer la paire de clefs.
La paire de clefs générée est typiquement stockée dans @file{/etc/guix},
dans @file{signing-key.pub} (clef publique) et @file{signing-key.sec} (clef
privée, qui doit rester secrète). Lorsque @var{paramètres} est omis, une
clef ECDSA utilisant la courbe Ed25519 est générée ou pour les version de
libgcrypt avant 1.6.0, une clef RSA de 4096 bits. Autrement,
@var{paramètres} peut spécifier les paramètres @code{genkey} adaptés pour
libgcrypt (@pxref{General public-key related Functions,
@code{gcry_pk_genkey},, gcrypt, The Libgcrypt Reference Manual}).
@item --authorize
@cindex autorisation, archives
Autoriser les imports signés par la clef publique passée sur l'entrée
standard. La clef publique doit être au « format avancé s-expression » —
c.-à-d.@: le même format que le fichier @file{signing-key.pub}.
La liste des clefs autorisées est gardée dans un fichier modifiable par des
humains dans @file{/etc/guix/acl}. Le fichier contient des
@url{http://people.csail.mit.edu/rivest/Sexp.txt, « s-expressions au format
avancé »} et est structuré comme une liste de contrôle d'accès dans
l'@url{http://theworld.com/~cme/spki.txt, infrastructure à clefs publiques
simple (SPKI)}.
@item --extract=@var{répertoire}
@itemx -x @var{répertoire}
Lit une archive à un seul élément telle que servie par un serveur de
substituts (@pxref{Substituts}) et l'extrait dans @var{répertoire}. C'est
une opération de bas niveau requise seulement dans de rares cas d'usage ;
voir plus loin.
Par exemple, la commande suivante extrait le substitut pour Emacs servi par
@code{hydra.gnu.org} dans @file{/tmp/emacs} :
@example
$ wget -O - \
https://hydra.gnu.org/nar/@dots{}-emacs-24.5 \
| bunzip2 | guix archive -x /tmp/emacs
@end example
Les archives à un seul élément sont différentes des archives à plusieurs
éléments produites par @command{guix archive --export} ; elles contiennent
un seul élément du dépôt et elles n'embarquent @emph{pas} de signature.
Ainsi cette opération ne vérifie @emph{pas} de signature et sa sortie
devrait être considérée comme non sûre.
Le but principal de cette opération est de faciliter l'inspection du contenu
des archives venant de serveurs auxquels on ne fait potentiellement pas
confiance.
@end table
@c *********************************************************************
@node Interface de programmation
@chapter Interface de programmation
GNU Guix fournit diverses interface de programmation Scheme (API) qui pour
définir, construire et faire des requêtes sur des paquets. La première
interface permet aux utilisateurs d'écrire des définitions de paquets de
haut-niveau. Ces définitions se réfèrent à des concepts de création de
paquets familiers, comme le nom et la version du paquet, son système de
construction et ses dépendances. Ces définitions peuvent ensuite être
transformées en actions concrètes lors de la construction.
Les actions de construction sont effectuées par le démon Guix, pour le
compte des utilisateurs. Dans un environnement standard, le démon possède
les droits en écriture sur le dépôt — le répertoire @file{/gnu/store} — mais
pas les utilisateurs. La configuration recommandée permet aussi au démon
d'effectuer la construction dans des chroots, avec un utilisateur de
construction spécifique pour minimiser les interférences avec le reste du
système.
@cindex dérivation
Il y a des API de plus bas niveau pour interagir avec le démon et le dépôt.
Pour demander au démon d'effectuer une action de construction, les
utilisateurs lui donnent en fait une @dfn{dérivation}. Une dérivation est
une représentation à bas-niveau des actions de construction à entreprendre
et l'environnement dans lequel elles devraient avoir lieu — les dérivations
sont aux définitions de paquets ce que l'assembleur est aux programmes C.
Le terme de « dérivation » vient du fait que les résultats de la
construction en @emph{dérivent}.
Ce chapitre décrit toutes ces API tour à tour, à partir des définitions de
paquets à haut-niveau.
@menu
* 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.
@end menu
@node Définition des paquets
@section Définition des paquets
L'interface de haut-niveau pour les définitions de paquets est implémentée
dans les modules @code{(guix packages)} et @code{(guix build-system)}. Par
exemple, la définition du paquet, ou la @dfn{recette}, du paquet GNU Hello
ressemble à cela :
@example
(define-module (gnu packages hello)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (guix build-system gnu)
#:use-module (guix licenses)
#:use-module (gnu packages gawk))
(define-public hello
(package
(name "hello")
(version "2.10")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/hello/hello-" version
".tar.gz"))
(sha256
(base32
"0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
(build-system gnu-build-system)
(arguments '(#:configure-flags '("--enable-silent-rules")))
(inputs `(("gawk" ,gawk)))
(synopsis "Hello, GNU world: An example GNU package")
(description "Guess what GNU Hello prints!")
(home-page "http://www.gnu.org/software/hello/")
(license gpl3+)))
@end example
@noindent
Sans être un expert Scheme, le lecteur peut comprendre la signification des
différents champs présents. Cette expression lie la variable @code{hello} à
un objet @code{<package>}, qui est essentiellement un enregistrement
(@pxref{SRFI-9, Scheme records,, guile, GNU Guile Reference Manual}). On
peut inspecter cet objet de paquet avec les procédures qui se trouvent dans
le module @code{(guix packages)} ; par exemple, @code{(package-name hello)}
renvoie — oh surprise ! — @code{"hello"}.
Avec un peu de chance, vous pourrez importer tout ou partie de la définition
du paquet qui vous intéresse depuis un autre répertoire avec la commande
@code{guix import} (@pxref{Invoquer guix import}).
Dans l'exemple précédent, @var{hello} est défini dans un module à part,
@code{(gnu packages hello)}. Techniquement, cela n'est pas strictement
nécessaire, mais c'est pratique : tous les paquets définis dans des modules
sous @code{(gnu packages @dots{})} sont automatiquement connus des outils en
ligne de commande (@pxref{Modules de paquets}).
Il y a quelques points à remarquer dans la définition de paquet précédente :
@itemize
@item
Le champ @code{source} du paquet est un objet @code{<origin>} (@pxref{Référence d'origine}, pour la référence complète). Ici, on utilise la méthode
@code{url-fetch} de @code{(guix download)}, ce qui signifie que la source
est un fichier à télécharger par FTP ou HTTP.
Le préfixe @code{mirror://gnu} demande à @code{url-fetch} d'utiliser l'un
des miroirs GNU définis dans @code{(guix download)}.
Le champ @code{sha256} spécifie le hash SHA256 attendu pour le fichier
téléchargé. Il est requis et permet à Guix de vérifier l'intégrité du
fichier. La forme @code{(base32 @dots{})} introduit a représentation en
base32 du hash. Vous pouvez obtenir cette information avec @code{guix
download} (@pxref{Invoquer guix download}) et @code{guix hash}
(@pxref{Invoquer guix hash}).
@cindex correctifs
Lorsque cela est requis, la forme @code{origin} peut aussi avec un champ
@code{patches} qui liste les correctifs à appliquer et un champ
@code{snippet} qui donne une expression Scheme pour modifier le code source.
@item
@cindex Système de construction GNU
Le champ @code{build-system} spécifie la procédure pour construire le paquet
(@pxref{Systèmes de construction}). Ici, @var{gnu-build-system} représente le système
de construction GNU familier, où les paquets peuvent être configurés,
construits et installés avec la séquence @code{./configure && make && make
check && make install} habituelle.
@item
Le champ @code{arguments} spécifie des options pour le système de
construction (@pxref{Systèmes de construction}). Ici il est interprété par
@var{gnu-build-system} comme une demande de lancer @file{configure} avec le
drapeau @code{--enable-silent-rules}.
@cindex quote
@cindex quoting
@findex '
@findex quote
Que sont ces apostrophes (@code{'}) ? C'est de la syntaxe Scheme pour
introduire une liste ; @code{'} est synonyme de la fonction @code{quote}.
@xref{Expression Syntax, quoting,, guile, GNU Guile Reference Manual}, pour
des détails. Ice la valeur du champ @code{arguments} est une liste
d'arguments passés au système de construction plus tard, comme avec
@code{apply} (@pxref{Fly Evaluation, @code{apply},, guile, GNU Guile
Reference Manual}).
La séquence dièse-deux-points (@code{#:}) définie un @dfn{mot-clef} Scheme
(@pxref{Keywords,,, guile, GNU Guile Reference Manual}), et
@code{#:configure-flags} est un mot-clef utilisé pour passer un argument au
système de construction (@pxref{Coding With Keywords,,, guile, GNU Guile
Reference Manual}).
@item
Le champ @code{inputs} spécifie les entrées du processus de construction —
c.-à-d.@: les dépendances à la construction ou à l'exécution du paquet. Ici
on définie une entrée nommée @code{"gawk"} dont la valeur est la variable
@var{gawk} ; @var{gawk} est elle-même liée à un objet @code{<package>}.
@cindex accent grave (quasiquote)
@findex `
@findex quasiquote
@cindex virgule (unquote)
@findex ,
@findex unquote
@findex ,@@
@findex unquote-splicing
De nouveau, @code{`} (un accent grave, synonyme de la fonction
@code{quasiquote}) nous permet d'introduire une liste litérale dans le champ
@code{inputs}, tandis que @code{,} (une virgule, synonyme de la fonction
@code{unquote}) nous permet d'insérer une valeur dans cette liste
(@pxref{Expression Syntax, unquote,, guile, GNU Guile Reference Manual}).
Remarquez que GCC, Coreutils, Bash et les autres outils essentiels n'ont pas
besoin d'être spécifiés en tant qu'entrées ici. À la place, le
@var{gnu-build-system} est en charge de s'assurer qu'ils sont présents
(@pxref{Systèmes de construction}).
Cependant, toutes les autres dépendances doivent être spécifiées dans le
champ @code{inputs}. Toute dépendance qui ne serait pas spécifiée ici sera
simplement indisponible pour le processus de construction, ce qui peut mener
à un échec de la construction.
@end itemize
@xref{Référence de paquet}, pour une description complète des champs
possibles.
Lorsqu'une définition de paquet est en place, le paquet peut enfin être
construit avec l'outil en ligne de commande @code{guix build}
(@pxref{Invoquer guix build}), pour résoudre les échecs de construction que
vous pourriez rencontrer (@pxref{Débogage des échecs de construction}). Vous pouvez
aisément revenir à la définition du paquet avec la commande @command{guix
edit} (@pxref{Invoquer guix edit}). @xref{Consignes d'empaquetage}, pour plus
d'inforamtions sur la manière de tester des définitions de paquets et
@ref{Invoquer guix lint}, pour des informations sur la manière de vérifier
que la définition réspecte les conventions de style.
@vindex GUIX_PACKAGE_PATH
Enfin, @pxref{Modules de paquets} pour des informations sur la manière
d'étendre la distribution en ajoutant vos propres définitions de paquets
dans @code{GUIX_PACKAGE_PATH}.