On Sat, 19 Sep 2009 19:19:41 -0400
Andrew D Kirch <trelane@...> wrote:
> > Please explain what you mean. EAPIs are conceptually independent,
> > and don't deprecate each other in any kind of way, and future EAPI
> > releases can't retroactively change what previous EAPIs said.
> >   
> There's no reason why a subsequent EAPI cannot modify or remove
> behavior created in a previous EAPI.

If you mean "EAPIs don't have to include every feature that was
included in a previous EAPI, and can do things differently from
previous EAPIs" then sure. See, for example, dohard and dosed being
removed in EAPI 3.

If you mean that "EAPIs can change the meaning of older EAPIs", then
you're wildly misunderstanding how the whole thing works. We couldn't
use EAPI 3 to say that "it's illegal for EAPI 0, 1 and 2 things to use
dohard and dosed"; that would defeat half of the point of having EAPIs.

> >> This is a specifications document, not a history lesson covering
> >> past mistakes.
> >
> > Getting off-topic here, but which parts of kdebuild-1 do you think
> > were mistakes? Given how kdebuild-1 features are making their way
> > into EAPIs 2, 3 and beyond as Portage gains support for them, I'm
> > sure you don't mean that every feature was wrong, so which of the
> > remaining ones do you think shouldn't be adopted and why?
> >   
> kdebuild itself wasn't a mistake, that it made it in when it's not
> used was.

Explain please. kdebuild-1 was used.

-- 
Ciaran McCreesh