1 |
On 26-07-2022 09:20:58 +0200, Fabian Groffen wrote: |
2 |
> On 26-07-2022 09:03:18 +0200, Florian Schmaus wrote: |
3 |
> > On 26.07.22 05:00, Sam James wrote: |
4 |
> > >> On 25 Jul 2022, at 16:28, Fabian Groffen <grobian@g.o> wrote: |
5 |
> > >> |
6 |
> > >> bin/ebuild-helpers/emake: force SHELL to be set |
7 |
> > >> |
8 |
> [snip] |
9 |
> > >> |
10 |
> > >> diff --git a/bin/ebuild-helpers/emake b/bin/ebuild-helpers/emake |
11 |
> > >> index 60718a2e4..21da85845 100755 |
12 |
> > >> --- a/bin/ebuild-helpers/emake |
13 |
> > >> +++ b/bin/ebuild-helpers/emake |
14 |
> > >> @@ -12,7 +12,7 @@ |
15 |
> > >> source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1 |
16 |
> > >> |
17 |
> > >> cmd=( |
18 |
> > >> - ${MAKE:-make} ${MAKEOPTS} "$@" ${EXTRA_EMAKE} |
19 |
> > >> + ${MAKE:-make} SHELL="${BASH:-/bin/bash}" ${MAKEOPTS} "$@" ${EXTRA_EMAKE} |
20 |
> > >> ) |
21 |
> > >> |
22 |
> > >> if [[ ${PORTAGE_QUIET} != 1 ]] ; then |
23 |
> > >> |
24 |
> > > |
25 |
> > > I don't think I agree with this as it is. Why not just ${EPREFIX}/bin/sh to avoid using |
26 |
> > > an ancient host sh? |
27 |
> > |
28 |
> > I was about to write the same (also using EPREFIX, but EBROOT seems what |
29 |
> > you want, as you figured). |
30 |
> > |
31 |
> > But then I wondered if "make SHELL=$BROOT/bin/sh" wouldn't override |
32 |
> > explicitly set SHELL values in Makefiles. Assume a package has |
33 |
> > |
34 |
> > SHELL = /bin/zsh |
35 |
> > |
36 |
> > in one of its Makefiles. Then emake would reset this to 'sh'. Which |
37 |
> > appears like it could cause build issues. |
38 |
> > |
39 |
> > If this is the case, then I am not sure what we can do about it. It |
40 |
> > appears fragile, if not impossible, to ask 'make' which value for SHELL |
41 |
> > it would assume, so that emake could adjust the path. Another option |
42 |
> > could be that affected packages define a variable in their ebuild, e.g. |
43 |
> > EMAKE_SHELL="zsh", which emake could extend with BROOT before passing |
44 |
> > the resulting value as SHELL to make. |
45 |
> |
46 |
> So, I can also envision we drop this patch, and I see if I can patch |
47 |
> make(1) to use $EPREFIX/bin/sh instead of /bin/sh by default. Not sure, |
48 |
> but this would retain the behaviour Portage is doing now for non-Prefix, |
49 |
> and would get the behaviour we want in Prefix. |
50 |
> |
51 |
> On an alternative note, there is CONFIG_SHELL (used for setting which shell |
52 |
> to use with configure), which I think in many cases bleeds through to |
53 |
> make, but should there be a MAKE_SHELL perhaps as well? Then the |
54 |
> default would be pretty much ok. |
55 |
> |
56 |
> (We never ran into any problems forcing SHELL to bash in Prefix, but |
57 |
> perhaps that's not a representative test for the whole of Gentoo.) |
58 |
|
59 |
I've been looking around in make, and it seems we can set a default |
60 |
shell there, would be pretty simple, I guess. It doesn't solve, |
61 |
however, a bigger problem, which is what make's source also mentions, |
62 |
lots of Makefiles having SHELL=/bin/sh. In other words, setting a |
63 |
default in make makes no difference in preventing it from using /bin/sh |
64 |
(which is the main aim here). |
65 |
|
66 |
Therefore, I would like to consider the possibility to override SHELL |
67 |
this way via emake, as it seems like the fix we need (for Prefix at |
68 |
least) afterall. |
69 |
|
70 |
Overriding should be safe, I think. SHELL=/bin/zsh makes little sense |
71 |
to me, SHELL=/bin/csh would be more of a thing, but is there any package |
72 |
out there that needs it? And if it does, wouldn't it be acceptable to |
73 |
just handle that in that package? It would require a dep on that shell |
74 |
anyway (so you could consider it a kludgy sanity check as well). |
75 |
|
76 |
I think using bash like the original patch did isn't quite nice, it |
77 |
should use sh instead. However, it cannot hardcode EPREFIX/bin/sh |
78 |
without ensuring that binary exists, else we break bootstraps. |
79 |
|
80 |
So I was thinking: how about something like SHELL=$(type -P sh)? To be |
81 |
completely safe here, it could become an if such that if there's no sh, |
82 |
it falls back to ${BASH}. |
83 |
|
84 |
Would this approach be acceptable? Should it be perhaps conditional |
85 |
based on whether an offset prefix is active? |
86 |
|
87 |
Thanks, |
88 |
Fabian |
89 |
|
90 |
-- |
91 |
Fabian Groffen |
92 |
Gentoo on a different level |