[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What 'sh' should 'system' use?
From: |
Ludovic Courtès |
Subject: |
Re: What 'sh' should 'system' use? |
Date: |
Wed, 19 Oct 2022 17:30:14 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
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’.