On 03/03/2010 02:40 PM, Ryan Hill wrote: > On Wed, 03 Mar 2010 13:09:49 +0200 > Petteri Räty <[email protected]> wrote: > >> On 3.3.2010 11.23, Nirbheek Chauhan wrote: >>> 2010/3/3 Tomáš Chvátal <[email protected]>: >>>>>> Removing eclass functions like this is not allowed by current policy. If >>>>>> you want to do it, you should discuss about changing policy. >>>>> >>>>> ?! >>>>> >>>>> since when? >>>>> >>>> Since ever. >>>> If you change eclass abi you need to rename it. >>>> >>> >>> I think you can *add* functions and variables to eclasses, you can >>> change *how* a function works internally, you can *fix* problems with >>> functions (which would technically result in a change in API). I don't >>> think it has ever been as strict as, say, the kernel ABI interface. >>> >> >> Yes, eclasses go along the same lines as shared libraries, which is >> probably what Tomáš meant any way. > > Is this actually documented anywhere? Or is this another of our > "this-is-policy-because-everyone-knows-it's-policy" policies? I know there > was a technical issue with removing pkg_*_rm functions way-back-when, but if > there's no technical reason why functions can't be deprecated, and we're just > clinging to policy in the name of policy, then I can't say I see the point. >
Big eclass changes should go through gentoo-dev so someone here will point it out at least. Devmanual should document it so I challenge anyone to submit a patch: http://devmanual.gentoo.org/eclass-writing/index.html git+ssh://git.gentoo.org/var/gitroot/devmanual.git 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. Regards, Petteri
signature.asc
Description: OpenPGP digital signature
