unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Dmitry Alexandrov <321942@gmail.com>
Cc: 27244@debbugs.gnu.org
Subject: bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’?
Date: Wed, 07 Jun 2017 11:40:55 +0200	[thread overview]
Message-ID: <87efuwuod4.fsf@gnu.org> (raw)
In-Reply-To: <87k24oz38e.fsf@gmail.com> (Dmitry Alexandrov's message of "Wed, 07 Jun 2017 10:06:09 +0300")

Hi Dmitry,

Dmitry Alexandrov <321942@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’.

      reply	other threads:[~2017-06-07  9:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05  1:58 bug#27244: Should not $GUIX_LOCPATH belong to ‘glibc-locales’ rather than ‘glibc’? Dmitry Alexandrov
2017-06-05 20:39 ` Ludovic Courtès
2017-06-06  1:33   ` Dmitry Alexandrov
2017-06-06 22:57     ` Ludovic Courtès
2017-06-07  7:06       ` Dmitry Alexandrov
2017-06-07  9:40         ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efuwuod4.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=27244@debbugs.gnu.org \
    --cc=321942@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).