Re: dh_python and python policy analysis
On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek <vorlon@debian.org> said:
> On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:
>> 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.
> AFAICS you've correctly described the requirements for this
> scenario, but this is not the scenario that I've been trying to
> point out to you.
> Now, introduce version 2.0 of python-foo. Because upstream
> considers python 2.3 obsolete, they have begun using language
> features in their module (internally, not as part of the module
> interface which remains unchanged) that are specific to python 2.4
> and above.
This is similar to the case 4b in my scenario: a package
changes from supporting all known versions of python to supporting a
subset of that range. As in my case 4B, you don't take this action
lightly, while there is python2.3 in the archive, you do a
conditional import of the old version of the module in order to
retain the compatibility, or you talk to your rdependsand tell them
about the change.
> Now, looking at your example:
>> The following transition events occur.
> No disagreements on 1) and 2).
>> 3) Python2.3 is dropped.
>> policy A policy B no upload. Upload python-foo, removing provides
>> for 2.3
> Why does python-foo need to drop the provides for 2.3? In what way
> does python2.3's removal from the archive mean that python-foo has
> stopped supporting python2.3?
Because when python2.3 is removed, the site-packages directory
would also be purged of all automatically compiled versions of the
pure python modules. Indeed, I think this is already done; and
minimizes the house cleaning packages have to perform.
> Also,
>> 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
> This is a case where I don't see any need to reupload foo under
> policy B: it already has all the provides it's going to have, since
> it didn't yet know about python2.6 and therefore couldn't have
> declared any provides for it, no? So python-foo Provides:
> python2.5-foo because bar-baz is written for python2.5 and needs it;
> bar is AFAICS written to use "python", so only depends on
> python-foo; and baz has to wait.
Well, if you are not going to upload, you can't be using
python-support or python-central as the tools to automatically
compile your module -- and unless you have changed the .versions file
or XS-Python-Version variable, They'll try to compile, and may leave
a miscompiled version around, depending on how subtle the 2.6
incompatibility is.
===========================================================================
1) Python 2.5 is added | no upload. python-foo | Upload python-foo,
| recompiled for 2.5 | adding provides for
| | 2.5
| No transition for | package bar-baz must
| package bar or | wait the upload.
| bar-baz |
----------------------------------------------------------------------
2) Default python | |
version changes to | |
2.4 | |
----------------------------------------------------------------------
3) Python2.3 is dropped| | Upload python-foo,
| | removing provides for
| | 2.3 (since presumably
| | the compiled files
| | are gone
----------------------------------------------------------------------
4) Python 2.6 is added.| |
A) Source change fix | Package uploaded, with| Package uploaded, with
| changed source. | changed source, and
| | the provides.
| package baz has to | package baz has t
| wait | wait
B) Do not support 2.6 | Package uploaded, with| Upload with changed
| provides, rdepends | versions for byte
| apprised, mini | compiling tools??
| transition |
| package baz has to | package baz has t
| wait | wait
----------------------------------------------------------------------
5) Default python | |
version changes to | |
2.5 | |
----------------------------------------------------------------------
6) Instead of python2.6| Package uploaded, with| Upload with changed
New version of foo | provides, rdepends | provides
incompatible with 2.4 | apprised, mini |
added | transition |
===========================================================================
I posit that 1-3,5 are the common cases; and 4A is more common
than 4B or 6.
>> 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.
> Given that a reupload isn't generally needed for 3), and my premise
> that pure python modules should only declare Provides when something
> exists in the archive which actually *needs* them, I think the
> uploads between 1) and
> 4b) would nearly cancel out, making it a win to avoid the need for
> post hoc
> Conflicts.
This means that my package would be uploaded every time there
is someone who needs a provides, and god only knows when and how
often that happens; the simple way out is to declare all possible
provides, and the hell with the transitions. Since I have limited
time, and don't like the waiting around for the shoe to drop when
someone somewhere in the 15k packages out there decides they like my
module.
No, I still think that instead of a fuzzy Oh, I'll only
declare a dependency when someone asks nicely; the simpler rule is to
only have provides when your module supports a subset of all
versions of Python, and ask for a transition of your rdepends if you
transition from "support all" to "support fewer than all" versions of
Python (you can keep compatibility provides around for a bit when
transitioning back).
This reduces the common case of re-uploading every module when
a new version of Python is introduced; at the cost of requiring a
mini transition when a pure python modules package stops supporting
all known python versions -- a far less common case.
manoj
--
Watch all-night Donna Reed reruns until your mind resembles oatmeal.
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: