G'day debian-python, Just read the DWN, saw mention of the Python policy, read it, and subscribed to this list to throw in some comments. I note that the policy was posted some time ago, so these comments might be too late.
First off, you need to clarify what you are attempting to achieve. There are three possibile aims as I see it; 1) single "official" version of Python in archive/distro. 2) multiple alternative versions of Python in archive/distro, only one installed at a time. 3) multiple alternatives versions of Python installed at a time. Option 1 means every time Python upgrades, all packages dependant on that version of Python are broken and have to be upgraded, with old versions removed from the distro. Option 2 means every time Python upgrades, new versions of all version dependant python packages are added to the archive/distro at the mantainers lesure. Different versions of packages do not need to co-exist and must conflict with each other. Option 3 is similar to option 2, but different versions must be able to co- exist and shouldn't conflict with each other. Mechanisms need to be in place to ensure the correct version is used as needed. Why would you want multiple versions available/installed? One reason is new releases that are not backwards compatible, requiring old versions to run old software. Another reason is new versions being experimental, so you'd rather default to the old version but experiment with the new one. Your policy seems to be aiming for Option 3... the hardest, but is that really what we want? Option 2 looks viable to me, and is easier to achieve. Option 3 is highly suggestive of using the "alternatives" mechanism, which your policy doesn't mention. The policy says there should be a single python package of the latest version. Only a single package can provide /usr/bin/python. This suggests that when python upgrades, the old python package needs to be re-released as python-X.Y, and a new python package released. This is ugly... better way is to always release Python-X.Y packages, and use some mechanism to select which one is "python". This can be done by all python-X.Y packages providing python. The python-X.Y packages can then either all conflict with each other, or use alternatives to select which is /usr/bin/python. Note that if it is desireable to have a python package for some reason (apt-get funnies, version dependancies etc), then have the python-X.Y packages provide python-base, and have the python package depend on python-base. The policy says that modules should be named python-foo and depend on python- X.Y. This breaks Option 2 and option 3 because it only allows for a single version of python-foo, which will be tied to a particular version of python. In reality there are some modules that are tied to a particular version of python (compiled against them), and some that are forwards compatible with some base version (>=1.5). It would be nice if both types of packages could be handled with a minimum of upgrading required. I suggest modules that depend on python-X.Y should be named python-X.Y-foo, allowing for multiple versions of version dependant modules. Other modules should be named python-foo and depend on python (>=X.Y). The lack of versioned provides makes things a little tricky... it would be nice if python-X.Y could provide python (X.Y), so python-foo could depend on python (>=X.Y) (though even this introduces new problems). Without versioned provides, the best we can do is have installing python version X.Y depend on python-X.Y (ie installing latest python always installs the latest python-X.Y). Note that the same trick would need to be done with python-X.Y-foo packages... have a python-foo version X.Y package that depends on python-X.Y-foo so that other packages can depend on python-foo (>=X.Y). There are heaps of fine details to nut out. I've got some more thoughts on this, but this email is getting long enough, so I'll shut up now :-) -- ABO: finger [EMAIL PROTECTED] for more information.