[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What 'sh' should 'system' use?
From: |
Philip McGrath |
Subject: |
Re: What 'sh' should 'system' use? |
Date: |
Sat, 15 Oct 2022 19:23:29 -0400 |
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
signature.asc
Description: This is a digitally signed message part.