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
signature.asc
Description: OpenPGP digital signature
