Ricardo Wurmus <[email protected]> writes: > Ludovic Courtès <[email protected]> writes: > >> The first patch adds the 'GUIX_LOCPATH' environment variable, the idea being >> that on foreign distros, users could set this variable instead of 'LOCPATH', >> and the host distro's programs wouldn't break. >> >> The second patch was suggested by Mark. It basically adds "/2.22" to every >> directory name specified in LOCPATH, as well as to the default locale >> directory. The idea here is that libc would only stumble on compatible >> locale data. >> >> Actually with that second patch, I think 'GUIX_LOCPATH' is unneeded, because >> effectively Guix's libc would already be interpreting 'LOCPATH' differently. >> So my inclination would be to apply only the second one. > > I think that ‘GUIX_LOCPATH’ would still be useful for foreign systems > using Guix as a package manager. IIUC, the default location where our > libc looks for locale data is somewhere under ‘/run/current-system’, > which would have to be created on non-GuixSD systems. > > If only the LOCPATH patch were applied, users of non-GuixSD systems > would have to make sure that ‘/run/current-system/..../2.22/’ exists and > points to valid locale data. With support for ‘GUIX_LOCPATH’ users of > this system could just install locale data into a profile and set > ‘GUIX_LOCPATH’ accordingly without having to additionally manage a > symlink named ‘/run/current-system/.../2.22’. > > This is especially useful in shared systems where users would otherwise > have to ask a system administrator to also provide this additional link > so that the Guix libc default lookup location can be satisfied. > > But maybe I misunderstood. If so, I’d be happy if you could clarify.
I just saw your later emails. Please ignore the above. Thank you and Mark for having figured out a solution! ~~ Ricardo
