On Thu, 16 Mar 2017 13:57:44 +0100 Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Thu, 16 Mar 2017, Alexis Ballier wrote: > > > Indeed, but that eclass fails to follow devmanual eclass 101 [1]: > > An eclass is a collection of code which can be used by more than one > > ebuild. > > Which is the case here: > > sys-devel/autoconf/autoconf-2.13.ebuild | 10 +--- > sys-devel/autoconf/autoconf-2.59-r7.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.61-r2.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.62-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.63-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.64.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.65-r1.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.67.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.68.ebuild | 11 +--- > sys-devel/autoconf/autoconf-2.69-r2.ebuild | 11 +--- > sys-devel/autoconf/autoconf-9999.ebuild | 15 ++--- You're trying to find loopholes in the wording here, aren't you ? :) > > While this eclass might be a good temporary solution, I find it a > > rather convincing argument for per-package eclasses :) > > Yes, if there was sufficient demand for such a feature, and it would > therefore reduce the number of global eclasses significantly. IMHO it > wouldn't be worth it for only a handful of packages. What do you consider demand ? A handful of packages that have to write a hundred lines of boilerplate code to make it work isn't representative of any demand at all. I've already written in some bug some usecases I foresee for even a trivial 'include'.
