>> As of now [0] a search path ‘GUIX_LOCPATH’ is exported when ‘glibc’ >> package, which does not comprise any locales, is installed. I guess, >> it should belong to ‘glibc-locales’ and ‘glibc-utf8-locales’ instead. > > The idea of search path specifications like ‘GUIX_LOCPATH’ is that the > package that honors them defines them. > > For example, Python defines ‘PYTHONPATH’, Guile defines > ‘GUILE_LOAD_PATH’, and so on.
But locales are honoured by nearly every program. And nearly every program complains when they are not found: --8<---------------cut here---------------start------------->8--- $ guix guile: warning: failed to install locale warning: failed to install locale: Invalid argument --8<---------------cut here---------------end--------------->8--- > In this case, ‘GUIX_LOCPATH’ is honored by glibc, so glibc defines it. >From the user point of view ‘glibc’ is a package that installs catchsegv(1), getconf(1), getent(1), iconv(1), ldd(1), locale(1), localedef(1), makedb(1), mtrace(1), pcprofiledump, sprof(1), tzselect(1) and xtrace(1). At least on top of a foreign distro, when Guix is used as a language-specific package manager for GNU Guile for instance, that is a quite unlikely a package to be installed in the profile. > If instead ‘glibc-utf8-locales’ defined it, then you’d immediately get > the recommendation about setting ‘GUIX_LOCPATH’, which I guess is what > you’d like to see. Yes, that is exactly what I expected as a user: when locales are installed they come into play. > However, every locale-providing package would need to define it, > which is not great. But would not thorough following “search paths are exported by the active side” convention implies that every single package that ships a localized program has to define $GUIX_LOCPATH? That would be about 100 % of packages, I guess. On the other hand, now there are only two locale-providing packages, as I can see: ‘glibc-locales’ and ‘glibc-utf8-locales’. Are there plans to split them up? Is not that supposed to be done by means of ‘outputs’: glibc-locales:en, glibc-locales:fr, etc? (By the way, ‘glibc-utf8-locales’ looks like a misnomer to me, on the first glance on it a user have nothing but to think that it comprises UTF-8 locales for all supported languages.) > On a related note, see this issue about indirect search path > specifications: <https://bugs.gnu.org/22138>. Oops. My bad, I indeed should search for opened bugs more carefully. (I hope it should be possible to merge two issues within debbugs, is not it?)
