From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 05:41:12 2017 Received: (at 27244) by debbugs.gnu.org; 7 Jun 2017 09:41:12 +0000 Received: from localhost ([127.0.0.1]:60351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dIXSh-0002yJ-Tq for submit@debbugs.gnu.org; Wed, 07 Jun 2017 05:41:12 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37403) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dIXSf-0002y2-Uj for 27244@debbugs.gnu.org; Wed, 07 Jun 2017 05:41:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dIXSW-0006oc-UP for 27244@debbugs.gnu.org; Wed, 07 Jun 2017 05:41:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIXSW-0006oY-Qt; Wed, 07 Jun 2017 05:41:00 -0400 Received: from wifi-eduroam-161098.inria.fr ([128.93.161.98]:56872 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dIXSV-0000Fc-E6; Wed, 07 Jun 2017 05:41:00 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Dmitry Alexandrov <321942@gmail.com> Subject: Re: bug#27244: Should not $GUIX_LOCPATH belong to =?utf-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?utf-8?B?4oCY?= =?utf-8?B?Z2xpYmPigJk/?= In-Reply-To: <87k24oz38e.fsf@gmail.com> (Dmitry Alexandrov's message of "Wed, 07 Jun 2017 10:06:09 +0300") References: <87shjf8abx.fsf@gmail.com> <87inka9nk4.fsf@gnu.org> <87zidl294a.fsf@gmail.com> <87tw3s7mi3.fsf@gnu.org> <87k24oz38e.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 19 Prairial an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Wed, 07 Jun 2017 11:40:55 +0200 Message-ID: <87efuwuod4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27244 Cc: 27244@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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 =E2=80=9Csearch paths are exported by = the >>> active side=E2=80=9D convention implies that every single package that = ships a >>> localized program has to define $GUIX_LOCPATH? That would be about >>> 100=C2=A0% 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 =E2=80=98virtual package=E2=80=99, if you will) that would onl= y add a > search path to etc/profile without installing any executables. I believe the right way to address this issue is by fixing . 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. =E2=80=98emacs=E2=80= =99 and > =E2=80=98texinfo=E2=80=99 packages would have it as propagated dependency. Guix allows users to do that, but IMO we should not try to support this use case=E2=80=94using /usr/bin/foo to access Guix-provided files=E2=80=94i= n Guix proper, for at least one reason: there are many cases where it wouldn=E2=80= =99t work (PYTHONPATH, etc.). >>> (By the way, =E2=80=98glibc-utf8-locales=E2=80=99 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=E2=80=99s =E2= =80=9Climited to >> a few UTF-8 locales=E2=80=9D: >> . >> >> Note that the Guix 0.13.0 binary tarball comes with glibc-utf8-locales >> and glibc, such that its etc/profile defines =E2=80=98GUIX_LOCPATH=E2=80= =99. > > 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 =E2=80=98glibc=E2=80=99 (al= ong with all > its bin/ldd, etc). Or did I miss something? No you=E2=80=99re right, this has to be done per-profile. I was referring = to the profile that=E2=80=99s in the binary tarball. Thanks for your feedback, Ludo=E2=80=99.