Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’?

DoneSubmitted by Dmitry Alexandrov.
Details
2 participants
  • Dmitry Alexandrov
  • Ludovic Courtès
Owner
unassigned
Severity
normal
D
D
Dmitry Alexandrov wrote on 5 Jun 2017 03:58
Should not $GUIX_LOCPATH belong to ‘glibc-local es’ rather than ‘glibc’?
(address . bug-guix@gnu.org)
87shjf8abx.fsf@gmail.com
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.
[0] http://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=3bee4b619#n740
L
L
Ludovic Courtès wrote on 5 Jun 2017 22:39
Re: bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘ glibc’?
(name . Dmitry Alexandrov)(address . 321942@gmail.com)(address . 27244@debbugs.gnu.org)
87inka9nk4.fsf@gnu.org
Hi Dmitry,
Dmitry Alexandrov <321942@gmail.com> skribis:
Toggle quote (4 lines)> 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 thepackage that honors them defines them.
For example, Python defines ‘PYTHONPATH’, Guile defines‘GUILE_LOAD_PATH’, and so on.
In this case, ‘GUIX_LOCPATH’ is honored by glibc, so glibc defines it.
If instead ‘glibc-utf8-locales’ defined it, then you’d immediately getthe recommendation about setting ‘GUIX_LOCPATH’, which I guess is whatyou’d like to see. However, every locale-providing package would needto define it, which is not great.
On a related note, see this issue about indirect search pathspecifications: https://bugs.gnu.org/22138.
Does it make sense?
Thanks for your message,Ludo’.
D
D
Dmitry Alexandrov wrote on 6 Jun 2017 03:33
(name . Ludovic Courtès)(address . ludo@gnu.org)
87zidl294a.fsf@gmail.com
Toggle quote (10 lines)>> 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 everyprogram complains when they are not found:
Toggle snippet (5 lines)$ guixguile: warning: failed to install localewarning: failed to install locale: Invalid argument
Toggle quote (2 lines)> In this case, ‘GUIX_LOCPATH’ is honored by glibc, so glibc defines it.
From the user point of view ‘glibc’ is a package that installscatchsegv(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 alanguage-specific package manager for GNU Guile for instance, that is aquite unlikely a package to be installed in the profile.
Toggle quote (4 lines)> 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 areinstalled they come into play.
Toggle quote (3 lines)> However, every locale-providing package would need to define it,> which is not great.
But would not thorough following “search paths are exported by theactive side” convention implies that every single package that ships alocalized program has to define $GUIX_LOCPATH? That would be about100 % 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 thereplans 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 thefirst glance on it a user have nothing but to think that it comprisesUTF-8 locales for all supported languages.)
Toggle quote (3 lines)> 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, isnot it?)
L
L
Ludovic Courtès wrote on 7 Jun 2017 00:57
(name . Dmitry Alexandrov)(address . 321942@gmail.com)(address . 27244@debbugs.gnu.org)
87tw3s7mi3.fsf@gnu.org
Dmitry Alexandrov <321942@gmail.com> skribis:
Toggle quote (17 lines)>>> 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:>> $ guix> guile: warning: failed to install locale> warning: failed to install locale: Invalid argument
Yeah.
Toggle quote (11 lines)>> 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.
Right.
Toggle quote (15 lines)>> 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.
Correct.
Toggle quote (5 lines)> 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?
There are no concrete plans no. The problem is that any split is reallyarbitrary.
Toggle quote (4 lines)> (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.)
It is! The manual clearly warns about it, saying that it’s “limited toa few UTF-8 locales”:https://gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales.
Note that the Guix 0.13.0 binary tarball comes with glibc-utf8-localesand glibc, such that its etc/profile defines ‘GUIX_LOCPATH’.
Toggle quote (7 lines)>> 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?)
Yes we can merge them.
Thanks,Ludo’.
D
D
Dmitry Alexandrov wrote on 7 Jun 2017 09:06
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27244@debbugs.gnu.org)
87k24oz38e.fsf@gmail.com
Toggle quote (49 lines)>>>> 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:>>>> $ guix>> guile: warning: failed to install locale>> warning: failed to install locale: Invalid argument>> Yeah.>>>> 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.>> Right.>>>> 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.>> Correct.
So...? If moving search path definitions to the packages thatactually provide searchable stuff is not feasible, anotherforeign-distro-user-friendly option, I can imagine, is to have apackage (a ‘virtual package’, if you will) that would only add asearch path to etc/profile without installing any executables.
That approach might benefit to a user of Guix on top of a anotherdistro not only with respect to $GUIX_LOCPATH. I hope, to be able,for example, to read documentation of Guix-installed programs with/usr/bin/emacs or /usr/bin/info or even /usr/bin/tkinfo rather thanemacs(1) / info(1) from Guix is a fairly reasonable wish, so having apackage that only appends $INFOPATH would be nice. ‘emacs’ and‘texinfo’ packages would have it as propagated dependency.
Toggle quote (19 lines)>> 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?>> There are no concrete plans no. The problem is that any split is really> arbitrary.>>> (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.)>> It is! The manual clearly warns about it, saying that it’s “limited to> a few UTF-8 locales”:> <https://gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales>.>> Note that the Guix 0.13.0 binary tarball comes with glibc-utf8-locales> and glibc, such that its etc/profile defines ‘GUIX_LOCPATH’.
Excuse me? I far as I understand, etc/profile is managed onper-profile (i. e. per-user) basis. Thus $GUIX_LOCPATH is notexported until every user explicitly installs ‘glibc’ (along with allits bin/ldd, etc). Or did I miss something?
Toggle quote (8 lines)>>> 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?)>> Yes we can merge them.
L
L
Ludovic Courtès wrote on 7 Jun 2017 11:40
(name . Dmitry Alexandrov)(address . 321942@gmail.com)(address . 27244@debbugs.gnu.org)
87efuwuod4.fsf@gnu.org
Hi Dmitry,
Dmitry Alexandrov <321942@gmail.com> skribis:
Toggle quote (16 lines)>>>> 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.>>>> Correct.>> So...? If moving search path definitions to the packages that> actually provide searchable stuff is not feasible, another> foreign-distro-user-friendly option, I can imagine, is to have a> package (a ‘virtual package’, if you will) that would only add a> search path to etc/profile without installing any executables.
I believe the right way to address this issue is by fixinghttps://bugs.gnu.org/22138. Meta-packages sound more like aworkaround to me.
Toggle quote (8 lines)> That approach might benefit to a user of Guix on top of a another> distro not only with respect to $GUIX_LOCPATH. I hope, to be able,> for example, to read documentation of Guix-installed programs with> /usr/bin/emacs or /usr/bin/info or even /usr/bin/tkinfo rather than> emacs(1) / info(1) from Guix is a fairly reasonable wish, so having a> package that only appends $INFOPATH would be nice. ‘emacs’ and> ‘texinfo’ packages would have it as propagated dependency.
Guix allows users to do that, but IMO we should not try to support thisuse case—using /usr/bin/foo to access Guix-provided files—in Guixproper, for at least one reason: there are many cases where it wouldn’twork (PYTHONPATH, etc.).
Toggle quote (16 lines)>>> (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.)>>>> It is! The manual clearly warns about it, saying that it’s “limited to>> a few UTF-8 locales”:>> <https://gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales>.>>>> Note that the Guix 0.13.0 binary tarball comes with glibc-utf8-locales>> and glibc, such that its etc/profile defines ‘GUIX_LOCPATH’.>> Excuse me? I far as I understand, etc/profile is managed on> per-profile (i. e. per-user) basis. Thus $GUIX_LOCPATH is not> exported until every user explicitly installs ‘glibc’ (along with all> its bin/ldd, etc). Or did I miss something?
No you’re right, this has to be done per-profile. I was referring tothe profile that’s in the binary tarball.
Thanks for your feedback,Ludo’.
L
L
Ludovic Courtès wrote on 27 Jul 2017 14:30
control message for bug #27244
(address . control@debbugs.gnu.org)
87inie3vvt.fsf@gnu.org
tags 27244 notabugclose 27244
?
Your comment

This issue is archived.

To comment on this conversation send email to 27244@debbugs.gnu.org