Commits like these are happening all over: http://cgit.freedesktop.org/dbus/dbus-python/commit/?id=cdc0ca5c72686aab38a172f14da3b38fe304baa9 What is the point of trying to maintain everything for dev-lang/python:3.1 too? Propably nothing. Let's just kill it and be done with it. The maintaince cost is too high for keeping it. I can't speak for anyone else, but I have no plans whatsoever in trying any of my packages against 3.1.
#gentoo-dev: 01:50 <@floppym> That actually seems like a reasonable idea to me. Unless anyone has a good reason for keeping 3.1 around, I suppose we can just lastrite dev-lang/python:3.1 like normal package with 30 days?
The only reason I can think to keep it is that python upstream still releases security fixes for it. I don't see much value in it though.
(In reply to comment #2) > The only reason I can think to keep it is that python upstream still > releases security fixes for it. I don't see much value in it though. They propably *have to* do that for non-rolling binary distributions since some of them are fixed to use 3.1. But we don't have that "problem".
Allowing users to install Python 3.1 is not a problem. Some Gentoo users are upstream developers of projects, which want to support Python 3.1. Providing of multiple versions (e.g. 2.6, 2.7, 3.1, 3.2) and implementations (CPython, Jython, PyPy) is an advantage of Gentoo.
I'm actually with Arfrever on this one. We should just not be shy about restricting 3.1 support from packages that don't like it, but that doesn't mean we have to punt 3.1 from the tree entirely.
Then I would suggest to drop KEYWORDS to "" in =dev-lang/python-3.1* to reflect the unsupported status and to save the maintainers the trouble of adding RESTRICT_PYTHON_ABIS="3.1" everywhere And perhaps issuing a GLEP 42 News Item instructing users to steer away from dev-lang/python:3.1 and moving to dev-lang/python:3.2 for Python 3.x And bugs caused by the existance of dev-lang/python:3.1 can be closed off as WONTFIX just like they would for sys-devel/gcc:3.4, 4.0, ...
I think that's going to far. AFAICT, users already won't have 3.1 installed unless they explicitly set it in their PYTHON_TARGETS. And adding the 3.1 ABI restriction isn't *that* much work... We can kill off 3.1 sooner than we would otherwise do, but I think now is too soon, and things like removing keywords or declaring all bugs OBSOLETE are a little draconian.
*** Bug 418245 has been marked as a duplicate of this bug. ***
First of all, I do not know how it happened that I have python-3.1 installed. I don't see any PYTHON_TARGETS in my make.conf. I think I was just offered to upgrade 3.0? Further, as I did not adjust myself for 3.x I do not care about 3.1 being removed in favor of 3.2. But, I fully understand concerns if the transition requires them to do changes to some python-based tools to run on 3.2. That is not acceptable. I also foresee that people might need 3.1 to test their apps and so in general, removing any major.minor version of a DEVELOPMENT language, compiler, is really frustrating for me. I was once rejected by 'olemarkus' with php-5.2 being dropped from the tree in favor of 5.3. Be realistic, for me it means to fix some working PHP code to run under php-5.3 just because somebody wanted to drop the ebuild (security, bla bla). My answer here is clear. Rather leave the ebuild in the tree than drop it altogether. I have very much same opinion on gcc and python. Gentoo used to be an advantage as I could easily compile code using all kinds of gcc and test if some stuff can be compiled, report bugs in compiler, etc. Even worse if one has to change source code of php/python because the infrastructure does not support "old" version of a language. Gentoo is quite ahead with versions of glibc, python, gcc, etc. At the moment have need to ship binaries and looks I will have to install as oldest as possible glibc, python 2.5 or 2.6 at maximum. This is not about application. This is about core dev languages, compilers, libraries. Backwards compatibility sometimes does exist so this is a viable solution (providing binaries produced on "old" systems). In contrast, binaries from new glibc won't run for sure on old glibc-based system.
CPython upstream will provide security support for CPython 3.1 for 5 years after release of CPython 3.1, i.e. until 2014-06-27. http://www.python.org/download/releases/3.1/ Deletion of CPython 3.1 in Gentoo should not be considered before this date.
I think the Python team will decide when to remove 3.1 from the tree. The end of support from upstream will factor into it, but it will definitely not be the only deciding factor.
