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

Re: dh_python and python policy analysis


        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

        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.

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: