"Sandro Tosi" <mo...@debian.org> wrote:
>Hi Scott, >thanks for bringing this up (again :) ). > >On Wed, Jun 30, 2010 at 22:41, Scott Kitterman <deb...@kitterman.com> wrote: >> As I had said I would after the last round, I asked the release team about >> any >> specific requirements they might have for Python version specification. They >> don't. My summary of the thread is "We want it to be easy". The thread >> starts here for those interested: >> >> http://lists.debian.org/debian-release/2010/06/msg00211.html >> >> Based on the previous discussion here and feedback on IRC, here is a revised >> proposal: >> >> For Python(2): >> >> pyversions -r will use (in this order): >> >> 1. A new field called X-Python2-Version: This is identical to the current >> XS- >> P-V, except it doesn't get exported to the source Packages.{gz,bz2}, and it >> does not support lists of versions (e.g. (2.4, 2.5, 2.6) is not supported). >> Acceptable values are a single version (e.g 2.6), greater than or equal to a >> version (e.g. >= 2.5), or strictly less than a version (e.g. << 2.7). >> Versions 3 or greater will raise an error. > >Will this make XS-P-V a sort of "Deprecate"? I find the semantic of >X-P2-V clearer than XS-P-V, but I just want to know how hard are you >going to push it (if we're going to migrate to it, it requires a >change a lot of packages) Sort of deprecated, yes. I'd rather focus on getting Python 3 packages right than retrofitting improved semantics on Python 2 packages. If the Python 3 stuff goes well, I think we'll tend to pick this up over time. I believe it's premature to have a strong view on how hard to push it. >> 2. XS-Python-Version: The same as it is currently, except versions 3 or >> greater will raise an error. This will require at least two packages to have >> to be changed. I'd appreciate it if someone could check if anything other >> than python-apt and pyyaml are affected. >> >> 3. debian/pyversions: Same as XS-Python-Version. > >Please, pretty please, can we drop support for it? Is that really an >hassle to remove it? Or there are some advantages of having it around >I don't see? There should be one, and possibly only one, way to >specify python versions. I agree, but it's widely used by python-support. Unless Joss is supportive of moving away from it, I don't think it's manageable anytime soon. >> 4. Implicit "all" supported Python 2 versions (currently 2.5 and 2.6). > >You mean not specifying any X-P2-V or XS-P-V, 'all' is implicitly used >for 2.x supported versions? I'd rather explicit than implicit, so >raise error if not present. I agree on this also, but many, many packages rely on it and so I think we are stuck with it for Python 2. If we encourage people to document their X-P-V at the same time they add X-3P-V, maybe this will become tractable in the future. >> For Python3: >> >> 1. A new field called X-Python3-Version: It does not support lists of >> versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g >> 3.1), >> greater than or equal to a version (e.g. >= 3.1), or strictly less than a >> version (e.g. << 3.2). Versions 2 or less will raise an error. >> >> 2. There is no #2. If your build system uses py3versions -r, then you need >> X-P3-V, if it's not there, an error will be raised. If it doesn't use >> py3versions -r, then it's between the maintainer and their build system. >> The >> field is not mandatory. > >both points fine for me. > If you like this, please convince Piotr that implicit all is bad. 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/fbe738cd-720e-4a41-aaa8-dc7e495c2...@email.android.com