5 ms·

Why is Debian removing support for Python 2 at all? It's not like there are new releases they need to test against or updates they need to merge.

Denvercoder9 7y ago
Python 2 is obsolete. It won't have upstream support anymore when bullseye is released, which means that Debian has to do all the maintenance by themselves. Even if there are no updates, that still means fixing security vulnerabilities and keeping it compatible with changes in the environment (i.e. new packaging policy, new compilers, new hardening features, etc.). There's nothing to gain but work by keeping it.
rlpb 7y ago
Python 2 will not be maintained upstream beyond January 2020[1]. Therefore Debian will not include Python 2 in its next release since Python 2 will be already be EOL on the day of that next Debian release. Otherwise, who will fix the Debian Python packages when the next CVE comes out? [1] https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/
- 0xADEADBEE 7y ago
  This isn't strictly true. The final cPython release (2.7.18) is slated for April next year [0], and PyPy has no such plans to drop support [1]. I don't honestly think Python 2 is going anywhere for a while yet (judging from some of the commercial codebases I've seen at least). I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. [0] - https://www.python.org/dev/peps/pep-0373/#maintenance-releases https://www.python.org/dev/peps/pep-0373/#maintenance-releas... [1] - https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
  - rlpb 7y ago
    > The final cPython release (2.7.18) is slated for April next year [0]... Fair enough, but there is still no commitment from upstream for most of the supported release of the next Debian release, so that is moot. > ...PyPy has no such plans to drop support This isn't relevant to the CPython package dependencies which are the issue at matter for Debian on this matter. They haven't explicitly said CPython because it's implicit the way that Debian's Python packaging is structured.
  - bsder 7y ago
    > I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. There are still quite a few people running VB6 programs. Nothing helps this; there will always be laggards. If it weren't for deadlines, progress would never get made.
belorn 7y ago
A package with no active developer gets removed unless someone takes up the role of maintaining it. Since python software foundation will stop developing it there is no upstream support after 2020. In theory a new upstream for python 2 could pop up, and there is speculation that Redhat might do it, but Debian do not want to become the new upstream for python 2. If they included python 2 in next release they would have to support it for as long as next release get support. What will happen instead is that they will keep supporting python 2 in older releases but when those support periods are over then its over.
- wyldfire 7y ago
  > there is speculation that Redhat might do it If they're going to do it, for the sake of the community they should announce that soon. Even if they don't plan on taking up the responsibility until the middle or end of 2020 it might be something that distros and companies would consider when making their plans.
  - diminoten 7y ago
    They did and they have. I won't link to it because I strongly disagree with their decision to do so, but if you care about this you can find it.
- mjw1007 7y ago
  The normal thing in Debian is for a maintainer who wants to step down to orphan the package so that other maintainers get the chance to pick it up. It seems perfectly reasonable for the Debian Python team to decide they no longer want Python 2 getting in their way. But I think they should have done more to check whether someone else wants to take over. There's nothing terribly wrong with packaging mature software that doesn't have an active upstream. Realistically nobody cares about any remaining bugs in Python 2 being fixed; the work involved would basically be making sure it still compiles with newer versions of GCC.
  - Beltiras 7y ago
    There are 5 CVEs for 2.7 so far in 2019 [1]. [1]: https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/version_id-92056/year-2019/Python-Python-2.7.html https://www.cvedetails.com/vulnerability-list/vendor_id-1021...
ufo 7y ago
The Python developers will stop maintaining Python 2 very shortly https://pythonclock.org/ https://pythonclock.org/
lucb1e 7y ago
Do I understand correctly that you're asking why a distribution would remove a package at all, if it currently works just fine? The answer is mainly security issues and compatibility bugs. If a package is abandoned, it is typically removed. Someone needs to write updates both to fix newly found security problems and general issues with other new packages. Perhaps we'll switch from the init system systemd to systemf, and some package depended on that. Then it won't work in a new version anymore. Like someone else commented, it's nothing but work. I'm not sure why it is removed before any such issues arise or become known. My best guess is that it should prevent the removal from becoming super urgent once a vulnerability becomes known. If it is still used by anyone, they should either become the maintainer or (in this case the more realistic option than becoming a maintainer for python2) update the code to python3. Not sure why you're being downvoted though, it seems like a legitimate question: "it works, why bother even removing it?"
- dooglius 7y ago
  Yes, I was under the impression that distros would keep providing a lot of old packages that no one was looking at much anymore, until they actually started to cause problems.
  - _-___________-_ 7y ago
    Including it in the distro means people will use it. Since it's unmaintained, that basically assures security vulnerabilities. Avoiding this situation is one of the main reasons people use distros.
- PeterisP 7y ago
  The reason why it's removed before any such issues arise or become known is because Debian can't remove it afterwards - if they have included it in a release, they have committed to ensure that it's supported until the EOL of that release; and if noone upstream is supporting it, then it would fall upon them to provide these fixes. You can't simply remove packages from a release after it's shipped; either your release includes that package completely (including a commit to support them for the whole lifetime of your release) or not at all.

Denvercoder9 7y ago

Python 2 is obsolete. It won't have upstream support anymore when bullseye is released, which means that Debian has to do all the maintenance by themselves. Even if there are no updates, that still means fixing security vulnerabilities and keeping it compatible with changes in the environment (i.e. new packaging policy, new compilers, new hardening features, etc.). There's nothing to gain but work by keeping it.

rlpb 7y ago

Python 2 will not be maintained upstream beyond January 2020[1]. Therefore Debian will not include Python 2 in its next release since Python 2 will be already be EOL on the day of that next Debian release. Otherwise, who will fix the Debian Python packages when the next CVE comes out? [1] https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/

0xADEADBEE 7y ago
This isn't strictly true. The final cPython release (2.7.18) is slated for April next year [0], and PyPy has no such plans to drop support [1]. I don't honestly think Python 2 is going anywhere for a while yet (judging from some of the commercial codebases I've seen at least). I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. [0] - https://www.python.org/dev/peps/pep-0373/#maintenance-releases https://www.python.org/dev/peps/pep-0373/#maintenance-releas... [1] - https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
- rlpb 7y ago
  > The final cPython release (2.7.18) is slated for April next year [0]... Fair enough, but there is still no commitment from upstream for most of the supported release of the next Debian release, so that is moot. > ...PyPy has no such plans to drop support This isn't relevant to the CPython package dependencies which are the issue at matter for Debian on this matter. They haven't explicitly said CPython because it's implicit the way that Debian's Python packaging is structured.
- bsder 7y ago
  > I sometimes wonder if this mess would have dragged on quite so long if there'd been better features in Python 3. There are still quite a few people running VB6 programs. Nothing helps this; there will always be laggards. If it weren't for deadlines, progress would never get made.

belorn 7y ago

A package with no active developer gets removed unless someone takes up the role of maintaining it. Since python software foundation will stop developing it there is no upstream support after 2020. In theory a new upstream for python 2 could pop up, and there is speculation that Redhat might do it, but Debian do not want to become the new upstream for python 2. If they included python 2 in next release they would have to support it for as long as next release get support. What will happen instead is that they will keep supporting python 2 in older releases but when those support periods are over then its over.

wyldfire 7y ago
> there is speculation that Redhat might do it If they're going to do it, for the sake of the community they should announce that soon. Even if they don't plan on taking up the responsibility until the middle or end of 2020 it might be something that distros and companies would consider when making their plans.
- diminoten 7y ago
  They did and they have. I won't link to it because I strongly disagree with their decision to do so, but if you care about this you can find it.
mjw1007 7y ago
The normal thing in Debian is for a maintainer who wants to step down to orphan the package so that other maintainers get the chance to pick it up. It seems perfectly reasonable for the Debian Python team to decide they no longer want Python 2 getting in their way. But I think they should have done more to check whether someone else wants to take over. There's nothing terribly wrong with packaging mature software that doesn't have an active upstream. Realistically nobody cares about any remaining bugs in Python 2 being fixed; the work involved would basically be making sure it still compiles with newer versions of GCC.
- Beltiras 7y ago
  There are 5 CVEs for 2.7 so far in 2019 [1]. [1]: https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/version_id-92056/year-2019/Python-Python-2.7.html https://www.cvedetails.com/vulnerability-list/vendor_id-1021...

ufo 7y ago

The Python developers will stop maintaining Python 2 very shortly https://pythonclock.org/ https://pythonclock.org/

lucb1e 7y ago

Do I understand correctly that you're asking why a distribution would remove a package at all, if it currently works just fine? The answer is mainly security issues and compatibility bugs. If a package is abandoned, it is typically removed. Someone needs to write updates both to fix newly found security problems and general issues with other new packages. Perhaps we'll switch from the init system systemd to systemf, and some package depended on that. Then it won't work in a new version anymore. Like someone else commented, it's nothing but work. I'm not sure why it is removed before any such issues arise or become known. My best guess is that it should prevent the removal from becoming super urgent once a vulnerability becomes known. If it is still used by anyone, they should either become the maintainer or (in this case the more realistic option than becoming a maintainer for python2) update the code to python3. Not sure why you're being downvoted though, it seems like a legitimate question: "it works, why bother even removing it?"

dooglius 7y ago
Yes, I was under the impression that distros would keep providing a lot of old packages that no one was looking at much anymore, until they actually started to cause problems.
- _-___________-_ 7y ago
  Including it in the distro means people will use it. Since it's unmaintained, that basically assures security vulnerabilities. Avoiding this situation is one of the main reasons people use distros.
PeterisP 7y ago
The reason why it's removed before any such issues arise or become known is because Debian can't remove it afterwards - if they have included it in a release, they have committed to ensure that it's supported until the EOL of that release; and if noone upstream is supporting it, then it would fall upon them to provide these fixes. You can't simply remove packages from a release after it's shipped; either your release includes that package completely (including a commit to support them for the whole lifetime of your release) or not at all.