Gentoo Archives: gentoo-pms

From: Andrew D Kirch <trelane@×××××××.net>
To: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Cc: Ulrich Mueller <ulm@g.o>, Patrick Lauer <patrick@g.o>, gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] tree-layout.tex small cleanup
Date: Sat, 19 Sep 2009 23:19:46
Message-Id: 4AB5670D.3030901@trelane.net
In Reply to: Re: [gentoo-pms] tree-layout.tex small cleanup by Ciaran McCreesh
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.

Replies

Subject Author
Re: [gentoo-pms] tree-layout.tex small cleanup Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>