From ecfacdbd6d4d6c34ce9f0f8a2c8735520402e420 Mon Sep 17 00:00:00 2001
From: Ben Finney <ben+debian@benfinney.id.au>
Date: Mon, 25 Jan 2016 16:14:43 +1100
Subject: [PATCH] Correct whitespace to conform to Policy style.
---
debian/python-policy.sgml | 180 +++++++++++++++++++-------------------
1 file changed, 90 insertions(+), 90 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 6b8e976..b06c76f 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -17,24 +17,24 @@
<email>flight@debian.org</email>
</author>
<author>
- <name>Josselin Mouette</name>
+ <name>Josselin Mouette</name>
<email>joss@debian.org</email>
</author>
<author>
- <name>Joe Wreschnig</name>
+ <name>Joe Wreschnig</name>
<email>piman@debian.org</email>
</author>
<author>
- <name>Loïc Minier</name>
+ <name>Loïc Minier</name>
<email>lool@debian.org</email>
</author>
<author>
- <name>Scott Kitterman</name>
+ <name>Scott Kitterman</name>
<email>scott@kitterman.com</email>
</author>
<author>
- <name>Barry Warsaw</name>
- <email>barry@debian.org</email>
+ <name>Barry Warsaw</name>
+ <email>barry@debian.org</email>
</author>
<version>version 0.10.1.0</version>
@@ -83,11 +83,11 @@
Debian currently supports two Python stacks, one for Python 2
and one for Python 3. The long term goal for Debian is to
reduce this to one stack, dropping the Python 2 stack at some
- time.
+ time.
<url id="http://legacy.python.org/dev/peps/pep-0404/"
name="PEP 404"> states that no more major Python 2 releases
are planned, although the last released major version 2.7
- will see some extended support, documented in
+ will see some extended support, documented in
<url id="http://legacy.python.org/dev/peps/pep-0466/"
name="PEP 466">.
</p>
@@ -97,7 +97,7 @@
upload, new upstream versions for existing packages should
use Python 3 if the new upstream version supports it.
</p>
-
+
<p><enumlist>
<item>
<p>
@@ -209,7 +209,7 @@
some exceptions.
</p>
<p>
- Excluded are modules that cannot be included for licensing
+ Excluded are modules that cannot be included for licensing
reasons (for example the profile module), for dependency tracking
purposes (for example the GPL-licensed gdbm module) or that should
not be included for packaging reasons (for example the tk module
@@ -257,37 +257,37 @@
</sect>
<sect id="interpreter">
- <heading>Python Interpreter</heading>
- <sect1 id="interpreter_name">
- <heading>Interpreter Name</heading>
- <p>
+ <heading>Python Interpreter</heading>
+ <sect1 id="interpreter_name">
+ <heading>Interpreter Name</heading>
+ <p>
Python scripts depending on the default Python version (see <ref
id="base">) or not depending on a specific Python version should
use <file>python</file> (without a version) as the interpreter name.
</p>
- <p>
+ <p>
Python scripts that only work with a specific Python version must
explicitly use the versioned interpreter name
(<file>python<var>X</var>.<var>Y</var></file>).
- </p>
- </sect1>
- <sect1 id="interpreter_loc">
- <heading>Interpreter Location</heading>
- <p>
+ </p>
+ </sect1>
+ <sect1 id="interpreter_loc">
+ <heading>Interpreter Location</heading>
+ <p>
The preferred specification for the Python interpreter is
- <file>/usr/bin/python</file> or
- <file>/usr/bin/python<var>X</var>.<var>Y</var></file>.
+ <file>/usr/bin/python</file> or
+ <file>/usr/bin/python<var>X</var>.<var>Y</var></file>.
This ensures that a Debian installation of python is used
and all dependencies on additional python modules are met.
- </p>
- <p>
+ </p>
+ <p>
Maintainers should not override the Debian Python interpreter using
<file>/usr/bin/env python</file> or
<file>/usr/bin/env python<var>X</var>.<var>Y</var></file>. This is
not advisable as it bypasses Debian's dependency checking and makes
the package vulnerable to incomplete local installations of python.
</p>
- </sect1>
+ </sect1>
</sect>
<sect id="paths">
@@ -307,7 +307,7 @@
A special directory is dedicated to public Python modules
installed by the local administrator,
- /usr/lib/python3/dist-packages for all python3 versions,
+ /usr/lib/python3/dist-packages for all python3 versions,
/usr/local/lib/python2.<var>Y</var>/dist-packages for python2.7.
For a local installation by the administrator of python2.7, a
@@ -326,14 +326,14 @@
/usr/lib/python2.6/dist-packages/foo.py and
/usr/lib/python2.7/dist-packages/foo.py, these should point to a
common file. Version specific directories for identical source code
- are not required for python3 and must not be used for this.
+ are not required for python3 and must not be used for this.
Since python2.7 is the last python2 version and the only supported
- version in wheezy and later releases, a common location to share
- arch-independent files across Python versions is no longer needed.
- Historically the location for this was /usr/share/pyshared. For
- python2.7, use of /usr/lib/python2.7/dist-packages is sufficient.
- For python3, a special location is not required, use
+ version in wheezy and later releases, a common location to share
+ arch-independent files across Python versions is no longer needed.
+ Historically the location for this was /usr/share/pyshared. For
+ python2.7, use of /usr/lib/python2.7/dist-packages is sufficient.
+ For python3, a special location is not required, use
/usr/lib/python3/dist-packages
</p>
</sect>
@@ -433,14 +433,14 @@
</p>
<p>
Python packages are a way of structuring Python’s module namespace
- by using “dotted module namesâ€. See
+ by using “dotted module namesâ€. See
<url id="http://docs.python.org/tutorial/modules.html#packages"
name="Python's documentation"> for details on how packages are
defined in Python terms (A package in the Python sense is unrelated to a
- Debian package). Python packages must be packaged into the
- same directory (as done by upstream). Splitting components
- of a package across directories changes the import order and
- may confuse documentation tools and IDEs.
+ Debian package). Python packages must be packaged into the
+ same directory (as done by upstream). Splitting components
+ of a package across directories changes the import order and
+ may confuse documentation tools and IDEs.
</p>
<p>
There are two ways to distribute Python modules. Public
@@ -454,40 +454,40 @@
</p>
</sect>
<sect id="wheels">
- <heading>Wheels</heading>
- <p>
- <url id="http://legacy.python.org/dev/peps/pep-0427/"
- name="PEP 427">
- defines a built-package format called "wheels", which is a zip
- format archive containing Python code and a "dist-info" metadata
- directory, in a single file named with the .whl suffix. As zip
- files, wheels containing pure-Python can be put on sys.path and
- modules in the wheel can be imported directly by Python's "import"
- statement. (Importing extension modules from wheels is not yet
- supported as of Python 3.4.)
- </p><p>
- Except as described below, packages must not build or provide
- wheels. They are redundant to the established way of providing
- Python libraries to Debian users, take no advantage of distro-based
- tools, and are less convenient to use. E.g. they must be explicitly
- added to sys.path, cannot be easily grepped, and stack traces
- through zips are more difficult to debug.
- </p><p>
- A very limited set of wheel packages are available in the archive,
- but these support the narrow purpose of enabling
- the <prgn>pip</prgn> tool, in a Debian policy compliant way. The
- set of packages providing wheels for this purpose are (by source
- package name): chardet, distlib, html5lib, python-colorama,
- python-pip, python-setuptools, python-urllib3, requests, and six.
- </p><p>
- Wheel packages supporting <prgn>pyvenv</prgn> and <prgn>pip</prgn>
- are named with the <var>python-</var> prefix, and the <var>-whl</var>
- suffix, e.g. <package>python-chardet-whl</package>. When these
- binary packages are installed, their .whl files must be placed in
- the /usr/share/python-wheels directory. Such wheels must be built
- with the <tt>--universal</tt> flag so as to generate wheels
- compatible with both Python 2 and Python 3.
- </p>
+ <heading>Wheels</heading>
+ <p>
+ <url id="http://legacy.python.org/dev/peps/pep-0427/"
+ name="PEP 427">
+ defines a built-package format called "wheels", which is a zip
+ format archive containing Python code and a "dist-info" metadata
+ directory, in a single file named with the .whl suffix. As zip
+ files, wheels containing pure-Python can be put on sys.path and
+ modules in the wheel can be imported directly by Python's "import"
+ statement. (Importing extension modules from wheels is not yet
+ supported as of Python 3.4.)
+ </p><p>
+ Except as described below, packages must not build or provide
+ wheels. They are redundant to the established way of providing
+ Python libraries to Debian users, take no advantage of distro-based
+ tools, and are less convenient to use. E.g. they must be explicitly
+ added to sys.path, cannot be easily grepped, and stack traces
+ through zips are more difficult to debug.
+ </p><p>
+ A very limited set of wheel packages are available in the archive,
+ but these support the narrow purpose of enabling
+ the <prgn>pip</prgn> tool, in a Debian policy compliant way. The
+ set of packages providing wheels for this purpose are (by source
+ package name): chardet, distlib, html5lib, python-colorama,
+ python-pip, python-setuptools, python-urllib3, requests, and six.
+ </p><p>
+ Wheel packages supporting <prgn>pyvenv</prgn> and <prgn>pip</prgn>
+ are named with the <var>python-</var> prefix, and the <var>-whl</var>
+ suffix, e.g. <package>python-chardet-whl</package>. When these
+ binary packages are installed, their .whl files must be placed in
+ the /usr/share/python-wheels directory. Such wheels must be built
+ with the <tt>--universal</tt> flag so as to generate wheels
+ compatible with both Python 2 and Python 3.
+ </p>
</sect>
<sect id="package_names">
<heading>Module Package Names</heading>
@@ -505,9 +505,9 @@
multiple modules. In the latter case the maintainer chooses the
name of the module which represents the package the most.
- For subpackages such as <var>foo.bar</var>, the recommendation is to
- name the binary packages <package>python-<var>foo.bar</var></package>
- and <package>python3-<var>foo.bar</var></package>.
+ For subpackages such as <var>foo.bar</var>, the recommendation is to
+ name the binary packages <package>python-<var>foo.bar</var></package>
+ and <package>python3-<var>foo.bar</var></package>.
Such a package should support the current Debian Python version,
and more if possible (there are several tools to help implement
@@ -558,14 +558,14 @@ XS-Python-Version: all
The keyword "current" has been deprecated and used to mean that
the package would only have to support a single version (even
across default version changes). It must be ignored for Python 3
- versions.
+ versions.
</p>
<p>
The use of XB-Python-Version in the binary package paragraphs of
debian/control file has been deprecated and should be removed in the
normal course of package updates. It never achieved sufficient
deployment to support it's intended purpose of managing Python
- transitions. This can be adequately accomplished by examining
+ transitions. This can be adequately accomplished by examining
package dependencies.
</p>
</sect>
@@ -585,7 +585,7 @@ XS-Python-Version: all
All python module packages and python3 binary extension packages must
also declare a maximum version they support as currently built (this
is accomplished by declaring a maximum version constraint strictly
- less than one higher than the current maxiumum version, i.e.
+ less than one higher than the current maxiumum version, i.e.
"<package>python (<< <var>X</var>.<var>Y</var></package>)"
</p>
</sect>
@@ -593,8 +593,8 @@ XS-Python-Version: all
<sect id="provides">
<heading>Provides</heading>
<p>
- Python Provides in binary packages of the form
- <package>python-<var>X</var>.<var>Y</var><var>>foo</var></package>
+ Python Provides in binary packages of the form
+ <package>python-<var>X</var>.<var>Y</var><var>>foo</var></package>
were never supported for Python 3 and are no longer useful for
Python. They should be removed in the normal course of package
updates. Future provision of values for the substituation variable
@@ -603,7 +603,7 @@ XS-Python-Version: all
</sect>
<sect id="byte_compilation">
- <heading>Modules Byte-Compilation</heading>
+ <heading>Modules Byte-Compilation</heading>
<p>
If a binary package provides any binary-independent modules
(<file>foo.py</file> files), the corresponding byte-compiled
@@ -615,13 +615,13 @@ XS-Python-Version: all
<file>foo.pyo</file> are removed.
</p>
<p>
- A binary package should only byte-compile the files which belong to
- the package.
+ A binary package should only byte-compile the files which belong to
+ the package.
</p>
<p>
- The file <file>/etc/python/debian_config</file> allows
- configuration how modules should be byte-compiled. The
- postinst scripts should respect these settings.
+ The file <file>/etc/python/debian_config</file> allows
+ configuration how modules should be byte-compiled. The
+ postinst scripts should respect these settings.
</p>
<p>
Pure Python modules in private installation directories that are
@@ -656,8 +656,8 @@ XS-Python-Version: all
package ships multiple modules.
</p>
- <sect1 id="current_version_progs">
- <heading>Programs Shipping Private Modules</heading>
+ <sect1 id="current_version_progs">
+ <heading>Programs Shipping Private Modules</heading>
<p>
A program using <file>/usr/bin/python</file> as
interpreter can come up with private Python modules. These
@@ -860,7 +860,7 @@ Build-Depends: python3-all-dev (>= 3.2)
<heading>python-central (removed)</heading>
<p>
python-central has been removed from Jessie and later releases. It
- provided another way to manage Python modules.
+ provided another way to manage Python modules.
</p>
</sect>
@@ -944,7 +944,7 @@ Build-Depends: python3-all-dev (>= 3.2)
uninstallability is unavoidable. This is a transition that can
entangle other transitions in the distribution and requires more
careful coordination with the release team.
- </p>
+ </p>
</item>
<item>
<p>
@@ -955,7 +955,7 @@ Build-Depends: python3-all-dev (>= 3.2)
<p>
</item>
</enumlist>
-
+
</appendix>
</book>
</debiandoc>
--
GitLab