Gentoo Archives: gentoo-dev

From: Doug Goldstein <cardoe@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
Date: Sun, 11 Jul 2010 05:02:53
Message-Id: AANLkTilTEmLbipmMCkQ_btTx7iMXfYxlKt1Dfs5DB2-t@mail.gmail.com
In Reply to: [gentoo-dev] Re: RFC: remove php4 from depend.php and others by Ryan Hill
1 On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill <dirtyepic@g.o> wrote:
2 > On Sat, 10 Jul 2010 01:34:37 -0700
3 > Brian Harring <ferringb@×××××.com> wrote:
4 >
5 >> On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
6 >> > The standing policy is still not to remove any public functionality from
7 >> > eclasses. If we decide to start removing functionality the council
8 >> > should set common rules for it.
9 >>
10 >> Just adding a note on this one- the original technical reason for
11 >> this policy (portage inability to run from just the saved env dump)
12 >> is no longer an issue.
13 >>
14 >> If people want to allow eclasses to have fluid APIs (specifically
15 >> removal of functionality), that's a discussion that needs to start on
16 >> the dev level.
17 >>
18 >> Anyone got strong opinions on this one?
19 >
20 > I don't believe there ever was such a policy, except for pkg_{pre,post}rm
21 > because of the mentioned technical limitations (which were fixed in portage
22 > 2-3 years ago now).  If there is such a policy then I've violated it on
23 > several occasions :).  In fact, isn't the generally accepted method of
24 > deprecating an eclass to remove all functionality and replace it with a
25 > message in global scope and a "# @DEAD" tag?
26 >
27 > I don't see the advantage of keeping unmaintained broken code no one should
28 > use around in eclasses.  You can argue that removing eclass functionality can
29 > potentially break ebuilds in overlays, but if you follow that line of
30 > reasoning then really we should never remove any package from the tree
31 > because it may be a dependency of something, somewhere.
32 >
33 > So I'd like to see a policy that treats public functions in eclasses the same
34 > as the last rites policies for package removal:  minimum 30 day deprecation
35 > period, mail to dev-announce, etc.
36 >
37 >
38 > --
39 > fonts, gcc-porting,                                   and it's all by design
40 > toolchain, wxwidgets                        to keep us from losing our minds
41 > @ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
42 >
43
44 To be honest, the MythTV eclasses have been an ever evolving set of
45 eclasses for ages now. Ever since it was declared that its now safe to
46 remove eclasses from the tree since Portage saves eclasses and its
47 env, therefore it wouldn't cause a problem.
48
49 If I really need to go to the council with every change, considering
50 it must be debated on the ML for at least X number of days prior to
51 going to the council, I'd more likely just remove MythTV from the tree
52 and maintain it in an overlay. I don't invest a lot of time in the
53 MythTV ebuilds, but they work for a large majority of people. And when
54 a new version comes out it requires some retooling and it just works
55 for everyone.
56
57 So basically, you guys decide.. am I pulling them out of the tree or
58 am I leaving them in?
59
60 --
61 Doug Goldstein

Replies

Subject Author
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others "Petteri Räty" <betelgeuse@g.o>