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

Re: Python talks at DebConf

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 won't add them to Debian, because:

1. No Python 2.6
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

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

>  - breaking perfectly valid XS-Python-Version or debian/pyversions,

Sorry, I am not DD. What is this perfection for?

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

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

anatoly t.

Reply to: