On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]