On 2008-07-20 17:38, Peter Volkov uttered these thoughts: > В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: > > Which part of the 'Problem' section in the GLEP didn't you understand? > > Do you seriously consider not being able to add or change global scope > > functions in future EAPIs to be a non-issue, or were you ignoring those > > two bullet points? > > I've read all previous discussions but still miss answer to the > question: Why is it impossible to state that .ebuild extension is for > bash based ebuild make package manager get and filter EAPIs based on > EAPI variable?
Because that would still not allow global scope changes, because in order to get to know which EAPI the ebuild is written in, you have to actually source the ebuild, and by then it's too late. Unless you introduce some inane requirement that the EAPI variable has to be the first thing stated in the ebuild and force the PMs to extract that value before actually starting to parse the ebuild. Now, if _that's_ not an ugly solution, i don't know what is... You have to know _how_ to interpret an ebuild _before_ you actually start doing it. > Note, I assume that we can do not backward-compatible changes in PM, we > just need to wait enough time to start using it. But taking into account > that the features that will make use of this GLEP55 are still not so > evident I don't see any problem to wait. In any case I'd like to > understand why should we start support this hell of extensions. Reasons for the change has been stated before, and the one i just explained is the main one so far as i know. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats.
pgpG4XHQmlNIp.pgp
Description: PGP signature
