[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Patrick Lauer <patrick <at> gentoo.org> writes:

>
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>
> The proposed solution to a problem that is never refined, in short, is to add
> the EAPI into the ebuild filename "to make things easier". Which is a rather
> unsubstantiated idea that doesn't really add up if you look at it ... and it
> adds some artifacts that we've been laughing about for a decade because
> microsoft did the exact same thing (binding the executable-ness of a file to
> the filename).
>

The problem isn't GLEP55 (as such), it is a bit more subtle then that and runs 
deeper then just this GLEP.

For starters it is the whole GLEP process
GLEP [Gentoo Linux Enhancement Proposals] is meant as a central place to pull 
*proposals* that provide enhancements to Gentoo.
Some are quite self-apparent (GLEP08)
others are a bit more... lacking (GLEP55)
Why is GLEP55 lacking? because it providing a "solution" to a problem that is 
not actually defined
"The current way of specifying the EAPI in ebuilds is flawed"
That is not defining the problem, that is an opening statement.

"In order to get the EAPI the package manager needs to source the ebuild, which 
itself needs the EAPI in the first place."
It then describes "a" mechanism utilising an ebuild (source /usr/portage...) to 
obtain the EAPI from within the ebuild (EAPI=...). Using this method the entire 
content of GLEP55 is accurate. 

However, this is not the only method to determine the EAPI of an ebuild that 
exists and as such the viability of GLEP55 as the best solution is brought into 
question
Where is it defined that the ebuild must be sourced 1st?
Why does the ebuild have to be sourced 1st?


This then results in ml participants taking this GLEP as the *only* solution 
(to a problem that hasn't actually been defined...) with statements like 
"That's *obviously* completely wrong" 
If something was so obvious this GLEP would have been approved/rejected by now, 
but it hasn't because the problem isn't defined "because it is obvious"

If a problem cannot be describe then the problem is not understood by the one 
writing about the problem.


The GLEP process needs to be refined such that some means of initially raising 
a problem (be it a GLEP itself) that describes the problem in as much detail as 
possible. Once said GLEP has been accepted, ie the problem is acknowledged, 
(sub) GLEP's can be submitted providing possible solutions to the problem.

This way the problems encounted with this particular GLEP, a GLEP that keeps on 
re-surfacing, would be minimised

GLEP55 explicitly states that the EAPI to be recorded in the file extension, 
while, as this thread has shown, a number of methods can be used to source the 
EAPI version of the ebuild *without* the need of actually source'ing the ebuild
(grep, sed, metacache) all of which are viable solutions to the problem, the 
problem that is so obvious it doesn't actually have to be defined


Thing is the package manager *needs* to know the EAPI that the ebuild complies 
to before it can source it to ensure 
1) the correct EAPI-specific eclass is inherited
2) Package manager needs to protect itself from ebuild syntax that earlier 
system packages (eg bash) would fail with 


So please just reject GLEP55, not because its wrong but because it is 
incomplete
reject GLEP55 and have a GLEP62 submitted which defines the problem, then 
request GLEP62-{1,2,3...} be submitted providing possible solutions to the 
problem. GLEP55 can then be submitted as a possible solution. Then 
developers/council can vote on the sub-GLEP's to choose which solution is the 
best technically as well as what is best for the users (dev's and general 
users)


Traceability of issues and solutions is needed, traceability that extends 
beyond mailing-lists and irc logs (discussion mediums which are good for 
instantaneous discussion of issues, but are rubbish for returning to an issue a 
few years down the line, no matter how many logs exist). Report the problem 
better

How clear is it from the stored infomation available whether EAPI's when they 
were 1st conceived and added to portage/paludis/pkgcore was the best solution 
to the problem of expanding on ebuild capability. Or more to the point was how 
it was done partly responsible for the mess we are in now? 

If the problem on ebuild expansion was better documented and defined, maybe 
this GLEP wouldn't even exist, we may have been already using *.ebuild-3 
because it was the best solution