> > What exactly is it blocking? > > It blocks reverse deps from removing their Python 2 packages (or if > Py2-specific the package at large), which in turn block the removal > of other packages. > > In the case of bkchem python-pil and python-pmw, which in turn block > the removal of python-tk.
As bkchem is no longer in testing and the Python 2 version of bkchem can *never* migrate back to testing, these rdeps can now drop their Python 2 packages without making testing more buggy. * python-pil is already only cruft and is not in testing. * python-pmw can also be removed from testing now as it has no rdeps in testing and will be autoremoved soon; it may as well be removed from the archive entirely, unless someone wants to upgrade it to the Python 3 version just for the fun of it. (This has been the standard practice throughout the process of removing Python 2 and is the reason why the bugs are slowly elevated in severity; ideally, we never get as far as breaking packages that are in unstable but that is not a hard requirement in *any* transition, much less big and messy one like this.) The Python 2 version of bkchem will not be released with bullseye, so we may as well make it easier for those trying to do other things for the bullseye release. *If* a Python 3 version of bkchem appears we can get it into bullseye. I doubt that is ever going to appear, however, as that effort is tangled with several other changes to modules that bkchem currently ships embedded copies of; a py3-bkchem therefore needs to catch up with changes to other modules as well as port to Python 3. All this without a test suite to help catch the inevitable porting problems. I say this as a bkchem user who doesn't have a good Plan B :( regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ [email protected] Debian Developer http://www.debian.org/ [email protected] GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
