Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> writes:

> The first patch adds the 'GUIX_LOCPATH' environment variable, the idea being
> that on foreign distros, users could set this variable instead of 'LOCPATH',
> and the host distro's programs wouldn't break.
>
> The second patch was suggested by Mark.  It basically adds "/2.22" to every
> directory name specified in LOCPATH, as well as to the default locale
> directory.  The idea here is that libc would only stumble on compatible
> locale data.
>
> Actually with that second patch, I think 'GUIX_LOCPATH' is unneeded, because
> effectively Guix's libc would already be interpreting 'LOCPATH' differently.
> So my inclination would be to apply only the second one.

I think that ‘GUIX_LOCPATH’ would still be useful for foreign systems
using Guix as a package manager.  IIUC, the default location where our
libc looks for locale data is somewhere under ‘/run/current-system’,
which would have to be created on non-GuixSD systems.

If only the LOCPATH patch were applied, users of non-GuixSD systems
would have to make sure that ‘/run/current-system/..../2.22/’ exists and
points to valid locale data.  With support for ‘GUIX_LOCPATH’ users of
this system could just install locale data into a profile and set
‘GUIX_LOCPATH’ accordingly without having to additionally manage a
symlink named ‘/run/current-system/.../2.22’.

This is especially useful in shared systems where users would otherwise
have to ask a system administrator to also provide this additional link
so that the Guix libc default lookup location can be satisfied.

But maybe I misunderstood.  If so, I’d be happy if you could clarify.

Thanks!

~~ Ricardo