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. > > And eclasses are an entirely separate issue. They need to > > be dealt with differently, ideally starting with EAPI 2. > > > But they come under the scope of this discussion, since this is about > the long-term future of *every* EAPI. So let's discuss them. Ok. What technically sound ideas that have been implemented in a real package manager and tried out on a large, real tree maintained by multiple developers do you have about improving eclasses with respect to EAPI handling? I'm curious, because the only solutions we have for working with the current system are going to suck in the long term (but equally, they do work with EAPI 0/1, which means they're fine for short term), and I've yet to hear of a solution that is implementable (both theoretically and practically), usable from a tree perspective and scalable across EAPIs. To start you off, here's a list of ideas that suck: * Per-EAPI eclasses, or a master eclass that uses sub-eclasses for whichever EAPI is in use. This is the best general current solution, but it gets messy very quickly with new EAPIs. * Eclasses enforcing EAPI restrictions either by global scope or pkg_setup die. The former's illegal, breaks the metadata cache as it's done currently, and is way too easy for developers to screw up. The latter is way too easy for developers to screw up, results in users seeing the mess and doesn't allow package managers to work around it. * Variant: eclasses forcibly setting EAPI to OOPS-SOMEONE-SCREWED-UP if they don't support the eclass used. This one's actually ok from a package manager perspective, but lousy from a developer testing thing perspective. * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor across EAPIs removing features, nor EAPIs changing eclasses. * Some kind of list of supported EAPIs in an eclass. Still has to deal with EAPI 0 and 1, and doesn't work well across multiple eclasses. * Banning eclasses from using anything that isn't supported in every EAPI. Makes new features rather useless, and removing things rather difficult... * Crazy hackery involving making 'inherit' look somewhere else in future EAPIs. At best you'd end up having stub eclasses (again with no particularly nice way of saying 'oops') to deal with EAPIs 0 and 1. * Introduce some new global scope eclass-like function that, combined with supported EAPI sets, does have a proper way of signalling 'not supported' (and throw in per cat/pkg eclasses because you can). Unfortunately, you can't do this without breaking current EAPI 0 / 1 package managers, unless you also switch file extensions or some equivalent op. All but the last of these are nowhere near good enough. The last one may or may not be OK as a starting point, but everyone I've spoken to who's worked with a real multiple EAPI repo agrees that it's a long way off being a good enough idea that it's worth considering having serious discussion about it. So go ahead and start discussing eclasses, if you want. But first I suggest getting lots and lots of experience and making damned sure you understand how everything works... -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
