Differences between revisions 23 and 24
Revision 23 as of 2019-11-26 20:04:05
Size: 6106
Editor: ?RebeccaPalmer
Comment: add symlink_to_dir note + cleanup
Revision 24 as of 2019-11-29 00:21:40
Size: 6222
Comment: Add /usr/bin/foo disappeared in when python-foo is removed to common mistakes (I've seen it twice)
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
 * Forgetting to instruct python3-foo to install /usr/bin/foo when python2-foo previously provided this interface.

Python 2 / PyPy removal help page

Announcement: https://lists.debian.org/debian-python/2019/07/msg00080.html

Transition: https://release.debian.org/transitions/html/python2-rm.html

Fedora: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

Python 2 Countdown: https://pythonclock.org/

Common mistakes made when removing Python2 packages

Here are some issues seen for ongoing removal of Python2 packages:

  • Removing a python-foo package without checking for it's reverse dependencies first. The py2removal bugs even show you that kind of information.
  • Forgetting to adjust autopkg tests:
    • Not removing autopkg tests for python2, when the python-foo package is removed.
    • Not changing the interpreter name from python to python2 in autopkg tests, when still keeping the Python2 package.
  • Not renaming python-foo to python3-foo, but building it with Python3.
  • Forgetting to instruct python3-foo to install /usr/bin/foo when python2-foo previously provided this interface.

Check list

Quick list of things to do while removing Python / ?PyPy binary package:

  • port upstream package to python3 (or file upstream bug): make sure package doesn't call python at build- or compile time (as there won't be a python package and no python command in bullseye, only python3.)

  • check for reverse dependencies (including build-depends)
    • if there are any, you cannot remove it yet!

    • if you decide to prepare the removal now and upload it later, post a message stating this to the py2removal bug, to avoid duplication of work. (However, for typical packages, the removal process is simple enough that this is unnecessary.)
  • remove python-foo and pypy-foo binary packages from debian/control
  • remove python-* Build-Depends from debian/control
  • if python-foo installed a /usr/bin/foo, then python3-foo must now begin installing one
  • remove any Python 2 use (e.g. --with python2) or python-foo / pypy-foo references from debian/rules

  • remove python-foo and pypy-foo autopkgtests (debian/tests/*)
  • if documentation was in python-foo - move it to python3-foo or python-foo-doc
  • check/remove debian/python-foo.* and pypy-foo.* files
  • mention Python 2 / ?PyPy removal in debian/changelog

  • build the source package
  • test it
  • upload it to unstable
  • reassign py2removal bug to ftp.debian.org pseudo packagenot any more

How to check for reverse dependencies

For a quick initial check / if you're looking for a package to work on, see http://sandrotosi.me/debian/py2removal/index.html: look for binary (not source) packages with 0 in the rdeps column.

To search for all runtime Depends/Recommends, and all mentions in the Sources index (Build-Depends*, Testsuite-Triggers, and the package itself):

Here python-$module is a binary package name.

grep-dctrl -w -F Pre-Depends,Depends,Recommends -s Package "python-$module" /var/lib/apt/lists/*_debian_dists_{unstable,sid}_main_binary-amd64_Packages 
grep-dctrl -w -s Package "python-$module" /var/lib/apt/lists/*_debian_dists_{unstable,sid}_main_source_Sources

Outputs:

  • only this package's name => ready to be removed

  • other package(s) => not ready yet

  • nothing => package doesn't exist (either it's already been removed, or you mis-spelt it)

The alternative of "apt-cache rdepends python-$module ; reverse-depends -b python-$module" (ubuntu-dev-tools package) can be slow and does not find autopkgtest depends.

usertags (debian-python@lists.debian.org)

PLEASE, when changing user tags, please CC the bug report, because it's non-obvious who is changing a user tag by reading the bug report.

Every package should be tagged with:

  • py2removal - all packages affected by Python 2 / ?PyPy removal

Add more tags for better classifications:

  • py2leaf - leaf package ready to be removed, i.e. without (build-)dependencies

    • (including Recommends) in Debian main,
  • py3available - Python 3 support is available upstream, package needs an

    • update in Debian,
  • py3noport - there's no upstream support for Python 3, needs a port done by us

    • or package will be removed,
  • py2keep - package that should not be removed for now (popcon >1000 by

    • default). Please don't add this usertag without discussing it on the mailing list first,
  • py2rm - packages that we will remove from Debian due to low popcon, etc.

    • - all packages with popcon <300 will get this one by default, but it can be removed

FAQ

My package is affected only because it uses python-sphinx to generate documentation, what should I do?

just replace it with python3-sphinx, and in debian/rules, you can invoke Sphinx this way (the team do not recommand using the 'sphinx-build' command):

python3 -m sphinx

Discussions/Proposals

>  - bumping lintian info to warn, warn to error, ask ftp-master
>    to autoreject packages for some errors?
  • Likely to get pushback from ftp-master; notwithstanding the problems and advantages of removing Python2, autorejects should be for really rather severe issues IMHO.