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

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> After a lot more thought, I changed my mind.
>>
>> I realized that with the patch at
>> <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>, it’s OK to
>> have, say,
>>
>>   
>> LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23
>>
>> That way, programs will pick locale data that is compatible; so a 2.23
>> program might pick most of its locale data from the /2.22 directory (if
>> they are compatible), and some of them from /2.23 (if the format has
>> changed.)
>
> I'm a bit uncomfortable with this.  A few questions:
>
> * Will your glibc patch reliably ensure that no functionality is lost
>   because of picking up the wrong version of locales?

If locale data is missing or incompatible, ‘setlocale’ returns ENOENT or
EINVAL.  That’s the worst that can happen.

> * Do we have a mechanism for automatically setting LOCPATH (or
>   GUIX_LOCPATH) to include all of the available locale versioned
>   subdirectories?

No.

This is not a problem on GuixSD because we would populate
/run/current-system/locale/{2.22,2.23} by default and rarely need to
fiddle with GUIX_LOCPATH.

On foreign distros, it means people have to maintain GUIX_LOCPATH by
hand; this is already the case, but now they’d have to append “/2.22”
and possibly other subdirectories.

Ludo’.