Since PMS says BROOT is only valid during src_* phases, calling has_version -b during pkg_setup is invalid, triggering the error reported in bug 665038: > >>> Emerging (1 of 1) dev-libs/libevdev-1.5.9-r1::gentoo > > * libevdev-1.5.9.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] > has_version: Invalid ROOT: / > * ERROR: dev-libs/libevdev-1.5.9-r1::gentoo failed (setup phase): > * has_version: unexpected ebuild-ipc exit code: 3 > * > * Call stack: > * ebuild.sh, line 124: Called pkg_setup > * ebuild.sh, line 371: Called python-any-r1_pkg_setup > * python-any-r1.eclass, line 353: Called python_setup > * python-any-r1.eclass, line 320: Called _python_EPYTHON_supported 'python2.7' > * python-any-r1.eclass, line 262: Called python_is_installed 'python2_7' > * python-utils-r1.eclass, line 1121: Called has_version '-b' '>=dev-lang/python-2.7.5-r2:2.7' > * phase-helpers.sh, line 961: Called ___best_version_and_has_version_common '-b' '>=dev-lang/python-2.7.5-r2:2.7' > * phase-helpers.sh, line 946: Called die > * The specific snippet of code: > * die "${FUNCNAME[1]}: unexpected ebuild-ipc exit code: ${retval}" > *
I don't see how this could be solved without making major changes to the eclass API. Given that pkg_setup is the 'traditional' phase for doing things like that, and the other phases are usually required and well-defined, we'd need to require everyone to call 'python_setup' somewhere manually which would suck a lot. Given this is a common paradigm to use pkg_setup with MERGE_TYPE checks, maybe we should conditionally permit it in pkg_setup with MERGE_TYPE!=binary (and pkg_pretend?).
I don't think that we should open that can of worms, and have the scope of variables depend on the value of other variables. The simplest solution would be to change the scope of SYSROOT, ESYSROOT, and BROOT from src_* to All. Looks like that's something for EAPI 8?
(In reply to Ulrich Müller from comment #2) > The simplest solution would be to change the scope of SYSROOT, ESYSROOT, and > BROOT from src_* to All. Looks like that's something for EAPI 8? It doesn't make any sense to use build-time things in pkg_* scope, so we really need install-time dependencies as discussed in bug 660306.
Install-time deps are irrelevant here. The choice of phase is merely a matter of convenience, as pkg_setup is the only naturally empty phase here. The request for src_setup may also be related. I can switch the eclass to require manually calling python_setup but I'm pretty sure the main result is going to be a lot of ebuilds failing to do that. Exporting dumb src_configure or src_prepare is going to be even worse.
(In reply to Zac Medico from comment #3) > It doesn't make any sense to use build-time things in pkg_* scope, If that worries you, we could restrict it to pkg_pretend and pkg_setup. Still, I'd change it for all three {B,SYS,ESYS}ROOT. > so we really need install-time dependencies as discussed in bug 660306. That would need an EAPI bump for certain (whereas we've changed variable scope retroactively before).
I'm not intimately familiar with the Python eclasses but when I saw this, I thought this code really belonged in src_configure. Is it in pkg_setup because you might need to call Python in the other pkg_* phases? I thought only @system was guaranteed to be present there (as things stand) and Python isn't in @system.
For minimum change, we could simply enable has/best_version -b to work in any phase (it already works for non-prefix configurations). The patch to portage would make has/best_version -b behave exactly the same as --host-root in EAPI 6: > diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh > index 5c9f957e9..b8ecb3c73 100644 > --- a/bin/phase-helpers.sh > +++ b/bin/phase-helpers.sh > @@ -916,7 +916,10 @@ ___best_version_and_has_version_common() { > case ${root_arg} in > -r) root=${ROOT%/}/${EPREFIX#/} ;; > -d) root=${ESYSROOT} ;; > - -b) root=${BROOT:-/} ;; > + -b) > + root=/${PORTAGE_OVERRIDE_EPREFIX#/} > + cmd+=(env EPREFIX="${PORTAGE_OVERRIDE_EPREFIX}") > + ;; > esac > else > case ${root_arg} in
(In reply to Michał Górny from comment #4) > I can switch the eclass to require manually calling python_setup but I'm > pretty sure the main result is going to be a lot of ebuilds failing to do > that. I'm ok with doing this in EAPI 7+. Doing this for older EAPIs is sure to break existing ebuilds.
This has been determined to be an oversight in the PMS, and it has been amended to permit all root vars in pkg_setup.
