Suivant: , Précédent: , Monter: Installation   [Table des matières][Index]


2.6 Réglages applicatifs

Lorsque vous utilisez Guix par dessus une distribution GNU/Linux qui n’est pas Guix System — ce qu’on appelle une distro externe — quelques étapes supplémentaires sont requises pour que tout soit en place. En voici certaines.

2.6.1 Régionalisation

Les paquets installés via Guix n’utiliseront pas les données de régionalisation du système hôte. À la place, vous devrez d’abord installer l’un des paquets linguistiques disponibles dans Guix puis définir la variable d’environnement GUIX_LOCPATH :

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

Note that the glibc-locales package contains data for all the locales supported by the GNU libc and weighs in at around 917 MiB. Alternatively, the glibc-utf8-locales is smaller but limited to a few UTF-8 locales.

La variable GUIX_LOCPATH joue un rôle similaire à LOCPATH (voir LOCPATH dans The GNU C Library Reference Manual). Il y a deux différences importantes cependant :

  1. GUIX_LOCPATH n’est compris que par la libc dans Guix et pas par la libc fournie par les distros externes. Ainsi, utiliser GUIX_LOCPATH vous permet de vous assurer que les programmes de la distro externe ne chargeront pas de données linguistiques incompatibles.
  2. La libc ajoute un suffixe /X.Y à chaque entrée de GUIX_LOCPATH, où X.Y est la version de la libc — p. ex. 2.22. Cela signifie que, si votre profile Guix contient un mélange de programmes liés avec des versions différentes de la libc, chaque version de la libc essaiera de charger les environnements linguistiques dans le bon format.

Cela est important car le format des données linguistiques utilisés par différentes version de la libc peuvent être incompatibles.

2.6.2 Name Service Switch

Lorsque vous utilisez Guix sur une distro externe, nous recommandons fortement que ce système fasse tourner le démon de cache de service de noms de la bibliothèque C de GNU, nscd, qui devrait écouter sur le socket /var/run/nscd/socket. Sans cela, les applications installées avec Guix peuvent échouer à résoudre des noms d’hôtes ou de comptes, ou même planter. Les paragraphes suivants expliquent pourquoi.

La bibliothèque C de GNU implémente un name service switch (NSS), qui est un mécanisme d’extension pour les « résolutions de noms » en général : résolution de nom d’hôte, de compte utilisateur·rice et plus (voir Name Service Switch dans The GNU C Library Reference Manual).

Comme il est extensible, NSS supporte des greffons qui fournissent une nouvelle implémentation de résolution de nom : par exemple le greffon nss-mdns permet la résolution de noms d’hôtes en .local, le greffon nis permet la résolution de comptes avec le Network Information Service (NIS), etc. Ces « services de recherches » supplémentaires sont configurés au niveau du système dans /etc/nsswitch.conf, et tous les programmes qui tournent sur ce système honorent ces paramètres (voir NSS Configuration File dans The GNU C Reference Manual)

Lorsqu’ils essayent d’effectuer une résolution de nom — par exemple en appelant la fonction getaddrinfo en C — les applications essayent d’abord de se connecter au nscd ; en cas de réussite, nscd effectue la résolution de nom pour eux. Si le nscd ne tourne pas, alors ils effectuent la résolution eux-mêmes, en changeant les service de résolution dans leur propre espace d’adressage et en le lançant. Ce services de résolution de noms — les fichiers libnns_*.so — sont dlopenés mais ils peuvent provenir de la bibliothèque C du système, plutôt que de la bibliothèque C à laquelle l’application est liée (la bibliothèque C de Guix).

Et c’est là que se trouve le problème : si votre application est liée à la bibliothèque C de Guix (disons, glibc-2.24) et essaye de charger les greffons NSS d’une autre bibliothèque C (disons, libnss_mdns.so pour glibc-2.22), il est très probable qu’elle plante ou que sa résolution de nom échoue de manière inattendue.

Lancer nscd sur le système, entre autres avantages, élimine ce problème d’incompatibilité binaire car ces fichiers libnss_*.so sont chargés par le processus nscd, pas par l’application elle-même.

2.6.3 Polices X11

La majorité des applications graphiques utilisent fontconfig pour trouver et charger les police et effectuer le rendu côté client X11. Le paquet fontconfig dans Guix cherche les polices dans $HOME/.guix-profile par défaut. Ainsi, pour permettre aux applications graphiques installées avec Guix d’afficher des polices, vous devez aussi installer des polices avec Guix. Les paquets de polices essentiels sont gs-fonts, font-dejavu et font-gnu-freefont-ttf.

Once you have installed or removed fonts, or when you notice an application that does not find fonts, you may need to install Fontconfig and to force an update of its font cache by running:

guix install fontconfig
fc-cache -rv

Pour afficher des textes écrits en chinois, en japonais ou en coréen dans les applications graphiques, installez font-adobe-source-han-sans ou font-wqy-zenhei. Le premier a plusieurs sorties, une par famille de langue (voir Des paquets avec plusieurs résultats). Par exemple, la commande suivante installe les polices pour le chinois :

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

Les vieux programmes comme xterm n’utilisent pas fontconfig et s’appuient sur le rendu du côté du serveur. Ces programmes ont besoin de spécifier le nom complet de la police en utilisant XLFD (X Logical Font Description), comme ceci :

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

Pour pouvoir utiliser ces noms complets avec les polices TrueType installées dans votre profil Guix, vous devez étendre le chemin des polices du serveur X :

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

Ensuite, vous pouvez lancer xlsfonts (du paquet xlsfonts) pour vous assurer que vos polices TrueType y sont listées.

2.6.4 Certificats X.509

Le paquet nss-certs fournit les certificats X.509 qui permettent aux programmes d’authentifier les serveurs web par HTTPS.

Lorsque vous utilisez Guix sur une distribution externe, vous pouvez installer ce paquet et définir les variables d’environnement adéquates pour que les paquets sachent où trouver les certificats. Voir Certificats X.509, pour des informations détaillées.

2.6.5 Paquets emacs

When you install Emacs packages with Guix, the Elisp files are placed under the share/emacs/site-lisp/ directory of the profile in which they are installed. The Elisp libraries are made available to Emacs through the EMACSLOADPATH environment variable, which is set when installing Emacs itself.

Additionally, autoload definitions are automatically evaluated at the initialization of Emacs, by the Guix-specific guix-emacs-autoload-packages procedure. If, for some reason, you want to avoid auto-loading the Emacs packages installed with Guix, you can do so by running Emacs with the --no-site-file option (voir Init File dans The GNU Emacs Manual).

2.6.6 La chaîne d’outils GCC

Guix offre des paquets de compilateurs individuels comme gcc mais si vous avez besoin d’une chaîne de compilation complète pour compiler et lier du code source, vous avez en fait besoin du paquet gcc-toolchain. Ce paquet fournit une chaîne d’outils GCC pour le développement C/C++, dont GCC lui-même, la bibliothèque C de GNU (les en-têtes et les binaires, plus les symboles de débogage dans la sortie debug), Binutils et une enveloppe pour l’éditeur de liens.

Le rôle de l’enveloppe est d’inspecter les paramètres -L et -l passés à l’éditeur de liens, d’ajouter des arguments -rpath correspondants et d’invoquer le véritable éditeur de liens avec ce nouvel ensemble d’arguments. Vous pouvez dire à l’enveloppe de refuser de lier les programmes à des bibliothèques en dehors du dépôt en paramétrant la variable d’environnement GUIX_LD_WRAPPER_ALLOW_IMPURITIES sur no.


Suivant: , Précédent: , Monter: Installation   [Table des matières][Index]