From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH Date: Mon, 05 Oct 2015 21:39:53 +0200 Message-ID: <87r3l985py.fsf@gnu.org> References: <1443736716-8578-1-git-send-email-ludo@gnu.org> <87oagfrq41.fsf@mdc-berlin.de> <87mvvzrpsf.fsf@mdc-berlin.de> <87bnce7r1j.fsf@gnu.org> <87fv1qvag8.fsf@netris.org> <878u7h1izb.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]:38321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjBc6-0007Or-A4 for guix-devel@gnu.org; Mon, 05 Oct 2015 15:39:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjBc4-0001TG-Vr for guix-devel@gnu.org; Mon, 05 Oct 2015 15:39:58 -0400 In-Reply-To: (Federico Beffa's message of "Mon, 5 Oct 2015 17:38:06 +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, Oct 5, 2015 at 4:35 PM, Ludovic Court=C3=A8s wrote: >> Mark H Weaver skribis: >> >>> ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> >>>> So with current =E2=80=98core-updates=E2=80=99, someone on a =E2=80=9C= foreign distro=E2=80=9D needs to >>>> do: >>>> >>>> guix package -i glibc-locales >>>> export GUIX_LOCPATH=3D$HOME/.guix-profile/lib/locale/2.22 >>>> >>>> Note the extra =E2=80=9C/2.22=E2=80=9D, which comes from commit f2d7bb= b. 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=3D$HOME/.guix-profile/lib/locale/2.22:$HOME/.gui= x-profile/lib/locale/2.23 >>>> >>>> The only question is whether having the =E2=80=9C/2.22=E2=80=9D 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 =E2=80=98glibc-utf8-locales=E2=80= =99 where >> everything is in lib/locale directly, and =E2=80=98glibc-transition-loca= les=E2=80=99 >> 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=3D$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. This is what the patch at does. However, it has the drawback of being fairly intrusive and non-trivial. Intrusive in that it touches libc, and if it doesn=E2=80=99t make it upstre= am, then we=E2=80=99ll have difficulties dealing with it. Non-trivial in that I think it=E2=80=99s pretty unusual for software to automatically modify sear= ch path entries (when defining FOOPATH=3D/x:/y, one expects Foo to look under /x and /y, not under /x/2.22.) None of these two approaches is perfect, but I=E2=80=99m inclined to make t= he choice that requires the smallest amount of modifications to libc. Thoughts? Ludo=E2=80=99.