William Hubbs posted on Sat, 16 Aug 2014 18:01:08 -0500 as excerpted: > 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.
Of course that can be foreseen since the eclass is directly inherited and an ebuild writer could do... ECLASS_EXCLUDE="foo_src_unpack bas_src_unpack bar_src_unpack" ... even if there isn't one, since an ebuild writer can be presumed to know what his inherit line is. But what about Nth generation inherits? Suppose the foo eclass maintainer decides to inherit raz, and there's a raz_src_unpack, what then? So with reverse-logic excludes, to be sure he gets what he intended in the default_src_unpack wanted scenario above, an ebuild writer will have to create a src_unpack that simply calls default_src_unpack. Of course that's the way it is today too, but it's much more of a trap with reverse- logic as now you pretty-much have to do your src_unpack simply calling default_src_unpack from the get-go, while with reverse-logic, it might be fine from the get-go, and only break in some rather hidden and non- intuitive Nth-level inheritance case much later. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
