| 1 |
On Sonntag, 11. November 2007, Ciaran McCreesh wrote: |
| 2 |
> I suspect that for existing eclasses, the safest way to proceed is to |
| 3 |
> make a new eclass and move common code into a third eclass. So you'd |
| 4 |
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common, |
| 5 |
> and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting |
| 6 |
> foo-common. |
| 7 |
|
| 8 |
And this is where it gets ugly - maybe finally a good reason for versioned |
| 9 |
eclasses (though I fear the misuse). |
| 10 |
|
| 11 |
That it is not possible today to let an ebuild die in global scope is not a |
| 12 |
big issue, as you can in pkg_setup(), just as with missing use dependencies, |
| 13 |
just that the developer in question /should/ stumble about it, so in the best |
| 14 |
of all worlds the user base wouldn't ever notice. The only problem is the |
| 15 |
weakest link: One of us missing to care to invoke <eclass>_pkg_setup(), when |
| 16 |
necessary. |
| 17 |
|
| 18 |
Maybe it would in general not be bad to require eclass phase functions to be |
| 19 |
called, when the inheriting ebuild/eclass writes a custom phase function and |
| 20 |
having Portage to complain about it, unless some override_<eclass-phase> |
| 21 |
variable is set. |
| 22 |
|
| 23 |
|
| 24 |
Carsten |
Archives