bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’?

[Dmitry Alexandrov]

>> 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?)