[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather tha
From: |
Dmitry Alexandrov |
Subject: |
bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’? |
Date: |
Tue, 06 Jun 2017 04:33:09 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
>> 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?)