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

[Federico Beffa]

On Mon, Oct 5, 2015 at 4:35 PM, Ludovic Courtès <address@hidden> wrote:
> Mark H Weaver <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> So with current ‘core-updates’, someone on a “foreign distro” needs to
>>> do:
>>>
>>>   guix package -i glibc-locales
>>>   export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22
>>>
>>> Note the extra “/2.22”, which comes from commit f2d7bbb.  This is a bit
>>> of an annoyance for end users, but the point is that eventually this
>>> would allow us to recommend things like:
>>>
>>>   export 
>>> GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23
>>>
>>> The only question is whether having the “/2.22” prefix by default is a
>>> good idea.  Opinions?
>>
>> I think the "/2.22" suffix will be needed to prevent another awkward
>> transition the next time glibc makes an incompatible change to their
>> locales.  Suppose that 2.23 makes another incompatible change.  After
>> that, many Guix systems will have a mixture of software linked with
>> glibc-2.22 and glibc-2.23.
>
> Yes.  But we could just as well have ‘glibc-utf8-locales’ where
> everything is in lib/locale directly, and ‘glibc-transition-locales’
> where things are under lib/locale/2.22 and lib/locale/2.23.  Dunno.

I'm wondering if it would be better to point GUIX_LOCPATH to

export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

and have 'glibc' itself to append it's own version number to that
string. In this way pre 2.22 programs (last official Guix(SD) release)
would find pre-2.22 locale in '/$HOME/.guix-profile/lib/locale'. The
next releases (with 'glibc-2.22' and following) will provide locales
in versioned sub-directory (no conflict with pre 2.22) and the new
programs will co-exist without users ever having to modify
GUIX_LOCPATH.

Regards,
Fede