On Saturday 16 May 2009 20:17:14 Nick Fortino wrote: > 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
And we could probably switch between types if forced to do so.
