| 1 |
Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman: |
| 2 |
> |
| 3 |
> I think we are well-served by taking Ciaran's advice here. Utility |
| 4 |
> eclasses should just passively export functions. Anything that does |
| 5 |
> overrides should really be designed for special situations and not |
| 6 |
> widespread use where it would potentially conflict with other eclasses |
| 7 |
> that do the same. So, a KDE all-in-one eclass might not be bad. A |
| 8 |
> perl all-in-one eclass would be more troublesome, |
| 9 |
|
| 10 |
Bad example. :) We have ca 1800 packages in the portage tree inheriting perl- |
| 11 |
module.eclass and most of them do not declare any phases themselves but just |
| 12 |
inherit eclass phases. Which works fine and reduces most ebuilds to a bare |
| 13 |
minimum. |
| 14 |
|
| 15 |
But yes, in general the idea of separating utility eclasses and phase eclasses |
| 16 |
somehow is imho a good one. My personal suggestion would be for a future EAPI |
| 17 |
to only allow "export all phases, if necessary autogenerated dummies" or |
| 18 |
"export no phases". |
| 19 |
|
| 20 |
-- |
| 21 |
|
| 22 |
Andreas K. Huettel |
| 23 |
Gentoo Linux developer |
| 24 |
dilfridge@g.o |
| 25 |
http://www.akhuettel.de/ |
Archives