[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dh_python and python policy analysis



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: pgphJkcZhkaK6.pgp
Description: PGP signature


Reply to: