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 u.a. als Linux-Systemadministrator an der ETH Zürich, ist sowohl Mitglied des Debian-Projekts als auch in den Vorständen des Vereins Debian.ch und der Linux User Group Switzerland (LUGS).
Er benutzt aptitude seit Anfang der 2000er Jahre 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. Desweiteren hat er im Namen des Debian Perl Teams die
Pflege der im Buch erwähnten Pakete debsums und equivs übernommen.
Dipl.-Inf. Frank Hofmann hat Informatik mit Nebenfach Englisch an der Technischen Universität Chemnitz studiert. Er bevorzugt das Arbeiten von unterwegs aus als Entwickler, Trainer und Autor. Nach Berlin, Kapstadt und Besançon (Franche-Comté) arbeitet er von Freiburg im Breisgau aus.
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 waren 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 kaum welche. 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. Hier im Buch zeigen wir Ihnen die verschiedenen (Schleich-)Wege, die wir kennen.
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 analogen Aufrufen von RPM,
YUM, DNF und Zypper — siehe [kommandos-zur-paketverwaltung-im-vergleich].
Bitte beachten Sie, dass sich nicht alle Verhaltensweisen identisch in
beiden Welten abbilden lassen.
Das vorliegende Buch will darum vor allem Klarheit schaffen und Ihnen die Zusammenhänge zwischen den einzelnen Programmen deutlich machen. Es hilft Ihnen, in jeder Situation das passende Werkzeug zur Paketverwaltung auszuwählen und es danach gekonnt einzusetzen. Die einzelnen Kapitel sind aufgabenbezogen zusammengestellt. In jedem Abschnitt finden Sie Lösungen, wie Sie die jeweilige Aufgabe mit den verschiedenen Werkzeugen umsetzen.
Der Praxisteil fokussiert auf komplexere Fragestellungen. Dazu fassen wir den aktuellen Stand der Entwicklung zusammen und beleuchten darüber hinaus die angrenzenden Programme bzw. die damit verbundenen Situationen im Alltag der Systembetreuung.
1.2.4. Baustellenstatus
Zum aktuellen Zeitpunkt (Frühjahr 2021) bewegt sich das Buch stramm darauf zu, den Umfang von 500 Seiten zu überschreiten. Als inhaltlich vollendet sehen wir den Teil 1 „Konzepte“ an. Kleinere Baustellen finden sich noch in Teil 2 „Werkzeuge“. Hingegen klaffen im Teil 3 „Praxis“ noch größere Lücken. Wir arbeiten kontinuierlich daran, diese Lücken zu schließen. Das gelingt nicht so einfach, weil dafür bspw. komplexere Setups notwendig sind oder auch weil die Dokumentation der Werkzeuge für den betrachteten Fall schlicht und einfach nicht vorhanden, (bislang) unverständlich oder gar veraltet ist.
1.2.5. 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. Wir freuen uns über alle Anmerkungen, die uns erreichen und helfen, das Buch für alle besser zu machen.
|
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.6. Online-Fassung
Unter https://buch.dpmb.org/ gibt es den jeweils aktuellsten Stand des
Buches auch in diversen Formaten zum Online-Lesen oder
Herunterladen. Derzeit sind es HTML, PDF und EPUB. Diese Fassungen
werden automatisch bei jedem git push frisch generiert.
Sollte die Ihnen vorliegende Fassung (sei es als Paket in einer Debian-Veröffentlichung oder als gedrucktes Buch) nicht aktuell genug sein, so schauen Sie doch mal in die Online-Fassung. Vielleicht wurde die entsprechende Stelle dort bereits aktualisiert.
1.2.7. Quellcode und Lizenz
Der o.g. Quellcode des Buches findet sich auf GitHub [dpmb-github] und ist unter der Creative Commons Namensnennung — Weitergabe unter den 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.8. Organisatorisch
Beide Autoren leben und arbeiten in recht unterschiedlichen Regionen — Axel Beckert in Zürich und Frank Hofmann in Kirchzarten bei Freiburg. Aufgrund der mitunter recht großen Distanz sind regelmäßige Arbeitstreffen nur begrenzt möglich und wurden daher 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 Aix-les-Bains, Ajacchio (Korsika), Ålesund (Norwegen), Andorra, Augsburg, Beauvais (Picardie), Bergneustadt, Berlin, Besançon, Biel/Bienne, Bottighofen (Bodensee, Schweiz), Bratland (bei Bergen, Norwegen), Bruchsal, Canterbury (Kent), Chemnitz, Cudrefin, Delémont, Engelberg-Titlis, Essen, Frankfurt/Main, Freiburg im Breisgau, Friedrichshafen, Genf, Germersheim, Goizueta (Baskenland, Spanien), Großer Sankt-Bernhard-Paß, Hamburg, Hannover, Heidelberg, Hout Bay und Kapstadt (beide Western Cape, Südafrika), Kirchzarten bei Freiburg im Breisgau, Koblenz, Lauchringen (Baden, Wutachtal), Laveno Mombello (Italien, Lago Maggiore), Lausanne, Magdeburg, Meersburg (Bodensee), Montpellier, Montreux, 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-Claude (Jura, Frankreich) Saint-Étienne, Saint-Jouin-Bruneval (Normandie), Saint-Victor-sur-Loire (Auvergne-Rhône-Alpes), Sankt Augustin (bei Bonn), Savines-le-Lac (Hautes Alpes, Frankreich), Insel Sokn (bei Stavanger, Norwegen), Tübingen, Tvinnefossen (Norwegen), Zernez (Engadin, Schweiz) und Zürich (siehe [fig.buchkarte]). Orange Kreise mit rotem Rand markieren Axels Stationen, rote Kreise mit orangenem Rand die Arbeitsorte von Frank. Manchmal überlappt sich das auch — dann ist es nur einer von beiden. 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.