Kapitel 7. Grundlagen des Debian-Paketverwaltungssystems

Inhaltsverzeichnis

7.1. Was ist ein Debian-Paket?
7.2. Wie ist ein binäres Debian-Pakets aufgebaut?
7.3. Warum sind Debian-Paketdateinamen so lang?
7.4. Was ist eine Debian-control-Datei?
7.5. Was ist ein Debian »conffile«?
7.6. Was sind Debians »preinst«-, »postinst«-, »prerm«- und »postrm«-Skripte?
7.7. Was ist ein Essential-, Required-, Important-, Standard-, Optional- oder Extra-Paket?
7.8. Was ist ein virtuelles Paket?
7.9. Was ist damit gemeint, dass ein Paket eine Depends-, Recommends-, Suggests-, Conflicts-, Replaces- oder Provides-Abhängigkeit zu einem anderen Paket hat?
7.10. Was bedeutet Pre-Depends (Vor-Abhängigkeit)?
7.11. Was bedeutet unknown, install, remove purge und hold im Paket-Status?
7.12. Wie setze ich ein Paket auf »hold« (zurückhalten)?
7.13. Wie installiere ich ein Quellpaket?
7.14. Wie baue ich Binärpakete aus einem Quellpaket?
7.15. Wie kann ich selbst Debian-Pakete erstellen?

Dieses Kapitel behandelt einige tiefer gehende Internas der Debian-Paketverwaltung. Wenn Sie hauptsächlich an der Verwendung der entsprechenden Programme interessiert sind, springen Sie zu Kapitel 8, Die Debian-Paketverwaltungswerkzeuge und/oder Kapitel 9, Wie man sein Debian-System auf aktuellem Stand hält.

7.1. Was ist ein Debian-Paket?

Pakete beinhalten im Grundsatz alle notwendigen Dateien, um eine Sammlung zusammengehöriger Befehle und Fähigkeiten zu implementieren. Es gibt zwei Arten von Debian-Paketen:

  • Binärpakete, die ausführbare Dateien, Konfigurationsdateien, man/info-Seiten, Copyright-Informationen und andere Dokumentation beinhalten. Diese Pakete werden in einem speziellen Debian-Archivformat verteilt (siehe Abschnitt 7.2, „Wie ist ein binäres Debian-Pakets aufgebaut?“). Sie sind für gewöhnlich an der Dateierweiterung ».deb« zu erkennen. Binärpakete können mittels des Debian-Werkzeugs dpkg entpackt werden (eventuell auch über Frontends wie aptitude). Mehr Details finden Sie auf dessen Handbuchseite.

  • Quellpakete, welche aus einer .dsc-Datei bestehen, die das Quellpaket beschreibt (inklusive der Namen der folgenden Dateien), einer .orig.tar.gz-Datei, welche den Original-Quellcode ohne Veränderungen in einem gzip-komprimierten tar-Format enthält, sowie üblicherweise einer .diff.gz-Datei mit Debian-spezifischen Änderungen des Codes. Das Dienstprogramm dpkg-source packt und entpackt Debian-Quellpakete. Mehr Details sind auf der Handbuchseite zu finden. (Das Programm apt-get kann als Frontend für dpkg-source genutzt werden.)

Für die Installation von Software benutzt das System die von den Paketbetreuern sorgfältig definierten Abhängigkeiten. Diese Abhängigkeiten sind in der control-Datei, die zu jedem Paket gehört, dokumentiert. Zum Beispiel beinhaltet das Paket des GNU C-Compilers (gcc) Abhängigkeiten (»depends«) zu dem Paket binutils, welches den Linker und den Assembler enthält. Wenn ein Benutzer versucht, gcc zu installieren, ohne zuerst binutils installiert zu haben, gibt das Paketverwaltungssystem (dpkg) die Fehlernachricht aus, dass es das Paket binutils benötigt und stoppt die Installation von gcc. (Allerdings kann, wer dies nicht hinnehmen möchte, die Prüfung außer Kraft setzen, siehe dpkg(8).) Näheres in Abschnitt 7.9, „Was ist damit gemeint, dass ein Paket eine Depends-, Recommends-, Suggests-, Conflicts-, Replaces- oder Provides-Abhängigkeit zu einem anderen Paket hat?“ weiter unten.

Debian-Paketwerkzeuge können benutzt werden, um:

  • Pakete oder Paketteile zu verändern und zu verwalten;

  • lokal eine vom Nutzer bevorzugte Version einer Datei in ein Paket einzufügen;

  • Entwickler beim Aufbau von Paketarchiven zu unterstützen, und

  • Benutzern die Installation von Paketen zu ermöglichen, die sich z.B. auf fernen Archiv-Servern befinden.

7.2. Wie ist ein binäres Debian-Pakets aufgebaut?

Ein Debian-Paket oder eine Debian-Archivdatei beinhaltet ausführbare Dateien, Bibliotheken und Dokumentationen, die zu einem Programm oder einer Menge verwandter Programme gehören. Normalerweise hat eine Debian-Archivdatei die Dateiendung .deb.

Die Interna des Debian-Paketformats für ausführbare Programme sind auf der Handbuchseite deb(5) beschrieben. Dieses interne Format kann sich (von einer Debian GNU/Linux-Veröffentlichung zur anderen) verändern, benutzen Sie daher bitte immer dpkg-deb(1), um .deb-Dateien zu bearbeiten.

7.3. Warum sind Debian-Paketdateinamen so lang?

Die Namen aller Debian-Binärpaketdateien sind folgendermaßen aufgebaut: <foo>_<Versionsnummer>-<Debian-Revisionsnummer>_<Debian-Architektur>.deb

Bitte beachten Sie, dass foo nur nach landläufiger Auffassung den Paketnamen darstellt. Sie können den Paketnamen der Debian-Archivdatei (.deb-Datei) auf eine der folgenden Arten herausfinden:

  • untersuchen Sie die Packages-Datei in dem Verzeichnis, in dem es im Debian-Archiv abgelegt ist. Diese Datei enthält einen Eintrag für jedes Paket. Der erste Abschnitt in jedem Eintrag enthält den formalen Paketnamen.

  • benutzen Sie den Befehl dpkg --info foo_VVV-RRR_AAA.deb (wobei VVV durch die Version, RRR durch die Revisionsnummer und AAA durch die Architektur des Paketes ersetzt werden muss). Dies gibt unter anderem den zur entpackten Archivdatei gehörenden Paketnamen aus.

Die VVV-Komponente ist die Versionsnummer, die vom Original-Entwickler festgelegt worden ist. Hierfür sind keine Standards festgelegt. Für sie sind daher völlig unterschiedliche Formate, von »19990513« bis »1.3.8pre1« in Gebrauch.

Die RRR-Komponente ist die Debian-Revisionsnummer, die von einem Debian-Entwickler (oder einem individuellen Benutzer mit der Absicht, das Paket selbst zu bauen) festgelegt wurde. Diese Nummer entspricht dem Stand des Debian-Paketes. Eine neue Revisionsnummer kennzeichnet daher Änderungen im Debian-Makefile (debian/rules), der Debian-control-Datei (debian/control), den Installations- oder Entfernungs-Skripten (debian/p*) oder in den Konfigurationsdateien, die mit diesem Paket benutzt werden.

Die AAA-Komponente identifiziert den Prozessor, für den das Paket gebaut wurde. Dies ist häufig amd64, was für AMD64-, Intel 64 oder Via Nano-Chips steht. Andere mögliche Werte finden Sie, wenn Sie Debians Archiv-Verzeichnisstruktur unter Abschnitt 6.7, „Was haben all die Verzeichnisse in den Debian-Archiven zu bedeuten?“ durchsuchen. Details finden Sie unter »Debian architecture« auf der Handbuchseite dpkg-architecture(1).

7.4. Was ist eine Debian-control-Datei?

Die Spezifikationen zu den Debian-control-Dateien finden Sie im Debian-Policy-Handbuch, Abschnitt 5, siehe Abschnitt 12.1, „Welche andere Dokumentation gibt es auf einem und für ein Debian-System?“.

Hier beispielsweise eine control-Datei des Debian-Pakets »hello«:

Package: hello
Version: 2.9-2+deb8u1
Architecture: amd64
Maintainer: Santiago Vila <sanvila@debian.org>
Installed-Size: 145
Depends: libc6 (>= 2.14)
Conflicts: hello-traditional
Breaks: hello-debhelper (<< 2.9)
Replaces: hello-debhelper (<< 2.9), hello-traditional
Section: devel
Priority: optional
Homepage: https://www.gnu.org/software/hello/
Description: example package based on GNU hello
 The GNU hello program produces a familiar, friendly greeting.  It
 allows non-programmers to use a classic computer science tool which
 would otherwise be unavailable to them.
 .
 Seriously, though: this is an example of how to do a Debian package.
 It is the Debian version of the GNU Project's `hello world' program
 (which is itself an example for the GNU Project).

Das »Package«-Feld zeigt den Paketnamen an. Diesen Namen erwarten die Paketverwaltungswerkzeuge als Eingabe. Er stimmt nicht unbedingt mit dem ersten Teil des Namens der Debian-Archivdatei überein, ähnelt ihm aber gewöhnlich.

Das »Version«-Feld gibt sowohl die Original-Entwickler-Versionsnummer (an erster Stelle) wie auch (im zweiten Teil) die Revisionsnummer des Debian-Paketes an. Dieses wird unter Abschnitt 7.3, „Warum sind Debian-Paketdateinamen so lang?“ näher beschrieben.

Das »Architecture«-Feld gibt den Prozessor-Typ an, für den das Binärpaket kompiliert worden ist.

Das »Depends«-Feld enthält eine Liste von Paketen, die benötigt werden, um dieses Paket erfolgreich installieren zu können.

»Installed-Size« gibt an, wieviel Speicherplatz das installierte Paket auf der Festplatte belegen wird. Dieser Wert wird von den Frontends benutzt, um zu prüfen, ob noch genug Festplattenplatz für die Installation vorhanden ist.

Die »Section«-Zeile gibt an, in welchem Bereich des Debian-Archivs das Paket zu finden ist.

Die »Priority« zeigt, wie wichtig dieses Paket für die Installation ist. Quasi-intelligente Programme wie "apt" oder "aptitude" übernehmen diese Angabe und bilden entsprechende Paketgruppen, zum Beispiel eine Gruppe optionaler Software, siehe Abschnitt 7.7, „Was ist ein Essential-, Required-, Important-, Standard-, Optional- oder Extra-Paket?“.

Das »Maintainer«-Feld enthält die E-Mail-Adresse der Person, die momentan für die Paketbetreuung zuständig ist.

Das »Description«-Feld umreißt das Anwendungsgebiet und die Funktionen eines Paketes.

Mehr Informationen über alle möglichen Felder, die ein Paket haben kann, finden Sie im Debian-Policy-Handbuch, Abschnitt 5 »Control files and their fields«, siehe Abschnitt 12.1, „Welche andere Dokumentation gibt es auf einem und für ein Debian-System?“.

7.5. Was ist ein Debian »conffile«?

»Conffiles« ist eine Liste von Konfigurationsdateien (meistens unter /etc zu finden). Diese Dateien werden vom Paketverwaltungswerkzeug bei einer Paketaktualisierung nicht überschrieben. Dies stellt sicher, dass eigene Einstellungen, die in diesen Dateien gesetzt wurden, beibehalten werden. Dies ist notwendig, um den Austausch von Paketen auf laufenden Systemen zu ermöglichen.

Um herauszufinden, welche Dateien bei einem Update erhalten bleiben, benutzen Sie:

dpkg --status paket

und schauen unter »Conffiles:« nach.

7.6. Was sind Debians »preinst«-, »postinst«-, »prerm«- und »postrm«-Skripte?

Diese Dateien sind ausführbare Skripte, die automatisch vor oder nach einer Paketinstallation bzw. -entfernung ausgeführt werden. Genau wie die control-Datei sind all diese Dateien Teil des »control«-Abschnitts der Debian-Archivdatei.

Die einzelnen Dateien sind:

preinst

Dieses Skript wird ausgeführt, bevor die Debian-Archivdatei (».deb«-Datei), zu der sie gehört, entpackt wird. Viele »preinst«-Skripte stoppen Dienste, die aktualisiert werden, bis deren Installation bzw. Update abgeschlossen ist (nach dem erfolgreichen Ausführen des »postinst«-Skripts).

postinst

Bei Software, die für das konkrete System konfiguriert werden muss, ist es typischerweise ein solches Skript, das (nach dem Transfer der Dateien auf die Festplatte) die Konfiguration des Pakets foo abschließt. Oft erfragen »postinst«-Skripte Eingaben vom Benutzer und/oder warnen ihn, dass er das Paket bei Bedarf neu konfigurieren muss, wenn er die Standardwerte akzeptiert. Viele »postinst«-Skripte führen nach der Installation/Aktualisierung die für das Starten bzw. Neustarten der Dienste nötigen Befehle aus.

prerm

Dieses Skript stoppt üblicherweise alle Dienste, die mit einem Paket verknüpft sind. Es wird ausgeführt, bevor die Dateien des Paketes gelöscht werden.

postrm

Typischerweise modifiziert dieses Skript Links oder andere Dateien, die zu foo gehören und/oder entfernt Dateien, die vom Paket erzeugt wurden. (Siehe auch Abschnitt 7.8, „Was ist ein virtuelles Paket?“.)

Momentan können Sie alle control-Dateien in /var/lib/dpkg/info finden. Die für das Paket foo relevanten Dateien beginnen mit »foo« und haben die Dateierweiterungen »preinst«, »postinst« usw. Die Datei foo.list in diesem Verzeichnis enthält eine Liste aller Dateien, die mit dem Paket foo installiert worden sind. (Beachten Sie, dass die Pfade der Dateien ein dpkg-Interna sind. Sie sich sollten nicht darauf verlassen.)

7.7. Was ist ein Essential-, Required-, Important-, Standard-, Optional- oder Extra-Paket?

Von den Distributionsbetreuern wird jedem Debian-Paket eine Priorität zugeordnet, auf die das Paketverwaltungssystem zugreifen kann. Die Prioritäten sind:

  • Required: Pakete die für das korrekte Funktionieren des Systems benötigt werden.

    Dieses schließt alle Werkzeuge mit ein, die notwendig sind, um Systemdefekte zu reparieren. Sie dürfen diese Pakete nicht entfernen, ansonsten kann es passieren, dass Ihr System zusammenbricht und Sie sogar außerstande sind, mittels dpkg Sachen wieder zu installieren. Ein nur aus Required-Paketen aufgebautes System ist vermutlich unnütz, aber es bietet genug Funktionalität, um dem Systemadministrator zu ermöglichen, weitere Programme zu installieren.

  • Important-Pakete sollten auf jedem Unix-ähnlichen System installiert sein.

    Andere Pakete, ohne die das System nicht vernünftig laufen kann, finden Sie hier. Das beinhaltet nicht Emacs, X11, TeX oder andere große Anwendungen. Diese Pakete stellen lediglich die Basisinfrastruktur dar.

  • Standard-Pakete sind Standard auf jedem Linux-System, einschließlich eines recht kleinen, aber nicht zu begrenzten Text-Modus-Systems. Es sind Werkzeuge enthalten, um E-Mails zu verschicken (mit mutt) oder Dateien von Archiv-Servern herunterzuladen.

    Programme dieser Priorität werden standardmäßig installiert, wenn der Benutzer nichts anderes ausgewählt hat. Es beinhaltet keine großen Programme, aber den Python-Interpreter und einiges an Server-Software, wie OpenSSH (für ferne Administration) und Exim (für E-Mail-Auslieferung; allerdings kann Exim auch so konfiguriert werden, dass er nur lokale Nachrichten verarbeitet). Auch grundlegende Dokumentation, die für die meisten Benutzer hilfreich sein könnte, ist enthalten.

  • Optional-Pakete beinhalten alles das, was abseits spezieller Anforderungen zur Verfügung stehen sollte oder wovon unterstellt wird, dass Sie es nutzen wollen, ohne es von vornherein zu kennen.

    Dazu gehört X, eine komplette TeX-Distribution und viele andere Programme.

  • Extra: Pakete, die in Konflikt mit Paketen höherer Priorität stehen, die nur für jemanden interessant sind, der sie schon kennt, oder die spezielle Anforderungen haben, welche sie ungeeignet für »Optional« machen.

Wenn Sie eine Standard-Debian-Installation durchführen, werden alle Pakete mit der Priorität Standard oder höher auf Ihrem System installiert. Wenn Sie vordefinierte Programmgruppen (Tasks) auswählen, bekommen Sie auch Pakete mit geringerer Priorität.

Zusätzlich sind einige Pakete als Essential markiert. Da diese Pakete für die Grundfunktionalität des Systems absolut notwendig sind, lehnen es die Paketverwaltungswerkzeuge ab, diese zu entfernen.

7.8. Was ist ein virtuelles Paket?

Virtuelle Pakete stellen Verweise auf grundlegende Funktionen des Systems dar und tragen einen entsprechenden, systematischen Namen. Zum Beispiel sind konqueror and firefox-esr beides Webbrowser, folglich werden beide Programme die Abhängigkeit erfüllen, die ein Programm hat, das einen Webbrowser braucht, um auf einem System richtig zu funktionieren. Beide Pakete erfüllen also die Abhängigkeit des »virtuellen Pakets« namens www-browser.

Ebenso bieten exim4 und sendmail beide die Funktionalität eines Mail-Transport-Agents. Wir sagen also, dass beide Programme das »virtuelle Paket« mail-transport-agent anbieten. Wenn eines der Programme installiert ist, dann wird die Installation jedes Paketes, das von einem mail-transport-agent abhängig ist, durch die Existenz des virtuellen Paketes ermöglicht.

Für den Fall, dass mehr als ein Paket installiert ist, von denen alle dasselbe virtuelle Paket bereitstellen, bietet Debian einen Mechanismus an, der es dem Systemadministrator erlaubt, ein Paket als bevorzugt einzustellen. Der zugehörige Befehl ist update-alternatives und wird später in Abschnitt 11.11, „Einige Benutzer mögen mawk, andere gawk; einige mögen vim, andere elvis; einige trn, wieder andere tin; wie unterstützt Debian die Vielfalt?“ näher erläutert.

7.9. Was ist damit gemeint, dass ein Paket eine Depends-, Recommends-, Suggests-, Conflicts-, Replaces- oder Provides-Abhängigkeit zu einem anderen Paket hat?

Das Debian-Paketverwaltungssystem hat eine Reihe von »Paket-Abhängigkeiten«, die (in einer einzigen Markierung) anzeigen, inwieweit ein Programm A unabhängig vom Vorhandensein von Programm B auf einem gegeben System arbeiten kann:

  • Paket A hängt ab von Paket B (depends), wenn B unbedingt installiert sein muss, damit A läuft. In manchen Fällen hängt A überdies von einer bestimmten Version von B ab. Meistens handelt es sich dabei um eine Untergrenze, wonach As Abhängigkeit durch jede Version von B erfüllt wird, die neuer ist als die angegebene Version.

  • Paket A empfiehlt Paket B (recommends), wenn der Paketverwalter der Meinung ist, dass die meisten Benutzer A nicht ohne die Funktionalität von B haben wollen.

  • Paket A schlägt Paket B vor (suggests), wenn B Dateien beinhaltet, die auf die Funktionen von A bezogen sind und dessen Gebrauchswert für gewöhnlich deutlich steigern.

  • Paket A steht in Konflikt mit Paket B (conflicts), wenn A nicht funktioniert, solange B auf dem System installiert ist. Sehr oft sind Konflikte Fälle, in denen A Dateien beinhaltet, die eine Verbesserung gegenüber denen aus B darstellen. »Conflicts« werden oft mit »Replaces« verbunden.

  • Paket A ersetzt Paket B (replaces), wenn Dateien, die von B installiert wurden, von Dateien aus A entfernt und (in manchen Fällen) überschrieben werden.

  • Paket A beschädigt Paket B (breaks), wenn diese beiden Pakete nicht gleichzeitig auf einem System konfiguriert werden können. Die Paketverwaltung wird es ablehnen, eines davon zu installieren, wenn das andere bereits auf dem System installiert und konfiguriert ist.

  • Paket A stellt Paket B bereit (provides), wenn alle Dateien und Funktionalitäten von B in A vereinigt sind. Dieser Mechanismus ermöglicht es Benutzern mit einem begrenzten Festplattenplatz, nur den Teil von Paket A zu installieren, den sie wirklich benötigen.

Detaillierte Informationen über die Nutzung all dieser Bezeichnungen finden Sie im Policy-Handbuch, Abschnitt 7.2 »Binary Dependencies«, siehe Abschnitt 12.1, „Welche andere Dokumentation gibt es auf einem und für ein Debian-System?“.

7.10. Was bedeutet Pre-Depends (Vor-Abhängigkeit)?

»Pre-Depends« ist eine spezielle Abhängigkeit. Im Fall der meisten Pakete entpackt dpkg die Archiv-Datei eines Pakets (also die .deb-Datei) unabhängig davon, ob die Dateien, von denen das Paket abhängt, auf dem System existieren oder nicht. Stark vereinfacht bedeutet »entpacken«, das dpkg die Dateien aus der Archiv-Datei in Ihrem Dateisystem an der entsprechenden Stelle abgelegt. Wenn solch ein Paket von der Existenz anderer Pakete abhängt, lehnt dpkg es ab, die Paketinstallation abzuschließen (d.h. die Konfiguration des Pakets wird nicht durchgeführt), bevor die anderen Pakete installiert sind.

Für einige Pakete lehnt dpkg jedoch sogar das Entpacken ab, bis bestimmte Abhängigkeiten erfüllt sind. Solche Pakete haben eine sogenannte »Pre-depends«-Abhängigkeit von anderen Paketen. Das Debian-Projekt führte diese Kategorie ein, um ein sicheres Upgrade des Systems vom a.out- zum ELF-Format zu ermöglichen; dabei war die Reihenfolge, in der die Pakete ausgepackt wurden, kritisch. Es gibt andere große Upgrade-Situationen, bei denen diese Methode hilfreich ist, z.B. bei Paketen mit der Priorität »Required« und ihrer Abhängigkeit zu LibC.

Genau wie zuvor finden Sie weiterführende Informationen dazu im Policy-Handbuch.

7.11. Was bedeutet unknown, install, remove purge und hold im Paket-Status?

Diese »Wunsch«-Markierungen zeigen an, was ein Benutzer mit einem Paket tun wollte, z.B. als er dpkg aufrief.

Ihre Bedeutungen sind:

  • unknown (unbekannt) - der Benutzer hat nie angegeben, ob er das Paket wünscht;

  • install (installieren) - der Benutzer möchte das Paket installiert oder aktualisiert haben;

  • remove (entfernen) - der Benutzer möchte das Paket entfernt haben, aber die Konfigurationsdateien sollen erhalten bleiben;

  • purge (vollständig entfernen)- der Benutzer möchte das Paket samt der zugehörigen Konfigurationsdateien entfernt haben;

  • hold (zurückhalten) - der Benutzer wünscht keine Veränderung an diesem Paket, d.h. das Paket soll in der derzeitigen Version beibehalten werden, wie es ist.

7.12. Wie setze ich ein Paket auf »hold« (zurückhalten)?

Es gibt drei Wege, Pakete zurückzuhalten: mit dpkg, apt oder aptitude.

Mit dpkg müssen Sie lediglich die Liste der Paketauswahlen mittels

dpkg --get-selections \* > selections.txt

exportieren. Dann modifizieren Sie die daraus resultierende Datei selections.txt: ändern Sie die Zeile, die das Paket beinhaltet, das Sie zurückhalten wollen (in diesem Beispiel libc6) von:

libc6                                             install

in:

libc6                                             hold

Speichern Sie die Datei und laden Sie sie mit folgendem Befehl zurück in die »dpkg«-Datenbank:

dpkg --set-selections < selections.txt

Mit apt können Sie ein Paket auf Zurückhalten setzen mittels:

apt-mark hold Paketname

Oder Sie entfernen die Zurückhalten-Markierung mit:

apt-mark unhold Paketname

Mit aptitude können Sie ein Paket auf Zurückhalten setzen mittels:

aptitude hold Paketname

Oder Sie entfernen die Zurückhalten-Markierung mit:

aptitude unhold Paketname

7.13. Wie installiere ich ein Quellpaket?

Debian-Quellpakete können nicht im eigentlichen Sinne »installiert« werden. Sie werden lediglich in ein Verzeichnis Ihrer Wahl entpackt, wo Sie dann die Binärpakete daraus erzeugen können.

Quellpakete werden meistens auf denselben Spiegel-Servern angeboten, auf denen auch die Binärpakete zu finden sind. Wenn Sie Ihre sources.list(5) für APT so eingerichtet haben, dass die benötigten »deb-src«-Zeilen enthalten sind, können Sie jegliches Quellpaket einfach mittels des folgenden Befehls herunterladen:

apt-get source foo

Um Ihnen beim Bauen der Quelltext-Pakete zu helfen, bieten die Debian Quellpakete den sogenannten »build-dependencies«-Mechanismus (Bau-Abhängigkeiten). Das bedeutet, dass die Quellpaket-Betreuer eine Liste anderer Pakete pflegen, die zum Bauen des Paketes benötigt werden. Um zu sehen, wozu dies nützlich ist, probieren Sie einmal dies aus

apt-get build-dep foo

bevor Sie den Quellcode kompilieren.

7.14. Wie baue ich Binärpakete aus einem Quellpaket?

Der beliebteste Weg hierfür ist die Nutzung verschiedener Wrapper-Werkzeuge. Im folgenden Beispiel wird die Programmsammlung devscripts eingesetzt. Installieren Sie dies Paket, falls noch nicht geschehen.

Laden Sie jetzt das Quellpaket herunter:

apt-get source foo

und wechseln Sie in dessen Verzeichnisbaum:

cd foo-*

Installieren Sie, falls zum Bauen weitere Pakete gebraucht werden, diese mit:

sudo apt-get build-dep foo

Beugen Sie Verwirrung vor, wenn später seitens Debian neue Versionen veröffentlicht werden, indem Sie mit folgendem Kommando die selbst erstellte Version kennzeichnen:

dch -l local 'Irgendein Text ...'

Und dann bauen Sie Ihr Paket:

debuild -us -uc

Wenn alles korrekt gelaufen ist, sollten Sie jetzt Ihr Paket installieren können mittels

sudo dpkg -i ../*.deb

Wenn Sie es vorziehen, die Dinge händisch zu erledigen, statt devscripts zu benutzen, gehen Sie folgendermaßen vor:

Sie benötigen alle foo_*.dsc-, foo_*.tar.gz- und foo_*.diff.gz-Dateien, um den Quellcode zu kompilieren. (Wobei die innerhalb des Debian-Projekts entstandenen Pakete nicht unbedingt eine .diff.gz-Datei beinhalten).

Wenn Sie diese Dateien haben (siehe Abschnitt 7.13, „Wie installiere ich ein Quellpaket?“) und das Paket dpkg-dev auf Ihrem System installiert ist, können Sie mit

dpkg-source -x foo_version-revision.dsc

das Paket in ein Verzeichnis namens foo-version entpacken.

Wollen Sie einfach nur das Paket kompilieren, wechseln Sie in das foo-version-Verzeichnis und führen folgenden Befehl aus:

dpkg-buildpackage -rfakeroot -b

um das Paket zu bauen (beachten Sie, dass dazu das Paket fakeroot erforderlich ist). Installieren Sie dann mit

dpkg -i ../foo_version-revision_arch.deb

das neu gebaute Paket.

7.15. Wie kann ich selbst Debian-Pakete erstellen?

Details hierzu finden Sie im Debian-Leitfaden für neue Paketbetreuer (aus dem maint-guide-Paket bzw. unter https://www.debian.org/doc/devel-manuals#maint-guide) oder in dem Handbuch für Debian-Paketbetreuer (verfügbar im Paket debmake-doc oder unter https://www.debian.org/doc/devel-manuals#debmake-doc).