[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Duncan]

Brian Harring <ferringb@×××××.com> 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[...]
>>
>> 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