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