Hacker News Reader

Comment by dooglius | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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.

There are 5 CVEs for 2.7 so far in 2019 [1].

[1]: https://www.cvedetails.com/vulnerability-list/vendor_id-1021...

Yes, I think whoever ends up taking over Python 2 maintenance would be well advised to stub out the https support immediately, and maybe a bit later do the same for all support for network requests.

In particular, you don't want to have to worry about building against openssl.

I think the vast majority of cases where people have a good reason to carry on using Python 2 won't need that.

Is there any evidence that people are regularly checking whether software has been abandoned, and those packages removed? It seems more plausible to me that this was an excuse to replace the default 'python' with Python 3.

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?"

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.

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.

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.

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/

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-releas...

[1] - https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...

> 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.

> 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.

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.

The Python developers will stop maintaining Python 2 very shortly

https://pythonclock.org/

Reply on news.ycombinator.com