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