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. > > b) Easier overall tree maintenance. > I've recently removed a useflag on poppler (xpdf-headers for those > interested). Of course, this involved fixing all in-tree reverse dependencies > first. Now I consider myself very lucky there, because all except two > packages > were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously > bumped it to 4. One was EAPI 0. Having fun with || there. If a package has a maintainer, you could just ask him to fix the issue, so you dont have to even think about the EAPI. And if there is no maintainer, you can take and bump it. And if noone wants to maintain it, it will be dropped at some point. So you can bump whatever you maintain, just still the question: Why force this on everyone else? -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
