1 |
Ciaran McCreesh wrote: |
2 |
> On Sat, 19 Sep 2009 18:31:22 -0400 |
3 |
> Andrew D Kirch <trelane@×××××××.net> wrote: |
4 |
> |
5 |
>>> But it was an official Gentoo project, and it was used in a |
6 |
>>> repository run by the Gentoo KDE team. Remember that EAPI support |
7 |
>>> is needed to be able to uninstall a package that was installed with |
8 |
>>> a particular EAPI, so EAPIs can't be removed even when they're no |
9 |
>>> longer in use. |
10 |
>>> |
11 |
>> I can't agree here. While no process exists to remove deprecated EAPI |
12 |
>> functionality, this sort of thing should be noted in the NEXT EAPI |
13 |
>> RELEASED and via that method eliminated. |
14 |
>> |
15 |
> |
16 |
> Please explain what you mean. EAPIs are conceptually independent, and |
17 |
> don't deprecate each other in any kind of way, and future EAPI |
18 |
> releases can't retroactively change what previous EAPIs said. |
19 |
> |
20 |
There's no reason why a subsequent EAPI cannot modify or remove behavior |
21 |
created in a previous EAPI. |
22 |
>> This is a specifications document, not a history lesson covering past |
23 |
>> mistakes. |
24 |
>> |
25 |
> |
26 |
> Getting off-topic here, but which parts of kdebuild-1 do you think were |
27 |
> mistakes? Given how kdebuild-1 features are making their way into EAPIs |
28 |
> 2, 3 and beyond as Portage gains support for them, I'm sure you don't |
29 |
> mean that every feature was wrong, so which of the remaining ones do you |
30 |
> think shouldn't be adopted and why? |
31 |
> |
32 |
kdebuild itself wasn't a mistake, that it made it in when it's not used was. |