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: