From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Why does glibc provide bash? Date: Tue, 11 Aug 2015 00:23:18 -0400 Message-ID: <871tfapi6h.fsf@netris.org> References: <87vbcnb2vp.fsf@igalia.com> 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]:44086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZP163-0006oQ-MK for guix-devel@gnu.org; Tue, 11 Aug 2015 00:23:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZP160-0001wr-Ex for guix-devel@gnu.org; Tue, 11 Aug 2015 00:23:31 -0400 Received: from world.peace.net ([50.252.239.5]:55219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZP160-0001wb-BM for guix-devel@gnu.org; Tue, 11 Aug 2015 00:23:28 -0400 In-Reply-To: <87vbcnb2vp.fsf@igalia.com> (Andy Wingo's message of "Mon, 10 Aug 2015 17:05:14 +0200") 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: Andy Wingo Cc: guix-devel@gnu.org Hi Andy, it's good to see you here :) Andy Wingo writes: > bash-4.3$ .guix-profile/bin/bash --norc /tmp/foo.bash > /tmp/foo.bash: line 6: complete: command not found > > What could be going on? Well here's a lollerskates thing, back in the > main environment: > > $ ls -l `which bash` > lrwxrwxrwx 11 root guixbuild 63 Jan 1 1970 /home/wingo/.guix-profil= e/bin/bash -> /gnu/store/5995q4p9ayvicd8qxjmn8zrwis4y7a8c-glibc-2.21/bin/ba= sh > > It's coming from glibc!!! Zomg. Why is this? From what I can tell > it's not in the propagated inputs of glibc, so this shouldn't be > happening. Indeed, we should have dealt with this issue long ago, but it seems to have fallen through the cracks. The following email, including the quotations, summarizes the problems and possible solutions: https://lists.gnu.org/archive/html/guix-devel/2014-03/msg00349.html Ludovic pointed out that glibc's static bash should be in $libexecdir not $bindir. That's an easy fix, but I spoke against it because, IMO, it sweeps the real problem under the rug where it might be forgotten. The real problem is that there is a circular dependency between bash and glibc, but guix-daemon does not allow circular dependencies between different store items, a limitation inherited from nix-daemon. This means that we either have to avoid the circularity by introducing multiple copies of glibc and/or bash (currently we duplicate both), or else we must put glibc and bash into the same store item. Obviously, putting glibc and bash into the same store item feels wrong on multiple levels. First of all, users might reasonably want to install one in a profile but not both. One solution would be to have a 'glibc+bash' package behind the scenes, and then separate 'glibc' and 'bash' packages that have only symlinks into the 'glibc+bash' package. It could even be just two symlinks, where /gnu/store/=E2=80=A6-bash-VERSION= and /gnu/store/=E2=80=A6-glibc-VERSION are each symlinks into subdirectories of /gnu/store/=E2=80=A6-glibc+bash. Another problem is that it's rather gross to try to build these two packages together within a single package definition. I guess that first glibc would be built and installed, configured to look for a yet-to-be-built bash that will eventually be installed in glibc's libexecdir. Then 'bash' would be built against that 'glibc' and installed into the place where 'glibc' will look for it. It's workable but would be a bit gross to implement. A better way might be to initially build the two packages separately, with 'glibc' initially configured to use the bootstrap bash, and then to have a separate 'glibc+bash' package that simply copies the contents of the two packages together into a new package, while mutating the reference(s) to bash in 'glibc' to use the new bash instead of the bootstrap one, thus creating the cycle for the first time. Care should be taken to ensure that the new package does not refer to either the bootstrap bash or the original separate glibc or bash packages. Finally, I should raise the possibility of eventually eliminating this prohibition on circular dependencies between different store items. However, I'm not confident that I'm aware of all the implications of doing this, e.g. how it might effect the desirable properties of Nix/Guix and what parts of the code would need adjustment. I'd like to investigate this some day, but not today. What do you think? Mark