Bug 524964 – sys-apps/portage-2.2.13 + unable to run portageq in ebuilds

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Denis Kaganovich 2014-10-10 15:35:46 UTC]

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

[Comment 1 Mike Gilbert 2014-10-10 16:26:42 UTC]

I'm not sure what valid reason there would be for calling portageq from an ebuild.

[Comment 2 Michał Górny 2014-10-10 18:31:39 UTC]

It's definitely wrong, disallowed and banned to call it. Which ebuild does that?

[Comment 3 Zac Medico 2014-10-10 18:57:55 UTC]

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.

[Comment 4 Zac Medico 2014-10-11 04:46:29 UTC]

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.

[Comment 5 Zac Medico 2014-10-11 08:23:14 UTC]

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

[Comment 6 Denis Kaganovich 2014-10-11 09:57:23 UTC]

(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

[Comment 7 Michał Górny 2014-10-11 17:54:14 UTC]

(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.

[Comment 8 Zac Medico 2014-10-19 17:49:23 UTC]

This is in git:

https://github.com/gentoo/portage/commit/03cbe2762903601fe679ccd766456f6f6cba8ea2

[Comment 9 Zac Medico 2014-10-20 19:31:53 UTC]

This is fixed in 2.2.14.

[Comment 10 Zac Medico 2014-10-26 01:18:54 UTC]

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.

[Comment 11 Zac Medico 2014-10-26 01:31:28 UTC]

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.

[Comment 12 Zac Medico 2014-10-27 09:48:52 UTC]

This is in git now:

https://github.com/gentoo/portage/commit/61c34d8f4681860e6b45b8f63627bd0173d020df

[Comment 13 Brian Dolbec (RETIRED) 2014-12-04 05:40:45 UTC]

This is in the portage-2.2.15 release.