Matthias Klose <[EMAIL PROTECTED]> writes: > It already exists: > > deb http://ftp-master.debian.org/~doko/python ./
So, it will exist soon. > > > > s/major//. Correct. Assume we release woody with python (2.1), and we > > > > 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. 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 my propsal would be: make a python1.5-xml package (separate source > package), and one of: > > - a python-xml package (for 2.1) > - a python-xml (2.1), a python2.2-xml package > - a python-xml (2.1), a python2.1-xml, a python2.2-xml package 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? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://marant.org