Re: Proposed Email to the release team about XS/B-P-V

[Jakub Wilk]

* Piotr Ożarowski <pi...@debian.org>, 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:




Here are some real world examples (for 2.X, but that's irrelevant):

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. * 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)

--
Jakub Wilk

If you implement this, I will refrain from doing any QA work on python3-* packages. Have fun.

signature.asc
Description: Digital signature