Differences between revisions 15 and 26 (spanning 11 versions)
Revision 15 as of 2019-10-15 19:39:30
Size: 4452
Editor: ?Thomas Goirand
Comment:
Revision 26 as of 2020-02-11 11:54:08
Size: 6237
Editor: AnthonyFok
Comment: Fix typo: it's → its
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
== 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 its 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.

Line 14: Line 29:
 * port upstream package to python3 (or file upstream bug): make sure package doesn't call `python` at build- or compile time (as here won't be a python package and no `python` command in bullsey, only `python3`.)
 * check `apt rdepends python-foo` and … TODO: build-depends (`reverse-depends -b python-foo` from ubuntu-dev-tools package?).
   NOTE: If there are reverse dependencies, you cannot remove it yet!
 * remove python-foo and pypy-foo from debian/control
   NOTE: If python-foo installed a /usr/bin/foo, then python3-foo must now begin installing one.
 * remove python-foo and pypy-foo from debian/rules
 * remove ''--with python2'' from debian/rules if your package didn't use dh-sequence-python2 build dependency
 * remove python-foo and pypy-foo from debian/tests
 * 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/*)
Line 23: Line 39:
   (do '''not''' remove python-foo-doc or rename it to python3-foo-doc)    * the contents of python-foo-doc will automatically move from /usr/share/doc/python-foo to /usr/share/doc/python-foo-doc - update any links to it, [[https://bugs.debian.org/945501|remembering to use symlink_to_dir when overwriting a link with a real directory]]
   * do '''not''' remove python-foo-doc
   * do '''not''' rename it to python3-foo-doc
Line 26: Line 44:
   do not close the bug in the changelog (exception: applications moving to Python 3)
Line 30: Line 47:
 * reassign py2removal bug to ftp.debian.org pseudo package, rename it to "FIXME: proper title to remove binary package only"  * --(reassign py2removal bug to ftp.debian.org pseudo package)--[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933034#22|not any more]]
Line 32: Line 49:
== Suggested commands for also finding autopkgtests == == 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.
Line 37: Line 56:
Where $module is *binary* package name. Here python-$module is a ''binary'' package name.
Line 40: Line 59:
grep-dctrl -w -F Depends,Recommends -s Source "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
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
Line 46: Line 63:
Outputs only this package's source name => ready to be removed
Outputs other source package(s) => not ready yet
Outputs nothing => package doesn't exist (either it's already been
removed, or you mis-spelt it)
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)
Line 51: Line 68:
apt-cache rdepends python-$module can slow and does not find autopkgtest depends.

(Suggested by Rebecca Palmer on the debian-python mailing list)
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.
Line 56: Line 71:

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.
Line 83: Line 100:

== 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.

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 its 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.