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 versions, but if you are developing for python, you should use the default version and that's all. > 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 > and two major versions have been released after it. My opinion is that > if there are too packages, lets drop old versions of python from sarge > (like python2.1 and python2.1-*). Yes, I agree that we should remove all unnecessary python packages. > 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. > 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... Again, why would you want to use a different version from the default? When I'm speaking of widely used modules, I think there should be about a dozen of them, not 113. > This is a good question... I'd like to adopt python-gd, I found a bug > which require the module compiled for old versions of python... What I > have to do? How can I choose to consider it enough diffuse and widely > used to package it also for old versions of python? And which versions? > Only python2.2 or also python2.1? 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. -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
