2. Why Backport?

Before actually gearing up for the backporting process, it's worthwhile to discuss the purpose of such an activity.

2.1. What's a Backport?

A backport in this context is a Debian GNU/Linux package that has been rebuilt against a distribution of Debian other than the original package maintainer's intended target. For example, a newer version of wget might be available in the Debian Sid (Unstable) archive that you would like to use. However, as you're running Debian Stable, which is a fixed, stable set of software, the newer wget package will never be available in the Stable release you're running. As a general rule, only security updates are made available for the Stable release of Debian, and even then the patches are applied against the existing software. So, a security vulnerability in, say, OpenSSL won't result in OpenSSL 0.98 propogating into Stable if OpenSSL 0.97 is the version that shipped with Stable.

2.2. Why Backport to Stable?

But you really want that newer version of wget, right? Perhaps you need it for some important business function or personal pleasure. Whatever the need, you have need your wget and you want it now.

Why not just upgrade to Debian Sid (Unstable), then?

Stability. You can be confident that the Debian Stable release isn't going to change when you're not looking closely. It is what it is. It isn't what it's not. Having a stable target distribution is an enormous benefit in a large computing environment, where there's precious little time to work through issues that may crop up in Debian Unstable on occasion as it undergoes major revisions, like the recent move to gcc4.1. In a production computing environment, predictability isn't merely a bonus but a real necessity that running Debian Unstable doesn't buy you in the slightest.

2.3. Pitfalls of Backporting

Of course, nothing is without its drawbacks. Debian Unstable is a moving target. When dealing with any moving target, there's always the possibility that compatibility with earlier software will break so badly that you simply can't backport some packages without moving to a more recent glibc2 and upgrading your compiler toolchain. When that happens, you must carefully evaluate what you need is another backport or an infrastructure upgrade. Eventually, you may need to built your own packages internally or radically alter packages in Unstable to suit your needs.

You're likely to have more significant issues the older your version of Debian Stable. For example, if you're running OldStable you'll experience a much greater challenge when backporting than if you're running Stable. Packages with fewer dependencies will often be a nobrainer to backport whereas those with significant dependencies, especially on newer libraries, may fail to built at all.

Pick your battles.

2.4. Why pbuilder?

Since you can download all the necessary software to create a build environment on a workstation or build host, why even bother with learning about pbuilder?

pbuilder provides for a completely static build environment, within which packages are applied at build time. As a result, you're always building in a pristine, reproducible environment. With pbuilder you always know where you stand. If you can successfully build and install a backported package on your pristine image, pulling from the pool of packages from your version of Stable and any internal package repository, you know the package you backported is always going to work; On every single host. And you need not worry about previous backports and required dependency packages conflicting your build environment.

Backporting with pbuilder is all about consistency, reproducibility, and portability.