| 1 |
Michael Haubenwallner <haubi@g.o> posted |
| 2 |
1243584886.27150.33.camel@×××××××××××××××.at, excerpted below, on Fri, 29 |
| 3 |
May 2009 10:14:46 +0200: |
| 4 |
|
| 5 |
> Ohw, the latter would be necessary here, or '4.ebuild' would not be |
| 6 |
> found. |
| 7 |
|
| 8 |
s/4.ebuild/4.eclass/ I assume. |
| 9 |
|
| 10 |
> Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 - |
| 11 |
> how become they masked _now_? What did I miss here? |
| 12 |
|
| 13 |
They used the old "wait an extended period (loosely speaking, a year) |
| 14 |
after initial stabilization of a new feature before use" method. EAPI |
| 15 |
was supposed to do away with that, since once EAPI aware PMs could be |
| 16 |
assumed (after the year or whatever waiting period), any EAPI a PM didn't |
| 17 |
understand was supposed to be rejected. |
| 18 |
|
| 19 |
Except... since an ebuild must presently be sourced to (properly) |
| 20 |
determine EAPI, it still doesn't work for changes that break sourcing or |
| 21 |
other pre-EAPI processing (like parsing PN and PVR out of the filename), |
| 22 |
so the changes allowed with a simple EAPI change are still rather limited. |
| 23 |
|
| 24 |
That's why the change to GLEP55 or alternative, whether in-filename or |
| 25 |
in-file-itself, will again require either an extended wait after |
| 26 |
introduction (the old way) or at minimum, a one-time change to extension |
| 27 |
such that old PM versions don't even see the currently EAPI incompatible |
| 28 |
changes. |
| 29 |
|
| 30 |
-- |
| 31 |
Duncan - List replies preferred. No HTML msgs. |
| 32 |
"Every nonfree program has a lord, a master -- |
| 33 |
and if you use the program, he is your master." Richard Stallman |
Archives