On Wed, 21 Jul 2010, Sandro Tosi wrote:
> Fact is, we should find a way to tight the dependencies on
> python-numpy, for example we can re-inforce some sort of "python-numpt
> (>= MAJOR.MINOR), python-numpy (<< MAJOR.MINOR+1)" (where MAJOR is the
> current major version number, and MINOR is the minor one). That means
> that at each update of major/minor release of numpy, the depending
> packages needs to be binNMU'ed or receive a sourceful upload.
Pardon possible ignorance -- but isn't all the situation with transition
from numpy 1.3 to 1.4 is actually the effect of absent proper transition
in Debian for numpy from 1.3 to 1.4?
Restricting version might be an overkill as a generic solution
since most of the modules (and may be extensions) would not need that
and we do not precisely know what will happen in 1.5 to restrict just
some packages.
So how can we do transitions without involving maintainers for all
dependent projects in regard to their knowledge about compatibility with
upcoming new version? Due to peculiarities of Python it is harder to
assure compatibility even of pure Python modules without extensions with
a transition to a new version, even at pure API level unless there is
100% code coverage by unittests. But assuming that in longer run we
agree on how we invoke unittesting for Python modules we ship,
then for each future transition all dependent modules could easily be
tested to unveal bad cows:
if unittests (against installed version) are ok:
pass
elif re-build (including unittests against re-built version) is ok:
binNMU
else:
ring the bell
Or am I simply hallucinating and missing the point?
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Attachment:
signature.asc
Description: Digital signature