pyjamas (and dependent) packaging: examples of failure of ubuntu packaging and development process

[Luke Kenneth Casson Leighton]

dear ubuntu developers,

i've been shouting for years quite vocally about various problems i've
seen with ubuntu development, and have been strongly recommending to
the average linux developer, of whom there are a considerable number
on the pyjamas-dev mailing lists, to NOT use ubuntu for _any_ reason.

finally i thought it might be a good idea to simply state what the
problems encountered are, so that you can a) explain to me why, so
that i can then explain to other people b) deal with them - a) or b) i
don't mind which.

the majority of the issues are related to how pyjamas is adversely
affected by the ubuntu development process: i feel certain that
pyjamas is not the only suite of packages affected.

root cause of the problem: The 6 Month Release Cycle

the 6 month release cycle results in picking up "broken" versions of
software; doesn't leave enough time for testing; if it don't work,
it's out, and all rdependencies are just deleted, period.

taking pyjamas-desktop as a specific example: it depends on
python-hulahop.  python-hulahop depends on python-xpcom.  python-xpcom
is - was - part of xulrunner.  python-xpcom has been merely moved into
a "third party" category whilst the mozilla foundation, which is
losing its grip on reality, panics to avert a mindshare and identity
crisis to webkit, and focusses on "speed, speed, speed".

so, _no_ other major linux distribution, not gentoo, not fedora, not
debian, not arch-linux, has yet picked up xulrunner 1.9.2 ... yet lo
and behold, ubuntu has, for the 10 series.  result: OLPC's web browser
has gone, and ... wait... the *entire* pyjamas package has been
destroyed?  when only one of its sub-dependencies has gone?

err... so, there's this broken bit of software, which was picked up
far too early, and, rather than back out and wait for the mozilla team
to fix it... ubuntu _removes_ several pieces of useful software?

please could i have an explanation for this decision.

then - that software is removed _without_ checking whether one of them
is a "multi-package" where only _one_ of the packages
(pyjamas-desktop) in the source package (pyjamas) relies on
python-hulahop and python-xpcom, where all the _other_ packages have
only python and python-support as dependencies?

please could i have an explanation for this decision.

second issue, highlighted by ubuntu 9.04: failure to test components.

the packaging of python-xpcom for ubuntu 9.04 was a total failure.
yes it was built, but it was built so badly that it couldn't actually
be used.  even doing a basic "import xpcom" by the package maintainer
would have showed that it wasn't going to work.

by doing "apt-get build-dep python-xpcom; apt-get source python-xpcom;
cd {pkgname}; dpkg-buildpackage", it could be clearly seen that the
person who built python-xpcom failed to actually use ubuntu 9.04 to
perform the build, because it was impossible to actually build
python-xpcom on ubuntu 9.04

we had to give instructions to pyjamas developers, who are _not_
c-programmers they're python programmers, to download UPSTREAM
xulrunner sources, perform a manual build and then extract xpcom.so
manually, which is a _totally_ unsatisfactory situation in a large
number of ways.

please could i have an explanation for the failures, here.

i believe there were some additional failures associated with
python-hulahop around ubuntu 9.04 as well, but it is sufficient time
ago that i cannot exactly recall.  i seem to remember that hulahop.so
would not work with python 2.6, but would work with python 2.5...
which wasn't installed!

overall, the process is deeply dissatisfactory, and the answer *is
not* "we don't care: it's your problem - go compile everything from
source" because i personally, as a debian developer, do not care
either: what i _do_ care about is that "it's your problem" means "it's
your (plural) problem" i.e. "your problem as pyjamas developers" -
none of whom are c-programmers or ubuntu maintainers.

thus, these people are completely reliant on _you_ - the ubuntu
maintainers - to get this stuff right.  the fedora team got it right;
the arch linux people got it right; debian/testing is absolutely fine,
so what is wrong with the process that ubuntu is following, that makes
this so hard to get right, *especially* when ubuntu is based on
debian?

some answers really appreciated, so that i can talk with confidence to
ubuntu users that they are being looked after, as opposed to me
unequivocably steering them _away_ from ubuntu.

l.