John Marino <netbsd%marino.st@localhost> writes: > On 10/4/2012 18:24, Greg Troxel wrote: >> >> 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. > > I see this as mixing concepts. > One concept is using python for purposes not related to pkgsrc and the > other concept is using a specific version python to build specific > packages that can't be built with anything else. > > For the latter concept, there's no problem at all deleting python2.6 > if nothing requires it. There are indeed two concepts. One is that the purpose of pkgsrc is to provide a way to build code for people that need it. The other is that having A in pkgsrc often requires B. The mixing is to say A requires B (and nothing else in pkgsrc depends on B) we don't need A, or have removed it therefore there is no reason to keep B, because only A depended on it and it's gone but that doesn't address is the user community better served by the presence of B, because it is used in its own right and I keep running into people treating things in pkgsrc as only existing to support other things in pkgsrc. > For the former concept, you can make the same argument about python2.4. Yes. But the balance is the usefulness of it combined with the issues. There's a general principle that we remove things that have a successor and for which upstream does not do security maintainance. The key question is whether you can say to someone "It's really not reasonable or responsible for you to be running python2.4, and we're not going to help you do it". For 2.4, I think that's been true, and for 2.5 it seems like now is a fine time to say that. I don't think it's close to true for 2.6, which is getting upstream security updates. > As I understand it, pkgsrc is segmented into "branches" so each branch > should be self-contained and also to provide a guarantee that with > this infrastructure, that package will build. "Migration" is only a > problem if you start mixing branches, but that is specifically not > supported (or do at your own risk). > > >> 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". > > > Correction: PKGSRC doesn't need it anymore, it has a more modern > replacement. pkgsrc is a provider of things that meets needs, not a source of needs. > I object to needless versions of the same package. I would not object > to python2.6 if it didn't spawn packages. Can multiversion be > modified to build python2.6 without building python2.6-based packages? > Then everybody wins. That's an excellent suggstion. If we had a way to leave 26 and leave the py26- things buildable, but not automatically build py26-foo for all foo during bulk builds, that would be a reasonable intermediate step. To do that, we still have to be able to say in good faith to anyone running 26: You really should just switch to 27 right now, and there's no reason that should be expected to be difficult (or at least any more than it would be in a year). I'm not sure that's true, and I suspect we can't really say that yet.
Attachment:
pgpq006L5rb0u.pgp
Description: PGP signature