From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: Dmitry Alexandrov <321942@gmail.com> Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 05 Jun 2017 01:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 27244@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14966279124425 (code B ref -1); Mon, 05 Jun 2017 01:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Jun 2017 01:58:32 +0000 Received: from localhost ([127.0.0.1]:56292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHhHs-00019J-0f for submit@debbugs.gnu.org; Sun, 04 Jun 2017 21:58:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHhHo-000194-D1 for submit@debbugs.gnu.org; Sun, 04 Jun 2017 21:58:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHhHi-0005DV-8B for submit@debbugs.gnu.org; Sun, 04 Jun 2017 21:58:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33089) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dHhHi-0005DR-4x for submit@debbugs.gnu.org; Sun, 04 Jun 2017 21:58:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHhHh-0000IN-3f for bug-guix@gnu.org; Sun, 04 Jun 2017 21:58:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHhHe-0005Bb-0M for bug-guix@gnu.org; Sun, 04 Jun 2017 21:58:21 -0400 Received: from forward20h.cmail.yandex.net ([87.250.230.162]:42273) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dHhHd-00058s-Lt for bug-guix@gnu.org; Sun, 04 Jun 2017 21:58:17 -0400 Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [IPv6:2a02:6b8:0:2519::121]) by forward20h.cmail.yandex.net (Yandex) with ESMTP id 32ADE21B72 for ; Mon, 5 Jun 2017 04:58:12 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id EE88163C0EA2 for ; Mon, 5 Jun 2017 04:58:11 +0300 (MSK) Received: by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id bGKJQ0bxQx-wBCusodc; Mon, 05 Jun 2017 04:58:11 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1496627891; bh=8+V2Cfeu4iDj4rj+tzbOtLtSH14cz0Aj8xac+bhcXZk=; h=From:To:Subject:Date:Message-ID; b=bqP7uZxbEvkCG03PshfowyZMD0k3cRx1pJIzyEL6DAOq6eQGhep0T+PFgxSWLYq+K SGE0IDK+pueLcOqdQNypraIv0CyJU4FCaeCMXCMnNuU3xzy4F5GekErgXfg6EWvH9s kddqJEWMBicYITjWsGzIvETOkCWjyG2iIdAGitcw= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@ya.ru X-Yandex-Suid-Status: 1 0 From: Dmitry Alexandrov <321942@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Mail-Copies-To: always Date: Mon, 05 Jun 2017 04:58:10 +0300 Message-ID: <87shjf8abx.fsf@gmail.com> 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] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) 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: -3.8 (---) As of now [0] a search path =E2=80=98GUIX_LOCPATH=E2=80=99 is exported wh= en =E2=80=98glibc=E2=80=99 package, which does not comprise any locales, is installed. I guess, it should belong to =E2=80=98glibc-locales=E2=80=99 and =E2=80=98glibc-ut= f8-locales=E2=80=99 instead. [0] http://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=3D3= bee4b619#n740 From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 05 Jun 2017 20:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Dmitry Alexandrov <321942@gmail.com> Cc: 27244@debbugs.gnu.org Received: via spool by 27244-submit@debbugs.gnu.org id=B27244.149669517617867 (code B ref 27244); Mon, 05 Jun 2017 20:40:01 +0000 Received: (at 27244) by debbugs.gnu.org; 5 Jun 2017 20:39:36 +0000 Received: from localhost ([127.0.0.1]:58129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHymm-0004e7-KK for submit@debbugs.gnu.org; Mon, 05 Jun 2017 16:39:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHyml-0004ds-6y for 27244@debbugs.gnu.org; Mon, 05 Jun 2017 16:39:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHymc-0001YA-Vp for 27244@debbugs.gnu.org; Mon, 05 Jun 2017 16:39:30 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHymc-0001Y4-Sx; Mon, 05 Jun 2017 16:39:26 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:59192 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHymc-0004E7-90; Mon, 05 Jun 2017 16:39:26 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87shjf8abx.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 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: Mon, 05 Jun 2017 22:39:23 +0200 In-Reply-To: <87shjf8abx.fsf@gmail.com> (Dmitry Alexandrov's message of "Mon, 05 Jun 2017 04:58:10 +0300") Message-ID: <87inka9nk4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) 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-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: > As of now [0] a search path =E2=80=98GUIX_LOCPATH=E2=80=99 is exported wh= en =E2=80=98glibc=E2=80=99 > package, which does not comprise any locales, is installed. I guess, > it should belong to =E2=80=98glibc-locales=E2=80=99 and =E2=80=98glibc-ut= f8-locales=E2=80=99 instead. The idea of search path specifications like =E2=80=98GUIX_LOCPATH=E2=80=99 = is that the package that honors them defines them. For example, Python defines =E2=80=98PYTHONPATH=E2=80=99, Guile defines =E2=80=98GUILE_LOAD_PATH=E2=80=99, and so on. In this case, =E2=80=98GUIX_LOCPATH=E2=80=99 is honored by glibc, so glibc = defines it. If instead =E2=80=98glibc-utf8-locales=E2=80=99 defined it, then you=E2=80= =99d immediately get the recommendation about setting =E2=80=98GUIX_LOCPATH=E2=80=99, which I gu= ess is what you=E2=80=99d like to see. However, every locale-providing package would n= eed to define it, which is not great. On a related note, see this issue about indirect search path specifications: . Does it make sense? Thanks for your message, Ludo=E2=80=99. From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: Dmitry Alexandrov <321942@gmail.com> Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 06 Jun 2017 01:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Cc: Dmitry Alexandrov <321942@gmail.com>, 27244@debbugs.gnu.org Received: via spool by 27244-submit@debbugs.gnu.org id=B27244.1496712802954 (code B ref 27244); Tue, 06 Jun 2017 01:34:02 +0000 Received: (at 27244) by debbugs.gnu.org; 6 Jun 2017 01:33:22 +0000 Received: from localhost ([127.0.0.1]:58332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI3N3-0000FI-Qi for submit@debbugs.gnu.org; Mon, 05 Jun 2017 21:33:22 -0400 Received: from forward3m.cmail.yandex.net ([5.255.216.21]:58769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI3N1-0000F2-IW for 27244@debbugs.gnu.org; Mon, 05 Jun 2017 21:33:20 -0400 Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward3m.cmail.yandex.net (Yandex) with ESMTP id 59C2E20F67; Tue, 6 Jun 2017 04:33:12 +0300 (MSK) Received: from smtp3o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 5FEE62940E22; Tue, 6 Jun 2017 04:33:10 +0300 (MSK) Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PY9APMNcYH-XASCvand; Tue, 06 Jun 2017 04:33:10 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1496712790; bh=HqO5kn1xXbr50K1azYL1v/OW03kQ1bpv+CXKz/OWrAQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID; b=gh49PE1PMfWGNhYBnwhwLP+cmPrJM8RDoXlm1Q8TIA45LtyX8PCGZ61pr/1VM/+/C 5gVQ99JifGV6l3jUVEXnmzbkR6BGDhz6L2OZ3FlGp+KSzYXAiRfpcJhVqIoNCjZi3g /ppm6cz3ED06LGofu3+eSjJLUct7NR2fB5TMVNVg= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@ya.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 From: Dmitry Alexandrov <321942@gmail.com> In-Reply-To: <87inka9nk4.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 05 Jun 2017 22:39:23 +0200") References: <87shjf8abx.fsf@gmail.com> <87inka9nk4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Mail-Copies-To: always Date: Tue, 06 Jun 2017 04:33:09 +0300 Message-ID: <87zidl294a.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) 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: -0.5 (/) >> 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: . 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?) From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 06 Jun 2017 22:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Dmitry Alexandrov <321942@gmail.com> Cc: 27244@debbugs.gnu.org Received: via spool by 27244-submit@debbugs.gnu.org id=B27244.14967898674030 (code B ref 27244); Tue, 06 Jun 2017 22:58:01 +0000 Received: (at 27244) by debbugs.gnu.org; 6 Jun 2017 22:57:47 +0000 Received: from localhost ([127.0.0.1]:59997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dINQ3-00012v-6b for submit@debbugs.gnu.org; Tue, 06 Jun 2017 18:57:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dINQ1-00012j-SR for 27244@debbugs.gnu.org; Tue, 06 Jun 2017 18:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dINPr-0000gj-Qb for 27244@debbugs.gnu.org; Tue, 06 Jun 2017 18:57:40 -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]:39443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dINPr-0000gb-OB; Tue, 06 Jun 2017 18:57:35 -0400 Received: from astlambert-651-1-208-19.w92-151.abo.wanadoo.fr ([92.151.64.19]:37538 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dINPr-000101-3c; Tue, 06 Jun 2017 18:57:35 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87shjf8abx.fsf@gmail.com> <87inka9nk4.fsf@gnu.org> <87zidl294a.fsf@gmail.com> 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 00:57:24 +0200 In-Reply-To: <87zidl294a.fsf@gmail.com> (Dmitry Alexandrov's message of "Tue, 06 Jun 2017 04:33:09 +0300") Message-ID: <87tw3s7mi3.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) 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-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 (-----) Dmitry Alexandrov <321942@gmail.com> skribis: >>> As of now [0] a search path =E2=80=98GUIX_LOCPATH=E2=80=99 is exported = when =E2=80=98glibc=E2=80=99 >>> package, which does not comprise any locales, is installed. I guess, >>> it should belong to =E2=80=98glibc-locales=E2=80=99 and =E2=80=98glibc-= utf8-locales=E2=80=99 instead. >> >> The idea of search path specifications like =E2=80=98GUIX_LOCPATH=E2=80= =99 is that the >> package that honors them defines them. >> >> For example, Python defines =E2=80=98PYTHONPATH=E2=80=99, Guile defines >> =E2=80=98GUILE_LOAD_PATH=E2=80=99, 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, =E2=80=98GUIX_LOCPATH=E2=80=99 is honored by glibc, so gli= bc defines it. > > From the user point of view =E2=80=98glibc=E2=80=99 is a package that ins= talls > 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 =E2=80=98glibc-utf8-locales=E2=80=99 defined it, then you=E2= =80=99d immediately get >> the recommendation about setting =E2=80=98GUIX_LOCPATH=E2=80=99, which I= guess is what >> you=E2=80=99d 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 =E2=80=9Csearch paths are exported by the > active side=E2=80=9D convention implies that every single package that sh= ips a > localized program has to define $GUIX_LOCPATH? That would be about > 100=C2=A0% of packages, I guess. Correct. > On the other hand, now there are only two locale-providing packages, > as I can see: =E2=80=98glibc-locales=E2=80=99 and =E2=80=98glibc-utf8-loc= ales=E2=80=99. Are there > plans to split them up? Is not that supposed to be done by means of > =E2=80=98outputs=E2=80=99: 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, =E2=80=98glibc-utf8-locales=E2=80=99 looks like a misnomer t= o 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. >> On a related note, see this issue about indirect search path >> specifications: . > > 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=E2=80=99. From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: Dmitry Alexandrov <321942@gmail.com> Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 07 Jun 2017 07:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Cc: 27244@debbugs.gnu.org Received: via spool by 27244-submit@debbugs.gnu.org id=B27244.149681918629867 (code B ref 27244); Wed, 07 Jun 2017 07:07:02 +0000 Received: (at 27244) by debbugs.gnu.org; 7 Jun 2017 07:06:26 +0000 Received: from localhost ([127.0.0.1]:60256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dIV2v-0007lf-RF for submit@debbugs.gnu.org; Wed, 07 Jun 2017 03:06:26 -0400 Received: from forward5p.cmail.yandex.net ([77.88.31.20]:38184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dIV2u-0007lR-0Z for 27244@debbugs.gnu.org; Wed, 07 Jun 2017 03:06:25 -0400 Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [IPv6:2a02:6b8:0:2519::125]) by forward5p.cmail.yandex.net (Yandex) with ESMTP id D183F20677; Wed, 7 Jun 2017 10:06:16 +0300 (MSK) Received: from smtp3m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id 9C5AA2840CC2; Wed, 7 Jun 2017 10:06:10 +0300 (MSK) Received: by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id XDxrxxUbCC-69jSGJNG; Wed, 07 Jun 2017 10:06:09 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1496819169; bh=qCac9JhsM4Bj+SSjzEcmFRVyQciDDAxcXF6nrMOPJx0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID; b=HiH+ggYblZpM60OyheTRVo6k9OFw3kqhbE30J2DR1kHz7cV4L320gqGqTdWhrzki6 1LqzS/1si5W4l0cSFndb+pEnt1yDWlqZwWLcmnkp7aiUYviDPd1/qAFqDkIcg8ziMz 3L8sSMGybJKmEbUZ0yGFuIPWljRBCjmyCNLfx2/o= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@ya.ru X-Yandex-Suid-Status: 1 0,1 0 From: Dmitry Alexandrov <321942@gmail.com> In-Reply-To: <87tw3s7mi3.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 07 Jun 2017 00:57:24 +0200") References: <87shjf8abx.fsf@gmail.com> <87inka9nk4.fsf@gnu.org> <87zidl294a.fsf@gmail.com> <87tw3s7mi3.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Mail-Copies-To: always Date: Wed, 07 Jun 2017 10:06:09 +0300 Message-ID: <87k24oz38e.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >>>> As of now [0] a search path =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is exported when =?UTF-8?Q?=E2=80=98glibc=E2=80=99?= >>>> package, which does not comprise any locales, is installed. I guess, >>>> it should belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= and =?UTF-8?Q?=E2=80=98glibc-utf8-locales=E2=80=99?= instead. >>> >>> The idea of search path specifications like =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is that the >>> package that honors them defines them. >>> >>> For example, Python defines =?UTF-8?Q?=E2=80=98PYTHONPATH=E2=80=99,?= Guile defines >>> =?UTF-8?Q?=E2=80=98GUILE=5FLOAD=5FPATH=E2=80=99,?= 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, =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is honored by glibc, so glibc defines it. >> >> From the user point of view =?UTF-8?Q?=E2=80=98glibc=E2=80=99?= 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 =?UTF-8?Q?=E2=80=98glibc-utf8-locales=E2=80=99?= defined it, then =?UTF-8?Q?you=E2=80=99d?= immediately get >>> the recommendation about setting =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99,?= which I guess is what >>> =?UTF-8?Q?you=E2=80=99d?= 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 =?UTF-8?Q?=E2=80=9Csearch?= paths are exported by the >> active =?UTF-8?Q?side=E2=80=9D?= convention implies that every single package that ships a >> localized program has to define $GUIX_LOCPATH? That would be about >> =?UTF-8?Q?100=C2?= % of packages, I guess. > > Correct. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [77.88.31.20 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (321942[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [77.88.31.20 listed in wl.mailspike.net] 1.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 1.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >>>> As of now [0] a search path =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is exported when =?UTF-8?Q?=E2=80=98glibc=E2=80=99?= >>>> package, which does not comprise any locales, is installed. I guess, >>>> it should belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= and =?UTF-8?Q?=E2=80=98glibc-utf8-locales=E2=80=99?= instead. >>> >>> The idea of search path specifications like =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is that the >>> package that honors them defines them. >>> >>> For example, Python defines =?UTF-8?Q?=E2=80=98PYTHONPATH=E2=80=99,?= Guile defines >>> =?UTF-8?Q?=E2=80=98GUILE=5FLOAD=5FPATH=E2=80=99,?= 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, =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99?= is honored by glibc, so glibc defines it. >> >> From the user point of view =?UTF-8?Q?=E2=80=98glibc=E2=80=99?= 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 =?UTF-8?Q?=E2=80=98glibc-utf8-locales=E2=80=99?= defined it, then =?UTF-8?Q?you=E2=80=99d?= immediately get >>> the recommendation about setting =?UTF-8?Q?=E2=80=98GUIX=5FLOCPATH=E2=80=99,?= which I guess is what >>> =?UTF-8?Q?you=E2=80=99d?= 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 =?UTF-8?Q?=E2=80=9Csearch?= paths are exported by the >> active =?UTF-8?Q?side=E2=80=9D?= convention implies that every single package that ships a >> localized program has to define $GUIX_LOCPATH? That would be about >> =?UTF-8?Q?100=C2?= % of packages, I guess. > > Correct. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [77.88.31.20 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [77.88.31.20 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (321942[at]gmail.com) 1.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 1.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders >>>> 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”: > . > > 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: . >> >> 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. From unknown Sat Aug 09 05:06:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27244: Should not $GUIX_LOCPATH belong to =?UTF-8?Q?=E2=80=98glibc-locales=E2=80=99?= rather than =?UTF-8?Q?=E2=80=98glibc=E2=80=99=3F?= Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 07 Jun 2017 09:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27244 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Dmitry Alexandrov <321942@gmail.com> Cc: 27244@debbugs.gnu.org Received: via spool by 27244-submit@debbugs.gnu.org id=B27244.149682847211432 (code B ref 27244); Wed, 07 Jun 2017 09:42:02 +0000 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?=) 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-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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 27 08:30:25 2017 Received: (at control) by debbugs.gnu.org; 27 Jul 2017 12:30:25 +0000 Received: from localhost ([127.0.0.1]:58026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dahvs-0004hp-Of for submit@debbugs.gnu.org; Thu, 27 Jul 2017 08:30:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dahvq-0004b2-VN for control@debbugs.gnu.org; Thu, 27 Jul 2017 08:30:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dahvl-0004Of-1H for control@debbugs.gnu.org; Thu, 27 Jul 2017 08:30:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dahvk-0004OS-Ui for control@debbugs.gnu.org; Thu, 27 Jul 2017 08:30:16 -0400 Received: from [193.50.110.224] (port=37468 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dahvj-0008HE-Gr for control@debbugs.gnu.org; Thu, 27 Jul 2017 08:30:16 -0400 Date: Thu, 27 Jul 2017 14:30:14 +0200 Message-Id: <87inie3vvt.fsf@gnu.org> To: control@debbugs.gnu.org From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: control message for bug #27244 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: control 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 (-----) tags 27244 notabug close 27244