GLEP 55
January 21st, 2008I will state that I’m far from the most technical person when it comes to the EAPI’s that we deal with. I learn about it as I’m required to so my understanding will be far from perfect. I however was asked by a user to explain in a bit clearer detail what this glep is about and what it means to the users as a whole.
At its core this is a expansion of the EAPI=0 documentation that is defined in the PMS. You can get the full technical document here. EAPI’s are basically as I defined earlier a spec for ebuilds, eclasses, and the package manager. It defines what should be expected and in what form to ensure that no matter where your source is, or the package manager that you use it will all just work happily.
Now you might say that Gentoo has always done this but its never really had any other package manager that wanted to make use of the same ebuilds. This is why the spec was created so that there is a defined standard that everything conforms to and you get a very expected result every time. It also allows people to write paludis, portage, and pkgcore without having to find edge cases.
Glep 55 is a continuation of this EAPI spec. It seeks to add a ending onto the .ebuild suffix to define what part of the spec it is valid in. A .ebuild conforms to a -0 or EAPI=0. .ebuild-1 would conform to EAPI=1 which is glep 55. This doesn’t require any parsing of the actual ebuild itself to figure out what EAPI version you are dealing with.
A function that could be eapi=1 only would not work for a package manager that is only able to do eapi=0 specs. It would obviously fail for a number of reasons.
Now as far as users are concerned, there’s not much change for you. It ensures that you continue to get updates without issue no matter if you switch from portage, to pkgcore, to paludis, then back to portage. What will change is that if you are using a version that is only supporting eapi=0 you will not see packages that are .ebuild-1 as the package manager would not be able to handle them anyways.
Hopefully, this gives you a somewhat better understanding of what the heck the Glep is about.
January 21st, 2008 at 8:57 pm
very nice and explanatory article…
thx!…
January 23rd, 2008 at 4:28 pm
No offense, but I far prefer ferringb’s idea (as discussed in the last Council meeting) to use an eapi function. Putting this data in the filename is such a nasty hack. EAPI was never meant to be for anything other than bash ebuilds, according to ferringb (who came up with it in the first place.)
January 24th, 2008 at 12:44 pm
SteveL,
I don’t entirely agree with the name changing option that is going on here and am glad that the council is giving it serious consideration about what would be the best way to go about EAPI version synchronization without having to physically read the ebuild to find out.
I however did this post just as an informational post to the users who requested some details about what the GLEP was about. If you’d like to expand on ferringb’s idea on the matter I’m sure that many people would like to hear it.
February 26th, 2008 at 6:34 pm
Oops, missed your response, and I don’t really know the ins and outs; all I understood it to be was an eapi function call rather than a variable declaration. This is extensible to other formats, although EAPI was only ever supposed to be for BASH.
I don’t see the big issue with reading the ebuild, especially if it doesn’t require sourcing it in bash (simple var declaration.) There is a metadata cache, after all.
Thanks for the recent posts, both here and on the forums.