Federico Beffa <be...@ieee.org> skribis: > On Mon, Oct 5, 2015 at 4:35 PM, Ludovic Courtès <l...@gnu.org> wrote: >> Mark H Weaver <m...@netris.org> skribis: >> >>> l...@gnu.org (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.
This is what the patch at <http://article.gmane.org/gmane.comp.gnu.guix.devel/12004> does. However, it has the drawback of being fairly intrusive and non-trivial. Intrusive in that it touches libc, and if it doesn’t make it upstream, then we’ll have difficulties dealing with it. Non-trivial in that I think it’s pretty unusual for software to automatically modify search path entries (when defining FOOPATH=/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’m inclined to make the choice that requires the smallest amount of modifications to libc. Thoughts? Ludo’.
