guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multi-version system-wide locales


From: Ludovic Courtès
Subject: Multi-version system-wide locales
Date: Fri, 30 Oct 2015 23:14:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello!

I just pushed the last bit to deal with the locale data incompatibility
issue on GuixSD; doc below.

Ludo’.


7.2.6.1 Locale Data Compatibility Considerations
................................................

‘operating-system’ declarations provide a ‘locale-libcs’ field to
specify the GNU libc packages that are used to compile locale
declarations (*note operating-system Reference::).  “Why would I care?”,
you may ask.  Well, it turns out that the binary format of locale data
is occasionally incompatible from one libc version to another.

   For instance, a program linked against libc version 2.21 is unable to
read locale data produced with libc 2.22; worse, that program _aborts_
instead of simply ignoring the incompatible locale data(1).  Similarly,
a program linked against libc 2.22 can read most, but not all, the
locale data from libc 2.21 (specifically, ‘LC_COLLATE’ data is
incompatible); thus calls to ‘setlocale’ may fail, but programs will not
abort.

   The “problem” in GuixSD is that users have a lot of freedom: They can
choose whether and when to upgrade software in their profiles, and might
be using a libc version different from the one the system administrator
used to build the system-wide locale data.

   Fortunately, unprivileged users can also install their own locale
data and define GUIX_LOCPATH accordingly (*note ‘GUIX_LOCPATH’ and
locale packages: locales-and-locpath.).

   Still, it is best if the system-wide locale data at
‘/run/current-system/locale’ is built for all the libc versions actually
in use on the system, so that all the programs can access it—this is
especially crucial on a multi-user system.  To do that, the
administrator can specify several libc packages in the ‘locale-libcs’
field of ‘operating-system’:

     (use-package-modules base)

     (operating-system
       ;; …
       (locale-libcs (list glibc-2.1 (canonical-package glibc))))

   This example would lead to a system containing locale definitions for
both libc 2.21 and the current version of libc in
‘/run/current-system/locale’.

   ---------- Footnotes ----------

   (1) Versions 2.23 and later of GNU libc will simply skip the
incompatible locale data, which is already an improvement.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]