Web lists-archives.com

Re: Please do not drop Python 2 modules




On Sat, Apr 21, 2018 at 08:57:55PM +0300, Adrian Bunk wrote:
> The tip of the iceberg are some recent cases where Python 2 modules
> were dropped that still had reverse dependencies in unstable, but
> also for those without there will in many cases be users who will
> still need these modules in buster.

We had this discussion on IRC recently and there consensus of a
significant portion of participants was in favour of keeping Python 2
modules. The major theme was leaving the choice to users and use cases
that depend on other software not packaged for Debian.

Actually removing Python 2 modules is a rather easy task in most cases:
You drop the binary package. I'm confident that we'll easily be able to
drop all Python 2 modules after buster with little problems. The problem
is with rdeps. What is much harder is switching applications from Python
2 to Python 3. Also moving applications from Python 2 to Python 3 is
something we can and should do in time for buster as much as possible.
In some cases (e.g. gimp) it can be difficult or impossible, but it is
something that should be worked on now or removing Python 2 after buster
will be painful. Switching applications also means that many
installations will be able to do without a (potentially) poorly
supported Python release. In my opinion, removing Python 2 from the most
common default installations would be useful.

Thus let me propose adding a new lintian tag for non-module packages
that depend on Python 2 and kindly ask them to switch to Python 3. Such
a tag can very well be a warning today. It would hit around 800 binary
packages at present. I'd love to see that number go down to around 100
when buster is released.

Do people agree that such a tag would be useful?

Other than that, I think the discussion is quite similar to the one
about dropping init scripts after stretch. We resolved, yes keep them
unless you know that they don't work at all. Can we simply do the same
for Python 2 modules?

> All of the above applies especially in cases where continuing to
> provide a Python 2 module does not cause problems or extra work
> (in several cases Python 2 modules were dropped in a new Debian
>  revision of a package without any real reason).

I actually face the issue you are trying to exclude here. You likely
know that I work on making packages cross-buildable and I do not stop at
python extensions. As it happens, cross building extensions tends to
work for Python 3, but not for Python 2 these days. Now I am faced with
a choice:
 * Ask for removing Python 2 extensions to make packages cross
   buildable.
 * Produce patches for the deprecated Python 2 and ask the Python
   maintainer to take them while knowing that they cannot be upstreamed.
 * Insert a new nopython2 build profile to allow building without Python
   2.
 * Wait for the problem to solve itself after buster.

I tend to use the last option, but the pile is ever increasing. What do
you suggest here?

So yes, not dropping Python 2 extensions makes my work harder and yes, I
am in favour of keeping them for buster anyway.

Helmut