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
