| 1 |
David Leverton wrote: |
| 2 |
|
| 3 |
> 2009/5/17 Ben de Groot <yngwin@g.o>: |
| 4 |
>> I think the way eapi-2 was introduced into the tree wasn't particularly |
| 5 |
>> problematic. |
| 6 |
> |
| 7 |
> I think there might be a misunderstanding here. Ciaran means functions |
| 8 |
> provided by the package manager that ebuilds can call during metadata |
| 9 |
> generation, for example built-in versionator-like functionality, not |
| 10 |
> new phase functions like src_prepare and src_configure. |
| 11 |
|
| 12 |
Ugh. Firstly versionator is a piece of bloated crap that should have died a |
| 13 |
long time ago; all it does is stop Gentoo newbs learning the basics[1] of |
| 14 |
their implementation language, which leaves them open to nonsensical |
| 15 |
arguments about printf -v (glad you finally learnt that one, btw.) |
| 16 |
|
| 17 |
Secondly, please explain fully and clearly, but concisely, why we can't |
| 18 |
simply state that EAPI=NN allows the ebuild to use the EAPI functions in |
| 19 |
global scope. |
| 20 |
|
| 21 |
Bear in mind that you have to deal with the case of the mangler which can |
| 22 |
get EAPI from an ebuild without sourcing, as portage currently can, I |
| 23 |
believe. |
| 24 |
|
| 25 |
Relaxing that restriction strikes me as much saner than relaxing all the |
| 26 |
other restrictions which make interoperability easier. |
| 27 |
|
| 28 |
(Frankly, I'm amazed at having to state that to people trusted to write a |
| 29 |
specification. Follow up to -project on this point please, as it's about |
| 30 |
process, not technique.) |
| 31 |
|
| 32 |
[1] (watch wrap) |
| 33 |
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 |
| 34 |
http://wooledge.org/mywiki/BashFAQ/073 |
| 35 |
man bash /Parameter Expansion |
| 36 |
|
| 37 |
-- |
| 38 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |
Archives