Re: Python policy proposed changes
Le mardi 18 octobre 2005 à 02:57 +0200, "Martin v. Löwis" a écrit :
> Josselin Mouette wrote:
> > Apart from a typo and the FSF address, the changes are about which
> > packaging variants are mandated, recommending to provide only one
> > python-foo package for each module, except when depending applications
> > mandate another python version.
> >
> > This way, we could enforce that policy during the transition, removing
> > hundreds of cruft python2.X-foo packages.
>
> I don't like this policy. the python2.X-foo are not at all cruft; they
> provide a useful feature.
To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?
> With the multi-version build, you can support Python versions more
> recent than the default python version, which is useful for people
> who would like to use more recent versions: they don't have to rebuild
> all their extension modules themselves.
To avoid this, as states the policy, the latest python upstream should
be the unstable version. Furthermore, is this needed that badly? It
isn't possible to use a more recent perl version, but I don't see that
many complaints from perl users.
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. 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.
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 also simplifies the transition from one Python version to the next:
> people can build and test their packages against newer versions long
> before Debian updates the default. That way, when the default version
> changes, they just have to turn a switch in the default package. This
> reduces the amount of work necessary in the transition phase itself.
You're completely wrong. Based on the 2.2->2.3 experience, multi-binary
packages complexify the transition a lot. Instead of just a rebuild,
they require adding the new version and removing the older ones, on a
case-by-case basis, before going through the NEW queue. Believe me, it's
more work for everyone.
> 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 ?
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: