| 1 |
Michael Haubenwallner wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> Reminder (for myself): |
| 5 |
> As long as we want/have to support PMs lacking EAPI detection in |
| 6 |
> '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI |
| 7 |
> to an '*.ebuild' must be hackish. So we can try to find the least ugly |
| 8 |
> hack, or we need to change the extension. |
| 9 |
> |
| 10 |
> So just another idea, based on the "eapi() function" one: |
| 11 |
> As inherit() is the only(?) global function provided by old PMs, the |
| 12 |
> first non-commentary/non-blank line in '*.ebuild' could read: |
| 13 |
> |
| 14 |
> inherit eapi |
| 15 |
> |
| 16 |
> Compliant PMs identify 'eapi' as a special eclass name (with or without |
| 17 |
> sourcing the ebuild), to know that "this ebuild specifies an EAPI". |
| 18 |
> |
| 19 |
> For non-compliant PMs, we need to provide an 'eapi.eclass', which just |
| 20 |
> spits some 'your PM lacks EAPI support' message and causes the PM to |
| 21 |
> mask this ebuild 'by corruption' or the like. |
| 22 |
> |
| 23 |
> Or - what are old PM's messages when an eclass is missing? |
| 24 |
> |
| 25 |
> Eventually, this line also could finally specify the EAPI and read: |
| 26 |
> |
| 27 |
> inherit eapi 4 |
| 28 |
> |
| 29 |
> Because non-compliant PM's already quit because of (missing or dying) |
| 30 |
> eapi.eclass, there is no need to have a '4.eclass'. |
| 31 |
|
| 32 |
How would the 4.eclass determine whether the package manager actually |
| 33 |
supports the eapi? |
| 34 |
|
| 35 |
inherit is a function remember so any "special" parsing will not change |
| 36 |
the fact the the inherit function will be called. |
| 37 |
Will then need to determine whether there is actually a PM that doesn't |
| 38 |
support the eclasses EAPI and then die. |
| 39 |
What are the implications of calling inherit multiple times within an |
| 40 |
ebuild? |
| 41 |
|
| 42 |
Im sorry, but this just sounds like a HACK, and a hacky hack at that. |
| 43 |
|
| 44 |
> |
| 45 |
> /haubi/ |
Archives