[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Proposed updates to the Python Policy to reflect current practices



On Wed, Dec 09, 2009, Luca Falavigna wrote:
> I entirely read the 1.9.0.0 draft, I've got some thoughts on it.

 Thanks for your review, I'm attaching the following new patches:
    s/binary/interpreter for /usr/bin/python*
    Clarify binary versus source packages
    Require the python- prefix for public modules

 let me know if they address your comments

>  ---
> |  1.5. Module Path
> |
> |    As an exception to the above, modules managed by python-support are
> |    installed in another directory which is added to the sys.path using
> |    the .pth mechanism.
>  ---
> I'm unsure about this point. Doesn't python-support search for modules
> in /usr/lib/pythonY.X/{site,dist}-packages, or is this another location
> where pysupport can look at?

 IIUC, python-supports generates the /usr/lib/pymodules hierarchy which
 is where python-support backed modules get loaded from.  This location
 is added to the path by matters of
 /usr/lib/python2.*/*-packages/python-support.pth files:
%  ls -l /usr/lib/python2.*/*-packages/python-support.pth
lrwxrwxrwx 1 root root 31 Dec 11 09:27 /usr/lib/python2.4/site-packages/python-support.pth -> ../../pymodules/python2.4/.path
lrwxrwxrwx 1 root root 31 Dec 11 09:27 /usr/lib/python2.5/site-packages/python-support.pth -> ../../pymodules/python2.5/.path
lrwxrwxrwx 1 root root 31 Dec 11 09:27 /usr/lib/python2.6/dist-packages/python-support.pth -> ../../pymodules/python2.6/.path

>  ---
> |  2.3. Specifying Supported Versions
> |
> |    Your control file should also have a line:
> |
> |          XB-Python-Version: ${python:Versions}
> |
> |    The python:Versions is substituted by the supported Python
> |    versions of the binary package, based on `XS-Python-Version'.  (If
> |    you are not using python-central or python-support, you will need
> |    to handle this substitution yourself.)
>  ---
> python-support doesn't manage XB-Python-Version (or at least it
> shouldn't right now). Is this supposed to be changed in python-support,
> or packages using such tool can ignore it?

 python-support can generate XB-Python-Version:, but wont use the data.

 This recommendation was kept because it might be useful to have a
 machine parseable field containing the list of supported versions for a
 package, perhaps to schedule rebuilds.

   Thanks
-- 
Loïc Minier
>From ddc90e42630f2f1045809f850ec14e286b092cb0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <lool@dooz.org>
Date: Fri, 11 Dec 2009 10:13:52 +0100
Subject: [PATCH 26/28] s/binary/interpreter for /usr/bin/python*

Use "interpreter" instead of "binary" for /usr/bin/python*; thanks
Luca Falavigna
---
 debian/python-policy.sgml |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index e387629..98e7653 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -135,8 +135,9 @@
 	  For every Python version provided in the distribution, the package
 	  <package>python<var>X</var>.<var>Y</var></package> shall provide a
 	  complete distribution for <em>deployment</em> of Python scripts
-	  and applications. The package must ensure that the binary
-	  <file>/usr/bin/python<var>X</var>.<var>Y</var></file> is provided.
+	  and applications. The package must ensure that the
+	  <file>/usr/bin/python<var>X</var>.<var>Y</var></file> interpreter
+	  is provided.
 	</p>
 	<p>
 	  Installation of <package>python<var>X</var>.<var>Y</var></package>
@@ -153,7 +154,7 @@
 	</p>
 	<p>
 	  At any time, the <package>python</package> package must ensure
-	  that the binary <file>/usr/bin/python</file> is provided.
+	  that the <file>/usr/bin/python</file> interpreter is provided.
 
 	  The <package>python</package> package must also depend on the
 	  appropriate <package>python<var>X</var>.<var>Y</var></package> to
-- 
1.6.5

>From d814a40c6da2dc94398549cc280ea3844f1177f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <lool@dooz.org>
Date: Fri, 11 Dec 2009 10:51:23 +0100
Subject: [PATCH 27/28] Clarify binary versus source packages

Clarify binary versus source packages; thanks Luca Falavigna
---
 debian/python-policy.sgml |   75 +++++++++++++++++++++++---------------------
 1 files changed, 39 insertions(+), 36 deletions(-)

diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 98e7653..3b5019c 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -79,8 +79,8 @@
       <sect id="versions">
 	<heading>Versions</heading>
 	<p>
-	  At any given time, the package <package>python</package> will
-	  represent the current default Debian Python version.
+	  At any given time, the binary package <package>python</package>
+	  will represent the current default Debian Python version.
 	</p>
 	<p>
 	  The default Debian Python version should always be the latest stable
@@ -101,7 +101,7 @@
 	  indeed different versions.)
 	</p>
 	<p>
-	  For any version, the main package must be called
+	  For any version, the main binary package must be called
 	  <package>python<var>X</var>.<var>Y</var></package>.
 	</p>
 
@@ -132,10 +132,10 @@
       <sect id="base">
 	<heading>Main packages</heading>
 	<p>
-	  For every Python version provided in the distribution, the package
-	  <package>python<var>X</var>.<var>Y</var></package> shall provide a
-	  complete distribution for <em>deployment</em> of Python scripts
-	  and applications. The package must ensure that the
+	  For every Python version provided in the distribution, the binary
+	  package <package>python<var>X</var>.<var>Y</var></package> shall
+	  provide a complete distribution for <em>deployment</em> of Python
+	  scripts and applications. The package must ensure that the
 	  <file>/usr/bin/python<var>X</var>.<var>Y</var></file> interpreter
 	  is provided.
 	</p>
@@ -146,23 +146,24 @@
 	<p>
 	  Excluded are any modules that depend on
 	  non-<em>required</em> packages, they will be provided in
-	  separate packages.  Some tools and files for the
+	  separate binary packages.  Some tools and files for the
 	  <em>development</em> of Python modules are split off in a
-	  separate package
+	  separate binary package
 	  <package>python<var>X</var>.<var>Y</var>-dev</package>.
 	  Documentation will be provided separately as well.
 	</p>
 	<p>
-	  At any time, the <package>python</package> package must ensure
-	  that the <file>/usr/bin/python</file> interpreter is provided.
+	  At any time, the <package>python</package> binary package must
+	  ensure that the <file>/usr/bin/python</file> interpreter is
+	  provided.
 
-	  The <package>python</package> package must also depend on the
-	  appropriate <package>python<var>X</var>.<var>Y</var></package> to
-	  ensure this runtime is installed.
+	  The <package>python</package> binary package must also depend on
+	  the appropriate <package>python<var>X</var>.<var>Y</var></package>
+	  to ensure this runtime is installed.
 	</p>
 	<p>
-	  The version of the <package>python</package> package must be
-	  greater than or equal to <var>X</var>.<var>Y</var> and smaller
+	  The version of the <package>python</package> binary package must
+	  be greater than or equal to <var>X</var>.<var>Y</var> and smaller
 	  than <var>X</var>.<var>Y+1</var>.
 	</p>
       </sect>
@@ -171,9 +172,10 @@
 	<heading>Minimal packages</heading>
 	<p>
 	  For every Python version provided in the distribution, the
-	  package <package>python<var>X</var>.<var>Y</var></package>-minimal
-	  might exist and should not be depended upon by other packages
-	  except the Python runtime packages themselves.
+	  binary package
+	  <package>python<var>X</var>.<var>Y</var></package>-minimal might
+	  exist and should not be depended upon by other packages except the
+	  Python runtime packages themselves.
 	</p>
       </sect>
 
@@ -257,8 +259,8 @@
 	</p>
 
 	<p>
-	  When packages ship identical source code for multiple Python
-	  versions, for instance
+	  When binary packages ship identical source code for multiple
+	  Python versions, for instance
 	  /usr/lib/python2.6/dist-packages/foo.py and
 	  /usr/lib/python2.5/site-packages/foo.py, these should point to a
 	  common file.
@@ -272,8 +274,9 @@
       <sect id="runtimes_hooks">
 	<heading>Hooks for updates to installed runtimes</heading>
 	<p>
-	  The <package>python</package> package has special hooks to allow
-	  other packages to act upon updates to the installed runtimes.
+	  The <package>python</package> binary package has special hooks to
+	  allow other packages to act upon updates to the installed
+	  runtimes.
 
 	  This mechanism is required to handle changes of the default Python
 	  runtime in some packages and to enable the Python packaging
@@ -324,10 +327,10 @@
       <sect id="docs">
 	<heading>Documentation</heading>
 	<p>
-	  Python documentation is split out in separate packages
-	  <package>python<var>X</var>.<var>Y</var>-doc</package>. The package
-	  <package>python-doc</package> will always provide the documentation
-	  for the default Debian Python version.
+	  Python documentation is split out in separate binary packages
+	  <package>python<var>X</var>.<var>Y</var>-doc</package>. The binary
+	  package <package>python-doc</package> will always provide the
+	  documentation for the default Debian Python version.
 	</p>
 	<p>
 	  TODO: Policy for documentation of third party packages.
@@ -384,8 +387,8 @@
       <sect id="package_names">
 	<heading>Module Package Names</heading>
 	<p>
-	  Public modules should be packaged with a name
-	  of <package>python-<var>foo</var></package>,
+	  Public modules should have a binary package named
+	  <package>python-<var>foo</var></package>,
 	  where <var>foo</var> is the name of the module. Such a
 	  package should support the current Debian Python version,
 	  and more if possible (there are several tools to help
@@ -407,8 +410,8 @@ import foo
 	<p>
 	  The optional <tt>XS-Python-Version</tt> field
 	  in <file>debian/control</file> specifies the versions of
-	  Python supported by the package.  When not specified, it defaults
-	  to all currently supported Python versions.
+	  Python supported by the source package.  When not specified, it
+	  defaults to all currently supported Python versions.
 
 	  It is notably used to track packages during Python transitions,
 	  and is also used by some packaging scripts to automatically
@@ -476,7 +479,7 @@ XB-Python-Version: ${python:Versions}
       <sect id="provides">
 	<heading>Provides</heading>
 	<p>
-          Provides in packages of the form
+          Provides in binary packages of the form
           <package>python-<var>foo</var></package> must be specified,
           if the package contains an extension for more than one
           python version. Provides should also be added on request of
@@ -487,7 +490,7 @@ XB-Python-Version: ${python:Versions}
       <sect id="bytecompilation">
         <heading>Modules Bytecompilation</heading>
 	<p>
-	  If a package provides any binary-independent modules
+	  If a binary package provides any binary-independent modules
 	  (<file>foo.py</file> files), the corresponding bytecompiled
 	  modules (<file>foo.pyc</file> files) and optimized modules
 	  (<file>foo.pyo</file> files) must not ship in the
@@ -497,7 +500,7 @@ XB-Python-Version: ${python:Versions}
 	  <file>foo.pyo</file> are removed.
 	</p>
 	<p>
-          A package should only byte-compile the files which belong to
+          A binary package should only byte-compile the files which belong to
           the package.
 	</p>
 	<p>
@@ -549,7 +552,7 @@ XB-Python-Version: ${python:Versions}
 	  <p>
 	    The rules explained in <ref id="bytecompilation"> apply to
 	    those private modules: the bytecompiled modules must not
-	    be shipped with the package, they should be generated in
+	    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.
@@ -647,7 +650,7 @@ XB-Python-Version: ${python:Versions}
       </p>
       <p>
 	Some applications and pure Python modules may be able to
-	depend only on <package>python</package>
+	build-depend only on <package>python</package>
 	or <package>python-all</package> and not require the -dev
 	packages.
       </p>
-- 
1.6.5

>From 73cca36cbf67ab6746dbb5dbc8994a0d9665ef22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <lool@dooz.org>
Date: Fri, 11 Dec 2009 11:00:24 +0100
Subject: [PATCH 28/28] Require the python- prefix for public modules

Require the python- prefix for packages shipping public modules used by
other packages, and recommend using python-foo for public modules in
general; thanks Luca Falavigna
---
 debian/python-policy.sgml |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 3b5019c..67e3d76 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -387,9 +387,11 @@
       <sect id="package_names">
 	<heading>Module Package Names</heading>
 	<p>
-	  Public modules should have a binary package named
-	  <package>python-<var>foo</var></package>,
-	  where <var>foo</var> is the name of the module. Such a
+	  Public modules used by other packages must have a binary package
+	  named <package>python-<var>foo</var></package>,
+	  where <var>foo</var> is the name of the module; this is also the
+	  recommended naming when public modules might be used by other
+	  packages in the future, as to avoid a rename. Such a
 	  package should support the current Debian Python version,
 	  and more if possible (there are several tools to help
 	  implement this, see <ref id="packaging_tools">). For
-- 
1.6.5


Reply to: