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 |