Bugzilla Bug 206944

sys-apps/fakeroot-1.8.1 and also -1.9 (earlier versions not tested) fail when
/bin/sh is a symlink to /bin/dash.

According to the messages, the reason is that the configure script tests
whether the shell understands += (the test succeeds because it is run by bash)
and only afterwards decides which shell to use (which is the shell to which
/bin/sh points).

The easiest solution would be if upstream would remove the superfluous +=
treatment completely: It is only used in one function and obviously is
incompatible and has no advantage. As a temporary hack, one could just let the
test fail:

sed -e 's/\(shell_append.*\)yes/\1no/' configure

try exporting CONFIG_SHELL=/bin/sh before emerging fakeroot

(In reply to comment #1)
> try exporting CONFIG_SHELL=/bin/sh

Works like a charm. That's a much cleaner solution than my hack, of course.
Now I am not sure whether to close this bug:

Is this recommended for all autotools stuff (i.e. should I actually put this in
my /etc/make.conf) or is this a particular "feature" of fakeroot's autotools
usage? In the latter case, I suppose the export command should happen in the
ebuild.

it's a nested mess ... configure will re-exec itself with a "better" shell so
that even if /bin/sh is broken, it'll get a less broken shell while executing

unfortunately, that means embedded shell tests (while logically they should be
ok), actually arent representative of the the real /bin/sh shell ... it'll have
to create a new shell script like:
cat <<EOF > moo
#!/bin/sh
<test for the += crap>
EOF

and then execute moo

looking at the m4 macros makes it look like this test comes from libtool, but i
cant find any corresponding code in libtool itself

at any rate, i'll push this to the debian peeps and use CONFIG_SHELL in our
ebuild