Created attachment 863880 [details] Test ebuild According to PMS, when the ebuild is being sourced, variables EBUILD_PHASE and EBUILD_PHASE_FUNC must be either unset or set to a single word that is not the name of any phase (function). https://projects.gentoo.org/pms/8/pms.html#x1-109001r1 With attached test ebuild, I get this output: $ ebuild foo-1.ebuild unpack *** begin global scope EBUILD_PHASE = pretend EBUILD_PHASE_FUNC = pkg_pretend *** end global scope *** begin global scope EBUILD_PHASE = setup EBUILD_PHASE_FUNC = pkg_setup *** end global scope >>> Unpacking source... >>> Source unpacked in /tmp/portage/app-misc/foo-1/work
fwiw iwdevtools' portage-only bashrc files relies on EBUILD_PHASE being empty or unset to avoid qa-sed from being used when it shouldn't (potentially by portage internals), not that it's an issue once phases start being called so left-over value hasn't been a real "problem". But being always unset/empty in non-phase scope would be more consistent, and potentially kill bit more misuse. If set to non-empty if preferred (for some reason) like "global" then I'll need to do an update (which is fine).
ping
Just to note that this may break existing /etc/portage/bashrc expectations. Came across [1] which noted that [2] has: It is important to note that this file will be sourced multiple times during the build, at least once per phase plus several other times. Therefore when code gets executed should be controlled using e.g. EBUILD_PHASE, EBUILD_PHASE_FUNC (EAPI 5), or otherwise avoid using the global scope by only putting code into hook functions (e.g. pre_pkg_setup()). See bug #250240. I'd assume that fixing this will not allow the former to work anymore (which I'd agree shouldn't be used over pre/post_<phase> either way). [1] https://forums.gentoo.org/viewtopic-p-8816876.html [2] https://wiki.gentoo.org/wiki//etc/portage/bashrc#Multiple_calls
Had forgotten about these, but EBUILD_PHASE is also used in several profile.bashrc, e.g. profiles/prefix/linux/profile.bashrc:if [[ ${EBUILD_PHASE} == setup ]]; then And I do assume fixing this would break these too. profile.bashrc is *not* a PMS thing and support and how to use them is bit up in the air. Unsure if anything but portage tries to read these and if pre_pkg_setup and such could actually be used instead.
(In reply to Ionen Wolkens from comment #4) > ... if pre_pkg_setup and such could actually be used instead. (either way that would complicate things with redefinitions when there's multiple profile.bashrc loaded or even combined with user's which expect these to belong to them)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=ef9be7c2a696a476514de29e2f88df82f37f2ceb commit ef9be7c2a696a476514de29e2f88df82f37f2ceb Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2024-02-22 17:19:40 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2024-02-22 17:19:40 +0000 ebuild-env-vars.tex: EBUILD_PHASE{,_FUNC} are valid only in phases Portage didn't ever set (or unset) these variables to a special value when sourcing the ebuild, so obviously ebuilds cannot rely on this. Restrict their validity to actual phases and make global scope behaviour unspecified. The previous wording was introduced with commit 58d3bc0. Bug: https://bugs.gentoo.org/908552 Signed-off-by: Ulrich Müller <ulm@gentoo.org> ebuild-env-vars.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
