From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lbb8E-0006x4-HO for garchives@archives.gentoo.org; Mon, 23 Feb 2009 13:46:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A98B9E0406; Mon, 23 Feb 2009 13:45:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 69D0CE0406 for ; Mon, 23 Feb 2009 13:45:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E77E0B6D28 for ; Mon, 23 Feb 2009 13:45:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 required=5.5 tests=[AWL=0.629, 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 6E6uszhwCCN5 for ; Mon, 23 Feb 2009 13:45:52 +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 00372B597F for ; Mon, 23 Feb 2009 13:45:50 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lbb7y-0004hw-5d for gentoo-dev@gentoo.org; Mon, 23 Feb 2009 13:45:46 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 13:45:46 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 13:45:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Date: Mon, 23 Feb 2009 13:45:39 +0000 (UTC) Message-ID: References: <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <20090223085232.GA6492@hrair> 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-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c76b06f4-3942-4b3b-8529-65e2e647a182 X-Archives-Hash: e9a009ef4120995a3d687eac3d71472c Brian Harring posted 20090223085232.GA6492@hrair, excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800: > On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: >> [quoting...] >>> What is proposed in glep-55 seems to aim to solve both issues at the >>> same time (it isn't stated) by switching file extension every time >>> the eapi is changed. This is slightly against the principle of the >>> least surprise and apparently is disliked by enough people[...] >>=20 >> Instead of switching file extension every time the eapi is changed you >> could also increment it only when a new EAPI breaks sourcing the ebuil= d >> compared to the requirements of the prior EAPI. (This way you'd in fac= t >> split EAPI into a major- and a minor-version.) >=20 > Complicates the implementation (annoying), but more importantly negates > one of the features of g55- being able to tell via the extension if the > manager supports that EAPI. That makes sense, but from my observation, the biggest resistance is=20 coming from potentially unlimited changes to the extension. That rubs=20 some people strongly enough the wrong way to have folks threatening to=20 leave over it, etc. If it must be, it must be, but obviously, if there's= =20 a /reasonable/ way to avoid it, we should. Way back when this first came up, I asked a simple question and IIRC=20 wasn't satisfied with the answer. Since the elements of it have been=20 proposed separately, perhaps it's time to ask about the combination once=20 again, as it seems to me to solve both the technical and aesthetic=20 issues, tho admittedly it does have a bit of the "complicates the=20 implementation" problem. As I understand it, the nastiest technical problem is currently the=20 chicken/egg issue of needing the EAPI to source the ebuild... to /get/=20 the EAPI. Above, we have what amounts to a major/minor EAPI proposal,=20 stick the major in the extension (or as a variant, the pre-extension=20 filename), with it bumped only when the format changes enough to require=20 pre-source knowledge of the change. Elsewhere, someone proposed strenthening the format rules by hard- specifying a location and format for the EAPI line, say line two of the=20 ebuild and in a format specific enough to be parsed /without/ sourcing=20 the ebuild, thus providing a pre-source method for grabbing the EAPI. =20 The shoot-down when originally suggested was that this isn't flexible=20 enough. It's also arguably less efficient since one has to access the=20 file twice, first to get the EAPI, then to actually source the file. =20 Unfortunately the below suggestion doesn't avoid that. Combining the two ideas, we get: Why not put the "EAPI-major" aka "pre-parse-EAPI" in that hard-specified=20 in-file location, thus giving the package manager a method to grab it pre= - source, then allow more flexibility on the "EAPI-minor" aka "post-parse-EAPI"? FWIW, all EAPIs to date have been EAPI-minor/post-parse, precisely=20 /because/ of the need-the-EAPI-to-source-to-get-the-EAPI issue. This=20 would eliminate that issue, providing both the necessary pre-source=20 (major) EAPI solution and flexibility on the post-source (minor) EAPI. =20 It would also avoid the so controversial aesthetic issue, maintaining the= =20 traditional .ebuild extension. The negative, however, as mentioned, is that of efficiency. It'd be=20 necessary to access the file twice, pre-source to get the EAPI-major,=20 then the source to fill in all the details. Putting just the EAPI-major=20 in the filename/extension would avoid the first access (a dir listing=20 would suffice) and using the filename for the EAPI entirely would in some= =20 cases possibly avoid accessing the file itself entirely -- at the expense= =20 of EAPI flexibility and aesthetics. Meanwhile, a status/process observation, if I may. Given the efficiency=20 negative of putting the EAPI anywhere /but/ the filename and the way the=20 debate has gone, GLEP-55 or something close to it (using the filename for= =20 EAPI) would appear headed toward ultimate approval, however slow it seems= =20 to be getting there. The major blocker would appear to be that the GLEP as-is simply doesn't=20 sufficiently address everything that has come up in the discussions. As=20 such, it's not clearly and sufficiently enough worded for the council to=20 feel comfortable approving it. Based on council logs and discussion, I=20 get the STRONG impression that they are pretty much /begging/ the=20 proponents to address this issue, updating the GLEP as appropriate, so=20 they can /finally/ get out of the eternal debate stage and vote it up or=20 down (presumably up as it doesn't appear they have a viable alternative=20 either) on its merits, and the PMs can get it implemented and both the=20 council and Gentoo can move on. Unfortunately, due to "personnel issues", apparently there's currently=20 nobody filling the triple qualifications of being (1) a strong enough=20 proponent to bother, (2) a PM dev or other with sufficient grasp of the=20 issues to actually /do/ the work, and (3) a Gentoo dev with the necessary= =20 authorization and access privs. Until that changes and the GLEP is=20 updated appropriately, we seem locked in the endless loop of discussion=20 going nowhere, fast! So it seems the proponents have a clear way forward, should they wish to=20 pursue it. Until they do, we might as well quit the discussion as it's=20 not accomplishing anything, no matter how good it could be or how much of= =20 a block the failure to implement is on future improvements. The council=20 seems to have been clear enough, even /I'm/ getting that much. --=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