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

[Michał Górny]

On Sun, 2021-08-29 at 14:41 -0400, Ionen Wolkens 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.
>
> 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.

What about transitive inherits?  Say, foo.eclass inherits bar.eclass. 
Does that imply that the ebuild calls foo_src_prepare
and bar_src_prepare, and the eclass has no way of overriding this?  What
if the eclass needs bar_src_prepare called explicitly before or after
its own src_prepare?

-- 
Best regards,
Michał Górny