On 03/03/2010 11:39 PM, Ryan Hill wrote:
>>
>> Also policies should be changed when they don't make sense any more as I
>> said in my first response but I am not sure if that's the case here.
> 
> The problem is I don't think this is actually a policy.  One of the first
> projects I did as a developer, while still under probation, was a complete
> rewrite, in-place, of an eclass.  Many functions were removed or renamed
> (done in an overlay of course, with a migration path). It was fully reviewed,
> on list, by senior devs at the time.  I was told by several people that if
> there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be
> touched because of portage limitations (those limitations were removed ~3
> years ago now IIRC).  So I wonder if this isn't just a years-long game of
> Telephone where one rule passed down by word of mouth got over-generalized
> and sufficiently twisted as to apply to everything.
> 

You can mostly get away with deprecating eclass functions in a slowly
manner.

> Nor do I think it's a particularly useful policy that keeps deprecated
> interfaces around forever.  Careful removal with a long warning period
> shouldn't actually pose a problem.  I think Arfrever's plan is reasonable.
> 

If we decide allowing removal of functions, we should come up with a
common procedure like the eclass removal policy:
http://devmanual.gentoo.org/eclass-writing/index.html

Regards,
Petteri