On Wed, Sep 30, 2015 at 3:46 PM, Ludovic Courtès <l...@gnu.org> wrote: > Federico Beffa <be...@ieee.org> skribis: > >> On Mon, Sep 28, 2015 at 10:45 PM, Ludovic Courtès <l...@gnu.org> wrote: > > [...] > >> From my point of view Mark's suggestion sounds as the most acceptable > > Which one is it?
For some reason I don't see Mark's message on the ML. So instead of a link, a copy/paste from his email: " I think I know a workaround: leave LOCPATH unset, and make /run/current-system/locale a symlink to freshly generated locales for glibc 2.22. Guix-compiled software is configured to look for locales there if LOCPATH is unset. " > >>> 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 ;-)). >From my point of view either one is much better than the current situation. Thanks, Fede
