Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[jerome.marant@free.fr (Jérôme Marant)]

Matthias Klose <doko@cs.tu-berlin.de> 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 <jerome.marant@free.fr>
              <jerome@marant.org>

http://marant.org