Web browsers tend to be fast-moving targets. They are frequently updated
both for security holes and to add new functionality. Two of the most
popular free software browsers, Firefox and Chromium, also have fairly
short lifecycles, which often requires distributions to backport security
fixes into unsupported releases. Both Mozilla and Google are more focused
on the Windows versions of their browsers—where application updates with bundled
libraries are the norm—but it makes life difficult for Linux
distributions. So difficult that it appears Debian will be dropping
Chromium from the upcoming 6.0 ("Squeeze") release.
On September 1, Giuseppe Iuculano posted to debian-release asking that the
release team allow him to replace Chromium version 5, which was in the
testing repository, with version 6. Version 5 will no longer receive
updates from Google, but Iuculano was concerned that it would too difficult
to backport patches that fix some "security
issues" with SVG in WebKit because of major refactoring in that
codebase. Roughly a week a later, he uploaded Chromium 6 and asked that
the team either unblock that from being added to unstable or remove Chromium
5 from testing. The team opted for the latter.
One of the big problems is that Chromium uses a WebKit version that is
bundled into the browser source, rather than using a particular released
version of the library. Each time Google updates the browser, a new WebKit
comes with it, and the old browser goes into an unsupported state. In
order to keep using the v5 browser, any security fixes from the new
browser and bundled libraries would have to be reflected into the older
code—not a small task by any means.
In addition, Chromium versions come fast and furious: v5 was only supported
for roughly two months, so the release team was worried that the same would
be true of v6. Meanwhile, Squeeze has been frozen, which means that new
features are not being added. For a release that prides itself on
stability, there really was no choice but to drop Chromium.
In response to
Debian project leader Stefano Zacchiroli's request for information to better understand
the decision, release assistant
Julien Cristau put it this way:
We were given a choice between removing chromium-browser from testing,
or accepting a diff of
22161 files changed, 8494803 insertions(+), 1202268 deletions(-)
That didn't seem like much of a choice. I don't have any reason to
believe the new version won't have the same problem 2 months (or a year)
from now, and as far as I know neither the security team nor the stable
release managers usually accept that kind of changes in stable.
Zacchiroli noted that he is a Chromium
user and wants to have a clear story for why the browser is not in Squeeze,
both for users and for upstream.
While it won't be available in the Squeeze repository (testing right now,
but stable once it is released), Chromium will likely still be available in
official backports repository. That led Michael Gilbert to suggest a slightly different interpretation of
what "supported in stable" might mean:
I think that this need is justification to declare backports "officially
supported by the debian project". Thus when asked this question, you
can point to the fact that chromium is indeed supported on stable, just
via a different model than folks are used to. That is of course
assuming someone is willing to support the backport. I may do that if
Giuseppe isn't interested.
Having chromium not present in stable proper helps the security team
While it may help the security team, there are still some things to be
worked out for users of the backports repository. Currently, packages that
come from backports do not get automatically updated when doing an
apt-get upgrade (or its GUI equivalent). That would mean
that users would have to remember to go grab the latest Chromium whenever a
security update came out. Since backports has become an official part of
Debian, there is thought that changing the behavior to pick up updates from
there would make sense.
It's not just Chromium that is affected however. Squeeze will ship with an
Iceweasel—Debian-branded Firefox—in its repository, but there
seems to be a belief that over time, as the shipping Iceweasel version
falls further and further behind, it too will be coming from
backports. That would give further reason to make backports updates
automatic and that seems to be the consensus on the debian-release list.
This is a problem that we haven't heard the last of. For any distribution
with a long-lasting support window (like Ubuntu LTS, Debian, or any of the
enterprise distributions), it is going to be very difficult to keep
supporting older browsers. The alternative, which is the direction that
most are taking, is to update to the latest upstream version throughout
the distribution's support window.
New browser versions often require newer system libraries, though, which
conflict with other application's requirements. Either the browser can be
backported to use the libraries that shipped with the distribution, or the
newer libraries can be bundled with the browser. Ubuntu has taken the
latter approach, choosing
to bundle some libraries for 10.04 LTS.
It's also possible that eventually it may be more than just web browsers
that adopt a fast release schedule with fairly short support
windows. If that happens, it seems likely that distributions will need to
pool their resources to backport fixes into the older releases or just
follow the upstream releases. It will be especially prevalent for
cross-platform software, where the Windows or Mac OS X versions are the
most popular. Bundling libraries is the usual path taken by applications
on those platforms, so they don't suffer under the same constraints that
Linux systems do.
Keeping up with what seems to be an ever-increasing pace of development,
maintaining stability for users, is a tricky problem to manage.
Distributions may find that it is one they can't manage alone—or at
all. If the latter, distributions will increasingly have to rely on
stability coming from the upstream projects, but there is tension there as
Fast-moving projects are likely to make changes to fundamental components,
changing both the program's behavior and its interface. While that doesn't
necessarily make the application unstable in the usual sense of that term,
it does change things in ways
that stability oriented distributions try to avoid. It's a difficult
balancing act and we'll have to see how it plays out.
to post comments)