Re: Why does glibc provide bash?

[Mark H Weaver]

Hi Andy, it's good to see you here :)

Andy Wingo <address@hidden> 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-profile/bin/bash -> 
> /gnu/store/5995q4p9ayvicd8qxjmn8zrwis4y7a8c-glibc-2.21/bin/bash
>
> 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/…-bash-VERSION and
/gnu/store/…-glibc-VERSION are each symlinks into subdirectories of
/gnu/store/…-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