1 |
On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico <zmedico@g.o> wrote: |
2 |
> On 11/06/2014 01:53 PM, Rich Freeman wrote: |
3 |
>> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <mgorny@g.o> wrote: |
4 |
>>> |
5 |
>>> # This eclass contains backports of functions that were accepted |
6 |
>>> # by the Council for the EAPI following the EAPI used by ebuild, |
7 |
>>> # and can be implemented in pure shell script. |
8 |
>> |
9 |
>> I'm not sure that I like this sort of a moving-target definition. |
10 |
>> When EAPI6 is out, do you intend to have the eclass die at some point |
11 |
>> for any packages using EAPI5? |
12 |
> |
13 |
> We should be able to simply migrate consumers to the new EAPI, then |
14 |
> deprecate future.eclass. |
15 |
> |
16 |
|
17 |
Deprecate it? But what about providing EAPI7 support for EAPI6 |
18 |
packages? The description doesn't say that the eclass is intended to |
19 |
provide EAPI6 support for EAPI5 packages - it says that it is intended |
20 |
to provide EAPIn+1 support for EAPIn packages. |
21 |
|
22 |
Of course, this approach tends to make the assumption that EAPIs are |
23 |
orderable, which isn't actually something anybody has committed to as |
24 |
far as I'm aware. The next EAPI /could/ be named "webapp-1" and only |
25 |
be used for web applications. Granted, there have been no plans to |
26 |
date to deviate from the linear EAPI history we've maintained so far. |
27 |
|
28 |
I'm still concerned that in general we tend to have packages hang |
29 |
around at older EAPIs for a long time as it is. That isn't really a |
30 |
problem if those EAPIs are stable and supported for a while. This |
31 |
seems likely to complicate things. There is no guarantee that moving |
32 |
to the actual new EAPI won't break something, and packages that don't |
33 |
move become blockers for the eclass being able to move on to the next |
34 |
EAPI. |
35 |
|
36 |
-- |
37 |
Rich |