Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as
Testing or even
Unstable — so that this new package works in their
Stable distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information.
15.1.1. Die Quellen besorgen
Rebuilding a Debian package starts with getting its source code. The easiest way is to use the
apt-get source source-package-name command. This command requires a
deb-src line in the
/etc/apt/sources.list file, and up-to-date index files (i.e.
apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see
Abschnitt 6.1, „Befüllen der sources.list Datei“). Note however, that you will be downloading the source packages from the Debian version mentioned in the
deb-src line. If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions
*.dsc — for
Debian Source Control —
*.tar.comp, and sometimes
*.diff.gz or
*.debian.tar.comp —
comp taking one value among
gz,
bz2 or
xz depending on the compression tool in use), then run the
dpkg-source -x file.dsc command. If the
*.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the
dget URL command. This command (which can be found in the
devscripts package) fetches the
*.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it extracts the source package (unless the
-d or
--download-only option is used).
15.1.2. Änderungen vornehmen
The source of the package is now available in a directory named after the source package and its version (for instance, samba-4.1.17+dfsg); this is where we'll work on our local changes.
The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.1.17+dfsg-2, we can create version 2:4.1.17+dfsg-2falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command (Debian CHangelog) from the devscripts package, with an command such as dch --local falcot. This invokes a text editor (sensible-editor — this should be your favorite editor if it is mentioned in the VISUAL or EDITOR environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that dch really did change the debian/changelog file.
When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages for explanations on how to achieve this).
Je nach den vor Ort vorgenommenen Veränderungen der Pakete kann auch eine Aktualisierung der Datei debian/control, die eine Beschreibung der erzeugten Pakete enthält, erforderlich sein. Diese Datei enthält insbesondere Build-Depends-Zeilen, die die Liste der Abhängigkeiten überwachen, die zum Zeitpunkt der Paketerstellung erfüllt sein müssen. Sie beziehen sich häufig auf Versionen von Paketen, die in der Distribution enthalten sind, aus der das Quellpaket stammt, jedoch in der Distribution, die für die Neuerstellung verwendet wird, möglicherweise nicht vorhanden sind. Es gibt kein automatisches Verfahren um herauszufinden, ob eine Abhängigkeit tatsächlich besteht, oder ob sie nur angegeben wird, um sicherzustellen, dass die Neuerstellung nur mit der jüngsten Version einer Programmbibliothek unternommen wird - dies ist die einzig verfügbare Möglichkeit, einen Autobuilder dazu zu zwingen, während einer Neuerstellung eine bestimmte Paketversion zu verwenden. Aus diesem Grund benutzen Debian-Betreuer häufig streng versionierte Erstellungsabhängigkeiten.
Wenn Sie mit Sicherheit wissen, dass diese Erstellungsabhängigkeiten zu streng sind, haben Sie die Wahl, sie vor Ort zu lockern. Die Lektüre der Dateien, die den normalen Weg zur Erstellung des Programms dokumentieren - diese Dateien sind häufig INSTALL benannt - hilft Ihnen, die passenden Abhängigkeiten herauszufinden. Idealerweise sollten alle Abhängigkeiten durch die Distribution, die für die Neuerstellung verwendet wird, erfüllt werden. Wenn dies nicht der Fall ist, beginnt ein rekursiver Prozess, bei dem die im Build-Depends-Feld genannten Pakete zurückportiert werden müssen, bevor es das Zielpaket kann. Es kann sein, dass einige Pakete nicht zurückportiert werden müssen und während des Erstellungsprozesses in ihrem gegenwärtigen Zustand installiert werden können (ein namhaftes Beispiel ist debhelper). Beachten Sie, dass der Prozess des Zurückportierens sehr schnell kompliziert werden kann, wenn Sie nicht aufpassen. Daher sollten Zurückportierungen so gering wie möglich gehalten werden.
15.1.3. Die Neuerstellung beginnen
Wenn alle erforderlichen Veränderungen auf die Quellen angewendet worden sind, können wir damit beginnen, das eigentliche Binärpaket (die .deb-Datei) zu erstellen. Der gesamte Prozess wird durch den Befehl dpkg-buildpackage gesteuert.
Beispiel 15.1. Ein Paket neu erstellen
$ dpkg-buildpackage -us -uc
[...]
Der oben stehende Befehl kann scheitern, wenn die Build-Depends-Felder nicht aktualisiert worden sind, oder wenn die dazugehörigen Pakete nicht installiert sind. In diesem Fall ist es möglich, diese Kontrolle außer Kraft zu setzen, indem die Option -d an dpkg-buildpackage gegeben wird. Das ausdrückliche Ignorieren dieser Abhängigkeiten erhöht jedoch das Risiko, dass der Erstellungsprozess in einem späteren Stadium scheitert. Oder schlimmer noch, das Paket wird scheinbar richtig erstellt, läuft aber nicht ordnungsgemäß: einige Programme deaktivieren automatisch einige ihrer Leistungsmerkmale, wenn eine erforderliche Bibliothek zum Zeitpunkt der Erstellung nicht verfügbar ist.
In den meisten Fällen benutzen Debian-Entwickler ein übergeordnetes Programm, wie zum Beispiel debuild; dieses führt dpkg-buildpackage wie üblich aus, fügt aber den Aufruf eines Programms hinzu, das zahlreiche Tests ausführt, um das erstellte Paket im Hinblick auf das Debian-Regelwerk zu überprüfen. Dieses Skript bereinigt auch die Umgebung, so dass lokale Umgebungsvariablen die Paketerstellung nicht „verschmutzen“. Der Befehl debuild ist eines der Hilfsprogramme in der devscripts-Suite, die eine gewisse Konsistenz und Konfiguration gemeinsam haben und so die Aufgabe des Betreuers einfacher machen.
