From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Problems with handicapped 'bash' from glibc package Date: Fri, 28 Mar 2014 14:48:48 +0100 Message-ID: <87ha6io2m7.fsf@gnu.org> References: <871tz8oldk.fsf@netris.org> <874n2oubuq.fsf@gnu.org> <8761n4mzvu.fsf@yeeloong.lan> <87siq8r77u.fsf@gnu.org> <87vbv4l1bu.fsf@yeeloong.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTX9U-0007Kz-0p for guix-devel@gnu.org; Fri, 28 Mar 2014 09:49:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WTX9P-00028w-5U for guix-devel@gnu.org; Fri, 28 Mar 2014 09:48:55 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:51099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTX9O-00028m-Ng for guix-devel@gnu.org; Fri, 28 Mar 2014 09:48:51 -0400 In-Reply-To: <87vbv4l1bu.fsf@yeeloong.lan> (Mark H. Weaver's message of "Sun, 23 Mar 2014 23:31:17 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Mark H Weaver skribis: >> >>> ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> >>>> Mark H Weaver skribis: >>>> >>>>> The 'bash' in the glibc package is handicapped in at least two ways: >>>>> >>>>> * It can't set the locale, because it looks for locales in >>>>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18= -locales >>>>> >>>>> * It can't look up anything from NSS, such as passwd data, because it >>>>> tries to load the modules from >>>>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18 >>>>> >>>>> There are two problems that need to be addressed, I think: >>>>> >>>>> * Users could easily end up with this handicapped 'bash' as their >>>>> primary bash, if they installed (or upgraded?) 'glibc' since the la= st >>>>> time I installed 'bash'. This happened to me, for example. >>>> >>>> I realized that this particular problem is easily solved by moving >>>> glibc=E2=80=99s bash away from $bindir, for instance to $libexecdir. >>>> >>>> I=E2=80=99m trying it out locally, and plan to commit to core-updates = if >>>> everything works as expected (hopefully as the last core-updates >>>> change.) >>>> >>>> Thoughts? >>> >>> Hmm. We need a more intelligent union.scm anyway, >> >> Agreed, but that=E2=80=99s a separate issue. >> >> Having it in $bindir also means that patch-shebangs can pick it up, >> which is usually not what we want. >> >> So I think it really makes sense to move it out of sight. > > Well, that's sweeping it under the rug, when actually this broken bash > should never be used for anything except perhaps during the bootstrap. > > The fact is, we have broken 'system' and 'popen' functions in Guix. > For example: > > mhw:~$ cat foo.c > #include > > int > main (int argc, char *argv[]) > { > return system ("echo Hello world"); > } > > mhw:~$ gcc -o foo foo.c > mhw:~$ ./foo > sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) > Hello world Yes, understood. > Our glibc should not use a broken bash. It would also be nice if the > bash used by glibc was linked with the same glibc, so that we only need > one copy of glibc in memory. So there's a circular dependency here. > > I think we need a better way of dealing with circular dependencies in > general, but in the meantime, I think we should build the final glibc > and bash as two outputs from the same derivation, so that they can refer > to each other. > > What do you think? Again, I definitely agree. We discussed ways to do it here: https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00145.html Someone just needs to do it. :-) We could schedule it for the next core-updates round, WDYT? Note that technically, it cannot be two separate outputs because outputs currently cannot have circular references (and it wouldn=E2=80=99t buy us m= uch anyway.) Ludo=E2=80=99.