Re: [gentoo-dev] The fallacies of GLEP55

[George Prowse]

Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
> Patrick Lauer <patrick@g.o> wrote:
>> "You need to know the EAPI to parse the ebuild to find the EAPI"
>> Obviously that's not true, because somehow we manage at the moment.
>> And if one does a small restriction (which doesn't restrict current
>> behaviour because all in-tree ebuilds currently fit within this
>> limitation) it becomes trivial again:
>>
>> Let EAPI be defined as (the part behind the = of) the first line of
>> the ebuild starting with EAPI=
>
> Uh, so horribly utterly and obviously wrong.
>
>     inherit foo
>     EAPI=4
>
> where foo is both a global and a non-global eclass that sets metadata.
>
> If you're looking for a formally correct alternative that works in the
> way you suggest, I already provided one, and you already read about it
> -- and it still doesn't solve the problems that 55 does.
>
>> "It's slower!"
>> The theory here being that a stat() is needed if it is encoded in the
>> filename, but a stat() followed by an open() to parse it from the
>> file. Well then, just cache it! You can use the mtime to check the
>> cache validity (which means you do a stat() anyway, so with glep55
>> caching it is actually slower!), and then you have to parse the
>> ebuild anyway for the other metadata. So the "extra" cost of finding
>> the EAPI is ... what extra cost? The only case when it is actually
>> slower is when there is no cache because then you have to parse the
>> ebuild. But that "degenerate" case will only hit some overlay users
>> and people like developers that can wait .3 seconds longer. And ...
>> uhm ... to extract other metadata like DEPENDS you'll have to parse
>> it anyway.
>
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
>
>> "Having GLEP55 allows us to add GLEP54 without issues!"
>> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
>> add it to metadata, as we should for all metadata? Define a key, I
>> don't know ... LIVE ? LIVE="true". There. No need to fix the
>> filename. And now stop mixing up issues because it is highly
>> confusing!
>
> There is no existing version ordering solution that accurately
> represents upstream scm branches.
>
>> A few words in closing -
>>
>> We can encode all the relevant info in "the first line of the ebuild
>> starting with EAPI="
>
> No we can't. That's *obviously* completely wrong.
>
>> The overhead of parsing out this value for all ebuilds in the tree
>> has been timed at ~2 CPU-seconds by solar. It's negligible.
>
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
>
> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
>
Having countered those four points I guess you agree with the other five 
then. Over 50% success rate (by your definition) is hardly being 
ignorant or trolling