| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 30/08/12 09:14 AM, Rich Freeman wrote: |
| 5 |
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@g.o> |
| 6 |
> wrote: |
| 7 |
>> |
| 8 |
>> The primary benefit to the policy that dev's should bump EAPI |
| 9 |
>> when bumping ebuilds is so that older inferior EAPIs can be |
| 10 |
>> deprecated and eventually removed from the tree. |
| 11 |
> |
| 12 |
> What is the benefit from removing the old EAPIs? |
| 13 |
|
| 14 |
Simpler eclasses is the first thing that comes to mind. Consistency |
| 15 |
in the way the dependency tree is built would be another (when newer |
| 16 |
EAPIs address such things, that is) |
| 17 |
|
| 18 |
> |
| 19 |
> Simply bumping an ebuild to EAPI=5 doesn't even guarantee that |
| 20 |
> either of those features would be used anyway. |
| 21 |
|
| 22 |
..although this could technicaly be true, I think most developers |
| 23 |
would assume that bumping EAPI doesn't mean changing the EAPI variable |
| 24 |
from whatever to 5 and that's it; the "bump" should involve |
| 25 |
integrating any applicable features that the new EAPI offers. |
| 26 |
|
| 27 |
> |
| 28 |
> If there is a benefit from some specific practice, then let's |
| 29 |
> adopt it. However, I don't think that is the same as just bumping |
| 30 |
> EAPIs for their own sake. |
| 31 |
> |
| 32 |
> When there is a benefit to adopting a new EAPI of course |
| 33 |
> maintainers should try to take advantage of it. If there are |
| 34 |
> specific changes we want to try to make tree-wide let's try to do |
| 35 |
> that too. But, why bump ebuilds from 0 to 1 to 2 to 3 to 4 to 5 |
| 36 |
> when your only example of an end-user benefit would have been |
| 37 |
> achieved if we just bumped from 0 to 5 in one step? |
| 38 |
|
| 39 |
|
| 40 |
We used to have a policy that the oldest EAPI that implements all |
| 41 |
features needed for an ebuild is the one that should be used. Now (as |
| 42 |
of when EAPI=4 was made official i think?) it's the reverse -- the |
| 43 |
newest (official) EAPI is the one that should be used. All this |
| 44 |
policy change suggestion scarabeus provided is doing, is recommending |
| 45 |
that developers bump EAPI when they bump their ebuilds, as compared to |
| 46 |
only when writing new ones (which is all the current policy would |
| 47 |
require us to do). |
| 48 |
|
| 49 |
if you want another example, i'm sure end-user benefits would have |
| 50 |
ensued if many existing packages that die in pkg_setup were bumped to |
| 51 |
EAPI=4 right away and their checks moved to pkg_pretend. Examples |
| 52 |
prior to EAPI=4 are irrelevent as the policy was different then. |
| 53 |
|
| 54 |
-----BEGIN PGP SIGNATURE----- |
| 55 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 56 |
|
| 57 |
iF4EAREIAAYFAlA/a6sACgkQ2ugaI38ACPBO5wD+JSBmTT3j0MFc1GMjIDatRLnV |
| 58 |
J7Oj3rQWjS3GKpU8pQgBALsVg7R1QGGjETv0KS3j9yxBlflr4PlKECboVXqoRupL |
| 59 |
=+zxo |
| 60 |
-----END PGP SIGNATURE----- |
Archives