Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 11:45:32PM +0200, Matthias Klose wrote:
> 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
I'm not sure about this. I do use libkpathsea, but I'm not sure about
how long it takes for migrating to testing.
> - the extension is required as a dependency for a package not using
> the default python version.
The package is not required by any other packages, and I don't ever
envision that happening.
> 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).
Hmm... this seems like a worthwhile thing to support.
Basically, I think that adding support for multiple Python versions to
my package will not be used, since I expect that the package will only
be used with the current version of Python. On the other hand, it sounds
like supporting multiple versions will help with transitions.
I'm not sure which side I should take, but I suppose that I'm leaning
towards supporting multiple versions, since that would make it easier on
others.
Comments?
--
gram
Reply to: