Created attachment 678394 [details] EAPI 7 Please port the eselect ebuild to EAPI 7. I noticed it creates a bottleneck when emerging into a different ROOT due to having coreutils in DEPEND, when its build-time dependencies are all native programs that belong in BDEPEND.
We tend to be extra conservative with EAPI bumps because eselect is a dependency of portage. However, since portage ebuilds are EAPI 7 now, I guess that we can proceed here.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1021d268b8b73b06b4409115af18655ea42dd7ff commit 1021d268b8b73b06b4409115af18655ea42dd7ff Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-12-16 12:03:58 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-12-16 12:09:12 +0000 app-admin/eselect: Version bump to 1.4.17. Closes: https://bugs.gentoo.org/718920 Closes: https://bugs.gentoo.org/760081 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-admin/eselect/Manifest | 1 + app-admin/eselect/eselect-1.4.17.ebuild | 58 +++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e6eb59b1a0bf00c8ad6a08d0e68d76cccb52aff commit 2e6eb59b1a0bf00c8ad6a08d0e68d76cccb52aff Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-12-16 12:06:26 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-12-16 12:09:13 +0000 app-admin/eselect: Bump live ebuild to EAPI 7. Bug: https://bugs.gentoo.org/760081 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-admin/eselect/eselect-9999.ebuild | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
I have moved docutils to BDEPEND. The dependency on "|| ( sys-apps/coreutils app-misc/realpath )" is only needed because configure tests for it, so it's a CHOST type dependency.
Those dependencies are checked with AC_CHECK_PROGS, i.e. they are found in $PATH, so they must be declared in BDEPEND. https://gitweb.gentoo.org/proj/eselect.git/tree/configure.ac#n22 https://gitweb.gentoo.org/proj/eselect.git/tree/configure.ac#n48 It can be a build failure now in EAPI 7 if they're not in BDEPEND: # emerge --rage-clean sed # cross emerge -v eselect ... checking for gsed... no checking for sed... no configure: error: sed is required
(In reply to David Michael from comment #4) > Those dependencies are checked with AC_CHECK_PROGS, i.e. they are found in > $PATH, so they must be declared in BDEPEND. That's not the intention and a bug in the "upstream" package then. What do we need instead, AC_CHECK_TOOLS?
And in fact, for bash and sed we need both checks, because they're used both as build tools and at runtime.
AC_CHECK_TOOLS is to find native programs that are prefixed with $CHOST to create/use cross-compiled programs, like $CHOST-objcopy and such. If the programs are called at build time, they should be searched in $PATH and declared in BDEPEND. If the programs are called at runtime, they should be declared in RDEPEND and the build system doesn't need to be aware of them. If they are called at both run and build time, they still don't need to be declared in DEPEND because the build system has no use for unexecutable cross-compiled programs.
I looked a bit closer, and I think I see the issue now. If the concern is a prefix in the target ROOT, then it should probably be using separate variables for build tools and runtime path substitution. Maybe use e.g. SED_FOR_BUILD for the BDEPEND version and SED for the RDEPEND version, so the Makefile could have something like this: dosed = @SED_FOR_BUILD@ -e 's%\@SED\@%@SED@%g' ... That's the only program I see used in both build time and runtime at a glance. I would still probably just have configure.ac search for sed/readlink/realpath/env-update/bash in PATH and then override their variables on the econf line with ${EROOT}-prefixed paths for simplicity in autotools. (That's how I configure a similar setup elsewhere, e.g. setting BASH when building glibc to set it in installed script headers.)
I believe we can get away with just using hardcoded "sed" at build time. However, configure still needs to check for the programs on the CHOST system, because we neither know their path nor their name (which could be "gsed" for GNU sed, versus "sed" for the system sed which may miss the GNU features). Which also means that the corresponding packages need to be in DEPEND. (Also, it doesn't make much sense to put packages like app-shells/bash or sys-apps/sed in BDEPEND, because their presence at build time is guaranteed by PMS.)
Thinking about it, presumably GNU systems will always have coreutils, so we don't need an explicit dependency for them. So, would something like the following help? DEPEND="... !userland_GNU? ( || ( >=sys-apps/coreutils-8.15 app-misc/realpath ) ) ..." (And probably I'd keep the USE-conditional also in RDEPEND for simplicity.)
That change should loosen up the builddep graph in my case, yes, but this is a very minor issue for me at this point compared to what is required to implement these dependencies properly. We can probably just close this. To fix it for Gentoo's ebuild, I think the simplest way would be to have the configure script look for tools in the CBUILD paths, but have econf override them like below. That would allow dropping all build-time dependencies from the ebuild since specifying the paths would skip searching for them, while the configure script would still work for anyone natively building eselect outside of portage. Maybe I can throw together some patches for the ebuild and autotools stuff later to demonstrate. econf SED="${EPREFIX}/usr/bin/sed" REALPATH="${EPREFIX}/usr/bin/realpath" ... Otherwise, to actually detect the runtime paths at build time, I think you would have to set the following PATH in the environment and then strip ${SYSROOT} from the beginning of each found path (and also disable the execution tests that detect GNU tools when cross-compiling). PATH="${ESYSROOT}/usr/bin:${ESYSROOT}/usr/sbin:${ESYSROOT}/bin:${ESYSROOT}/sbin:$PATH"
Closing for now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04c012b1efd77c59d584a080f4dca464e7ec0001 commit 04c012b1efd77c59d584a080f4dca464e7ec0001 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-12-25 12:27:33 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-12-25 12:30:24 +0000 app-emacs/eselect-mode: Version bump to 1.4.17. No actual changes, just sync the version with app-admin/eselect. Closes: https://bugs.gentoo.org/760081 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-emacs/eselect-mode/Manifest | 1 + app-emacs/eselect-mode/eselect-mode-1.4.17.ebuild | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=72692838fb81f64bbc2098b4bee6c75444b92864 commit 72692838fb81f64bbc2098b4bee6c75444b92864 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-12-25 12:28:22 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-12-25 12:30:25 +0000 app-emacs/eselect-mode: EAPI 7 for live ebuild. Bug: https://bugs.gentoo.org/760081 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-emacs/eselect-mode/eselect-mode-9999.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
(In reply to Larry the Git Cow from comment #13) Sorry, wrong bug number in commit message.
