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

[Luke Kenneth Casson Leighton]

On Sat, Jul 3, 2010 at 3:09 PM, Carlos Ribeiro <carribeiro at gmail.com> wrote:
> Disclaimer: I'm not a member of the ubuntu-devel team, and I only follow
> this list to keep up with the news.
>
> I think you have a point, but the way you put it doesnt' help.

 ... i get that a lot.  trouble is: i drastically tone things down,
and i _still_ get people saying exactly the same thing.  so, i'm not
"giving up", but... y'know what?  i'm just going to have to live with
that, state the facts and my opinion of them, so that people on the
receiving end have a clear and unambigous idea of the kind of effect
that they are having on developers...

 ... and leave it at that.  i really apologise, but there's not a lot
i can do about this, without going into incredibly obsequious and
patronising phraseology, glossed over the top of every single
paragraph and probably sentence as well, which i guarantee will drive
people nuts (myself included).

 so, for those people who _are_ irritated at what i've pointed out,
i'm really sorry, but you'll just have to take it on faith that that
"irritation" is a) in your own mind b) not intented to _cause_
irritation but to *demonstrate that irritation has occurred*.

> And people
> that COULD help solving your issue most probably willl not get involved.

 deep joy :)  ah - correction: it's not "my" issue.  i am... merely
the go-between / messenger, the one between "the process", which
holistically, is failing, and the end-users, who are on the receiving
end of that process failure.

 so, for the sake of not associating "people" with anything _at all_,
so that there can _be_ no "irritation" or "blame", let's call it "the
issue" and "the process".

> Instead of blaming the six month process, or the lack of component testing,
> it would be way better to put forward a proposal to help solve the
> defficiencies you pointed out.

 ok.  yes.  it didn't occur to me to do that, initially: i wanted to
guage peoples' reactions, first, get a response, see if there's a
collective "ownership" of responsibility for solving "the issue".

 so, thank you for asking, and prompting me.  i'm going to cc someone
(phil hands) whose opinion on the root cause of the problem i entirely
agree with (phil, could you check i got this right?)

 in reading this, it's important that you know, carlos, that i read
what you wrote (even though i am not including it here) and it seems
eminently sensible... yet is a "patch" on top of an underlying root
cause: lack of resources.

 so the root cause of the problem is, i believe, that the ubuntu
repository should never have been a "total" fork of the debian
repository.

 it's really as simple as that.

 what _should_ have happened is that ubuntu became an increasingly
large number of "replacement" packages, likely maxing out somewhere
around... 300 to 500.  the naming conventions on .deb packages allows
for "upgrading" by adding suffixes: this should have been - should be
- utilised to great effect.

there should have been - should be - a continuous "push" process into
debian/unstable, with coordination between ubuntu developers and
debian developers (paying the latter a token fee, on a per-package
basis if necessary, to avoid them feeling like they're being "used"),
with the ultimate aim (probably never met, but that's ok) of the
*entire* ubuntu repository being absorbed into debian.  even if it
means changing the names of "coreutils" to "coreutils-debian" and
"coreutils-ubuntu"; for each package to be changed to "Provides:
coreutils", and thus for users to literally be able to do "apt-get
install XXXX-ubuntu" on a debian system and vice-versa and LITERALLY
change their system from pure debian to ubuntu or vice-versa WITHOUT
unintentional consequence.

there should have been - should be - an automated "mirror" system
which takes those packages which have accidentally dropped out of
debian/testing but which those 300-500 ubuntu-specific packages still
happen to rely on (temporarily or otherwise).   as a
specific-versioned package drops out of debian/testing (because it got
replaced by an updated version which was in debian/unstable), the
automated mirror would re-add the missing (old) package to the ubuntu
mirror, and flag up an alert to the developers (wark, wark, wark).
the developers then have the choice:

* permanently add that package to ubuntu
* recompile the dependencies to use the new debian/testing version

in the case where packages rrreally don't shoe-horn even into the
superset called "debian", _that's_ the time when an entirely new
package is created (with "Provides: ...." etc. if needed), thus
increasing the 300-500 ubuntu packages to 301-501.

this approach - especially the automated mirror - would be very very
useful for other mirror maintainers such as debian-multimedia.org:
it's often the case that debian-multimedia packages get "out-of-date"
and start ripping apart a debian/testing system (seen it happen
several times) because various dependencies get removed before the
debian-multimedia packages are recompiled.

so the problems that debian-multimedia has are those that the ubuntu
developers should learn from, because, upscaled and solved, that's the
approach that i believe will work extremely well.


there are several critical critical advantages to this approach:

* if there's a screw-up, users can fallback to the [working] debian
versions of the exact same packages.  this solves the specific problem
that the pyjamas ubuntu users are having.  all i need to is add an
entry into the FAQ: "ok to solve the problem of python-xpcom having
been deleted and xulrunner having been messed up, do XYZ and you will
still have an ubuntu system, correctly using the underlying working
debian packages".

* the ubuntu "process" is falling apart at the seams due to lack of
resources.  by riding directly on the back of the debian repository
and _staying_ there, the hard work done by the debian developers and
users _directly_ transfers over to the ubuntu system.  if the ubuntu
"process" gets too far ahead in its "innovation", users can always
take a step back (see above).

* the "innovation" you refer to, carlos, which i believe is actually
more like "extremely risky experimentation", _has_ to coordinate with
the debian "stability", to a much greater extent.

ok, so that's what i think should be done.  basically *ABSOLUTELY*
insist that debian be added to /etc/apt/sources.list. period.
*REMOVE* all duplicate ubuntu packages which are identical to
debian's.  make an automated mirror service which keeps steady the
debian/testing "moving targets" on which the (few remaining) ubuntu
packages critically depend.


to solve the specific issue faced by pyjamas users, right now, there
are several solutions:

a) back out the "innovation" of the xulrunner / firefox upgrade.  it's a mess.

b) return the xulrunner packaging in ubuntu to that of debian.
_including_ adding back in the package "python-xpcom", which was
removed/merged into xulrunner in ubuntu 9 and then the xpcom.so
library was REMOVED from ubuntu 10 entirely, probably because someone
went "what the heck's that doing there?? get rid of it! there aren't
any dependencies, those packages hulahop and pyjamas desktop depend on
xulrunner, they'll be fiiiiine" which is the whole reason why this
mess exists: deviation from the debian packaging.

c) create and maintain two separate xulrunner packages: one for
firefox, and one for everything else (miro, sugar-hulahop,
pyjamas-desktop).

d) include xulrunner as a self-contained dependency as part of the
firefox package.  xulrunner is designed to be installed in multiple
locations: the run-mozilla.sh script takes care of everything, so this
should not be particularly hard to do.  this would then leave
xulrunner (and python-xpcom) as *separate* packages, on which firefox
does not depend, and everybody is happy.

this latter is probably the most sensible option (with c being the
fall-back, and b being the _really_ sensible option)

* firefox packaging from the mozilla foundation is basically a
self-contained tarball, executing from its own local subdirectory.
actually splitting it out into separate packages is actually harder
work!  solution: make the firefox package simpler and self-contained,
including xulrunner.  _that_ version won't need xpcom.so, because
firefox doesn't use it (nooobody uses pyxpcomext and if they do, they
can download firefox from the mozilla foundation, or compile from
source)

* the version of xulrunner, on which sugar-hulahop, miro and
pyjamas-desktop depend, can be left at the "older" and working
packaging.

so, that solves that problem, too, in a way that allows "innovation"
(which i will always read as "risky experimentation") as well as
"stability".

so that's what i believe should be done.

i leave you with this - even though it's not something that the ubuntu
developers are going to want to hear, but it really does have to be
said: ubuntu is literally _the_ only major linux distribution with a
consistently failed pyjamas-desktop and sugar-hulahop installation,
for over one year, probably going on 18 months in the case of
sugar-hulahop.

* FC13 successfully added pyjamas last month: i didn't even know about
it.  i accidentally encountered it, grabbed FC13 live CD, installed it
in qemu, tested it... and it just worked.  _including_
pyjamas-desktop, and they're using Firefox 3.6.

* arch linux has a working pyjamas / pyjamas-desktop package, as of last week.

* gentoo / funtoo have a working pyjamas / pyjamas-desktop package, as
of... about two months ago.

* freebsd, bless 'em, only have pyjamas 0.5 (from over a year ago).
you can't have everything :)

none of these free software teams are paid to get this stuff in there.

so if all these free software teams can get it right, and some of them
are using the same (or very similar) versions including
minor-version-numbers of the dependencies (xulrunner 1.9.1.N) then
surely a company with *paid employees* should be able to be the
_leader_ in the field, not the also-ran.

please don't take offense at me pointing that out, or take it to
heart, but instead take it at face value.  this is the situation:
ubuntu is behind, and i think you'll agree that it should not be.

l.