Policy for "Specifying Supported Versions" for Python3
The version of Python Policy that was just uploaded to unstable is the first
one that attempts to address Python3. It is just a start and more changes are
needed.
POX and I were just discussion this and discovered that we had been carrying
different assumptions about how packages would be expressing what versions they
support.
Today (since python3-defaults was also just uploaded) we have two supported
python versions (2.5, 2.6) and one supported python3 version (3.1).
The question that we think needs some discussion is what should the output of
`py3versions -vr '>= 2.4'` be?
As currently implemented, py3versions does not see that as including any
python3 versions, since no python3 support is explicitly declared. I had
anticipated something like:
`py3versions -vr '>= 2.4 >=3.0'`
I am concerned to avoid packages implicitly picking up a claim for python3
support that they don't actually provide. The problem with this is that using
something like:
XS-Python-Version: >= 2.x, >= 3.x
in debian/control is not expected by at the very least python-support and
dh_python{2,3}. Lintian is not at all happy with it either. First question:
Does anyone know of other packages that this would be a problem for?
Alternatives:
XS-Python-Version: >= 2.x
XS-Python3-Version: >= 3.x
This avoids any risk of existing packages inadvertently expressing support for
a Python3 version, but adds more fields to debian/control (this would also
imply, I think, XB-Python3-Version). This ends up making Packages.gz (and
.bz2) larger and making updates slower for everyone.
Only interpret XS-Python-Version: >= 2.x as including python3 versions if
there is some python3 interpreter in build-depends.
This avoids making Packages.gz build and inadvertently causing packages to
claim support for Python3, but it could get very convoluted when not all
Python3 versions are supported. I think you'd end up with something like:
XS-Python-Version: >= 2.7, <<3.0, >= 3.2
I don't thinks this helps in the long run as that would still break all the
same tools my original proposal breaks and is more complex (pyversions would
have to parse Build-depends and recognize that the python3 interpreter package
variants).
Related points: Python policy already says "all" means all Python2 versions
and has no meaning in a Python3 context and that "current" is deprecated and
does not apply at all to Python3.
I'm open to other suggestions. Comments?
Once there is some rough consensus around a concept, I'll prepare draft policy
language for us to review.
Scott K
Reply to: