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

[Zac Medico]

On 11/06/2014 01:53 PM, Rich Freeman wrote:
> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <mgorny@g.o> 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