Re: Python policy proposed changes
On Tue, 2005-10-18 at 08:23, Josselin Mouette wrote:
> Le mardi 18 octobre 2005 à 02:57 +0200, "Martin v. Löwis" a écrit :
> > Josselin Mouette wrote:
[...]
> 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.
Just because there are no Debian packages that depend on them, doesn't
mean they aren't used. A simple example is python2.1-mysqldb. I'm pretty
sure there would be no Debian packages that use it, but anyone
developing/testing for python2.1 that needs to talk to a mysql database
will need it. The fact that Ubuntu has it made my life much easier...
> > 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.
This is why I suggested that the policy recommend seperate python-foo
and pythonx.y-foo source packages for multi-version support. Have the
pythonx.y-foo source package build all the pythonX.Y-foo binary
packages, and have a simple python-foo source package build the small
binary python-foo wrapper package. This way, when python transitions,
only the small python-foo source package needs to have it's dependencies
updated, so only the small python-foo binary wrapper package gets
re-built. The pythonx.y-foo source package and pythonX.Y-foo binary
packages don't need to be touched.
> > 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 ?
So why remove them? If they aren't being re-built, they are not being
updated, and hence are not being re-mirrored. Sure, they are using disk
space on the mirrors, but it's not that much, and they are not eating
bandwidth, which is the bit that really hurts.
Rather than add the burden of removing legacy packages into the
transition process, by de-coupling them Python can transition first, and
then the legacy packages can be kept or removed at the individual
package maintainers discretion later.
This only applies to multi-version supporting packages...
--
Donovan Baarda <abo@minkirri.apana.org.au>
Reply to: