Re: python 2.3
Thomas Bushnell BSG writes:
> On Wed, 2006-12-20 at 19:51 -0800, Steve Langasek wrote:
> > On Tue, Dec 19, 2006 at 11:17:03AM -0800, Thomas Bushnell BSG wrote:
> > > The python team has apparently decreed that python 2.3 will not be in
> > > etch. This forces every package to use the new version. Surely it is
> > > too late in the release cycle to be risking regressions in this way?
> >
> > The python team has expressed concern about the security supportability of
> > python2.3 in etch. Extension packages built with the current version of
> > python-all-dev and friends already have no support for python2.3; shipping
> > python2.3 in stable for the benefit of a handful of reverse dependencies is
> > a genuine concern, particularly when those reverse-deps work just fine with
> > python 2.4.
>
> And yet, this isn't the only case. Users actually use the programs in
> Debian, not just other parts of Debian. Why is python 2.3 some sort of
> security nightmare? And what suddenly happened to make it one?
python2.3 doesn't get attention by upstream anymore. there was a 2.3.6
release to address a security related issue (which is addressed for
sarge and current testing), but even for the 2.4 series no new
upstream bug fix releases are announced for the future. If you ask why
2.5 isn't the default for etch: by the time upstream versions were
frozen for etch we didn't have new upstream releases for packages
depending on 2.5. it's still difficult at this point of time (Dec
2006) to make 2.5 the default and rely on upstream releases for
depending packages.
An explicitely stated goal of the release team was to reduce the
number of supported python versions for the next stable release. We
did include three python versions for sarge (2.[123]). To reduce that
count we do have to drop 2.3 (prefering 2.5 over 2.3).
> What about users who are depending on Python 2.3? Do they just lose?
yes. and even if the transition to the new default version was late,
you do loose.
> It seems to me that for things like this, our releases should always
> have the next-oldest version as an option for those users.
No. there is no reason to do so. The two reasons we did come up with
the support of more than one python version are:
- some applications are very late to adopt a new python upstream
version (the last version to provide compatibility with 2.4 was
zope2.x). Debian currently doesn't have a process of freezing
packages for a release besides the toolchain.
- the inability to manage the transition of packages from unstable to
testing. If you do want to work around the current migration
process from unstable to testing you have to support the python
version in testing and unstable. Every proposal to just support
one python version in Debian bares any sense of Debian reality.
To conclude, the support of multiple python versions is not meant at
all as an excuse for lazy debian maintainers depending on python for
not following upstream python development.
Matthias
Reply to: