Re: Summary of python transition problems
Colin Watson writes:
> On Sun, Oct 05, 2003 at 11:40:50AM +1000, Donovan Baarda wrote:
> > On Sun, 2003-10-05 at 02:55, Matthias Klose wrote:
> > > Donovan Baarda writes:
> > > > The second problem is is when we get python (2.4), a new python2.3
> > > > package will need to be released just to fix the dependencies. The
> > > > Python Policy was designed so that no pythonX.Y(-foo) packages would
> > > > need to be updated when python (X.Y+1) is released.
> > >
> > > not true. the 2.3 upload is needed for not building the unversioned
> > > python packages.
> >
> > Hmm, I forgot about that. Is this a hassle? Would it be possible, and
> > would it help, to have "python" built from it's own empty source
> > package?
>
> 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 ...).
IMO it depends on the amount of packages that explicitely depend on
python2.3.
But maybe an upload of the current python2.3 packages (without
changing the default version) to testing would help as well in this
case.
Matthias
Reply to: