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 1M4mRM-0001bc-Jy for garchives@archives.gentoo.org; Fri, 15 May 2009 01:42:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2CAE2E032F; Fri, 15 May 2009 01:42:23 +0000 (UTC) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by pigeon.gentoo.org (Postfix) with ESMTP id C3DCFE032F for ; Fri, 15 May 2009 01:42:22 +0000 (UTC) Received: by ewy9 with SMTP id 9so2168875ewy.34 for ; Thu, 14 May 2009 18:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eafoN80Sr/BfG0gE2C1v01cHFiJR5ofbqt0E3X9EWoI=; b=f+osLdCwV1jgPOsIgNgb8/LafrnIX/fU2gl5+9hxGWDiE58L7kPJ5DjLVA9r9HlAjS oe9p6mYEffkuMeOSh7a/4cjEiq7suw8rYrWrXHp/bWE+rp/XXUYxxl9vuBRUMFm8mWtz vZkQEQsE2Un9OCnSGrri0GB47Hq4ODnvcLz+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ojn6EJAKDb/gsAH9/8ktCztb0/ZcsLue/ESt6qQogG2MewP8ASic/2/XD1VHi+cvi9 UrxtAOdsl48oTN+IA4jb232zbr23f6s76FwOsCPBAI6EEostuZYVLqby2PtGkLgT7PfB UJBwI3vqTPYqvVvYjf9WBpbRilWU95LlWWlEM= Received: by 10.210.37.16 with SMTP id k16mr287635ebk.22.1242351742208; Thu, 14 May 2009 18:42:22 -0700 (PDT) Received: from ?192.168.1.65? (user-514f9e9a.l1.c4.dsl.pol.co.uk [81.79.158.154]) by mx.google.com with ESMTPS id 5sm937736eyh.50.2009.05.14.18.42.21 (version=SSLv3 cipher=RC4-MD5); Thu, 14 May 2009 18:42:21 -0700 (PDT) Message-ID: <4A0CC889.2070704@gmail.com> Date: Fri, 15 May 2009 02:42:33 +0100 From: George Prowse User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The fallacies of GLEP55 References: <200905142006.51998.patrick@gentoo.org> <20090514193907.56754ae6@snowcone> In-Reply-To: <20090514193907.56754ae6@snowcone> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: fe02f583-80d6-41b9-9d27-6568ce052dc3 X-Archives-Hash: 4f3799c3ebb61518ebdcb6813973e851 Ciaran McCreesh wrote: > On Thu, 14 May 2009 20:06:51 +0200 > Patrick Lauer 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