Binärpakete beinhalten Programme in kompilierter Form, die vorher bspw. in C oder einer ähnlichen Programmiersprache geschrieben wurden. Weiterhin beinhaltet es häufig noch Konfigurationsdateien, Dokumentation und weitere Daten in exakt dem Zustand, wie sie nachher auch auf der Festplatte Ihres Rechners vorliegen.

Bei der Installation eines deb-Pakets entpackt das Programm dpkg zuerst das Archiv aus dem deb-Paket und kopiert danach die Inhalte des Archivs an die vorbezeichnete Stelle in der Verzeichnishierarchie auf dem Zielsystem. Alle im Archiv genannten Pfade und Berechtigungen werden dabei übernommen.

Außerdem sind in den Binärpaketen Metadaten gespeichert, die solche Informationen wie bspw. die Abhängigkeiten zu anderen Paketen enthalten. Weitere Details dazu erfahren Sie unter „Konzepte und Ideen dahinter“ (siehe Abschnitt 4.1, „Konzepte und Ideen dahinter“) sowie „Aufbau und Format von Binärpaketen“ (siehe Abschnitt 4.2.3, „Binärpakete“).

Wie bereits oben benannt, hat ein Binärpaket üblicherweise die Dateiendung deb und wird auch durch das UNIX-Kommando file entsprechend als solches erkannt. Nachfolgende Ausgabe zeigt dieses Verhalten am Beispiel des Pakets vnstat, eines Programms zur Analyse des Netzwerktraffics.

Das UNIX-Kommando file identifiziert die deb-Datei als Debianpaket. 

$ file vnstat_1.10-1_i386.deb
vnstat_1.10-1_i386.deb: Debian binary package (format 2.0)
$

Es gibt ein paar besondere Varianten von Binärpaketen – Übergangspakete und Metapakete. Vom Aufbau her unterscheiden sich diese nicht von normalen Binärpaketen, aber vom Inhalt. Übergangspakete und Metapakete sind reguläre Binärpakete, die jedoch im Normalfall keine eigenen Programme, Daten oder ähnliches beinhalten. Stattdessen liefern diese Abhängigkeiten auf andere Pakete.

Übergangspakete werden bei Paketumbenennungen verwendet und dienen nur dazu, Ihnen den Wechsel bei geänderten (Binär-)Paketnamen zu erleichtern. Damit wird bei einer Aktualisierung eines bestehenden Pakets das Paket mit dem neuen Namen nachgezogen. In den meisten Fällen können Sie nach der Aktualisierung das Paket mit dem bisher verwendeten Namen gefahrlos von ihrem System entfernen. Nicht selten passiert dies bereits automatisch über die Paketverwaltung durch weitere, ggf. negative Abhängigkeiten.

Übergangspakete hängen meist nur von einem einzigen anderen Paket ab. Beispiele dafür sind:

Metapakete sind hingegen bewusst installierte Pakete, die Ihnen die Installation einer ganzen Gruppe von Paketen erleichtern. Als Abhängigkeiten zieht ein Metapaket eine Gruppe von verwendeten Paketen hinter sich her. Auf diese Art und Weise installieren Sie durch die Auswahl eines einzelnen Pakets eine ganze Gruppe an weiteren Paketen, die thematisch zusammengehören und sich häufig auch einander bedingen.

Das ist sehr nützlich, wenn Sie sich sicher sind, dass Sie eine bereits vorbereitete Zusammenstellung von Programmen benötigen. Für die Desktop-Umgebung XFCE genügt es beispielsweise, das dazugehörige Metapaket namens xfce4 auszuwählen. Andere Programmzusammenstellungen wie gnome (GNOME-Window-Manager), lxde (LXDE-Window-Manager) und kde-full (K Desktop Environment) handhaben das ähnlich.

Sehr intensiv verwendet das Projekt Communtu diese Metapakete. Über die Webseite des Projekts stellen Sie sich individuelle Paketkombinationen („Bündel“) zusammen und beziehen diese von dort. Ausführlicher gehen wir darauf in Abschnitt 6.5.3, „Communtu“ ein.

Tasks – auf deutsch mit „Aufgaben“ übersetzbar – sind Metapakete, die vom Debian Installer verwendet werden, um bestimmte Paketgruppen zu installieren. Dabei geht es vor allem um Pakete für bestimmte Sprachen und Lokalisierungen. Zum Beispiel hängt die Aufgabe task-german-desktop u.a. von den Paketen mit den deutschsprachigen Hilfedateien und Wörterbüchern von LibreOffice ab. Ähnliches existiert für Serverfunktionen, bspw. task-dns-server und task-database-server. Diese Funktionalität stammt vom Paket tasksel und wird ab Debian 7 Wheezy vermehrt verwendet. Auf das angesprochene Programm tasksel gehen wir in Abschnitt 6.3.1, „tasksel“ ausführlicher ein.

Mikro-Binärpakete tragen die Dateiendung udeb, wobei das u den griechischen Buchstaben Mu („µ“) repräsentiert. Sie sind technisch keine gewöhnlichen Binärpakete, sondern aufs Kleinste heruntergestutzte Pakete. Sie kennen nur eine einzige Art von Paketrelation namens „hängt ab von“. Desweiteren beinhalten sie keine Maintainer-Skripte und führen auch sonst kaum Metainformationen mit.

Einziger Einsatzzweck dieser Mikro-Debs ist im Debian Installer während des Zeitpunkts der Installation. Deswegen gibt es auch nur solche Pakete als udeb-Variante, die vom Debian Installer selbst gebraucht werden. Darunter zählen bspw. Pakete mit den Programmen zum Anlegen von Dateisystemen.

Diese Pakete beinhalten den Quellcode von Programmen und tragen das Suffix dsc als Abkürzung für Debian Source Control. Die Bestandteile eines solchen Paketes sind:

Alle diese genannten Dateien stellen in der Gesamtheit ein einzelnes Debian-Source-Paket dar und beinhalten den Upstream-Quellcode plus Paketierung.

Reale Binärpakete können zusätzlich deklarieren, dass sie die Funktionalität eines weiteren Pakets ebenfalls bereitstellen. Existiert dieses weitere Paket nicht auch als reales Binärpaket, wird es als virtuelles Paket bezeichnet. Das gleiche virtuelle Paket kann hierbei von verschiedenen Binärpaketen zur Verfügung gestellt werden.

Andere Pakete können von einem solchen virtuellen Paket abhängen. Um diese Abhängigkeit zu erfüllen, genügt es, wenn ein Paket installiert ist, welches dieses virtuelle Paket bereitstellt.

In Debian gibt es bspw. die virtuellen Pakete xserver, x-display-manager und x-window-manager, die typische Komponenten des X-Window-Systems zusammenfassen. Abbildung 2.5, „Inhalt des Pakets x-display-manager in Aptitude“ zeigt beispielhaft die Auswahl für das virtuelle Paket x-display-manager in aptitude. In der ersten Spalte der Darstellung kennzeichnet dazu der Buchstabe v neben dem Namen des virtuellen Pakets diese spezielle Variante.

Zur Auswahl aus dem Paket stehen u.a. der Displaymanager Slim (Paket slim), der Gnome Display Manager in Versionen 2 und 3 (Pakete gdm und gdm3), der KDE Display Manager (Paket kdm), der WINGs Display Manager und der ursprüngliche X Display-Manager (Paket xdm). Der Screenshot in Abbildung 2.5, „Inhalt des Pakets x-display-manager in Aptitude“ stammt von einem Debian-System, auf welchem GDM3 installiert ist. Das erkennen Sie an der Hervorhebung durch fettgedruckten Text und der Markierung i für „Paket ist installiert“ in der ersten Spalte der Darstellung (siehe auch Abschnitt 6.2.1, „dpkg“ für weitere Darstellungsvarianten).

Abbildung 2.5. Inhalt des Pakets x-display-manager in Aptitude

Eine Liste aller offiziell verwendeten virtuellen Pakete in Debian gibt es im Paketierungshandbuch auf der Debian-Webseite [Debian-Virtual-Packages-List]. Andere Distributionen nutzen dieses Konzept auch, jedoch in unterschiedlicher Intensität.

Eine weitere Art nicht real existierender Pakete sind die sogenannten Pseudopakete, die Sie bei der Rückmeldung von Fehlern verwenden können. Diese Pakete dienen dazu, um Probleme mit der Debian-Infrastruktur aufzufangen und über das Debian Bug Tracking System (BTS) zu verfolgen.

Finden Sie bspw. einen Fehler auf den Webseiten von Debian, so können Sie einen Fehlerbericht gegen das Pseudopaket www.debian.org schreiben. Paketentfernungen aus Debian werden über Fehlerberichte gegen das Paket ftp.debian.org abgehandelt. Zukünftige Pakete sowie verwaiste Pakete werden über das Pseudopaket wnpp verwaltet und verfolgt. wnpp ist eine Abkürzung für „Work-needing and prospective packages“ — auf deutsch: „Arbeit bedürfende und zukünftige Pakete“.

Möchten Sie einen Fehlerbericht schreiben, wissen aber nicht, welchem konkreten Paket der Fehler zuzuordnen ist, so können Sie einen Fehlerbericht gegen das Pseudopaket general schreiben. Die Debian-Entwickler werden danach versuchen, herauszufinden, welches reale Paket die Ursache für den von Ihnen berichteten Fehler ist.