Applications and bundled libraries

LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

Package installation for Linux distributions has traditionally separated libraries and application binaries into different packages, so that only one version of a library would be installed and it would be shared by applications that use it. Other operating systems (e.g. Windows, MacOS X) often bundle a particular version of a library with each application, which can lead to many copies and versions of the same library co-existing on the system. While each model has its advocates, the Linux method is seen by many as superior because a security fix in a particular commonly-used library doesn't require updating multiple different applications—not to mention the space savings. But, it would seem that both Mozilla and Google may be causing distributions to switch to library-bundling mode in order to support the Firefox and Chromium web browsers.

One of the problems that distributions have run into when packaging Chromium—the free software version of Google's Chrome browser—is that it includes code for multiple, forked libraries. As Fedora engineering manager Tom "spot" Callaway put it: "Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought." For distributions like Fedora, with a "No Bundled Libraries" policy, that makes it very difficult to include Chromium. But it's not just Chromium.

Mozilla is moving to a different release model, which may necessitate distribution changes. The idea is to include feature upgrades as part of minor releases—many of which are done to fix security flaws—which would come out every 4-6 weeks or so. Major releases would be done at roughly six-month intervals and older major releases would stop being supported soon after a subsequent release. Though the plan is controversial—particularly merging security and features into the minor releases—it may work well for Mozilla, and the bulk of Mozilla's users who are on Windows.

Linux distributions often extend support well beyond six-months or a year, though. While Mozilla is still supporting a particular release, that's easy to do, but once Mozilla stops that support, it becomes more difficult. Distributions have typically backported security fixes from newer Firefox versions into the versions that they shipped, but as Mozilla moves to a shorter support window that gets harder to do. Backporting may also run afoul of the Mozilla trademark guidelines—something that led Debian to create "Iceweasel". The alternative, updating Firefox to the most recent version, has its own set of problems.

A new version of Mozilla is likely to use updated libraries, different from those that the other packages in the distribution use. Depending on the library change, it may be fairly straightforward to use it for those other applications, but there is a testing burden. Multiple changed libraries have a ripple effect as well. Then there is the problem of xulrunner .

Xulrunner is meant to isolate applications that want to embed Mozilla components (e.g. the Gecko renderer) from changes in the Mozilla platform. But xulrunner hasn't really committed to a stable API, so updates to xulrunner can result in a cascade of other updates. There are many different packages (e.g. Miro, epiphany, liferea, yelp, etc.) that use xulrunner, so changes to that package may require updates to those dependencies, which may require other updated libraries, and so on.

The Windows/Mac solution has the advantage that updates to Firefox do not require any coordination with other applications, but it has its set of downsides as well. Each application needs some way to alert users that there are important security fixes available and have some mechanism for users to update the application. Rather than a central repository that can be checked for any pending security issues, users have to run each of their installed applications to update their system. Furthermore, a flaw in a widely used library may require updating tens or hundreds of applications, whereas, in the Linux model, just upgrading the one library may be sufficient.

It would appear that Ubuntu is preparing to move to the bundled library approach for Firefox in its upcoming 10.04 (Lucid Lynx) release. That is a "long-term support" (LTS) release that Ubuntu commits to supporting for three years on the desktop. One can imagine that it will be rather difficult to support Firefox 3.6 in 2013, so the move makes sense from that perspective. But there are some other implications of that change.

For one thing, the spec mentions the need to "eliminate embedders" because they could make it difficult to update Firefox: "non-trivial gecko embedders must be eliminated in stable ubuntu releases; this needs to happen by moving them to an existing webkit variant; if no webkit port exists, porting them to next xulrunner branch needs to be done." Further action items make it clear that finding WebKit alternatives for Gecko-embedders is the priority, with removal from Ubuntu (presumably to "universe") being the likely outcome for most of the xulrunner -using packages.

In addition, Ubuntu plans to use the libraries that are bundled with Firefox, rather than those that the rest of the system uses, at least partially because of user experience issues: "enabling system libs is not officially supported upstream and supporting this caused notable work in the past while sometimes leading to a suboptimal user experience due to version variants in the ubuntu released compared to the optimize version shipped in the firefox upstream tarballs." While it may be more in keeping with Mozilla's wishes, it certainly violates a basic principle of Linux distributions. It doesn't necessarily seem too dangerous for one package, but it is something of a slippery slope.

The release model for Chromium is even more constricting as each new version is meant to supplant the previous version. As Callaway described, it contains various modified versions of libraries, which makes it difficult for distributions to officially package in any way other than with bundled libraries. If that happens in Ubuntu for example, that would double the number of applications shipped with bundled libraries. Going from one to two may seem like a fairly small thing, but will other upstreams start heading down that path?

The Fedora policy linked above is worth reading for some good reasons not to bundle libraries, but there are some interesting possibilities in a system where that was the norm. Sandboxing applications for security purposes would be much more easily done if all the code lives in one place and could be put into some kind of restrictive container or jail. Supporting multiple different versions of an application also becomes easier.

It is fundamentally different from the way Linux distributions have generally operated, but some of that is historical. While bandwidth may not be free, it is, in general, dropping in price fairly quickly. Disk space is cheap, and getting cheaper; maybe there is room to try a different approach. The distribution could still serve as a central repository for packages and, perhaps more importantly, as a clearinghouse for security advisories on those packages.

Taking it one step further and sandboxing those applications, so that any damage caused by an exploit is limited, might be a very interesting experiment. The free software world is an excellent candidate for that kind of trial, in fact it is hard to imagine it being done any other way; the proprietary operating systems don't have as a free a hand to repackage the applications that they run. It seems likely that the negatives will outweigh the advantages, but we won't really know until someone gives it a try.

