Severity issues raised for Python 2 Debian packages for not supporting Python 3

On Monday, Neil Williams a software developer from Linux CodeHelp raised severity issues for Python 2 leaf packages in Debian which do not support Python 3. Neil has urged Debian maintainers to remove Python 2 from all the Debian packages.

He specifically mentions one of the packages, Calibre, an e-book management software which is completely open source and licensed under the GNU GPL v3. Calibre is written primarily in Python with some C/C++ code for speed and system interfacing. But it is not yet compatible with Python 3 as it requires at least Python 2.7.9.

In 2017, an issue was raised on the Calibre platform by a user, “Python 2 is retiring in thirty months. Calibre needs to convert to Python 3.” Kovid Goyal, author of the Calibre platform responded saying, “No, it doesn't. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.” Now the latest Calibre version requires Python modules which are no longer available for Python 2.

Gregor Riepl, a systems engineer in response to Neil says, “As of now, calibre is not of sufficient quality to be part of a Debian release and until it drops all Python2 requirements, it must be considered RC buggy.”

This means that Calibre >= 4.0 for the foreseeable future will not be available in Debian. Calibre version 3.48 will be the last version that can run on Debian until the upstream Calibre switches to Python 3.

Riepl further asked Neil if his quality argument is due to the Calibre authors resistance to migrate to Python 3. Neil responded, “No, it is based just on the removal of Python2 from Debian and avoiding special cases. Right now, any and every package in Debian testing which requires Python2 and has no Python3 alternative in Debian or ready for upload is of poor quality for no other reason than that. All such packages are of such poor quality that the package should be removed from testing - in an orderly manner, leaf packages first. That is in the best interests of all users, despite what may or may not happen to any particular subset(s) of users.

The decision flow is easy - if the answer in each case is "no", then move on to the next and if you get to the bottom, the bug should be RC.

* Has the package already been removed from testing?

* Is a Python3-only version already in Debian?

* Is a Python3-only version available upstream?

* Does the package have any reverse dependencies?

* If you get here, it is already too late, there have already been

enough warnings. Upgrade the bug to RC and get the package

auto-removed from testing.”

Neil said he was aware of the history of Calibre and understood what would happen if it is no longer a part of Debian. But that did not matter as removal of Python 2 is more important for the next Debian release. He also believes that Calibre has a relatively large user base that doesn't know much or care about the Python 2 deprecation. User will simply perceive dropping Calibre as a bad move on Debian's side and rush towards other packages of significantly lower quality.

He further concluded, “Calibre is nothing special - it's a Python2 leaf package like vland and tftpy and any one of far too many others. Calibre can stay in unstable - it will go FTBFS, of course, but that isn't a problem either, IMHO. It's calibre's problem - not Debian's problem. There's always the option of users installing the old Python2 stuff from Buster to keep calibre hobbling along.

Debian is the higher priority here. Calibre would be nice to have but it does not deserve to cause delays on anybody else's voluntary effort. No package has that right.”

Community feels Python 2 will result in unmaintained runtime and libraries in packages

On Hacker News, users are discussing how Python foundation is pushing in packages to migrate to Python 3 that will result in Python 2 having an entire set of unmaintained runtime and libraries in the package repository. One user comments, “Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support.

I doubt anyone is checking for potential security problems in Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that.

It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran.

In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.”

Another user responded, “This isn't about "languages". It's about software!

Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repository. Starting very soon - Python 2 will have an entire set of unmaintained runtime and libraries in the package repository. You know - actual, officially, unmaintained software! Unmaintained software that other packages, including Calibre in this example, further build on. Of course they're throwing this out.”