Próximo: Atualizando o Guix, Anterior: Invocando guix-daemon
, Acima: Instalação [Conteúdo][Índice]
Ao usar Guix sobre uma distribuição GNU/Linux que não seja um Guix System — uma chamada distro alheia — algumas etapas adicionais são necessárias para colocar tudo no seu lugar. Aqui estão algumas delas.
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 MiB9. 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:
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.
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.
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.
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á.
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.
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.
O
tamanho do pacote glibc-locales
é reduzido para cerca de 213 MiB
com desduplicação de armazém e ainda mais para cerca de 67 MiB ao usar
um sistema de arquivos Btrfs compactado em zstd.
Próximo: Atualizando o Guix, Anterior: Invocando guix-daemon
, Acima: Instalação [Conteúdo][Índice]