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 16:19:33 -0400 Message-ID: <8761n4mzvu.fsf@yeeloong.lan> References: <871tz8oldk.fsf@netris.org> <874n2oubuq.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]:58497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRosr-0007Br-HY for guix-devel@gnu.org; Sun, 23 Mar 2014 16:20:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRosk-00069p-J0 for guix-devel@gnu.org; Sun, 23 Mar 2014 16:20:41 -0400 In-Reply-To: <874n2oubuq.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Mar 2014 17:19:09 +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: > >> 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-lo= cales >> >> * 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, and that would solve this problem and many others. Therefore, I'd be inclined to avoid making this change, and instead work on union.scm. I want to optimize it anyway, since it takes over 5 minutes to build my profile, which is a bit painful. 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 :-( So perhaps I should recuse myself from this decision. Mark