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
