>>>>> On Fri, 7 Nov 2014, Rich Freeman wrote: > I am still a bit uneasy, but I definitely agree that if we do this I'd > much rather see a series of versioned eclasses than an eclass whose > functionality changes in place over time.
> Ulm's point still exists that technically EAPI6 isn't actually > approved yet, in part because the agreement was that nothing gets > approved for good without a reference implementation in portage. So, > there is some risk that it could change, which might mean that ebuilds > that use future.eclass would need more work when moving them to an > EAPI that no longer contains the function they call. > That said, the whole point of the council vote was to avoid having the > PM teams spending time on features that were going to get voted out at > the last minute. Assuming that all goes as planned the actual PMS > vote should be a formality, but you know how plans go... :) I had thought that the lesson from premature implementation of the einstalldocs function in an eclass had been learned. There we have the problem that the eclass function is incompatible with what will be implemented in the package manager. Now we will have a third implementation of einstalldocs, along with a third implementation of the patch applying function. (The whole point of eapply is that it will be implemented in the PM; in eclasses we already have epatch which is more sophisticated.) Also I still don't see what problem future.eclass would solve. It doesn't save the EAPI bump, so the maintainer will have to update the ebuild twice, users will have to rebuild the package twice, and arch teams will have to stabilise twice. Besides, an eclass like this would also undermine the council's and QA team's efforts to keep the number of EAPIs in tree limited. Ulrich
pgpOCTDmB9yz6.pgp
Description: PGP signature
