Re: Preparing for the libc/locale upgrade

[Federico Beffa]

On Wed, Sep 30, 2015 at 3:46 PM, Ludovic Courtès <address@hidden> wrote:
> Federico Beffa <address@hidden> skribis:
>
>> On Mon, Sep 28, 2015 at 10:45 PM, Ludovic Courtès <address@hidden> wrote:
>
> [...]
>
>> From my point of view Mark's suggestion sounds as the most acceptable
>
> Which one is it?

For some reason I don't see Mark's message on the ML. So instead of a
link, a copy/paste from his email:

"
I think I know a workaround: leave LOCPATH unset, and make
/run/current-system/locale a symlink to freshly generated locales for
glibc 2.22.  Guix-compiled software is configured to look for locales
there if LOCPATH is unset.
"

>
>>> IMO Guix is not at fault; rather, it sheds light on a shortcoming of
>>> libc’s handling of locale data, which was designed with single-libc
>>> systems in mind.
>>
>> I fully agree with your statement. However, leaving Guix users (I'm
>> not talking about developers) exposed to such problems is not what I
>> expect from a high quality product.
>
> I agree.
>
>> A brute force fix may be to tell each Guix program where the locale is
>> with a wrapper. This is for sure not elegant (and there may be better
>> ways, you know better...), but the point is that probably a way to
>> preserve a good end user experience out of the box does exist and,
>> from my point of view, we should provide it.
>
> Well, we could ship 110+ MiB of locales along with our libc, as we used
> to do¹; adding a wrapper basically amounts to this.  That way, no need
> to fiddle with LOCPATH, the right locale data will always be found.
>
> But honestly, I think that sucks.  It shouldn’t be all-or-nothing.
>
> Alternately, we could patch our libc to honor GUIX_LOCPATH (in addition
> to LOCPATH), so that the host distro’s programs are unaffected, and thus
> don’t end up aborting with that assertion failure.
>
> That’s the best kludge that comes to mind (yeah that’s an oxymoron ;-)).

>From my point of view either one is much better than the current situation.

Thanks,
Fede