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 1M5InA-0002Sh-UW for garchives@archives.gentoo.org; Sat, 16 May 2009 12:15:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A0770E0433; Sat, 16 May 2009 12:15:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 63084E0433 for ; Sat, 16 May 2009 12:15:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id F156E65349 for ; Sat, 16 May 2009 12:15:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 required=5.5 tests=[AWL=0.696, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17oLWI9wiDeD for ; Sat, 16 May 2009 12:14:55 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id ACFFA64E9F for ; Sat, 16 May 2009 12:14:48 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M5Imj-00032K-E6 for gentoo-dev@gentoo.org; Sat, 16 May 2009 12:14:37 +0000 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2009 12:14:37 +0000 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2009 12:14:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: The fallacies of GLEP55 Date: Sat, 16 May 2009 12:14:23 +0000 (UTC) Message-ID: References: <200905142006.51998.patrick@gentoo.org> <20090515204905.54aa6a5c@snowmobile> <4A0E8717.5070600@gentoo.org> <200905161059.53706.levertond@googlemail.com> 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=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0750e064-5c3b-4530-80c1-34caa738f43d X-Archives-Hash: e88d961ede0733e356d88f7330a7754f David Leverton posted 200905161059.53706.levertond@googlemail.com, excerpted below, on Sat, 16 May 2009 10:59:53 +0100: > But the point isn't that we want to be able to do those things. The > point is that if the EAPI is in the filename, it's blatantly obvious > that it has to be static, but adding strange and unintuitive > restrictions on which shell constructs can be used is, well, strange an= d > unintuitive. Has it really come down to this? I mean, for the longest time, the main (among many) boosting claim seemed= =20 to be that the speed difference between in-file and in-filename made the=20 former prohibitive in practice. Perhaps the benchmarks the council asked= =20 for are disproving this. I don't know but I know I sure see a lot less=20 of that claim, call it a deemphasis if you will, now, only that the=20 filename method (i.e. glep55) isn't slower. Now, the main argument seems to be that glep55 filename based eapis are=20 "more intuitive". =20 The argument was originally made that a simple highly specified EAPI=3D=20 declaration in the file itself was too restrictive of all the ways it=20 could be specified now -- until it began to be pointed out every time the= =20 argument was made that the filename method was very similarly=20 restricted. =20 Now that argument has been debunked and no longer works as it did, so it=20 seems the reasons now being presented are what they have left, that the=20 filename restriction is "blatantly obvious", while the in-file EAPI=3D=20 restrictions are "unintuitive". I'd argue no, it's no more unintuitive than any other format definition=20 choice. It's the basic format definition, using the long accepted method= =20 of "magic values" at a "magic location" to define the format version. =20 That's very basic definitional, restricted only to the degree necessary=20 for practical application of the definition. Therefore, it's not=20 unintuitive, or at least, certainly no more so than arbitrarily defining=20 it to be in the filename instead, because "intuitive" now gets defined by= =20 the format definition at an extremely basic level, well below the level=20 at which all the "intuitive or not" fancy stuff gets addressed. Regardless, the practical effect is the same, (relatively) severe=20 restrictions from the extremely loose definition we have now. The=20 restrictions are even similar. Thus, it's only an argument over how=20 "intuitive" it is, and, well, a stable "base" definition that's=20 unchanging is certainly going to look more "intuitive" than say, what=20 features are in each EAPI, the much more difficult and "unintuitive"=20 thing devs are already trying to track. Anyway, if it has come down to arguing how intuitive the two opposing=20 options may be, that's GOOD news indeed! It means the important=20 questions are, one way or another, getting resolved. After that,=20 ultimately, it's a council judgment call, and we're actually getting=20 close! Unfortunately, "close" is a relative term. =3D:^( Realistically? I'm not sure it's going to resolve by the end of this council's term, but= =20 provided the elections don't shake things up too badly, it actually looks= =20 possible to do so reasonably within the /next/ council's term. We've=20 never actually had it (realistically) that close before! --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman