On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau <[email protected]> wrote: > Michael Mol schrieb: >> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <[email protected]> wrote: >>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <[email protected]> wrote: >>>> >>>> The primary benefit to the policy that dev's should bump EAPI when >>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and >>>> eventually removed from the tree. >>> >>> What is the benefit from removing the old EAPIs? >> >> I can answer this one...removing old EAPIs simplifies code for things >> which need to be EAPI-aware. There are no bugs in code that doesn't >> exist. >> > > Like package managers? > > Sorry, but this is not true, since you can never assume, that older > EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never > needed a bump, is enough), so older EAPI versions have to be supported > forever.
I would assume that's what auditing is for. Unless I'm sorely mistaken (and I may be; I don't know much at all about eclasses), it should be fairly simple to script through the tree to find any eclasses or ebuilds which express a dependency on an EAPI of a given level, presuming the expression is of a standard form. Compile a list of existing ebuilds which depend on old EAPIs, and you've got a TODO list. (eclasses, I don't know; I don't know if eclasses explicitly express EAPI compatibility in metadata) Once that list is cleared, yes, you can assume there are no ebuilds with a specified EAPI of 0. I'd presume it would have been made widely known that new ebuilds shouldn't use the old EAPI by that point, and so support for the deprecated EAPI level can be abandoned. Out-of-tree ebuilds pose their own problems, but that's a matter for the managers of the relevant overlays. Now, for the million-dollar question: Who should do the work? My answer would be "whoever wants it done." Whoever wants the work done can go through their audit list and submit the relevant patches to the maintainers. Whether that's a team of twenty people or the work of an individual with a shell script and a lot of time on his hands, that's where that kind of work belongs. Now, if a maintainer rejects the patch, then the submitter can fix the patch to the maintainer's specifications. If the maintainer rejects the patch on some principle, that's an issue that can be raised and dealt with rationally at the time it happens. I imagine most maintainers would welcome assistance, especially if it means simplifying future work they may need to do. -- :wq
