Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009, Jakub Wilk wrote:
> >+ versions explicitely.
> You could fix that typo if you are at it.
Thanks; I've spell checked the whole document and came up with the
attached patch, "Spell check fixes".
--
Loïc Minier
>From ee2c89e0b24b2deff74ad35d59a8ca4a9f936ecf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <lool@dooz.org>
Date: Fri, 11 Dec 2009 12:00:18 +0100
Subject: [PATCH 29/29] Spell check fixes
---
debian/python-policy.sgml | 52 ++++++++++++++++++++++----------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 67e3d76..513200e 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -62,7 +62,7 @@
<tt>/usr/share/common-licences/GPL</tt> in the Debian GNU/Linux
distribution or on the World Wide Web at
<url id="http://www.gnu.org/copyleft/gpl.html";
- name="The GNU Public Licence">.
+ name="The GNU Public License">.
</p>
<p>
You can also obtain it by writing to the
@@ -96,7 +96,7 @@
are needed by other packages, or as long as it seems
reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature
- releases, i.e. Python 2.5 and 2.5.1 are subminor versions of
+ releases, i.e. Python 2.5 and 2.5.1 are sub-minor versions of
the same Python version 2.5, but Python 2.4 and 2.5 are
indeed different versions.)
</p>
@@ -115,7 +115,7 @@
byte-compiled, old-versions which is the list of runtimes which
might still be on the system but for which should not be built
anymore, and unsupported-versions which is the list of runtimes
- which should not be supported at all, that is modules shouldn't be
+ which should not be supported at all, that is modules should not be
built or byte-compiled for these.
</p>
<p>
@@ -186,11 +186,11 @@
<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> (unversioned) as the interpreter name.
+ use <file>python</file> (without a version) as the interpreter name.
</p>
<p>
Python scripts that only work with a specific Python version must
- explicitly use the versioned interpreter name
+ explicitly use the version-ed interpreter name
(<file>python<var>X</var>.<var>Y</var></file>).
</p>
</sect1>
@@ -285,7 +285,7 @@
There are three supported hook types which come in the form of
scripts which are invoked from the maintainer scripts of the
Python runtime packages when specific installations,
- uninstallations, or upgrades occur.
+ removals, or upgrades occur.
</p>
<p><enumlist>
<item>
@@ -345,7 +345,7 @@
Python transitions. Python modules are internally very
dependent on a specific Python version. However, we want to
automate recompiling modules when possible, either during the
- upgrade itself (re-bytecompiling pyc and pyo files) or shortly
+ upgrade itself (re-byte-compiling pyc and pyo files) or shortly
thereafter with automated rebuilds (to handle C
extensions). These policies encourage automated dependency
generation and loose version bounds whenever possible.
@@ -378,8 +378,8 @@
modules are installed in a public directory as listed
in <ref id="paths">. They are accessible to any
program. Private modules are installed in a private directory such
- as <file>/usr/share/<var>packagename</var></file>
- or <file>/usr/lib/<var>packagename</var></file>. They are
+ as <file>/usr/share/<var>package-name</var></file>
+ or <file>/usr/lib/<var>package-name</var></file>. They are
generally only accessible to a specific program or suite of
programs included in the same package.
</p>
@@ -446,7 +446,7 @@ XB-Python-Version: ${python:Versions}
yourself.) The format of the field <tt>XB-Python-Version</tt> is
the same as the <tt>XS-Python-Version</tt> field for packages not
containing extensions. Packages with extensions must list the
- versions explicitely.
+ versions explicitly.
</p>
<p>
If your package is used by another module or application
@@ -489,11 +489,11 @@ XB-Python-Version: ${python:Versions}
</p>
</sect>
- <sect id="bytecompilation">
- <heading>Modules Bytecompilation</heading>
+ <sect id="byte_compilation">
+ <heading>Modules Byte-Compilation</heading>
<p>
If a binary package provides any binary-independent modules
- (<file>foo.py</file> files), the corresponding bytecompiled
+ (<file>foo.py</file> files), the corresponding byte-compiled
modules (<file>foo.pyc</file> files) and optimized modules
(<file>foo.pyo</file> files) must not ship in the
package. Instead, they should be generated in the package's
@@ -534,7 +534,7 @@ XB-Python-Version: ${python:Versions}
begin with <tt>#!/usr/bin/python</tt> or <tt>#!/usr/bin/env
python</tt> (the former is preferred). They must also
specify a dependency on <package>python</package>, with a
- versioned dependency if necessary.
+ version-ed dependency if necessary.
</p>
<p>
If the program needs the python module <tt>foo</tt>,
@@ -552,12 +552,12 @@ XB-Python-Version: ${python:Versions}
architecture-dependent (e.g. extensions).
</p>
<p>
- The rules explained in <ref id="bytecompilation"> apply to
- those private modules: the bytecompiled modules must not
+ The rules explained in <ref id="byte_compilation"> apply to
+ those private modules: the byte-compiled modules must not
be shipped with the binary package, they should be generated in
the package's postinst, using the current default Python
version, and removed in the prerm. Modules should be
- bytecompiled using the current default Python version.
+ byte-compiled using the current default Python version.
</p>
<p>
Programs that have private compiled extensions must either
@@ -582,16 +582,16 @@ XB-Python-Version: ${python:Versions}
package providing necessary modules. It should not depend on
any <package>python-foo</package> package, unless it
requires a specific version of the package (since virtual
- packages cannot be versioned). If this is the case, it
+ packages cannot be version-ed). If this is the case, it
should depend on both the virtual package and the main
package (e.g. <tt>Depends: python2.4-foo, python-foo (>=
1.0)</tt>).
</p>
<p>
- The notes on installation directories and bytecompilation
+ The notes on installation directories and byte-compilation
for programs that support any version of Python also apply
to programs supporting only a single Python version. Modules
- to be bytecompiled should use the same Python version as the
+ to be byte-compiled should use the same Python version as the
package itself.
</p>
</sect>
@@ -608,7 +608,7 @@ XB-Python-Version: ${python:Versions}
<package>python<var>X</var>.<var>Y</var>-dev</package>, where
python<var>X</var>.<var>Y</var> is the python version the program
builds against. It should be the current default python version
- unless the program doesn't work correctly with this version.
+ unless the program does not work correctly with this version.
</p>
</sect>
@@ -633,8 +633,8 @@ XB-Python-Version: ${python:Versions}
version.
</p>
<p>
- If you install a different subrelease of the version of python
- you've got installed, you'll need to be careful to install all
+ If you install a different sub-release of the version of python
+ you have got installed, you will need to be careful to install all
the modules you use for that version of python too.
</p>
@@ -723,7 +723,7 @@ Build-Depends: python-all-dev
Using the <prgn>--install-layout=deb</prgn> flag to
<prgn>setup.py</prgn> with a system-provided python2.4 or
- python2.5 doesn't affect the default installation directory.
+ python2.5 does not affect the default installation directory.
</p>
</sect>
@@ -731,7 +731,7 @@ Build-Depends: python-all-dev
<heading>python-support</heading>
<p>
The python-support system provides a simple way to
- bytecompile pure Python modules and manage dependencies. It
+ byte-compile pure Python modules and manage dependencies. It
integrates with <package>debhelper</package>, manages
byte-compilation, private modules, will properly use the
/usr/share/pyshared directory, integrates with runtime update
@@ -809,7 +809,7 @@ Build-Depends: python-all-dev
</item>
<item>
<p>
- Upload of the python core metapackages <package>python</package>,
+ Upload of the python core meta-packages <package>python</package>,
<package>python-dev</package>, <package>python-doc</package> and
several <package>python-<var>module</var></package>, depending on
the new <package>python<var>X</var>.<var>Y</var></package>,
--
1.6.5
Reply to: