Re: What 'sh' should 'system' use?

[Ludovic Courtès]

Hi,

Philip McGrath <philip@philipmcgrath.com> skribis:

> This makes sense as far as using 'bash-static' in Glibc. The aspects I'm 
> unsure
> of are:
>
>  1. If I'm packaging software that implements a function like 'system'
>     (e.g. Racket, SML/NJ, Chez Scheme, etc.), should I use 'bash-minimal' or
>     'bash-static'?
>
>  2. Do we really need 'bash-minimal' at all? Why not just replace it with
>     'bash-static'?

Rather ‘bash-minimal’ (so it can benefit from grafts), but in practice
it doesn’t matter all that much.

> In particular, AFAICT, 'bash-minimal' currently has a reference to
> 'bash-static' via Glibc:
>
> $ guix size bash-minimal 
> store item                                                       total    self
> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33              38.3    
> 36.6  50.4%
> /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib          71.7    
> 33.4  45.9%
> /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8        1.7     
> 1.7   2.3%
> /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8      72.7     
> 1.0   1.4%
> total: 72.7 MiB

True; at least it’s a small part of the closure size.

>> > 2) If we want to make 'sh' a weak/dynamic reference, I think we should
>> > strongly consider arranging to make it available at '/bin/sh' when
>> > present. I expect this option would require less patching of other
>> > packages *by far* than any other approach.
>> 
>> This is not a viable option because build containers lack /bin/sh.
>> 
>
> Right, this option would depend on making /bin/sh exist in the build
> environment.

And this won’t happen: it’s important that the contents of build
environments be stable over time.  That is the foundation of
reproducible builds in Guix.

> I'd hoped this might be possible without having to change the daemon, but the
> ways I've tried so far haven't worked. I tried `(mkdir-p "/bin")`, but the
> build user apparently doesn't have sufficient permissions. Then I tried
> creating a nested container using `call-with-container` in which I could
> bind-mound the directory from 'bash-static' at '/bin', but I hit permissions
> errors that way, too. I also thought there might be a way to pass the daemon
> options like 'build-chroot-dirs' to have it set up /bin/sh before it drops
> privileges, but I couldn't figure out how to do that.

For the record, /bin/sh was dropped on purpose early on in Guix (unlike
in Nix) to have a limited and well-defined build environment:

  https://lists.gnu.org/archive/html/bug-guix/2013-01/msg00041.html

> The patching itself isn't so bad, and, as you say, it's limited to at least
> a relatively small number of packages. However, the fact that Glibc retains a
> reference to 'bash-static' affects nearly every package. It doesn't affect 
> them
> very much, to be sure! But I think it does prevent using
> `guix shell --container` to create containers without a shell, and it likewise
> seems difficult to experiment with different shells. Or maybe it's really just
> that it disturbs my sense of aesthetics.

The choice was made for ‘guix shell -C’ to always provide /bin/sh but
purely for convenience (I can’t find the reference); it’s not strictly
necessary.

Now, it’s true that currently ‘guix shell -C’ always uses Bash as
/bin/sh.  Are you saying that it would be nice to be able to use a
different shell?  In ‘guix home container’, we made a different, which
is to honor $SHELL (see ‘user-shell’ in guix/scripts/home.scm).

Thanks,
Ludo’.