desktop-packages team mailing list archive

[Randall Leeds <740815@xxxxxxxxxxxxxxxxxx>]

Sorry to revive an old thread, but I wanted to voice my thoughts for
posterity. Right now the embedder's story is something like:

1) Look for js-config. If found, use it to find the sdkdir, then do feature detection to figure out what JSAPI version it is.
2) Otherwise, look for libmozjs185
3) ... or for libmozjs
4) ... or for libjs

I'm glad to see that the mozilla-central repository has not taken the
versioning used here into the library name upstream. I encourage
everyone involved in releases not to worry about getting the JS language
version involved in the library naming at all. It may often be of much
less importance to an embedder whether the language changed slightly as
whether the embedding ABI changed, so please stick to ABI compatibility
when deciding version numbering for the library and keep one library
name. I suspect backward-incompatible language changes are less frequent
than ABI changes and much of the JS world is used to feature-testing for
language compatibility anyway due to the variety of language versions
and features supported by browsers. Furthermore, embedders who _do_ care
about the language version can look at the define in jsversion.h.
Changing library names just complicates things needlessly.

Thanks for all your hard work.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-python-extras in Ubuntu.
https://bugs.launchpad.net/bugs/740815

Title:
  [FFe] Updates to enable us to drop xulrunner from main

Status in The Mozilla Firefox Browser:
  Fix Released
Status in “couchdb” package in Ubuntu:
  Fix Released
Status in “gluezilla” package in Ubuntu:
  Fix Released
Status in “gnome-python-extras” package in Ubuntu:
  Fix Released
Status in “gtk-vnc” package in Ubuntu:
  Fix Released
Status in “gwt” package in Ubuntu:
  Fix Released
Status in “icedtea-web” package in Ubuntu:
  Fix Released
Status in “libreoffice” package in Ubuntu:
  Fix Released
Status in “libreoffice-l10n” package in Ubuntu:
  Fix Released
Status in “mono” package in Ubuntu:
  Fix Released
Status in “mozvoikko” package in Ubuntu:
  Fix Released
Status in “packagekit” package in Ubuntu:
  Fix Released
Status in “swt-gtk” package in Ubuntu:
  Fix Released
Status in “xulrunner-1.9.2” package in Ubuntu:
  Fix Released
Status in “xulrunner-2.0” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: xulrunner-2.0

  Based on the new Firefox release schedule
  (http://people.mozilla.com/~sayrer/2011/temp/process.html), we need to
  drop xulrunner from main as unsupportable, else I'm going to risk
  spending nearly 100% of my time continually providing support for this
  across up to 5 stable releases, when most applications using it are in
  universe and probably aren't interesting to much more than 1% of our
  users.

  This is a catch-all-bug driving that work.

  The plan of action is:

  couchdb -  We will introduce a libmozjs source package for main,
  totally decoupled from the Firefox release process. This will be used
  by couchdb (and possibly other spidermonkey embedders in univese in
  the future)

  icedtea-web -  Firefox already provides an SDK now. We will build
  icedtea-web against Firefox rather than xulrunner. It seems that
  icedtea-web only really needs Firefox or xulrunner to do a version
  check in order to decide whether to turn on some XPCOM bits (which are
  turned off when built against newer Firefox builds). We should
  consider making this a pure NPAPI plugin and drop the mozilla
  dependency entirely (but perhaps not Natty timeframe)

  swt-gtk - We will update swt-gtk to the stable 3.6 2 release, turning
  on webkit support and turning off mozilla support. This requires some
  updates to applications in universe which hardcode SWT.MOZILLA.

  libreoffice-l10n/libreoffice - declares a build-depend on xulrunner-
  dev, so we need to investigate why and see if we can remove that.

  gtk-vnc - has a xulrunner-dev build-depend purely for the NPAPI
  headers. We can build this against firefox-dev, but it really should
  just ship its own headers (NPAPI is cross-browser anyway)

  gnome-python-extras - this is a tricky one. The only thing I can think
  of now is to turn of python-gtkmozembed and drop everything which uses
  it (not sure how popular that would make me)

  mozvoikko - this is a firefox extension with binary components anyway,
  so must be built against firefox (xulrunner and firefox versions won't
  be kept in sync in the future anyway)

  packagekit - has a build-depend for the NPAPI browser plugin. Same as
  above really - either ship its own headers or build against firefox-
  dev.

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/740815/+subscriptions