On Sonntag, 11. November 2007, Ciaran McCreesh wrote: > I suspect that for existing eclasses, the safest way to proceed is to > make a new eclass and move common code into a third eclass. So you'd > have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common, > and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting > foo-common.
And this is where it gets ugly - maybe finally a good reason for versioned eclasses (though I fear the misuse). That it is not possible today to let an ebuild die in global scope is not a big issue, as you can in pkg_setup(), just as with missing use dependencies, just that the developer in question /should/ stumble about it, so in the best of all worlds the user base wouldn't ever notice. The only problem is the weakest link: One of us missing to care to invoke <eclass>_pkg_setup(), when necessary. Maybe it would in general not be bad to require eclass phase functions to be called, when the inheriting ebuild/eclass writes a custom phase function and having Portage to complain about it, unless some override_<eclass-phase> variable is set. Carsten
signature.asc
Description: This is a digitally signed message part.
