On 10/4/2012 18:59, Greg Troxel wrote:
and I keep running into people treating things in pkgsrc as only existing to support other things in pkgsrc.
I suspect that's because it's easily verifiable if something is needed in pkgsrc and it's impossible to know if something is no longer needed in its own right.
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.
I am glad you like the suggestion. I think we still don't see eye to eye on this "migration" issue though. If somebody is using python2.6 for their own purposes (meaning non-pkgsrc programs) then he's lost nothing. You're clearly talking about a system with packages built with python 2.6 and the system owner switching to a new pkgsrc branch to update/add to his packages. He wouldn't have the option if we stopped building python 2.6 packages (unless he set PYTHON_VERSION_ACCEPTED I guess). I believe that risk comes with the territory of mixing branches.
However, this is a good compromise: - python2.6 exists - python2.6 packages are not built by default in bulk- The possibility exists to built packages with python 2.6 from source, but the packages are not guaranteed to build or function correctly.
Then the guy isn't "forced" to migrate, but it would be in his best interest to do so.
John