On 03.11.19 13:10, Neil Williams wrote:
On Wed, 30 Oct 2019 16:44:24 +0100 Matthias Klose <[email protected]> wrote:
On 27.10.19 17:59, Neil Williams wrote:
Package: python3
Version: 3.7.5-1
Severity: normal
As discussed on IRC and alongside the post to debian-devel-announce, please
review and include this amendment to the Debian Python Policy to cover
the removal of the Python 2 stack as outlined at
https://wiki.debian.org/Python/2Removal
thanks for doing that. I think we should make it more clear that there will no
python binary package, and no python command in bullseye. You adjusted the
names, but are still talking about "should" in some place. If we end up with
some remaining python 2 packages, then these must depend on python2,
python2-dbg, and must use the python2 command.
OK, I've updated MR 1 with changes along those lines.
https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/1
ok, commenting here in the bug report:
diff --git a/debian/python-policy.dbk b/debian/python-policy.dbk
index
42051b3b20804d02b42195a61aaf5736a8c3f8dc..bc2708426848f651998618723f95447e11635254
100644
--- a/debian/python-policy.dbk
+++ b/debian/python-policy.dbk
@@ -75,12 +79,12 @@
</para>
</legalnotice>
</bookinfo><chapter id="python3">
- <title>On the move to Python 3</title>
+ <title>Completing the move to Python 3</title>
<para>
- Debian currently supports two Python stacks, one for Python 3
- and one for Python 2. The long term goal for Debian is to
- reduce this to one stack, dropping the Python 2 stack at some
- time.
+ Debian has previously supported two Python stacks, one for Python 3
+ and one for Python 2. The goal for Debian is to reduce this
+ to one stack, dropping the Python 2 stack and intepreter for
+ the Bullseye release.
</para>
<para>
<ulink url="https://www.python.org/dev/peps/pep-0404/";
TYPO "intepreter"
@@ -91,32 +95,33 @@
>PEP 466</ulink>.
</para>
<para>
- Packages in Debian should use Python 3 if Python 3 is
- supported. New packages should use Python 3 from the initial
- upload, new upstream versions for existing packages should
- use Python 3 if the new upstream version supports it.
+ Packages in Debian must use Python 3. New packages must
+ use Python 3 from the initial upload, new upstream versions
+ for existing packages should must use Python 3.
</para>
TYPO "should must"
Wouldn't we disallow any Python2 package with this change?
<para><orderedlist>
<listitem>
<para>
- Programs should use Python 3, and should not be packaged
- for Python 2 as well. Python 3 should be used for the
- packaging if the packaging scripts use Python.
+ Applications must use Python 3, and should not be packaged
+ for Python 2 as well. If an application supports only
+ Python 2, the application will need to be removed from
+ Debian so that it does not block removal of other Python 2
+ packages.
I think this is a bit premature. I don't agree with the py2keep tag filed for
mercurial, but maybe there will be another application which will not exist for
Python 2 for the time of the bullseye release.
</para>
</listitem>
<listitem>
<para>
- Python libraries, if they support Python 3, should be always
- packaged for Python 3. If an application supports only Python
- 2, the Python libraries for that application should also be
- packaged for Python 2.
+ Python libraries need to support Python 3 and new versions
+ must be packaged for Python 3. Existing Python 2 libraries
+ must not be dropped before the last reverse dependency is
+ removed. New Python 2 libraries must not be introduced.
</para>
</listitem>
<listitem>
<para>
- Existing Python 2 libraries should not be dropped before
- the last reverse dependency is removed.
+ Python 3 should be used for the packaging if the
+ packaging scripts use Python.
</para>
</listitem>
</orderedlist></para>
@@ -131,9 +136,10 @@
At any given time, the binary package <literal>python3</literal>
will represent the current default Debian Python 3 version; the
binary package <literal>python</literal> will represent the
- current default Debian Python 2 version. As far as is reasonable,
- Python 3 and Python 2 should be treated as separate runtime
- systems with minimal interdependencies.
+ current default Debian Python 2 version, for as long as it
+ exists. As far as is reasonable, Python 3 and Python 2 should
+ be treated as separate runtime systems with minimal
+ interdependencies.
</para>
<para>
In some cases, Python policy explicitly references Python helper
@@ -251,25 +257,26 @@
3.<replaceable>Y+1</replaceable>.
</para>
<para>
- At any time, the <literal>python</literal> binary package must
+ The <literal>python</literal> and <literal>python-dbg</literal>
+ binary packages are to be removed for Bullseye. If any Python 2
+ packages remain in Bullseye, these must depend on
+ <literal>python2</literal> or <literal>python2-dbg</literal>.
+ The <literal>python2</literal> package must depend on the
+ <literal>python2.<replaceable>Y</replaceable></literal>
+ package that installs the executable
<filename>/usr/bin/python2</filename>.
+ The version of the <literal>python2</literal> package must be
+ greater than or equal to 2.<replaceable>Y</replaceable> and lower than
+ 2.<replaceable>Y+1</replaceable>.
+ The <literal>python2</literal> must not provide
<filename>/usr/bin/python</filename>.
+ </para>
yes, thanks for this clarification.
+ <para>
+ For as long as it remains supported, the <literal>python</literal> binary
package must
ensure that <filename>/usr/bin/python2</filename> is provided, as a
symlink to the current
<filename>python2.<replaceable>Y</replaceable></filename>
executable. The package must depend on
the <literal>python2.<replaceable>Y</replaceable></literal> package that
installs
the executable.
</para>
- <para>
- The version of the <literal>python</literal> package must be
- greater than or equal to 2.<replaceable>Y</replaceable> and lower than
- 2.<replaceable>Y+1</replaceable>.
- </para>
- <para>
- The <literal>python</literal> binary package must also ensure
- that <filename>/usr/bin/python</filename> is provided, as a symlink
to the
- current <filename>python2.<replaceable>Y</replaceable></filename>
executable. See
- <ulink url="https://www.python.org/dev/peps/pep-0394/";
->PEP 394</ulink> for details.
- </para>
While I would like that change, just removing it would allow pointing the python
package to python3. This isn't seen so by everybody, so please keep this
paragraph, and maybe address this later.
</section>
<section id="minimal">
@@ -296,12 +303,14 @@
</para>
<para>
Python scripts that require the default Python 2 version should
- specify <filename>python2</filename> as the interpreter name.
+ specify <filename>python2</filename> as the interpreter name
+ for as long as this remains supported.
</para>
<para>
- Python scripts may specify <filename>python</filename> as the
- interpreter name only if they do not require any particular
- version of Python. (Note: this means any python2 version)
+ Python scripts should not specify <filename>python</filename> as the
+ interpreter name even if they do not require any particular
+ version of Python as the script would stop working upon removal
+ of the Python 2 stack.
</para>
<para>
Python scripts that only work with a specific Python minor
@@ -329,8 +338,10 @@
2.<replaceable>Y</replaceable>).
</para>
<para>
- Scripts requiring the default Python 2 version may instead
- specify the interpreter <filename>/usr/bin/python</filename>.
+ Scripts requiring the default Python 2 version must not
+ specify the interpreter <filename>/usr/bin/python</filename>
+ as such scripts will fail when the unversioned interpreter
+ binary <filename>/usr/bin/python</filename> is removed.
</para>
<para>
Maintainers should not override the Debian Python interpreter
@@ -409,7 +420,7 @@
<section id="runtimes_hooks">
<title>Hooks for updates to installed runtimes</title>
<para>
- The <literal>python</literal> binary package has special hooks to
+ The <literal>python3</literal> binary package has special hooks to
allow other packages to act upon updates to the installed
runtimes.
</para>
@@ -427,8 +438,7 @@
<para><orderedlist>
<listitem>
<para>
- <filename>/usr/share/python3/runtime.d/*.rtinstall</filename>,
- <filename>/usr/share/python/runtime.d/*.rtinstall</filename>:
These
+ <filename>/usr/share/python3/runtime.d/*.rtinstall</filename>:
These
are called when a runtime is installed or becomes supported.
The first argument is <literal>rtinstall</literal>, the second
argument
is the affected runtime (for
@@ -440,8 +450,7 @@
</listitem>
<listitem>
<para>
- <filename>/usr/share/python3/runtime.d/*.rtremove</filename>,
- <filename>/usr/share/python/runtime.d/*.rtremove</filename>:
These are
+ <filename>/usr/share/python3/runtime.d/*.rtremove</filename>:
These are
called when a runtime is removed or stops being supported. The
first argument is <literal>rtremove</literal>, and the second
argument
is the affected runtime (for
@@ -450,8 +459,7 @@
</listitem>
<listitem>
<para>
- <filename>/usr/share/python3/runtime.d/*.rtupdate</filename>,
- <filename>/usr/share/python/runtime.d/*.rtupdate</filename>:
These are
+ <filename>/usr/share/python3/runtime.d/*.rtupdate</filename>:
These are
called when the default runtime changes. The first argument is
either <literal>pre-rtupdate</literal>, called before changing the
default runtime, or <literal>rtupdate</literal>, called when
changing
@@ -475,8 +483,10 @@
<para>
The binary package <literal>python3-doc</literal> will always
provide the documentation for the default Debian Python 3 version.
- The binary package <literal>python-doc</literal> will always
- provide the documentation for the default Debian Python 2 version.
+ The binary package <literal>python-doc</literal> may
+ provide the documentation for the default Debian Python 2, or
+ the default Debian Python 3 version if no Python 2 binary
+ is built.
hmm, up to now I thought to remove python-doc together with python and
python-dbg. So build python-doc now from python3-defaults and let it depend on
python3-doc?
</para>
<para>
TODO: Policy for documentation of third party packages.
@@ -581,22 +591,19 @@
<section id="package_names">
<title>Module Package Names</title>
<para>
- Public Python modules must be packages separately by major Python
+ Public Python modules must be packaged separately by major Python
version, to preserve run time separation between Python 2 and
Python 3.
</para>
<para>
Public Python 3 modules used by other packages must have their
binary package name prefixed with <literal>python3-</literal>.
- Public Python 2 modules used by other packages must have their
- binary package name prefixed with <literal>python-</literal>.
It is recommended to use this prefix for all packages with public
modules as they may be used by other packages in the future.
</para>
<para>
The binary package for module <replaceable>foo</replaceable> should
preferably be
- named <literal>python3-<replaceable>foo</replaceable></literal> (for
Python 3)
- or <literal>python-<replaceable>foo</replaceable></literal> (for Python 2),
if the
+ named <literal>python3-<replaceable>foo</replaceable></literal>, if
the
module name allows. This is not required if the binary package
installs multiple modules, in which case the maintainer shall
choose the name of the module which best represents the package.
@@ -604,8 +611,7 @@
<para>
For subpackages such as <replaceable>foo.bar</replaceable>, the
recommendation is
to name the binary
- package <literal>python3-<replaceable>foo.bar</replaceable></literal> (for
Python
- 3) or <literal>python-<replaceable>foo.bar</replaceable></literal> (for
Python 2).
+ package <literal>python3-<replaceable>foo.bar</replaceable></literal>.
</para>
<para>
Such a package should support the current Debian Python version,
@@ -622,12 +628,11 @@ import foo
versions should be included in a single package.
</para>
<para>
- Packages intended for use with Django
(<literal>python3-django</literal>/
- <literal>python-django</literal>) are installed in the same
namespace as
- other python packages for a variety of reasons. Many such packages
are
+ Packages intended for use with Django
(<literal>python3-django</literal>
+ are installed in the same namespace as other python packages
+ for a variety of reasons. Many such packages are
named django_$name upstream. These are then packaged as
- <literal>python3-django-$name</literal> and
- <literal>python-django-$name</literal>.
+ <literal>python3-django-$name</literal>.
This makes it clear that they are intended for use with Django
and not general purpose Python modules. Debian maintainers are
encouraged to work with their upstreams to support consistent use of
@@ -650,7 +655,7 @@ import foo
Similarly, the optional fields <literal>X-Python-Version</literal>
or <literal>XS-Python-Version</literal> were used to specify the
versions of
Python 2 supported by the source package. They are obsolete and
- can be removed now that only Python 2.7 is supported.
+ must be removed.
</para>
<para>
These fields are used by some packaging scripts to automatically
@@ -660,15 +665,13 @@ import foo
X-Python3-Version: >= X.Y
X-Python3-Version: >= A.B, << X.Y
XS-Python-Version: A.B, X.Y
-XS-Python-Version: all
</programlisting>
</para>
<para>
- The keyword <literal>all</literal> means that the package supports any
- Python 2 version available but might be deprecated in the future
+ The keyword <literal>all</literal> is no longer to be used
since using version numbers is clearer than <literal>all</literal> and
- encodes more information. The keyword <literal>all</literal> is
limited to
- Python 2 versions and must be ignored for Python 3 versions.
+ encodes more information. The keyword <literal>all</literal>
+ must be ignored for Python 3 versions.
</para>
<para>
A comma-separated list of multiple individual versions
@@ -679,10 +682,8 @@ XS-Python-Version: all
later releases.
</para>
<para>
- The keyword <literal>current</literal> has been deprecated and used
to mean
- that the package would only have to support a single Python 2
- version (even across default version changes). It must be ignored
- for Python 3 versions.
+ The keyword <literal>current</literal> has been deprecated and must
+ not be used. It must be ignored for Python 3 versions.
</para>
<para>
The use of <literal>XB-Python-Version</literal> in the binary package
@@ -711,9 +712,9 @@ XS-Python-Version: all
corresponding <literal>python3-<replaceable>foo</replaceable></literal>
packages.
</para>
<para>
- For Python 2, the correct dependencies are <literal>Depends:
- python (>= 2.<replaceable>Y</replaceable>)</literal> and any
- corresponding
<literal>python-<replaceable>foo</replaceable></literal> packages.
+ If any Python 2 packages remain, the correct dependencies are
<literal>Depends:
+ python2 (>= 2.<replaceable>Y</replaceable>)</literal> and any
+ corresponding <literal>python2-<replaceable>foo</replaceable></literal>
packages.
</para>
<para>
Any package that installs Python modules or Python 3 binary
@@ -730,10 +731,10 @@ XS-Python-Version: all
<para>
Binary packages that declare Provides dependencies of the form
<literal>python<replaceable>X</replaceable>.<replaceable>Y</replaceable>-<replaceable>foo</replaceable></literal>
- were never supported for Python 3 and are no longer useful for
- Python 2. They should be removed in the normal course of package
- updates. Future provision of values for the substituation variable
- <literal>python:Provides</literal> is not guaranteed.
+ were never supported for Python 3. They should be removed in
+ the normal course of package updates. Future provision of
+ values for the substituation variable
<literal>python:Provides</literal>
+ is not guaranteed.
</para>
</section>
@@ -782,7 +783,7 @@ XS-Python-Version: all
<title>Interpreter directive (“Shebang”)</title>
<para>
Executables written for interpretation by Python must use an
- appropraite interpreter directive, or “shebang”, as the first line
+ appropriate interpreter directive, or “shebang”, as the first line
of the program. This line should be of the
form
<literal>#!<replaceable>interpreter_location</replaceable></literal>.
See <xref linkend="interpreter_name"/> for the interpreter name to
use.
@@ -819,8 +820,8 @@ XS-Python-Version: all
<title>Programs Shipping Private Modules</title>
<para>
A program that specifies <filename>python3</filename>
- or <filename>python</filename> as its interpreter may require its
own
- private Python modules. These modules should be installed
+ as its interpreter may require its own private Python modules.
+ These modules should be installed
in
<filename>/usr/share/<replaceable>module</replaceable></filename>, or
<filename>/usr/lib/<replaceable>module</replaceable></filename> if the
modules are
architecture-dependent (e.g. extensions).
@@ -926,7 +927,7 @@ XS-Python-Version: all
dependency on the <literal>-dev</literal> packages, and declare
<literal>Build-Depends</literal> on the runtime environment only
(<literal>python3</literal>, <literal>python3-all</literal>,
- <literal>python</literal>, <literal>python-all</literal>). A package
+ <literal>python2</literal>, <literal>python2-all</literal>). A package
that does not require the <literal>-dev</literal> packages must not
declare <literal>Build-Depends</literal> on them.
</para>
@@ -1015,8 +1016,7 @@ Build-Depends: python3-all-dev (>= 3.2)
maintainers.
</para>
<para>
- See <literal>man dh_python3</literal> or <literal>man
dh_python2</literal> for
- details.
+ See <literal>man dh_python3</literal> for details.
</para>
</section>
@@ -1097,10 +1097,10 @@ Build-Depends: python3-all-dev (>= 3.2)
</listitem>
<listitem>
<para>
- Upload of the Python core meta-packages <literal>python</literal>,
- <literal>python-dev</literal>, <literal>python-doc</literal> and
- several <literal>python-<replaceable>module</replaceable></literal>,
depending on
- the new
<literal>python<replaceable>X</replaceable>.<replaceable>Y</replaceable></literal>,
+ Upload of the Python core meta-packages
<literal>python3</literal>,
+ <literal>python3-dev</literal>, <literal>python3-doc</literal> and
+ several <literal>python3-<replaceable>module</replaceable></literal>,
depending on
+ the new
<literal>python3<replaceable>X</replaceable>.<replaceable>Y</replaceable></literal>,
<literal>python<replaceable>X</replaceable>.<replaceable>Y</replaceable>-dev</literal>
and so on.
</para>
</listitem>
