1. Über dieses Buch

1.1. Kann Paketmanagement Spaß machen?

Ja! Und wir werden Ihnen in diesem Buch zeigen, warum das so ist.

Software ist heute meist sehr komplex und darum modular aufgebaut. Das gilt nicht nur für das Betriebssystem Linux und andere freie Anwendungen, sondern hat sich als allgemeines Prinzip in der Softwareentwicklung durchgesetzt.

Modularität hat mehrere Facetten: einzelne Bausteine für spezifische Aufgaben, klare Beschreibungen zu deren Funktion, definierte Schnittstellen und Protokolle zur Kommunikation untereinander. All dies gewährleistet die Kombination und Austauschbarkeit von Komponenten, also die flexible Anpassung der Software an konkrete Anforderungen. Modularität heißt aber auch Abhängigkeiten: Bausteine und Funktionen bedingen einander, bauen aufeinander auf, verlangen bei der Installation eine vorgegebene Reihenfolge – und stehen ggf. zueinander in Konflikt. Das betrifft insbesondere Varianten und Entwicklungsstufen einer Implementierung.

Auf die Verwaltung von Software übertragen, heißt das: Die einzelnen Module werden als Pakete (Packages) bereitgestellt. Das setzt voraus, dass deren Bezug zueinander (Relation) klar geregelt ist; nur so kann ein Betriebssystem wie Debian GNU/Linux (siehe [was-ist-debian]) funktionieren und weiterentwickelt werden, an dem Hunderte von Entwicklern aus der ganzen Welt mitwirken und das inzwischen aus mehr als 40.000 Paketen besteht. Ohne ein leistungsfähiges Paketmanagement wäre dies unmöglich.

Debian GNU/Linux und davon abgeleitete Betriebssysteme – wie Ubuntu [Ubuntu], Linux Mint [LinuxMint], Knoppix [Knoppix] oder Grml [Grml] – setzen auf dem Paketformat deb und der Paketverwaltung mit dpkg und APT auf. Neben dem RPM-Paketformat (siehe [varianten-und-formate-fuer-softwarepakete]) ist die Kombination aus dem deb-Format und seinen Werkzeugen am weitesten unter den verschiedenen Linux-Distributionen verbreitet. Das hat mehrere Gründe:

  • Es funktioniert verlässlich.

  • Es ist ausführlich und meist auch verständlich dokumentiert. Leider ist die Dokumentation aber nicht ganz einheitlich und recht verstreut – weshalb nicht zuletzt auch dieses Buch entstanden ist.

  • Pakete für Debian GNU/Linux sind aufeinander abgestimmt, wurden vorab intensiv getestet und unterliegen strengen Qualitätskontrollen.

  • Pakete für Debian GNU/Linux werden nach ihrer Veröffentlichung (Release) bzw. ihrem Entwicklungszweig kategorisiert: oldoldstable, oldstable, stable, testing, unstable oder experimental. Ein Paket für Debian GNU/Linux kann in mehreren dieser Zweige parallel vorliegen und unterscheidet sich nur in seinem jeweiligen „Reifegrad“. Als Benutzer wissen Sie daher genau, worauf Sie sich einlassen, wenn Sie einen bestimmten Entwicklungsstand benutzen (falls nicht, lesen Sie in [veroeffentlichungen] nach). Das Debian-Derivat namens Ubuntu handhabt das etwas anders: Es unterscheidet nur zwischen mehreren stabilen Veröffentlichungen und dem Entwicklungszweig. Im Rahmen einer halbjährlichen Freigabe wird aus dem Entwicklungszweig die nachfolgende, stabile Veröffentlichung.

  • Kein Stress mit Lizenzen. Es ist klar geregelt, welche Bedingungen ein Paket erfüllen muss, damit es überhaupt in den offiziellen Bestand von Debian GNU/Linux unter den Distributionsbereich main Eingang findet. Alle anderen Pakete werden in die Bereiche contrib oder non-free einsortiert. Ubuntu kennt kein Äquivalent zu contrib und verwendet statt non-free die beiden Bereiche restricted und multiverse (siehe [distributionsbereiche]).

  • Die beiden Debian-Entwicklungszweige unstable und testing (siehe [veroeffentlichungen]) wie auch der Bereich Debian Backports (siehe [debian-backports]) bekommen regelmäßig neue Pakete, die das Paketverwaltungswerkzeug aptitude (siehe [aptitude]) in einer eigenen Liste übersichtlich darstellt. Das ist fast wie Weihnachten, nur günstiger und häufiger.

All dies gewährleistet zwar nicht, dass Software fehlerfrei ist, allerdings reduziert dieses Vorgehen die Zahl der Fehlerquellen deutlich. Es stellt insbesondere sicher, dass sich Softwarepakete unter Berücksichtigung ihrer Abhängigkeiten konfliktfrei installieren, konfigurieren, ausprobieren und auch wieder vollständig aus dem System entfernen lassen. Der Fall, dass andere, bereits integrierte Komponenten Schaden nehmen, ist bei korrektem Vorgehen nahezu ausgeschlossen. Falls das Problem doch auftritt, ist es definitiv in überschaubarer Zeit mit Bordmitteln zu beheben. Diese Werkzeuge stehen im Mittelpunkt dieses Buches.

Die Sorge, dass Sie durch Ausprobieren Ihr Arbeitsgerät unbenutzbar machen, ist unberechtigt – zumindest innerhalb von Debian stable. Aber auch in Debian unstable passiert das nur sehr selten. Ausführlicher gehen wir darauf im Zusammenhang mit Distributionsbereichen (siehe [distributionsbereiche]) und Veröffentlichungen (siehe [veroeffentlichungen]) ein. Fühlen Sie sich also ausdrücklich ermutigt, mit den Paketen Ihres Debian-Systems zu experimentieren!

1.2. Zum Buch

1.2.1. Über die Autoren

Dipl.-Inf. Axel Beckert [Beckert-Webseite] hat Informatik mit Nebenfach Biologie an der Universität des Saarlandes studiert. Er arbeitet als Linux-Systemadministrator an der ETH Zürich, ist im Vorstand der Linux User Group Switzerland (LUGS) und Mitglied des Debian-Projekts. Er benutzt aptitude seit über 10 Jahren und ist seit der Neuformierung des aptitude-Teams zum Jahreswechsel 2011/2012 als Mentor, Versuchskaninchen für neue Versionen und Paketsponsor bei aptitude mit an Bord. Seit 2015 ist er auch offiziell einer der Maintainer des Pakets aptitude und kümmert sich primär um die Paketierung.

Dipl.-Inf. Frank Hofmann hat Informatik mit Nebenfach Englisch an der Technischen Universität Chemnitz studiert. Derzeit arbeitet er in Berlin im Büro 2.0 [Buero2.0], einem Open-Source Experten-Netzwerk, als Dienstleister mit Spezialisierung auf Druck und Satz [Hofmann-Webseite]. Weiterhin ist er Mitgründer des Schulungsunternehmens Wizards of FOSS [Wizards-of-Foss]. Seit 2008 koordiniert er das Regionaltreffen der Linux User Groups aus der Region Berlin-Brandenburg und gehört zu den Ansprechpartnern rund um die Community-Plattform lug.berlin [lug.berlin]. Seit Sommer 2013 ist er Mitglied im Debtags-Projekt [Debian-Debtags], das sich die Verschlagwortung der einzelnen Debian-Pakete zum Ziel gesetzt hat.

1.2.2. Wie und warum dieses Buch entstand

Das Thema „Paketmanagement“ beschäftigt uns als Autoren schon sehr lange. Obwohl jeder die Werkzeuge und Mechanismen tagtäglich verwendet, entdeckten wir zunächst unabhängig voneinander immer wieder neue Aspekte, die sich schrittweise zu einem komplexen Gesamtbild ergänzten.

Beim gemeinsamen Fachsimpeln entstanden aus dieser Begeisterung heraus zunächst Beiträge für die Zeitschrift LinuxUser [Hofmann-Osterried-Alien-LinuxUser] [Hofmann-Winde-Aptsh-LinuxUser] [Hofmann-Debtags-LinuxUser]. Parallel dazu arbeiteten wir weitere Aspekte digital auf und veröffentlichten entsprechende Blogbeiträge [Beckert-Blog], hielten Vorträge bei Linux-Veranstaltungen und versuchten uns in einem Screencast zum Thema.

Im Herbst 2012 hatte Axel die Idee, einen LinuxUser-Artikel zu aptitude im Alltagsgebrauch zu schreiben. Dazu kam es bisher noch nicht
[Jörg, bitte nicht böse sein!]
, denn eine Reihe von Vorarbeiten war dazu notwendig. Wir einigten uns daher auf einen Beitrag zu den Unterschieden zwischen apt-get und aptitude, der jedoch immer länger und länger wurde und schließlich im Frühjahr 2013 in einen Zweiteiler mündete [Beckert-Hofmann-Aptitude-1-LinuxUser] [Beckert-Hofmann-Aptitude-2-LinuxUser].

Bevor wir uns daran machten, Passagen aus diesen umfangreichen Beiträgen wieder herauszustreichen, fiel irgendwann der Satz: „Wenn wir so weitermachen, können wir eigentlich gleich ein Buch schreiben“. Seitdem ließ uns diese Idee nicht mehr los. Teile der Texte und Abbildungen wurden aus den erwähnten Veröffentlichungen übernommen und nach Bedarf für das vorliegende Werk überarbeitet. Das Ergebnis halten Sie nun in Ihren Händen.

1.2.3. Motivation

Uns fasziniert die Paketverwaltung unter Debian, deren Mächtigkeit und unglaubliche Robustheit. Sie funktioniert so klaglos, dass man schon wieder skeptisch werden müsste und nach konzeptionellen Fehlern sucht – aber es gibt tatsächlich keine. Wie in jedem größeren IT-Projekt gibt es neben den intensiv genutzten, gut dokumentierten Bereichen aber auch „dunkle Ecken“ und unangenehme Bugs, kuriose Lösungen und kurzfristige Workarounds; es sind allerdings nur wenige, die auch nur in recht ausgefallenen Situationen zutage treten.

Genießen Sie also das beruhigende Gefühl, dass bei der Verwendung der Werkzeuge eigentlich nichts schiefgehen kann – und wenn doch, gibt es immer einen kurzen Weg, das Malheur wieder zu beseitigen.

Sich hingegen in dem vielschichtigen Geflecht aus dpkg, APT und aptitude zurechtzufinden und ein Verständnis für die einzelnen Programme und Mechanismen zu entwickeln, bedarf Ihrerseits ein wenig Geduld: Ohne nachzulesen und intensiv auszuprobieren, geht es nicht – und auf eben diesem Weg möchte Sie unser Buch begleiten.

Nach einem ersten, flüchtigen Blick auf die genannten Werkzeuge zur Paketverwaltung scheint es so, als sei es unerheblich, welches wann zum Einsatz kommt. Dem ist nicht so, denn jedes hat seine ureigene Aufgabe in der Hierarchie der Paketverwaltung. Subtile Unterschiede zwischen APT und aptitude sorgen mitunter für eine blutige Nase, und insbesondere Ein- und Umsteiger aus der RPM-Welt haben es zu Beginn nicht so leicht. Daher gibt es im Anhang eine Übersicht zu den Aufrufen von RPM und YUM — siehe [kommandos-zur-paketverwaltung-im-vergleich].

Das Buch will darum vor allem Klarheit schaffen und Ihnen die Zusammenhänge zwischen den Programmen deutlich machen. Es hilft Ihnen, in jeder Situation das passende Werkzeug zur Paketverwaltung auszuwählen und es gekonnt einzusetzen. Dazu fassen wir den aktuellen Stand der Entwicklung zusammen und beleuchten darüber hinaus die angrenzenden Programme bzw. die damit verbundenen Fragestellungen im Alltag der Systembetreuung.

1.2.4. Technische Basis

Rein technisch setzt das Buch auf AsciiDoc [AsciiDoc] auf — einem Textformat, aus welchem dann über mehrere Zwischenstufen diverse Ausgabeformate wie PDF, EPUB oder HTML entstehen. Basierend auf einer einzigen Quelle stehen damit passende Ergebnisse für die verschiedenen Ausgabegeräte zur Verfügung. Die AsciiDoc-Dateien liegen in einem Versionskontrollsystem namens Git und sind auf der Plattform GitHub verfügbar [dpmb-github]. Neben der Möglichkeit, während des Arbeitens auch auf eine frühere Revision zurückgreifen zu können, ermöglicht das ein paralleles, verteiltes Arbeiten von verschiedenen Standorten aus. Zudem kann jeder Interessierte am Buch in Form von Vorschlägen und Korrekturen beitragen.

Tipp
Versionsverwaltung mit Git

Den Einstieg zu Git erleichtert Ihnen das gleichnamige Buch von Julius Plenz und Valentin Haenel (Julius Plenz und Valentin Haenel: Git. Verteilte Versionsverwaltung für Code und Dokumente, Open Source Press, München, 2. Auflage November 2014, ISBN 978-3-95539-119-5).

1.2.5. Quellcode und Lizenz

Der o.g. Quellcode des Buches findet sich auf GitHub [dpmb-github] und ist unter der Creative Commons Namensnennung — Weitergabe unter gleichen Bedingungen 4.0 International Lizenz [CreativeCommons] frei verfügbar.

Änderungswünsche oder -vorschläge zum Buch senden Sie bitte dort als Issue [github-issue] — oder sogar noch besser — als Pull-Request mitsamt Patch [github-pull-request] ein.

1.2.6. Organisatorisch

Beide Autoren leben und arbeiten etwa 90 Flugminuten (oder rund 850 km) voneinander entfernt – in Zürich und Berlin. Regelmäßige Arbeitstreffen waren daher nur begrenzt möglich und wurden mit Hilfe von Buchsprints sowie elektronischer Kommunikation überbrückt. Das Buch entsteht seit dem Frühjahr 2013 und häufig auch im Rahmen von Linux-Events. Besonders hervorzuheben sind hierbei die Chemnitzer Linux-Tage [CLT], die Rencontres Mondiales du Logiciel Libre [RMLL] und die Debian Entwicklerkonferenz [DebConf]. An diesen Veranstaltungen nehmen wir gern aktiv teil und nutzen die Gelegenheit, das Buch gemeinsam zu vervollständigen.

Viele Texte verfassen wir zudem von unterwegs aus. Die bisherigen Stationen umfassen Ålesund (Norwegen), Andorra, Augsburg, Beauvais (Picardie), Bergneustadt, Berlin, Besançon, Biel, Bottighofen (Bodensee, Schweiz), Bratland (bei Bergen, Norwegen), Bruchsal, Cudrefin, Chemnitz, Delémont, Essen, Frankfurt/Main, Freiburg im Breisgau, Friedrichshafen, Genf, Germersheim, Goizueta (Baskenland, Spanien), Hamburg, Heidelberg, Hout Bay (Western Cape, Südafrika), Kapstadt, Koblenz, Lauchringen (Baden, Wutachtal), Lausanne, Meersburg, Montpellier, München, Orø (Dänemark), Port del Cantó (Katalanische Pyrenäen, Spanien), Radebeul bei Dresden, Rømø (Dänemark), Rostock-Warnemünde, Saint Cergue (Jura, Schweiz), Saint-Jouin-Bruneval (Normandie), Insel Sokn (bei Stavanger, Norwegen), Tübingen, Tvinnefossen (Norwegen), Zernez (Engadin) und Zürich (siehe [fig.buchkarte]). Wir nahmen uns dabei an der Philosophie von Debian GNU/Linux ein Beispiel: ohne Hektik, mit dem Blick fürs Detail und zumeist pedantisch bis ins letzte i-Tüpfelchen, aber trotzdem mit viel Freude, Neugierde und unserem Entdeckerdrang folgend.

kann-denn-paketmanagement-spass-machen/zum-buch/buchkarte.png
Abbildung 1. Orte, an denen das vorliegende Buch entstand

1.2.7. Grundlagenwissen für Administratoren

Der sichere Umgang mit der Paketverwaltung zählt zu Ihrem Grundwissen als Administrator, um ein UNIX-/Linux-System einrichten und in Bezug auf die eingesetzte Software betreuen zu können. Betreiben Sie Ihre Systeme als Benutzer in Eigenverantwortung, sind diese Kenntnisse für Sie im Alltag ebenso unverzichtbar.

Unabdingbar ist die Auseinandersetzung mit dem Paketmanagement für Zertifizierungen. Das Linux Professional Institute (LPI) widmet dem Thema in der Zertifikatsstufe LPIC-1 einen eigenen Schwerpunkt mit hoher Gewichtung [lpic-101].

Tipp
Material für Ihre LPIC-Prüfungen

Ihre Vorbereitung auf die anspruchsvollen Tests des LPI ergänzen die beiden Bücher „LPIC-1. Vorbereitung auf die Prüfungen des Linux Professional Institute“ von Peer Heinlein [Heinlein-LPIC-1] und „LPIC-1. Sicher zur erfolgreichen Linux-Zertifizierung“ von Harald Maaßen [Maassen-LPIC-1].

Dokumentation zu aptitude

Das vorliegende Buch resultiert auch aus einem Ärgernis, das zur weltweit verteilten Zusammenarbeit über das Netz gehört: Das Internet vergisst nichts, und irgendwo ist immer noch eine veraltete Dokumentation verlinkt, deren Hinfälligkeit mangels Verfallsdatums auch nicht zu erkennen ist.

Bei der Recherche nach aptitude-Optionen verzweigen Suchtreffer häufig auf unklare, überholte und vielfach verteilte Erläuterungen. Als erster Anhaltspunkt bei einer überschaubaren Fragestellung mag das helfen, kann aber auch in eine Sackgasse oder gar zu Fehlern führen, wenn sich die Software just in diesem Punkt weiterentwickelt hat.

Der Wunsch nach einem aktuellen, konsistenten und einsprachigen Nachschlagewerk zur Paketverwaltung mit dpkg, APT und aptitude erhielt also ausreichend Nahrung, zumal auch die an recht prominenter Stelle verlinkte Online-Dokumentation zu aptitude veraltet war (Stand: 2008). Auf Axels Initiative wurde sie aber mittlerweile auf den neuesten Stand gebracht und steht seit August 2013 wieder in sämtlichen bisherigen Übersetzungen zur Verfügung [aptitude-dokumentation].

Das kommt insbesondere Anwendern entgegen, die Dokumentation lieber online lesen (oder „ergooglen“) statt sich die (stets aktuellen) Dokumentationspakete aus den Repositories auf ihrem System zu installieren. Ausführlicher gehen wir auf das Thema in [dokumentation] ein.

Bei unserer Arbeit am Buch entdeckten wir zahlreiche Lücken in den Programmbeschreibungen, den Manpages und den beigefügten, weiterführenden Dokumentationen [bugs-found-during-book-writing]. Dabei wurde uns auch bewusst, welche Bedeutung dem persönlichen Erfahrungsschatz und insbesondere dem passiven Wissen zukommt. Wir haben uns bemüht, davon möglichst viel in dieses Buch einfließen zu lassen.

1.2.8. Dokumentation deb vs. rpm

Trotz vieler Fortschritte sind manche Programme zur Paketverwaltung und Hinweise zum Zusammenspiel von dpkg, APT und aptitude nur bruchstückhaft oder gar nicht beschrieben – oder sie sind über viele Köpfe und Online-Ressourcen hinweg verstreut. Auch an Übersetzungen mangelt es: So liegt trotz des hohen Nutzungsgrades beispielsweise die aptitude-Dokumentation bisher nicht in deutscher Sprache vor.

Im Vergleich steht das Paketformat RPM etwas besser da. In seinem Buch „Maximum RPM“ [Bailey-Maximum-RPM] hat Edward C. Bailey im Jahr 2000 die Regieanweisungen für den Umgang mit diesem Format veröffentlicht. Aktueller sind der „RPM Guide“ des Fedora-Projekts [Foster-Johnson-RPM-Guide] und weiterführende Dokumentationen auf der rpm-Projektseite [RPM-Webseite].

Ein vergleichbares Buch zur Debian-basierten Paketverwaltung fehlte bislang. Viele hervorragende Kompendien (siehe dazu [weitere-buecher]) behandeln zwar die einzelnen Kommandozeilenwerkzeuge dpkg, APT, aptitude oder Synaptic, aber meist fehlt der (entscheidende) Entwurf eines Gesamtbildes, das sich erst aus der geschickten Kombination dieser Werkzeuge ergibt.

1.2.9. Was ist das Buch – und was nicht …

Wir stellen dpkg, APT und aptitude mit den zugrundeliegenden Mechanismen in den Mittelpunkt. Wir erläutern die Unterschiede und ordnen die Werkzeuge anhand konkreter Aufgabenstellungen in den realen Einsatzkontext ein. Diesem problemorientierten Ansatz folgend, werden Sie die Programme künftig effizienter einsetzen und Paketmanagement als ebenso hilfreichen wie angenehmen Teil der Administration der Ihnen anvertrauten Systeme erleben.

Gedacht ist das Buch als Nachschlagewerk und Lernmedium für den Alltag. Es hilft Ihnen, (typische) Fehler oder Umwege zu vermeiden, und räumt mit zahlreichen Missverständnissen auf, die beim Thema Paketmanagement immer noch kursieren.

Unser Buch ist kein allgemeines Linux-Einsteiger-Buch in der Geschmacksrichtung „Debian GNU/Linux“, sondern widmet sich mit der Paketverwaltung bei Debian-Systemen einem speziellen Teilaspekt der Systembetreuung. Folglich spielen andere Paketformate als deb allenfalls eine Nebenrolle (siehe [varianten-und-formate-fuer-softwarepakete]). Andere Debian-Derivate (siehe [welche-unix-artigen-betriebssysteme-verwenden-das]) und Linux-Distributionen haben vieles von Debian GNU/Linux übernommen, und die Rezepte lassen sich daher oft in gleicher Weise anwenden. Wir können jedoch nicht garantieren, dass wirklich alle Ausführungen uneingeschränkt für andere Distributionen gelten. Sofern uns gravierende Abweichungen vom Debian-Standard bekannt sind, benennen wir diese und erklären, wie Sie in einem solchen Fall am besten verfahren.

Weiterhin ist dieses Werk kein Entwicklerhandbuch, aus dem Sie erfahren, wie Sie deb-Pakete bauen und diese in Debian einbringen. Dieses Thema würde den Rahmen des vorliegenden Werkes um ein Mehrfaches sprengen und bleibt daher außen vor.

1.2.10. Zielgruppe und Lernziele

Dieses Buch richtet sich in erster Linie an Systemadministratoren und „Gehäusedeckelabschrauber“
[Dieter Thalmayr in: Oberflächliches – Enlightenment als Alternative zu Gnome und KDE, Vortrag im Rahmen des 11. Linux-Infotages Augsburg, 24. März 2012]
. Richtig sind hier Verwalter und Betreuer Debian-basierter Infrastrukturen sowie Fortgeschrittene, die eine solche Funktion anstreben. Ihnen dienen Teil 1 (Konzepte) und 2 (Werkzeuge) mit den darin beschriebenen Optionen als Nachschlagewerk. Teil 3 (Praxis) hingegen nutzen sie als Arbeits- und Planungsmittel zur bestmöglichen Nutzung der beschriebenen Werkzeuge im Alltag.

Für Anwender, die den Linux-Einstieg mit Ubuntu oder Linux Mint bereits erfolgreich absolviert haben und nun der Systemverwaltung jenseits graphischer Oberflächen entgegenfiebern, bilden die Teile 1 und 2 das unverzichtbare Handwerkszeug. Teil 3 entspricht der Kür fortgeschrittener Kenntnisse. Die Lernkurve wird für sie deutlicher steiler ausfallen, aber stets beherrschbar sein.

1.2.11. Vorkenntnisse

Der Umgang mit der Kommandozeile sollte Ihnen vertraut sein. Wir legen uns nicht auf eine bestimmte Shell oder eine Terminalemulation fest. Alle Beispiele wurden unter bash getestet, funktionieren aber auch unter anderen Shells, wie z.B. der zsh (Axel nutzt auf einigen seiner Systeme die zsh als Login-Shell für den Benutzer root, wie es auch auf der Linux-Live-CD Grml gehandhabt wird). Die von uns ausgewählten und hier abgedruckten Ausgaben im Terminal sind unabhängig von der verwendeten Shell.

Graphische Werkzeuge spielen hier nur eine untergeordnete Rolle. Sie kommen nur dann zum Einsatz, wenn etwas nicht anders möglich ist oder es um genau deren Besonderheiten geht. Wir gehen davon aus, dass Sie auf einem Serversystem arbeiten und dieses ggf. sogar aus der Ferne betreuen. In dieser Konstellation bilden graphische Werkzeuge die absolute Ausnahme.

Für Teil 1 (Konzepte) ist Linux-Grundwissen unabdingbar: neben der Arbeit auf der Kommandozeile also auch grundlegende Kenntnisse über den Filesystem Hierarchy Standard (FHS), der die Struktur der Hauptverzeichnisse und deren Inhalte definiert (siehe dazu [FHS-Linux-Foundation] und [Debian-Wiki-FHS]).

Teil 2 (Werkzeuge) bespricht neben Strukturen zur Paketverwaltung alle Paketoperationen im Alltag und setzt dafür zumindest das Wissen aus Teil 1 voraus. Um manche Beispiele oder vorgestellte Konzepte leichter nachvollziehen zu können, ist mehrjährige Erfahrung mit Linux oder als UNIX-Systemadministrator von Nutzen.

Teil 3 (Praxis) beleuchtet ausschließlich konkrete, komplexere Anwendungsfälle aus dem Alltag. Voraussetzung dafür ist eine Vertrautheit mit den Werkzeugen zur Paketverwaltung, da es in diesem Abschnitt „ans Eingemachte“ geht.

Hilfreich sind darüber hinaus Englischkenntnisse: Viele Bildschirmausgaben sind englisch, nicht zuletzt weil die Lokalisierung der einzelnen Pakete bislang unvollständig ist.

Sie müssen auf Ihrem System über administrative Benutzerrechte verfügen, um manche Beispiele nachvollziehen zu können. Wir weisen nicht jedes Mal explizit darauf hin
[Sie erlangen diese je nach Konfiguration Ihres Systems über die Kommandos su oder sudo – oder indem Sie sich als Benutzer root auf Ihrem System anmelden.]
. In den Beispielen für die Kommandozeile erkennen Sie anhand des Prompt-Zeichens, ob administrative Rechte notwendig sind oder nicht (# falls ja, und $, falls nicht). Auf Ausnahmen weisen wir Sie an der betreffenden Stelle explizit hin.

Auch wenn dpkg, APT und aptitude stabil und zuverlässig funktionieren – gerade in der Rolle und mit den Berechtigungen eines Administrators können falsche Befehle viel kaputt machen. Wir empfehlen Ihnen darum, die vorgestellten Beispiele zunächst auf einem separaten Testsystem auszuprobieren – sei dies ein eigener Rechner, eine virtuelle Maschine oder auch nur eine chroot-Umgebung [Debian-Wiki-chroot].

Dabei spielt es kaum eine Rolle, welches APT-basierte System Sie verwenden. Die meisten Beispiele im Buch stammen von einem Debian 7 Wheezy (oldstable) oder einem Debian 8 Jessie (stable). Alle Ausnahmen sind entsprechend gekennzeichnet.

1.2.12. Und das können Sie nach der Lektüre …

Haben Sie das Buch gelesen und die Beispiele am Rechner nachvollzogen, verfügen Sie über profunde Kenntnisse in der Paketverwaltung unter Debian GNU/Linux. Dazu gehört:

  • Debian-Pakete sauber verwalten

  • kleinere und mittlere Debian-basierte Infrastrukturen pflegen

  • die richtigen Werkzeuge für die Pflege benutzen und mit der Paketverwaltung sowie den Werkzeugen effektiv umgehen

  • nicht nur die Software verwenden, sondern auch wissen, warum etwas funktioniert

  • Pakete und Software nach Wunschkriterien finden

  • alternative Auflösungen für Paketabhängigkeiten finden, verstehen und anwenden

All dies qualifiziert Sie für das entsprechende Lernziel der LPI-Prüfungen. Darüber hinaus schaffen Sie sich damit die Grundlagen, um später eigene und fremde Pakete zu bauen und die Paketierung für Debian durchzuführen. Das ist zugleich eine Voraussetzung, um später als Debian-Paket-Maintainer agieren zu können [Debian-Wiki-Debian-Entwickler].

1.2.13. Buchinfo

Wir pflegen eine buchbegleitende Webseite unter der URL:

Darauf finden Sie neben einer Liste der Errata und deren Korrekturen auch inhaltliche Ergänzungen und Aktualisierungen. Natürlich freuen wir uns auch über Ihre Fragen und Anmerkungen!

1.3. Danksagung

Eine Reihe von Menschen haben uns bei der Realisierung dieses Buches direkt oder indirekt unterstützt, sei es in Form von Anregungen, Kritik, Vorschlägen zur Ergänzung oder Fach- und Verständnisfragen. Diesen Menschen gebührt unser Dank:

  • Elmar Heeb (für aptitude-robot und viele interessante Diskussionen)

  • Dirk Deimeke (für Tipps zum Autor-Werden) [Hackerfunk]

  • Arne Wichmann (für das Diagramm der Vertrauenskette in Debian – unter GPL)

  • Annette Kalbow (für inhaltliche Vorschläge mit apt-file, dpkg -l und dpkg -L sowie die graphische Umsetzung der Landkarte)

  • Mechtilde Stehmann (für die Sprachkorrekturen und die Vorschläge für die FAQ)

  • Marco Uhl (für die Idee zum FAQ-Eintrag über Debian Snapshots [Debian-Snapshots] bei Testing- vs. Produktiv-Umgebung)

  • Werner Heuser (für die Installation und den Umgang auf Embedded und Mobile Devices)

  • Claude Becker (für Ideen und Korrekturlesen rund um das Parsen von Debian-Versionsnummern und APT-Pinning)

  • Christoph Berg (für Tipps und Tricks rund um reprepro und seine Erfahrungen mit apt.postgresql.org) [APT-Repo-PostgreSQL]

  • Dr. Thomas Fricke (für Ergänzungen rund um die Verteilung von Paketen auf mehrere Maschinen)

  • Jens Wilke (Konfigurationsmanagement)

  • Martin Schütte (reprepro)

  • Michael Vogt (für Erklärungen rund um APTs mirror:// Methode und gdebi)

  • David Kalnischkies (für viele Detailerklärungen – z.B. zur Parameterverarbeitung von apt-get – und die endlosen Diskussionen darüber, die dennoch meist irgendwann in Erleuchtung endeten)

  • Albrecht Barthel (für die vielen Infos und Einblicke zum Univention Corporate Server, UCS)

  • Martin Venty Ebnöther (für ein weiteres paar Augen und Ohren zum Thema Paketmanagement)

  • Dr. Markus Wirtz für die lange Unterstützung und Hilfe, das Buch auf seinen Weg zu bringen, für den Klappentext sowie fürs Lektorat der Einleitung und dem erstem Kapitel.

  • Oliver Rath für seine Vorschläge zur besseren Lesbarkeit von Programmcode

  • Karsten Merker für viele kleine Korrekturen

  • Wolfram Schneider für den Hinweis zu dh-make-perl als spezialisierte Variante von checkinstall sowie zum Aktualisieren von LTS-Versionen (siehe [umgang-mit-lts])

  • Jörg Brühe für die Anregungen zu den Paketabhängigkeiten

  • Sebastian Andres für seine Anregungen zu Debian Backports

Nicht zu vergessen sind die Probeleser, die sich durch unser Manuskript gekämpft haben: Arne Wichmann, Thomas Winde, Jana Pirat, Jörg Dölz, Hagen Sankowski und Eberhard Hofmann. Vielen Dank für Eure Mühe und Geduld!

Konzepte

1. Willkommen im Linux-Dschungel!

1.1. Was ist Debian?

Je nach Kontext bezeichnet „Debian“ entweder

  • das Debian-Projekt, also den Zusammenschluss von mittlerweile um die 1000 Entwicklern (Debian Developers, kurz: DD) weltweit, die das freie Betriebssystem gemeinsam entwickeln und veröffentlichen

oder

  • das vom Debian-Projekt entwickelte Betriebssystem „Debian GNU/Linux“ bzw. dessen Varianten. Dazu zählen derzeit auch Debian GNU/kFreeBSD [Debian-Wiki-Debian-GNUkFreeBSD] und Debian GNU/Hurd [Debian-Wiki-Debian-GNUHurd], die statt eines Linux-Kerns einen FreeBSD- bzw. GNU-Hurd-Betriebssystemkern nutzen.

Einer der Eckpunkte des vom Debian-Projekt entwickelten Betriebssystems ist die ausschließliche Verwendung freier Software. Dafür sind die Debian Free Software Guidelines (DFSG) [DFSG] maßgeblich, die im Debian-Gesellschaftsvertrag festgelegt sind [Debian-Social-Contract]. Sichtbar wird das auch darin, dass Pakete in den beiden Entwicklungszweigen contrib und non-free offiziell kein Bestandteil von Debian GNU/Linux sind. Genauer gehen wir darauf in [distributionsbereiche] ein.

Debian ist weder kommerziell noch profitorientiert. Das gesamte Projekt finanziert sich ausschließlich durch Spenden [Debian-Donations]. Dazu zählen nicht nur Geldspenden zufriedener Benutzer, sondern auch die Arbeitszeit von Entwicklern, Hardwarespenden oder das Betreiben eines Debian-Mirrors oder gar eines dedizierten Rechners für das Debian-Projekt.

Angestrebt wird ein universelles Betriebssystem, d.h. es gibt keinen Fokus auf einen spezifischen Einsatzbereich wie bei vielen Derivaten von Debian. Desweiteren werden dem Benutzer viele Entscheidungen selbst überlassen: Er muss – anders als z.B. in Ubuntu – wissen, was er möchte. Daher richtet sich Debian an zielorientierte, ambitionierte Einsteiger, Fortgeschrittene, Experten und Profis oder solche, die es wirklich werden wollen.

Debian stellt dafür ein ausgereiftes, stabiles und zuverlässiges Betriebssystem inklusive aller Software dar. Es ist ein Betriebssystem, das die Debian-Entwickler selbst benutzen wollen
[„The project consists of a group of people who are working together to create something that, primarily, we all want to use“ [Allbery-Debian-Popularity]]
. Daher unterstützt Debian viele verschiedene Architekturen und ermöglicht eine einheitliche Administration auf verschiedensten Plattformen (siehe [debian-architekturen]). Ausführliches Testen und das Bereinigen von Fehlern hat Vorrang vor brandaktueller Software.

Aus diesen Grundsätzen folgen weitere Eigenschaften, die sich insbesondere im Einsatzzweck von Debian und der Einordnung in die Distributionsvielfalt widerspiegeln. Die typischen Anwendungsbereiche sind Server, Systeme für die Infrastruktur sowie Low-End Systeme wie etwa die Hardware-Lernplattform Raspberry Pi [RaspberryPi]. Dennoch hat sich Debian (nicht nur bei den Autoren) auch einen festen Platz auf dem Desktop erobert.

Zudem leiten sich aus Debian sehr viele Derivate für ausgewählte Zielgruppen oder Einsatzzwecke ab, z.B. Ubuntu, Linux Mint, Knoppix, Grml oder Damn Small Linux (DSL). Einen vollständigen Überblick („Stammbaum“) erhalten Sie in [welche-unix-artigen-betriebssysteme-verwenden-das] sowie der GNU Linux Distribution Timeline [GNU-Linux-Distribution-Timeline].

1.2. Debian-Architekturen

Debian kommt mit den unterschiedlichsten Hardware-Architekturen zurecht. Die offizielle Liste der aktuell unterstützten Architekturen finden Sie auf der Debian-Webseite [Debian-Architekturen] sowie im Anhang dieses Buches (siehe [anhang-offizielle-debian-architekturen]). Neben den veralteten Architekturen (siehe [anhang-veraltete-debian-architekturen]) werfen wir auch einen Blick in die Zukunft (siehe [anhang-debian-architekturen-zukunft]).

Nicht alle „Architekturen“ sind wirklich nur von der Hardware-Architektur abhängig, auf der die Programme einsetzbar sind, sondern auch von weiteren Punkten. Dazu zählen etwa der Betriebssystemkern, wie Linux, GNU Hurd [Hurd] oder FreeBSD [FreeBSD], aber auch die Art, wie die Programme kompiliert wurden (Application Binary Interface, ABI). Daher bezeichnen Entwickler dies als Portierung (Port) und sich selbst als Porters. Hier verwenden wir durchgängig den Begriff Architektur, da das entsprechende Feld in den Metadaten eines Pakets (siehe [debian-paketformat-im-detail]) architecture heißt und Debian selbst die Begriffe bislang nicht konsistent verwendet.

Eine vollständige Liste der von dpkg verstandenen Architekturen gibt Ihnen der Aufruf dpkg-architecture -L im Terminal aus. Viele der in der Ausgabe des Kommandos genannten Architekturen existieren allerdings nur in der Theorie und zeigen auf, welche Möglichkeiten bestehen.

Architekturen, die das Werkzeug dpkg unterstützt (Ausschnitt)
$ dpkg-architecture -L
uclibc-linux-armel
uclibc-linux-alpha
uclibc-linux-amd64
m68k
sparc
sparc64
...
$

Die Übersicht im Anhang (siehe [anhang-debian-architekturen]) beschreibt die einzelnen Architekturen näher. Die verwendeten Bezeichnungen in Klammern geben dabei das entsprechende GNU-Triplet an, sofern dieses bekannt ist. Das GNU-Triplet besteht aus der Hardware-Plattform, dem Kernel und dem ABI.

Mit Hilfe des Perl-Moduls Dpkg::Arch ermitteln Sie diese Bezeichnungen im Handumdrehen selbst. Nachfolgend sehen Sie einen Aufruf für die Plattformen PPC64, PowerPC-spe, Arm, Armel und Armhf.

Perl-Aufruf zur Ermittlung der GNU-Triplets einer Debian-Architektur
$ perl \
    -MDpkg::Arch=debarch_to_gnutriplet \
    -E 'map { say "$_ = ".debarch_to_gnutriplet($_) } @ARGV' \
    ppc64 powerpcspe arm armel armhf

ppc64 = powerpc64-linux-gnu
powerpcspe = powerpc-linux-gnuspe
arm = arm-linux-gnu
armel = arm-linux-gnueabi
armhf = arm-linux-gnueabihf
$

1.2.1. Debian-Ports-Projekt

Das Debian-Ports-Projekt [Debian-Ports-Projekt] stellt die Infrastruktur für APT-Archive und automatisiertes Bauen von Paketen für Architekturen bereit, die Debian noch nicht oder nicht mehr unterstützt. Typischerweise gibt es dort nur zwei Kategorien von Veröffentlichungen: unstable und unreleased. Ersteres sind die gleichen Pakete wie in Debian unstable, nur wurden diese aus demselben Quellcode für diese spezifische Architektur übersetzt. Letzteres sind speziell für diese Architektur entwickelte oder modifizierte Pakete, die in den offiziellen APT-Archiven von Debian auch nicht im Quellcode zu finden sind.

In gewisser Weise stellt das Debian-Ports-Projekt dadurch gleichzeitig den Kreißsaal und das Altersheim für Debian-Architekturen dar – Anfang und Ende.

1.2.2. Pakete für alle Architekturen

Neben den bereits genannten Architekturen gibt es noch Pakete mit dem Eintrag all. Dies sind architekturunabhängige Pakete und Sie können diese auf beliebigen Architekturen installieren.

Dazu zählen z.B. Pakete von Programmen, die vollständig in den Skriptsprachen Perl, Python, Ruby oder Tcl geschrieben wurden. Ebenfalls gehören zu dieser Gruppe Pakete, die lediglich Daten enthalten, die auf jeder Architektur identisch sind. Das betrifft z.B. Bilder und Musik.

Auswahl der installierten, architektur-unabhängigen Pakete
$ dpkg -l | fgrep " all" | head -5
ii  abiword-common        3.0.0-8    all
    efficient, featureful word processor with collaboration -- common files
ii  acpi-support-base     0.142-6    all
    scripts for handling base ACPI events such as the power button
ii  adduser               3.113+nmu3 all
    add and remove users and groups
ii  adwaita-icon-theme    3.14.0-2   all
    default icon theme of GNOME
ii  aglfn                 1.7-3      all
    Adobe Glyph List For New Fonts
...
$

1.2.3. Multiarch: Mehrere Architekturen gleichzeitig auf einem System

Seit etwa 2004 läuft unter den Debian-Entwicklern die Diskussion um den Support für multiarch [Debian-Wiki-multiarch]. Unterstützung dafür gibt es in Debian seit Version 7 Wheezy und in Ubuntu seit Version 11.10 Oneiric Ocelot. Es beschreibt zwei Dinge:

  • Systeme, auf denen Sie Pakete unterschiedlicher Architekturen nebeneinander benutzen können.

  • Architekturspezifische Pakete, die explizit auf mehreren Architekturen installierbar sind.

Die Gründe für diese Mischung sind vielfältig:

  • die Existenz von Systemen mit (nahezu) identischen Prozessorbefehlen (Instruction Set), aber unterschiedlicher Verarbeitungsbreite. Dazu zählen z.B. i386/x86_64, ppc/ppc64, sparc/sparc64 und s390/s390x. Unterstützung hierfür gibt es bei RedHat/Fedora unter dem Namen biarch bereits länger [biarch].

    Dies ist insbesondere relevant bei proprietärer, nicht-quelloffener Software, die für 32-Bit-Linux kompiliert wurde, aber auf einem 64-Bit-System installiert bzw. verwendet werden soll.

  • Systeme, die gemischte Prozessorbefehle unterstützen – entweder als Emulation in Hardware oder per Software. Dazu gehören z.B. i386/ia64 mittels Hardware-Emulation und arm/jede Plattform (via Qemu Userland-Emulation).

  • gemischte Betriebssystemumgebungen. Darunter fallen die Verwendung und Ausführung von Binärcode anderer Plattformen über eine Kompatibilitätsebene. Beispiele dafür sind Linux/i386 auf FreeBSD/i386 und Solaris/sparc auf Linux/sparc.

  • Cross-Kompilieren. Darunter fällt das Übersetzen von Programmcode für eine andere Zielplattform.

Um diese Eigenschaft zu ermöglichen, bedarf es z.T. erheblicher Änderungen in den Übersetzungswerkzeugen und der Integration von Daten in der Dateistruktur. Dieser Vorgang ist bislang noch nicht vollständig abgeschlossen.

Benötigen Sie Pakete von einer anderen Architektur — bspw. ein i386-Paket (32 bit) auf einer amd64-Installation (64 bit) — ist diese parallele Installation und Benutzung der Software durchaus möglich. Wir zeigen Ihnen in [multiarch-einsetzen], wie Sie diesen Schritt mit dpkg und apt erfolgreich bewerkstelligen.

1.2.4. Bevor es Multiarch gab

Wie oben bereits beschrieben, ist einer der Gründe hinter multiarch das Nutzen bereits kompilierter 32-Bit-Software auf 64-Bit-Systemen. Der Bedarf hierfür war auch schon vor der Entstehung von multiarch sehr groß.

Der Aufwand, alle üblicherweise genutzten Shared Libraries (zu dt.: gemeinsam genutzte Bibliotheken) der 32-Bit-Architektur i386 zusätzlich auch noch als eigenes amd64-Binärpaket anzubieten, ist immens. Pakete dieser Form tragen üblicherweise das Präfix ia32- im Paketnamen. Vor der Entstehung von multiarch wurden daher alle notwendigen 32-Bit-Bibliotheken in ein einziges amd64-Binärpaket namens ia32-libs [Debian-Paket-ia32-libs] gepackt. Dieses Paket umfasste am Ende etwa stolze 800 MB und wurde in regelmäßigen Abständen mit den Sicherheitsaktualisierungen der entsprechenden Bibliotheken aufgefrischt.

Allein die Pflege dieses Pakets war schon recht mühsam. Ab der Einführung von multiarch wurde es gegenstandslos. Darum ist es seit Debian 7.0 Wheezy ein (leeres) Übergangspaket auf die passenden multiarch-fähigen Einzelpakete der Architektur i386.

1.3. Vom tar.gz zur Linux-Distribution

Der Begriff Linux-Distribution bezeichnet die Zusammenfassung von Softwarepaketen aus unterschiedlichen Quellen und deren gemeinsame Verteilung unter einem Distributionsnamen. Einen hohen Bekanntheitsgrad haben heute z.B. RedHat/Fedora, Debian, SuSE-Linux, Ubuntu, Knoppix und Linux Mint erreicht.

Die Vorteile einer Distribution liegen klar auf der Hand: aktuelle, stabile Versionen der Programme und insbesondere die Abstimmung der einzelnen Pakete aufeinander. Letzteres leistet der Distributor und nimmt damit Ihnen als Nutzer erhebliche Arbeit ab. Sie können sich darauf konzentrieren, die Distribution bzw. die Programme daraus zu verwenden.

Die ersten Linux-Distributionen entstanden zu Beginn der 1990er Jahre. Zu den Pionieren zählen Yggdrasil, SLS, Slackware, SuSE, RedHat und Debian. Bis dahin gab es kaum spezifische Pakete für jedes System – jeder Anwender passte die Software nach seinen eigenen Bedürfnissen an und pflegte diese Version dann kontinuierlich weiter. Zumeist waren das einfache tar.gz-Archive, die von Hand ergänzt und vorrangig für das eigene System übersetzt wurden.

Ein automatisiertes Verwalten der Software war zu diesem Zeitpunkt noch nicht möglich, weil die Strukturen nicht erdacht und umgesetzt waren. Abhängigkeiten der Software ließen sich nicht automatisch auflösen. Als Benutzer mussten Sie einerseits wissen, welche Software einander bedingte, und andererseits, welche Versionen und Varianten sich miteinander vertrugen. Namensgleiche Dateien und Verzeichnisse waren problematisch. Die große Kunst bestand im Wissen, in welcher Reihenfolge Sie zueinander passende Versionen von Software zunächst auswählen und diese nachfolgend auf Ihrem Linuxsystem installieren und konfigurieren mussten.

1.4. Debians Paketsystem

Aus diesen Erfahrungen heraus startete 1993 das Debian-Projekt unter Ian Murdock [Debian-History] mit einer revolutionären Idee: dem Bereitstellen kompilierter, vorkonfigurierter und sauber aufeinander abgestimmter Softwarepakete. Es folgte die Entwicklung von dpkg (d für Debian und pkg für Package), welches bis heute ein robuster Grundstein des Systems geblieben ist. Das verwendete deb-Paketformat und die dazugehörigen Werkzeuge wurden später von etlichen Linux-Distributionen übernommen. Ausführlicher beleuchten wir diesen Aspekt in [welche-unix-artigen-betriebssysteme-verwenden-das].

Bald aber stieß das Werkzeug dpkg an Grenzen: Es installiert lediglich deb-Pakete, löst aber die Abhängigkeiten zwischen einzelnen Paketen nicht automatisch auf. Zudem muss das Paket bereits lokal vorliegen, d.h. dpkg kann es nicht direkt aus einem FTP- oder HTTP-Archiv beziehen.

Daraufhin begann die Entwicklung von dselect, welches aus dem Quellcode von dpkg gebaut wird, aber als eigenständiges Programm gilt. Später folgten console-apt (inzwischen aufgegeben) und tasksel (siehe [tasksel]), ab 1998 APT (Advanced Packaging Tool) sowie ab 1999 aptitude als Ncurses-basierte Oberfläche für dpkg. dselect wurde später weiterentwickelt und konnte somit auch APT als Backend benutzen.

Dabei lag die Zielrichtung auf der konsequenten Anwendung des UNIX-Prinzips „Ein Werkzeug für eine Aufgabe“. Das zeigt sich insbesondere darin, dass sich APT und aptitude an dpkg andocken und die verfügbaren Funktionen integrieren, indem die Programme bereits bestehende dpkg-Bibliotheken mitnutzen. Weitere Details dazu finden Sie in [softwarestapel-und-ebenen].

Heute stehen weitere textbasierte und graphische Benutzeroberflächen für dpkg zur Verfügung. Neben aptitude sind das Synaptic (siehe [gui-synaptic]), PackageKit (siehe [gui-packagekit]) – als Basis für Gnome-PackageKit und Apper bei KDE – sowie Muon (siehe [gui-muon]), PackageSearch (siehe [debtags-werkzeuge]), Xara [Debian-Paket-xara-gtk] und SmartPM (siehe [gui-smartpm]). Einen genaueren Blick werfen wir auf diese Programme in [werkzeuge-zur-paketverwaltung].

1.5. Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement

Debian-Binärpakete liegen in einem spezifischen Format vor – dem deb-Paketformat. Sowohl das Format, als auch die dazugehörigen Werkzeuge haben innerhalb der letzten 20 Jahre bei weitaus mehr UNIX-artigen Betriebssystemen Einzug gehalten, als es auf den ersten Blick zu vermuten wäre.

Vereinfacht gesagt, basiert praktisch jedes Debian-Derivat auf den beiden Konzepten. Die Übersicht in [paketformat-im-einsatz] zeigt eine Auswahl, jeweils ergänzt um den spezifischen Einsatzbereich. Bis auf den Univention Corporate Server (UCS) sind alle der genannten Derivate kostenfrei verfügbar.

2. Software in Paketen organisieren

2.1. Was ist Paketmanagement

Paketmanagement beschreibt die geordnete Verwaltung der einzelnen Softwarepakete auf ihrem System. Ziel ist dabei, dass Ihr Linux-System funktionstüchtig und benutzbar bleibt, insbesondere wenn Sie vorhandene Software aktualisieren, entfernen oder auch neue Software ergänzen.

Es umfasst daher nicht nur den Abgleich der lokalen Paketdatenbank mit den eingetragenen Paketverzeichnissen (Repositories), sondern auch die Auflistung der verfügbaren und derzeit verwendeten Pakete mit deren jeweiligen Statusinformation. Dazu gehört etwa die Paketbeschreibung, ob das Paket vollständig installiert ist und, falls ja, welche Version derzeit verwendet wird.

Weiterhin zählt zum Paketmanagement die automatische Auflösung von Paketabhängigkeiten. Das vereinfacht die Benutzung erheblich, da Sie die einzelnen Abhängigkeiten der Pakete nicht vorab recherchieren müssen. Diese Abhängigkeiten beeinflussen den lokalen Paketbestand und die Reihenfolge notwendiger Änderungen beim Hinzufügen, Aktualisieren oder Entfernen einer Paketauswahl. Daran schließen sich die plattform- und hardwarespezifische Konfiguration vor und nach der Installation von Paketen über die sogenannten Maintainer-Skripte an, die dpkg automatisch anstößt. Mehr Informationen dazu finden Sie in [aufbau-und-format].

Die Distribution selbst bzw. die verantwortlichen Paketmaintainer kümmern sich bei der Übersetzung und Bereitstellung der Pakete darum, dass die nachfolgende Zusammenstellung der Paketliste harmonisch ist und die verschiedenen Versionen der einzelnen Softwarepakete aufeinander abgestimmt sind. Jedes deb-Paket verfügt über eine Beschreibung in Textform sowie eine Liste der Pakete, von denen es abhängt – bei Bedarf sogar samt Versionsangabe.

Die Aktualisierung einer bereits bestehenden, installierten Softwareversion durch eine andere Version beinhaltet i.d.R. eine fehlerbereinigte oder erweiterte Variante des Programms. Das kann eine individuelle Sicherheitsaktualisierung sein, das Installieren eines sogenannten Debian Backports, d.h. eine neuere Paketversion wird für eine vorherige Veröffentlichung zurückportiert, aber auch im Rahmen einer Aktualisierung auf eine neue Veröffentlichung der Distribution (siehe [veroeffentlichungen]) stattfinden. Dass letzteres überhaupt möglich ist, ist noch lange nicht bei allen Distributionen selbstverständlich. Lange Zeit war dies ein Alleinstellungsmerkmal von Debian und auch heute noch bieten einige Debian-Derivate diese Eigenschaft nicht. Gleiches gilt für den Wechsel auf eine zurückliegende Softwareversion, einen sogenannten Downgrade. Dies wird allerdings auch bei Debian nicht explizit unterstützt, funktioniert aber dennoch in den meisten Fällen.

Im Detail erklären wir Ihnen die Thematik unter Pakete aktualisieren (siehe [pakete-aktualisieren]), Distribution aktualisieren (siehe [distribution-aktualisieren]), Paket downgraden (siehe [pakete-downgraden]) und dem Debian Backports Archiv (siehe [debian-backports]).

Nachfolgende Ausgaben zeigen zweierlei – die Liste aller Pakete am Beispiel von dpkg und die ausführliche Übersicht auf der Basis von apt-cache. Ersteres listet alle installierten Pakete zur Textverarbeitung Abiword auf. Ersichtlich ist der Installationsstatus (erste Spalte), der Paketname und die Paketversion (zweite und dritte Spalte) sowie eine Paketbeschreibung (vierte Spalte). Auf das Werkzeug dpkg gehen wir en detail in den beiden Abschnitten Softwarestapel und Ebenen ([softwarestapel-und-ebenen]) und dpkg ([dpkg]) ein.

Ausgabe aller derzeit installierten Pakete für Abiword mit dpkg
$ dpkg -l "abiword*"
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                Version        Architektur    Beschreibung
+++-===================-==============-==============-============================================
ii  abiword             2.9.2+svn20120 i386           efficient, featureful word processor with co
ii  abiword-common      2.9.2+svn20120 all            efficient, featureful word processor with co
ii  abiword-plugin-gram 2.9.2+svn20120 i386           grammar checking plugin for AbiWord
ii  abiword-plugin-math 2.9.2+svn20120 i386           equation editor plugin for AbiWord
$

In Beispiel zwei nutzen wir apt-cache mit dem Parameter showpkg, um weitere Details zum Paket abiword-common zu erhalten. Neben der Versionsnummer sind auch die Paketquelle, die Paketsignaturen sowie die Abhängigkeiten zu weiteren Paketen genannt. Die Pakete stammen aus dem main-Zweig von Debian 7 Wheezy, sind für die Architektur i386 kompiliert und wurden vom deutschen FTP-Server des Debian-Projekts bezogen. Die einzige Abhängigkeit besteht zum Paket abiword.

Auflistung der Paketdetails zum Paket abiword-common mittels apt-cache
$ apt-cache showpkg abiword-common
Package: abiword-common
Versions:
2.9.2+svn20120603-8 (/var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages
                  MD5: 168081fc8391dc5eb8f29d63bb588273
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-de
                  MD5: 168081fc8391dc5eb8f29d63bb588273
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-en
                  MD5: 168081fc8391dc5eb8f29d63bb588273


Reverse Depends:
  abiword,abiword-common 2.9.2+svn20120603-8
Dependencies:
2.9.2+svn20120603-8 -
Provides:
2.9.2+svn20120603-8 -
Reverse Provides:
$

2.2. Varianten und Formate für Softwarepakete

Auf Linux-Systemen herrscht in Bezug auf das Paketformat keine Einheitlichkeit. Jede Linux-Distribution legt selbst fest, welches Paketformat sie verwendet. Zwei dieser Formate haben eine sehr hohe Verbreitung erlangt – rpm und deb. Slackware Linux nutzt hingegen ein schlichtes tar-Archiv, welches entweder mit gzip oder ab Release 13 mit xz komprimiert wird (siehe [tab.paketformate]).

Tabelle 1. Übersicht zu Paketformaten und deren Verbreitung
Abkürzung Format in Verwendung Distribution

deb

Debian-Paketformat

seit 1993

Debian, Ubuntu, Grml, Knoppix, Linux Mint …

rpm

Redhat Package Manager

seit 1995

RedHat/Fedora, CentOS, Mandrake/Mandriva/Mageia, SuSE/openSUSE, …

apk

Android-Paketformat

seit 2003

Android

ipkg

Itsy Package Management System, Vorbild deb

2001 bis 2006

Unslung, OpenWrt, OpenMoko, webOS, Gumstix, iPAQ, QNAP (als Plugin), Synology (als Zusatz)

opkg

OpenMoko Package Management System, ipkg-Fork

seit 2006

OpenMoko, OpenWrt, OpenZaurus, OpenEmbedded

pkg.tar.gz

Pacman

seit 2002

Arch Linux

tar.gz, tar.xz

mit gzip bzw. xz komprimiertes tar-Archiv

seit 1993 (2009)

Slackware

Seit 2015 und der Popularisierung von Docker bestehen Containerformate. Ziel ist, in diesen Containern bereits fertig installierte Anwendungen bereitzustellen. Dazu zählen bspw. die Formate Flatpack, OpenContainer und Snappy (siehe [Docker], [Flatpack], [OpenContainer] und [Ubuntu-Snappy-Projekt]).

Tabelle 2. Übersicht zu Containerformaten und deren Verbreitung
Abkürzung Format in Verwendung Distribution

Docker

Containerformat

seit 2014

Debian, Ubuntu, RedHat/Fedora

Flatpack

Containerformat

seit 2015

RedHat/Fedora, Ubuntu

OpenContainer

Containerformat

seit 2015

Virtualisierer

Snappy

Containerformat

seit 2015

Ubuntu

Ändern Sie den Paketbestand auf Ihrem System durch eine Installation, Aktualisierung oder das Löschen eines oder mehrerer Pakete, ist in der Regel kein Neustart des gesamten Systems erforderlich. Die Paketpflege erfolgt bei laufendem System. Nach der Paketpflege ist üblicherweise lediglich der dazugehörige Dienst neu zu starten. Im Normalfall passiert dies heutzutage in den Maintainer-Skripten des Pakets und wird von der Paketverwaltung automatisch angestoßen. Mehr Informationen zu den Maintainer-Skripten finden Sie unter „Aufbau und Format eines Debianpakets“ in [aufbau-und-format].

2.3. Softwarestapel und Ebenen

2.3.1. Ebenen

Die Paketverwaltung kann man leicht in zwei Ebenen aufteilen. Dabei wird jede Ebene durch eine Reihe von Programmen und Bibliotheken repräsentiert (siehe [fig.werkzeugebenen]).

konzepte/software-in-paketen-organisieren/werkzeugebenen-2.png
Abbildung 2. Schichtenmodell zur deb-basierten Paketverwaltung

2.3.2. Untere Ebene

Die Basis bildet dpkg. Dessen Aufgabe ist es a) ein bereits lokal vorliegendes deb-Paket auszupacken und auf dem System einzuspielen und b) die Inhalte eines bereits installierten deb-Pakets wieder aus dem System zu entfernen. Ersteres entspricht dabei dem Kommandozeilenaufruf dpkg -i Paketdatei, das zweite hingegen dpkg -r Paketdatei (siehe [pakete-installieren] und [pakete-deinstallieren]).

Für Statusabfragen zu einem einzelnen Paket stützt sich dpkg auf die beiden Hilfsprogramme dpkg-deb und dpkg-query. Dazu gehören bspw. die Schalter -c und -L zum Anzeigen des Inhalts eines Pakets (siehe [paketinhalte-anzeigen-apt-file]) sowie -l zur Auflistung der installierten Pakete (siehe [liste-der-installierten-pakete-anzeigen-und-deuten]), -s zum Erfragen des Paketstatus (siehe [paketstatus-erfragen]) und -S, um das Paket zu finden, in dem eine bestimmte Datei vorkommt (siehe [paket-zu-datei-finden]).

Mit dpkg können Sie Ihre Pakete verwalten und das System vollständig pflegen. Jedoch müssen Sie sich dann aber selbst um alle Komfortfunktionen kümmern. dpkg prüft nur, ob alle Abhängigkeiten zu anderen Paketen erfüllt sind und beendet im Fehlerfall die Aktion. Es nimmt Ihnen weder die automatische Auflösung von Paketabhängigkeiten, noch die richtige Reihenfolge bei der Installation der Pakete ab. Diese Mühe erleichtern Ihnen die Werkzeuge der oberen Ebene.

Tipp
Paketverwaltung bei anderen Linux-Distributionen

Das Analogon zu dpkg bei rpm-basierten Distributionen ist rpm, bei Arch Linux ist es Pacman und bei Gentoo erreichen Sie die Funktionalität durch die beiden Programme emerge und equery. Eine komplette Übersicht zu den verschiedenen Programmen finden Sie einerseits in der Pacman-Rosetta (siehe [pacman-rosetta-beschreibung]) sowie in unserer Übersicht im Anhang des Buches (siehe [kommandos-zur-paketverwaltung-im-vergleich]).

2.3.3. Obere Ebene

Bei deb-basierten Distributionen besteht die obere Ebene typischerweise aus dem Werkzeug APT (siehe [apt]). Häufig ist mindestens eines der weiteren Programme wie aptitude (siehe [aptitude]), Synaptic (siehe [gui-synaptic]), Ubuntu Software Center (siehe [gui-ubuntu-software-center]), Muon (siehe [gui-muon]) oder auch PackageKit (siehe [gui-packagekit]) installiert. Die Auswahl variiert und hängt von der von Ihnen gewählten Linux-Distribution und ihren Vorlieben ab.

Alle diese Programme übernehmen die Aufgabe, Ihnen die Installation und die Aktualisierung der einzelnen Programmpakete auf Ihrem System zu vereinfachen und unter möglichst einer Benutzeroberfläche zusammenzufassen. Konkret gehört dazu die Aktualisierung der Liste von Paketen aus den Paketquellen, der Auflösung der Paketabhängigkeiten und die Berechnung der Installationsreihenfolge der von Ihnen ausgewählten Pakete.

Bei der Erfüllung ihrer Aufgaben stützen sich die Programme einerseits auf die beiden Bibliotheken libapt-inst und libapt-pkg (siehe [apt-und-bibliotheken]) und andererseits auf die Werkzeuge aus der unteren Ebene, d.h. vor allem auf dpkg. Es übernimmt die eigentliche Installation, Entfernung oder Aktualisierung (siehe untere Ebene). Sichtbar wird dies insbesondere, wenn Sie ein Paket mit apt-get oder aptitude installieren. Einen Teil der Ausgaben auf dem Terminal steuern dpkg und die o.g. Bibliotheken bei.

2.3.4. Paketformate und -werkzeuge anderer Distributionen

Bei rpm-basierten Distributionen RedHat, Fedora und CentOS heißen die Werkzeuge Yellowdog Updater, Modified (YUM) [YUM], bei SuSE und openSUSE Zypper [Zypper] und Yet another Setup Tool (YaST). Mageia Linux und Rosa Linux nutzen hingegen urpmi [Mageia-urpmi]. rpmdrake [rpmdrake] setzt auf urpmi auf und ist das Pendant zum graphischen Werkzeug Synaptic. Aufgrund der einfachen Benutzbarkeit wird es häufig Einsteigern empfohlen.

2.3.5. Werkzeuge, die verschiedene Paketformate unterstützen

Darüber hinaus gibt es Programme, die mit mehreren unterschiedlichen Paketformaten umgehen können. Dazu zählen Muon (siehe [gui-muon]), der Smart Package Manager (SmartPM) (siehe [gui-smartpm]) und PackageKit (siehe [gui-packagekit]). Muon und SmartPM können die Paketformate deb, rpm und tar.gz (Slackware) verarbeiten sowie die bereits oben genannten Verwaltungen APT, YUM und urpmi ansprechen. Weitere Informationen dazu finden Sie unter „Frontends für das Paketmanagement“ in [frontends-fuer-das-paketmanagement].

2.4. Alternativen zu APT

APT mit apt-get und apt-cache ist erprobt, zuverlässig und daher weit verbreitet. Dennoch gibt es Programme, die die gleichen Funktionalitäten wie APT implementieren. Dabei gibt es verschiedene Kategorien von Alternativen:

Alternative Benutzerschnittstellen

Hierzu zählen u.a. die im Buch vorgestellten Programme aptitude, Muon, Synaptic und wajig (siehe [aptitude], [gui-muon], [gui-synaptic] und [wajig2]). Diese setzen auf den APT-Bibliotheken auf und sind nur Alternativen zu den Kommandozeilentools apt-get und apt-cache, nicht aber zu APT als Ganzes.

Vorgänger

Bevor es APT gab und an Popularität gewann, wurden Paketlisten und Pakete mit dselect heruntergeladen (Recherchen ergaben etwa das Jahr 1998). dselect ist Bestandteil des dpkg-Projekts und wird heute noch aus den Quellen von dpkg gebaut. Allerdings benutzt es für viele Funktionalitäten mittlerweile ebenfalls APT als Backend, insbesondere für das Herunterladen von Paketen. dselect hat heute keine Relevanz mehr (liegt quasi im Wachkoma) und wird daher im Buch nicht weiter besprochen.

Potentielle Nachfolger

APT ist nicht mehr ganz jung, und es wurden in der Vergangenheit Design-Entscheidungen getroffen, welche aus heutiger Sicht eher als weniger gelungen gelten, sich aber nicht mehr oder zumindest nur mit sehr viel Aufwand korrigieren lassen. Eugene V. Lyubimkin war einer der APT-Entwickler und hat sich aus o.g. Grund aus der APT-Entwicklung zurückgezogen und eine Re-Implementierung von APT namens Cupt [Debian-Wiki-cupt] geschrieben (siehe [Cupt]).

2.5. Zusammenspiel von dpkg und APT

Wie bisher gezeigt wurde, bauen dpkg, APT und Freunde aufeinander auf. Dabei gibt es eine Reihe von Bibliotheken und weiteren Programmen, die zur Nutzung dieser Werkzeuge ebenfalls notwendig sind.

APT hängt vor allem von der aus dem APT-Quellcode gebauten Bibliothek libapt-pkg, von gnupg und debian-archive-keyring ab. libapt-pkg stellt eine Schnittstelle für den Zugriff auf die Debianpakete bereit (siehe „APT und Bibliotheken“ in [apt-und-bibliotheken]). Die beiden anderen Pakete werden hingegen für die Validierung von digitalen Signaturen benötigt (siehe „Bezogenes Paket verifizieren“ in [bezogenes-paket-verifizieren]).

dpkg ist ein sog. essentielles Paket (siehe [paket-prioritaet-und-essentielle-pakete]), hat also eher wenig Abhängigkeiten. Die meisten davon sind selbst essentielle Pakete und müssen daher nicht namentlich als Abhängigkeit in den Metadaten des Pakets aufgeführt werden. Deshalb tauchen sie nur unter bestimmten Umständen explizit in den Abhängigkeitslisten auf, z.B. wenn bestimmte Einschränkungen bzgl. der Version bestehen.

Bei aptitude und den meisten anderen Frontends ist dies anders, denn diese sind alle um eine ganze Spur komplexer. Bei aptitude kommt z.B. noch die Benutzeroberfläche auf der Basis von Ncurses [Ncurses] hinzu. [fig.apt-dot], [fig.dpkg-dot] und [fig.aptitude-dot] zeigen die minimalen Paketabhängigkeiten für APT, dpkg und aptitude in graphischer Form.

konzepte/software-in-paketen-organisieren/apt.png
Abbildung 3. Paketabhängigkeiten von APT
konzepte/software-in-paketen-organisieren/dpkg.png
Abbildung 4. Paketabhängigkeiten von dpkg
konzepte/software-in-paketen-organisieren/aptitude+apt.png
Abbildung 5. Paketabhängigkeiten von aptitude und APT

Die Grafiken in den drei obigen Abbildungen erzeugen Sie mit Hilfe der beiden Programme debtree [Debian-Paket-debtree] (siehe [debtree-Projektseite]) und dot [Graphviz]. Ersteres berechnet über die Metadaten in den Paketlisten die Abhängigkeiten zu anderen Paketen und erzeugt daraus eine entsprechende Beschreibung des Abhängigkeitsgraphen in der Sprache dot.

Erzeugung der Abhängigkeitsgraphen zu dpkg mittels debtree
$ debtree dpkg
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
digraph "dpkg" {
        rankdir=LR;
        node [shape=box];
        "dpkg" -> "libbz2-1.0" [color=purple,style=bold];
        "dpkg" -> "liblzma5" [color=purple,style=bold,label="(>= 5.1.1alpha+20120614)"];
        "dpkg" -> "libselinux1" [color=purple,style=bold,label="(>= 2.3)"];
        "libselinux1" -> "libpcre3" [color=blue,label="(>= 8.10)"];
        "dpkg" -> "tar" [color=purple,style=bold,label="(>= 1.23)"];
        "tar" -> "libacl1" [color=purple,style=bold,label="(>= 2.2.51-8)"];
        "libacl1" -> "libattr1" [color=blue,label="(>= 1:2.4.46-8)"];
        "libacl1" -> "libacl1-kerberos4kth" [color=red];
        "tar" -> "libselinux1" [color=purple,style=bold,label="(>= 1.32)"];
        "dpkg" [style="setlinewidth(2)"]
        "libacl1-kerberos4kth" [style=filled,fillcolor=oldlace];
}
I: The following dependencies have been excluded from the graph (skipped):
I: libc6 multiarch-support zlib1g
// Excluded dependencies:
// libc6 multiarch-support zlib1g
// total size of all shown packages: 11501568
// download size of all shown packages: 4358750
$

Das zweite Kommando dot wandelt diese Beschreibung über den Schalter -TAusgabeformat in eine hübsche Grafik um. Als Ausgabeformat unterstützt dot derzeit bspw. PostScript, Structured Vector Graphics (SVG), GIF, PNG und FIG (für die Verwendung in xfig). Beachten Sie bitte, dass dot im Aufruf zwischen dem Schalter und dem von Ihnen gewählten Ausgabeformat kein Leerzeichen erlaubt.

Für dpkg erhalten Sie die Abbildung im Bildformat Portable Network Graphics (PNG) mit dem nachfolgend gezeigten Aufruf auf der Kommandozeile. Dabei wird die Ausgabe des debtree-Kommandos nicht auf dem Terminal sichtbar, sondern wird mit dem Pipe-Operator | direkt an das Programm dot weitergegeben, welches es als Eingabe verarbeitet. Die Ausgabe von dot – die erzeugte Bilddatei – wird danach mit dem Umleitungsoperator > in die Datei dpkg.png im aktuellen Verzeichnis umgeleitet.

Erzeugung der Abhängigkeitsgraphen und Speicherung als Rastergrafik
$ debtree dpkg | dot -Tpng > dpkg.png
$

2.6. Vom monolithischen Programm zu Programmkomponenten

Computerprogramme sind vergleichbar mit Kochrezepten und umfassen eine Folge von Anweisungen, die nacheinander abgearbeitet werden. Einfachere, kleine Programme sind häufig noch überschaubar und somit monolithisch. Sie beinhalten den gesamten Programmcode, der in einer einzigen Datei bereitgestellt wird.

Während zu Beginn der Informationsverarbeitung noch eine Tontafel, ein Holzstab mit Einkerbungen, ein Blatt Papier oder auch nur ein Lochstreifen zur Erfassung einer Folge von Anweisungen ausreichte, passt heutiger Programmcode nur noch selten auf eine einzige Bildschirmseite [Naumann-Abakus-Internet]. Ein Großteil der aktuell genutzten Software ist daher mehrteilig und überaus komplex. Dabei spielen viele, unterschiedliche Komponenten zusammen, erfüllen verschiedene Aufgaben und bedingen einander. Dazu gehören kompilierte Programme, Skripte, Bibliotheken, Daten und Konfigurationsdateien.

Die Paketierung der einzelnen Komponenten folgt eigenen Regeln, deren Konventionen nur zum Teil festgeschrieben sind und sich auch von Distribution zu Distribution etwas unterscheiden. [tab.paketierung-apt] zeigt die Zerlegung in einzelne Pakete am Beispiel von APT. Dabei beinhaltet die linke Spalte den generischen Paketnamen ohne Nennung von Versionsnummer und Architektur, die mittlere Spalte die Kategorie, der das Paket zugeordnet ist (siehe „Sortierung der Pakete nach Verwendungszweck“ in [sortierung-der-pakete-nach-verwendungszweck]) und die rechte Spalte eine kurze Paketbeschreibung. Auf die genannten Bibliotheken gehen wir genauer in „APT und Bibliotheken“ in [apt-und-bibliotheken] ein.

Tabelle 3. Paketierung der Komponenten am Beispiel von APT
Paketname Paketkategorie Komponente und Bedeutung

apt

Administration (admin)

Paketmanager für die Kommandozeile (siehe [apt])

apt-doc

Dokumentation (doc)

Dokumentation zum Paket apt

apt-transport-https

Administration (admin)

APT-Plugin für HTTPS-Support

apt-utils

Administration (admin)

Hilfsprogramme für APT

libapt-inst

Bibliotheken (libs)

Laufzeitbibliothek zum Paketformat

libapt-pkg

Bibliotheken (libs)

Laufzeitbibliothek zur Paketverwaltung

libapt-pkg-dev

Bibliotheken zur Entwicklung (libdevel)

Entwicklerdateien zu libapt-pkg

libapt-pkg-doc

Dokumentation (doc)

Dokumentation zur Laufzeitbibliothek libapt-pkg

libapt-pkg-perl

Bibliotheken (libs)

Laufzeitbibliothek zur Paketverwaltung, Perl-Schnittstelle

Tipp
Benennung eines Debianpakets und Paketkategorien

In [benennung-eines-debian-pakets] beleuchten wir die Benennung und Abfolge der Komponenten in den Paketnamen. Eine genaue Auflistung und zur Bedeutung der Paketkategorien lesen Sie in [sortierung-der-pakete-nach-verwendungszweck] nach.

Die Ideen hinter der Zerlegung in einzelne Komponenten sind ganz unterschiedlich und ergeben sich aus der Entwicklung, dem Ausrollen und der nachfolgenden Pflege einer Software. Hauptmotivation ist dabei häufig, nicht das Rad jedes Mal neu erfinden zu müssen und stattdessen bereits bestehende Komponenten zu integrieren, die etabliert sind und bekanntermaßen einen gewissen Qualitätsstandard erfüllen. Im Open-Source-Bereich erfolgt die Entwicklung weltweit verteilt, daher ist hier eine Zerlegung in kleinere Einheiten und „Bausteine“ häufig von großem Nutzen. Aufgaben und Komponenten können dadurch besser an kleine, spezialisierte Teams verteilt werden.

2.7. Debian-Pakete (Varianten)

Wird von einem Debianpaket gesprochen, ist meist ein Binärpaket mit der Dateiendung deb gemeint. Dieses beinhaltet Software oder Daten, welche Sie sofort auf einem Computer mit Debian GNU/Linux installieren können.

Darüberhinaus gibt es aber auch noch andere Paketarten in Debian. Das wichtigste davon sind die Sourcepakete (siehe [sourcepakete]), die den Quellcode enthalten, aus dem später eines oder mehrere Binärpakete (siehe [binaerpakete]) gebaut werden.

2.7.1. Binärpakete (deb)

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 [konzepte-und-ideen-dahinter]) sowie „Aufbau und Format von Binärpaketen“ (siehe [aufbau-und-format-binaer]).

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)
$

2.7.2. Übergangspakete, Metapakete und Tasks

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:

  • gitgnuit und dann später git-coregit

  • chromiumchromium-bsu und dann später chromium-browserchromium

  • diffdiffutils

  • ttf-mplusfonts-mplus

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 [webbasierte-programme-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 intensiv verwendet. Auf das angesprochene Programm tasksel gehen wir in [tasksel] ausführlicher ein.

2.7.3. Mikro-Binärpakete

Ausschließlich die Mikro-Binärpakete mit der Dateiendung udeb sind technisch keine gewöhnlichen Binärpakete. Sie sind aufs Kleinste heruntergestutzte Pakete, die nur eine Art von Paketrelation namens „hängt ab von“ kennen, desweiteren keine Maintainer-Skripte beinhalten und auch sonst kaum Metainformationen mitführen. Einziger Einsatzzweck dieser Mikro-Debs
[das „u“ soll den griechischen Buchstaben Mu („µ“) darstellen]
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.

Tipp
Aufbau und Format von Übergangs- und Metapaketen

Mehr Informationen zum Aufbau dieser Pakete finden Sie unter „Aufbau und Format von Übergangs- und Metapaketen“ in [aufbau-und-format-uebergang-und-metapakete].

2.7.4. Source-Pakete (dsc und weitere Dateien)

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:

  • der Originalquellcode als ein oder mehrere komprimierte tar-Archive. Je nach verwendetem Komprimierungsverfahren lauten die Dateiendungen orig.tar.gz, orig.tar.bz2 oder orig.tar.xz.

  • die Änderungen vom Original zum Debianpaket als komprimierter Patch. Diese Dateien haben klassisch die Endung diff.gz und wurden mit gzip gepackt. Liegen die Änderungen wie bei moderneren Sourcepaketen als komprimiertes tar-Archiv vor, wird als Dateiendung debian.tar.gz oder debian.tar.xz genutzt. Bei Letzterem kommt anstatt von gzip das Komprimierungswerkzeug xz zum Einsatz.

  • eine Datei mit den Metadaten (Größe, Hashsummen, etc.) über die vorher genannten Dateien. Genutzt wird die Dateiendung dsc als Abkürzung für Debian Source Control.

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

Tipp
Auspacken von Debian-Source-Paketen

Zum Auspacken von Debian-Source-Paketen benutzen Sie das Programm dpkg-source aus dem Paket dpkg-dev. Müssen Sie das Source-Paket vorher noch herunterladen, so nutzen Sie besser den Aufruf apt-get source Paketname, welcher das Source-Paket herunterlädt und danach direkt mit dpkg-source auspackt. Mehr Informationen zu Source-Paketen finden Sie unter „Aufbau und Format von Sourcepaketen“ in [aufbau-und-format-source] und „Sourcepakete beziehen“ in [sourcepakete-beziehen].

2.7.5. Virtuelle Pakete

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. [fig.aptitude-virtuelle-pakete] 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 [fig.aptitude-virtuelle-pakete] 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 [dpkg] für weitere Darstellungsvarianten).

konzepte/software-in-paketen-organisieren/aptitude-virtuelle-pakete.png
Abbildung 6. 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.

2.7.6. Pseudopakete im Debian Bug Tracking System

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.

Tipp
Fehler zu einem Paket anzeigen

Unter „Bugreports anzeigen“ in [bugreports-anzeigen] lernen Sie, wie Sie die bestehenden Fehlermeldungen zu einem Paket anzeigen, deuten und einen eigenen Bugreport an das Betreuerteam des Pakets (Paket-Maintainer) übermitteln.

2.8. Sortierung der Pakete nach Verwendungszweck

Für Debian sind inzwischen sehr viele unterschiedliche Pakete verfügbar. Um Ihnen die Orientierung in der Paketmenge sowie die Recherche und Auswahl daraus zu erleichtern, ordnet der Paketbetreuer – der Verantwortliche für das Paket – dieses Paket genau einer bestimmten Kategorie zu. Die Auswahl der Kategorie basiert dabei auf dem hauptsächlichen Einsatzbereich der Software.

[fig.aptitude-paketbereiche] zeigt die Sichtbarkeit der Kategorien bei der Paketauswahl in aptitude. In jeder Kategorie sind die Pakete zusätzlich nach ihrem Distributionsbereich (siehe [distributionsbereiche]) – main, contrib und non-free – gruppiert. Der jeweilige Entwicklungszweig (siehe [veroeffentlichungen]) – bspw. stable, unstable oder testing – wird in dieser Darstellung nicht angezeigt, lässt sich aber bei Bedarf als weitere Ebene in der Anzeigehierarchie konfigurieren.