1 |
On Fri, 20 Feb 2009 00:11:32 +0300 |
2 |
Peter Volkov <pva@g.o> wrote: |
3 |
|
4 |
> That said, technically there are other solutions for this problem, |
5 |
> e.g. 1) it is possible to read one line of defined format from any |
6 |
> file 2) it is possible to make eapi inside ebuild name |
7 |
> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even |
8 |
> breaking compatibility solution, we could already start using if we |
9 |
> had forgotten about GLEP 55 long time ago... |
10 |
|
11 |
I really don't understand why foo-0.1.eapi3.ebuild is considered an |
12 |
acceptable solution and foo-0.1.ebuild.eapi3 is not. |
13 |
|
14 |
They have the same advantages, arguments about aesthetics aside, and |
15 |
seem to be a much cleaner solution than any other that has been |
16 |
proposed. But the former has one distinct disadvantage that the latter |
17 |
does not: any currently released version of portage does not work |
18 |
correctly with ebuilds having version suffixes it does not recognize. |
19 |
For example, you cannot currently create a Manifest in a package |
20 |
directory containing a file named package-1.0.eapi3.ebuild. |
21 |
|
22 |
We can modify portage, of course, to recognize this suffix, and then |
23 |
wait long enough for that release to trickle down. But later, if we |
24 |
want to add another suffix, -scm perhaps, or something we |
25 |
haven't considered yet, we again have to go through the same process. I |
26 |
thought the reason we introduced EAPI was to free us from this. |
27 |
|
28 |
It may seem a minor gripe, but it doesn't take much imagination to come |
29 |
up with other scenarios where this could become a bigger problem. |
30 |
|
31 |
With a format such as .ebuild.eapiX we would avoid these issues. |
32 |
Portage (without any modifications) will not recognize these files as |
33 |
ebuilds (which is exactly the behaviour we want if it doesn't |
34 |
understand the EAPI), so the format of the version string is moot. We |
35 |
could introduce -scm (or whatever) in EAPI X, and be able to use it |
36 |
immediately. |
37 |
|
38 |
Your argument that the .ebuild file suffix is required by convention |
39 |
does not hold water. Ebuilds are not bash scripts. They are |
40 |
specialized scripts for package management that happen to be written |
41 |
in bash ;). You make the point yourself that if you wanted to implement |
42 |
a new ebuild format or change the language ebuilds are written in, you |
43 |
would change the extension to something else. I'd like to argue that |
44 |
we've already done so twice and I hear number 3 is coming real soon now. |
45 |
|
46 |
> Putting GLEP 55 infinite number of times on council agenda makes me |
47 |
> feel that this issue has something common with perpetuum mobile. At |
48 |
> least I'd like similar resolution from our council as the Royal |
49 |
> Academy of Sciences in Paris did in 1775. It's hard to tell anything |
50 |
> new about GLEP 55 but people still don't like it, so, council, |
51 |
> please, ban it forever and let something else arise. |
52 |
|
53 |
I'm sorry, but until you come up with a better reason than "it's |
54 |
tradition", I'm afraid this will continue to be submitted indefinitely. |
55 |
You will have to provide technical objections why this approach is |
56 |
unacceptable before anyone can come up with something that is. |
57 |
|
58 |
Here is an example, to get you started: |
59 |
If a Manifest is generated using a portage version that supports an |
60 |
EAPI and recognizes a package atom containing a version suffix that |
61 |
was added in that EAPI as an ebuild and thus categorizes it as EBUILD in |
62 |
the Manifest, do portage versions that do not support the EAPI have |
63 |
trouble when they see the entry marked EBUILD for a package atom they |
64 |
think is invalid? |
65 |
|
66 |
|
67 |
-- |
68 |
gcc-porting, by design, by neglect |
69 |
treecleaner, for a fact or just for effect |
70 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |