Various bits of bash code check the $EAPI environment variable to determine the EAPI. This isn't reliable: the code needs to change behaviour based upon the EAPI metadata variable, not the value of the environment variable, which may contain something else. Note that it's legal for ebuilds to unset metadata variables for the benefit external utilities. For example, it used to be necessary to unset 'AA' before calling 'econf' for some annoying build systems. EAPI is no different here (other than that we've not had to do it yet). It also gives people the misleading impression that they could do something like "EAPI=3 econf" to call an econf defined by a different EAPI. That happens to sort of work with Portage at the moment, and it shouldn't. Finally, with the new EAPI semantics, it will be legal to do this: inherit blah EAPI=5 But we're allowing 'inherit' to change behaviour based upon EAPI. The easiest fix is probably to set an "unlikely to need to be tampered with" variable like PORTAGE_ACTUAL_EAPI and to use that.
(In reply to comment #0) > The easiest fix is probably to set an "unlikely to need to be tampered with" > variable like PORTAGE_ACTUAL_EAPI and to use that. And keep the council apprised of the actual realities (ebuild flow, gotchas, take your pick) of this decision.
Council removed from CC as discussed in today's meeting.
