Federico Beffa <be...@ieee.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > > [...] > >> Consequences for Guix on foreign distros: >> >> • If the host distro provides binaries that use libc < 2.22 and you >> use a mixture of Guix-provided and distro-provided programs, this is >> pretty bad. >> >> Solution: unset LOCPATH and say goodbye to locales for Guix-provided >> packages (setting LOCPATH=$HOME/.guix-profile/lib/locale would break >> all the distro-provided programs), or use exclusively Guix-provided >> programs, or use the “C” locale. > > Does this means that Guix on other distributions is no longer of > interest to the Guix project and it is essentially unsupported?
No, definitely not! While suboptimal, the 3 solutions above are probably OK as a temporary measure. For the longer term, I hope we can help improve libc: https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html (I’d like to apply this patch in Guix in the next ‘core-updates’ cycle anyway to mitigate the problem.) > Or is this a transitory situation and an acceptable solution is being > worked on? This is transitory because sooner or later your host distro will upgrade to libc 2.22 as well. 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. Thanks, Ludo’.
