From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Preparing for the libc/locale upgrade Date: Wed, 30 Sep 2015 15:46:03 +0200 Message-ID: <87pp10qauc.fsf@gnu.org> References: <871tdi6zo1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhHiA-0000Hg-S6 for guix-devel@gnu.org; Wed, 30 Sep 2015 09:46:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhHi9-0004uy-KA for guix-devel@gnu.org; Wed, 30 Sep 2015 09:46:22 -0400 In-Reply-To: (Federico Beffa's message of "Wed, 30 Sep 2015 14:35:56 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Federico Beffa Cc: Guix-devel Federico Beffa skribis: > On Mon, Sep 28, 2015 at 10:45 PM, Ludovic Court=C3=A8s wro= te: [...] > 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=E2=80=99s handling of locale data, which was designed with single-l= ibc >> 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+=C2=A0MiB of locales along with our libc, as we used to do=C2=B9; 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=E2=80=99t be all-or-nothing. Alternately, we could patch our libc to honor GUIX_LOCPATH (in addition to LOCPATH), so that the host distro=E2=80=99s programs are unaffected, and= thus don=E2=80=99t end up aborting with that assertion failure. That=E2=80=99s the best kludge that comes to mind (yeah that=E2=80=99s an o= xymoron ;-)). Thoughts? Thanks, Ludo=E2=80=99. =C2=B9 http://bugs.gnu.org/18085