Brian Harring <ferri...@gmail.com> posted 20090223085232.ga6...@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[...] >> >> Instead of switching file extension every time the eapi is changed you >> could also increment it only when a new EAPI breaks sourcing the ebuild >> compared to the requirements of the prior EAPI. (This way you'd in fact >> split EAPI into a major- and a minor-version.) > > 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 coming from potentially unlimited changes to the extension. That rubs some people strongly enough the wrong way to have folks threatening to leave over it, etc. If it must be, it must be, but obviously, if there's a /reasonable/ way to avoid it, we should. Way back when this first came up, I asked a simple question and IIRC wasn't satisfied with the answer. Since the elements of it have been proposed separately, perhaps it's time to ask about the combination once again, as it seems to me to solve both the technical and aesthetic issues, tho admittedly it does have a bit of the "complicates the implementation" problem. As I understand it, the nastiest technical problem is currently the chicken/egg issue of needing the EAPI to source the ebuild... to /get/ the EAPI. Above, we have what amounts to a major/minor EAPI proposal, stick the major in the extension (or as a variant, the pre-extension filename), with it bumped only when the format changes enough to require 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 ebuild and in a format specific enough to be parsed /without/ sourcing the ebuild, thus providing a pre-source method for grabbing the EAPI. The shoot-down when originally suggested was that this isn't flexible enough. It's also arguably less efficient since one has to access the file twice, first to get the EAPI, then to actually source the file. 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 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 /because/ of the need-the-EAPI-to-source-to-get-the-EAPI issue. This would eliminate that issue, providing both the necessary pre-source (major) EAPI solution and flexibility on the post-source (minor) EAPI. It would also avoid the so controversial aesthetic issue, maintaining the traditional .ebuild extension. The negative, however, as mentioned, is that of efficiency. It'd be necessary to access the file twice, pre-source to get the EAPI-major, then the source to fill in all the details. Putting just the EAPI-major in the filename/extension would avoid the first access (a dir listing would suffice) and using the filename for the EAPI entirely would in some cases possibly avoid accessing the file itself entirely -- at the expense of EAPI flexibility and aesthetics. Meanwhile, a status/process observation, if I may. Given the efficiency negative of putting the EAPI anywhere /but/ the filename and the way the debate has gone, GLEP-55 or something close to it (using the filename for EAPI) would appear headed toward ultimate approval, however slow it seems to be getting there. The major blocker would appear to be that the GLEP as-is simply doesn't sufficiently address everything that has come up in the discussions. As such, it's not clearly and sufficiently enough worded for the council to feel comfortable approving it. Based on council logs and discussion, I get the STRONG impression that they are pretty much /begging/ the proponents to address this issue, updating the GLEP as appropriate, so they can /finally/ get out of the eternal debate stage and vote it up or down (presumably up as it doesn't appear they have a viable alternative either) on its merits, and the PMs can get it implemented and both the council and Gentoo can move on. Unfortunately, due to "personnel issues", apparently there's currently nobody filling the triple qualifications of being (1) a strong enough proponent to bother, (2) a PM dev or other with sufficient grasp of the issues to actually /do/ the work, and (3) a Gentoo dev with the necessary authorization and access privs. Until that changes and the GLEP is updated appropriately, we seem locked in the endless loop of discussion going nowhere, fast! So it seems the proponents have a clear way forward, should they wish to pursue it. Until they do, we might as well quit the discussion as it's not accomplishing anything, no matter how good it could be or how much of a block the failure to implement is on future improvements. The council seems to have been clear enough, even /I'm/ getting that much. -- 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
