From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NmqD4-0006cX-6a for garchives@archives.gentoo.org; Wed, 03 Mar 2010 15:10:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 39821E0F97; Wed, 3 Mar 2010 15:09:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id AD37FE0F55 for ; Wed, 3 Mar 2010 15:09:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 509EC1B45DF for ; Wed, 3 Mar 2010 15:09:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 required=5.5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dECSPFxAk7eU for ; Wed, 3 Mar 2010 15:09:30 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 3746F1B45EF for ; Wed, 3 Mar 2010 15:09:27 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NmqC6-0006c2-Rd for gentoo-dev@gentoo.org; Wed, 03 Mar 2010 16:09:02 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Mar 2010 16:09:02 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Mar 2010 16:09:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> 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) Message-ID: References: <201003021927.18379.Arfrever@gentoo.org> <4B8E0747.4050008@gentoo.org> <20100303015253.7930de6f@gentoo.org> <4B8E2229.3010408@gentoo.org> <20100303124741.53f4b82c@snowcone> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9c0f37ee-7f14-4e6b-bebc-a8bd8531ad7d X-Archives-Hash: f360643da66e4e6c62f6db0646b09c51 Ciaran McCreesh posted on Wed, 03 Mar 2010 12:47:41 +0000 as excerpted: > On Wed, 03 Mar 2010 09:47:37 +0100 > Tom=C3=A1=C5=A1 Chv=C3=A1tal wrote: >> >> Removing eclass functions like this is not allowed by current >> >> policy. If you want to do it, you should discuss about changing >> >> policy. >> >=20 >> > since when? >> >=20 >> Since ever. >> If you change eclass abi you need to rename it. >=20 > 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=20 possible to change eclasses without affecting uninstalls of currently=20 installed packages that used them. Now that the wait is over and the work is done, are we going to forbid to= =20 actually use it? But I believe the policy claim was simply a misunderstanding of the=20 original practical requirement and the reasons behind it. With that=20 misunderstanding cleared up, what remains is ensuring that current in-tre= e=20 use gets fixed, and the changes are communicated so future users get it=20 right, as well. The proposed deprecation and migration plan does seem to= =20 do that, altho minor quibbles on timing could be made. (It does seem mos= t=20 changes like this get a year by tradition, and that would be to the "die"= =20 phase, which would put it at March ??, 2011, with the final removal=20 perhaps another six months out. However, for this ~arch user, that alway= s=20 seemed overly conservative, so /I'd/ not contest the shorter timing as=20 proposed. Someone might wish to, tho, and AFAIK the precedent would be=20 behind them.) I would suggest setting /some/ sort of minimum time policy, however,=20 perhaps four months per phase (warning, die), thus giving folks who updat= e=20 once per quarter a bit of leeway. In practice that'd push the die phase=20 out slightly as the deprecations are still being debated and are=20 presumably not in-tree yet, perhaps to mid-July if they're in by mid-mont= h=20 (March), but allow removal before the end of the year. --=20 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