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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to