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

[Ricardo Wurmus]

Ricardo Wurmus <address@hidden> writes:

> 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.

I just saw your later emails.  Please ignore the above.
Thank you and Mark for having figured out a solution!

~~ Ricardo