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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27244 in the body.
You can then email your comments to 27244 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <321942 <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’?
Date: Mon, 05 Jun 2017 04:58:10 +0300

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

Message #8 received at 27244 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Dmitry Alexandrov <321942 <at> gmail.com>
Cc: 27244 <at> debbugs.gnu.org
Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to
 ‘glibc-locales’ rather than ‘glibc’?
Date: Mon, 05 Jun 2017 22:39:23 +0200

Hi Dmitry,

Dmitry Alexandrov <321942 <at> gmail.com> skribis:

> 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.

In this case, ‘GUIX_LOCPATH’ is honored by glibc, so glibc defines it.

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.  However, every locale-providing package would need
to define it, which is not great.

On a related note, see this issue about indirect search path
specifications: <https://bugs.gnu.org/22138>.

Does it make sense?

Thanks for your message,
Ludo’.

Message #11 received at 27244 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <321942 <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: Dmitry Alexandrov <321942 <at> gmail.com>, 27244 <at> debbugs.gnu.org
Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to
 ‘glibc-locales’ rather than ‘glibc’?
Date: Tue, 06 Jun 2017 04:33:09 +0300

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

Message #14 received at 27244 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Dmitry Alexandrov <321942 <at> gmail.com>
Cc: 27244 <at> debbugs.gnu.org
Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to
 ‘glibc-locales’ rather than ‘glibc’?
Date: Wed, 07 Jun 2017 00:57:24 +0200

Dmitry Alexandrov <321942 <at> gmail.com> skribis:

>>> 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.

> 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’.

>> 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’.

Message #17 received at 27244 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <321942 <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 27244 <at> debbugs.gnu.org
Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to
 ‘glibc-locales’ rather than ‘glibc’?
Date: Wed, 07 Jun 2017 10:06:09 +0300

>>>> 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 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.

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.

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

>>> 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.

Message #20 received at 27244 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Dmitry Alexandrov <321942 <at> gmail.com>
Cc: 27244 <at> debbugs.gnu.org
Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to
 ‘glibc-locales’ rather than ‘glibc’?
Date: Wed, 07 Jun 2017 11:40:55 +0200

Hi Dmitry,

Dmitry Alexandrov <321942 <at> gmail.com> skribis:

>>>> 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 fixing
<https://bugs.gnu.org/22138>.  Meta-packages sound more like a
workaround to me.

> 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 this
use case—using /usr/bin/foo to access Guix-provided files—in Guix
proper, for at least one reason: there are many cases where it wouldn’t
work (PYTHONPATH, 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.)
>>
>> 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 to
the profile that’s in the binary tarball.

Thanks for your feedback,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.