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