Siguiente: Actualizar Guix, Anterior: Invocación de guix-daemon, Subir: Instalación [Índice general][Índice]
Cuando se usa Guix sobre una distribución GNU/Linux distinta al sistema Guix—una distribución distinta—unos pocos pasos adicionales son necesarios para tener todo preparado. Aquí están algunos de ellos.
Los paquetes instalados a través de Guix no usarán los datos de localización
del sistema anfitrión. En vez de eso, debe instalar primero uno de los
paquetes de localización disponibles con Guix y después definir la variable
de entorno GUIX_LOCPATH:
$ guix install glibc-locales $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
Fíjese que el paquete glibc-locales contiene datos para todas las
localizaciones que ofrece GNU libc y pesa alrededor de 917 MiB. De
manera alternativa, glibc-utf8-locales tiene menor tamaño pero está
limitado a localizaciones UTF-8.
La variable GUIX_LOCPATH juega un rol similar a LOCPATH
(véase LOCPATH en The GNU C Library Reference
Manual). No obstante, hay dos diferencias importantes:
GUIX_LOCPATH es respetada únicamente por la libc dentro de Guix, y no
por la libc que proporcionan las distribuciones distintas. Por tanto, usar
GUIX_LOCPATH le permite asegurarse de que los programas de la
distribución distinta no cargarán datos de localización incompatibles.
GUIX_LOCPATH con /X.Y,
donde X.Y es la versión de libc—por ejemplo, 2.22. Esto
significa que, en caso que su perfil Guix contenga una mezcla de programas
enlazados contra diferentes versiones de libc, cada versión de libc
únicamente intentará cargar datos de localización en el formato correcto.
Esto es importante porque el formato de datos de localización usado por diferentes versiones de libc puede ser incompatible.
Cuando se usa Guix en una distribución distinta, recomendamos
encarecidamente que el sistema ejecute el daemon de caché del servicio
de nombres de la biblioteca de C de GNU, ncsd, que debe escuchar
en el socket /var/run/nscd/socket. En caso de no hacerlo, las
aplicaciones instaladas con Guix pueden fallar al buscar nombres de máquinas
o cuentas de usuaria, o incluso pueden terminar abruptamente. Los siguientes
párrafos explican por qué.
La biblioteca de C de GNU implementa un selector de servicios de nombres (NSS), que es un mecanismo extensible para “búsquedas de nombres” en general: resolución de nombres de máquinas, cuentas de usuaria y más (véase Selector de servicios de nombres en The GNU C Library Reference Manual).
Al ser extensible, NSS permite el uso de módulos, los cuales
proporcionan nuevas implementaciones de búsqueda de nombres: por ejemplo, el
módulo nss-mdns permite la resolución de nombres de máquina
.local, el módulo nis permite la búsqueda de cuentas de
usuaria usando el servicio de información de red (NIS), etc. Estos
“servicios de búsqueda” extra se configuran para todo el sistema en
/etc/nsswitch.conf, y todos los programas en ejecución respetan esta
configuración (véase NSS Configuration File en The GNU C Reference
Manual).
Cuando se realiza una búsqueda de nombres—por ejemplo, llamando a la
función getaddrinfo en C—las aplicaciones primero intentarán
conectar con nscd; en caso satisfactorio, nscd realiza la búsqueda de
nombres en delegación suya. Si nscd no está ejecutándose, entonces realizan
la búsqueda por ellas mismas, cargando los servicios de búsqueda de nombres
en su propio espacio de direcciones y ejecutándola. Estos servicios de
búsqueda de nombres—los archivos libnss_*.so—son abiertos con
dlopen, pero pueden venir de la biblioteca de C del sistema, en vez
de la biblioteca de C contra la que la aplicación está enlazada (la
biblioteca de C que viene en Guix).
Y aquí es donde está el problema: si su aplicación está enlazada contra la
biblioteca de C de Guix (digamos, glibc 2.24) e intenta cargar módulos de
otra biblioteca de C (digamos, libnss_mdns.so para glibc 2.22),
probablemente terminará abruptamente o sus búsquedas de nombres fallarán
inesperadamente.
Ejecutar nscd en el sistema, entre otras ventajas, elimina este
problema de incompatibilidad binaria porque esos archivos libnss_*.so
se cargan en el proceso nscd, no en la aplicación misma.
La mayoría de aplicaciones gráficas usan Fontconfig para encontrar y cargar
tipografías y realizar la renderización del lado del cliente X11. El paquete
fontconfig en Guix busca tipografías en $HOME/.guix-profile
por defecto. Por tanto, para permitir a aplicaciones gráficas instaladas con
Guix mostrar tipografías, tiene que instalar las tipografías también con
Guix. Paquetes esenciales de tipografías incluyen gs-fonts,
font-dejavu y font-gnu-freefont.
Una vez que haya instalado o borrado tipografías, o cuando se de cuenta de que una aplicación no encuentra las tipografías, puede que necesite instalar Fontconfig y forzar una actualización de su caché de tipografías ejecutando:
guix install fontconfig fc-cache -rv
Para mostrar texto escrito en lenguas chinas, Japonés o Coreano en
aplicaciones gráficas, considere instalar font-adobe-source-han-sans
o font-wqy-zenhei. La anterior tiene múltiples salidas, una por
familia de lengua (véase Paquetes con múltiples salidas). Por ejemplo, la
siguiente orden instala tipografías para lenguas chinas:
guix install font-adobe-source-han-sans:cn
Programas más antiguos como xterm no usan Fontconfig sino que
dependen en el lado del servidor para realizar el renderizado de
tipografías. Dichos programas requieren especificar un nombre completo de
tipografía usando XLFD (Descripción lógica de tipografías X), como esta:
-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1
Para ser capaz de usar estos nombres completos para las tipografías TrueType instaladas en su perfil Guix, necesita extender la ruta de fuentes del servidor X:
xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))
Después de eso, puede ejecutar xlsfonts (del paquete xlsfonts)
para asegurarse que sus tipografías TrueType se enumeran aquí.
El paquete nss-certs proporciona certificados X.509, que permiten a
los programas verificar los servidores accedidos por HTTPS.
Cuando se usa Guix en una distribución distinta, puede instalar este paquete y definir las variables de entorno relevantes de modo que los paquetes sepan dónde buscar los certificados. Véase Certificados X.509, para información detallada.
Cuando instale paquetes de Emacs con Guix los archivos de Elisp se
encuentran en el directorio share/emacs/site-lisp/ del perfil en el
que se instalen. Las bibliotecas de Elisp se ponen a disposición de Emacs a
través de la variable de entorno EMACSLOADPATH, a la cual se le asigna
un valor cuando se instale el propio Emacs.
De manera adicional, las definiciones de carga automática se evaluan de
manera automática en la inicialización de Emacs, mediante el procedimiento
guix-emacs-autoload-packages específico de Guix. Si, por alguna
razón, desea evitar la carga automática de paquetes Emacs instalados con
Guix, puede hacerlo ejecutando Emacs con la opción --no-site-file
(véase Init File en The GNU Emacs Manual).
Siguiente: Actualizar Guix, Anterior: Invocación de guix-daemon, Subir: Instalación [Índice general][Índice]