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

[Zac Medico]

On 11/07/2014 03:13 AM, Rich Freeman wrote:
> On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico <zmedico@g.o> wrote:
>> 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.
>>
>
> Deprecate it?  But what about providing EAPI7 support for EAPI6
> packages?  The description doesn't say that the eclass is intended to
> provide EAPI6 support for EAPI5 packages - it says that it is intended
> to provide EAPIn+1 support for EAPIn packages.

Okay, then we could number the future eclasses by EAPI. Like
future-eapi-6, future-eapi-7, and so on.

> Of course, this approach tends to make the assumption that EAPIs are
> orderable, which isn't actually something anybody has committed to as
> far as I'm aware.  The next EAPI /could/ be named "webapp-1" and only
> be used for web applications.  Granted, there have been no plans to
> date to deviate from the linear EAPI history we've maintained so far.

We could also add a future-eapi-webapp-1 eclass.

> I'm still concerned that in general we tend to have packages hang
> around at older EAPIs for a long time as it is.  That isn't really a
> problem if those EAPIs are stable and supported for a while.  This
> seems likely to complicate things.

Sure, it could. However, it should be pretty manageable if we use a
separate future eclass for each EAPI.

> There is no guarantee that moving
> to the actual new EAPI won't break something, and packages that don't
> move become blockers for the eclass being able to move on to the next
> EAPI.
-- 
Thanks,
Zac