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 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.
