Re: Proposed Email to the release team about XS/B-P-V
Thanks for everyone's comments. Sent: http://lists.debian.org/debian-release/2010/06/msg00211.html 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/201006251712.27818.deb...@kitterman.com
Re: Proposed Email to the release team about XS/B-P-V
Il giorno Wed, 23 Jun 2010 13:15:46 -0400 Scott Kitterman ha scritto: > 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. I conducted my analysis in order to provide binNMUs for python2.6 as supported version using the method explained at [1]. Fields were used only marginally to exclude some false positives, most of the job was done by looking at package content, generated by helpers rather than XS-P-V or equivalent. Those could be completely ignored in case a stricted dependency had been in place (e.g. python (<< 2.6)). [1] <20100123201506.35c9d...@utumno> -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Proposed Email to the release team about XS/B-P-V
"Josselin Mouette" wrote:
>Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
>> >5. End this madness and use the version in build-dependencies instead of
>> >asking maintainers to specify it twice - which they usually do wrong.
>> >
>> With this approach then with the current python-defaults in Sid, how would
>> one specify works with 2.5 and 2.6, but not 2.7?
>>
>> b-d python{-all} (>= 2.5), python{-all} (=< 2.7)
>>
>> Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
>> 2.6, and/or 2.7 versions, this isn't clear to me.
>
>Indeed, but I doubt this is a real problem.
>
>> Also how does that intersect with needing specific package features to
>> build (e.g python-all (>= 2.6.5-2~) because I switched from
>> python-central to dh_python2)?
>>
>> I'd love to just specify it once if we can do it in a reasonably
>> non-convoluted and complete way.
>
>Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
>requiring it.
>
If there is concurrence from the release team that there is no need to expose
this externally then I don't see a need to require it. It would be part of a
tool set, but up to the package maintainer if they use it.
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/e318c32f-76fb-43ce-9e5b-9985f0392...@email.android.com
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski wrote: >> * A module that works perfectly with every Python >= 2.5, but its >> documentation generation system required Python 2.6. Build-dep on python >> (>= 2.6) is needed, which doesn't mean that modules shouldn't be >> byte-compiled for 2.5. > > python (>= 2.6-1~) | python (>= 2.5) > (note that buildds ignore everything after "|") I don't think that relying on the current behaviour of the buildds to make semantically incorrect build-deps work is a great idea, even if that behaviour never changes. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- 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/aanlktimiojzbkoggkwuuqpqks0o4whuktqlfnka1r...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
[Jakub Wilk, 2010-06-24]
> * Piotr Ożarowski , 2010-06-24, 09:27:
>> it gets a little bit messy when minimum required Python version is
>> greater than the default one, but it should work, yes (IIRC last year
>> someone gave me example where it wouldn't work, but I don't remember it
>> now, hopefully it will be pointed out again soon)
>
> XSPV is currently used for two things:
> 1. cdbs/dh7 etc. use it to iterate over Python versions to build, install
> etc. stuff.
... which use py{,3}versions command¹ to get the list of supported
Python versions
[¹] just like all other packages that do not use cdbs/dh7 should do
[...]
> Here are some real world examples (for 2.X, but that's irrelevant):
>
> * A module that works perfectly with every Python >= 2.5, but its
> documentation generation system required Python 2.6. Build-dep on python
> (>= 2.6) is needed, which doesn't mean that modules shouldn't be
> byte-compiled for 2.5.
python (>= 2.6-1~) | python (>= 2.5)
(note that buildds ignore everything after "|")
> * A module with no upstream build-system, which works only with Python
> 2.5. Build-dep on python normally isn't needed at all, yet one should be
> able to specify which Python version are supported by this module.
well, right now python is pulled in anyway (via python-central or
python-support build dependency). If a package doesn't use helper
tools, it doesn't use XS-Python-Version as well.
>> example for default=3.1 minimum=3.2 maximum=3.5:
>> python-all | python-all (>= 3.2), python-all (<< 3.5), python-all (>=
>> 3.1.2-2)
>> or even
>> python-all (>= 3.1.2-2) | python-all (>= 3.2), python-all (<< 3.5)
>
> This is neither human readable nor human writable.
most packages will have "python3-all (>= 3.1.2-2)" only
>> I will implement it in dh_python3 (only ">= X.Y" and "<< X.Y" will be
>> taken into account, I will ignore all ".* X\.Y.*" including X.Y-Z)) and
>> use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version
>> is not available (in that order)
>
> If you implement this, I will refrain from doing any QA work on python3-*
> packages. Have fun.
ok, postponing
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20100624103545.gw18...@piotro.eu
Re: Proposed Email to the release team about XS/B-P-V
* Piotr Ożarowski , 2010-06-24, 09:27:
5. End this madness and use the version in build-dependencies
instead of asking maintainers to specify it twice - which they
usually do wrong.
With this approach then with the current python-defaults in Sid, how
would one specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (>= 2.5), python{-all} (=< 2.7)
Since a python-all version of 2.6 may at different times reflect
b-d on 2.5, 2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
it gets a little bit messy when minimum required Python version is
greater than the default one, but it should work, yes (IIRC last year
someone gave me example where it wouldn't work, but I don't remember it
now, hopefully it will be pointed out again soon)
XSPV is currently used for two things:
1. cdbs/dh7 etc. use it to iterate over Python versions to build,
install etc. stuff.
2. pysupport/pycentral etc. use it to determine for which Python
versions pure-python modules are bytecompiled.
Point 1 is related to build-dependencies, but not everyone use
cdbs/dh7. Point 2 has nothing to do with build-dependencies. Using
build-dependencies as replacement of XP3V is just semantically wrong.
Here are some real world examples (for 2.X, but that's irrelevant):
* A module that works perfectly with every Python >= 2.5, but its
documentation generation system required Python 2.6. Build-dep on
python (>= 2.6) is needed, which doesn't mean that modules shouldn't be
byte-compiled for 2.5.
* A module with no upstream build-system, which works only with Python
2.5. Build-dep on python normally isn't needed at all, yet one should be
able to specify which Python version are supported by this module.
example for default=3.1 minimum=3.2 maximum=3.5:
python-all | python-all (>= 3.2), python-all (<< 3.5), python-all (>= 3.1.2-2)
or even
python-all (>= 3.1.2-2) | python-all (>= 3.2), python-all (<< 3.5)
This is neither human readable nor human writable.
I will implement it in dh_python3 (only ">= X.Y" and "<< X.Y" will be
taken into account, I will ignore all ".* X\.Y.*" including X.Y-Z)) and
use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version
is not available (in that order)
If you implement this, I will refrain from doing any QA work on
python3-* packages. Have fun.
--
Jakub Wilk
signature.asc
Description: Digital signature
Re: Proposed Email to the release team about XS/B-P-V
[Piotr Ożarowski, 2010-06-24] > [Josselin Mouette, 2010-06-24] > example for default=3.1 minimum=3.2 maximum=3.5: > python-all | python-all (>= 3.2), python-all (<< 3.5), python-all (>= > 3.1.2-2) > or even > python-all (>= 3.1.2-2) | python-all (>= 3.2), python-all (<< 3.5) err, python3-all of course > I will implement it in dh_python3 (only ">= X.Y" and "<< X.Y" will be > taken into account, I will ignore all ".* X\.Y.*" including X.Y-Z)) and and ".* X\.Y.+" here > use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version > is not available (in that order) or drop debian/pyversions and XS-Python-Version from above list -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100624073755.gu18...@piotro.eu
Re: Proposed Email to the release team about XS/B-P-V
[Josselin Mouette, 2010-06-24]
> Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
> > >5. End this madness and use the version in build-dependencies instead of
> > >asking maintainers to specify it twice - which they usually do wrong.
> > >
> > With this approach then with the current python-defaults in Sid, how would
> > one specify works with 2.5 and 2.6, but not 2.7?
> >
> > b-d python{-all} (>= 2.5), python{-all} (=< 2.7)
> >
> > Since a python-all version of 2.6 may at different times reflect b-d on
> > 2.5, 2.6, and/or 2.7 versions, this isn't clear to me.
>
> Indeed, but I doubt this is a real problem.
it gets a little bit messy when minimum required Python version is
greater than the default one, but it should work, yes (IIRC last year
someone gave me example where it wouldn't work, but I don't remember it
now, hopefully it will be pointed out again soon)
example for default=3.1 minimum=3.2 maximum=3.5:
python-all | python-all (>= 3.2), python-all (<< 3.5), python-all (>= 3.1.2-2)
or even
python-all (>= 3.1.2-2) | python-all (>= 3.2), python-all (<< 3.5)
I will implement it in dh_python3 (only ">= X.Y" and "<< X.Y" will be
taken into account, I will ignore all ".* X\.Y.*" including X.Y-Z)) and
use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version
is not available (in that order)
> > Also how does that intersect with needing specific package features to
> > build (e.g python-all (>= 2.6.5-2~) because I switched from
> > python-central to dh_python2)?
> >
> > I'd love to just specify it once if we can do it in a reasonably
> > non-convoluted and complete way.
>
> Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
> requiring it.
it's not required
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20100624072719.gt18...@piotro.eu
Re: Proposed Email to the release team about XS/B-P-V
Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
> >5. End this madness and use the version in build-dependencies instead of
> >asking maintainers to specify it twice - which they usually do wrong.
> >
> With this approach then with the current python-defaults in Sid, how would
> one specify works with 2.5 and 2.6, but not 2.7?
>
> b-d python{-all} (>= 2.5), python{-all} (=< 2.7)
>
> Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
> 2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
> Also how does that intersect with needing specific package features to
> build (e.g python-all (>= 2.6.5-2~) because I switched from
> python-central to dh_python2)?
>
> I'd love to just specify it once if we can do it in a reasonably
> non-convoluted and complete way.
Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
requiring it.
--
.''`.
: :' : “Fuck you sir, don’t be suprised when you die if
`. `' you burn in Hell, because I am a solid Christian
`-and I am praying for you.” -- Mike
--
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/1277361894.29067.2.ca...@meh
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 12:44:36AM -0400, Scott Kitterman wrote: > On Wednesday, June 23, 2010 11:08:47 pm Paul Wise wrote: > > On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman > wrote: > > > The email is meant to go to the release team to address what I understand > > > to be release team specific requirement. I think that the broader > > > question needs to be discussed in a broader audience. > > I think it is relevant there as well, IIRC folks from the then release > > team were behind the move from python2.X-foo to python-foo modules. > OK. I'll include them in that discussion, although I think what we are > proposing now is entirely unrelated to that decision. As one of the aforementioned release team members, I agree. When module compatibility between python2.x and python3.x is not the common case, I don't think the arguments for consolidating on python-foo apply here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposed Email to the release team about XS/B-P-V
On Wednesday, June 23, 2010 11:08:47 pm Paul Wise wrote: > On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman wrote: > > The email is meant to go to the release team to address what I understand > > to be release team specific requirement. I think that the broader > > question needs to be discussed in a broader audience. > > I think it is relevant there as well, IIRC folks from the then release > team were behind the move from python2.X-foo to python-foo modules. OK. I'll include them in that discussion, although I think what we are proposing now is entirely unrelated to that decision. 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/201006240044.37497.deb...@kitterman.com
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman wrote: > The email is meant to go to the release team to address what I understand to > be release team specific requirement. I think that the broader question needs > to be discussed in a broader audience. I think it is relevant there as well, IIRC folks from the then release team were behind the move from python2.X-foo to python-foo modules. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktimzqrdcbyxlmafqa12t5npj4xbvze75d3skj...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
On Wednesday, June 23, 2010 10:01:03 pm Paul Wise wrote: > On Thu, Jun 24, 2010 at 1:15 AM, Scott Kitterman wrote: > > 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. > > Your mail doesn't seem to mention the planned python-foo/python3-foo > duplication for modules that are portable to both versions of python. The email is meant to go to the release team to address what I understand to be release team specific requirement. I think that the broader question needs to be discussed in a broader audience. 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/201006232242.41734.deb...@kitterman.com
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 1:15 AM, Scott Kitterman wrote: > 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. Your mail doesn't seem to mention the planned python-foo/python3-foo duplication for modules that are portable to both versions of python. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktimaz8owqmc11fogtfgpvgqmsjcy-qcypg8ro...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
"Josselin Mouette" wrote:
>Le mercredi 23 juin 2010 à 13:15 -0400, Scott Kitterman a écrit :
>> 1. Use XS/B-P-V for Python and Python3 versions
>> 2. Create a new set of fields, XS/B-Python3-Version.
>> 3. Create a new field, X-Python-Version: for Python3 versions.
>> 4. Create a new field, X-Python3-Version: for Python3 versions
>
>5. End this madness and use the version in build-dependencies instead of
>asking maintainers to specify it twice - which they usually do wrong.
>
With this approach then with the current python-defaults in Sid, how would one
specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (>= 2.5), python{-all} (=< 2.7)
Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
2.6, and/or 2.7 versions, this isn't clear to me.
Also how does that intersect with needing specific package features to build
(e.g python-all (>= 2.6.5-2~) because I switched from python-central to
dh_python2)?
I'd love to just specify it once if we can do it in a reasonably non-convoluted
and complete way.
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/44796d70-2a7e-41ae-a736-7078f5779...@email.android.com
Re: Proposed Email to the release team about XS/B-P-V
Le mercredi 23 juin 2010 à 13:15 -0400, Scott Kitterman a écrit : > 1. Use XS/B-P-V for Python and Python3 versions > 2. Create a new set of fields, XS/B-Python3-Version. > 3. Create a new field, X-Python-Version: for Python3 versions. > 4. Create a new field, X-Python3-Version: for Python3 versions 5. End this madness and use the version in build-dependencies instead of asking maintainers to specify it twice - which they usually do wrong. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Proposed Email to the release team about XS/B-P-V
"Piotr Ożarowski" wrote: >[Scott Kitterman, 2010-06-23] >> 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." > Thanks. >> 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. > >is it worth mentioning migration of XS-Python-Version to >X-Python-Version? Will we ever do that? For what gain? It would remove the wart of exposing useless information and slightly de-bloat the files that would no longer carry this information. If we were to start over it would be something more like this. I think it's worth mentioning the more "correct" design even if we conclude the gain is not worth the effort now. 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/d03302b6-287a-4ed0-a7fb-bc6b9eee9...@email.android.com
Re: Proposed Email to the release team about XS/B-P-V
[Scott Kitterman, 2010-06-23] > 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 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. is it worth mentioning migration of XS-Python-Version to X-Python-Version? Will we ever do that? For what gain? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Proposed Email to the release team about XS/B-P-V
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
