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

[Ionen Wolkens]

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.

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.
-- 
ionen