Thomas Klausner <wiz%NetBSD.org@localhost> writes: > On Thu, Oct 04, 2012 at 08:59:12AM +0200, John Marino wrote: >> After I mentioned last week that Python 25 was going away, a >> DragonFly user asked me on IRC what the justification for keeping >> Python26 in pkgsrc was. Apparently there is very little API >> difference between 2.6 and 2.7.x, and likely all packages that build >> for 2.6 would build for 2.7 (perhaps with minor tweaks in a very few >> cases). >> >> I couldn't answer him, but I think it's a good question. What is >> the justification for python 2.6 especially given python 2.7.x will >> be a very long term version? > > Good question. > > pkgsrc itself currently has three packages that claim to only work > with python26, but these claims could of course be outdated (I haven't > checked them): > > lang/py-psyco/Makefile:PYTHON_VERSIONS_ACCEPTED= 26 > sysutils/salt/Makefile:PYTHON_VERSIONS_ACCEPTED= 26 > textproc/py-pdf-parser/Makefile:PYTHON_VERSIONS_ACCEPTED= 26 > > Python org claims they will provide security fixes for it until > October 2013, but we can of course deprecate it earlier. Here we cross the tricky line from "upstream does not maintain it, so it's definitely crufty" into "I don't see why someone else should not have moved from 2.6 to 2.7, so let's nuke it". As always, we don't know what people are doing that isn't in pkgsrc (using python from pkgsrc). And migrating systems takes time - I know of multiple boxes with 26 in use, even though they could be rebuilt to 27. Right now I don't see what harm python26's continued presence is causing, and I object to a general approach of "I don't use that any more so let's delete it". So if we want to announce that it will be moved after 2013Q2 is cut, to avoid having a branch or head with a version not supported upstream, that seems sensible. But I don't see any justification for rushing into it now.
Attachment:
pgpeFelo7P7MQ.pgp
Description: PGP signature