1 |
Ciaran McCreesh wrote: |
2 |
> On Sat, 16 May 2009 16:39:40 -0700 |
3 |
> Nick Fortino <nfortino@×××××.com> wrote: |
4 |
> |
5 |
>> Given the above, it should be clear that any argument which states |
6 |
>> some future improvement to the ebuild format will be impossible based |
7 |
>> upon making the wrong choice between proposal 1 and proposal 2 must be |
8 |
>> invalid, as they have the same expressive power. Note that allowable |
9 |
>> algorithms for which the proof works includes caching and version |
10 |
>> ordering as well as the simple execution of the ebuild. |
11 |
>> |
12 |
> |
13 |
> Unfortunately, your argument is entirely wrong, as can be illustrated |
14 |
> by a simple counter-example that you would already know about, had you |
15 |
> read the GLEP or the thread. |
16 |
> |
17 |
> With EAPI in a fixed format, it is impossible to allow extensions to the |
18 |
> version format in future EAPIs. Even given a fixed format and a constant |
19 |
> extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding |
20 |
> foo-1.23-rc1.ebuild-4 will not. |
21 |
> |
22 |
> This has already been covered at length, and is explained in the GLEP. |
23 |
> Why did you disregard this when posting your 'proof'? |
24 |
> |
25 |
> |
26 |
I didn't intentionally disregard that case, but I see your point. I made |
27 |
the assumption that package mangers wouldn't try to source ebuilds with |
28 |
a sourcing EAPI they didn't understand. I concede this is a terrible |
29 |
assumption, unless such a thing is specified in the PMS itself. It is |
30 |
still fixed by a single extension change, as opposed to a whole set. |
31 |
Once this is done, simply state that all package managers should ignore |
32 |
EAPIs they don't understand (a requirement of GLEP-55 as well). |
33 |
|
34 |
Your point still does not dispute that specifying the EAPI within the |
35 |
ebuild and outside the ebuild convey identical information (this is all |
36 |
I was trying to prove in the first place). For the case you bring up: |
37 |
If foo-1.23-rc1.ebuild is added, it must not be in any of the currently |
38 |
existing EAPIs, for if it were, it would be illegal. Thus, a package |
39 |
manager would open this file, get the sourcing EAPI in an EAPI |
40 |
independent way, realize it doesn't understand, and abort the sourcing |
41 |
of that ebuild. Changing the extension once insures current package |
42 |
managers don't try to do things they aren't capable of (I apologize for |
43 |
not putting this in my first mailing). Given this change, however, I |
44 |
still assert the statement of the two schemes have identical expressive |
45 |
power. |
46 |
|
47 |
For versioning, it has been pointed out (by you and others) that getting |
48 |
the latest version would require, under any implementation, opening N |
49 |
files in case 1, and reading N file names in case 2. I do not dispute |
50 |
this in any way. Instead, I would like to point out that moving the |
51 |
argument from features which are possible to support (which I still |
52 |
contend are essentially identical), to efficiency vs. a perceived |
53 |
prettiness would be significant progress. Indeed, at this point it would |
54 |
be possible to make a decision based on reference implementations for |
55 |
known common use cases, and an executive council decision about whether |
56 |
timing or extension consistency is more important. If it turns out that |
57 |
using a solution of type 1 takes minutes to resolve versions, than by |
58 |
all means, GLEP-55 is by far the best proposed solution. If, instead, |
59 |
the runtime difference in real use cases is negligible, then the pure |
60 |
philosophical arguments for using a single extension holds true (in my |
61 |
opinion). |
62 |
|
63 |
Nick Fortino |