Re: [gentoo-dev] RFC: future.eclass

[Ulrich Mueller]

>>>>> 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