[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
rebuild
[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
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100510112301.gb28...@piotro.eu
