Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, Jul 16, 2008 at 7:00 PM, Daniel Drake [EMAIL PROTECTED] wrote: I recently modified OLPC-3 xulrunner to remove dependencies on libgnome and gnomevfs2. Once Dennis has had a chance to review my work to remove libgnome deps from other packages too, a huge dependency chain (including metacity, icon themes, and plenty more) will fall out of the build. Therefore it is quite important that OLPC's xulrunner continues to avoid it's dependency on libgnome. The dependency chain there looks suspect. i.e. it's odd that libgnome is bringing in metacity... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Thu, 2008-07-17 at 11:51 +0200, Marco Pesenti Gritti wrote: The dependency chain there looks suspect. i.e. it's odd that libgnome is bringing in metacity... Yeah. It's because libgnome brings in fedora-gnome-theme which then (somewhere along the way) brings in a metacity theme which then brings in metacity. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Help! Summarizing the xulrunner situation in OLPC
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
We will also need to enable pyxpcom in the fedora firefox for Browse to work. Marco On Wed, Jul 16, 2008 at 6:43 PM, Greg Dekoenigsberg [EMAIL PROTECTED] wrote: 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, 2008-07-16 at 12:43 -0400, Greg Dekoenigsberg wrote: 3. These dependencies will be coming back someday in the upstream, when Mozilla makes these hard dependencies instead of soft dependencies. Are you saying that, in future, it will not be possible to compile a xulrunner without printing support? What about the libgnome/gnomevfs 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? So far, I don't think we've been considering space footprints for specific packages. Instead, we have been considering our OS build as a whole: we want to limit it to 300mb, and our F9 builds are currently 45mb overweight. http://dev.laptop.org/ticket/7353 I recently modified OLPC-3 xulrunner to remove dependencies on libgnome and gnomevfs2. Once Dennis has had a chance to review my work to remove libgnome deps from other packages too, a huge dependency chain (including metacity, icon themes, and plenty more) will fall out of the build. Therefore it is quite important that OLPC's xulrunner continues to avoid it's dependency on libgnome. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
Daniel, It is quiet possible we'll want to pick up gnomevfs2 as a basic library in a future release (think about the OLPCfs method of accessing the journal). We didn't want the old gnomevfs library since that pulled in the old bonobo horror as a dependency. I'm not familiar with libgnome, and therefore have no opinion there. - Jim On Wed, 2008-07-16 at 13:00 -0400, Daniel Drake wrote: On Wed, 2008-07-16 at 12:43 -0400, Greg Dekoenigsberg wrote: 3. These dependencies will be coming back someday in the upstream, when Mozilla makes these hard dependencies instead of soft dependencies. Are you saying that, in future, it will not be possible to compile a xulrunner without printing support? What about the libgnome/gnomevfs 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? So far, I don't think we've been considering space footprints for specific packages. Instead, we have been considering our OS build as a whole: we want to limit it to 300mb, and our F9 builds are currently 45mb overweight. http://dev.laptop.org/ticket/7353 I recently modified OLPC-3 xulrunner to remove dependencies on libgnome and gnomevfs2. Once Dennis has had a chance to review my work to remove libgnome deps from other packages too, a huge dependency chain (including metacity, icon themes, and plenty more) will fall out of the build. Therefore it is quite important that OLPC's xulrunner continues to avoid it's dependency on libgnome. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, Jul 16, 2008 at 7:44 PM, Jim Gettys [EMAIL PROTECTED] wrote: Daniel, It is quiet possible we'll want to pick up gnomevfs2 as a basic library in a future release (think about the OLPCfs method of accessing the journal). We didn't want the old gnomevfs library since that pulled in the old bonobo horror as a dependency. I'm not familiar with libgnome, and therefore have no opinion there. I guess you mean gvfs. (gnome-vfs2 is the old one). libgnome is gradually being deprecated too afaik. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, 2008-07-16 at 13:44 -0400, Jim Gettys wrote: Daniel, It is quiet possible we'll want to pick up gnomevfs2 as a basic library in a future release (think about the OLPCfs method of accessing the journal). We didn't want the old gnomevfs library since that pulled in the old bonobo horror as a dependency. I'm not familiar with libgnome, and therefore have no opinion there. My mistake - we already ship gnome-vfs2 and are not dropping it. A sugar component actually requires it. Enabling gnome-vfs2 support in xulrunner should not be an issue. libgnome is the component which is a dependency headache. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, Jul 16, 2008 at 7:48 PM, Daniel Drake [EMAIL PROTECTED] wrote: On Wed, 2008-07-16 at 13:44 -0400, Jim Gettys wrote: Daniel, It is quiet possible we'll want to pick up gnomevfs2 as a basic library in a future release (think about the OLPCfs method of accessing the journal). We didn't want the old gnomevfs library since that pulled in the old bonobo horror as a dependency. I'm not familiar with libgnome, and therefore have no opinion there. My mistake - we already ship gnome-vfs2 and are not dropping it. A sugar component actually requires it. Enabling gnome-vfs2 support in xulrunner should not be an issue. In update.1 we shipped the DBus version of gnome-vfs2 (Nokia patches) which didn't bring ORBit in. I'm not sure if that's still the case in joyride. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help! Summarizing the xulrunner situation in OLPC
On Wed, 2008-07-16 at 19:48 +0200, Marco Pesenti Gritti wrote: On Wed, Jul 16, 2008 at 7:44 PM, Jim Gettys [EMAIL PROTECTED] wrote: Daniel, It is quiet possible we'll want to pick up gnomevfs2 as a basic library in a future release (think about the OLPCfs method of accessing the journal). We didn't want the old gnomevfs library since that pulled in the old bonobo horror as a dependency. I'm not familiar with libgnome, and therefore have no opinion there. I guess you mean gvfs. (gnome-vfs2 is the old one). libgnome is gradually being deprecated too afaik. ah, ok, I was confused. - Jim Marco -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
