Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : > § 2.3.3, 2.4.2, 2.5.3, 2.6.2: > *here* the python$version alternative is correct, > because /extensions/ can be used with a '/usr/bin/python' as soon > as the python current version is in their supported range. > > so take the previous algorithm, and add to (2): if current python > version isn't in that range, add an alternative to the pythonX.Y > corresponding to the range lower bound. Meaning that in my test > cases, instead of *SHOULD NOT HAPPEN* you will get: > > python (>= 2.4) | python2.4 > > and in fact, wrt Depends, the algorithm for pure modules or > extensions, private or public is the same. I forgot to explicitely mention that when extensions are in the package, then you have to restrict your 'python' range to the range of the python for which extensions have been built. That seems obvious, but it has to be stated in the policy very clearly. That means that if you ship a .so for e.g. 2.3, 2.4, then your python depends will be: python (>= 2.3), python (<< 2.5) even if the pyversions is 2.1- about debian/pyversions, unlike his brother XS-P-V it does not supports all/current. for python support you have to use sth like 2.1-. current explicitely says that the package is only built for the current python version, and not for any other supported in debian. But I don't like that value for the following reasons: * it says for what the package is built, whereas other values explain for which range of python versions the package is build-able, so semanticaly it's not homogenous ; * it prevents the packager to explain with which python versions the package is compatible, as saying 'current' suggests that the package is now compatible with the current python version, and will always in the future, wich may be wrong when (if that happen) some python 3.0 that is not 100% backward compatible should exists ; * it also give an information we already have as a package that is built for the current python version should depend upon python-dev and not python-all-dev ; * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. so IMHO the "current" value should be documented as an internal pycentral value, and should not be recommended to be used for other ways of python packaging. OTOH, I thing "pysupport" should also support "all" as it's prettier than 2.1- and more explicit to the packager, and then it could go into the policy as a recomended value in that case. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp5LvK707rOK.pgp
Description: PGP signature