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

[Philip McGrath <philip@philipmcgrath.com>]

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote:
> Hello!
> 
> Philip McGrath <philip@philipmcgrath.com> skribis:
> > 1) If we want to continue to hard-code a specific shell into Glibc, I
> > think we should document the decision (for example, why 'bash-static' vs.
> > 'bash- minimal'?) […]
> 
> The choice of ‘bash-static’ rather than ‘bash-minimal’ is motivated by
> the fact that, in (gnu packages commencement), we want to make sure
> ‘glibc-final’ does not retain references to its build-time environment.
> See #:allowed-references in ‘glibc-final’.
> 

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'?

In particular, AFAICT, 'bash-minimal' currently has a reference to
'bash-static' via Glibc:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

> > 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.

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.

> Overall, I think the current situation is a reasonable tradeoff.  It
> forces us to do some patching, indeed, but I think that’s acceptable:
> we’re talking about a handful of packages.
> 
> WDYT?
> 
> Ludo’.

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.

-Philip

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]