Discussion:
Removing lang/python26
r***@NetBSD.org
2014-06-17 15:32:51 UTC
Permalink
Don't remember if we discussed this before... python26 was EOL'd in 2013Q4.
Can we make 2014Q2 the last supported release of pkgsrc with py26 packages? Is
there anything barring the path forward? Ref:

http://www.python.org/dev/peps/pep-0361/
Greg Troxel
2014-06-17 15:49:22 UTC
Permalink
Post by r***@NetBSD.org
Don't remember if we discussed this before... python26 was EOL'd in 2013Q4.
Can we make 2014Q2 the last supported release of pkgsrc with py26 packages? Is
http://www.python.org/dev/peps/pep-0361/
I think it's entirely reasonable to discuss this post freeze. (The real
question is the balance of work on behalf of pkgsrc maintainers and
utility to users, and that's more complicated than just noting that
upstream has EOLed something.)

I am not in favor of making changes like this during a freeze; I don't
think there's any compelling reason to get rid of it before then. I
realize you were suggesting doing this after the freeze, but wanted to
note that.
Matthias Drochner
2014-06-18 17:05:18 UTC
Permalink
I don't think we should force people to change major versions, unless it
becomes technically impossible to support the old one.
I have myself more often abandoned (or at least stopped to update)
pkgsrc on production machines in such cases.
Wrt Python-2.6: I'm using some commercial s/w which only comes as
precompiled .pyc for 2.6, on a laptop which I'm using for daily
work. That would be the next one where I had to drop pkgsrc...

best regards
Matthias


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
OBATA Akio
2014-06-22 15:26:02 UTC
Permalink
Post by Matthias Drochner
I don't think we should force people to change major versions, unless it
becomes technically impossible to support the old one.
I have myself more often abandoned (or at least stopped to update)
pkgsrc on production machines in such cases.
Wrt Python-2.6: I'm using some commercial s/w which only comes as
precompiled .pyc for 2.6, on a laptop which I'm using for daily
work. That would be the next one where I had to drop pkgsrc...
I believe that we already have some rule about removal of pkgsrc
(package using non-redistributable distfile must have MAINTAINER,
or so one, where in documented?)

Following new rule is reasonable?
* EOL packages will be removed if no MAINTAINER.

We used to be using such rule for mysql4.
--
OBATA Akio / ***@lins.jp
Greg Troxel
2014-06-22 16:06:01 UTC
Permalink
Post by OBATA Akio
Post by Matthias Drochner
I don't think we should force people to change major versions, unless it
becomes technically impossible to support the old one.
I have myself more often abandoned (or at least stopped to update)
pkgsrc on production machines in such cases.
Wrt Python-2.6: I'm using some commercial s/w which only comes as
precompiled .pyc for 2.6, on a laptop which I'm using for daily
work. That would be the next one where I had to drop pkgsrc...
I believe that we already have some rule about removal of pkgsrc
(package using non-redistributable distfile must have MAINTAINER,
or so one, where in documented?)
Following new rule is reasonable?
* EOL packages will be removed if no MAINTAINER.
We used to be using such rule for mysql4.
I don't think this is reasonable. Having python26 sit in pkgsrc is not
causing problems -- but it seems to offend people who want to stop other
people from running software that has hit EOL. When there's actually a
problem for pkgsrc maintenance, then there will probably be broad
consensus to drop it.

Of course, there's a tradeoff between bulk build time and whether
anybody cares, which is really the question of what best serves the user
community. I don't think we have zero user interest yet, and I don't
think python26 and py26-* are a signficant usage of bulk build time.

Are you seeing the continued presence of python26 as actively causing problems? Or
are you expressing from an "EOL bad, should be removed" general
viewpoint?
OBATA Akio
2014-06-23 01:00:10 UTC
Permalink
Post by Greg Troxel
Post by OBATA Akio
Post by Matthias Drochner
I don't think we should force people to change major versions, unless it
becomes technically impossible to support the old one.
I have myself more often abandoned (or at least stopped to update)
pkgsrc on production machines in such cases.
Wrt Python-2.6: I'm using some commercial s/w which only comes as
precompiled .pyc for 2.6, on a laptop which I'm using for daily
work. That would be the next one where I had to drop pkgsrc...
I believe that we already have some rule about removal of pkgsrc
(package using non-redistributable distfile must have MAINTAINER,
or so one, where in documented?)
Following new rule is reasonable?
* EOL packages will be removed if no MAINTAINER.
We used to be using such rule for mysql4.
I don't think this is reasonable. Having python26 sit in pkgsrc is not
causing problems -- but it seems to offend people who want to stop other
people from running software that has hit EOL. When there's actually a
problem for pkgsrc maintenance, then there will probably be broad
consensus to drop it.
Of course, there's a tradeoff between bulk build time and whether
anybody cares, which is really the question of what best serves the user
community. I don't think we have zero user interest yet, and I don't
think python26 and py26-* are a signficant usage of bulk build time.
Are you seeing the continued presence of python26 as actively causing problems? Or
are you expressing from an "EOL bad, should be removed" general
viewpoint?
python24 was dropped even "It is last version for old Solaris! please keep!"
python31 wad dropped even "It is still supported by upstream, same as python26!"
...
Any particular reason to keep pytohn26?

Python-3x compatibilities of python-2.6 is lesser than python-2.7.
Then, keeping python26 reduce maintenance cost of python related packages,
take care about python26 compatibility, and introduce another trade off,
"keep package to be python-2.6 compatible? update to python-3.x compatible?"

"Dead upstream" means that we must maintain it by ourselves, require MAINTAINER
having particular reason to keep it.
--
OBATA Akio / ***@lins.jp
David Holland
2014-06-23 05:38:31 UTC
Permalink
Post by OBATA Akio
Following new rule is reasonable?
* EOL packages will be removed if no MAINTAINER.
That sounds like a good plan.

...at least, for packages like python26 where there's a different
non-EOL version in pkgsrc.

For packages where the only version is EOL or otherwise dead upstream
there's a different set of arguments and tradeoffs. :-/
--
David A. Holland
***@netbsd.org
r***@NetBSD.org
2014-07-06 00:06:16 UTC
Permalink
Post by Matthias Drochner
I don't think we should force people to change major versions, unless it
becomes technically impossible to support the old one.
I have myself more often abandoned (or at least stopped to update)
pkgsrc on production machines in such cases.
Wrt Python-2.6: I'm using some commercial s/w which only comes as
precompiled .pyc for 2.6, on a laptop which I'm using for daily
work. That would be the next one where I had to drop pkgsrc...
I'm seeing some packages dropping support for it. It's a matter of time before
it become so problematic that we're adding 26 to PYTHON_VERSIONS_INCOMPATIBLE
for a lot of packages. Look at how many py26 packages break in the bulk builds
already. We could be pro-active here and kill it this quarter.

In your case - it's VCS. You can't pull a stable tree, then pull package files
from an earlier pkgsrc version which had the packages you need?

Loading...