Subj: Future requirements for specifying supported Python versions and
transition support
In Debian Python we are currently discussing how best to specify version
information for Python 3. There is a strong (but not unanimous) view among
the participants in debian-pyt...@l.d.o and #debian-python that Python(2) and
Python 3 are sufficiently different that they should be treated as essentially
separate run time systems. If a package expresses support for Python versions
greater than (for example) 2.4, this should never include any Python 3
versions.
This discussion has caused us to take a look as the current methods for
expressing support for different python versions. AIUI the approach of
embedding this information in the source and binary control files was intended
to support the release team for Python transitions, e.g. if the source
expressed support for Python 2.4 and later:
XS-Python-Version: >= 2.4
and the binary was only built for python2.5:
XB-Python-Version: 2.5
Then this would be a package that needed either binNMU or sourceful changes
for the python2.6 transition.
I have consulted with Luca Falavigna (DktrKranz) and Jakub Wilk (jwilk), who
did most of the analysis for the last two Python transitions (Adding 2.6 to
supported versions and the current transition to 2.6 as default) and neither
of them found this embedded information useful in their analysis. They did
their work based on package dependencies. While I'm sure XS/B-P-V was a good
idea at the time, it does not seem to have, in practice met it's goal.
Among the group discussing the question of how to represent Python 3 versions,
there is some reasonable consensus around the idea of a separate field in
debian/control, but there is concern about further bloating Packages.{gz,bz2}
and adding more to the binary control file.
Since support to the release team was an important use case for the current
design, we are consulting with you before any decisions are made.
The first question is: Does the release team still consider it a requirement
for supported Python{3} versions to be externally exposed in some way other
than through package dependencies? In our review of the recent transitions,
we don't see a case for it.
We have discussed a number of options (and I've added more for completeness):
1. Use XS/B-P-V for Python and Python3 versions, but Python tools must never
return any versions 3 or higher and Python 3 tools must never return versions
lower than 3. This is implemented in pyversions and py3versions in Sid. It
has the advantage of not introducing any new fields, but it does depend on
implementation correctness to avoid mixing versions. It also leads to warts
like:
XS-Python-Version: >= 2.4, >= 3.0
2. Create a new set of fields, XS/B-Python3-Version. This would obtain a
clearer separation and conditions like XS-Python-Version: 2.5, 2.5, 3.1 can be
treated as an error so that maintainers are aware of a problem. It does add
to the information exposed in Packages.{gz,bz2} for no clear gain.
3. Create a new field, X-Python-Version: for Python3 versions. This avoids
concerns about control file bloat, but may be a bit confusing in combination
with the existing XS/B-P-V.
4. Create a new field, X-Python3-Version: for Python3 versions and in Squueze
+1 migrate the existing XS/B-P-V to X-Python-Version. This avoids confusion,
but does require lots of packages to be changed and tools to be updated to
recognize X-Python-Version. In the long run, it does stop Python packages
from exposing information externally that has turned out not to be very
useful.
Please CC me on any replies as I am not subscribed. Anyone with an interest
in the topic is encouraged to join the discussion on debian-pyt...@l.d.o and
in #debian-python.
Scott K
--
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/201006231315.47072.deb...@kitterman.com
