>>>>> On Tue, 13 Mar 2012, Brian Harring wrote:
> Perfectly valid, if stupid, bash:
> EAPI=3
> EAPI=4
> Which is the PM to choose? Because if your answer is "the first",
> then you need to keep in mind that any following code (including
> eclasses that test eapi) will be seeing the second during sourcing.
> Nice little gotcha, that one.
> I'm aware people have suggested "make EAPI readonly" to try and deal
> w/ this; that however means it'll break any PM that uses eval for
> loading the ebuild, and means that every ebuild sourcing for phase
> running will throw a complaint about EAPI being readonly.
For the moment, let's assume that we go that route and specify the
EAPI in a comment in the first line of the ebuild. The EAPI variable
can be made readonly if we do one of the following:
- One time change of the ebuild's extension, so old package managers
won't see the new ebuilds.
- Specify the EAPI in the header, plus an assignment that is only seen
by old package managers (that don't get the EAPI variable from the
ebuild's header). All of the following should work:
: ${EAPI=5}
: ${EAPI=unsupported}
[[ ${EAPI} ]] || EAPI=-1
Any value for the EAPI can be used, as long as it's unknown to old
package managers.
- A variant of the above, if an EAPI would add features that make
sourcing of the ebuild with old package managers impossible:
[[ ${EAPI} ]] || { EAPI=-1; return; }
Testing this with current Portage (2.1.10.49) and two test ebuilds,
app-misc/foo-1 is EAPI 4, app-misc/foo-2 contains the above line:
# emerge -p app-misc/foo
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-misc/foo-1
foo-2 is masked by its unknown EAPI. No further warnings for the
user.
If I try to force installation of foo-2, I get the following:
# emerge -p =app-misc/foo-2
These are the packages that would be merged, in order:
Calculating dependencies... done!
!!! All ebuilds that could satisfy "=app-misc/foo-2" have been masked.
!!! One of the following masked packages is required to complete your
!!! request:
- app-misc/foo-2::x-ulm (masked by: missing keyword, invalid: SLOT:
invalid value: '', SLOT: undefined)
The current version of portage supports EAPI '4'. You must upgrade to a
newer version of portage before EAPI masked packages can be installed.
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
One line of spurious warnings because of missing KEYWORDS and SLOT,
because the ebuild returns before these lines can be assigned.
Otherwise, a clear message that the user should upgrade Portage.
(Arguably, adding a line like [[ ${EAPI} ]] || { EAPI=-1; return; }
to ebuilds wouldn't look elegant. See the above as proof of concept
that a readonly EAPI variable is possible.)
> I don't hugely expect PMs to screw up the ordering of which to
> chose, although it exists; trying to ban secondary settings is also
> an approach... but all of it points to the fact it's a fricking hack
> and isn't really worth doing.
> If we're going to redo EAPI, redo it right. Don't half ass it- this
> time around we're not forced to make compromises.
> Viewing it that way, this grep hack shouldn't be on the table as a
> viable option.
Agreed, it's a hack if we try parsing the bash assignment statement.
I don't see it as a hack if we have a well defined syntax for the
ebuild's first line.
Ulrich
