Ciaran McCreesh wrote:
> On Sat, 19 Sep 2009 18:31:22 -0400
> Andrew D Kirch <trelane@...> wrote:
>   
>>> But it was an official Gentoo project, and it was used in a
>>> repository run by the Gentoo KDE team. Remember that EAPI support
>>> is needed to be able to uninstall a package that was installed with
>>> a particular EAPI, so EAPIs can't be removed even when they're no
>>> longer in use.
>>>       
>> I can't agree here.  While no process exists to remove deprecated EAPI
>> functionality, this sort of thing should be noted in the NEXT EAPI
>> RELEASED and via that method eliminated.
>>     
>
> 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.
>> 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.