Using the XulRunner tarball

[Randy McMurchy]

Recently, "we" has crept into the book in the section about using XulRunner and then saying to only download Firefox once.

To me, saying to use the Firefox tarball for XulRunner is like saying use the MPlayer tarball for FFMpeg. I would prefer to use the actual tarball for the package. I know that sounds picky, but what if someone only wants T-Bird and uses another browser other than Firefox.

We should revise the text to more accurately describe what is required for any package using XulRunner.

[Randy McMurchy]

It is noted that until T-Bird is released in 3.5 XulRunner format, Firefox is the only potential user of Xulrunner, so the comment above about using another browser is not yet applicable.

[ken@…]

If you look at the releases during the firefox 3.0 series, the xulrunner tarballs were "intermittent", and since trying to make sense of a diff between 2 versions of firefox in the same series is not practical (far too much noise in the diff, probably deliberately so, to obfuscate), why take the risk of building against a vulnerable xulrunner ?

As of gnome-2.28, I believe yelp still uses gecko and so needs xulrunner.

For myself, I've now dropped yelp so I'm happy to do without xulrunner (using separate nss, nspr). For what is in the 6.5 book, I think it's too soon to drop xulrunner.

I have no objection to changing "we" in the book.

[Randy McMurchy]

On the contrary, I didn't mean we should drop XulRunner, I only thought that perhaps we should use the actual XulRunner tarball instead of the Firefox tarball.

I'd bet (and perhaps lose) that as Firefox has been updated many times, there were times it uses the exact same XulRunner code as in the previous version.

But I am no authority on this matter. Better left to Ken and DJ.

[ken@…]

Replying to randy@…:

On the contrary, I didn't mean we should drop XulRunner, I only thought that perhaps we should use the actual XulRunner tarball instead of the Firefox tarball.

Sorry, didn't mean to imply that you did: after 6.5 *I* think we should, but that's for another day.

I'd bet (and perhaps lose) that as Firefox has been updated many times, there were times it uses the exact same XulRunner code as in the previous version.

I make enough bets on things I think I understand. For me, using an older xulrunner would be classed as "pious hope".

But I am no authority on this matter. Better left to Ken and DJ.

/me neither, but if in doubt I tend to apply fixes - if we use the firefox tarball for xulrunner, that is one download (45MB+) per build, and guaranteed to contain the same source used in a standalone firefox.

[Randy McMurchy]

After thinking about this a bit more, I just cannot see the Mozilla developers maintaining more than one Xulrunner tree. Seems they would be smarter than that (it is time consuming and subject to errors to update multiple trees for minor changes).

Additionally, is it just coincidence that the directory name of the unpacked Firefox tarball is for example mozilla-1.9.2, the exact version number of the current Xulrunner tarball? Probably not.

Furthermore, what if one doesn't want Firefox, but needs Xulrunner only? It seems unconventional to download a Firefox tarball for the Xulrunner code when there is a dedicated Xulrunner tarball.

Some current book text:

<para><command>echo "Requires: nspr"

xulrunner/installer/libxul-embedding.pc.in</command>: If you try to build

<application>Yelp</application> without this, the prtypes header from NSPR will not be found. It is arguable whose error this is (the code presumably works on earlier geckos), but this fix is unlikely to cause any damage in other packages.</para>

This must be changed. We cannot be saying that damage is "unlikely", because that means there is a chance for damage. It should indicate that there will be *no* damage.

I would like to continue to discuss the decision to use the Firefox tarball to install Xulrunner.

[Randy McMurchy]

Not to beat the horse to death, but I feel this is important.

I just diffed Firefox-2.6.3 and Xulrunner-1.9.2. The *only* changes are to configure, configure.in, and Makefile.in (there are also some changes to .hgtag files, but they probably don't affect us).

The changes are to reflect that they call the Hildon Graphics API (formerly just Hildon) to Maemo now (which is the mother project of Hildon).

I just can't see a "vulnerable Xulrunner" ever being exposed. If Xulrunner is vulnerable, that means Firefox is also. Both packages would be updated. I suppose there could be an issue with a user installing Xulrunner and a year later adding on Firefox, then yeah sure, there could be a vulnerable Xulrunner. But a simple note on the Firefox page saying to ensure the most current Xulrunner package is installed probably would eliminate that issue.

[DJ Lucas]

Historically, the XULRunner tarball has lagged behind the Firefox release by a couple of weeks. The last release time was better IIRC. Regardless, I would recommend adding a note about the latest XUL being the same as the Firefox release tarball to save people a 45+ MB download. IOW, point to the latest XUL tarball, but state that if you've already downloaded Firefox, there is no need to download XUL. And in the case you pointed out above, this would actually be better if building bleeding edge. Well maybe not in that case...can you build with external Hildon? What is Hildon?

[Corstiaan]

Replying to dj@…:

What is Hildon?

Hildon is (now) a part of GNOME that provides an application framework to make finger-friendly apps. Basicly makes thing more easy to use with a touchscreen.

[(none)]

Milestone 6.5 deleted

[Randy McMurchy]

Updated milestone to 6.7

[Randy McMurchy]

After actually building and using Firefox/Xulrunner, I know concur with the existing setup and instructions to use the Firefox tarball for both package instructions. Closing the ticket.

[bdubbs@…]

Milestone 6.7 deleted