[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python policy proposed changes



Le mardi 18 octobre 2005 à 10:24 +0200, "Martin v. Löwis" a écrit :
> > 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.

I don't understand your approach of the issue. The default python
version is available in the "python" command, and all modules should be
available when launching "python", not "python2.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?

No, I mean a script using the "foo" module, which is only available for
python 2.4, might also require the "gtk" module, as the latter is widely
used. That's a reason to build a module like gtk in a multi-binary
fashion.

> 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.

The rationale is to save mirror size, bandwidth and Packages size, and
to make things clearer to our users. It is your rationale which I wonder
about. You want all modules to be available for all python versions?
What does it bring to our users? When using python, you're using the
"python" binary, you don't want to ask yourself what version to use.

> > 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?

It's the "just" that bothers me. It's not a "just" when you're talking
about rebuilding 200 packages.

> 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.

You mean that's "only" 3 percent of the total number of packages that
could be saved?

Regards,
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom



Reply to: