Re: Summary of python transition problems
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
Reply to: