[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

[Ryan Hill <dirtyepic@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
> > 2010/3/3 Tomáš Chvátal <scarabeus@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]