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: /bin/sh: Command not found
Steps to Reproduce:
1. `emerge -NDuva -j3 world` from stage3-x86-2008.0 tarball with parallel portage
>>> 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:
>>> Failed to emerge sys-libs/gpm-1.20.5, Log file:
Created attachment 179949 [details]
Created attachment 179951 [details]
Created attachment 179952 [details]
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 184.108.40.206.
This is released in 220.127.116.11.