Re: Preparing for the libc/locale upgrade

[Ludovic Courtès]

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?

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

Thoughts?

Thanks,
Ludo’.

¹ http://bugs.gnu.org/18085