# default lisp if use arm; then DEF_LISP=2 # gcl else DEF_LISP=0 # sbcl fi DEF_DEP="${DEF_DEP} `depends ${DEF_LISP}`" This is a huge QA violation. Both global scope use calls are forbidden, and metadata becomes invariant (cache invalidated etc.). You really are supposed to be doing "arm? ( ... ) !arm? ( ... )" there.
In this ebuild DEPEND and RDEPEND strings are generated by a complicated calculation from simple arrays LISPS, SUPP_RL, CONF_FLAG, PATCH_V. This makes adding a new lisp implementation, or removing one of them, a trivial operation. Long ago, after big rewrites of the ebuild to add a new lisp, I implemented this table-driven approach. Suppose I want to add dev-lisp/abcl (it is already nearly OK for compiling maxima); with the current ebuild, I just add 1 more element to these 4 arrays, and don't touch the code. OK, I suppose I can generate programmatically (without use call) DEF_DEP containing arm? ( !clisp? ( !clozurecl? ( !ecls? ( !gcl? ( !cmucl? ( !sbcl? ( dev-lisp/gcl ) ) ) ) ) ) ) !arm? ( !clisp? ( !clozurecl? ( !ecls? ( !gcl? ( !cmucl? ( !sbcl? ( dev-lisp/sbcl app-misc/rlwrap ) ) ) ) ) ) ) (when abcl will be added, these things will become more deeply nested). Will this be OK?
Can't you just use: DEF_DEP="${DEF_DEP} arm? ( $(depends 2) ) !arm? ( $(depends 0) )" ?
OK, the fixed ebuild is maxima-5.37.3-r1.ebuild; I've removed 5.37.3 and 5.36.1. The only remaining ebuild with wrong dependencies is 5.34.1, it is stable on amd64, ppc and x86. I can, of course, produce the fixed 5.34.1-r1, but I cannot remove 5.34.1 until at least one of the corected ebuilds is stabilized on these 3 arches. And the time needed for stabilization of this 5.34.1-r1 would be not shorter than of the current 5.37.3-r1. So, I see no good reasons to introduce this 5.34.1-r1 to the tree. As soon as 5.37.3 is stabilized on amd64, ppc and x86, I'll remove 5.34.1.
* ERROR: sci-mathematics/maxima-5.34.1::gentoo failed (depend phase): * use() calls are not allowed in global scope * * Call stack: * ebuild.sh, line 606: Called source '/home/mgorny/git/gentoo/sci-mathematics/maxima/maxima-5.34.1.ebuild' * maxima-5.34.1.ebuild, line 66: Called use 'arm' * ebuild.sh, line 78: Called die * The specific snippet of code: * eval "${x}() { die \"\${FUNCNAME}() calls are not allowed in global scope\"; }" * * If you need support, post the output of `emerge --info '=sci-mathematics/maxima-5.34.1::gentoo'`, * the complete build log and the output of `emerge -pqv '=sci-mathematics/maxima-5.34.1::gentoo'`. * Working directory: '/usr/lib64/python3.5/site-packages' * S: '/tmp/portage/sci-mathematics/maxima-5.34.1/work/maxima-5.34.1' Please either backport or remove that version.
I can easily commit maxima-5.34.1-r1 with the fix, then wait 30 days, then ask to stabilize it. I doubt that it will be stabilized earlier than maxima-5.37.3-r4, stabilization bug for which has been filed on 2016-01-31.
You can also fix it in place, and don't bother the stablereq flow. One month from now, arch teams won't probably even be able to run repoman in that directory, not to mention stabilizing anything.
(In reply to Michał Górny from comment #6) > You can also fix it in place, and don't bother the stablereq flow. Thus violating a lot of written rules? :-) In fact, I think the situation is far from critical. maxima-5.34.1 is not keyworded arm, and never will be. So, if use arm; in it will always return false. No unpredictable dependencies can ever be saved in the database. What is saved is correct. Why not wait calmly until all the arches, namely x86 and ppc, stabilize maxima-5.37.3-r4, and then remove maxima-5.34.1?
Because the next release of Portage completely bails out upon meeting this directory, on every arch.
commit d3719379ce98a943a373eb25803eb6da461546e3 Author: Andrey Grozin <grozin@gentoo.org> Date: Mon Jun 6 17:44:03 2016 +0600 Fix #566550 in stable Package-Manager: portage-2.3.0_rc1
