I stumbled across this while building stages w/ systemd via catalyst. 'which' is in the @system set but not the build set used by stage1. As a dependency of systemd libseccomp just happened to get built during stage3 before 'which' causing the configure script to fail. Easily fixed with DEPEND=sys-apps/which or slightly less easily with a patch to use 'type -p' in the configure script.
i think we should just add which to stage2
(In reply to SpanKY from comment #1) > i think we should just add which to stage2 Mike, to me it seems that adding the dep to libseccomp makes more sense. If there is a strong reason not to add it, then perhaps we can just add it to the list of packages to build on stage1.
(In reply to Jorge Manuel B. S. Vicetto from comment #2) sys-apps/which is already part of @system precisely because we don't want to track the deps in various packages that use it. saying "if your package has the potential to end up in a stage1/2/3, then you need to depend on which" doesn't really make sense.
(In reply to SpanKY from comment #3) > sys-apps/which is already part of @system precisely because we don't want to > track the deps in various packages that use it. saying "if your package has > the potential to end up in a stage1/2/3, then you need to depend on which" > doesn't really make sense. So any objection to add it to the end of profiles/base/packages?
(In reply to Jorge Manuel B. S. Vicetto from comment #4) > (In reply to SpanKY from comment #3) > > sys-apps/which is already part of @system precisely because we don't want to > > track the deps in various packages that use it. saying "if your package has > > the potential to end up in a stage1/2/3, then you need to depend on which" > > doesn't really make sense. > > So any objection to add it to the end of profiles/base/packages? Sorry, I meant to profiles/default/linux/packages.build and profiles/default/bsd/fbsd/packages.build.
(In reply to Jorge Manuel B. S. Vicetto from comment #5) > (In reply to Jorge Manuel B. S. Vicetto from comment #4) > > (In reply to SpanKY from comment #3) > > > sys-apps/which is already part of @system precisely because we don't want to > > > track the deps in various packages that use it. saying "if your package has > > > the potential to end up in a stage1/2/3, then you need to depend on which" > > > doesn't really make sense. > > > > So any objection to add it to the end of profiles/base/packages? > > Sorry, I meant to profiles/default/linux/packages.build and > profiles/default/bsd/fbsd/packages.build That's certainly fine by me, I proposed the same change in CoreOS :) https://github.com/coreos/coreos-overlay/commit/89edb94573921ba30d800548e59a6073e2a1938b
02:11 < irker781> gentoo-x86: jmbsvicetto profiles/default/bsd/fbsd: Add sys-apps/which to the list of packages to build on stage1 - fixes bug 502084. 02:11 < irker781> gentoo-x86: jmbsvicetto profiles/default/linux: Add sys-apps/which to the list of packages to build on stage1 - fixes bug 502084. Done. Please test the change works. Please reopen the bug if you hit the same issue.
Looks like the which was removed from libseccomp's configure.ac: https://github.com/seccomp/libseccomp/commit/45b7b49a04eafb544e4bd1768b46a407fc696ff9 I have verified that sys-libs/libseccomp-2.5.3 (the stable version) builds here without sys-apps/which installed. So I wonder if that change could be reverted? It is contrary to the goal of bug 646588.
ping
I think you're right, I'll remove it and watch the next week's builds for any issues.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e955fee91e08f99b4b1e8b8dbdfb34f447e7275 commit 4e955fee91e08f99b4b1e8b8dbdfb34f447e7275 Author: Ben Kohler <bkohler@gentoo.org> AuthorDate: 2023-01-25 18:37:02 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2023-01-25 18:37:34 +0000 profiles: remove sys-apps/which from packages.build (stage1) Bug: https://bugs.gentoo.org/502084 Signed-off-by: Ben Kohler <bkohler@gentoo.org> profiles/default/linux/packages.build | 1 - 1 file changed, 1 deletion(-)
