The Mozilla Platform on SUSE

As CODE10 bugfix mode is almost over now I want to give a short overview what’s coming on the Mozilla front in SUSE Linux 10.2 timeframe with focus on the “Mozilla platform” aka XULRunner aka GeckoRuntimeEnvironment (GRE) and so on.

So the first thing to mention is that the Gecko roadmap states that Gecko 1.9 will not be ready within our deadline and therefore we can expect to have Firefox 2, Thunderbird 2 and SeaMonkey 1.1 in the SUSE Linux 10.2 release. It also means that we won’t have XULRunner 1.9 but a 1.8.1 release. That’s important to know and I’ll come back to this later.

With SUSE Linux 10.1 (and all other CODE10 products) we are shipping the packages mozilla-xulrunner and its development subpackage gecko-sdk in versions 1.8.0.x. This has changed already in FACTORY (which is our moving development tree) and now there are the following packages:

  • mozilla-xulrunner180 (replaces mozilla-xulrunner)
  • mozilla-xulrunner180-l10n (new subpackage containing toolkit localizations other than en-US)
  • mozilla-xulrunner180-devel (replaces gecko-sdk)

The naming change and some other changes within the package were made to make it possible to have different versions of XULRunner installed on one system. As you can see there is still only one version allowed from a major Gecko release. So the next packages which will appear on FACTORY are mozilla-xulrunner181 etc. and some time in the future (if versioning scheme doesn’t change) mozilla-xulrunner190. There are also changes to adopt the structure and naming scheme according to Ben’s (XULRunner project lead) proposal which is primarily meant for version 1.9 and I don’t want to change the filesystem locations for the 1.8.0.x versions to keep it as compatible as possible with our released package. The upcoming 1.8.1.x package will most probably still follow the same directory structure. (Please note that I still have to figure out some details to make minor version upgrades possible without breaking applications embedding libgtkembedmoz.so using rpath or environment tricks.)

Coming back to the consequence of the unavailability of XULRunner 1.9 in 10.2 timeframe.

In short: Nothing will change 😉

Long description:

Applications using libgtkembedmoz.so will still have to use workarounds to be able to find the correct version of the library. (see Novell bug 184911) In most cases this workaround is using rpath. Please see what’s coming with XULRunner 1.9 in the future. Every application using gtkmozembed should use this linking strategy when XULRunner 1.9 is finally there.

Share