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 attachment 179949 [details] perl-5.8.8-r5 build.log
Created attachment 179951 [details] gpm-1.20.5 build.log
Created attachment 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.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=0896ede9663d1ffb10434ee163205e7d9a909667 commit 0896ede9663d1ffb10434ee163205e7d9a909667 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2024-02-26 00:12:13 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2024-02-27 02:52:19 +0000 Scheduler: Support parallel-install with merge-wait For system packages, always serialize install regardless of parallel-install, in order to mitigate failures triggered by fragile states as in bug 256616. For other packages, continue to populate self._task_queues.merge, which will serialize install unless parallel-install is enabled. Fixes: 825db01b91a3 ("Add merge-wait FEATURES setting enabled by default") Bug: https://bugs.gentoo.org/256616 Bug: https://bugs.gentoo.org/925213 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/_emerge/PackageMerge.py | 4 ++-- lib/_emerge/Scheduler.py | 44 +++++++++++++++++++++++++++++++++----------- man/make.conf.5 | 9 ++++++--- 3 files changed, 41 insertions(+), 16 deletions(-)
