On 08/30/2017 01:31 PM, Michał Górny wrote: > W dniu śro, 30.08.2017 o godzinie 10∶48 -0700, użytkownik Zac Medico > napisał: >> On 08/30/2017 02:06 AM, Michał Górny wrote: >>> The value of get_libdir depends on the profile, and so it is not useful >>> for dependency calculations. Furthermore, it seems that Portage does >>> not handle defining it in global scope well due to EAPI checking magic. >>> Ban it completely where it is defined as EAPI function to let developers >>> catch their mistakes early rather than see them as 'command not found' >>> errors during dependency calculation / cache updates. >>> >>> Bug: https://bugs.gentoo.org/629010 >>> --- >>> bin/ebuild.sh | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/bin/ebuild.sh b/bin/ebuild.sh >>> index a400ef72e..f1ac3f278 100755 >>> --- a/bin/ebuild.sh >>> +++ b/bin/ebuild.sh >>> @@ -66,6 +66,7 @@ else >>> use useq usev use_with use_enable" >>> ___eapi_has_usex && funcs+=" usex" >>> ___eapi_has_in_iuse && funcs+=" in_iuse" >>> + ___eapi_has_get_libdir && funcs+=" get_libdir" >>> # These functions die because calls to them during the "depend" phase >>> # are considered to be severe QA violations. >>> funcs+=" best_version has_version portageq" >>> >> >> It's possible that there are working ebuilds that call get_libdir in >> global scope. Have we done an analysis of the ebuilds in the gentoo >> repository? Obviously, it would be safer to call eqawarn. > > If there were any (more), we'd have caught them during cache regen, > wouldn't we? When I accidentally left it when bumping to EAPI 6, I've > got a bug report almost immediately.
We'll only catch it during cache regen if we delete all of the previous cache, forcing all of the ebuilds to be sourced again. If all ebuilds in the gentoo tree are compliant, the I think that's good enough for us to die here. -- Thanks, Zac
