On Thu, Aug 30, 2012 at 3:44 PM, Thomas Sachau <to...@gentoo.org> wrote: > Andreas K. Huettel schrieb: >> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell: >>> Could you elaborate what the reasons FOR it are (not that I don't know >>> any, but you brought it up) since this will add work for every developer >>> to check a) how the behavior of the new EAPI impacts the current ebuild >>> and b) how the behvaior of inherited eclasses change depending on EAPI. >> >> a) Easier eclass maintenance. >> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler. >> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the >> tree.) > > An eclass, which includes helper commands like eutils or versionator > eclass wont benefit from it. Only specific eclasses (like your kde > example would benefit and for those, the related team can always decide > to bump all their packages to the wanted EAPI and then to bump the > eclass requirement. So no need to force this on everyone else.
Agreed. I'm fine with asking maintainers to change EAPI in specific cases where there is a specific benefit. Diego sends me bug reports from time to time for whatever odd set of circumstances cause some kind of problem on a tinderbox, and when I can I fix the bugs and report upstream. The result is a better experience for all, even beyond Gentoo. If somebody wants to drop code in qt.eclass or whatever and my bumping EAPI makes their life easier they can always ask nicely and I'm happy to help out. What I don't see the value in is policies that extend the work beyond where the benefit lies. Rich
