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