On Wed, 03 Mar 2010 13:09:49 +0200 Petteri Räty <betelge...@gentoo.org> wrote:
> On 3.3.2010 11.23, Nirbheek Chauhan wrote: > > 2010/3/3 Tomáš Chvátal <scarab...@gentoo.org>: > >>>> 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. And if this is such a bad idea, then can we get it in writing? -- fonts, by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
