Re: [gentoo-dev] The fallacies of GLEP55

[Nick Fortino <nfortino@gmail.com>]

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino <nfortino@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