On Tue, 18 Dec 2007 23:50:22 +0000 (UTC) Duncan <[EMAIL PROTECTED]> wrote: > Piotr Jaroszyński <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec > 2007 21:11:20 +0100: > > On Tuesday 18 of December 2007 20:45:44 Duncan wrote: > >> How about when we have a dozen or so EAPIs active, several of which > >> apply to a specific ebuild? > > > > Where is this idea of mixing EAPIs coming from? It really doesn't > > make much sense. > > If EAPI is defined as a particular set of features and rules as > grouped together under a specific EAPI label (Ciaran's general > definition), and is specifically not ordered, as is the case, thus > allowing, potentially, multiple EAPIs to evolve in parallel > (Grobian's message), as the upthread argues is possible, even > likely...
But you can't mix features arbitrarily. > And if a particular ebuild uses features from a non-conflicting > super-set of several such EAPIs (Ulrich's message) ... Then there should be an EAPI defined that permits all of those features. Functionality would only be removed from EAPIs for specific reasons: * Conflicts with new features (think *DEPEND vs DEPENDENCIES). In which case, you can't mix features between EAPIs anyway. * Deprecating old nasty features. In which case, you shouldn't be using said features anyway. * Massively different EAPIs. In which case you reaaaallly can't mix EAPIs. -- Ciaran McCreesh
signature.asc
Description: PGP signature
