Re: Coordinated effort to update python packages

[Matthias Klose <doko@cs.tu-berlin.de>]

Graham Wilson writes:
> On Tue, Jun 13, 2006 at 11:22:27PM +0200, Piotr Ozarowski wrote:
> > Graham Wilson (graham@mknod.org):
> > > Speaking of this, I have a module (python-pyx) that I think is only used
> > > by end-users (not applications), so I think it makes sense to only
> > > install modules and extensions for the current version. Does this make
> > > sense?
> > 
> > What if default python version will change? You will have to reupload
> > your package.
> 
> That would happen anyway for new Python releases, plus, my understanding
> is that with the new Python framework in place, supporting new Python
> versions can be handled simply by bin NMUs in the case that I can't make
> an upload myself.

that is correct. OTOH, each new upload to unstable may add a new
dependency on a newly uploaded library having a more strict dependency
or a new soname. If you build for the version we transition from, and
for the version we transition to, we even don't need that binNMU
anymore. Once the python change did migrate to testing and we drop
support for the old supported python version, you can binNMU the
package.  So you should provide extensions not only for the default
version,

 - if you depend on shared libaries which take long to migrate to
   testing

 - the extension is required as a dependency for a package not using
   the default python version.

One other side effect: If we include python2.5 in the set of supported
versions in an upload to experimental, we can easily check all
packages for python2.5 compatibility (building at least).

Matthias