Re: [gentoo-dev] The inherit-EXPORT_FUNCTIONS ordering problem

[Sam James]

> On 29 Aug 2021, at 19:41, Ionen Wolkens <ionen@g.o> wrote:
>
> On Sun, Aug 29, 2021 at 12:23:22PM -0500, William Hubbs wrote:
>> On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote:
>>> Hi,
>>>
>>> I've been informed of a slight inconsistency in package manager behavior
>>> that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
>>> for the report!).  Please consider the three following snippets:
>>
>> ...
>>
>>> 1. I'd like to propose that we explicitly require all inherits to happen
>>> before EXPORT_FUNCTIONS.  This will ensure consistent behavior across
>>> all package managers.
>>>
>>> 2. I'd like to ask your opinion whether we should:
>>>
>>> a. revert the Portage behavior to be consistent with PkgCore/Paludis
>>>
>>> b. update PMS to identify the behavior as 'undefined', i.e. either
>>> solution is correct.
>>
>> I would go with 1 and 2 b, but I also propose another option for the
>> next eapi which may be a bit controversial.
>>
>> Starting with eapi 9, make export_functions a noop (you can't remove it
>> until all eclasses/ebuilds only support eapis that don't require it).
>>
>> I understand that this is controversial, because it would require a lot
>> of work to convert ebuilds to eapi 9, but it would eliminate this
>> ambiguity/inconsistency in the future because it would require all
>> ebuilds to have phase functions unless they can use the default phases
>> the eapis provide.
>>
>> Thoughts?
>
> If anything I'd personally prefer the rough opposite of this, in the
> event multiple eclass export the same, have the package manager merge
> them.

This is my preference too, if we're to go this route.

It's similar to what was proposed in https://bugs.gentoo.org/516014, although
this topic tends to lead to lots of different ideas (sometimes solving different
problems!)

>
> e.g. rather than have `inherit cmake xdg` run xdg_src_prepare over
> cmake's, would export:
>
> src_prepare() {
> 	cmake_src_prepare
> 	xdg_src_prepare
> }
>
> unless the ebuild redefines it (which I imagine would often be because
> of optional support, e.g. use lua &&, or occasional incompatibilities)
>
> Some ebuilds have special needs, but then there's all those generic
> ebuilds that should stay nearly empty.

best,
sam