On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote: > On 17 August 2014 09:54, William Hubbs <willi...@gentoo.org> 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
signature.asc
Description: Digital signature
