1 |
On 03/03/2010 11:39 PM, Ryan Hill wrote: |
2 |
>> |
3 |
>> Also policies should be changed when they don't make sense any more as I |
4 |
>> said in my first response but I am not sure if that's the case here. |
5 |
> |
6 |
> The problem is I don't think this is actually a policy. One of the first |
7 |
> projects I did as a developer, while still under probation, was a complete |
8 |
> rewrite, in-place, of an eclass. Many functions were removed or renamed |
9 |
> (done in an overlay of course, with a migration path). It was fully reviewed, |
10 |
> on list, by senior devs at the time. I was told by several people that if |
11 |
> there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be |
12 |
> touched because of portage limitations (those limitations were removed ~3 |
13 |
> years ago now IIRC). So I wonder if this isn't just a years-long game of |
14 |
> Telephone where one rule passed down by word of mouth got over-generalized |
15 |
> and sufficiently twisted as to apply to everything. |
16 |
> |
17 |
|
18 |
You can mostly get away with deprecating eclass functions in a slowly |
19 |
manner. |
20 |
|
21 |
> Nor do I think it's a particularly useful policy that keeps deprecated |
22 |
> interfaces around forever. Careful removal with a long warning period |
23 |
> shouldn't actually pose a problem. I think Arfrever's plan is reasonable. |
24 |
> |
25 |
|
26 |
If we decide allowing removal of functions, we should come up with a |
27 |
common procedure like the eclass removal policy: |
28 |
http://devmanual.gentoo.org/eclass-writing/index.html |
29 |
|
30 |
Regards, |
31 |
Petteri |