2009/5/18 Steven J Long <sl...@rathaus.eclipse.co.uk>: > David Leverton wrote: > >> 2009/5/17 Ben de Groot <yng...@gentoo.org>: >>> I think the way eapi-2 was introduced into the tree wasn't particularly >>> problematic. >> >> I think there might be a misunderstanding here. Ciaran means functions >> provided by the package manager that ebuilds can call during metadata >> generation, for example built-in versionator-like functionality, not >> new phase functions like src_prepare and src_configure. > > Ugh. Firstly versionator is a piece of bloated crap that should have died a > long time ago; all it does is stop Gentoo newbs learning the basics[1] of > their implementation language, which leaves them open to nonsensical > arguments about printf -v (glad you finally learnt that one, btw.)
Yes, it should have died a long time ago, that's why we're talking about adding equivalent built-in functionality. Please try to keep up. (And it's always amusing to see your bizarre delusions about what I do and don't know.) > Secondly, please explain fully and clearly, but concisely, why we can't > simply state that EAPI=NN allows the ebuild to use the EAPI functions in > global scope. Because by the time the package manager knows the EAPI and is in a position to provide the appropriate functions, the ebuild will have already tried to use them. > Bear in mind that you have to deal with the case of the mangler which can > get EAPI from an ebuild without sourcing, as portage currently can, I > believe. Interesting.... > Relaxing that restriction strikes me as much saner than relaxing all the > other restrictions which make interoperability easier. > > (Frankly, I'm amazed at having to state that to people trusted to write a > specification. Follow up to -project on this point please, as it's about > process, not technique.) You're amazed that people trusted to write a specification don't already know what "strikes you as much saner"? Believe it or not, the world does not revolve around you and your opinions.
