2.6.1 Régionalisation

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

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

Remarquez que le paquet glibc-locales contient les données de tous les paramètres linguistiques pris en charge par la GNU libc et pèse environ 930 Mio⁹. Si vous n’avez besoin que de quelques paramètres, vous pouvez définir un paquet personnalisé avec la procédure make-glibc-utf8-locales du module (gnu packages base). L’exemple suivant défini un paquet contenant plusieurs paramètres linguistiques canadiens connus de GNU libc, qui pèse environ 14 Mio :

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-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 pris en compte 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 prennent en compte 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 polices 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 font-ghostscript, font-dejavu et font-gnu-freefont.

Lorsque vous installez ou supprimez des polices, ou lorsque vous remarquez qu’une application ne trouve pas les polices, vous pouvez avoir besoin d’installer Fontconfig et de forcer un rafraîchissement de son cache de police avec :

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

Quand vous installez des paquets Emacs avec Guix, les fichiers Elips sont placés dans le répertoire share/emacs/site-lisp/ du profil dans lequel ils sont installés. Les bibliothèques Elisp sont rendues disponibles dans Emacs avec la variable d’environnement EMACSLOADPATH, qui est initialisée à l’installation d’Emacs lui-même.

En plus, des définitions autoload sont automatiquement évaluées au démarrage d’Emacs, par la procédure guix-emacs-autoload-packages de Guix. Si, pour quelque raison que ce soit, vous souhaitez éviter de charger automatiquement les paquets Emacs installés avec Guix, vous pouvez le faire en lançant Emacs avec l’option --no-site-file (voir Init File dans The GNU Emacs Manual).

Remarque : Emacs peut maintenant compiler des paquets nativement. Dans la configuration par défaut, cela signifie que les paquets Emacs seront maintenant compilés à la volée (JIT) quand vous les utilisez, et les résultats seront stockés dans un sous-répertoire de votre user-emacs-directory.

De plus, le système de construction des paquets Emacs prend en charge la compilation native de manière transparente, mais remarquez que emacs-minimal — l’Emacs par défaut pour construire les paquets — n’a pas été configuré avec la compilation native. Pour compiler nativement vos paquets emacs en avance, utilisez une transformation comme --with-input=emacs-minimal=emacs.