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. Please note the lack of XB-Python-Version, i.e.
X-Python-Version will be used to feed build tools only.
4. Create a new field, X-Python3-Version: for Python3 versions and support
both the existing XS/B-P-V and a new X-Python-Version (to parallel X-Python3-
Version). This avoids confusion namespace confusion, but does require
packages to be changed and tools to be updated to recognize X-Python-Version.
In the long run, it may stop Python packages from exposing information
externally that has turned out not to be very useful.
5. "End this madness and use the version in build-dependencies instead of
asking maintainers to specify it twice - which they usually do wrong" is
suggested by Joss, but there's no design for this.
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
signature.asc
Description: This is a digitally signed message part.
