Fabian Groffen kirjoitti: > On 09-11-2007 23:55:51 +0200, Petteri Räty wrote: >> Usually it's best that ebuild variables follow the order that is in >> skel.ebuild. So know we should decide where to place EAPI. I suggest we >> put it it after LICENSE as that's where the more technical stuff like >> SLOT starts. Attached a patch for skel.ebuild. > > Just my 2 cents, I have placed EAPI right after the # $Header: line of > each ebuild, as I felt that it was the first thing to know of the > ebuild, as it describes how you possibly have to process the rest of the > ebuild. Examples can be found in the prefix overlay, e.g. > http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-shells/bash/bash-3.2_p17-r00.1.ebuild > > It has the advantage for me that EAPI is never hidden away somewhere > down the ebuild, and it is just inserted by a simple bash script > automagically (eapify in this case). >
If we go with this solution then I guess eclasses must check for the EAPI variable and then act accordingly. For example if the ebuild sets EAPI=2 and the eclass is designed for EAPI=1 then it could be made to die in case EAPI 2 is not backwards compatible. The main reason for me asking this it that I plan to make the java eclasses use the EAPI 1 features. Regards, Petteri
signature.asc
Description: OpenPGP digital signature
