Re: Future requirements for specifying supported Python versions and transition support
[ speaking only for myself ]
one thing that isn't clear for me, what is (or is there any) opinion
from doko / POX on this?
* Scott Kitterman (debian@kitterman.com) [100625 22:37]:
> 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.
I don't think the bloat is so bad.
> 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.
I think whatever way it works is fine - the main requirement is
something along the lines "transitions should be as less painful as
possible". Of course, as long as "the python people" take mostly care
of the required packages for rebuilding, this is "less painful" for
the release team ;)
> XS-Python-Version: >= 2.4, >= 3.0
I think that's ugly.
> 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.
Sounds fine for me (from the technical point).
> 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.
I think this will cause confusion. If, then as X-Python3-Version.
Andi
Reply to: