1 |
On Thu, 19 Feb 2009 13:06:01 +0300 |
2 |
Peter Volkov <pva@g.o> wrote: |
3 |
> В Чтв, 12/02/2009 в 18:03 +0000, Ciaran McCreesh пишет: |
4 |
> > GLEP 55 *is* the good, workable solution. There still haven't been |
5 |
> > legitimate any technical objections to it. |
6 |
> |
7 |
> This issue was discussed already... [1] |
8 |
|
9 |
...and there weren't any legitimate technical objections. |
10 |
|
11 |
> If you and think that EAPI is meta-information then it should not be |
12 |
> inside file name and then it's possible to parse ebuild and get EAPI |
13 |
> from some defined-format line. Performance penalties can be mitigated |
14 |
> by some new caching (you know better than me that it's good idea to |
15 |
> re-implement caching in any case). |
16 |
|
17 |
The only thing that can parse ebuilds is bash, and it can only do that |
18 |
once it already knows the EAPI. Another cache won't solve anything |
19 |
since there's no way to generate that cache to begin with -- and a |
20 |
second level of cache would slow things down, not speed them up. |
21 |
|
22 |
> We are already discussing this feature more than year. Many people |
23 |
> voiced concerns about .eapi extension so why don't you try fix same |
24 |
> issue differently? Yes it's harder and probably longer but I don't |
25 |
> believe it's impossible. |
26 |
|
27 |
Because all the alternatives are worse, and none of the objections to |
28 |
the extension have been technical in nature. They've all been "we don't |
29 |
want you to apply anti-mould paint to the rotting bikeshed because it's |
30 |
only available in brown". |
31 |
|
32 |
-- |
33 |
Ciaran McCreesh |