On Feb 21st, Sunday, the Gentoo Mozilla Team had an informal meeting
to discuss some of the recent changes which have a large-ish impact on
users. Below is a list of them and the decisions that were taken.
After the list is a description of each decision.
-> SQLite with Firefox: Firefox will use the bundled sqlite by
default. Users can select the system-wide sqlite by setting
USE=system-sqlite.
-> Ebuilds for Extensions in-tree: The Gentoo Mozilla team will not
ship ebuilds for extensions such as noscript and weave anymore. We
will only have ebuilds for extensions which are linux-specific and
compiled; such as enigmail.
-> Firefox and Thunderbird Alphas and Betas: In addition to the
overlay, we are going to start placing alphas and betas of Firefox and
Thunderbird in the tree with a package.mask and a big fat ewarn during
installation. Adventurous users are encouraged try them out but report
bugs only in the Gentoo bugzilla. Do not go to upstream unless we ask
you.
NOTE: These ebuilds will not have language packs since upstream does
not release packs for these.
-> NSS/NSPR Changes: This involves various cleanups to the ebuild, and
moving of the libraries from ${libdir}/{nss/nspr} to ${libdir} and
removal of the /etc/env.d/08{nss,nspr} LDPATH entries alongwith
corresponding changes in firefox-bin and thunderbird-bin launchers.
These changes should be completely transparent to the user.
-> Revival of #gentoo-mozilla @ FreeNode: The mozilla team has
expanded in recent times, and with that we have decided to revive the
ages-old #gentoo-mozilla irc channel. Users are welcome to idle,
discuss, and ask for help on that channel. Come on over!
=========================
Why we made these decisions:
=========================
NOTE: These are very link-heavy, so you might want to view them in
html at:
http://bheekly.blogspot.com/2010/02/gentoo-mozilla-team-meeting-decisions.html
====
SQLite with Firefox: We've done flip-flops on using the
system-installed sqlite for for XULRunner and Firefox. Initially, we
used the internal one, but folks reported bugs[1][2][3] about that (we
prefer not to use bundled libraries), so we switched to the system
sqlite.
Then with the next version of Firefox, people started reporting major
bugs[4][5] with using the system sqlite and we temporarily disabled
it. Once the problems were resolved, we added USE=+sqlite to use the
system-installed sqlite by default.
Recently, another issue cropped up: upstream mozilla was getting bug
reports that the sqlite db was insecure, and trivial tools like grep
could be used to get (private) deleted information from it. They
traced that to distros using the system sqlite which didn't have
support for SQLITE_SECURE_DELETE. They then made that a mandatory
configure check with 3.6 (and we added a dep on the system sqlite for
it). Soon, we started getting bug reports[6] from people who did not
want that enabled system-wide (since it zeroes out the data when
deleting it, which has a performance penalty). Upstream made it clear
that they would not make the check optional[7].
In the end, we decided to make firefox use the internal sqlite by
default, and allow the user to select the system installed sqlite via
USE=sytem-sqlite if they are ok with secure-delete being on
system-wide.
====
Ebuilds for Extensions in-tree: We found that a number of extensions
were being released at a very swift rate which meant two things:
1. Bumping ebuilds was very tedious, which led to them becoming
stale very quickly[8][9]
2. Judging whether an ebuild can go stable was not possible, and
most often the extension developers just want the users to use the
latest release.
This offset the benefit of users being able to install extensions
system-wide and have it managed by portage. Users can still manually
install and manage system-wide extensions if they so wish. They are
also free to copy the old ebuilds to their local overlays and use them
if they wish.
====
Firefox and Thunderbird Alphas and Betas: Mozilla Upstream has been
complaining that their betas and release candidates don't get much
testing on Linux since all the distros ship only the final releases.
This means that bugs are caught very late, and aren't fixed till the
next major version. To help with this, we've decided to revise our
release strategy and give a bit more visibility to our alphas and
betas (which are generally kept in the overlay[10]) by pushing them to
the tree under package.mask, and with large ewarns all over the place.
Users are strongly advised NOT to report bugs with these directly to
upstream. Please use the Gentoo Bugzilla.
====
NSS/NSPR Changes: the libraries for nss and nspr were installed in a
prefix due to collisions with other packages (libssl.a for instance).
Recently, Google decided to use portage for cross-compiling and
managing ChromeOS. This combined with some bugs reported[11][12] with
NSS/NSPR led to some investigation, and a voluntary review[13][14] of
the ebuilds by the nice folks at Google.
This led to a number of changes which included disabling static
libraries for NSS and NSPR, and moving the rest to ${libdir}. Further
details on the changes and their "why" are listed on the review bugs
linked above.
====
1. http://bugs.gentoo.org/show_bug.cgi?id=228637
2. http://bugs.gentoo.org/show_bug.cgi?id=258462
3. http://bugs.gentoo.org/show_bug.cgi?id=303028
4. http://bugs.gentoo.org/show_bug.cgi?id=281695
5. http://bugs.gentoo.org/show_bug.cgi?id=283083
6. http://bugs.gentoo.org/show_bug.cgi?id=304913
7. https://bugzilla.mozilla.org/show_bug.cgi?id=546162
8. http://bugs.gentoo.org/show_bug.cgi?id=297214
9. http://bugs.gentoo.org/show_bug.cgi?id=295252
10. http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git
11. http://code.google.com/p/chromium/issues/detail?id=32081
12. https://bugs.gentoo.org/show_bug.cgi?id=302807
13. https://bugzilla.mozilla.org/show_bug.cgi?id=545037
14. https://bugzilla.mozilla.org/show_bug.cgi?id=545036
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
