Re: RFC: Adding discussion about required versions to Python policy

[Scott Kitterman]

On Monday, March 19, 2012 12:20:18 PM Jakub Wilk wrote:
 * Scott Kitterman deb...@kitterman.com, 2012-03-17, 14:29:
 Upon reflection, this could be better stated something like this:
 
 The generated minumum dependency may be different than the lowest
 version currently supported. In such cases, X-Python-Version must
 still be specified if the generated dependency is not sufficient.
 
 To give a specific example, even though python3.2 is the only supported
 python3, for an arch all module, dh_python3 will generate a dependency
 of python3 = 3.1.3-13.  If the upstream code requires 3.2, then you
 still need to specify (in this example) X-Python3-Version.
 
 This is true, but I'm not sure why Python Policy needs to talk about
 this. If it does, then probably appendix B would be the correct place.
 Or a footnote.
 
 In general, how X(S)P(3)V is translated to dependency on python(3)
 varies depending on which helper you use. A packaging helper can add a
 dependency on python(3) (= $V) for several reasons:
 
 1) because the package declared X(S)P(3)V: = $V [all helpers];
 
 2) because the package ships extension modules (or other files that
 cannot be shared across versions) only for versions = $V [all helpers];
 
 3) because the helper is implemented in such a way that it supports at
 runtime only (a subset of) versions available at buildtime [dh_python2,
 and sometimes python-central];
 
 4) because it generates maintainer scripts that need such version of
 python(3) [dh_python2, dh_python3].

I think something like my first paragraph needs to go wherever it says X3-P-V 
can be omitted if all versions are supported, because it has to be clear that 
all isn't just all in Unstable on the day you're uploading.  It's a function 
of how the dependencies are calculated.  

I think your helper specific information ought to go in appendix B.  

Does that make sense (to the extent anything less than a rewrite makes sense)?

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: RFC: Adding discussion about required versions to Python policy

[Jakub Wilk]

* Scott Kitterman deb...@kitterman.com, 2012-03-19, 09:29:
The generated minumum dependency may be different than the lowest 
version currently supported. In such cases, X-Python-Version must 
still be specified if the generated dependency is not sufficient.

[...]
I think something like my first paragraph needs to go wherever it says 
X3-P-V can be omitted if all versions are supported, because it has to 
be clear that all isn't just all in Unstable on the day you're 
uploading.


How about saying that it can be ommitted only it the package is 
compatible with all versions supported in unstable, in testing and in 
stable?


dh_python2 allows you to be less strict about this, but that doesn't 
mean you should take the opportunity. :)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120319162925.gb7...@jwilk.net

RFC: Adding discussion about required versions to Python policy

[Scott Kitterman]

I've worked on a couple of dh_python3 bugs in the last few days and as a 
result, gotten my hands dirty on the Python 3 dependency generation code.

This caused me to consider the question of specifying which Python 3 versions 
are supported by a package a little more closely.  I have generally considered 
that if all Python (Python 3) versions supported in the development release 
were supported by the package, then there's no need to explicitly define the 
supported versions in the packaging (e.g. using X-Python-Version).  Reality 
is, of course, slightly more complex.

For Python 3, architecture independent packages that have no version specific 
code in them will always depend on python3 = 3.1.3-13~.  So for these 
packages the minimum version requirement specified in X-Python3-Version isn't 
3.2 (the current version in Wheezy), it's 3.1.  Packages that will only work 
with Python 3 3.2 need this specifed in X-Python3-Version.

I took a stab at adding some words to the Python policy to explain this.  
Comments please (diff attached).

Scott K--- python-policy.txt	2012-03-16 23:29:14.384401914 -0400
+++ python-policy.new.txt	2012-03-16 23:46:06.460372010 -0400
@@ -398,16 +398,29 @@
  Python 3) supported by the source package.  Similarly,
  `X-Python3-Version' is used to specify the versions of Python 3
  supported by the package.  When not specified, they default to all
- currently supported Python (or Python 3) versions.  They are used by
- some packaging scripts to automatically generate appropriate Depends
- and Provides lines.  The format of the field may be one of the
- following:
+ currently supported Python (or Python 3) versions.
+
+ They are used by some packaging scripts to automatically generate
+ appropriate Depends and Provides lines.  The format of the field may
+ be one of the following:
 
   XS-Python-Version: = X.Y
   XS-Python-Version: = A.B,  X.Y
   XS-Python-Version: A.B, X.Y
   XS-Python-Version: all
 
+ If the package supports all versions of Python/Python3 either
+ supported in or planned for the development release, as well as the
+ stable release, then `X-Python-Version' or `X-Python3-Version' may
+ generally be omitted from `debian/control'.  The most common exception
+ to this is architecture independent Python 3 modules with no version
+ specific code.  Since, unlike in Python, version specific directories
+ are not needed for Python 3, there is no need to constrain their
+ minimum Python 3 version to the supported versions.  For these
+ packages, `X-Python3-Version' can only be omitted if the package
+ supports python3 = 3.1.3-13 and later (python3 3.0 was never a
+ supported Python 3 version in Debian).
+
  The keyword all means that the package supports any Python version
  available but might be deprecated in the future since using version
  numbers is clearer than all and encodes more information.  The
@@ -416,6 +429,7 @@
  2.5, 2.6) work for `XS-Python-Version' and will continue to be
  supported, but are not recommended and will not be supported by
  `X-Python-Version' or `X-Python3-Version' after the Squeeze release.
+
  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.


signature.asc
Description: This is a digitally signed message part.