Jérôme Marant writes: > Matthias Klose <[EMAIL PROTECTED]> writes: > > > But I don't want all my python packages to be uninstalled because > > > python changed. This is unacceptable. > > > > So you simply set the new python packages on hold, until all packages > > you need are converted. What's wrong with this approach? > > It is wrong because people will have to put their packages on hold: not > everyone is familiar with holding packages.
This will happen in unstable only for a period of one week. You won't see this in testing. People running unstable should expect some breakage for a limited time. We minimize the time of unstability be letting maintainers know when the upgrade will happen. Why the heck do we have unstable? > And if they use daily upgrades or dist-upgrades, they can be surprised > to see the packages they are using everyday being removed. > > This won't happen if the package depends on a precise version of python: > the upload of the new python can happen without any problem and the module > maintainer will change dependencies on this new python, so modules packages > will be smoothly upgraded. so please explain us how you would do the upgrade. On the current packages we do have _unversioned_ dependencies. > > So my propsal would be: make a python1.5-xml package (separate source > > package), and one of: > > > > - a python-xml package (for 2.1) pro: package maintainer only needs to support one version. con: you only support one version. > > - a python-xml (2.1), a python2.2-xml package > > - a python-xml (2.1), a python2.1-xml, a python2.2-xml package basically the same, I would prefer the latter if you think that python2.1-xml will need to stay if we switch to 2.2. > What are the pro and the cons for each one? (except from 2.2 is > not out yet)? > Could we decide on this through the policy? No. We could decide that you need at least to provide the package for the default version ;-) Personally I would like to see basic modules be provided for each python version available in Debian. Matthias