[gentoo-dev] The fallacies of GLEP55

[Patrick Lauer <patrick@gentoo.org>]

For quite some time (over a year, actually) we've been discussing the
mysterious and often misunderstood GLEP55. 
[http://www.gentoo.org/proj/en/glep/glep-0055.html]

The proposed solution to a problem that is never refined, in short, is to add
the EAPI into the ebuild filename "to make things easier". Which is a rather
unsubstantiated idea that doesn't really add up if you look at it ... and it 
adds some artifacts that we've been laughing about for a decade because 
microsoft did the exact same thing (binding the executable-ness of a file to 
the filename).

Here's just some of the theories in support of GLEP55 that have been thrown at
me, and a few words to show how they are not really issues:

"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=

As long as ebuilds remain shell-like this is not much of a restriction, and 
any format that diverges enough to make this inconvenient shouldn't be called 
an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial.

"You need to parse the ebuild and its eclasses to find the EAPI!"
See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
strange effects and is implicitly impossible with GLEP55 anyway, so it might 
be easier to just declare it invalid. 

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

"But we need to be able to change things in the future!"
Well then. Once we have identified such an issue we can do the changes. Until
then it's not even clear if there are such changes, so why should we break
current known and predictable behaviour to satisfy a need we don't even have?
Make a structured proposal defining a concrete problem in unambiguous terms,
list all the ways to solve this issue, including advantages and disadvantages,
and we can get it voted on and ratified within a month.

"We want to change the versioning rules!"
Why do you want that, and what do we gain from it? 

"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!

"Obviously you don't understand the issue, because if you did you'd support 
it!"
Uhm, obviously you have no idea what you are saying. But  just to play along
... if it were that obvious we wouldn't have had to discuss it for so long.
Maybe understanding the issue forces one to support the current behaviour!


A few words in closing - 

We can encode all the relevant info in "the first line of the ebuild starting
with EAPI="
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.
The changes are none at the moment, all that changes is the specification. And
if we ever have the need to change things around we can still look at the
expected costs and benefits and decide to implement something almost, but not
completely unlike GLEP55. And maybe we can now spend the same amount of
council-time (it has been eating time for over a year!) to get important 
things done ...

hth,

Patrick the bonsaikitten


P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg