When doing eix-update with repository not having a metadata cache and a recent Portage version, I get a number of bash errors: /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[1] /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[0] /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[1] /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[0] /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[1] /usr/src/gx86/eclass/eutils.eclass: line 146: no match: _ESTACK_eshopts_[0] This is because of failglob being enabled in EAPI 6. However, the option should not apply to earlier EAPIs. This is done via ${EAPI} check (___eapi_enables_failglob_in_global_scope call) in Portage's bin/ebuild.sh. The check assumes that Portage has set the initial value of EAPI as parsed per the PMS rules, since that's what Portage does. However, eix doesn't implement that and therefore calls ebuild.sh incorrectly.
Thanks for the report and for the analysis. I do not know what is the best to do about this problem: The whole cache method ebuild* is rather fragile in eix since it is using the undocumented ebuild.sh "interface": Probably a whole lot of variables are not set correctly, and the method is only repaired heuristically after bug reports... I am not sure whether it is worth implementing even further hacks for the current issue which also make the method slower. Perhaps this method should be deprecated and replaced by cache method "ebuild" which uses "ebuild depend" which is at least semi-official (although also undocumented). The disadvantage of the latter is the speed, of course. Or might it be possible to provide some quicker "clean" portage interface to "ebuild depend"?
For people running into the problem and reading this bug: A temporary workaround is to set OVERLAY_CACHE_METHOD="parse|ebuild" e.g. in /etc/eixrc/10-overlay-cache-method which changes the default from cache method(s) 'parse|ebuild*' to 'parse|ebuild' for overlays.
CC-ing dev-portage@ for opinion on comment #1.
(In reply to Martin Väth from comment #1) > I am not sure whether it is worth implementing even further hacks for the > current issue which also make the method slower. Yeah, I never would have recommended ebuild.sh for external consumers, since the interface often needs to change. > Perhaps this method should be deprecated and replaced by cache method > "ebuild" which uses "ebuild depend" which is at least semi-official > (although also undocumented). The disadvantage of the latter is the speed, > of course. "portageq metadata" is the closest existing alternative, with similar performance to "ebuild depend". > Or might it be possible to provide some quicker "clean" portage interface to > "ebuild depend"? Sure. Maybe a new portageq sub-command that reads package names from stdin, and writes metadata to stdout as JSON objects?
(In reply to Zac Medico from comment #4) > > Sure. Maybe a new portageq sub-command that reads package names from stdin, > and writes metadata to stdout as JSON objects? For eix, it would be simpler to just have the output of "metadata" or of "metadata-md5", since the corresponding parsers are already built-in, and I do not want to include some new JSON parser as well. However, if performance would not be quicker, then I think it is best to remain with "ebuild depends". The recommended way is to use egencache and metadata{,-md5}, anyway... So, I guess that I will deprecate cache method "ebuild*" in the next eix version, probably by making it equivalent to "ebuild".
(In reply to Martin Väth from comment #5) > (In reply to Zac Medico from comment #4) > > > > Sure. Maybe a new portageq sub-command that reads package names from stdin, > > and writes metadata to stdout as JSON objects? > > For eix, it would be simpler to just have the output of "metadata" or of > "metadata-md5", since the corresponding parsers are already built-in, and I > do not want to include some new JSON parser as well. > > However, if performance would not be quicker, then I think it is best to > remain with "ebuild depends". The recommended way is to use egencache and > metadata{,-md5}, anyway... What is the main reason for poor performance here? If it's startup time, then having a stdin/stdout interface with portageq being started once would indeed be faster. > So, I guess that I will deprecate cache method "ebuild*" in the next eix > version, probably by making it equivalent to "ebuild". Well, you can also add the EAPI parsing code. It's rather straightforward by definition and limited to simple matches on the first few lines of ebuild.
(In reply to Michał Górny from comment #6) > > What is the main reason for poor performance here? I don't know. ebuild.sh is about 2.5 times faster than ebuild depend. > If it's startup time I made no benchmarks, but I guess so (startup of python code?) > then having a stdin/stdout interface with portageq being started once would > indeed be faster. Yes, probably. But whether it is worth the hassle? So far, the cache class is just called once per ebuild/category (and delegates to corresponding cache method). It would need a rather different logic: start tasks in the background, communicate, know when to close, have traps in case of errors etc. I am not very keen to implement such a thing, especially since it will probably not be dramatically faster, and I do not have much time at all, currently: People who want it fast should use egencache anyway, everything else is just a poor substitute. > Well, you can also add the EAPI parsing code Yes, I also thought about this. It is certainly less work than the above restructuring of the whole internal logic. Maybe if I find sufficient time, I will do this. > It's rather straightforward by definition Well, I would use the result of the parse cache method for value EAPI - this would be the simplest thing. Slightly more tricky is to cache the result e.g. in case of "parse|ebuild*", and much more tricky is to find the time to implement anything at all - especially, if it might happen that in the next portage version something else is broken with that method (if you remember, I just fixed it recently, again...)
This should be fixed in >=eix-0.30.6 (currently eix git master branch): I found a free hour today and implemented setting of EAPI for ebuild* However, I cannot test, since I was never able to produce the error message. Thus, I only tested that the EAPI is exported when ebuild.sh is called.
Since I got a positive report by pm, I released now eix-0.30.6 with the fix (cache method ebuild* is still the default and sets EAPI). Until eix-0.30.6 is in the tree, I would mark this bug as "in progress" but it seems this status is no longer available...
where is 0.30.6? I've only found 0.30.5 here[1] [1] https://github.com/vaeth/eix/releases
