Bugzilla Bug 256616

while emerging app-shells/bash-3.2_p39 (in a emerge -NDuva world from
stage3-x86-2008.0 tarball) other emerge compilation fail with this message:
make[1]: /bin/sh: Command not found

Reproducible: Always

Steps to Reproduce:
1. `emerge -NDuva -j3 world` from stage3-x86-2008.0 tarball with parallel
portage

Actual Results:  
>>> Emerging (35 of 75) app-shells/bash-3.2_p39
>>> Installing sys-apps/texinfo-4.11-r1
>>> Emerging (36 of 75) sys-apps/less-418
>>> Installing sys-apps/less-418
>>> Emerging (37 of 75) sys-libs/gpm-1.20.5
>>> Installing app-shells/bash-3.2_p39
>>> Failed to emerge dev-lang/perl-5.8.8-r5, Log file:
>>>  '/var/tmp/portage/dev-lang/perl-5.8.8-r5/temp/build.log'
>>> Failed to emerge sys-libs/gpm-1.20.5, Log file:
>>>  '/var/tmp/portage/sys-libs/gpm-1.20.5/temp/build.log'

Created an attachment (id=179949) [details]
perl-5.8.8-r5 build.log

Created an attachment (id=179951) [details]
gpm-1.20.5 build.log

Created an attachment (id=179952) [details]
emerge --info

You'd better do this to fix it (your system might not boot otherwise):

  ln -s bash /bin/sh

Actually, I suspect that your /bin/sh symlink already exists. It's just that it
didn't exist in the time between bash being upgraded and the pkg_postinst phase
executing (which creates the symlink).

One possible way to solve this would be to add /bin/sh to CONFIG_PROTECT.
There's already some code in pkg_preinst which bumps the timestamp on the
symlink, and that will prevent it from being unmerged if it's CONFIG_PROTECTed.

Considering that this issue boils down to an unspecified dependency on /bin/sh,
maybe we should have a new RESTRICT value for packages like this, which
prevents them from being merged while other packages are being built. I suppose
we could also just use the system set to identify such packages, but that
wouldn't provide as much granularity.

I don't think a new RESTRICT value is really necessary. Since the system set
should work pretty well as an indicator, so I'll go ahead and use that.

This is fixed in svn r12569.

Or you could do --jobs properly, by installing via binary packages, as you've
been told is necessary for correctness several times before. Adding in more
workarounds doesn't fix the underlying issue.

The "underlying issue" doesn't apply to all packages. It would be better to
introduce a new RESTRICT value than to treat all packages identically.

You have no idea which packages are and aren't affected. This bug is a perfect
example of one of the many things you didn't think of. Why not just do it
properly in a way that's guaranteed not to introduce new breakages?

This is fixed in 2.2_rc24 which is in package.mask. I'll close this bug when
it's also released in 2.1.6.8.

This is released in 2.1.6.8.