Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman: > > I think we are well-served by taking Ciaran's advice here. Utility > eclasses should just passively export functions. Anything that does > overrides should really be designed for special situations and not > widespread use where it would potentially conflict with other eclasses > that do the same. So, a KDE all-in-one eclass might not be bad. A > perl all-in-one eclass would be more troublesome,
Bad example. :) We have ca 1800 packages in the portage tree inheriting perl- module.eclass and most of them do not declare any phases themselves but just inherit eclass phases. Which works fine and reduces most ebuilds to a bare minimum. But yes, in general the idea of separating utility eclasses and phase eclasses somehow is imho a good one. My personal suggestion would be for a future EAPI to only allow "export all phases, if necessary autogenerated dummies" or "export no phases". -- Andreas K. Huettel Gentoo Linux developer [email protected] http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
