On May 18, 2010, at 11:42 PM, anatoly techtonik wrote: >On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski <piotr@debian.org> wrote: >> >> Why I think derivatives should not add new versions? >> * because it's mostly chasing numbers - I'm pretty sure there are not >> more than 10 packages that require Python >= 2.6 and are not easy to >> port to 2.5 in Ubuntu 10.04, > >Backporting is a waste of time, Python 2.6 adds new tasty useful >functions that I use for my packages and do not want to support Python >2.5. I'm in a similar situation with my own packages, most of which these days are spun out of my Mailman 3 work. They will only support Python 2.6 and it is a waste of time to try to back port them. >I won't add them to Debian, because: > >1. No Python 2.6 But maybe they can make it to unstable or experimental or very soon now squeeze <wink>. >2. I still do not know how >3. Non-Python toolchain is obscure >4. I do not feel like to wasting time learning Debian Policy Tomes >5. I already know virtualenv These are all problems that both Debian and Ubuntu suffer from, IMO. I wouldn't be surprised if just about every Linux distribution suffers from it too. We have huge documents filled with policies, lots of wiki pages, gobs of tools, and enormous amounts of lore in people's heads. It all makes for a very difficult navigation for the newbie. Truth is, Python has this problem too. TOOWTDI is a nice slogan, but not really true in reality. It's just that we know what we know and once that newbie is shined off of us, we forget what we didn't know. ;) >> * because when you have to convert hundreds of packages, without >> checking them carefully (most packages in Ubuntu don't have maintainer >> assigned to them) you end up with "fixes" like: >> - disabling tests, > >Which tests can fail on newer Python versions? I though newer Pythons >are backward compatible, except Py3k. They are *mostly* compatible, but they cannot be fully 100% backward compatible. Modules and features go through a well defined deprecation cycle, __future__ imports get turned on by default, etc, etc. Why just today we had a discussion in #debian-python about string exceptions(!). Those have been deprecated for at least 3.5 years and yet there's still (what Piotr, 100+?) packages in Debian that still use them. (I can understand the confusion about this. Reading PEP 352 would imply that string exceptions will only be deprecated in Python 2 and not removed until Python 3. However, the What's New in Python 2.6, and empirical evidence says that they were removed in Python 2.6. I honestly don't remember that decision being made.) >> - hardcoding "-I /usr/include/python2.6" in debian/rules (yes, 2.5 was >> still in supported when I saw it) >> or no fixes at all (>100 packages that FTBFS, ignoring broken >> XS-Python-Version or debian/pyversions, packages that build >> correctly, pass all tests... and do not work[1]), > >Looks like a major failure of Debian to be a common base for >derivative distributions for Python apps. If there are such problems, I hope that Debian can find ways to make this easier for derivatives. This relates to my previous question about how best to sync work done for Ubuntu for Python 2.7 back into Debian. >> * because new version often means changes in helper tools (cdbs, >> debhelper, python-central, python-support) and you're risking the >> situation where we will not like your implementation and will rewrite >> them in incompatible way (and that will mean you will have to rewrite >> them again), > >That's why helper tools should be Python based and crossplatform, like >the Python itself. And there should be OOWTDI. :) -Barry
Attachment:
signature.asc
Description: PGP signature