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 1M5TVR-0007rB-1Y for garchives@archives.gentoo.org; Sat, 16 May 2009 23:41:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F338BE05AD; Sat, 16 May 2009 23:41:27 +0000 (UTC) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by pigeon.gentoo.org (Postfix) with ESMTP id AFDD8E05AD for ; Sat, 16 May 2009 23:41:27 +0000 (UTC) Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) by fire-doxen-postvirus (Postfix) with ESMTP id 283A13280D3 for ; Sat, 16 May 2009 16:41:27 -0700 (PDT) X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new Received: from [131.215.168.112] (DHCP-168-112.caltech.edu [131.215.168.112]) (Authenticated sender: nfortino) by fire-doxen-ssl (Postfix) with ESMTP id E3401328071 for ; Sat, 16 May 2009 16:41:25 -0700 (PDT) Message-ID: <4A0F4EBC.5020706@gmail.com> Date: Sat, 16 May 2009 16:39:40 -0700 From: Nick Fortino User-Agent: Thunderbird 2.0.0.21 (X11/20090429) 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: <20090514225337.34df7dac@snowcone> <20090515194329.GA16382@linux1> <20090515204905.54aa6a5c@snowmobile> <20090516092710.GA3221@eric.schwarzvogel.de> <20090516151216.15efc792@snowmobile> <20090516153224.GA4964@eric.schwarzvogel.de> <20090516163421.32935cbc@snowmobile> <20090516154332.GA6646@eric.schwarzvogel.de> <20090516164903.261df865@snowmobile> <1242491708.7309.3.camel@peripatetic.hades> <20090516163908.GB11144@dodo.hsd1.nj.comcast.net> <1242492270.7309.6.camel@peripatetic.hades> <20090516174730.1d7dd5b7@snowmobile> <1242492844.7309.9.camel@peripatetic.hades> <20090516175931.7756060d@snowmobile> <1242493786.7309.17.camel@peripatetic.hades> <20090516185508.0fd02f0e@snowmobile> In-Reply-To: <20090516185508.0fd02f0e@snowmobile> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: fc17716a-99f4-4d20-85fa-c9583cd81a57 X-Archives-Hash: 8aa23efc5ba527681fb7c164f0c2c41b -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sat, 16 May 2009 22:39:46 +0530 > Arun Raghavan wrote: > >> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote: >> >>>> Don't care. Let's fix the problems we have *now* using solutions >>>> that we can agree upon, rather than try to foist solutions that a >>>> reasonably large population of developers *don't* like (even after >>>> extended debate) to solve problems that don't exist yet. >>>> >>> No, let's fix it so we don't have to do the whole thing again in >>> another year or two. >>> >> I see nothing about the current problem that merits the fooling around >> with the ebuild extension. I've listened to and considered all the >> arguments that have been made, and I still stand by my opinion that it >> an unclean solution (meaning, we don't need to rehash those arguments >> again here). >> > > You have yet to provide an alternative for fixing the arbitrary and > pointless version format restrictions that are currently in place. > > > It seems to me that putting the EAPI in a fixed place in the file has nearly identical freedom as specifying the EAPI in the file name, and therefore the argument is more philosophical than based upon features. To be concrete, consider two proposals, 1. For an ebuild wishing to be sourced with EAPI != 0, line 4 shall be blank and line 5 shall contain the string EAPI="arg", where arg is the desired EAPI. 2. An ebuild wishing to be sourced with EAPI != 0 shall have the extension .ebuild-EAPIarg, where arg is the desired EAPI. Throughout, these shall be referred to as ebuilds of type 1 and 2 respectively. I claim for any format where the concept of line 4 and line 5 are well defined and identical across EAPIs, and the EAPI string embeddable in the file name, these two proposals allow identical expressive power.[1][2] "Proof": Given a set of ebuilds of type 1 transform to ebuilds of type 2 as follows: for every ebuild ${A}.ebuild, look for a blank line 4 and line 5 with EAPI="arg". If found, move the ebuild to ${A}.ebuild-EAPIarg, and remove lines 4 and 5. Otherwise, move the file to ${A}.ebuild-EAPI0. Given a set of ebuilds of type 2 transform to ebuilds of type 1 as follows: for every ebuild ${A}.ebuild-EAPIarg, insert a blank line 4 and put the string EAPI="arg" on line 5. move the ebuild to ${A}.ebuild. For every ebuild ${A}.ebuild, insert a blank line 4, and EAPI="0" on line 5. Such a transformation is possible, given the restrictions on arg, as well as ebuild format. Given the further restriction that any algorithm using ebuilds must behave identically with ebuilds of unspecified EAPI as with ebuilds with specified EAPI="0" [3], it can easily be seen that the two transformations are inverses of each other, and that every ebuild of either type can be transformed. Thus, the above must be a one-to-one and onto mapping between the two formats. The conclusion is any algorithm which can be run on a set of ebuilds type 1 has a set of ebuilds with type 2 and an appropriate algorithm for which identical results will be produced, and vice versa [4]. 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. Nick Fortino [1] I further state, philosophically, any formats which have differing (including non-existent) concepts of line 4 and line 5 should have different extensions. Proposal 2 takes care of this automatically. For any format, the desired EAPI should be specifiable within the file in a manner uniquely determined by the extension of the file, so proposal 1 is also capable of achieving this freedom. [2] The astute reader may notice that the concept of a blank line is also needed, and that line 5 must be capable of encoding the desired data in a way specified by only the extension. To avoid clutter, these details are located here, but are in fact restrictions made on the ebuild format. [3] There are no algorithms I know of which violate this for EAPI="0", and I would hope that there are no EAPI="0" ebuilds which are broken by putting this specification explicitly in the file. Similarly, I would hope that anything in proposal 2 with EAPI="0" which works with the .ebuild extension works with the .ebuild-EAPI0 extension. Note that one could dream up algorithms violating this (take the MD5 hash, do something based on this which affects the outcome). Doing such a thing where the difference would be visible to the user would be silly. It is mostly irrelevant for this argument anyway, as it only affects EAPI="0", which nobody will debate both schemes can handle. [4] If this is unclear, consider the following (inefficient) construction of a set of ebuilds of type 2 and a corresponding algorithm, given a set of type 1: Take the set of ebuilds, transform to type 2; let this be the new set of ebuilds. Take the given type 1 algorithm, and produce the modified algorithm as follows: Given the type 1 algorithm, take the set of ebuilds of type 2, transform to type 1, and run the algorithm on the properly formatted ebuilds. Our mapping is 1-1 and onto. We are comparing the result of running the type 1 algorithm directly, and running the type 1 algorithm on the ebuild having the mapping and it's inverse applied. The result must be the same for any algorithm satisfying our restrictions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoPTrwACgkQRQqsawN7JJSefwCaAunc1F/iGV0FITN9W8EwUZkZ vHQAoIbcbl4cIwjWjeILSfpSFj5yG17Z =DVZJ -----END PGP SIGNATURE-----