| 1 |
(trying to have people understand the idea, not to discuss in this |
| 2 |
thread) |
| 3 |
|
| 4 |
On Fri, 2009-03-13 at 06:18 +1300, Alistair Bush wrote: |
| 5 |
|
| 6 |
> > As long as we want/have to support PMs lacking EAPI detection in |
| 7 |
> > '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI |
| 8 |
> > to an '*.ebuild' must be hackish. So we can try to find the least ugly |
| 9 |
> > hack, or we need to change the extension. |
| 10 |
|
| 11 |
> > inherit eapi 4 |
| 12 |
> > |
| 13 |
> > Because non-compliant PM's already quit because of (missing or dying) |
| 14 |
> > eapi.eclass, there is no need to have a '4.eclass'. |
| 15 |
> |
| 16 |
> How would the 4.eclass determine whether the package manager actually |
| 17 |
> supports the eapi? |
| 18 |
> |
| 19 |
> inherit is a function remember so any "special" parsing will not change |
| 20 |
> the fact the the inherit function will be called. |
| 21 |
> Will then need to determine whether there is actually a PM that doesn't |
| 22 |
> support the eclasses EAPI and then die. |
| 23 |
|
| 24 |
The most important point here I thought everyone is aware of: |
| 25 |
inherit() is a function provided *by* PM - or am I wrong here? |
| 26 |
|
| 27 |
So it already *knows* to handle the 'eapi' argument as special when the |
| 28 |
PM is compliant, to not read *any* eclass for this one inherit-call when |
| 29 |
the ebuild gets sourced (assuming selected eapi specifies to |
| 30 |
shell-source the ebuild). |
| 31 |
And non-compliant PMs would mask the ebuild 'by corruption', because of |
| 32 |
either missing or globalscope-dying eapi.eclass, whatever can be made |
| 33 |
look more obvious to the user. |
| 34 |
|
| 35 |
> What are the implications of calling inherit multiple times within an |
| 36 |
> ebuild? |
| 37 |
|
| 38 |
A compliant PM does allow this if the selected eapi specifies to inherit |
| 39 |
eclasses, a non-compliant PM will not come to a subsequent inherit call |
| 40 |
after 'inherit eapi'. |
| 41 |
|
| 42 |
> Im sorry, but this just sounds like a HACK, and a hacky hack at that. |
| 43 |
|
| 44 |
Agreed (see above). |
| 45 |
Again - the only reason for this idea is to eventually allow for keeping |
| 46 |
the '.ebuild' extension, because EAPI 0 does not allow for specifying |
| 47 |
*any* eapi at all. It just forces PM to provide inherit() as the only |
| 48 |
PM-defined global-scope function. So whatever we try, specifying an eapi |
| 49 |
inside an .ebuild *without* changing the extension *will* be a hack, |
| 50 |
just more ore less ugly. |
| 51 |
|
| 52 |
/haubi/ |
| 53 |
-- |
| 54 |
Michael Haubenwallner |
| 55 |
Gentoo on a different level |
Archives