2.4.1 Localidades

Pacotes instalados via Guix não usarão os dados de localidade do sistema host. Em vez disso, você deve primeiro instalar um dos pacotes de localidade disponíveis com Guix e então definir a variável de ambiente GUIX_LOCPATH:

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

Observe que o pacote glibc-locales contém dados para todos os locais suportados pela GNU libc e pesa cerca de 930 MiB⁹. Se você precisar apenas de alguns locais, poderá definir seu pacote de locais personalizados por meio do procedimento make-glibc-utf8-locales do módulo (gnu packages base). O exemplo a seguir define um pacote contendo os vários locais UTF-8 canadenses conhecidos pela GNU libc, que pesa cerca de 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"))

A variável GUIX_LOCPATH desempenha um papel similar a LOCPATH (veja LOCPATH em The GNU C Library Reference Manual). Há duas diferenças importantes, no entanto:

1. GUIX_LOCPATH é honrado apenas pela libc no Guix, e não pela libc fornecida por distros estrangeiras. Assim, usar GUIX_LOCPATH permite que você tenha certeza de que os programas da distro estrangeira não acabarão carregando dados de localidade incompatíveis.
2. libc sufixa cada entrada de GUIX_LOCPATH com /X.Y, onde X.Y é a versão libc—por exemplo, 2.22. Isso significa que, caso seu perfil Guix contenha uma mistura de programas vinculados a diferentes versões libc, cada versão libc tentará carregar apenas dados de localidade no formato correto.

Isso é importante porque o formato de dados de localidade usado por diferentes versões da libc pode ser incompatível.

2.4.2 Name Service Switch

Ao usar o Guix em uma distro alheia, nós recomendamos fortemente que o sistema use o daemon de cache de serviço de nomes da biblioteca C do GNU, nscd, que deve ouvir no soquete /var/run/nscd/socket. Caso não faça isso, os aplicativos instalados com Guix podem falhar em procurar nomes de máquina e contas de usuário, ou até mesmo travar. Os próximos parágrafos explicam o porquê.

A biblioteca GNU C implementa um name service switch (NSS), que é um mecanismo extensível para “pesquisas de nomes” em geral: resolução de nomes de host, contas de usuários e muito mais (veja Name Service Switch em The GNU C Library Reference Manual).

Sendo extensível, o NSS suporta plugins, que fornecem novas implementações de pesquisa de nomes: por exemplo, o plugin nss-mdns permite a resolução de nomes de host .local, o plugin nis permite a pesquisa de contas de usuários usando o Network information service (NIS), e assim por diante. Esses "serviços de pesquisa” extras são configurados em todo o sistema em /etc/nsswitch.conf, e todos os programas em execução no sistema honram essas configurações (veja NSS Configuration File em The GNU C Reference Manual).

Quando eles realizam uma pesquisa de nome — por exemplo chamando a função getaddrinfo em C — os aplicativos primeiro tentam se conectar ao nscd; em caso de sucesso, o nscd realiza pesquisas de nome em seu nome. Se o nscd não estiver em execução, eles realizam a pesquisa de nome sozinhos, carregando os serviços de pesquisa de nome em seu próprio espaço de endereço e executando-o. Esses serviços de pesquisa de nome — os arquivos libnss_*.so — são dlopen’d, mas podem vir da biblioteca C do sistema host, em vez da biblioteca C à qual o aplicativo está vinculado (a biblioteca C vem do Guix).

E é aqui que está o problema: se seu aplicativo estiver vinculado à biblioteca C do Guix (por exemplo, glibc 2.24) e tentar carregar plugins NSS de outra biblioteca C (por exemplo, libnss_mdns.so para glibc 2.22), ele provavelmente travará ou terá suas pesquisas de nome falhando inesperadamente.

Executar nscd no sistema, entre outras vantagens, elimina esse problema de incompatibilidade binária porque esses arquivos libnss_*.so são carregados no processo nscd, não nos próprios aplicativos.

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 Fontes X11

A maioria dos aplicativos gráficos usa o Fontconfig para localizar e carregar fontes e executar renderização do lado do cliente X11. O pacote fontconfig no Guix procura fontes em $HOME/.guix-profile por padrão. Assim, para permitir que aplicativos gráficos instalados com o Guix exibam fontes, você precisa instalar fontes com o Guix também. Pacotes de fontes essenciais incluem font-ghostscript, font-dejavu e font-gnu-freefont.

Depois de instalar ou remover fontes, ou quando notar que um aplicativo não encontra fontes, talvez seja necessário instalar o Fontconfig e forçar uma atualização do cache de fontes executando:

guix install fontconfig
fc-cache -rv

Para exibir texto escrito em chinês, japonês ou coreano em aplicativos gráficos, considere instalar font-adobe-source-han-sans ou font-wqy-zenhei. O primeiro tem várias saídas, uma por família de idiomas (veja Pacotes com múltiplas saídas). Por exemplo, o comando a seguir instala fontes para idiomas chineses:

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

Programas mais antigos como xterm não usam Fontconfig e, em vez disso, dependem da renderização de fontes do lado do servidor. Tais programas exigem a especificação de um nome completo de uma fonte usando XLFD (X Logical Font Description), como este:

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

Para poder usar esses nomes completos para as fontes TrueType instaladas no seu perfil Guix, você precisa estender o caminho da fonte do servidor X:

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

Depois disso, você pode executar xlsfonts (do pacote xlsfonts) para garantir que suas fontes TrueType estejam listadas lá.

2.4.4 Certificados X.509

O pacote nss-certs fornece certificados X.509, que permitem que programas autentiquem servidores Web acessados por HTTPS.

Ao usar uma Guix em uma distro alheia, você pode instalar esse pacote e definir as variáveis de ambiente relevantes de forma que os pacotes saibam onde procurar por certificados. Veja Certificados X.509, para informações detalhadas.

2.4.5 Pacotes Emacs

Quando você instala pacotes do Emacs com o Guix, os arquivos Elisp são colocados no diretório share/emacs/site-lisp/ do perfil no qual eles são instalados. As bibliotecas Elisp são disponibilizadas para o Emacs por meio da variável de ambiente EMACSLOADPATH, que é definida ao instalar o próprio Emacs.

Além disso, as definições de autoload são avaliadas automaticamente na inicialização do Emacs, pelo procedimento específico do Guix guix-emacs-autoload-packages. Este procedimento pode ser invocado interativamente para que pacotes Emacs recém-instalados sejam descobertos, sem precisar reiniciar o Emacs. Se, por algum motivo, você quiser evitar o carregamento automático dos pacotes Emacs instalados com o Guix, você pode fazer isso executando o Emacs com a opção --no-site-file (veja Init File em The GNU Emacs Manual).

Nota: A maioria das variantes do Emacs agora são capazes de fazer compilação nativa. A abordagem adotada pelo Guix Emacs, no entanto, difere muito da abordagem adotada pelo upstream.

O Upstream Emacs compila pacotes just-in-time e normalmente coloca arquivos de objetos compartilhados em uma pasta especial dentro do seu user-emacs-directory. Esses objetos compartilhados dentro da referida pasta são organizados em uma hierarquia plana, e seus nomes de arquivo contêm dois hashes para verificar o nome do arquivo original e o conteúdo do código-fonte.

O Guix Emacs, por outro lado, prefere compilar pacotes antes do tempo. Objetos compartilhados retêm muito do nome do arquivo original e nenhum hashe é adicionado para verificar o nome do arquivo original ou o conteúdo do arquivo. Crucialmente, isso permite que o Guix Emacs e os pacotes construídos contra ele sejam enxertados (veja enxertos), mas, ao mesmo tempo, o Guix Emacs não tem a verificação baseada em hash do código-fonte embutido no Emacs upstream. Como esse esquema de nomenclatura é trivial de explorar, desabilitamos a compilação just-in-time.

Observe ainda que emacs-minimal—o Emacs padrão para construir pacotes—foi configurado sem compilação nativa. Para compilar nativamente seus pacotes emacs antes do tempo, use uma transformação como --with-input=emacs-minimal=emacs.