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

[Petteri Räty]

On 03/03/2010 02:40 PM, Ryan Hill wrote:
> On Wed, 03 Mar 2010 13:09:49 +0200
> Petteri Räty <betelgeuse@g.o> wrote:
>
>> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
>>> 2010/3/3 Tomáš Chvátal <scarabeus@g.o>:
>>>>>> 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