Help! Summarizing the xulrunner situation in OLPC

[Greg Dekoenigsberg]

So today I had a meeting with Christopher Aillon, the maintainer of all 
things Mozilla in Fedora, and it helped greatly to shape my understanding 
of the issues around xulrunner for OLPC and/or Sugar and/or Fedora.

My proposed goal is to maintain a xulrunner package in Fedora that meets 
the needs of OLPC.  Why?  So that (a) the Browse activity (which imho is 
the most important activity in Sugar with the possible exception of 
Journal) can run natively in Fedora without forcing naive users to figure 
out how to resolve package conflicts; and (b) OLPC is not forced to carry 
a forked xulrunner, and the maintenance headaches that go along with it.

So here's the current situation, as I understand it; caillon and others, 
please correct me if I go astray:

1. xulrunner, with all dependencies, takes up "a lot" of space on the 
target system, for some definition of "a lot".  Printing support, for 
instance, brings a whole chain of dependencies along with it.

2. In an effort to cut down on space, OLPC has built its own xulrunner 
that breaks these dependencies.

3. These dependencies will be coming back someday in the upstream, when 
Mozilla makes these hard dependencies instead of soft dependencies.

If this analysis is correct, it forces us to answer some key questions.

1. Space.  What are the real space requirements for the xulrunner 
dependencies?  Do we have any hard numbers that we can analyze?  Is it 
reasonable to carry all of the dependencies along in OLPC?  How were the 
decisions made to leave out certain pieces of the xulrunner dependency 
chain, and can those decisions be revisited?

2. Future.  My understanding of how the dependencies will move in the 
future from "soft" to "hard" is incomplete.  When these changes happen, 
what will be the exact impact on people who are trying to maintain a 
slimmed-down xulrunner that breaks these dependencies?

--g