| 1 |
On Sun, 5 Oct 2008 17:07:40 +0200 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
> Maybe eclasses should die on unknown eapi; the fact is I really hate |
| 4 |
> the current way it's done when switching an ebuild to EAPI-2 which |
| 5 |
> uses an eclass that exports src_compile; most eclasses don't special |
| 6 |
> case eapi-2 yet and we end up running econf twice at best. I fear |
| 7 |
> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll |
| 8 |
> support src_configure too) |
| 9 |
|
| 10 |
There's currently no mechanism for an ebuild or eclass to 'die' in |
| 11 |
global scope. |
| 12 |
|
| 13 |
It's something that could be available for future EAPIs without too |
| 14 |
much difficulty, though... We discussed this for Exherbo, and decided |
| 15 |
upon something like this: |
| 16 |
|
| 17 |
* Add a new metadata key called BROKENNESS. |
| 18 |
|
| 19 |
* Any ID with non-empty BROKENNESS is treated as being hard masked and |
| 20 |
not unmaskable by the user, in the same way than an unknown EAPI is. |
| 21 |
|
| 22 |
* Add a function which can only be called in global scope that adds an |
| 23 |
item to BROKENNESS. This does *not* prevent further sourcing. |
| 24 |
|
| 25 |
This one hopefully shouldn't be too hard to implement (Zac?). If people |
| 26 |
are running into excessive difficulties with eclasses, it might be |
| 27 |
worth doing an EAPI 3 quickly with just this addition... |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives