Bug 480994 – sys-apps/paludis-1.4.0 fails pkg_preinst for sys-apps/portage-2.2.0, Error emulating 'portageq envvar SYNC'

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2013-08-14 07:41:01 UTC]

Created attachment 355948 [details]
cave info sys-apps/portage

>>> Starting pkg_preinst
 * Running preinst sanity tests...
testBashSyntax (portage.tests.lint.test_bash_syntax.BashSyntaxTestCase) ... ok
testCompileModules (portage.tests.lint.test_compile_modules.CompileModulesTestCase) ... ok
testImportModules (portage.tests.lint.test_import_modules.ImportModulesTestCase) ... ok

----------------------------------------------------------------------
Ran 3 tests in 2.120s

OK
 * Error emulating 'portageq envvar SYNC':

!!! ERROR in sys-apps/portage-2.2.0::gentoo:
!!! In portageq at line 4108
!!! portageq emulation for envvar not implemented

!!! Call stack:
!!!    * portageq (/tmp/portage/sys-apps-portage-2.2.0/temp/loadsaveenv:4108)
!!!    * pkg_preinst (/tmp/portage/sys-apps-portage-2.2.0/temp/loadsaveenv:4014)
!!!    * ebuild_f_preinst (/usr/libexec/paludis/0/pkg_preinst.bash:43)
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:668)
!!!    * main (/usr/libexec/paludis/ebuild.bash:691)

diefunc: making ebuild PID 11409 exit with error
die trap: exiting with error.


oddly, "portageq envvar SYNC" does in fact work just fine.

I'm not sure if this is paludis interaction to blame yet, but I'm just being up front about it, because I haven't tested this version on portage yet.

[Comment 1 Kent Fredric (IRC: kent\n) (RETIRED) 2013-08-14 07:41:47 UTC]

Created attachment 355950 [details]
emerge --info sys-apps/portage

Not likely hugely relevant, because haven't used emerge on this box for a few years now.

[Comment 2 Kent Fredric (IRC: kent\n) (RETIRED) 2013-08-14 07:46:23 UTC]

Ok, further looking suggest paludis is to blame here, because it has its own implementation of portageq:

/usr/libexec/paludis/0/portage_stubs.bash:        die "portageq emulation for $1 not implemented"



=sys-apps/paludis-1.4.0

[Comment 3 cmuelle8 2013-08-16 14:23:07 UTC]

(In reply to Kent Fredric from comment #2)
> Ok, further looking suggest paludis is to blame here, because it has its own
> implementation of portageq:
> 
> /usr/libexec/paludis/0/portage_stubs.bash:        die "portageq emulation
> for $1 not implemented"
> 
> 
> 
> =sys-apps/paludis-1.4.0

Same problem here.

[Comment 4 Petr Zima 2013-08-17 21:34:12 UTC]

Same here, paludis-1.4.0.

[Comment 5 gourichon nicolas 2013-08-20 20:50:29 UTC]

same problem (paludis 1.4.0)

[Comment 6 Alex Turbov 2013-08-22 08:51:24 UTC]

anyone have any idea that this message about?
I'm really tired to watch it few weeks...

[Comment 7 Simon Kohlmeyer 2013-08-23 21:40:08 UTC]

Looks like something that is missing in paludis. I opened a ticket on the paludis trac.

http://paludis.exherbo.org/trac/ticket/1283

[Comment 8 Kent Fredric (IRC: kent\n) (RETIRED) 2013-08-24 12:46:18 UTC]

Paludis are adamant its an ebuild problem.

Indeed, it can be fixed at the ebuild level, by replacing:

type portageq >/dev/null 2>&1 && \
 REPOS_CONF_SYNC=$(portageq envvar SYNC)

with:

 type -f portageq >/dev/null 2>&1 && \
 REPOS_CONF_SYNC=$($(type -fp portageq) envvar SYNC)

This simply side-steps any function stubs ( such as those paludis provides ) and uses the executable in $PATH

[Comment 9 Simon Kohlmeyer 2013-08-24 14:04:21 UTC]

I can confirm that this fixes the problem

[Comment 10 Zac Medico 2013-08-24 15:02:19 UTC]

This is fixed in cvs now:

--- portage-2.2.1.ebuild        22 Aug 2013 04:45:46 -0000      1.1
+++ portage-2.2.1.ebuild        24 Aug 2013 14:54:06 -0000
@@ -430,8 +430,8 @@
                USERSYNC_UPGRADE=true
                REPOS_CONF_UPGRADE=true
                REPOS_CONF_SYNC=
-               type portageq >/dev/null 2>&1 && \
-                       REPOS_CONF_SYNC=$(portageq envvar SYNC)
+               type -P portageq >/dev/null 2>&1 && \
+                       REPOS_CONF_SYNC=$($(type -P portageq) envvar SYNC)
        else
                USERPRIV_UPGRADE=false
                USERSYNC_UPGRADE=false

[Comment 11 Jeff (JD) Horelick (RETIRED) 2014-08-25 21:36:27 UTC]

Resolving as fixed. There are only 2 portage ebuilds in tree that have this issue. 1 is masked and 1 is the same EAPI and has the same deps as portage-2.2.1 (and is older) so there's little reason for it to be used.

Closing