From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
Date: Wed, 3 Mar 2010 15:08:22 +0000 (UTC) [thread overview]
Message-ID: <pan.2010.03.03.15.08.22@cox.net> (raw)
In-Reply-To: 20100303124741.53f4b82c@snowcone
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@gentoo.org> 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
next prev parent reply other threads:[~2010-03-03 15:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 18:27 [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2 Arfrever Frehtes Taifersar Arahesis
2010-03-03 6:52 ` Petteri Räty
2010-03-03 7:52 ` [gentoo-dev] " Ryan Hill
2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 9:23 ` Nirbheek Chauhan
2010-03-03 11:09 ` Petteri Räty
2010-03-03 12:40 ` Ryan Hill
2010-03-03 15:55 ` Petteri Räty
2010-03-03 21:39 ` Ryan Hill
2010-03-04 7:13 ` Petteri Räty
2010-03-04 7:39 ` Ulrich Mueller
2010-03-04 7:55 ` Petteri Räty
2010-03-04 9:43 ` Ulrich Mueller
2010-03-05 3:19 ` Ryan Hill
2010-03-03 12:47 ` Ciaran McCreesh
2010-03-03 15:08 ` Duncan [this message]
2010-03-03 15:46 ` Petteri Räty
2010-03-05 9:54 ` [gentoo-dev] " Peter Hjalmarsson
2010-03-05 11:12 ` Petteri Räty
2010-03-05 20:14 ` [gentoo-dev] " Ryan Hill
2010-03-05 21:00 ` Mike Frysinger
2010-03-06 5:42 ` Petteri Räty
2010-03-05 18:40 ` Duncan
2010-03-05 19:16 ` Mike Frysinger
2010-03-03 14:02 ` [gentoo-dev] " Jeremy Olexa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2010.03.03.15.08.22@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox