Stable distributions and unstable software

Some projects evolve quickly, with rapid release cycles that often leave older major versions behind. That may work just fine for users who are getting the code directly from the project, but it can be problematic for users getting the code from distributions. The problem becomes more acute when security updates are wrapped up inside releases for new features and other bug fixes. The tension between stability and the latest and greatest version was discussed in a recent debian-devel thread regarding WordPress, but the problem goes beyond just Debian—or WordPress.

The discussion started from a bug report filed by Bernd Zeimetz entitled "wordpress: no sane way for security updates in stable releases". He was reacting to a recent wordpress security update that upgraded Debian's wordpress package (based on 3.0.5) to the latest upstream version (3.3.2) because "specific fixes are usually not identified", which makes it difficult or impossible to backport the fixes. The update announcement goes on to warn users that compatibility (especially for plugins or themes that have been installed) may be impacted by the update.

That's not generally the experience that Debian users expect. As Zeimetz put it:

His suggestion was to leave WordPress out of the upcoming "Wheezy" (7.0) release "until upstream handles such issues in a sane way". It's not the first time that idea has been raised. Back in 2007, Moritz Muehlenhoff argued that "Etch" (Debian 4.0) should not ship WordPress due to its security track record. That suggestion was overridden by a vote of the technical committee. So far, at least, it doesn't seem like Zeimetz's bug (which was closed by Muehlenhoff) is headed toward the technical committee, but it did bring up some interesting discussion.

The general consensus seemed to be that WordPress (and other web-oriented applications and frameworks) just move too fast to fit in well with the Debian stable model. Each new release of WordPress likely has some security fixes, Russell Coker said, that are undocumented, so the safest approach is to always update to the newest release. That led Jon Dowland to wonder what value Debian is providing by packaging WordPress if there are no stability guarantees. Several people suggested that it does provide for an easy way to install and upgrade the package, though it is a bit unclear how many people actually do things that way.

In the thread, several users said that they install directly from upstream, rather than using the packages, for a number of reasons. There are numerous plugins and themes for WordPress, many of which are not packaged for Debian for licensing or other reasons, and that typically require the latest version to function. In addition, the Debian package is not really targeted at multi-blog installations. For example, Russ Allbery described the reasons that Stanford University installs from upstream; others concurred with that assessment.

Other distributions have essentially been forced down the same path that the recent Debian update took. Fedora, for example, also updated to the latest WordPress in order to fix a number of security problems. Fedora users are probably more used to living on (or close to) the bleeding edge than Debian stable users are. But maintaining a package that upstream has left far behind for 2-3 years, as Debian tries to do, is likely to be difficult.

Evidently, WordPress doesn't have a lot of interest in declaring a stable release to maintain over that kind of time frame. That's not a surprise, nor a knock on WordPress, as the web moves very quickly and the project can make its own decisions about how to support its users. That said, it would certainly help distributions and others to give better information about security fixes so that backports could potentially be made. While the WordPress security track record may have gotten better over the years—that depends on whom you listen to— some of the same problems that we wrote about in 2009 persist.

The problem is not limited to WordPress, of course, as there are lots of projects, particularly in the web space, that are rapidly updating and leaving their older major versions behind. Firefox is another example of a project that generally forces distributions to upgrade to the latest version due to its rapid release cycle (though the extended support release may blunt the impact for some distributions). Other content management systems, web browsers, frameworks, and so on, have had similar situations that required a major version upgrade for security fixes.

It is still an open question how Linux distributions should handle packaging these kinds of projects. One possible solution for Debian is just to document the problem as is done for browsers, which was suggested by Martin Bagge. Essentially, Debian alerts users that some browsers may not get updates because of the lack of a long-term maintenance branch.

This is yet another example of the difficulty in maintaining a stable base using an ever-shifting array of parts. Distributions are dependent on the upstream projects, but those projects may have an entirely different focus. For distributions like Fedora that turn over every year or so, it's less of an issue, but distributions like Debian (or Ubuntu LTS) are going to have to carefully decide which packages they can maintain—and how they maintain them—over the long haul.

In the future, it may make sense to explore other options. Perhaps distributions could concentrate on the core "plumbing" of the system (libraries, desktops, development tools, utilities, etc.) while providing a means for users to easily install applications (especially fast moving ones) from upstream. That is the model that the Google's Play store follows for Android, and Ubuntu is experimenting with that to some extent in its Ubuntu Software Center. With cooperation of the upstream projects, some kind of middle ground might be found between using the package manager and installing upstream code with an entirely different mechanism. There are lots of things to like about the Linux distribution model, but that doesn't mean that there is no room for improvement.