The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

SDB:Backports

Jump to: navigation, search


This article provides information on what a "backport" is and why openSUSE uses backports extensively. The information in this article 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 projects like openSUSE, 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 discernible 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 analyze 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.

But 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 bug-fixes 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

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

  • Having stable interfaces (APIs) that software vendors can rely on when building products for use on openSUSE.
  • Ensuring that packages in release of openSUSE versions are of the highest quality and have been thoroughly tested, both in themselves and as part of the whole of the distribution.
  • Maintaining the various certifications of openSUSE by other vendors.
  • Allowing openSUSE'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 openSUSE release, so that the community can provide accurate and timely technical support for it.

Reasons not to use backports

It is a general policy rule that no new upstream versions of a package are introduced into a openSUSE version. This rule is not an absolute rule however. For a limited class of packages, 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 openSUSE.

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 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 practice of backporting, one cannot simply compare version numbers to determine whether an openSUSE package contains a fix for a particular issue or has had a particular feature added to it. With backporting, the upstream part of a openSUSE package's version number merely indicates what upstream version the 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 openSUSE 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 "bnc#1234" that refer to bugs
  • in openSUSE's bugzilla bug tracking system 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 openSUSE/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 openSUSE security announcements and the CVE Index. These often refer to bugs through standardized 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.