On Friday, for better or worse, I marked stable the current versions of the mozilla-* ebuilds. These were pushed to stable quickly because of security issues (98855 98846) in the older versions, plus extension compatibility problems in mozilla.org’s first attempt at releasing a security update. Here are the versions that went stable:
mozilla-launcher-1.41.ebuild
mozilla-1.7.10-r1.ebuild
mozilla-firefox-1.0.6-r2.ebuild
mozilla-thunderbird-1.0.6-r2.ebuild
mozilla-bin-1.7.10.ebuild
mozilla-firefox-bin-1.0.6-r1.ebuild
mozilla-thunderbird-bin-1.0.6-r1.ebuild
If that seems like a long list to you, well it does to me too! Along with the security fixes, these ebuilds carry along a large number of improvements:
-
post-installation chrome registration is handled by mozilla-launcher’s update_chrome() and the -register argument to the binaries. This is a huge improvement over dropping in an “initialized” tarball during src_install and hoping it worked. (It also starts us on the road to including extensions as separate ebuilds in portage, which was completely impossible before.)
-
The multilib-awareness of mozilla-launcher and the ebuilds has been improved via the MOZILLA_LIBDIR variable that is set in the stubs. This obviates the old multilib patch that was being applied to mozilla-launcher and allows us to change the installation directories far more easily.
-
Speaking of changing the installation directories, we now install to /usr/lib/mozilla-firefox and /usr/lib/mozilla-thunderbird instead of /usr/lib/MozillaFirefox and /usr/lib/MozillaThunderbird respectively. This was a purely aesthetic change, but one that certainly demonstrates that it can be done!
-
The mozilla-launcher stub in /usr/bin is installed by install_mozilla_launcher_stub() from mozilla-launcher.eclass. That makes installation of the stub generic and rescues us from some of the duplication in the ebuilds.
-
Plugins shouldn’t clash now because we’re no longer moving them around and creating symlinks, instead we’re setting MOZ_PLUGIN_DIR in mozilla-launcher.
-
The ebuilds have been re-organized and synchronized, which means that they should be easier to maintain in the future.
Maintaining the mozilla stuff takes a lot of effort. A huge amount of effort. More effort than I can give it right now… This will be my last weekend working on the mozilla ebuilds. Starting Monday, I intend to leave their care and feeding to the rest of the mozilla team. It seems like a good time since this week has seen so many improvements and we’re mostly stable now.
Since that’s the case, here are some things that have been on my mind, which I hope the rest of the mozilla team will see through. Terminology note: I use “browser” to refer to any of mozilla, firefox or thunderbird.
Extensions in portage
Ideally, it would be nice to build enigmail (and possibly other extensions) as separate ebuilds in portage. I spent quite a while on this problem and was ultimately stumped. First, I tried to build enigmail by massaging the Makefiles to use include files, tools and libs from ${MOZILLA_FIVE_HOME}. Gradually I prodded it along, but finally surrendered to the notion that enigmail wants to be built in an unpacked mozilla or thunderbird tree.
So I pursued using a stripped-down thunderbird ebuild, based on instructions on the enigmail site, especially the later paragraphs that talk about building it more quickly. I got quite a long way with that, but could never get it actually working once it was installed. Finally, I came across a message that indicated that installing global extensions in 1.0.x is difficult/broken. I also found suggestions that 1.1 will make global extension installation easier. My personal conclusion: Wait for thunderbird-1.1 to build extensions in portage.
Some people have been very unhappy that I took enigmail out of the thunderbird build in the first place. The reason it was taken out was that the build wasn’t working in my testing, even on thunderbird-1.0.2. For some reason the build process that we’ve been using for enigmail in mozilla and thunderbird stopped working for thunderbird. It seems to still work for mozilla, so I’ve left it there.
Note to the mozilla team: Nathan Adams says he has something working. The only difference I can see between his effort and mine is that he’s using make instead of emake. It would be worth following up on this, trying to get it back into the thunderbird ebuild, until it can be properly split out for thunderbird-1.1.x
Unmerge and -unregister
Recent versions of mozilla-launcher sport a new -unregister argument and associated remove_chrome() function. The point is to be called in pkg_prerm() so that the package can be completely uninstalled instead of leaving the generated bits on the filesystem. The ebuilds haven’t been modded yet for that, though, so there’s a task for somebody.
Patches
One of the reorganization steps I took recently was to sort the patches in src_unpack() into architecture-specific, general compilation issues, and behavioral changes. Furthermore, I made the sorting mostly the same between the packages, so it should be possible to, for example, do a meaningful diff between the current versions of the browser ebuilds.
A couple things I noticed: First, there is an alpha stubs patch being applied in all the ebuilds. Is that still necessary? Is the patch the same in all the ebuilds, and therefore could it be moved to ${DISTDIR} as I’ve done for some of the other patches?
Second, not all of the architecture patches are applied in all the ebuilds. For example, there is an hppa patch that is applied inconsistently. What’s the story with that?
There are gcc4 patches being applied all over the place. Are those in reality a common patch that could be applied from ${DISTDIR}?
Presently there are a few bugs open recommending cherry-picking patches from Fedora and Ubuntu. I’d urge you guys to be careful about that. Some of the patches are worthwhile and some are not. The closer you stay to upstream sources, the easier it will be going forward. Usually Gentoo has made a point of staying close to upstream, and I think that’s the right route for the browser ebuilds. Just my humble opinion…
A final thought on patches: Right now many of the patches are applied from either ${DISTDIR} or ${FILESDIR}. It might be advantageous to roll the current set into a versioned tarball that is common for the browsers. You could keep the tree of patches in subversion along with a script for generating the tarball and putting it on the mirrors. That would reduce the number of downloads people are doing per-ebuild.
Plugins
The plugins problem is this: many packages (for example acroread and java) provide plugins written to the netscape API, which is supported by the browsers. These plugins aren’t found by the browsers by default, because they only look in ${MOZILLA_FIVE_HOME}/plugins
The original solution to this problem was architected by Azarah in nsplugins.eclass: The plugin ebuilds would call inst_plugin to create a symlink from the plugin to /usr/lib/nsbrowser/plugins. In src_install, the browser ebuilds would move their own plugins to /usr/lib/nsbrowser/plugins and make ${MOZILLA_FIVE_HOME}/plugins be a symlink to that dir.
This worked for a time, but was relatively difficult to maintain in the ebuilds, and had the negative effect that the files in /usr/lib/nsbrowser/plugins were owned by multiple packages.
Recently I attempted to solve this problem a different way: First I created a patch which I thought would add /usr/lib/nsbrowser/plugins to the default search path for plugins. Second I removed the code from the ebuilds which would move the browser-installed plugins. I was hoping this would allow both browser-installed and third-party-installed plugins to be found automatically without all the hackery.
However the patch didn’t work (I don’t know why yet…) so instead I resorted to setting MOZ_PLUGIN_PATH=/usr/lib/nsbrowser/plugins in mozilla-launcher. For all intents and purposes, this works! It only has a couple small issues, such as removing the user’s ability to set their own MOZ_PLUGIN_PATH.
Whatever solution the mozilla team chooses for this problem, I’d suggest first trying to make the patch work. It can’t be that hard, I’m just out of steam! If that doesn’t work, then consider sticking with the MOZ_PLUGIN_PATH solution. The least desirable solution is one that moves plugins around and makes more symlinks, because that perpetuates the old nsplugins.eclass complexity and makes full unmerge of the browser difficult.