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 <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
