Ciaran McCreesh wrote: > On Mon, 24 Dec 2007 10:52:53 +0000 > Steve Long <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >> > On Mon, 24 Dec 2007 06:03:12 +0000 >> > Steve Long <[EMAIL PROTECTED]> wrote: >> >> * Set the EAPI inside the ebuild in a way that makes it easy to >> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is >> >> no backward compatibility issue. >> > >> > It's both a backwards and a forwards compatibility issue. >> > >> Yeah, so forwards into the future where it's impossible to maintain >> this format (er..) there'll be another type of ebuild for your >> purported long-term solution. > > Hopefully that'll be EAPI 2, and hopefully we're talking months rather > than years. > Whatever. EAPI="2" works fine with current software. Could you tell me why you're so hot on export'ing EAPI? I thought it was only relevant, environment-wise, to the ebuild and subshells. What is the use case for exporting it externally?
> * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor > across EAPIs removing features, nor EAPIs changing eclasses. > I don't see what's wrong with EAPI (if set, otherwise implicitly whatever the ebuild sets, or 0 if not set there) only applying to the file it's declared in. Since we can't remove eclasses, it would be useful to continue allowing them to examine the EAPI variable for future compatibility. I'm sure there are other restrictions imposed by this "enhancement" which make maintenance more difficult for no benefit to the maintainer. -- [EMAIL PROTECTED] mailing list
