It’s the hottest new flamewar topic in Gentoo. But I still have to ask, why? The entire idea to me seems stupid. Why must we butcher filenames to achieve this? OK, let’s look at the GLEP’s proposed problem.
The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source’able by old package managers and hence there is no way to do any of the following: [...]
Oh noes! And the proposed “solution”:
The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This allows package managers to trivially read the EAPI from the ebuild filename. It is also backwards compatible, because currently ebuilds are recognised by the .ebuild file extension and hence EAPI-suffixed ebuilds are simply ignored by the package managers.
Alright, I don’t see how the package manager developers cannot develop an easier solution. How about improving what we already are doing? All of our ebuilds with EAPI have the EAPI="foo" string in the ebuild. Why cannot we formalize and set guidelines exactly where this line should be (such as the top of the ebuild) and the format of the string. If we did this, then figuring out the current ebuild EAPI would be insanely trivial.
With the string formalized, package managers wouldn’t even need to “source” the file to figure out what EAPI it is. They could simply use $(insert favorite method of extracting a string) to grab the EAPI line and then pass it to the package manager to figure out what to do with it. No butchering of the filenames and other nonsense. The EAPI string would have a sane format and would easily be extractable to be passed to the package manager. It would then be up to the package manager to do with the situation thereafter.
I don’t see how we can’t use this as a solution. I better revisit those three bullets under problems to make sure I try to make some sense.
Change the behaviour of inherit in any way (for example, to extend or change eclass functionality).
Well since the package manager doesn’t need to source the thing to find the sanely formatted EAPI string inherit isn’t going to randomly implode into a billion pieces. This is essentially the same as shoving the string in the filename, except doesn’t make the filenames ugly and still works.
Add new global scope functions in any sane way.
Same as above, if the EAPI doesn’t match just abort the mission.
Extend versioning rules in an EAPI – for example, addition of the scm suffix – GLEP54
Well, since we have a sane format for the EAPI string, this shouldn’t be a problem at all.
BUT WHAT ABOUT THE BACKWARDS COMPATIBILITY !!1?!1!?!
Umm, every new EAPI pretty much breaks backwards compatibility. Either the PM knows how to handle the new EAPI or it should tell the user to upgrade or something and die gracefully. I see no difference between a sane line in the filename or a sane line inside the file. One of these solutions requires a bigger change than the other.
I don’t want to even argue you people that go “omg what if we use XML or binary or some other type of crap instead of bash ebuids”. Well then, you just ran the backwards compatibility baby over with a train and its moot.
At the end of the day no solution is perfect and there will be code to be written. Nothing can truly predict what we will need to accommodate the future.
#1 by Ciaran McCreesh on May 16, 2009 - 5:27 pm
The only reason this is still being discussed is that people like you go around commenting on things you don’t understand. Your post is chock full of nonsense and you clearly don’t have a clue what we’re discussing. Kindly shut up until you do — posts like yours are part of the problem, not part of the solution.
#2 by Maciej Piechotka on May 16, 2009 - 6:11 pm
In GLEP 55 there are specified counter-arguments against such solution. About the ‘Umm, every new EAPI pretty much breaks backwards compatibility.’ it is not a counter argument – EAPI does not directly break backwards compatibility in package manager. I.e. package manager supporting EAPI 2 does not fails with EAPI 1 package. However with such restriction it will fail despite the ebuild was valid (it does not matter if it is well-written or not – as long as it follows the standard it should be accepted).
#3 by rik on May 16, 2009 - 6:55 pm
“The proposed solution is to use EAPI-suffixed file extensions for ebuilds. “
As in exheres-0 ?
#4 by Ken on May 16, 2009 - 7:03 pm
Sorry, I’ll voice my opinion on whatever I want. I don’t see a solution in this GLEP, just more beating around the woods and bastardization of portage.
I see no concrete reason why this filename game is better in any kind of way.
Sorry I see no counter-arguments, care to actually list one than just proposing its invalid without cause?
#5 by Ciaran McCreesh on May 16, 2009 - 7:59 pm
How do you plan to fix the arbitrary and pointless restrictions forbidding versions like 1.2.3-rc1 without GLEP 55?
#6 by Ken on May 16, 2009 - 9:15 pm
Last time I read GLEP 55 it only indirectly addresses versions through new EAPI’s.
The only issue I see to that is that older PM’s would not know to search the EAPI inside without sourcing the entire thing and thus erroring out. Any new package managers would be aware of the new change (either filename or my proposal).
Assuming this is what you meant, I admit I did not consider older versions of PM’s, mainly as there will almost always be users out there with crap so old its a lost cause.
I will agree with you that I find it disturbing this GLEP is still being discussed for over a year. It should be polished if it needs it and shipped off for voting.
#7 by Ciaran McCreesh on May 16, 2009 - 9:24 pm
That’s always been one of the critical points of GLEP 55. It’s right up there in the problem description at the start.
At best, you’d be forcing the package manager to extract metadata for every version of a package before it can do anything. Currently package managers can just start at the best version and work downwards until they find something suitable.
It’s not a lost cause, that’s the point. GLEP 55 does what EAPIs were supposed to do — it removes the need to break older package managers.