Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer <patrick@gentoo.org> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]