From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M4fKZ-0001vU-97 for garchives@archives.gentoo.org; Thu, 14 May 2009 18:06:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94699E051B; Thu, 14 May 2009 18:06:53 +0000 (UTC) Received: from dev.gentooexperimental.org (dev.gentooexperimental.org [81.93.240.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 4E132E051B for ; Thu, 14 May 2009 18:06:53 +0000 (UTC) Received: from lolcathost.localnet (xdsl-78-34-101-45.netcologne.de [78.34.101.45]) by dev.gentooexperimental.org (Postfix) with ESMTP id BA80B626B25 for ; Thu, 14 May 2009 20:06:52 +0200 (CEST) From: Patrick Lauer To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] The fallacies of GLEP55 Date: Thu, 14 May 2009 20:06:51 +0200 User-Agent: KMail/1.11.90 (Linux/2.6.28; KDE/4.2.85; x86_64; ; ) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200905142006.51998.patrick@gentoo.org> X-Archives-Salt: 04481040-5553-4eec-a273-a66b9e9067f3 X-Archives-Hash: d7a59d4d2634b5f5b6cd650884de608c 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