firefox/mozilla/libnspr packaging change

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

firefox/mozilla/libnspr packaging change

Ian Jackson-3
We've had an IRC conversation about what to do about mozilla/firefox's
depedents and libraries.

There are two classes of other programs which depend on stuff
currently provided by firefox or mozilla:

  I.  Packages which embed the browser (eg, epiphany, oo.o.)

  II. Packages which use libnspr as generally useful libraries
      (there are lots of these).  (libnspr is the Netscape
      Portable Runtime; I will use `libnpr' to include libnss, the
      Netscape Security Services library, too.)

Currently, class II packages get libnss from mozilla, both at
build-time and at run-time.  Class I packages get everything from
firefox.  They Build-Depend on firefox-dev, and the resulting binaries
Depend on firefox.

This has at least two bad properties:

 * The mozilla suite cannot be relegated to universe because of the
   many (class II) packages in main which depend on it for libnspr.

 * There are two different (but supposedly functionally equivalent)
   versions of libnss on the system.  It is quite possible that some
   programs may accidentally confuse the two versions which might lead
   to incorrectly-linked programs.

We propose to change the situation as follows:

 * The firefox source package will ship libnspr{4,-dev} packages which
   will look just like the ones currently shipped by mozilla.

 * The firefox.deb will be changed to Depend libnspr4 rather than
   including a copy of the libraries.

 * The situation with firefox-dev will remain unchanged.  Class I
   programs (embedders of firefox) will contine to use firefox-dev and
   build in the usual way.

This will solve the two problems identified without needing
significant changes anywhere outside firefox's build system, and even
there the changes should be relatively well-contained (even if we need
to have a symlink or two).

Possible trouble will be handled as follows:

* ABI change to libnss:

  We can if we choose just upgrade the firefox package and the
  relevant sonames, breaking compatibility.  Alternatively, we could
  choose to fork the firefox source package to make a
  firefox-old-libs.  firefox-old-libs would have a build system hit
  over the head to generate only only the libnspr4.deb.

* ABI change to embeddable firefox:

  This will definitely be a pain.  Since any embedder will Depend on
  exactly the right ABI version, and since you can't coinstall two
  firefox packages, you won't be able to coinstall
  oo.o-built-against-ff1 and epiphany-built-against-ff2.  We hope that
  this will only occur during distribution-upgrade and we have given
  up on incremental upgradeability anyway.  So we will just take the
  hit here.  Only class I packages are affected; luckily there are
  only a few of them (although they're usually big in themselves).

* Bugs in libnspr which mean we want to have different libnspr
  versions for firefox and for applications in general:

  If this happens and we can't fix it easily so we don't have that
  requirement, we can either revert to the previous arrangement (ie,
  using the mozilla package), or create a separate libnspr source
  package built from upstream libnspr.

Ian.

--
ubuntu-devel-announce mailing list
[hidden email]
http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce