On Fri, 2009-05-29 at 10:42 +0000, 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
