2.4.1 Региональные настройки

Пакеты, установленные с помощью Guix, не будут использовать данные локали хост-системы. Вместо этого вы должны вначале установить один из пакетов локали, доступных в Guix, а затем определить переменную окружения 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 930 MiB⁹. If you only need a few locales, you can define your custom locales package via the make-glibc-utf8-locales procedure from the (gnu packages base) module. The following example defines a package containing the various Canadian UTF-8 locales known to the GNU libc, that weighs around 14 MiB:

(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"))

Переменная GUIX_LOCPATH играет ту же роль, что и LOCPATH (see LOCPATH in The GNU C Library Reference Manual). Но есть два существенных различия:

1. GUIX_LOCPATH учитывается только libc в Guix, но не учитывается libc, предоставляемым чужим дистрибутивом. Так что использование GUIX_LOCPATH позволяет вам убедиться, что программы чужого дистрибутива не будут производить загрузку несовместимых данных локали.
2. libc добавляет суффиксы /X.Y к каждому компоненту GUIX_LOCPATH, где X.Y - это версия libc, например, 2.22. Это значит, что если ваш профиль Guix будет содержать смесь программ, связанных с дугой версией libc, каждая версия libc будет пытаться загружать только данные локали в правильном формате.

Это важно, потому что использование данных локали другой версией libc может быть неприемлемо.

2.4.2 Переключатель службы имен

При использовании Guix на чужом дистрибутиве мы настойчиво рекомендуем, чтобы система запускала демон кеша имён сервисов библиотеки GNU C, nscd, который должен слушать сокет /var/run/nscd/socket. Если это не сделано, приложения, установленные Guix, могут некорректно адресовать имена хостов или аккаунты пользователей и даже падать. Ниже объясняется почему.

Библиотека GNU C реализует выбор имён сервисов (NSS), который представляет собой расширяемый механизм для резолвинга имён в целом: резолвинг имён хостов, аккаунтов пользователей и другое (see Name Service Switch in The GNU C Library Reference Manual).

Будучи расширяемым, NSS поддерживает плагины, которые предоставляют реализации разрешения новых имён: плагин nss-mdns резолвит имена хостов .local, плагин nis адресует пользовательские аккаунты, используя сервис сетевой информации (NIS) и т.д. Эти дополнительные сервисы адресации настраиваются для всей системы в /etc/nsswitch.conf, и все запущенные в системе программы учитывают эти настройки (see NSS Configuration File in The GNU C Reference Manual).

Когда выполняется разрешение имён, например, вызовом функции C getaddrinfo, приложения вначале делают попытку соединиться с nscd; в случае успеха nscd выполняет разрешение имён по их запросу. Если nscd не запущен, тогда они выполняют разрешение имён самостоятельно, загружая сервисы разрешения имён в их собственные адресные пространства и запуская их. Эти сервисы разрешения имён — файлы libnss_*.so — запускаются dlopen, но они могут поставляться системной библиотекой C, а не библиотекой C, с которой залинковано приложение (библиотека C из Guix).

Вот где кроется проблема — если ваше приложение залинковано с библиотекой C Guix (скажем, glibc 2.24) и пытается загрузить плагины NSS из другой библиотеки C (скажем, libnss_mdns.so для glibc 2.22), это вероятно вызовет падение или резолвинг имени завершится с ошибкой.

Запуск nscd в системе, помимо преимуществ, также исключает эту проблему несовместимости программ, потому что файлы libnss_*.so загружены в процессе nscd, а не в самом приложении.

Note that nscd is no longer provided on some GNU/Linux distros, such as Arch Linux (as of Dec. 2024). nsncd can be used as a drop-in-replacement. See the nsncd repository and this blog post for more information.

2.4.3 Шрифты X11

The majority of graphical applications use Fontconfig to locate and load fonts and perform X11-client-side rendering. The fontconfig package in Guix looks for fonts in $HOME/.guix-profile by default. Thus, to allow graphical applications installed with Guix to display fonts, you have to install fonts with Guix as well. Essential font packages include font-ghostscript, font-dejavu, and font-gnu-freefont.

После того, как вы установили или удалили шрифты, или когда вы заметили приложение, которое не находит шрифты, вам может потребоваться установить Fontconfig и принудительно обновить кэш шрифтов, выполнив:

guix install fontconfig
fc-cache -rv

Для отображения в графических приложениях текста на китайском, японском, корейском нужно установить font-adobe-source-han-sans или font-wqy-zenhei. Первый имеет множественный выход, один для языковой семьи (see Пакеты со множественным выходом). Например, следующая команда устанавливает шрифты для китайских языков:

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

Старые программы, например, xterm, не используют Fontconfig, а вместо этого вызывают рендеринг шрифтов на стороне сервера. Таким программам необходимо указывать полное имя шрифта, используя XLFD (X Logical Font Description), примерно так:

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

Чтобы иметь возможность использовать такие полные имена для шрифтов TrueType, установленных в вашем профиле Guix, вам нужно расширить пути шрифтов X-сервера:

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

После этого можно запустить xlsfonts (из пакета xlsfonts), чтобы убедиться, что ваши шрифты TrueType находятся там.

2.4.4 Сертификаты X.509

Пакет nss-certs предоставялет сертификаты X.509, которые позволяют программам аутентифицировать веб-серверы и работать через HTTPS.

При использовании Guix на чужом дистрибутиве можно установить этот пакет и определить соответствующие переменные окружения, чтобы пакеты знали, где искать сертификаты. Смотрите See Сертификаты X.509 для подробной информации.

2.4.5 Пакеты Emacs

Когда вы устанавливаете пакеты Emacs с Guix, файлы пакетов помещаются в каталог share/emacs/site-lisp/ того профиля, в котором они установлены. Библиотеки Elisp доступны для Emacs через переменную среды EMACSLOADPATH, которая устанавливается при установке самого Emacs.

Additionally, autoload definitions are automatically evaluated at the initialization of Emacs, by the Guix-specific guix-emacs-autoload-packages procedure. This procedure can be interactively invoked to have newly installed Emacs packages discovered, without having to restart Emacs. 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 (see Init File in The GNU Emacs Manual).

Примечание: Most Emacs variants are now capable of doing native compilation. The approach taken by Guix Emacs however differs greatly from the approach taken upstream.

Upstream Emacs compiles packages just-in-time and typically places shared object files in a special folder within your user-emacs-directory. These shared objects within said folder are organized in a flat hierarchy, and their file names contain two hashes to verify the original file name and contents of the source code.

Guix Emacs on the other hand prefers to compile packages ahead-of-time. Shared objects retain much of the original file name and no hashes are added to verify the original file name or the contents of the file. Crucially, this allows Guix Emacs and packages built against it to be grafted (see grafts), but at the same time, Guix Emacs lacks the hash-based verification of source code baked into upstream Emacs. As this naming schema is trivial to exploit, we disable just-in-time compilation.

Further note, that emacs-minimal—the default Emacs for building packages—has been configured without native compilation. To natively compile your emacs packages ahead of time, use a transformation like --with-input=emacs-minimal=emacs.