On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote: > 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]
We agree on the latter adjective, if nothing else. > 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). I wonder where people get this strange delusion that only Windows uses file extensions for anything? > 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. Because we haven't yet introduced any changes that would break it. > 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, It's an arbitrary, magical restriction that doesn't follow from the general rules of the language that ebuilds are written in - you said it yourself, "shell-like". "printf -v EAPI 1" is perfectly valid shell (at least if we decide to allow bash 3.1 features), and has the same effect as "EAPI=1" under the rules of the shell, but it's not compatible with your new rule. > "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. With GLEP 55 it's naturally invalid, and can't possibly be assumed to be valid. If you keep the assignment-like syntax but disallow it in eclasses, it's an extra weird restriction. > "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. And people say Gentoo users are ricers... the whole speed argument is a strawman, relevant only to the extent that we don't want to make things noticeably slower than they are already. You claim that GLEP 55 does that, but this claim seems to be based on the assumption that without it there would be no need to parse the filename in any way, which clearly isn't true. > "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. The same thing happened when EAPI itself was introduced. EAPI support was committed to Portage in late September 2005, but the first new EAPI in mainstream Gentoo was introduced in early October 2007, just over two years later. That's clearly not an argument for rejecting a compatibility mechanism. It's also not necessary to start putting EAPI in the filename as soon as it's approved. The Council could easily state that "once we need to make a change that requires a stronger mechanism than EAPI is currently, we'll do it like this" - no need to reject it, or keep "maybe"ing it for eternity. Of course, there's at least one GLEP 55-scope change that people want already, to the extent that they're making up hacks to work around the lack of it, namely per-package eclasses. I would hope that everyone agrees that a package manager-supported mechanism would be far preferably (I know that vapier does). > "We want to change the versioning rules!" > Why do you want that, and what do we gain from it? Aside from -scm (below), there are various changes suggested at http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000400.html that would help match various upstream version formats more closely, and reduce the amount of versionator hacking. Even if you don't like any of those examples, the version format has changed in the past, and it would be quite foolish to design around the assumption that it will never happen again. > "Having GLEP55 allows us to add GLEP54 without issues!" > Yeah, uhm, the live-ness of an ebuild is an attribute. No more so than the "1.2ness". "This ebuild installs the latest sources from the repository" is the same class of information as "this ebuild installs version 1.2", and therefore belongs in the same place. > 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! That still doesn't solve the version ordering issues, as has already been said countless times. > "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. You'd think so, but it never seems to work out that way. > Maybe understanding the issue forces one to support the current > behaviour! Unlikely.
