| 1 |
On Wed, 12 Dec 2007 15:08:36 +0100 |
| 2 |
"Santiago M. Mola" <coldwind@g.o> wrote: |
| 3 |
> Would it be possible to have eclass/eapiBLAH/foo.eclass? |
| 4 |
|
| 5 |
No. Not even with an EAPI change. This is one of the deficiencies in |
| 6 |
the way EAPI was designed -- an EAPI cannot change the behaviour of |
| 7 |
inherit, nor can it introduce new global-scope functions. |
| 8 |
|
| 9 |
The .ebuild-eapi proposal didn't have this problem, but unfortunately it |
| 10 |
was rejected for political reasons... |
| 11 |
|
| 12 |
> > * Eclasses cannot be made not to work with any given EAPI. If such |
| 13 |
> > functionality is desirable, someone needs to file an EAPI request |
| 14 |
> > for permitting an alternative to 'die' that is legal in global |
| 15 |
> > scope. |
| 16 |
> |
| 17 |
> So is it desirable? |
| 18 |
> |
| 19 |
> If portage masks ebuilds with an unsupported EAPI, what's the point? |
| 20 |
> It'd be enough to be able to check EAPI compatibility in eclasses |
| 21 |
> quickly so repoman and others can print a nice error. |
| 22 |
|
| 23 |
The problem is that people change eclasses and don't check every single |
| 24 |
package that uses them. Find a solution for that problem and then |
| 25 |
eclasses supporting only a subset of EAPIs becomes feasible. |
| 26 |
|
| 27 |
-- |
| 28 |
Ciaran McCreesh |
Archives