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 1M7K92-0005Yo-2y for garchives@archives.gentoo.org; Fri, 22 May 2009 02:06:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 70105E0241; Fri, 22 May 2009 02:05:57 +0000 (UTC) Received: from smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by pigeon.gentoo.org (Postfix) with ESMTP id 428BFE0241 for ; Fri, 22 May 2009 02:05:57 +0000 (UTC) Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id 125537023E for ; Fri, 22 May 2009 02:05:55 +0000 (UTC) Received: from smtp.hushmail.com (app1.hushmail.com [65.39.178.74]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Fri, 22 May 2009 02:05:55 +0000 (UTC) From: "Robert R. Russell" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The fallacies of GLEP55 Date: Thu, 21 May 2009 21:04:54 -0500 References: <20090514225337.34df7dac@snowcone> <20090517004842.61834397@snowmobile> <4A0F659A.4070803@gmail.com> In-Reply-To: <4A0F659A.4070803@gmail.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="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: X-Archives-Salt: 96386bce-e2cf-46c2-8073-b2f686054d71 X-Archives-Hash: 1f06105512c8d818f59e86d55e07fdbc On Saturday 16 May 2009 20:17:14 Nick Fortino wrote: > Ciaran McCreesh wrote: > > On Sat, 16 May 2009 16:39:40 -0700 > > > > Nick Fortino wrote: > >> Given the above, it should be clear that any argument which states > >> some future improvement to the ebuild format will be impossible based > >> upon making the wrong choice between proposal 1 and proposal 2 must be > >> invalid, as they have the same expressive power. Note that allowable > >> algorithms for which the proof works includes caching and version > >> ordering as well as the simple execution of the ebuild. > > > > Unfortunately, your argument is entirely wrong, as can be illustrated > > by a simple counter-example that you would already know about, had you > > read the GLEP or the thread. > > > > With EAPI in a fixed format, it is impossible to allow extensions to the > > version format in future EAPIs. Even given a fixed format and a constant > > extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding > > foo-1.23-rc1.ebuild-4 will not. > > > > This has already been covered at length, and is explained in the GLEP. > > Why did you disregard this when posting your 'proof'? > > I didn't intentionally disregard that case, but I see your point. I made > the assumption that package mangers wouldn't try to source ebuilds with > a sourcing EAPI they didn't understand. I concede this is a terrible > assumption, unless such a thing is specified in the PMS itself. It is > still fixed by a single extension change, as opposed to a whole set. > Once this is done, simply state that all package managers should ignore > EAPIs they don't understand (a requirement of GLEP-55 as well). > > Your point still does not dispute that specifying the EAPI within the > ebuild and outside the ebuild convey identical information (this is all > I was trying to prove in the first place). For the case you bring up: > If foo-1.23-rc1.ebuild is added, it must not be in any of the currently > existing EAPIs, for if it were, it would be illegal. Thus, a package > manager would open this file, get the sourcing EAPI in an EAPI > independent way, realize it doesn't understand, and abort the sourcing > of that ebuild. Changing the extension once insures current package > managers don't try to do things they aren't capable of (I apologize for > not putting this in my first mailing). Given this change, however, I > still assert the statement of the two schemes have identical expressive > power. > > For versioning, it has been pointed out (by you and others) that getting > the latest version would require, under any implementation, opening N > files in case 1, and reading N file names in case 2. I do not dispute > this in any way. Instead, I would like to point out that moving the > argument from features which are possible to support (which I still > contend are essentially identical), to efficiency vs. a perceived > prettiness would be significant progress. Indeed, at this point it would > be possible to make a decision based on reference implementations for > known common use cases, and an executive council decision about whether > timing or extension consistency is more important. If it turns out that > using a solution of type 1 takes minutes to resolve versions, than by > all means, GLEP-55 is by far the best proposed solution. If, instead, > the runtime difference in real use cases is negligible, then the pure > philosophical arguments for using a single extension holds true (in my > opinion). > > Nick Fortino And we could probably switch between types if forced to do so.