1 |
On Fri, 20 Feb 2009 00:11:32 +0300 |
2 |
Peter Volkov <pva@g.o> wrote: |
3 |
> Filename extension is a "suffix to the name of a computer file, |
4 |
> designed to show its format" (-- wikipedia). General format of |
5 |
> ebuilds is bash. Putting version of bash scripts inside filename |
6 |
> extension just breaks common convention people got accustomed to. |
7 |
|
8 |
Ebuilds are written in a domain specific language that's built on top of |
9 |
bash. Hence why we use .ebuild, not .bash... An EAPI can be thought of |
10 |
as a version of that DSL, so it's just like .mp3. |
11 |
|
12 |
> You don't need to parse full bash script. You just need to get |
13 |
> |
14 |
> EAPI="something" |
15 |
> |
16 |
> string from there. If you wish to implement new ebuild format, e.g. |
17 |
> ebuilds in xml, in such a case you'll change extension on .xebuild or |
18 |
> whatever suits better. |
19 |
|
20 |
Except with current rules, the only way you can get that EAPI=something |
21 |
string is to evaluate the entire ebuild inside a special environment |
22 |
that already knows the EAPI up-front. |
23 |
|
24 |
> > Another cache won't solve anything since there's no way to generate |
25 |
> > that cache to begin with -- and a second level of cache would slow |
26 |
> > things down, not speed them up. |
27 |
> |
28 |
> I told about caching just to avoid "it's slow to get EAPI from ebuild" |
29 |
> argument. |
30 |
|
31 |
Uh. So you don't understand the metadata generation process at all then? |
32 |
|
33 |
> That said, technically there are other solutions for this problem, |
34 |
> e.g. 1) it is possible to read one line of defined format from any |
35 |
> file |
36 |
|
37 |
No it isn't. The only way to get the EAPI from an ebuild is to evaluate |
38 |
it in an environment where EAPI is already known. |
39 |
|
40 |
> 2) it is possible to make eapi inside ebuild name |
41 |
> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even |
42 |
> breaking compatibility solution, we could already start using if we |
43 |
> had forgotten about GLEP 55 long time ago... |
44 |
|
45 |
This is just the same as GLEP 55, except that it breaks current package |
46 |
managers and is more typing. In other words, it's a bad solution. |
47 |
|
48 |
> Putting GLEP 55 infinite number of times on council agenda makes me |
49 |
> feel that this issue has something common with perpetuum mobile. At |
50 |
> least I'd like similar resolution from our council as the Royal |
51 |
> Academy of Sciences in Paris did in 1775. It's hard to tell anything |
52 |
> new about GLEP 55 but people still don't like it, so, council, |
53 |
> please, ban it forever and let something else arise. |
54 |
|
55 |
GLEP 55 is necessary, and there *still* haven't been any legitimate |
56 |
technical objections to it, nor have there been any viable alternatives |
57 |
proposed. |
58 |
|
59 |
-- |
60 |
Ciaran McCreesh |