[ubuntu-mono] [Bug 740815]

[Jorendorff]

> (In reply to comment #30)
> (Apologies if this is bikeshedding or a repeat of previous discussion)

(Well-aimed kick to the shins)

I don't think anything has changed since comment 5. See the last three
paragraphs there.

> Since we're deliberately changing the name, maybe libspidermonkey is a better
> name? I agree that putting 185 in the name isn't good. When we change to 1.9.0,
> would we have to change the SO name? That can't be right.

It isn't ideal, but it reflects reality. I would be thrilled to ship a
SM with no stupid version number in its name. We should totally do that,
as soon as have a sane upgrade story. First things first.

Fixing SM versioning was a non-goal for this release. Help us get it
right in the next one.

(In reply to comment #32)
> I don't think it matters a lot, honestly.  I really would rather we ship. 

This, with a bullet.

-- 
You received this bug notification because you are a member of Ubuntu
CLI/Mono Uploaders, which is subscribed to mono 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:
  In Progress
Status in “couchdb” package in Ubuntu:
  Fix Released
Status in “gluezilla” package in Ubuntu:
  Confirmed
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:
  New
Status in “libreoffice” package in Ubuntu:
  New
Status in “libreoffice-l10n” package in Ubuntu:
  New
Status in “mono” package in Ubuntu:
  Confirmed
Status in “mozvoikko” package in Ubuntu:
  Fix Released
Status in “packagekit” package in Ubuntu:
  Fix Committed
Status in “swt-gtk” package in Ubuntu:
  Fix Released
Status in “xulrunner-1.9.2” package in Ubuntu:
  In Progress
Status in “xulrunner-2.0” package in Ubuntu:
  Confirmed

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.