On 11/06/2014 01:53 PM, Rich Freeman wrote: > On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <mgo...@gentoo.org> wrote: >> >> # This eclass contains backports of functions that were accepted >> # by the Council for the EAPI following the EAPI used by ebuild, >> # and can be implemented in pure shell script. > > I'm not sure that I like this sort of a moving-target definition. > When EAPI6 is out, do you intend to have the eclass die at some point > for any packages using EAPI5?
We should be able to simply migrate consumers to the new EAPI, then deprecate future.eclass. > Or will they work indefinitely, and > then the eclass will behave differently depending on what EAPI is used > by the ebuild calling it? I can see issues either way (either we're > building a monster eclass that basically replicates half of PMS, or we > start running into migration issues and maybe even breakage of old > systems that aren't updated/etc). Old systems are not a problem, since installed packages always use serialized eclasses from /var/db/pkg/*/*/environment.bz2. The biggest problem would be out-of-tree ebuilds (overlays) that continue to use future.eclass after it's been deprecated. > If this were about testing EAPI features prior to implementation in a > limited and short-term scenario I could maybe see this being a > net-positive, but even then we have issues with the eclass changing > when users still have packages using it installed. No, as said, installed packages use serialized eclasses from /var/db/pkg/*/*/environment.bz2. > I get what you're trying to do, but I'm a little worried that it might > cause as many problems as it solves. Given that old systems aren't a problem, out-of-tree ebuilds are the main issue that I can think of. -- Thanks, Zac
