| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 28/08/12 10:35 AM, Mike Gilbert wrote: |
| 5 |
> On Tue, Aug 28, 2012 at 4:06 AM, Michał Górny <mgorny@g.o> |
| 6 |
> wrote: |
| 7 |
>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar |
| 8 |
>> Arahesis <arfrever.fta@×××××.com> wrote: |
| 9 |
>> |
| 10 |
>>> 2012-08-28 00:19:28 Michał Górny napisał(a): |
| 11 |
>>>> +case ${EAPI:-0} in + 0|1|2|3|4) ;; + *) die |
| 12 |
>>>> "${ECLASS}.eclass API in EAPI ${EAPI} not yet established." |
| 13 |
>>>> +esac |
| 14 |
>>> |
| 15 |
>>> Please accept all EAPIs. |
| 16 |
>> |
| 17 |
>> These are EAPIs which are allowed throughout the tree, sorry. |
| 18 |
>> Feel free to ping Council about adding non-standard EAPIs to |
| 19 |
>> eclasses. |
| 20 |
>> |
| 21 |
> |
| 22 |
> Is the eclass likely to be incompatible with future EAPIs? If not, |
| 23 |
> I think it is reasonable to remove this check. |
| 24 |
> |
| 25 |
|
| 26 |
It's quite standard to have the above check in place; and since there |
| 27 |
is no guarantee that new EAPIs *won't* break something, I think it |
| 28 |
would be a good idea to leave this as-is. |
| 29 |
|
| 30 |
Yes this will add a touch more work when it comes to bumping eclasses |
| 31 |
to accept EAPI=5 or newer, but forcing a dev to check the eclass's |
| 32 |
compatibility when a new EAPI rolls out is a good thing imo. |
| 33 |
|
| 34 |
-----BEGIN PGP SIGNATURE----- |
| 35 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 36 |
|
| 37 |
iF4EAREIAAYFAlA82ToACgkQ2ugaI38ACPA4LQEAhoW6FtSwDqTdsV84XOjsibOp |
| 38 |
TdM1B3sE8Gpp8WnfFhgA/3MvQy9oq+y/0U1cqMByiSAH4wN/12f0yuvGiWYD5pXf |
| 39 |
=GQ4U |
| 40 |
-----END PGP SIGNATURE----- |
Archives