On 11-11-2007 19:27:50 +0000, Ciaran McCreesh wrote: > On Sun, 11 Nov 2007 21:21:30 +0200 > Petteri Räty <[EMAIL PROTECTED]> wrote: > > > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to > > > 'die' at global scope. There's simply no way for eclasses to > > > complain that they're being misused. > > > > Well nothing formal but the ebuild developer should pick up ewarn/echo > > /whatever messages coming from global scope. That's what we have in > > debug.eclass atm. > > Past experience has shown that those messages will end up being seen by > end users and not being picked up by developers. People changing > eclasses generally don't force a metadata generation for every package > that uses the eclass. > > I suspect that for existing eclasses, the safest way to proceed is to > make a new eclass and move common code into a third eclass. So you'd > have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common, > and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting > foo-common.
This is indeed a very valid point that at least I have ignored for now. In order (for me) not to mix up all kinds of issues here, this is my percieved state with regard to EAPI. EAPI=0 is the assumed to be used EAPI when no EAPI is specified in an ebuild. EAPI=1 as supported by Portage is like an extension of EAPI=0 where EAPI=0 is like a subset of EAPI=1. For this reason current (soon to be stable?) Portage, and at least the trunk version have EAPI=1 support, but can deal with EAPI=0 ebuilds fine. In this setting, one could say that eclasses should remain EAPI=0, such that all ebuilds will be able to work with them. However, if an EAPI will require some change that makes it backwards incompatible then this won't work any more. What you get is that e.g. for an eclass to work properly it needs to know about variable X, which of course on previous EAPIs does not exist, and hence can result in undesired behaviour. While Ciaran's suggestion would allow some things to work there, it still does not deal with the issue that eclasses should actually be marked with an EAPI level too. (Ideally they also would be part of the digests of an ebuild, but that aside.) A slight alternative to Ciaran's idea here would be to make EAPI1, EAPI2 etc. subdirs in the eclass directory where sort of eclass overloading can be done. This would only solve eclasses not to have an EAPI= in it, so they don't overwrite the ebuild's value. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
