On Fri, Dec 11, 2009, Jakub Wilk wrote: > That should read: The GNU General Public License.
Thanks > Huh? "versioned" might not be recorded by dictionaries, but it is a > common term in Debian-related documentation: Hmm right that was pushing it over the top -- Loïc Minier
>From b4521be5d579c342f56a1c15b58ab27a404d885f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <l...@dooz.org> Date: Fri, 11 Dec 2009 12:00:18 +0100 Subject: [PATCH 29/30] Spell check fixes --- debian/python-policy.sgml | 46 ++++++++++++++++++++++---------------------- 1 files changed, 23 insertions(+), 23 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index 70dd793..f85320c 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 General 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,7 +186,7 @@ <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 @@ -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> @@ -451,7 +451,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 @@ -494,11 +494,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 @@ -557,12 +557,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 @@ -593,10 +593,10 @@ XB-Python-Version: ${python:Versions} 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> @@ -613,7 +613,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> @@ -638,8 +638,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> @@ -728,7 +728,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> @@ -736,7 +736,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 @@ -814,7 +814,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
