[Exherbo-dev] Merging XULRunner and Firefox
Wouter van Kesteren
woutershep at gmail.com
Thu Feb 9 15:06:56 UTC 2012
I would like to merge xulrunner and firefox into one.
REASONS TO MERGE:
1. Mozilla seems to actively discourage separating xulrunner. The
documentation says it's a bad idea because upgrades to xulrunner might break
stuff and the install documentation says you need to copy xulrunner to the
./xulrunner/ directory. With the rapid release cycle this has become a
bigger issue. Even in firefox itself it is not fully supported. After
firefox's `make install` symlinks and wrappers are required to actually make
it work. Not to mention g++:4.6 causing segfaults when xulrunner is separated.
2. Firefox is very tightly coupled to xulrunner. So tight that only a specific
version of xulrunner is usable by firefox at any one time. So if we where to
say hold xulrunner 10 back because it was incompatible with vlc we would also
be missing out on firefox 10 automatically. The same is true for the opposite,
if we want xulrunner 10 for security fixes we can no longer use firefox 9.
3. Another problem is the way its distributed. The configure is the same for
both xulrunner and firefox. This means that even though firefox doesn't
require something, the configure still checks for it and thus we have to
depend on it for it to build. This means firefox currently has the majority of
xulrunner dependencies and configure switches. And all patches to the
configure (libvpx-1.0.0 support for example) will have to be doubled.
Effectively doubling all maintenance work.
PACKAGES THAT NEED TO CHANGE FOR A MERGE:
Packages that depend on xulrunner can fit into the following three categories.
webkit? ( net-libs/webkit:3.0 )
xulrunner? ( dev-libs/xulrunner[>=2.0] )
spidermonkey? ( dev-libs/spidermonkey )
!spidermonkey? ( dev-libs/xulrunner:=[>=7.0] )
libproxy's scm has a commit that says:
> Only support mozjs185 as valid mozilla pacrunner backend. Xulrunner is no
> longer trackable from upstream due to the lightning fast movement of the
> Firefox source base. Also, Mozilla does not support usage of xulrunner from
> other apps.
The libproxy exheres should apply the patch and depend on spidermonkey instead
gjs has done the same which makes it hard-depend on mozjs185 and no longer
on the xulrunner/firefox versions. The gjs exheres just needs to hard-enable
the spidermonkey part and drop xulrunner support. (The masked gjs-1.31.10
already does this)
Packages that need it to build a plugin:
nsplugin? ( dev-libs/xulrunner )
nsplugin? ( dev-libs/xulrunner[~8.0] )
mozilla-plugin? ( dev-libs/xulrunner[>=1.9.1] )
These packages could in theory simply be changed to depend on net-www/firefox.
Building firefox in addition to xulrunner would only add like 5 minutes on a
compile time of 1+ hours so the overhead is negligible.
HOWEVER icedtea-web and vlc also support npapi-sdk.pc (currently two
versions, one from gentoo and one from openSUSE) which is a lightweight
replacement for building plugins. This would make it easyer for say chromium
users to build nsplugins without pulling in xulrunner.
gcc does not support npapi-sdk but does support firefox-plugin
Packages that require a XUL-runtime:
If upstreams followed the mozilla install guide it will be bundled with a copy
of xulrunner for which the app is written. Currently there are no exheres that
depend on xulrunner for a XUL runtime other than firefox so this category
isn't that important at the moment to begin with.
STEPS TO REALIZE THE MERGE:
1. switch libproxy/gjs over to spidermonkey
2a. merge xulrunner into firefox
2b. make gcj-jdk, icedtea-web and vlc depend on firefox
3. package npapi-sdk
4. make vlc and icedtea-web depend on npapi-sdk
Maybe with step 2a there should also be a news item for people who have
xulrunner installed so that they are aware that they need to move the options
to the firefox package. But I'm not really familiar with news items. Some
advice on this option would be welcome.
So are there any objections or additions to all of this? Things i missed?
-Wouter van Kesteren
More information about the Exherbo-dev