Re: dh_python and python policy analysis
Hi,
OK, I see I have to dot the i's and cross the t's for this
case here. So, here is the scenario: package python-foo packages a
public pure python module. Package bar imports the module
foo. Package baz is a package not yet written that would be written
for Python2.6 that would also need module foo, but only when
we actually get python2.6. Let us also have a package bar-baz that is
written for python2.5.
Also, ket us assume the module foo would work for versions
2.3, 2.4, 2.5 -- but in the yet unreleased version 2.6, stuff
changes, and module foo would not be compatible as written. OK?
State of Python at the start of the thought experiment: current
is 2.3, available is also 2.4, and let us pretend no one has
heard of 2.5 or 2.6 yet.
With me so far?
Now we have two policy proposals, A, and B. A decrees that
python-foo depends on python, ad has no provides. Policy B requires
that python-foo also provide python2.3-foo and python2.4-foo.
The following transition events occur.
1) Python 2.5 is added.
policy A policy B
no upload. python-foo recompiled Upload python-foo, adding
for 2.5 provides for 2.5
No transition for package bar package bar-baz must wait
or bar-baz the upload.
2) Default python version changes to 2,4
3) Python2.3 is dropped.
policy A policy B
no upload. Upload python-foo, removing
provides for 2.3
4) Python 2.6 is added.
Here there are two cases. Either module foo can't be written at all
for version 2.6, or it the same functionality can be provided with
a code change, perhaps hidden behind a version conditional.
How often have people seen a regression in Python that
something that was doable for version N can't be done at all in
version N + 1?
4a) foo can be coded for version 2.6
Policy A policy B
Package uploaded, with the changed Package uploaded, with the
source. package baz has to wait changed source, and with
the provides. Package
baz has to wait.
4b) foo can't be written for version 2,6, or will take time, and
support for 2,6 is dropped (at least for the moment)
Policy A policy B
Package uploaded, with provides, Package uploaded, with provides
Packages bar, bar-baz, and baz Package baz has to wait.
(rdepends python-foo) informed of
the provides. Need to upload the
rdepends
Now, most pure python packages will never see option 4 at all;
and those that do, a number will be case 4a.
Even for the case of 4b, there is time to do the transition
for packages bar and bar-baz -- until 2.6 becomes the default, there
is no critical bug in bar or bar-baz.
Now take this to every single pure python module package in
Debian, multiply with the upload by default for every single
addition or removal of python packages, and you can see that adding
more work in the corner case 4b is worth not having to upload
packages multiple times by default.
manoj
--
I used to be Snow White, but I drifted. Mae West
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: