NOTE: Staring July 2004, this is still a draft, needs to
be expanded a lot. Additions and corrections welcome.
Author: Elmar Heeb (heeb@phys.ethz.ch) and (elmar@heebs.ch)
It has become quite common now to use backported packages with the Debian GNU/Linux distribution. However, for a production environment it make sense to ask why one wants to install a backported package. This also leads to some criteria on when to use a backport and also which packages we can trust.
The main reason why there is such a backport activity at all is the relatively slow release mechanism of Debian. While there are many valid arguments for quicker releases, the current scheme has its reasons. The most important factor is to have a maintainable environment where all packages are properly interconnected by dependencies, provides, conflicts, etc. This environment is being maintained properly for all security relevant issues and other than that will not undergo feature changes that require new configurations. It is important to realize that "stability" as far as Debian releases are concerned are a matter of keeping the version number stable. The version available in "testing" or "unstable" may in fact be more "stable" in terms of program crashes.
By using a backport you will loose the advantage of having a stable version. I.e., you will need to backport security fixes for some chosen version of a package or face the burden of updating the package configuration in a production environment. How much configuration changes you can tolerate determines whether you should run a pure "stable" release, a stable release with a few backported packages, or a setup upgraded to the "testing" or "unstable" release.
When using backports the rule-of-thumb should be to use as few as possible to fulfill you requirements and to get your work done.
The obvious advantage with self made backports is that you get to choose which packages and which versions are backported. For some packages it is your only choice as there may not be a backported version available. If you are successful at backporting you may consider contributing your package. Of course, for your self made backports you assume some (at least a moral) responsibility for security fixes. With a contributed backport this responsibility may be higher, but you may also get more help from the community.
The advantage to publicly available backports is of course that somebody else did the work. However, you will want to make sure that a package is properly supported. If you can find a high quality backport of a package it may be better to use it instead of making your own.
At the time of this writing some of the most serious effort for backported packages is being done at www.backports.org Some other backports you can find through www.apt-get.org.
[FIXME: depending on your needs, the unstable or testing version of Debian may be acceptable and easier to use than using backports]
[FIXME: with pinning you can mix-and-match your own collection of packages. Interesting concept, although with its own problems.]
The Debian project already has elaborate build environments. However, these are meant to work within a particular Release. You would be compiling woody packages within a pure woody system, or sarge packages within a sarge system.
When doing backports, we want to make sure that we control the packages used. We want to do backports with the minimal dependencies on packages outside the stable distribution. Therefore we create our own build environment, albeit with much the same ideas used in the automatic build environments of the Debian project.
You can use a prepared build environment in which case you should download the following three files:
If you want to build your own or just now how this is done you can use the following receipe:
Use debootstrap to generate a pristine Debian environment:
Prepare the new Debian environment to allow chroot, i.e., mount the proc filesystem and provide appropriate resolv.conf, hosts, and .bashrc files:
Enter the Debian environment with chroot and finish the setup. For a build environment we want the simplest mail-transport-agent possible (it will not be used but has to be there because it belongs in a Debian base system). We also want debconf to be non-interactive for the build scripts we are running in this environment. Furthermore we want to have packages installed with their default settings so that they work in a generic Debian environment. We also want to remove all optional packages. For a build environment we need the package build-essential.
Clean up a bit and put all in a tar file:
If you haven't done so above you should download the do-woody-buildenv and the Build scripts:
You can now start a new clean woody build environment with the command
If you give do-woody-buildenv a name of a package
as an argument it will set up a new directory with a build
script template for a new backport as explained below.
FIXME: make sure you use sources with an upstream version not higher than what is available in testing.
FIXME: 4 kinds of dependencies:
FIXME: upload to your repository and make sure you can install the package with all its dependencies.
use a repository tree where you can choose packages individually so that you do not have to install all backported packages.
Structure:
.
|-- dists
| |-- stable -> woody
| `-- woody
| `-- backports
| |-- package-a
| | |-- binary-all
| | | ...
| | |-- binary-i386
| | | ...
| | `-- source
| | ...
| `-- package-b
| |-- binary-all
| | ...
| |-- binary-i386
| | ...
| `-- source
| ...
`-- pool
`-- main
|-- a
| ...
|-- p
| |-- package-a
| `-- package-b
| ...
`-- z