On Thu, Nov 6, 2014 at 5:09 PM, Andreas K. Huettel <dilfri...@gentoo.org> wrote: > 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.
I don't see perl MODULES as being a bad use of this, but an all-in-one eclass that was intended for packages that were written (partially or totally) in perl would not be a good thing IMO. The problem comes when you get into situations where the perl gurus wanted a fancy eclass, and the python maintainers wanted a fancy eclass, and the games maintainers wanted a fancy eclass, and your package is a game that includes some files written in python and perl. When you have a bunch of packages that tend to come from the same upstream with the same development/release/packaging practices then sure, an all-in-one can make the ebuilds a lot cleaner. I think we're on the same page in any case. -- Rich
