2.4.1 Locales

Über Guix installierte Pakete benutzen nicht die Daten zu Regions- und Spracheinstellungen (Locales) des Wirtssystems. Stattdessen müssen Sie erst eines der Locale-Pakete installieren, die für Guix verfügbar sind, und dann den Wert Ihrer Umgebungsvariablen GUIX_LOCPATH passend festlegen:

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

Beachten Sie, dass das Paket glibc-locales Daten für alle von GNU libc unterstützten Locales enthält und deswegen um die 930 MiB wiegt⁹. Wenn alles, was Sie brauchen, einige wenige Locales sind, können Sie Ihr eigenes Locale-Paket mit der Prozedur make-glibc-utf8-locales aus dem Modul (gnu packages base) definieren. Folgendes Beispiel definiert ein Paket mit den verschiedenen kanadischen UTF-8-Locales, die der GNU libc bekannt sind, das nur um die 14 MiB schwer ist:

(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-kanadische-utf8-locales"))

Die Variable GUIX_LOCPATH spielt eine ähnliche Rolle wie LOCPATH (siehe LOCPATH in Referenzhandbuch der GNU-C-Bibliothek). Es gibt jedoch zwei wichtige Unterschiede:

1. GUIX_LOCPATH wird nur von der libc in Guix beachtet und nicht der von Fremddistributionen bereitgestellten libc. Mit GUIX_LOCPATH können Sie daher sicherstellen, dass die Programme der Fremddistribution keine inkompatiblen Locale-Daten von Guix laden.
2. libc hängt an jeden GUIX_LOCPATH-Eintrag /X.Y an, wobei X.Y die Version von libc ist – z.B. 2.22. Sollte Ihr Guix-Profil eine Mischung aus Programmen enthalten, die an verschiedene libc-Versionen gebunden sind, wird jede nur die Locale-Daten im richtigen Format zu laden versuchen.

Das ist wichtig, weil das Locale-Datenformat verschiedener libc-Versionen inkompatibel sein könnte.

2.4.2 Name Service Switch

Wenn Sie Guix auf einer Fremddistribution verwenden, empfehlen wir stärkstens, dass Sie den Name Service Cache Daemon der GNU-C-Bibliothek, nscd, laufen lassen, welcher auf dem Socket /var/run/nscd/socket lauschen sollte. Wenn Sie das nicht tun, könnten mit Guix installierte Anwendungen Probleme beim Auflösen von Hostnamen (d.h. Rechnernamen) oder Benutzerkonten haben, oder sogar abstürzen. Die nächsten Absätze erklären warum.

Die GNU-C-Bibliothek implementiert einen Name Service Switch (NSS), welcher einen erweiterbaren Mechanismus zur allgemeinen „Namensauflösung“ darstellt: Hostnamensauflösung, Benutzerkonten und weiteres (siehe Name Service Switch in Referenzhandbuch der GNU-C-Bibliothek).

Für die Erweiterbarkeit unterstützt der NSS Plugins, welche neue Implementierungen zur Namensauflösung bieten: Zum Beispiel ermöglicht das Plugin nss-mdns die Namensauflösung für .local-Hostnamen, das Plugin nis gestattet die Auflösung von Benutzerkonten über den Network Information Service (NIS) und so weiter. Diese zusätzlichen „Auflösungsdienste“ werden systemweit konfiguriert in /etc/nsswitch.conf und alle auf dem System laufenden Programme halten sich an diese Einstellungen (siehe NSS Configuration File in GNU-C-Referenzhandbuch).

Wenn sie eine Namensauflösung durchführen – zum Beispiel, indem sie die getaddrinfo-Funktion in C aufrufen –, versuchen die Anwendungen als Erstes, sich mit dem nscd zu verbinden; ist dies erfolgreich, führt nscd für sie die weiteren Namensauflösungen durch. Falls nscd nicht läuft, führen sie selbst die Namensauflösungen durch, indem sie die Namensauflösungsdienste in ihren eigenen Adressraum laden und ausführen. Diese Namensauflösungsdienste – die libnss_*.so-Dateien – werden mit dlopen geladen, aber sie kommen von der C-Bibliothek des Wirtssystems und nicht von der C-Bibliothek, an die die Anwendung gebunden wurde (also der C-Bibliothek von Guix).

Und hier kommt es zum Problem: Wenn die Anwendung an die C-Bibliothek von Guix (etwa glibc 2.24) gebunden wurde und die NSS-Plugins von einer anderen C-Bibliothek (etwa libnss_mdns.so für glibc 2.22) zu laden versucht, wird sie vermutlich abstürzen oder die Namensauflösungen werden unerwartet fehlschlagen.

Durch das Ausführen von nscd auf dem System wird, neben anderen Vorteilen, dieses Problem der binären Inkompatibilität vermieden, weil diese libnss_*.so-Dateien vom nscd-Prozess geladen werden, nicht in den Anwendungen selbst.

2.4.3 X11-Schriftarten

Die Mehrheit der grafischen Anwendungen benutzen Fontconfig zum Finden und Laden von Schriftarten und für die Darstellung im X11-Client. Im Paket fontconfig in Guix werden Schriftarten standardmäßig in $HOME/.guix-profile gesucht. Um es grafischen Anwendungen, die mit Guix installiert wurden, zu ermöglichen, Schriftarten anzuzeigen, müssen Sie die Schriftarten auch mit Guix installieren. Essenzielle Pakete für Schriftarten sind unter anderem font-ghostscript, font-dejavu und font-gnu-freefont.

Sobald Sie Schriftarten installiert oder wieder entfernt haben oder wenn Ihnen auffällt, dass eine Anwendung Schriftarten nicht finden kann, dann müssen Sie vielleicht Fontconfig installieren und den folgenden Befehl ausführen, damit dessen Zwischenspeicher für Schriftarten aktualisiert wird:

guix install fontconfig
fc-cache -rv

Um auf Chinesisch, Japanisch oder Koreanisch verfassten Text in grafischen Anwendungen anzeigen zu können, möchten Sie vielleicht font-adobe-source-han-sans oder font-wqy-zenhei installieren. Ersteres hat mehrere Ausgaben, für jede Sprachfamilie eine (siehe Pakete mit mehreren Ausgaben.). Zum Beispiel installiert folgender Befehl Schriftarten für chinesische Sprachen:

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

Ältere Programme wie xterm benutzen kein Fontconfig, sondern X-Server-seitige Schriftartendarstellung. Solche Programme setzen voraus, dass der volle Name einer Schriftart mit XLFD (X Logical Font Description) angegeben wird, z.B. so:

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

Um solche vollen Namen für die in Ihrem Guix-Profil installierten TrueType-Schriftarten zu verwenden, müssen Sie den Pfad für Schriftarten (Font Path) des X-Servers anpassen:

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

Danach können Sie den Befehl xlsfonts ausführen (aus dem Paket xlsfonts), um sicherzustellen, dass dort Ihre TrueType-Schriftarten aufgeführt sind.

2.4.4 X.509-Zertifikate

Das Paket nss-certs bietet X.509-Zertifikate, womit Programme die Identität von Web-Servern authentifizieren können, auf die über HTTPS zugegriffen wird.

Wenn Sie Guix auf einer Fremddistribution verwenden, können Sie dieses Paket installieren und die relevanten Umgebungsvariablen festlegen, damit Pakete wissen, wo sie Zertifikate finden. Unter X.509-Zertifikate stehen genaue Informationen.

2.4.5 Emacs-Pakete

Wenn Sie Emacs-Pakete mit Guix installieren, werden die Elisp-Dateien innerhalb des Verzeichnisses share/emacs/site-lisp/ in demjenigen Profil platziert, wohin sie installiert werden. Die Elisp-Bibliotheken werden in Emacs über die EMACSLOADPATH-Umgebungsvariable verfügbar gemacht, die durch die Installation von Emacs eingerichtet wird.

Bei der Initialisierung von Emacs werden „Autoload“-Definitionen automatisch über die Guix-spezifische Prozedur guix-emacs-autoload-packages ausgewertet. Sie können diese Prozedur selbst interaktiv aufrufen, damit neu installierte Emacs-Pakete erkannt werden, ohne Emacs neu zu starten. Wenn Sie aber aus irgendeinem Grund die mit Guix installierten Pakete nicht automatisch laden lassen möchten, können Sie Emacs mit der Befehlszeilenoption --no-site-file starten (siehe Init File in The GNU Emacs Manual).

Anmerkung: Die meisten Varianten von Emacs sind mittlerweile in der Lage, Code nativ zu kompilieren. Allerdings verhält sich Guix’ Emacs merklich anders als die Voreinstellungen der Emacs-Macher.

Deren Emacs kompiliert Pakete bei Bedarf („just-in-time“) und legt die Objektdateien („Shared Objects“) in einem eigenen Verzeichnis innerhalb Ihres user-emacs-directory-Verzeichnisses an. Die Objektdateien darin sind in einer flachen Hierarchie angeordnet und tragen Dateinamen mit zwei Hashes, mit denen der ursprüngliche Dateiname und der Inhalt des Quellcodes verifiziert werden.

Guix’ Emacs dagegen kompiliert seine Pakete bevorzugt im Voraus. Objektdateien tragen im Wesentlichen den ursprünglichen Dateinamen ohne zusätzliche Hashes, mit denen Name oder Inhalt verifiziert würde. Das ermöglicht es, für Guix’ Emacs erstellte Pakete zu veredeln (siehe Veredelungen) und obwohl Guix’ Emacs so auch die hashbasierte Verifizierung des Quellcodes wie im Original-Emacs fehlt, kann eine solche Benennung als Sicherheitsmaßnahme ohnehin leicht umgangen werden. Daher schalten wir Just-in-time-Kompilieren ab.

Darüber hinaus sei erwähnt, dass emacs-minimal – die Emacs-Variante, mit der normalerweise Emacs-Pakete erstellt werden – weiterhin keine nativen Befehle generiert. Um native Befehle für Ihre Emacs-Pakete schon im Voraus zu erzeugen, nutzen Sie eine Transformation, z.B. --with-input=emacs-minimal=emacs.