Colin Watson writes: > On Tue, Oct 07, 2003 at 07:28:23PM +0200, Matthias Klose wrote: > > Colin Watson writes: > > > For what it's worth, I think a python-defaults source package or some > > > such would help: at the moment there are several packages needlessly > > > stalled on python2.3, even though their dependencies are simply > > > 'python2.3 (>= 2.3)' or similar. If the python binary package were built > > > from a separate source package then we could decouple transitions from > > > the task of keeping the versioned packages up to date. > > > > It does help for python applications, which depend on an explicit > > python version. I did not count packages with a 'python2.3 (>= 2.3)' > > dependency. > > > > It does not help for library packages building a python-foo binary > > package. For this case you would have to separate this binary package > > to build from it's own source (but maybe this could be built from the > > python-defaults package as well ...). > > Hmm. How many python-foo binary packages are there? (I count 138 in > testing. Ouch.) How feasible would it be to have at least some of the > core ones all built from a hypothetical python-defaults? > > This is blue-sky - I'm not involved enough in Python to know whether > it's feasible, unfortunately. I have a feeling that it might cause > different problems.
After two python transitions I am unsure if python-foo binary-arch packages are a good idea ... Most packages depending on python-foo have to be recompiled/reuploaded anyway, so having them to explicitely depend on pythonX.Y-foo is not a big burden. The pythonX.Y schema was never meant to allow permanent parallel installation of python versions, but to ease the transition between versions. > > But maybe an upload of the current python2.3 packages (without > > changing the default version) to testing would help as well in this > > case. > > In the absence of the above, it would certainly be helpful in future if > a version of pythonX.Y that satisfies the shlibs in unstable could be > ensured to be safely in testing before changing the default version. yes, but IIUC, this is not needed at them moment due to the transition in Wednesday. > I realize that was difficult this time round because glibc and > gcc-3.3 got in the way. wrong ;-) it was first glibc. Matthias