Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[William Hubbs]

On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote:
> On 17 August 2014 09:54, William Hubbs <williamh@g.o> wrote:
> > My counter proposal to this is that we stop calling eclass phase
> > functions automatically, and to minimize the amount of boilerplating
> >   we would have to do, we use a variable, such as ECLASS_PHASES  which
> >   would be defined at the ebuild level and contain a list of the eclass
> >   phase functions we want to run automatically.
>
> This proposal, seems reasonable, given my comments. I anticipate however
> its biggest downside would be
> the requirement to state *all* the functions you want, which would lead to
> maintenance headaches
> due to people forgetting to declare they wanted some function or other.
>
> So if you could sculpt it to be broader by default and have less scope for
> developer error, that'd be an improvement.
>
> --- code start --
> ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
> inherit foo bar baz
>
>
> --- code end ---
>
> here, src_unpack would be baz_src_unpack *regardless* of composition order
> because "foo" and "bar" were barred from being used, and baz took
> precedence as a result.
>
> If baz provides no src_unpack, then the ebuild in question is simply left
> without one.

My concern about reverse logic like excludes is this:

-- code start --

# foo and bas provide src_unpack, but you don't want the PMS default
# src_unpack to run them, and bar does not provide src_unpack:
# You want the rest of the PMS default src_unpack actions to run, so you
# don't write src_unpack.

ECLASS_EXCLUDE="foo_src_unpack bas_src_unpack"
inherit foo bar bas

-- code stop --

This works fine until the eclass maintainer for bar.eclass decides to
add bar_src_unpack.

As soon as that happens, your ebuild is broken.

William