On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima <[EMAIL PROTECTED]> wrote:
> Since it doesn't appear the question was answered by the last thread.
> I'm starting a new thread.
The only sane solution I can think of is that eclasses shouldn't be
allowed to change EAPI, but use conditionals to behave differently if
needed. Mixing two (or more) different arbitrary EAPIs isn't going to
work as after the inital parsing package managers will only see the
last EAPI value anyway. Also there is no guarantee that future EAPI
versions will be backwards compatible, so if eclasses could have an
EAPI version it would eventually require that all packages using it
need the same EAPI version (similar for nested inheritance).
It's trivial to let inherit check that an eclass doesn't modify EAPI,
and adding the conditional code to eclasses isn't difficult either:
foo.eclass:
if [ -z "$EAPI" ]; then
inherit foo-eapi0
fi
case "$EAPI" in
0)
inherit foo-eapi0
;;
1|2)
inherit foo-eapi1_2
;;
*)
eerror "foo.eclass: unsupported EAPI value $EAPI"
;;
esac
# EAPI independent code here
Obviously instead of specific eclasses one could also inline the
relevant code. The only two issues I see in this concept are the
eventual multiplication of eclasses and the lack of proper error
handling for unsupported EAPIs.
Marius
PS: Yes, this idea has been mentioned in the old thread as well
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
