Re: Python modules for every supported version
On Wed, 2004-06-16 at 09:08, Josselin Mouette wrote:
> Le mar 15/06/2004 à 19:09, Fabio Tranchitella a écrit :
> > In stable there is a python-slang compiled for python2.1, in testing and
> > unstable there is a python-slang compiled for python2.3... What about
> > python2.2? If I apt-get python2.2, why I can't use slang?
>
> Why would you want to use python2.2? If there are several versions of
> python, this is because of a few packages incompatible with the newer
There are various reasons why you might need a non-current Python
package. Typically it is for a legacy Python application that has not
yet been "upgraded".
In the days when the Python policy was being put together, Python
transitions were non-trivial, and even though the 2.2 -> 2.3 transition
was relatively painless, there is no reason to assume that future
transitions will be as minor. Even now, there are still several
applications, including Zope, still running on python2.2, when the
default is python2.3 and has been for some time.
If we were to revert to a "only one version of Python" policy, we would
be faced with the choice of delaying Python upgrades until _everything_
has been upgraded, or regularly breaking many important Python packages
until they "catch up" with the latest Python. For applications like
Zope, you would never have a working package, because it seems to be
perpetually dependant on the "latest-1" version of Python.
> > I know the number of packages in Debian is becoming a problem, simply I
> > don't uderstand why python2.1 (and a lot of modules for python2.1) are
> > available in testing (which will be stable soon) if it is an old version
[...]
> Yes, I agree that we should remove all unnecessary python packages.
I agree, where unnecessary is defined as; there are no packages that
depend on this package that do not have a python2.2 version, and the
maintainer wants to have it removed.
Package dependencies can be used to check that removing it doesn't break
something, but maintainers of individual packages have the best idea of
how important legacy packages are for that particular package.
> > Josselin: I don't agree, but I understand what you said... But IMHO
> > the python transitions are made easier also with a dummy package which
> > depends on the default current versions of python packages.
>
> Wrong. Let's take the example of such a package: when python2.4 is
> introduced, the package will have to be rebuilt with a version for
> python2.4, presumably removing the python2.2 version. Then, when the
> transition is here, making python2.4 the default, you just rebuilt it
> with a different default package. Fine, but that makes 2 uploads. If the
> upload for python2.4 wasn't done, at the time of the transition you have
> to make several changes in the packaging in order to enable python2.4.
> This makes the job more difficult for NMUers at transition time, and
> this method is prone to introducing packaging errors. On the other side,
> if the package is built for a single python version, you just have to
> rebuild it without any change in packaging when the transition comes.
The original idea behind the policy was that all the "legacy packages"
for python2.3[-foo] are a byproduct left behind from when python2.3 was
the "default". There would be no reason to upload new python2.3[-foo]
packages when python2.4 becomes the default. There would also be no
reason to upload new python2.4[-foo] packages that were uploaded before
python2.4 became the default. The only thing that would need uploading
is new python[-foo] dummy packages that toggle the default from
python2.3[-foo] to python2.4[-foo].
Unfortunately the policy missed the point that the python[-foo] packages
and python2.4[-foo] packages are generated from the same python2.4[-foo]
source package, and it is source packages that are uploaded, not
binaries. This means that the upgrade requires uploading a new
python2.4[-foo] source package that generates a python[-foo] binary
dummy package, _and_ a new python2.3[-foo] source package that doesn't.
IMHO this is where the current policy is very broken. It doesn't achieve
its original objective. There are other flaws and unresolved issues too,
but this is the big nasty from a package maintainers view. It is also a
PITA from the end users point of view because they get extra updated
pythonX.Y[-foo] binary packages just because the source changed to
generate a new python[-foo] package. Even worse, this was part of the
reason that Matthias decided to make python2.3 depend on python(>= 2.3),
which totally screwed up the 2.2 -> 2.3 transition for many users.
The obvious "least changes" solution would be to introduce python[-foo]
source packages that generate the dummy wrapper python[-foo] binary
packages. These packages should do any necessary stuff to define and
transition the default python version. The pythonX.Y[-foo] source
packages should only generate the corresponding pythonX.Y[-foo] binary
package, and should have no dependencies on any python[-foo] packages.
However, this does introduce another source package... dunno how package
maintainers feel about that. However, maintaining the small python[-foo]
source should be minor compared to having to support legacy
pythonX.Y[-foo] source packages every transition.
I'm willing to put in some time on making something like this work...
> > This is
> > my personal opinion: I think if Debian supports python2.x, should
> > supports every python2.x module without differences between widely
> > and not widely used modules...
[...]
The original idea was that legacy support would be a free byproduct of
the process. It was never the intention to have package maintainers
burdened with legacy support. The legacy packages could then "hang
around" as long as they were still useful, and be killed off when
weren't, at the maintainers discretion.
> If you're wondering whether to package it for several versions, the
> answer is simple: don't. We only maintain a single version of perl, and
> the reason why we maintain several versions of python doesn't justify
> having more than a hundred modules built for several python versions.
> There is only one default python version, and the modules should be
> built for this version. Other versions are nothing more than legacy for
> incompatible applications.
I bet Perl transitions are more painful than the Python transitions.
supporting one and only one version doesn't allow gradual transitions.
This has advantages and disadvantages. From an end users point of view,
Perl transitions in unstable are more pain.
The real answer why to not package new "legacy support" packages is; if
no-one needed them for python2.2 before, why would they need them now?
Anything that needs it now will be new, and hence should be using the
latest "default" python. OTOH, if you know people need it and you are
prepared to make it, then sure, go for it :-)
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: