Skip to content

policy: Expand the section about package names

Simon McVittie requested to merge smcv/python3-defaults:bug791635 into master

  • policy: Give advice about the source package name

    For source packages, I think we have rough consensus that package names that could collide with other ecosystems should have a python- prefix (python-build, python-keyring and python-packaging are good examples), but package names that are already distinctively Python do not need a redundant prefix. Let's say so. This is not exactly what Guillem was originally asking for in #791635, but I think it's the furthest step in that direction that has consensus.

    Based on pushback in #791635 I'm making it explicit that existing source packages are not expected to be renamed to follow this naming convention if their maintainers don't want to.

    Closes: #791635

  • policy: Mention the former Python 2 package naming convention

    Since commit a8645f29 "Update the Python policy for the Python2 removal" (#943666), the text starts talking about runtime separation between Python 2 and 3 modules, but then goes on to describe only the Python 3 naming convention, which reads a little oddly. A brief mention of the Python 2 naming convention here will resolve the dangling reference to Python 2.

    Helps: #791635

  • policy: Mention -common, -data and similar additional binary packages

    If these were shared between Python 2 and 3, or would be shared between Python 3 and a hypothetical Python 4, then they can safely follow the same naming convention as -doc packages. This matches current practice for packages like python-apt-common and python-dmidecode-data.

    Helps: #791635

  • policy: Give some concrete examples of typical naming conventions

    Helps: #791635

Prompted by recent discussion on the debian-python mailing list.

Merge request reports