Re: Python policy proposed changes
To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?
I don't know. What is the answer to this question? I wouldn't expect
it to be more than 1GiB per mirror, though, likely much less. On
i386, for example, the "useless" python2.[124]- packages for example
seem to add up to 59MiB, if I counted correctly.
Even in a situation like the current one, when we're stuck with 2.3 as
the default when there's 2.4 available, there are only a few python
packages which actually need the 2.4 version.
What do you mean, "actually need"? Every python2.3-foo package actually
needs python2.4. If you have only python2.3-foo installed, and do
~$ python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named foo
This is because python2.3-foo installed into python2.3's site-packages,
so it won't be available in python2.4. You really need a separate
package for 2.4.
In this case, the policy
states they should be built as python2.4-foo, until python2.4 becomes
the default. That's also why modules needed by a lot of binary packages
should be built as multi-binary packages, as there is a probability a
script requires both modules.
This I don't understand. You mean, a script might require both
python2.3-foo and python2.4-foo if foo contains an extension module?
But I'm not talking about python-gtk here, I'm talking about those
hundreds of modules actually used by zero or one binary packages. Do we
need multi-binary packages for them? Compared to the waste of human and
computer resources this implies, I'm pretty sure it's not worth the
deal.
It's a policy decision, obviously. I wonder how many users you have
interviewed or what other criteria you have used to decide what is
best for the users. IOW, even if this policy is chosen, it lacks
rationale, IMO.
Of course, supporting versions older than the default version is rarely
needed, except when there are applications that require such older
versions. So when 2.4 becomes the default, only 2.4 (and perhaps 2.5)
packages should be built.
Don't you understand that it's even more added work to remove the legacy
python 2.1 to 2.3 packages in hundreds of packages ?
It is more work, but I don't understand why it is significantly more
work. Maintainers just have to remove all traces of 2.1, 2.2, and 2.3.
from their debian directory, and rebuild, no?
Anyway, it's hardly "hundreds of". I counted 194 python2.3- packages,
82 python2.2- packages, and 46 python2.1- packages. There are also
125 python2.4- packages, so the majority of the packages has already
prepared for the transition.
Regards,
Martin
Reply to: