1 |
On Sun, Sep 2, 2012 at 6:52 AM, Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
2 |
> So in any case, for the _user_ an EAPI bump is (with the current EAPIs) |
3 |
> always a benefit. This should be worth to establish the policy currently. |
4 |
|
5 |
Your example only cited cases where an EAPI bump to 5 has a benefit. |
6 |
If that is the case, I'm fine with making an effort to migrate as many |
7 |
ebuilds as possible to EAPI 5. |
8 |
|
9 |
However, what is the benefit to users from migrating to EAPI 1, or 2, |
10 |
etc? The policy you're recommending would have required expending |
11 |
effort to implement every one of those for every ebuild in the tree |
12 |
without those kinds of end-user benefits. |
13 |
|
14 |
What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs |
15 |
are not numbers, and they aren't ordered either)? And since EAPIs |
16 |
aren't actually ordered, is the latest one whichever is actually last |
17 |
approved, or the one which is "most functional?" Suppose EAPI xml |
18 |
defines an ebuild format in xml that isn't parsed by bash, whose |
19 |
purpose is mainly to allow simple ebuilds to be simplified further but |
20 |
which is really only appropriate for 20% of the ebuilds in the tree? |
21 |
It isn't good to assume that newer EAPIs include all the features of |
22 |
the earlier ones - they just are different specifications for |
23 |
behavior. Maybe somebody will come up with a reason to have an EAPI |
24 |
that only works with packages that use cmake for building, or |
25 |
whatever. The bottom line is that it may be desirable in the future |
26 |
to have different branches of EAPIs followed by different packages. |
27 |
|
28 |
So, if we want to make a policy that we should use EAPI5 whenever |
29 |
possible I'm fine with that, if the benefits to users are worth the |
30 |
costs. However, why extend this to every EAPI that follows when the |
31 |
benefits of those are not yet known? |
32 |
|
33 |
Let's look at a different situation - --as-needed. It was realized |
34 |
that supporting this across the tree has significant benefits for |
35 |
users, so we made a push to make it happen. Packages that didn't |
36 |
support this had bugs filed, and they were fixed, and today it is the |
37 |
default. However, what we DIDN'T do is just make a policy that all |
38 |
packages have to support all possible options in LDFLAGS, but rather |
39 |
we just focused on the one we actually cared about. |
40 |
|
41 |
You don't even need a "policy" to enact these kinds of changes. There |
42 |
was never a policy that all ebuilds must support --as-needed, and |
43 |
there may be legitimate reasons for individual packages to not support |
44 |
it today. However, when the case was made that this benefits |
45 |
end-users then everybody just jumped on board, since, well, most of us |
46 |
are nice guys who do that sort of thing. :) |
47 |
|
48 |
Rich |