GLEP 55 Madness
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.