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. Regards, Fede
