On 08/30/2017 01:45 PM, Michał Górny wrote: > W dniu śro, 30.08.2017 o godzinie 13∶35 -0700, użytkownik Zac Medico > napisał: >> 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. > > I'm pretty sure all of them are. However, if someone has resources to > spare, I'd appreciate running a full regen with the patch to confirm.
Confirmed. Please merge the patch. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature