| 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 |
Archives