1 |
On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
> # This eclass contains backports of functions that were accepted |
4 |
> # by the Council for the EAPI following the EAPI used by ebuild, |
5 |
> # and can be implemented in pure shell script. |
6 |
|
7 |
I'm not sure that I like this sort of a moving-target definition. |
8 |
When EAPI6 is out, do you intend to have the eclass die at some point |
9 |
for any packages using EAPI5? Or will they work indefinitely, and |
10 |
then the eclass will behave differently depending on what EAPI is used |
11 |
by the ebuild calling it? I can see issues either way (either we're |
12 |
building a monster eclass that basically replicates half of PMS, or we |
13 |
start running into migration issues and maybe even breakage of old |
14 |
systems that aren't updated/etc). |
15 |
|
16 |
If this were about testing EAPI features prior to implementation in a |
17 |
limited and short-term scenario I could maybe see this being a |
18 |
net-positive, but even then we have issues with the eclass changing |
19 |
when users still have packages using it installed. |
20 |
|
21 |
I get what you're trying to do, but I'm a little worried that it might |
22 |
cause as many problems as it solves. |
23 |
|
24 |
--- |
25 |
Rich |