Next: Upgrading Guix, Previous: Invocando guix-daemon
, Up: Instalação [Contents][Index]
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.
Packages installed via Guix will not use the locale data of the host
system. Instead, you must first install one of the locale packages
available with Guix and then define the GUIX_LOCPATH
environment
variable:
$ 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 MiB9. 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"))
The GUIX_LOCPATH
variable plays a role similar to LOCPATH
(see LOCPATH
in The GNU C Library Reference
Manual). There are two important differences though:
GUIX_LOCPATH
is honored only by the libc in Guix, and not by the libc
provided by foreign distros. Thus, using GUIX_LOCPATH
allows you to
make sure the programs of the foreign distro will not end up loading
incompatible locale data.
GUIX_LOCPATH
with /X.Y
, where
X.Y
is the libc version—e.g., 2.22
. This means that, should
your Guix profile contain a mixture of programs linked against different
libc version, each libc version will only try to load locale data in the
right format.
This is important because the locale data format used by different libc versions may be incompatible.
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ê.
The GNU C library implements a name service switch (NSS), which is an extensible mechanism for “name lookups” in general: host name resolution, user accounts, and more (see Name Service Switch in The GNU C Library Reference Manual).
Being extensible, the NSS supports plugins, which provide new name
lookup implementations: for example, the nss-mdns
plugin allow
resolution of .local
host names, the nis
plugin allows user
account lookup using the Network information service (NIS), and so on.
These extra “lookup services” are configured system-wide in
/etc/nsswitch.conf, and all the programs running on the system honor
those settings (see NSS Configuration File in The GNU C Reference
Manual).
When they perform a name lookup—for instance by calling the
getaddrinfo
function in C—applications first try to connect to the
nscd; on success, nscd performs name lookups on their behalf. If the nscd
is not running, then they perform the name lookup by themselves, by loading
the name lookup services into their own address space and running it. These
name lookup services—the libnss_*.so files—are dlopen
’d,
but they may come from the host system’s C library, rather than from the C
library the application is linked against (the C library coming from Guix).
And this is where the problem is: if your application is linked against
Guix’s C library (say, glibc 2.24) and tries to load NSS plugins from
another C library (say, libnss_mdns.so
for glibc 2.22), it will
likely crash or have its name lookups fail unexpectedly.
Running nscd
on the system, among other advantages, eliminates
this binary incompatibility problem because those libnss_*.so
files
are loaded in the nscd
process, not in applications themselves.
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
.
Once you have installed or removed fonts, or when you notice an application that does not find fonts, you may need to install Fontconfig and to force an update of its font cache by running:
guix install fontconfig fc-cache -rv
To display text written in Chinese languages, Japanese, or Korean in
graphical applications, consider installing
font-adobe-source-han-sans
or font-wqy-zenhei
. The former has
multiple outputs, one per language family (see Pacotes com múltiplas saídas). For instance, the following command installs fonts for Chinese
languages:
guix install font-adobe-source-han-sans:cn
Older programs such as xterm
do not use Fontconfig and instead
rely on server-side font rendering. Such programs require to specify a full
name of a font using XLFD (X Logical Font Description), like this:
-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1
To be able to use such full names for the TrueType fonts installed in your Guix profile, you need to extend the font path of the X server:
xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))
After that, you can run xlsfonts
(from xlsfonts
package) to
make sure your TrueType fonts are listed there.
The nss-certs
package provides X.509 certificates, which allow
programs to authenticate Web servers accessed over 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. See Certificados X.509, para informações detalhadas.
When you install Emacs packages with Guix, the Elisp files are placed under
the share/emacs/site-lisp/ directory of the profile in which they are
installed. The Elisp libraries are made available to Emacs through the
EMACSLOADPATH
environment variable, which is set when installing Emacs
itself.
Additionally, autoload definitions are automatically evaluated at the
initialization of Emacs, by the Guix-specific
guix-emacs-autoload-packages
procedure. 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).
Nota: Emacs can now compile packages natively. Under the default configuration, this means that Emacs packages will now be just-in-time (JIT) compiled as you use them, and the results stored in a subdirectory of your
user-emacs-directory
.Furthermore, the build system for Emacs packages transparently supports native compilation, but 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.
The size of the glibc-locales
package is
reduced down to about 213 MiB with store deduplication and further down
to about 67 MiB when using a zstd-compressed Btrfs file system.
Next: Upgrading Guix, Previous: Invocando guix-daemon
, Up: Instalação [Contents][Index]