Starting from sys-apps/portage-2.2.13, running "portageq" from ebuild (currently only 1 ebuild in main tree use it and unsure 1 in "eclass") failed: "/usr/bin/python2.7: can't open file '/usr/lib/portage/python2.7/portageq': [Errno 2] No such file or directory". I use workaround: [ -x /usr/bin/portageq ] && portageq() { /usr/bin/portageq "${@}";} - but will fine to fix it. Reproducible: Always
I'm not sure what valid reason there would be for calling portageq from an ebuild.
It's definitely wrong, disallowed and banned to call it. Which ebuild does that?
The sys-apps/portage-2.2.12 and earlier ebuilds use this code to generate repos.conf: type -P portageq >/dev/null 2>&1 && \ REPOS_CONF_SYNC=$("$(type -P portageq)" envvar SYNC) It's broken now, since ebuild-helpers/portageq is a bash wrapper that redirects to $PORTAGE_BIN_PATH/portageq which no longer exists.
Created attachment 386408 [details, diff] bin/ebuild-helpers/portageq: fix bug #524964 Since commit 0cc4c1ac21a2ea94cfb1f6ff4b461a9e349d47df, $PORTAGE_BIN_PATH/portageq no longer exists, which breaks bin/ebuild-helpers/portageq. Note that has_version and best_version rely on bin/ebuild-helpers/portageq if IPC is disabled, so breakage extends beyond ebuilds that call portageq "illegally". Since $PORTAGE_BIN_PATH no longer works, use PATH to locate the real portageq python script.
Created attachment 386416 [details, diff] bin/ebuild-helpers/portageq: fix bug #524964 This updated patch uses 'set -f' in case ${PATH} contains any shell glob characters. I'll be maintaining this patch in the following branch: https://github.com/zmedico/portage/tree/bug_524964
(In reply to Michał Górny from comment #2) > It's definitely wrong, disallowed and banned to call it. Which ebuild does > that? dev-util/confix
(In reply to Denis Kaganovich from comment #6) > (In reply to Michał Górny from comment #2) > > It's definitely wrong, disallowed and banned to call it. Which ebuild does > > that? > > dev-util/confix It doesn't. It just suggests using it in output.
This is in git: https://github.com/gentoo/portage/commit/03cbe2762903601fe679ccd766456f6f6cba8ea2
This is fixed in 2.2.14.
We still have a broken portageq shell function inside bin/bashrc-functions.sh. It can simply be removed, because the bin/ebuild-helpers/portageq script is in $PATH and that's all we need.
Created attachment 387392 [details, diff] bin/bashrc-functions.sh: remove portageq function Since commit 0cc4c1ac21a2ea94cfb1f6ff4b461a9e349d47df, $PORTAGE_BIN_PATH/portageq no longer exists, which breaks the portageq shell function inside bashrc-functions.sh. Note that $PORTAGE_BIN_PATH/ebuild-helpers/portageq is in $PATH, so we can simply remove the redundant function. If this is considered serious enough, we might want to consider creating a branch with minimal fixes for 2.2.14. It could include this fix, and the fix from bug 517310.
This is in git now: https://github.com/gentoo/portage/commit/61c34d8f4681860e6b45b8f63627bd0173d020df
This is in the portage-2.2.15 release.