Summary: | EBUILD_PHASE and EBUILD_PHASE_FUNC have bad values in global scope | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ulrich Müller <ulm> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ionen, pms |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 563798 | ||
Attachments: | Test ebuild |
Description
Ulrich Müller
2023-06-15 18:34:01 UTC
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(-) |