On Sat, 15 Dec 2007 10:43:35 +0100 Vlastimil Babka <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote: > > On Wed, 12 Dec 2007 23:14:24 +0100 > > Carsten Lohrke <[EMAIL PROTECTED]> wrote: > >> I disagree here. It would be annoying and possibly even hindering > >> in future not being able to use higher EAPI features in eclasses. > >> Point is the eclass has to check, if the author of an ebuild sets > >> another EAPI and throw an error, in this case. > > > > There is no way for an eclass to throw an error. Nor, with the > > current way Portage implements EAPI, is there a way to add such a > > way. > > How bout declaring all supported (possibly with later conditional > checks on EAPI variable etc) EAPIs in eclass via some variable, and > repoman checking that EAPI set in the ebuild is compatible with all > inherited eclasses? And if you need newer EAPI in the ebuild, get > eclasses updated first (even if its just updating the compatibility > declaration). Also, repoman could check that EAPI is not being set in > the eclass. Nice idea, but gets quite complicated when multiple (possibly nested) eclasses are involved as we'd have to generate a complete inheritance graph and get that new variable separately for each eclass. Or alternatively each eclass has to update the variable with the intersection between the old value and it's own set of supported EAPIs. And doesn't really solve the problem, just reduces the scope a fair bit (e.g. if an eclass drops support for an EAPI version repoman will only catch it gradually if the packages using it are bumped, unless you manually check the whole tree). Marius -- [EMAIL PROTECTED] mailing list
