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

Re: Python talks at DebConf

[Barry Warsaw, 2010-05-10]
> Note that today is the first day of the Ubuntu Developer Summit for Ubuntu
> 10.10.  On Thursday we are going to have a session to discuss the roadmap for
> Python on Ubuntu and what version(s) we will ship by default in 10.10.  I
> invite your constructive input in this thread about issues that you'd like to
> see discussed.

IMHO derivatives should not add new versions to the list of supported
Pythons and most probably not change default Python version as well (it
should be OK to remove a version from supported ones[0]). We cannot tell
derivatives what to do, though. I'd never complain in public and would
let you do whatever you want (that's derivative's right after all)... if
Ubuntu's decisions would not have so strong impact on us - when I'm
forced to do something (specially when I have to do it in one month or
so), I try to resist by default, even if changes are good for me in the
end, like dist-packages or /usr/local by default change introduced in
Ubuntu (good changes need testing too!).

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,
* 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,
  - breaking perfectly valid XS-Python-Version or debian/pyversions,
  - 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]),
* 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),
* because we're supporting upgrades from oldstable only (do you know how
  many packages in Ubuntu are suffering from missing/too many
  Conflicts/Replaces/Provides: pythonX.Y-foo?) (this argument is
  actually semi related, as you cannot do much if we will drop support for
  one of versions and you still support it in LTS)
* because of crazy ideas like implementing "include-symlinks" in
  python-support or using virtualenv in Debian packages as workarounds ;-P

[0] if you will also drop all packages that depend on it even after
[1] gaupol works in Ubuntu only because I pointed Scott to it, nobody
    noticed it in Ubuntu (and I know it wasn't working with python2.6 only
    because I always read changelogs / debdiffs of packages I maintain)
    Note that gaupol is not the only package of mine that needed a sync with
    Debian and I do not maintain that many packages...
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Reply to: