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

[Duncan]

Ciaran McCreesh posted on Wed, 03 Mar 2010 12:47:41 +0000 as excerpted:

> On Wed, 03 Mar 2010 09:47:37 +0100
> Tomáš Chvátal <scarabeus@g.o> wrote:
>> >> 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.
>
> No, that's not been the case 'since ever' at all. It used to be that if
> you changed or removed a function, you just had to make sure you didn't
> break anything. This was made more complicated by the way that eclasses
> in the tree were used for removing installed packages too, which is no
> longer an issue.

Indeed.  And a long time waiting and a lot of work went into making it 
possible to change eclasses without affecting uninstalls of currently 
installed packages that used them.

Now that the wait is over and the work is done, are we going to forbid to 
actually use it?

But I believe the policy claim was simply a misunderstanding of the 
original practical requirement and the reasons behind it.  With that 
misunderstanding cleared up, what remains is ensuring that current in-tree 
use gets fixed, and the changes are communicated so future users get it 
right, as well.  The proposed deprecation and migration plan does seem to 
do that, altho minor quibbles on timing could be made.  (It does seem most 
changes like this get a year by tradition, and that would be to the "die" 
phase, which would put it at March ??, 2011, with the final removal 
perhaps another six months out.  However, for this ~arch user, that always 
seemed overly conservative, so /I'd/ not contest the shorter timing as 
proposed.  Someone might wish to, tho, and AFAIK the precedent would be 
behind them.)

I would suggest setting /some/ sort of minimum time policy, however, 
perhaps four months per phase (warning, die), thus giving folks who update 
once per quarter a bit of leeway.  In practice that'd push the die phase 
out slightly as the deprecations are still being debated and are 
presumably not in-tree yet, perhaps to mid-July if they're in by mid-month 
(March), but allow removal before the end of the year.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman