From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Problems with handicapped 'bash' from glibc package Date: Sun, 23 Mar 2014 23:31:17 -0400 Message-ID: <87vbv4l1bu.fsf@yeeloong.lan> References: <871tz8oldk.fsf@netris.org> <874n2oubuq.fsf@gnu.org> <8761n4mzvu.fsf@yeeloong.lan> <87siq8r77u.fsf@gnu.org> 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]:55692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRvcP-00029l-T0 for guix-devel@gnu.org; Sun, 23 Mar 2014 23:32:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRvcK-0001QJ-2q for guix-devel@gnu.org; Sun, 23 Mar 2014 23:32:09 -0400 In-Reply-To: <87siq8r77u.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Mar 2014 21:27:33 +0100") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org 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 last >>>> 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: --8<---------------cut here---------------start------------->8--- 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 mhw:~$=20 --8<---------------cut here---------------end--------------->8--- 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? >> I confess that I'm biased, because it would mean throwing away most of >> the core-updates build outputs my YeeLoong 8101B has produced over the >> last four days, and starting again from scratch :-( > > Yeah, I understand the frustration. However, I really view core-updates > as the place where we can make this kind of change without having to pay > much attention to build time (though I reckon this one occurs close to > the intended merge date.) Well, I certainly agree with this general view, and if I felt that this was a proper fix to the glibc/bash problem, I'd of course agree that we should do it. Mark