On Fri, 2009-05-29 at 10:42 +, Duncan wrote:
Michael Haubenwallner ha...@gentoo.org posted on Fri, 29
May 2009 10:14:46 +0200:
Ohw, the latter would be necessary here, or '4.ebuild' would not be
found.
s/4.ebuild/4.eclass/ I assume.
Indeed.
Except... since an ebuild must presently be sourced to (properly)
determine EAPI, it still doesn't work for changes that break sourcing or
other pre-EAPI processing (like parsing PN and PVR out of the filename),
so the changes allowed with a simple EAPI change are still rather limited.
As long as the *whole* ebuild content (including the filename) needs to
be successfully interpreted just for EAPI detection, we will have to
change the extension or wait the extended period for each incompatible
EAPI change. So this full interpretation for EAPI detection doesn't feel
like a good way to go at all.
That's why the change to GLEP55 or alternative, whether in-filename or
in-file-itself, will again require either an extended wait after
introduction (the old way) or at minimum, a one-time change to extension
such that old PM versions don't even see the currently EAPI incompatible
changes.
Wouldn't it be possible to avoid both the extension change and another
extended wait period for new incompatible(*) EAPIs, when we do this
early and silent exit hack for unsupported ebuilds with old PMs that
still do full interpretation for EAPI detection?
And after another extended wait period(**), we can start dropping the
silent exit hack, so we finally have switched to EAPI detection without
full interpretation, but still have the .ebuild extension.
(*) The incompatibility of EAPIs must not begin (meaning the bytewise
ebuild content) before the end of both the ebuild's EAPI value
definition and the silent exit hack.
But this IMO is an acceptable compromise.
(**) After this wait period, the incompatibility of EAPIs can start
after the end of the ebuild's EAPI value definition.
Thanks!
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
