SDB:Backports

Introduction

This TID provides information on what a "backport" is and why Novell/SUSE uses backports extensively. The information in this TID will help you understand why comparing version numbers in order to judge software's capabilities and problems can be deceptive.

To do so, we first provide some background on how free software is developed and how it gets into Linux distributions.

The "stream" metaphor in free software development

In understanding free software development, the metaphor of a stream is quite useful. A piece of free software gets written, is integrated by organisations like Novell who integrate the software with other software to build a distribution which is then used by end-users. Thus, the software flows downstream from its developers through the integrators towards the end-users.

Feedback typically flows in the opposite direction: users report bugs or ask for feature enhancements from their distribution vendor, who in turn works with the upstream developers to fix the bugs or develop the enhanced features.

Roles in free software development

Through the stream metaphor, one can see that there are various roles discernable in free software development: those of upstream developer, distribution developer and end-user. These roles have different interests and goals or responsibilities.

The primary interest of upstream developers is the development of the piece of software itself; integration with other software is of less concern. In most cases, upstream developers therefore only actively work on one or two "branches" of their projects.

To distribution developers however, this is the primary concern: fitting the individual pieces of software together in a coherent, integrated whole. To help achieve this, the distribution developers often act as a communication filter between the upstream developers and the end-users, helping to analyse end-user problems and relaying that analysis to upstream developers and, where possible, help them develop and test patches to address these problems. Distribution developers often offer support on a number of releases of their product or on a number of related but distinct products which typically are based on older versions of software than what its upstream developers are working on.

Lastly, the end-users' primary concern is to be productive using the software. Many end-users rely on commercial distribution vendors like Novell to deliver well-integrated environments for their use and for support in that use. For instance, Novell Technical Services offers a number of support contract offerings for enterprise use of Novell's Linux products.

End-users differ in their focus. Some are very keen on tracking "latest and greatest" software, while for others a stable environment for which long-term support is offered is more important. Novell's Linux products reflect these different interests to some degree: for some products new releases are made quite regularly, but each release is only supported for a relatively short period of time, whereas other, enterprise-focused, products are released less frequently but are supported for longer periods of time.

Backports

As upstream developers are primarily concerned with advancing the software they develop, in many cases they combine fixing bugs with introducing new features which haven't yet received extensive testing and which may introduce new bugs.

For distribution developers, it is important to distinguish between bugfixes with a limited potential for disrupting functionality and changes that may disrupt existing functionality. In most cases, distribution developers do not follow all upstream changes once a package has become part of a released distribution, but instead they stick with the upstream version that they initially released and create patches based on upstream changes to fix bugs. This practice is known as backporting, because changes from a newer version of the software are adapted for and applied to an older version of the software.

Distribution developers generally will only introduce newer version of software in two cases: when the changes between their packages and upstream's versions have become so large that backporting is no longer feasible, or for software that inherently ages badly, like anti-malware software (as malware writers and anti-malware software writers are in an evolutionary arms race).

Reasons for backports

Novell/SUSE uses backports extensively as they strike a good balance between a number of concerns for enterprise software. The most important of these are:

• Having stable interfaces (APIs) that software vendors can rely on when building products for use on Novell's enterprise products.
• Ensuring that packages in release of Novell's enterprise products are of the highest quality and have been thoroughly tested, both in themselves and as part of the whole of the enterprise product.
• Maintaining the various certifications of Novell's enterprise products by other vendors, like certifications for Oracle or SAP products on particular Novell enterprise products.
• Allowing Novell's developers to focus on making the next version of the product as good as they can make it, rather than having them have to spread their focus thinly across a wide range of releases
• Keeping a clear view of what is in a particular enterprise release, so that Novell Technical Services can provide accurate and timely technical support for it.

Reasons for not using backports in every case

It is a general policy rule that no new upstream versions of a package are introduced into a Novell enterprise product. This rule is not an absolute rule however. For a limited class of packages, in particular anti-virus software, security concerns weigh heavier than the conservative approach that is preferable from the perspective of quality assurance. For packages in that class occasionally newer versions are introduced into a released version of an enterprise product line.

Sometimes also for other types of packages the choice is made to introduce a new version rather than a backport. This is done when producing a backport is not economically feasible or when there is a very relevant technical reason to introduce the newer version.

The implications of backports for interpreting version numbers

Due to the practise of backporting, one cannot simply compare version numbers to determine whether a SUSE package contains a fix for a particular issue or has had a particular feature added to it. With backporting, the upstream part of a SUSE package's version number merely indicates what upstream version the SUSE package is based on. It can contain bug fixes and features that are not in the corresponding upstream release, but that have been backported into the SUSE package.

There are a number of locations where information regarding such bug fixes and features is stored:

• The package's changelog: rpm -q --changelog name-of-installed-package or rpm -qp --changelog packagefile.rpm. This changelog briefly documents the change history of the package.
• The package changelog may contain entries like "#1234" that refer to bugs in Novell's [bugzilla tracking system http://bugzilla.novell.com/] or links to other bugtracking systems. (Due to confidentiality policies, not all such information may be accessible to you)
• A package may contain a /usr/share/doc/packagename/README.SUSE or README.SuSE file which contains general, high-level information specific to the SUSE packaging.
• The RPM source package contains the patches that were applied during the building of the regular binary RPMs as separate files that can be interpreted if you are familiar with reading source code. See the Maximum RPM book for more information.
• For security bug fixes, the Novell/SUSE security announcements. These often refer to bugs through standardised names like "CAN-2005-2495" which are maintained by the Common Vulnerabilities and Exposures project.

One particular area where this limited value of version numbers when backporting is involved can cause problems is with security scanning tools. Some security vulnerability scanning tools (or particular tests in such tools) operate solely on version information. These tools/tests are thus prone to generate "false positives" (claims that a vulnerable piece of software has been found which in fact isn't vulnerable) when backports are involved. When evaluating reports from security scanning tools, one should always investigate whether an entry is based just on a version number or on an actual test of whether an actual vulnerability exists.

<keyword>backport,upstream,downstream,newer version,patch,bug,release,update,policy,certification,security,CVE,change,changelog</keyword>