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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
