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.

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.

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.

Zum aktuellen Zeitpunkt (Frühsommer 2023) hat das Buch den Umfang von 500 Seiten bereits überschritten. 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.

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.

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.

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.

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, Bern, Besançon, Biel/Bienne, Bottighofen (Bodensee, Schweiz), Bratland (bei Bergen, Norwegen), Bruchsal, Canterbury (Kent), Chemnitz, Cudrefin, Delémont, Edinburgh (Schottland), 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 (Rheinland), Konstanz am Bodensee, Lauchringen (Baden, Wutachtal), Laveno Mombello (Lago Maggiore, Italien), Lausanne, London, Magdeburg, Mannheim, Meersburg (Bodensee), Montpellier, Montreux, München, Oldenburg in Oldenburg, 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.

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. Die Prüfungen des Linux Professional Institutes (LPI), der Linux Foundation (LFC) [lfc] sowie die Linux+-Prüfung von CompTIA [comptia-linux] widmen dem Thema einen eigenen Schwerpunkt mit hoher Gewichtung (für LPIC-1 siehe [lpic-101]).

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.

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. Für den Bau von Debianpaketen empfehlen wir Ihnen den Blick in das Debian-Paketierbuch (kurz: dpb) von Michael und Mechtilde Stehmann [Debian-Paketierbuch].

Was Sie allerdings im vorliegenden Buch finden, ist die Zusammenstellung eines deb-Pakets — sprich: aus welchen Einzelteilen es besteht (siehe [aufbau-und-format]), wie Sie dieses in die Komponenten zerlegen (siehe [paket-auseinandernehmen]) und auch wieder zusammenbauen (siehe [pakete-bauen-mit-checkinstall]).

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.

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 erscheinen in englischer Sprache, nicht zuletzt weil die Lokalisierung der einzelnen Pakete bislang unvollständig ist. Die verwendeten Ausgaben auf dem Bildschirm und die Screenshots stammen hierbei von ganz unterschiedlichen Linux-Varianten und Veröffentlichungen — Debian GNU/Linux, Ubuntu, Xubuntu und Linux Mint. Die dabei eingestellten Lokalisierungen sind Deutsch oder Englisch.

Sie müssen auf Ihrem System über administrative Benutzerrechte verfügen, um einen Großteil der Beispiele nachvollziehen zu können. Wir weisen nicht jedes Mal explizit darauf hin
[Sie erlangen diese Berechtigung 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 verwendeten Prompt-Zeichens, ob dafür administrative Rechte notwendig sind oder nicht: # bedeutet hierbei ja und $ bedeutet nein. 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. Begonnen haben wir das Buch zu dem Zeitpunkt, als Debian 7 Wheezy die stabile Debian-Veröffentlichung war. Daher stammen viele Beispiele im Buch aus diesem Zeitraum. Spätere Inhalte setzen auf den Nachfolgern Debian 8 Jessie, Debian 9 Stretch, Debian 10 Buster, Debian 11 Bullseye und Debian 12 Bookworm auf. Alle Ausnahmen sind entsprechend gekennzeichnet, bspw. wenn wir zur Illustration auf ein Derivat wie Ubuntu zurückgegriffen haben.

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:

All dies qualifiziert Sie für das entsprechende Lernziel einer Linux-Zertifizierung. 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 auch als Debian-Paket-Maintainer agieren zu können [Debian-Wiki-Debian-Entwickler].

Wir pflegen eine buchbegleitende Webseite unter der URL:

https://www.debian-paketmanagement.de/

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!

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.

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, Musik und Dokumentation.

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:

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

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.

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 in Debian 7.0 Wheezy ein (leeres) Übergangspaket auf die passenden multiarch-fähigen Einzelpakete der Architektur i386. In Debian 8 Jessie ist es bereits nicht mehr enthalten, auch wenn man selbst heutzutage hier und da noch Pakete von Drittparteien findet, die davon abzuhängen scheinen.

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]).

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.

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]), 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.

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.

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].

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.

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 [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 vermehrt verwendet. Auf das angesprochene Programm tasksel gehen wir in [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. [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).

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.

Obwohl vielfach von außen anders wahrgenommen, zählt zur Debian-Distribution nur der Bereich main. Die anderen drei Bereiche sind lediglich Ergänzungen, die zusätzlich bereitgestellt werden. Wir empfehlen Ihnen daher, soweit möglich nur Pakete aus main zu verwenden, und nur wenn dies nicht ausreicht (z.B. wegen nicht-freier Firmware für bestimmte Hardwarekomponenten), die drei anderen Bereiche contrib, non-free und/oder non-free-firmware dazuzunehmen.

Pakete, die in main eingeordnet sind, unterliegen einer Lizenz, die den Debian-Richtlinien für Freie Software – kurz Debian Free Software Guidelines (DFSG) [DFSG] – entsprechen. Diese Richtlinien sind im Debian-Gesellschaftsvertrag festgelegt [Debian-Social-Contract] und weisen starke inhaltliche Gemeinsamkeiten zur Free Software Foundation (FSF) und zum GNU-Projekt auf.

Pakete im Bereich contrib stehen zwar genauso unter einer freien Lizenz wie die Pakete in main, bedingen jedoch weitere Software oder Inhalte, die nicht frei gemäß obiger Festlegung ist. Typische Gründe, warum ein Paket im Bereich contrib einsortiert wurde, sind:

In den beiden Bereichen non-free und non-free-firmware finden sich Pakete, die nicht den Debian-Richtlinien für Freie Software (DFSG) entsprechen, aber trotzdem immer noch frei verteilbar sind. Typische Gründe für die Nichterfüllung der DFSG sind:

Vor der Nutzung von Software aus diesen Bereichen ist es ratsam, immer erst anhand der Lizenz zu überprüfen, ob Sie diese Software überhaupt für Ihre gewünschten Zwecke einsetzen dürfen.

Für Software aus den beiden Bereichen non-free und non-free-firmware gilt außerdem, dass keine Unterstützung seitens Debian für diese Pakete möglich ist. Das trifft insbesondere dann zu, wenn der Quellcode nicht veröffentlicht wurde, wie das bspw. bei der Firmware zu bestimmten WLAN-Chipsätzen der Fall ist.

[fig.aptitude-unfreie-pakete] zeigt die Paketliste in Aptitude mit einem unfreien Paket aus dem Bereich Netzwerk – skype. Im abgebildeten Fall wurde es zudem nicht aus einem offiziellen Debian-Repository heruntergeladen, sondern aus einer anderen Quelle und danach manuell auf dem System eingepflegt.

Eine vollständige Übersicht zu allen nicht-freien Paketen, die auf ihrem System installiert sind, gibt Ihnen das Programm check-dfsg-status (vormals vrms) aus dem gleichnamigen Debianpaket [Debian-Paket-check-dfsg-status]. Darauf gehen wir unter „Liste der installierten, nicht-freien Pakete anzeigen“ in [unfreie-pakete-anzeigen]) ausführlicher ein.

Im Vergleich zu Debian sind bei Ubuntu die Distributionsbereiche etwas anders eingeteilt. Dort kommt neben den Lizenzen auch noch der Supportstatus zum Tragen. Dafür ist die Unterscheidung nach Softwarelizenzen auf frei oder unfrei reduziert: Es gibt main (frei, von Canonical unterstützt), restricted (unfrei, von Canonical unterstützt), universe (frei, nur Community-Unterstützung) und multiverse (unfrei, nur Community-Unterstützung). Zusätzlich existiert der Distributionsbereich partner, welcher für die Bereitstellung kommerzieller Software gedacht ist, deren Quellcode nicht offen liegt.

Andere Derivate von Debian bzw. Ubuntu (siehe „Paketformat im Einsatz“ unter [paketformat-im-einsatz]) oder nicht-offizielle Paketquellen (siehe „Paketquellen“ in [paketquellen]) können ebenfalls ihre eigenen Distributionsbereiche haben. Auf diese gehen wir hier nicht weiter ein.

Der Begriff „Software“ wird bei Debian recht weit gefasst und beinhaltet neben Programmcode auch Firmware, Dokumentation oder künstlerische Elemente wie beispielsweise Grafiken und Logos. Letztere stehen in manchen Fällen unter anderen Lizenzen als der Rest der Software und dürfen aus markenrechtlichen Gründen nicht für abgeänderte Programme verwendet werden.

Aus diesem Grund wurden 2006 einige Programme abgewandelt, bspw. der Webbrowser Iceweasel und das Mailprogramm Icedove, die im Original die Namen Firefox und Thunderbird tragen. Neben den beiden anderen Namen werden in Debian auch alternative Logos genutzt. Nach einer markenrechtlichen Einigung im Frühjahr 2016 sind seit Debian 9 Stretch Firefox und Thunderbird wieder zu Debian zurückgekehrt und lösen Iceweasel und Icedove wieder ab.

Bezogen auf die Anzahl der verfügbaren Softwarepakete findet sich der überwiegende Teil der Pakete im Bereich main, danach folgen contrib, non-free und non-free-firmware.

Für die Architektur amd64 in Debian 8 Jessie ist das Verhältnis 42987 (main) zu 250 (contrib) zu 470 (non-free). Damit sind das fast genau ein Prozent unfreie Pakete. Für die Plattform i386 ist die Verteilung ähnlich.

In der Klassifikation spiegelt sich die Offenheit und Vielfalt der Debian-Nutzer und -Entwickler sowie deren Weltbild wieder. Es zeugt von dem Verständnis dahingehend, welche Software Sie tatsächlich verwenden und nach welchen Kriterien Sie Ihre Pakete auswählen.

Je mehr Nutzer von Debian einbezogen werden, umso vielschichtiger sind die Varianten der Verwendung. Jeder Nutzer pendelt sich bei der Paketauswahl irgendwo zwischen den beiden Polen „nur freie Software“ und „freie und unfreie Software gemischt“ ein.

Erstere Gruppe versucht, ausschließlich freie Software zu verwenden und dazu auch unfreie in freie Software zu überführen, bspw. durch Nachbau, Neuentwicklung oder Anregen eines Lizenzwechsels. Dieser Schritt kann auch mit einem Funktionsverzicht einhergehen und ist vergleichbar mit der Überzeugung „so lange eine Technologie nur kommerziell/unfrei zur Verfügung steht, verwende ich diese nicht und nutze stattdessen Alternativen“. Die zweite Gruppe ist deutlich pragmatischer und folgt dem Gedanken „ich nutze die unfreie Variante, bis eine freie zur Verfügung steht, und steige dann um, wenn sie das kann, wie ich es brauche“. Dazwischen gibt es unendlich viele Abstufungen, die wiederum persönlichen Schwankungen unterliegen können.

Die Nutzung der Software hängt von den Bedürfnissen und dem Einsatzzweck ab. Viele Prozesse und Arbeitsabläufe bedingen eine bestimmte Menge von Eigenschaften („Featureset“), welche sich nicht immer adäquat und vollständig mit bestehender freier Software bzw. deren aktuellem Entwicklungsstand abbilden lässt. Dabei spielen die Faktoren Produktivität, Anbindung an bereits bestehende Software, Schnittstellen und unterstützte Hardware oder Protokolle eine große Rolle. Desweiteren sind das Budget, der Zeitrahmen und die Dokumentation bzw. der Support entscheidend. Über die Auswahl einer Lösung entscheidet häufig, welcher finanzielle Rahmen für eine Lösung zur Verfügung steht, welcher Zeitraum zur Inbetriebnahme gesetzt ist und wie gut die Dokumentation und der Support zur ausgewählten Software ist. Eine Software, die frei ist, aber nicht oder nur ungenügend zum tatsächlichen Einsatzzweck passt, ist an dieser Stelle zu hinterfragen und muss sich mit einer passenden Alternative messen lassen, auch wenn diese als unfrei eingestuft ist, aber damit im Nutzungszeitraum eine funktionierende und stabile Lösung erreicht wird.

Jedes aktuelle Debian-Paket gehört zu mindestens einem der nachfolgend beschriebenen Entwicklungsstände:

Darüberhinaus existiert der Paketbereich backports. Das beinhaltet Rückportierungen neuerer oder aktualisierter Pakete aus dem Entwicklungszweig testing nach stable, teilweise auch aus unstable. Das ist spannend, aber auch mit gewissen Risiken verbunden. Im Detail gehen wir darauf unter „Debian Backports“ in [debian-backports] ein.

Jede Veröffentlichung von Debian GNU/Linux hat einen Alias-Namen, der nach einer Figur aus Pixars Filmreihe Toy Story benannt ist. Bruce Perens — der Projektleiter für die Version 1.x — arbeitete zu dieser Zeit bei Pixar [Pixar] und legte das bis heute genutzte Namenschema fest. Für die bisherigen Veröffentlichungen von Debian standen die folgenden Figuren aus der Filmserie Pate:

Es stehen bereits ebenfalls die Namen von zwei zukünftigen Veröffentlichungen fest:

Mehr Details zu den einzelnen Veröffentlichungen finden sich in der Debian-Geschichte [Debian-History]. Die Figuren aus den verschiedenen Toy Story-Filmen und insbesondere deren Charakterzüge sind ausführlich im Disney Wiki [ToyStory] dokumentiert (siehe [fig.toystory]).

Auch bei der Bezeichnung der Aktualisierungen zur stabilen Veröffentlichung ergeben sich über die Jahre hinweg kleine Unterschiede. Anfangs erfolgte die Kennzeichnung durch Anhängen des Buchstabens r und der Nummer der Aktualisierung, z.B. 4.0r8 für die 8. Aktualisierung von Debian 4.0 Etch. Seit Debian 5.0 Lenny wird stattdessen ein Punkt verwendet, so z.B. 5.0.3 für die dritte Aktualisierung.

Seit Debian 4.0 Etch bekamen stabile Veröffentlichungen immer eine neue Nummer an erster Stelle. Seit Debian 7 Wheezy ist die Null an zweiter Stelle verschwunden. Stattdessen wird die Nummer der Aktualisierung genutzt, so z.B. 7.3 für die dritte Aktualisierung von Debian 7 Wheezy.

Neben den o.g. Entwicklungsständen haben alle Veröffentlichungen auch noch Alias-Namen, die eine Veröffentlichung stets unverändert beibehält. Jede neue Veröffentlichung startet nach einer stabilen Veröffentlichung als testing, wird dann bei der nächsten stabilen Veröffentlichung zu stable, bei der übernächsten zum oldstable und danach zu oldoldstable.

Ist eine Veröffentlichung — sei es als oldstable oder als oldoldstable — am Ende ihrer Unterstützung angelangt, wird sie in das Debian-Archiv [Debian-Archive] übertragen. Dieses Archiv beinhaltet alle nicht mehr unterstützten Veröffentlichungen.

Eine weitere Ausnahme bildet die Veröffentlichung zu unstable. Sie besitzt stets den gleichen Alias-Namen Sid. In der Filmreihe Toy Story ist das passenderweise der Name des bösen Nachbarkinds, welches immer alle Spielzeuge kaputt macht. Sid ist auch gleichzeitig ein Akronym für still in development – zu deutsch „noch in Entwicklung“ –, was den Status der Veröffentlichung der zukünftigen Distribution sehr treffend umschreibt.

Experimental trägt – analog zu unstable – immer den Alias-Namen rc-buggy, was im Debian-Jargon eine Kurzform für „contains release-critcal bugs“ darstellt. Das lässt sich sinngemäß als „in dieser Form ungeeignet zur Aufnahme in eine Veröffentlichung“ übersetzen.

Sieht man von Uploads nach experimental ab, fängt das Leben einer neuen Version eines Debianpakets mit dem Hochladen nach unstable an. Das Paket wird automatisch in testing übernommen, sobald einige Bedingungen erfüllt sind:

Das Debian-Release-Team kann allerdings diese Bedingungen individuell übersteuern und kürzere oder längere Fristen für den Übergang in die testing-Veröffentlichung setzen.

Zu einem bestimmten Zeitpunkt im Entwicklungszyklus einer neuen stabilen Veröffentlichung friert das Release-Team die testing-Veröffentlichung ein – auch genannt Freeze (engl. für Einfrieren). Ab diesem Moment wandern keine Pakete mehr automatisch von unstable nach testing und das Debian-Release-Team muss jeden einzelnen, weiteren Übergang eines Pakets explizit abnicken. Je länger der Freeze andauert, desto schärfer werden die Bedingungen, unter denen das Debian-Release-Team einen Übergang nach testing akzeptiert. Im Normalfall werden nur noch Paketversionen akzeptiert, die ausschließlich Fehler korrigieren und keine neuen Features einführen. Daher wird für diesen Zustand auch der Begriff Feature Freeze verwendet.

Auf diese Weise wird versucht, sämtliche veröffentlichungskritischen Fehler in der testing-Veröffentlichung zu beheben. Sobald es dort keinen dieser Fehler mehr gibt, geschehen die folgenden Dinge:

Wenn eine Paketversion von unstable nach testing wandert oder aus testing das neue stable wird, werden allerdings nicht wirklich Pakete kopiert. Stattdessen werden vielmehr nur die Metadaten des betreffenden Pakets von einer Paketliste in eine andere umgetragen. Das Paket selbst liegt immer noch an gleicher Stelle und nur einmal im sogenannten Paketpool.

So kann es vorkommen, dass ein Paket, welches nur selten aktualisiert wird, in allen aktuellen Veröffentlichungen in der gleichen Version vorkommt und dafür auch nur einmal auf jedem Spiegel des Debian-APT-Archivs liegt. Welches Paket dann aus den verschiedenen Entwicklungsständen bei einer Installation ausgewählt wird, erfahren Sie unter „Aus welchem Repo kommen die Pakete“ (siehe [aus-welchem-repo-kommen-die-pakete]) genauer.

Für unterstützte Veröffentlichungen, d.h. die aktuelle stabile Veröffentlichung ("stable release"), sowie mindestens ein Jahr nach einer Veröffentlichung für die vorherige stabile Veröffentlichung bietet Debian Sicherheitsaktualisierungen durch das Debian Security Teams [Debian-Security] an.

Im Frühjahr 2014 wurden zusätzlich sogenannte Long Term Support-Varianten [Debian-LTS] — auf Deutsch "Langzeitunterstützung" und kurz LTS — eingeführt. Diese verlängern den Zeitraum der weiteren Verfügbarkeit und Pflege einer Veröffentlichung von den typischerweise drei Jahren auf bis zu fünf Jahre.

In Folge wurde die im Jahr 2011 freigegebene und 2013 durch Debian 7 Wheezy abgelöste Veröffentlichung von Debian 6 Squeeze bis 2016 mit Aktualisierungen versorgt. Seither wurde jede weitere stabile Veröffentlichung nach ihrem offiziellen Lebensende ebenfalls als LTS mit Einschränkungen — z.B. nur noch die beliebtesten Architekturen — weitergeführt. Anfangs waren dies nur die beiden x86-basierten Architekturen i386 und amd64, momentan beinhaltet das zusätzlich auch noch alle drei ARM-basierten Architekturen (armel, armhf und arm64).

Debian LTS wird nicht wie die normalen Sicherheitsaktualisierungen vom Debian-Security-Team gehandhabt, sondern von einer Gruppe Freiwilliger wie auch Firmen, die daran interessiert sind, daß Debian LTS ein Erfolg wird — oft auch aus Eigenbedarf heraus. Dementsprechend übernimmt das Debian-LTS-Team das Bereitsstellen von Sicherheitsaktualisierungen vom Debian-Security-Team am Ende der normalen Unterstützungsdauer der Veröffentlichung.

Zur Nutzung von Debian LTS nach Ablauf des normalen Unterstützungszeitraumes muß an der Konfiguration des Systems nichts geändert werden. (Historisch galt diese Regel nicht für die allererste Debian Veröffentlichung mit LTS, Debian 6 Squeeze, welche eine Art Machbarkeitstest war. Aber da deren Langzeitunterstützung bereits abgelaufen ist, ist das heute von keiner Relevanz mehr.)

Da manchen Anwendern — vor allem aus dem professionellen Umfeld — auch die LTS-Varianten nicht lange genug Unterstützung anboten, gibt seit 2018 eine weitere Stufe der Verlängerung. Seit dem Auslaufen von LTS für Debian 7 Wheezy besteht das Projekt "Extended LTS", auf deutsch "Erweiterte Langzeitunterstützung" und kurz "ELTS", die die Unterstützung von Debian-Veröffentlichungen um weitere zwei Jahre auf ca. sieben Jahre verlängert. Im Gegensatz zu Debian LTS, welches immer noch ein Projekt unter dem Dach von Debian ist, ist Extended LTS ein kommerzielles Angebot, dessen Aktualisierungen jedoch trotzdem jeder nutzen kann.

Für welche Pakete es Aktualisierungen gibt, hängt jedoch davon ab, ob ein Paket jemandem wichtig genug ist, um sich am Arbeitsaufwand für dessen Sicherheitsaktualisierungen zu beteiligen. Interessieren sich mehrere Personen oder Organisationen für die Sicherheitsaktualisierungen desselben Paketes, so werden die Kosten entsprechend aufgeteilt. Die Koordination erfolgt über die französische Firma Freexian [Freexian].

Desweiteren gibt es im Vergleich zu LTS weitere Einschränkungen:

Die aktuellen Details zu den Einschränkungen als auch wie man Sponsor von Debian ELTS werden kann, ist auf der ELTS-Webseite von Freexian [Freexian-ELTS] erklärt.

Um die von der erweiterten Langzeitunterstützung bereitgestellten Paketaktualisierungen nutzen zu können, müssen Sie im Gegensatz zu Debian LTS zwei Dinge tun — 1.) ein weiteres APT-Repository zu Ihrer /etc/apt/sources.list (oder einer Datei im Verzeichnis /etc/apt/sources.list.d/) hinzufügen, und 2.) den PGP-Schlüssel des Extended-LTS-Projektes importieren. Wie das erfolgt, ist im 'Debian ELTS-HowTo [Debian-ELTS-HowTo] beschrieben. Im Folgenden dazu eine kurze Zusammenfassung:

Der erste Schritt ist das Herunterladen des aktuellen Schlüsselrings des Projektes als .deb-Paket von https://deb.freexian.com/extended-lts/pool/main/f/freexian-archive-keyring/ . Das Vertrauen liegt hierbei nur auf dem HTTPS-Zertifikat des Webservers.

Danach wird das heruntergeladene Paket mit Administrator-Rechten (d.h. als root oder z.B. mittels sudo) über den Aufruf dpkg -i freexian-archive-keyring*.deb installiert. Nun wird das APT-Repository durch das Hinzufügen der folgenden Zeile aktiviert:

Abschließend ist noch apt update oder ein Äquivalent aufzurufen, um die ELTS-Paketlisten herunterzuladen. Sind bereits Aktualisierungen verfügbar, so kann man diese direkt auch mit apt upgrade oder ggf. apt full-upgrade einspielen.

Feld 1 bezeichnet den Namen des Pakets, welches durch die Paketdatei bereitgestellt wird. Die Paketdatei iceweasel_3.5.16-12_i386.deb ist ein Binärpaket (Dateiendung .deb) und beinhaltet den Webbrowser Iceweasel in der Version 3.5.16 für die Architektur i386.

Darüberhinaus existieren bei der Benennung eine Reihe von Gepflogenheiten in Form von Präfixen und Suffixen. Diese stellen kein „muss“ dar, vereinfachen aber die Handhabung insgesamt sowie die Paketklassifikation und die spätere Recherche nach Paketen.

Beginnt der Paketname mit der Zeichenkette lib, handelt es sich meist um eine Bibliothek, auf englisch library. Als Beispiel seien hier die beiden XML-Bibliotheken libxml2-utils und libxml2 genannt. Aus dem Schema fallen allerdings die Komponenten zu LibreOffice wie libreoffice-writer (Textverarbeitung Writer) und libreoffice-calc (Tabellenkalkulation Calc) heraus.

Endet der Paketname mit dem Suffix -dev wie bspw. in libxslt1-dev, beinhaltet das Paket Kopfdateien (engl. header files), die nur notwendig sind, wenn Sie Programme unter Nutzung der dazugehörigen Bibliothek entwickeln. dev ist die gebräuchliche englische Abkürzung für development. Im Paket libxslt1-dev befinden sich beispielsweise die Kopfdateien zur XSLT-1-Bibliothek.

Das Suffix -doc weist auf Dokumentation hin, welches häufig noch von einer Abkürzung für die jeweilige Sprache gefolgt wird. Der Paketname aptitude-doc-es beinhaltet bspw. die spanische Übersetzung der Dokumentation zu aptitude.

Die Suffixe -common und -data deuten an, dass das Paket Dateien beinhaltet, die von mehreren Teilen eines Programms gemeinsam genutzt werden. Als Beispiel sei hier wireshark-common genannt, welches sowohl die Daten für die graphische Variante des Netzwerktools wireshark, als auch für die textbasierte Version tshark beinhaltet.

Feld 2 spiegelt eine Reihe unterschiedlicher Informationen und Zustände wieder, aus dem Sie den Versionsstand und -verlauf eines Pakets erkennen. Die Versionsangabe kann sowohl numerische Zeichen (Ziffern), als auch nichtnumerische Zeichen wie Punkte, Tilden und Buchstaben beinhalten.

Handelt es sich um ein nicht-natives Debian-Paket, besteht die Versionsnummer aus der Upstream-Version und der Debian-Revision. Bei dem Paket smartpm_1.4-2_all.deb für smartpm (siehe [gui-smartpm]) ist die Angabe 1.4 die Upstream-Version und die darauffolgende mit einem Minus - abgetrennte 2 steht für die zweite Debian-Revision. Hier liegt also das zweite Debianpaket vor, welches auf der Upstream-Version 1.4 basiert. Beinhaltet die Versionsnummer mehrere Bindestriche, ist immer der letzte Bindestrich der Trenner zwischen der Upstream-Version und der Debian-Revisionsnummer.

Handelt es sich hingegen um ein natives Debian-Paket, d.h. eine Software, die ausschließlich als Debian-Paket vertrieben wird, gibt es keine Debian-Revisionsnummer und die Versionsnummer des Pakets ist identisch mit der Versionsnummer der Software. Für das Paket dpkg_1.17.25_i386.deb zu dpkg ist das 1.17.25.

Ändert sich bei der Aktualisierung (Upstream) die Versionsangabe so grundlegend, dass die neuere Version eine kleinere Versionsnummer hat als die vorherige Version, so muss der Paketversion die Angabe einer mit einem Doppelpunkt abgetrennten Epoche hinzugefügt werden. Ist bspw. die vorhergehende Versionsnummer 2013.06.06-4 (Upstream-Version 2013.06.06 Revision 4), entspricht das der Epoche 0 und ist identisch zu 0:2013.06.06-4. Die Folgeversion wird dann 1:1.0-1, d.h. Epoche 1, Upstream-Version 1.0 und Revision 1.

Um eine spätere alphanumerisch korrekte Sortierung anhand des Releasestatus zu ermöglichen, sind eine bzw. mehrere aufeinanderfolgende Tilden ~ zulässig. Damit wird bspw. die Version 1.0~beta1 vor der Version 1.0 einsortiert. Diese Schreibweise kam zuerst bei Debian auf, wurde mittlerweile aber auch von anderen Open-Source-Projekten übernommen.

Zudem sind eine Reihe von Suffixen gebräuchlich. Diese gelten zwar nur als Konvention, werden aber auch an einigen Stellen erwartet.

Feld 3 in der Versionsangabe gibt an, für welche Architektur das vorliegende Paket übersetzt wurde. Die Benennung entspricht den Bezeichnungen, wie sie unter Debian-Architekturen in [debian-architekturen] aufgelistet sind. Die Angabe asterisk_1.8.13.1~dfsg-3+deb7u1_armhf.deb beschreibt die Paketierung der Telefoniesoftware Asterisk für die ARM-Plattform mit Hardware-Floating-Point-Unterstützung. Im Gegensatz dazu ist das Paket asciidoc_8.5.2-1_all.deb plattformunabhängig einsetzbar.

Ein vollständiges Beispiel für den Einsatz von multiarch ist die Nutzung des Forth-Interpreters pforth auf einem 64-bittigen Debian (Architektur amd64). pforth ist über das gleichnamige Paket bislang nur nativ für 32-Bit-Betriebssysteme verfügbar. Gleiches betrifft das recht weit verbreitete, aber nicht-quelloffene Kommunikationsprogramm Skype [Skype]. Eine passende Schritt-für-Schritt-Anleitung finden Sie im Debian Wiki [Debian-Wiki-Skype].

Im Folgenden zeigen wir Ihnen anhand des vorgenannten Pakets pforth, wie eine solche Installation abläuft und insbesondere, welche Einzelschritte wir dabei für beachtenswert halten. Zunächst überprüfen Sie mittels dpkg und dessen Option --print-architecture die derzeit benutzte Architektur Ihres Systems – im hier betrachteten Fall ist es amd64. Danach ergänzen Sie die Liste der Architekturen via dpkg --add-architecture i386 um i386 als weitere Plattform, für die Ihr System Pakete akzeptiert. Ob der Vorgang erfolgreich war, zeigt Ihnen der Parameter --print-foreign-architectures von dpkg an. Damit erhalten Sie eine Übersicht zu allen „Fremdarchitekturen“, die ihr Debiansystem derzeit akzeptiert.

Nun aktualisieren Sie die lokale Liste der verfügbaren Pakete mittels apt-get update, wobei APT nun auch die Informationen zu den Paketen der neu hinzugefügten Architektur herunterlädt.

Als nächsten Schritt prüfen Sie mit dem Aufruf apt-cache policy, für welche akzeptierte Architektur das von Ihnen gewünschte Paket bereitsteht. Die Details zum Aufruf von apt-cache finden Sie unter „Aus welchem Repo kommen die Pakete“ in [aus-welchem-repo-kommen-die-pakete].

Sie ersehen aus der obigen Ausgabe, dass das Paket bislang noch nicht auf Ihrem System installiert ist. Es steht für die Architektur i386 und die Veröffentlichung Debian 8 Jessie bereit. Nun können Sie das Paket pforth installieren. Das zieht u.a. das essentielle Paket libc6 für die Architektur i386 nach sich, um die Abhängigkeiten zum Paket pforth zu erfüllen.

In o.g. Fall wurde das Paket libc6 als Abhängigkeit auch für die Architektur i386 installiert. Sie erkennen das daran, dass neben dem Namen des Pakets auch die Architektur angegeben wird. Als Trennzeichen in der Ausgabe fungiert hier ein Doppelpunkt.

Abschließend überprüfen Sie mittels dpkg, für welche Architekturen die Pakete pforth und libc6 auf Ihrem System installiert sind.

Im letzten Schritt probieren Sie aus, ob das frisch installierte 32-Bit-Programm auch unter Ihrem 64-Bit-Betriebssystem funktioniert. Dazu rufen Sie das Programm auf.

Dieser Prioritätsstufe sind Pakete zugeordnet, die für die korrekte Funktion des Betriebssystem unbedingt erforderlich sind. Dazu gehören beispielsweise dpkg, coreutils für die GNU Core Utilities mit den Befehlen wie ls, rm, cp, mv, das Init-System (seit Debian 8 Jessie das Metapaket init) und die C-Standard-Bibliotheken (libc6 auf den meisten Architekturen).

Entfernen Sie eines oder mehrere Pakete mit dieser Prioritätsstufe, kann das Ihre Installation so stark beschädigen, dass selbst das Werkzeug dpkg nicht mehr funktioniert.

Systeme, die nur aus Paketen der Prioritätsstufe „erforderlich“ bestehen, sind zwar lauffähig, aber im Normalfall nahezu unbenutzbar, da z.B. Pakete wie APT, less oder ein Texteditor fehlen. Die letztgenannten sind zum Betrieb nicht zwingend erforderlich
[Hat z.B. ein System keine Netzwerkanbindung und wird deswegen nur sehr selten aktualisiert, ist APT nicht notwendig. Aktualisierungen können auch auf anderen Wegen, bspw. via USB-Stick oder SD-Karte mittels dpkg eingepflegt werden. Allerdings sind dann Abhängigkeiten ggf. manuell aufzulösen. Bei reinen Paketaktualisierungen ist dies nur sehr selten ein Problem, da die Abhängigkeiten im Normalfall auch schon von der vorherigen Paketversion gebraucht wurden.]
.

In diese Prioritätsstufe gehören alle Pakete, die auf jedem UNIX- bzw. Debian-System zu erwarten sind oder ohne die das System nur sehr schwierig zu warten wäre. Das schließt auch Server ohne Monitor mit ein.

Als Pakete gehören neben apt u.a. gnupg und debian-archive-keyring für den Debian-Archiv-Schlüsselring zum Überprüfen der Signaturen von Paketlisten (siehe [bezogenes-paket-verifizieren]) dazu, ebenso OpenSSL, ein DHCP-Client, zwei Texteditoren (eine abgespeckte Variante von Vim sowie Nano), Kommandozeilenwerkzeuge zur Prozessverwaltung (ps, kill, free, top, uptime aus dem Paket procps), ein Syslog-Daemon, ein Cron-Daemon, Man-Pages, Netzwerk-Programme wie ping, traceroute und iptables sowie das Netzwerkschnittstellenverwaltungssystem ifupdown.

Diese Prioritätsstufe beinhaltet weder große Applikationen noch graphische Programme. Insbesondere gehören weder GNU Emacs noch TeX noch das X Window System oder das xterm in diese Kategorie.

Haben Sie alle Pakete dieser Prioritätsstufe installiert, verfügen Sie über ein nicht allzu großes, aber auch nicht zu unkomfortables System ohne graphische Bedienoberfläche. Ein solches System wird im Debian Installer ausgewählt, wenn Sie als Administrator bei der Installation nicht explizit etwas anderes festlegen. Es enthält nur wenige größere Anwendungen und Daemons.

Dazu gehören u.a. ein abgespeckter Exim als lokales Mail-Server-Programm, die E-Mail-Programme mutt und mailx, eine vollständige Perl-Installation (d.h. Perl mitsamt allen „Core“-Modulen
[Perl selbst und ein paar wenige Perl-Module sind im Paket perl-base welches „essentiell“ ist.]
), Python, Client-Anwendungen für SSH, FTP, Telnet, NFS und Whois, ein Text-Modus-Webbrowser (w3m) und der allgegenwärtige Textdateien-Betrachter less. Außerdem ist reportbug enthalten, ein Programm zum Melden von Fehlern in Debian (siehe dazu „Bugreports anzeigen“ in [bugreports-anzeigen]).

Dies ist in gewisser Weise der Standardwert für die Priorisierung eines Pakets. Alle Pakete, die in keine der anderen Stufen gehören, werden dieser Prioritätsstufe zugeordnet. Sie enthält deswegen auch den Großteil aller Pakete in Debian. Optional bedeutet in diesem Kontext, dass diese Pakete nicht von jedermann benötigt werden.

In dieser Prioritätsstufe sind einerseits Pakete, die im Konflikt mit Paketen aus den anderen Prioritätsstufen stehen. Dazu zählen z.B. alternative Mail-Transport-Agents wie Postfix, alternative Cron-Daemons wie Cronie oder alternative Syslog-Daemons wie Syslog-NG oder die Syslog-Implementation aus Busybox.

Andererseits enthält sie aber auch Pakete, die nur in ganz bestimmten Fällen gebraucht werden, z.B. Programme zur Nutzung exotischer Hardware oder nur in bestimmten Umfeldern vorkommenden Daten, Pakete mit Debug-Symbolen für andere Pakete, Übergangspakete, etc. Beispielsweise sind viele Pakete aus dem Bereich „Wissenschaft“ mit dieser Priorisierung versehen.

Zusätzlich zu den bereits oben vorgestellten Prioritäten gibt es noch die Markierung essential. Diese Markierung tragen nur sehr grundlegende Pakete.

Pakete mit dieser Markierung müssen nicht explizit als Abhängigkeit bei anderen Paketen deklariert werden. In der Regel sind alle Pakete der Prioritätsstufe „erforderlich“ in dieser Form markiert, von denen kein anderes Paket dieser Stufe abhängt. Somit wird auch bei der Entfernung eines nicht-essentiellen Pakets der Stufe „erforderlich“ gewarnt. Das passiert jedoch nicht, wenn bei einer Umbenennung eines solchen Pakets das alte Paket entfernt wird, um für das neue Paket Platz zu machen oder weil es nicht mehr gebraucht wird (d.h. irgendwann nicht mehr notwendig ist).

Unter „Pakete nach Prioritäten finden“ in [pakete-nach-prioritaeten-finden] lesen Sie, wie Sie auflisten, welche Pakete genau auf Ihrer Version von Debian als essentiell markiert sind.

Weiterhin hat die Markierung „essentiell“ den Effekt, dass sich beispielsweise auch dpkg weigert, solche Pakete zu entfernen. Mit dem zusätzlichen Parameter --force-remove-essential übergehen Sie diese Voreinstellung und können die Aktion trotzdem durchführen (siehe dazu „Paketoperationen erzwingen“ in [paketoperationen-erzwingen]).

apt-get und aptitude entfernen diese Pakete nur nach Eingabe des vollständigen Satzes „Ja, tue was ich sage!“ (apt-get) bzw. „Mir ist klar, dass das eine sehr schlechte Idee ist.“ (aptitude). Diese Sätze werden jeweils in der eingestellten Sprache Ihres Debiansystems angezeigt (Lokalisierung), sofern eine Übersetzung vorhanden ist. Nachfolgendes Beispiel zeigt die Bildschirmausgabe vor der Entfernung des Pakets init [Debian-Paket-init].

Neben der Architektur der Installation und welche Pakete installiert sind, erfasst Popcon anhand der Zeitstempel im Dateisystem außerdem noch folgende Daten für jedes installierte Paket:

Werden weder Änderungszeitstempel noch Zugriffszeitstempel beim Projekt mitgeliefert, wird das Paket im Graphen no-files (keine Dateien) aufgelistet.

Unter dem Debian Popcon Graph [Debian-Popcon-Graph] können Sie dies sogar benutzen, um den Verlauf der Beliebtheit von Paketen gegenüberzustellen. [fig.popcon-screen-vs-tmux] zeigt beispielhaft einen Vergleich zwischen screen und tmux in den beiden Metriken installed und vote.

Diese Markierungen werden teilweise bereits automatisch von APT und aptitude gesetzt, wenn es Pakete installiert, entfernt oder aktualisiert. Als Systembetreuer können Sie jederzeit eingreifen und die Markierungen eigenhändig setzen und entfernen.

Die folgenden Paketmarkierungen sind in Benutzung:

Die Markierung manuell installiert entspricht defacto dem Nicht-Vorhandensein der Markierung automatisch installiert. Ein Paket hat jeweils immer genau eine der beiden Markierungen manuell installiert oder automatisch installiert.

Die vorgenannten Paketmarkierungen werden von dpkg (nur hold), APT und aptitude ausgewertet. Die Unterscheidung automatisch/manuell installiert wird dazu in der Datei /var/lib/apt/extended_states gespeichert, die hold-Markierungen in /var/lib/dpkg/status
[In früheren Debian-Veröffentlichungen wurden die hold-Markierungen von aptitude und dpkg getrennt gespeichert und apt-get wusste nichts von der hold-Markierung. Auch wurde die automatisch installiert-Markierung zuerst von aptitude eingeführt und dementsprechend anfangs nur in /var/lib/aptitude/pkgstates gespeichert.]

aptitude speichert weitere Informationen zu den Paketen eigenständig in der Datei /var/lib/aptitude/pkgstates. Dazu gehören:

Diese benutzerspezifischen Markierungen werden auch in der Textoberfläche (text-based user interface, kurz TUI) von aptitude angezeigt, jedoch können Sie diese dort nicht ändern.

Sichtbar werden alle Markierungen zu einem Paket, wenn Sie die Details dazu erfragen – entweder direkt über die Kommandozeile oder in der Textoberfläche zu aptitude. Wir verdeutlichen Ihnen das hier anhand des installierten und gehaltenen Pakets python-pkg-resources.

Auf der Kommandozeile rufen Sie hierfür aptitude mit dem Unterkommando show gefolgt vom Paketnamen auf. In den Zeilen 2 und 3 der nachfolgenden Ausgabe erfahren Sie einerseits, dass das Paket python-pkg-resources automatisch installiert wurde und die Version 18.8-1 nicht lokal eingespielt werden darf. Darüberhinaus wurde eine manuelle Markierung vergeben (broken-by-807773), die kennzeichnet, dass das Paket defekt ist (broken). Die Ziffernfolge referenziert die Nummer des Bugs im Debian Bug Tracking System (BTS) und ermöglicht Ihnen, nachzulesen, warum der Eintrag da ist.

In der Textoberfläche von aptitude bekommt jeder Eintrag in der Paketliste zusätzliche Buchstaben. Dabei stehen die Buchstaben h für hold und A für automatic (siehe [fig.aptitude-hold]).

aptitude kann ebenfalls nach allen Paketen fahnden, die automatisch installiert wurden und somit das Flag automatic tragen. Es kennt dazu das spezielle Muster ?automatic (Kurzform ~M) zum Unterkommando search. Ausführlicher besprechen wir das in „Automatisch installierte Pakete mit aptitude anzeigen“ in [automatisch-installierte-pakete-mit-aptitude].

Das Werkzeug apt-mark ist spezialisiert auf die Paketmarkierungen und kann Ihnen die Pakete ausgeben, bei denen nur ein bestimmtes Paketflag gesetzt ist. Es kennt dazu die folgenden sechs Unterkommandos

Nachfolgend sehen Sie beispielhaft nur das Ergebnis des Aufrufs für die manuell installierten Pakete. Auf automatisch installierte Pakete gehen wir genauer in [automatisch-installierte-pakete-anzeigen] ein. Dem Umgang mit dem Unterkommando showhold für die Verwendung des hold-Flags in der Praxis ist der Abschnitt „Ausgewählte Pakete nicht aktualisieren“ in [ausgewaehlte-pakete-nicht-aktualisieren] gewidmet.

apt-mark erlaubt keine Eingrenzung, welche Pakete überprüft werden. Es validiert stets den gesamten Paketbestand.

Die Markierungen automatic und manual werden von den Programmen zur Paketverwaltung eigenständig gesetzt, wenn Sie Pakete installieren. Grundlage sind die ausgewerteten Paketabhängigkeiten. Trotzdem können Sie stets eigenhändig eingreifen, sofern dazu Ihrerseits Bedarf besteht. apt-mark kennt dafür diese sechs Schalter:

Damit setzen Sie die entsprechende Markierung für ein angegebenes Paket explizit. Dazu erwartet apt-mark als Parameter ein einzelnes Paket oder eine Paketliste. Die nachfolgende Ausgabe zeigt das Setzen der Markierung manual für das Paket wireshark.

Für das Halten eines Pakets existieren die Unterkommandos hold und unhold. Welchen konkreten Nutzen das haben kann, erfahren Sie unter „Ausgewählte Pakete nicht aktualisieren“ in [ausgewaehlte-pakete-nicht-aktualisieren].

Durch das Setzen von Paketmarkierungen verändert sich die Art und Weise, wie die Paketabhängigkeiten bewertet werden. dpkg, apt, apt-get und aptitude respektieren die von Ihnen gesetzten Markierungen. apt, apt-get und aptitude empfehlen Ihnen bei einer Änderung des Paketbestands beispielsweise andere Pakete als sonst, um die Paketabhängigkeiten nicht zu verletzen. Oder sie schlagen vor, bestimmte Pakete zu entfernen, da sie neu als nicht mehr gebraucht angesehen werden.

Setzen oder Entfernen Sie bewusst das hold-Flag und legen somit eine Version explizit fest, nehmen Sie Einfluss auf den Zustand Ihres Systems. Wobei Ihnen das von Nutzen sein kann, erklären wir unter „Ausgewählte Pakete nicht aktualisieren“ ([ausgewaehlte-pakete-nicht-aktualisieren]) ausführlicher.

Alternativ zu apt-mark bietet sich auch aptitude an. Dort heißen die Unterkommandos etwas anders, ebenso agiert aptitude vielleicht ungewohnt. In der Standardeinstellung will es Pakete entfernen, die mangels geänderter Abhängigkeiten nicht mehr benötigt werden. Im u.g. Beispiel gibt es z.B. Pakete, die eine Abhängigkeit auf das Paket wireshark haben, aber keine, die eine Abhängigkeit auf zshdb haben. Entsprechend will aptitude es auch direkt entfernen.

Möchten Sie eine Markierung wieder aufheben, kennt aptitude den Schalter unmarkauto. Das nachfolgende Beispiel demonstriert das Vorgehen.

Dabei fällt auf, das aptitude im Gegensatz zu apt-mark nicht angibt, dass sich eine Markierung geändert oder nicht geändert hat. Stattdessen informiert es Sie darüber, dass es keine Pakete entfernt oder aktualisiert. Kurioserweise aktualisiert es (in der Standardeinstellung) nicht automatisch die Pakete, bei denen die hold-Markierung entfernt wurde:

Debianpakete sind von verschiedenen Orten und Medien verfügbar. Dazu zählen sowohl Online- als auch Offline-Quellen, bspw. offizielle, private und unternehmenseigene Repositories und Spiegelserver (Mirrors). Für die Recherche und Installation ohne Internetanbindung stehen bspw. vorbereitete Distributionsimages in unterschiedlichen Größen und Zusammenstellungen für CD, DVD, Blu-ray und USB-Stick über die Webseite des Debian-Projekts bereit [Debian-besorgen].

Je nach den persönlichen Vorlieben sowie der Bandbreite der lokalen Internetanbindung ist jeweils die eine oder andere Variante zur Installation empfehlenswert – eine pauschale Empfehlung können wir Ihnen an dieser Stelle leider nicht geben. Für eine Erstinstallation hat sich bei uns die Reihenfolge Bezug und Installation über ein kleines Installationsimage (genannt Netinst-ISO) und die nachfolgende, individuelle Auswahl der zusätzlich noch benötigten Programme über eine Netzwerkinstallation vielfach bewährt. Damit bleiben die eingerichteten Debian-Systeme von Beginn an überschaubar und pflegeleicht und enthalten möglichst wenig Ballast.

Die Auswahl eines Spiegelservers, der zu Ihren technischen Gegebenheiten und Gewohnheiten in der Benutzung Ihres Debian-Systems passt, ist eine Philosophie für sich. Auf die unterschiedlichen Varianten für bereits bestehende Spiegelserver gehen wir genauer in „Geeigneten Paketmirror auswählen“ in [geeigneten-paketmirror-auswaehlen] ein. Was Sie tun müssen, um hingegen einen eigenen Spiegelserver aufzusetzen und zu betreiben, geht über das Basiswissen deutlich hinaus. Wir erklären Ihnen die Vorgehensweise dazu in [eigenen-apt-mirror-aufsetzen].

Ist Ihnen der Name eines Pakets oder ein Fragment daraus bekannt, stehen Ihnen alle Möglichkeiten offen. Einerseits helfen Ihnen die Werkzeuge dpkg, apt-cache sowie aptitude auf der Kommandozeile weiter. Desweiteren verfügen die graphischen Programme wie beispielsweise Synaptic (siehe [gui-synaptic]), SmartPM (siehe [gui-smartpm]) oder auch PackageKit (siehe [gui-packagekit]) über eine entsprechende Suchfunktion. Für eine Recherche über das Internet hilft Ihnen nicht nur die Webseite des Debian-Projekts weiter, sondern auch spezielle Suchmaschinen und Verzeichnisdienste. Alle genannten Varianten stellen wir Ihnen unter „Pakete über den Namen finden“ in [pakete-ueber-den-namen-finden] genauer vor.

Bei den oben angesprochenen Varianten können Sie neben der Einordnung in die jeweilige Paketkategorie (siehe dazu „Sortierung der Pakete nach Verwendungszweck“ in [sortierung-der-pakete-nach-verwendungszweck]) bspw. auch über die Veröffentlichungen (siehe [veroeffentlichungen]), den Maintainer (siehe [paket-nach-maintainer-finden]), den Paketinhalt (siehe [paket-zu-datei-finden]) oder ein Fragment aus dem Paket (siehe [nach-muster-in-einem-paket-suchen]) suchen. Darüber hinaus gibt es eine konzept- und facettenbasierte Suche mit Hilfe von Debtags. Letzteres besprechen wir detailliert unter „Erweiterte Paketklassifikation mit Debtags“ in [erweiterte-paketklassifikation-mit-debtags].

Eine Paketquelle bezeichnet einen Ort, von dem aus Softwarepakete zur Verfügung stehen. Alternativ und gleichbedeutend werden dafür auch die Begriffe APT-Repository, Repository oder ganz kurz nur Repo benutzt. Der Begriff Paketmirror – oder auch komplett eingedeutscht als Paketspiegel – wird ebenfalls gerne verwendet. Letzteres impliziert aber zusätzlich, dass es sich dabei um eine vollständige Kopie einer offiziellen Paketquelle handelt, also z.B. um einen Spiegelserver von Debian oder Ubuntu.

Eine Paketquelle kann dabei aber auch ein externes Speichermedium wie eine CD, DVD, Blu-ray, eine Speicherkarte oder ein USB-Stick sein, aber ebenso ein lokales oder über das Netzwerk angebundenes Verzeichnis auf einer Festplatte. Waren noch vor wenigen Jahren die erstgenannten, festen Installationsmedien üblich, werden heute als Paketquelle aufgrund der weitestgehend flächendeckenden Verfügbarkeit des Internets stattdessen FTP- und HTTP-Server bevorzugt. Damit sind die von Ihnen genutzten Paketquellen stets aktuell.

Welche Paketquellen Sie verwenden, legen Sie bei Debian an zwei Stellen im Verzeichnisbaum fest:

Diese Dateien zählen zu den zentralen Komponenten des Debian-Paketsystems. An diesen Einträgen orientieren sich die Werkzeuge zur Paketverwaltung, wenn es um Änderungen im lokalen Paketbestand und entsprechende Aktualisierungen der Pakete auf Ihrem System geht.

Bei der Auswahl der Paketquellen sind Sie nicht auf lediglich eine dieser o.g. Ressourcen beschränkt. Sie können diese beliebig mischen und somit auch Konzepte zur Ausfallsicherung umsetzen. Diese Konstellation kommt genau dann zum Tragen, wenn Ihre primäre Paketquelle nicht in der gewohnten Art und Weise zur Verfügung steht, bspw. bei einem Ausfall des Internetzugangs oder der Wartung des von Ihnen bevorzugten Paketspiegels.

Jede Paketquelle folgt einer festgelegten Verzeichnisstruktur [Aoki-Debian-Referenz], auf die sich die einzelnen Programme zur Paketverwaltung stützen. Interessant wird diese Struktur genau dann, wenn Sie eine Paketquelle mit selbsterstellten Paketen oder einen eigenen Paketmirror aufsetzen und betreiben möchten (siehe [eigenen-apt-mirror-aufsetzen]).

Wie auf UNIX/Linux-Systemen üblich, ist die Konfigurationsdatei /etc/apt/sources.list eine reine Textdatei. Die Einträge darin erfolgen zeilenweise. Jede einzelne Paketquelle beschreiben Sie vollständig in einer separaten Zeile.

Sie fügen eine weitere Paketquelle hinzu, indem Sie die Liste um eine weitere Zeile ergänzen. Tragen Sie dazu in einer freien oder zusätzlichen Zeile die gewünschte Paketquelle nach. Um eine bereits erfasste Paketquelle zu modifizieren, ändern Sie den Listeneintrag in der entsprechenden Zeile. Mit Hilfe des #-Zeichens zu Beginn einer Zeile kommentieren Sie den jeweiligen Eintrag aus. Eine Paketquelle entfernen Sie endgültig aus der Liste, indem Sie die betreffende Zeile löschen.

Bei der späteren Aktualisierung der lokalen Paketliste mittels apt-get update, aptitude update oder apt update (siehe [pakete-aktualisieren]) werden die Paketquellen in der Reihenfolge abgearbeitet, wie sie in der Datei /etc/apt/sources.list aufgeführt sind. Ignoriert werden dabei Leerzeilen und die Einträge, die mit einem Hashzeichen # beginnen und somit auskommentiert sind.

Zur Automatisierung des Vorgangs wurden ebenfalls eine Reihe von Programmen entwickelt. Dazu zählen apt-cdrom (siehe dazu [physische-installationsmedien-mit-apt-cdrom-einbinden]) und add-apt-repository (siehe dazu [eintraege-mit-add-apt-repository-im-griff-behalten])). Sind Sie hingegen weniger tastaturaffin, bieten sich als weitere Möglichkeiten sowohl Synaptic sowie der Sources List Generator für Debian und Ubuntu an. Diese Programme stellen wir Ihnen in [einstellungen-mit-synaptic] und [debian-und-ubuntu-sources-list-generator] ausführlicher vor.

Jeder Eintrag in der Datei /etc/apt/sources.list folgt einem festen Muster mit einer genauen Abfolge von definierten Feldern:

Jedes dieser Felder hat eine bestimmte Funktion und erlaubt nur ausgewählte Inhalte:

Der Standardeintrag für den Bezug von stabilen Debianpaketen aus dem Bereich main mit dem deutschen Spiegelserver als Paketquelle sieht folgendermaßen aus:

Mit diesem Eintrag beziehen Sie stets nur Pakete aus der aktuellen, stabilen Veröffentlichung. Erscheint eine neue Veröffentlichung, sind Sie damit auf der sicheren Seite und wechseln automatisch zum Nachfolger.

Tragen Sie hingegen anstatt von stable den entsprechenden Aliasnamen der Veröffentlichung in Kleinbuchstaben wie bspw. bullseye oder bookworm ein, nutzen Sie ausschließlich Pakete aus der damit spezifizierten Veröffentlichung, die diesen Aliasnamen trägt. Möchten Sie später von dieser auf eine andere Veröffentlichung wechseln, passen Sie zunächst den Aliasnamen im Eintrag entsprechend an und aktualisieren nachfolgend die lokale Paketdatenbank (siehe „Distribution aktualisieren“ in [distribution-aktualisieren]).

Um hingegen zusätzlich die Pakete aus weiteren Paketbereichen wie bspw. contrib, non-free und non-free-firmware zu verwenden, ändern Sie den Eintrag auf das Folgende, hier wiederum mit expliziter Angabe des Aliasnamens bookworm:

In welcher Reihenfolge Sie die einzelnen, gewünschten Paketbereiche angeben, spielt keine Rolle. Üblich ist jedoch die Abfolge anhand des Freiheitsgrades der Softwarelizenz in der Form von main contrib non-free non-free-firmware.

Pakete können Sie auch aus einem Verzeichnis ihres Debian-Systems integrieren. Dabei sind Sie nicht auf lokale Einträge beschränkt, sondern können auch auf entfernte Ressourcen zugreifen, bspw. ein NFS- oder SMB-Share. Voraussetzung ist allerdings, dass die angegebene Ressource vorab in den Verzeichnisbaum eingehängt wurde (auf engl. mounted) und APT darauf zugreifen darf. Eine lokale Ressource geben Sie über das Schlüsselwort file an, hier am Beispiel des Verzeichnisses /home/benutzer/debian:

Ein Eintrag für einen externen Datenträger, bspw. eine CD, DVD oder Blu-ray, sieht ähnlich wie die vorhergehenden Beispiele aus. Nach dem Schlüsselwort deb folgt der Wert cdrom mit der Kennung des Datenträgers zur Installation. Am Schluss des Eintrags finden Sie die Veröffentlichung und den Distributionsbereich. Nachfolgend sehen Sie einen Eintrag für eine CD, auf dem Ubuntu 12.04 LTS Precise Pangolin enthalten ist:

Häufig, aber in unregelmäßigen Abständen – d.h. wenn es erforderlich ist – kündigt das Debian Security-Team [Debian-Security] Sicherheitsaktualisierungen an und stellt diese bereit. Um von diesen Aktualisierungen zu profitieren, braucht es einen entsprechenden Eintrag in der Datei /etc/apt/sources.list.

Typischerweise wird dieser bereits zum Installationzeitpunkt vom Debian Installer angelegt, falls die entsprechende Frage mit "Ja" beantwortet haben.

Hatten Sie während der Installation bei der Frage nach Sicherheitsaktualisierungen "Nein" ausgewählt, oder fehlt der Eintrag aus sonstigen Gründen, so können Sie diesen manuell nachtragen.

Allerdings ist an dieser Stelle darauf zu achten, dass sich das Format des Eintrages zwischen Debian 10 Buster und Debian 11 Bullseye leicht geändert hat.

Entsprechend hier Beispiele für Debian 10 Buster, Debian 11 Bullseye und Debian 12 Bookworm:

Obige Angaben beinhalten wiederum die empfohlene explizite Verwendung des Aliasnamens der Veröffentlichung anstatt des Suite-Namens. Dieser Name wird gefolgt vom Unterverzeichnis updates und den daraus gewünschten Distributionsbereichen main, contrib und non-free sowie ab Debian 12 Bookworm auch non-free-firmware. Je nach System nicht benötigte Archiv-Bereiche (z.B. non-free oder non-free-firmware) können Sie einfach weglassen.

Nicht alle verfügbaren Softwareveröffentlichungen werden in die offiziellen Paketquellen von Debian aufgenommen. Viele Projekte stellen Programmversionen als deb-Pakete bereit, die sich von der Version her von der stabilen Veröffentlichung von Debian unterscheiden.

Im folgenden Beispiel sehen Sie die Einbindung der Paketquellen des PostgreSQL-Projekts [APT-Repo-PostgreSQL] und des X2Go-Projekts [APT-Repo-X2Go] für Debian 10 Buster:

Ähnliches gilt für Unternehmen, die erfreulicherweise inzwischen vielfach eigene deb-Pakete für ihre Produkte zur Verfügung stellen. Die exakte Bezugsquelle finden Sie zumeist auf der Webseite des jeweiligen Unternehmens. Um bspw. die Pakete für den Webbrowser Opera des gleichnamigen skandinavischen Herstellers einzubinden, hilft Ihnen folgender Verweis
[Die aktuelle Konfiguration des APT-Repositories erlaubt nur die Verwendung von stable als Veröffentlichung. Verwenden Sie z.B. stretch anstatt von stable, so beschwert sich APT, dass dies nicht vorgesehen sei.]
auf den Bereich non-free auf dessen Paketserver:

Um Debian-Quellpakete (siehe [sourcepakete]) zu nutzen, benötigen Sie eine weitere Zeile in ihrer Paketliste. Im Vergleich zu Binärpaketen ändert sich lediglich das Schlüsselwort am Anfang eines Eintrags von deb auf deb-src. Danach erwartet APT wie gewohnt den Eintrag der Paketquelle. Für die offiziellen Quellpakete sieht der Eintrag wie folgt aus, hier am Beispiel des deutschen Paketmirrors für Debian 12 Bookworm:

Liegt ihr Lebens- und Arbeitsmittelpunkt in Deutschland oder Sie beziehen die Pakete von einem Paketmirror, der in Deutschland steht, enthält die Datei typischerweise die folgenden Einträge:

Mit den ersten beiden Zeilen beziehen Sie alle Binär- und Sourcepakete für die Distributionsbereiche main, contrib und non-free für die Veröffentlichung Debian 12 Bookworm vom primären deutschen Debian-Spiegelserver. Mit den Zeilen drei und vier beziehen Sie zusätzlich die dazugehörigen Sicherheitsaktualisierungen für alle Distributionsbereiche der gleichen Veröffentlichung von der zentralen Stelle security.debian.org.

Für Veröffentlichungen vor Debian 12 Bookworm müssen Sie allerdings den Distributionsbereich non-free-firmware weglassen. Dieser kam erst mit Debian 12 Bookworm hinzu. Paket aus diesem Bereich waren bei vorherigen Veröffentlichungen im Bereich non-free mit dabei.

Beim Ergänzen oder Ändern von Einträgen von Paketquellen können uns Fehler unterlaufen, die dazu führen, dass die lokalen Paketlisten nicht mehr sauber mit den Listen vom Paketmirror abgeglichen und aktualisiert werden. Üblicherweise sind das simple Schreibfehler — fehlende Leerzeichen oder auch falsche Namen der genutzten Veröffentlichung. Um diesen Fehlern auf die Spur zu kommen, verfügen bislang weder APT, noch apt-get und aptitude über ein spezifisches Unterkommando, mit dem sich die einzelnen Einträge auf korrekte Schreibweise prüfen lassen.

Daher bleiben nur die folgenden Workarounds:

Das Debian-Projekt pflegt eine offizielle Liste seiner Paketmirrors [Debian-Spiegel-Liste]. Diese Liste ist in primäre und sekundäre Mirrors gegliedert.

Primäre Mirrors sind dabei als zentrale, stets aktuelle Bezugspunkte mit hoher Last ausgelegt. Neben einer guten Netzanbindung bieten diese auch eine hohe Verfügbarkeit. Sie werden automatisch aktualisiert, sofern es Änderungen im Debian-Projekt bzw. dessen Paketarchiv gibt. Ein Mirror dieser Kategorie ist nach dem folgenden Namensschema erreichbar:

Die Länderkennung richtet sich nach dem ISO-Namensschema. Für Deutschland ist das de, für Österreich at und für die Schweiz ch. Der deutsche primäre Paketmirror ist somit unter ftp.de.debian.org erreichbar, der österreichische unter ftp.at.debian.org und der schweizerische unter ftp.ch.debian.org.

Primäre Debian-Mirrors stehen häufig bei Internetprovidern oder Lehr- und Forschungseinrichtungen. Beispielsweise steht der primäre Schweizer Debian-Paketmirror ftp.ch.debian.org an der ETH Zürich und einer der Debian-Paketmirrors für Deutschland an der TU Dresden.

Sekundäre Mirrors unterscheiden sich dahingehend von primären Mirrors, dass nicht garantiert ist, dass das volle Spektrum an Debianpaketen und Architekturen (siehe [debian-architekturen]) geboten wird. Hintergrund kann bspw. eine Begrenzung des verfügbaren Speicherplatzes auf dem Server sein. Das bedeutet jedoch nicht zwangsläufig, dass dieser Mirror schlechter erreichbar sein muss. Im deutschsprachigen Raum betreiben entsprechende Paketmirrors bspw. die Uni Erlangen, die TU Graz und SWITCH, das Schweizer Hochleistungsnetzwerk für die Wissenschaft [SWITCH].

Für jeden Paketmirror existiert eine Beschreibung, die diesen genauer klassifiziert. Dazu gehört z.B. die URL, der Aliasname, der Typ des Paketmirrors, die darüber verfügbaren Architekturen (siehe [debian-architekturen]) sowie die Informationen zum genauen Standort, zum Betreuer bzw. Betreiber und der Anbindung (IPv4 oder IPv6). Nachfolgender Auszug zeigt die Details für den Paketmirror ftp.de.debian.org, der an der TU Dresden beheimatet ist. Die Auswahl des Mirrors erfolgte daher, weil dieser den vollen Leistungsumfang bietet — von diesem Mirror bekommen Sie das ganze Debian-Spektrum.

Für die anderen deb-basierten Distributionen sieht das ähnlich wie bei Debian aus. Eine aktuelle Liste finden Sie auf der Webseite der jeweiligen Distribution, bei Ubuntu hingegen im Entwicklerportal [Ubuntu-Mirrors]. In [fig.linuxmint-mirrors] sehen Sie die Zusammenstellung für die Distribution Linux Mint.

Steht Ihnen lediglich ein Zugang über einen Webbrowser zur Verfügung, sind Sie trotzdem nicht vom Paketarchiv abgeschnitten. Unter dem Abschnitt „Browserbasierte Suche“ in [browserbasierte-suche] erfahren Sie, wie Sie die benötigten Pakete mit Hilfe ihres Webbrowsers recherchieren, vom Paketmirror beziehen und sauber unter Beachtung der Paketabhängigkeiten auf ihrem System installieren. Unter „Webbasierte Programme“ in [webbasierte-programme] stellen wir Ihnen weitere clevere Lösungen zur webbasierten Paketverwaltung für verschiedene Linux-Distributionen vor.

Die beiden Programme netselect und netselect-apt überprüfen den von Ihnen benannten Spiegelserver anhand von mehreren Kriterien. Dazu gehört primär die grundsätzliche Erreichbarkeit über das Netzwerk, die Pingzeit – d.h. wieviel Zeit benötigt ein Netzwerkpaket vom Paketmirror zu Ihrem Computer – , sowie die Verlustrate der Netzwerkpakete vom Spiegelserver zu Ihnen. Gleichzeitig wird die Anzahl der Zwischenknoten von Ihrem Computer zum Spiegelserver gezählt, auch genannt Hops. Bevorzugt werden lokale Paketmirrors, was sich auch im daraus errechneten Zahlenwert niederschlägt. Je kleiner der ermittelte Wert ist, umso besser ist das für Sie.

Zwischen netselect und netselect-apt bestehen die folgenden Unterschiede:

In den meisten Fällen gibt es zu einem Servernamen genau eine IP-Adresse (oder je eine IPv4- und eine IPv6-Adresse). Stärker in Anspruch genommene Dienste verteilen die Last aber oftmals auf mehr als eine Maschine. In solchen Fällen werden gerne mehr als eine IP-Adresse pro Servernamen zurückgegeben. Daraufhin wählt das Programm, welches eine Verbindung aufbauen möchte, willkürlich eine der zur Auswahl stehenden IP-Adressen aus. Auf diese Weise kann die Last zwischen mehreren (identisch konfigurierten) Servern aufgeteilt werden.

Ein bekanntes Beispiel eines solchen Falles im Kontext von Debian Paketspiegeln ist ftp.us.debian.org. Aufgrund der Größe der USA wird die Last des dortigen primären Debian-Paketmirrors auf drei Server aufgeteilt.

Auch wenn es vier IP-Adressen sind, handelt es sich jedoch nur um drei Server. Sowohl die IPv6-Adresse 2610:148:1f10:3::89, als auch die IPv4-Adresse 128.61.240.89 gehören zum Server debian.gtisc.gatech.edu.

Bei diesem Verfahren wird einer IP-Adresse ein geographischer Standort zugeordnet. Die Genauigkeit dieser Funktion schwankt je nach Internet-Anbieter, Datenbank und eingesetztem Verfahren.

Zu beachten ist dabei, dass der angegebene Standort nicht notwendigerweise dem tatsächlichen Standort des Rechners mit dieser IP-Adresse entspricht. Meistens ist das der Standort des Providers, von dem Sie diese IP-Adresse bezogen haben bzw. der diese IP-Adresse vergeben hat.

Eine Offline-Zuordnung ermöglicht beispielsweise das Paket geoip-database [Debian-Paket-geoip-database]. Es enthält eine entsprechende Datenbank mit stets bestehenden, festen IP-Adressen. Darüberhinaus existieren jedoch auch deutlich exaktere Alternativen.

Diese Funktionalitat lässt sich nutzen, um anhand der anfragenden IP-Adresse automatisiert einen geographisch nahen Paketmirror zu finden. Bei Debian ist dies an mehreren Stellen im Einsatz.

CDN steht für "Content Distribution Network" und beschreibt einen Service, der über die Welt verteilt viele Server stehen hat und je nach Qrt der Anfrage ein anderer Server kontaktiert wird. Die Verteilung auf verschiedene Server passiert dabei auf unterschiedliche Weisen. Mal antwortet unter der selben IP-Adresse ein anderer Server und die Verteilung wird per Routing gelöst. Mal kommt je nach Ort der DNS-Anfrage eine andere IP-Adresse als DNS-Antwort zurück.

Die Sicherheitsaktualisierungen von Debian kommen nicht über das normale Spiegelnetzwerk, welches regulär nur alle sechs Stunden aktualisiert wird. Stattdessen besteht ein separates Spiegelnetzwerk unter dem Hostnamen security.debian.org, das nur nach Bedarf aktualisiert wird. Dieses Spiegelnetzwerk verwendet schon seit längerem ein CDN.

Seit einigen Jahren ist aber auch die Standard-Einstellung in der sources.list-Datei von Debian der Hostname deb.debian.org, der auch wiederum auf ein CDN zeigt, zur Zeit auf das CDN von Fastly [debian-partners-fastly].

Eine DNS-Anfrage auf diesen Hostnamen aus der Schweiz sieht so aus:

Eine DNS-Anfrage aus Schweden dagegen anders:

APT kann seit Version 0.8 (ca. Ende 2010, ab Debian 6 Squeeze und Ubuntu 10.10 Maverick Meerkat) über das Schlüsselwort mirror in der Datei /etc/apt/sources.list seine Paketquelle aus einer Liste von Paketspiegeln aussuchen [Vogt-Apt-Mirror].

Offizielle Mirror-Listen im passenden Format gibt es bisher jedoch nur von Ubuntu. Für Ubuntu 12.04 LTS Precise Pangolin sieht der Eintrag für generell gut erreichbare Paketmirrors wie folgt aus:

In diesem Fall wird z.B. beim Aufruf von apt-get update zunächst die Mirror-Liste unter http://mirrors.ubuntu.com/mirrors.txt heruntergeladen. In dieser Datei stehen die Basis-URLs mehrerer Paketquellen. Danach sucht sich APT per Zufall eine der dieser Paketquellen aus und lädt von dort die spezifizierten Paketlisten herunter.

Clientseitig nutzt dieses Verfahren keinerlei GeoIP-Informationen, sondern wählt pro Maschine einen zufälligen Paketspiegel aus. Zunächst deutet o.g. URL auf eine simple Textdatei hin. Diese Datei wird jedoch bei jedem Aufruf automatisch neu generiert und — ähnlich wie die Weiterleitungen beim Debian Redirector — je nach anfragender IP dynamisch mit URLs anderer Spiegel gefüllt. Laden Sie diese Datei aus der Schweiz herunter, kann sie z.B. so aussehen:

Aus Österreich sieht die Liste dagegen z.B. so aus:

Erfragen Sie die Liste in Deutschland oder Frankreich, kommen sogar noch deutlich mehr Paketspiegel zur Auswahl. Eine Abfrage von einem Server, der bei dem deutschen Internetdienstleister Hetzner gehostet wird, ergab 34 aufgelistete Paketspiegel
[Um keine unübersichtlich langen Beispiele abzudrucken, wurden hier absichtlich die beiden Beispiele aus dem deutschsprachigen Raum gewählt, die relativ kurze Listen ergeben.]
.

Auffällig ist allerdings, dass als letzter Paketmirror in dieser Liste jeweils immer auch noch archive.ubuntu.com angegeben wird. Unter diesem Hostnamen sind per DNS Round Robin wiederum zur Zeit sechs verschiedene Server von Canonical erreichbar.

Alternativ zum dynamisch generierten mirrors.txt können Sie bei Ubuntu auch eine Paketspiegel-Liste per Land angeben. Für Deutschland gibt es eine Liste von deutschen Ubuntu-Paketspiegeln unter http://mirrors.ubuntu.com/DE.txt. Diese verwenden Sie z.B. für Ubuntu 14.04 LTS Trusty Tahr wie folgt in der /etc/apt/sources.list:

Wenn Sie möchten, können Sie dieses Feature von APT natürlich auch nutzen, um eine Liste ihrer favorisierten Paketspiegel selbst zusammenzustellen — auch unter Debian.

Unter https://www.debian-paketmanagement.de/hetzner-mirrors.txt haben wir z.B. eine Liste von Paketspiegeln für Debian erstellt, die alle bei dem deutschen Internetdienstleister Hetzner gehostet sind (ohne Gewähr) und somit für andere ebenfalls dort gehostete Server nicht mit ins Trafficvolumen zählen. Der passende Eintrag in der /etc/apt/sources.list sind dann so aus:

Egal, ob Sie eine der o.g. Methoden zur automatischen Auswahl des Paketspiegels verwendet haben oder ob Sie einen bestimmten Hostnamen in ihrer /etc/apt/sources.list eingetragen haben — oft stellt sich die Frage: Von welchem Paketspiegel bezieht APT denn nun die Paketlisten und Pakete tatsächlich? APT gibt diese Information leider nicht allzu leicht preis.

Falls einem der schlussendlich verwendeten Hostnamen mehr als eine IP zugewiesen ist, wird eine davon zufällig ausgewählt. APT und aptitude verwenden diese IP-Adresse intern, zeigen sie aber erst dann an, wenn Sie eines der Programme zur Paketverwaltung benutzen und die zusätzliche Option -o Debug::pkgAcquire::Worker=true verwenden. Damit wird APT sehr gesprächig und zeigt en detail, welche Einstellungen es benutzt. In dem nachfolgendem Beispiel sehen Sie das auszugsweise bei der Installation des Pakets netselect-apt.

Deutlich übersichtlicher ist jedoch die Demo-Seite des Debian Redirectors [Debian-Redirector]. Neben dem aktuellen Standort — hier Berlin — zeigt [fig.debian-net-demo] die ausgewählten Paketquellen als Hostname an.

Weitere Ansatzpunkte zur Leistungsfähigkeit eines bestimmten Mirrors liefern Ihnen die Werkzeuge netselect bzw. netselect-apt. Beide Programme stellen wir unter Bandbreite zum Paketmirror testen in [am-besten-erreichbaren-paketmirror-finden] ausführlich vor.

add-apt-repository akzeptiert als Parameter neben der Angabe des Repositories in Form einer vollständigen Zeile in korrekter Quotierung ebenso Personal Package Archives (PPAs) aus dem Ubuntu Launchpad [Ubuntu-Launchpad]. Der Aufruf ist von der Abfolge her analog zum manuellen Eintrag in der Liste der Paketquellen (siehe [etc-apt-sources.list-verstehen]):

Möchten Sie das Repository namens Petra zu ihrer Installation von Linux Mint hinzufügen, funktioniert der folgende Aufruf:

Ein PPA-Archiv namens gnome-desktop für Ubuntu fügen Sie wie folgt hinzu:

Um ein Repository wieder auszutragen, rufen Sie add-apt-repository mit dem zusätzlichen Schalter --remove auf. Nachfolgendes Beispiel zeigt das für den Eintrag für Medibuntu, aus dem der Zweig non-free wieder entfernt wird:

Zunächst wählen Sie ihre geographische Region aus, danach die Veröffentlichung (siehe [veroeffentlichungen]), die Architektur (siehe [debian-architekturen]) Ihres Systems und die Distributionsbereiche (siehe [distributionsbereiche]). In der rechten Spalte wählen Sie die gewünschten Repositories von Drittanbietern aus, sofern Sie dazu Bedarf haben (siehe [fig.debian-sources-list-generator]). Über den Knopf Generate sources list erstellt Ihnen das Programm eine passende Liste der Paketquellen (siehe [fig.debian-sources-list-generator-list]). Diese Datei können Sie nun als neue /etc/apt/sources.list in Ihr System übernehmen.

Die Abfolge ist ähnlich zu Debian, nur wesentlich umfangreicher. Nach der geographischen Region und der Veröffentlichung (siehe [veroeffentlichungen]) wählen Sie die Distributionsbereiche (siehe [distributionsbereiche]) aus, die hier als Ubuntu Branches bezeichnet werden. Hinter den Fragezeichen verbergen sich Erläuterungen, welche den ausgewählten Distributionsbereich näher beschreiben. Danach können Sie neben der Architektur (siehe [debian-architekturen]) auch etliche zusätzliche Paketquellen von Ubuntu-Partnern hinzufügen. Am Schluß erstellen Sie mit einem Klick auf den Knopf Generate die entsprechende Liste der ausgewählten Paketquellen, die Sie in ihr System übernehmen können.

Paketquellen und Repositories sind im Prinzip Fileserver mit einer vorab festgelegten, spezifischen Struktur, deren Inhalt öffentlich zugänglich ist [Debian-Wiki-Debian-Repository-Format]. Vereinfacht betrachtet muss bei dessen Abruf sichergestellt werden, dass die von dort bezogenen Daten echt sind und auch mit den Originaldaten übereinstimmen, aus denen die Distribution besteht. Daher sind in der Paketverwaltung mehrstufige Mechanismen integriert, welche die Echtheit und Vollständigkeit der empfangenen Paketlisten und Pakete überprüfen (Authentizität).

Hintergrund dafür ist einerseits, dass eine Paketquelle Paketarchive unterschiedlichster Herkunft umfasst. Die Daten könnten aus einer wenig vertrauenswürdigen Quelle stammen und auch Schadcode enthalten. Ebenso nimmt die Zuverlässigkeit von Speichermedien (Datenträger) mit der Zeit ab und sorgt für fehlerhafte Bitfolgen. Desweiteren erfolgt der Transport über Leitungsnetze unterschiedlichster Art, wobei hier gekippte Bits und somit Übertragungsfehler und verfälschte Daten auf dem Transportweg nicht vollständig auszuschließen sind.

Daher sind sowohl alle Veröffentlichungen (siehe [veroeffentlichungen]), als auch die Paketquellen (siehe [paketquellen]) mit den Paketlisten und die darüber bereitgestellten, einzelnen Pakete jeweils separat digital signiert. Eine digitale Signatur („Schlüssel“, GPG-Key) besteht aus zwei Teilen — einem öffentlichen und einem privaten, geheimen Schlüssel. Die Paketlisten werden zunächst vom Verwalter des Repositories mit seinem privaten Schlüssel signiert und der dazugehörige, öffentliche Schlüssel bekanntgegeben bzw. als Paket hinterlegt. Mit Hilfe dieses Signatur-Paares überprüfen Sie einerseits die Echtheit der Paketquelle und andererseits über die Hashsummen jeden einzelnen Pakets in den Paketlisten auch jedes einzelne Paket daraus (siehe auch „Bezogenes Paket verifizieren“ in [bezogenes-paket-verifizieren]).

APT und aptitude haben diesen Vorgang in ihre internen Abläufe integriert und nehmen Ihnen diesen Verifizierungsschritt vollständig ab. Falls die Signatur korrekt ist, dann wird der Paketmirror bzw. das bezogene Paket als glaubwürdig eingeschätzt. Falls nicht, erhalten Sie eine deutliche Warnung.

Die Verwaltung der Schlüssel erfolgt mit dem Programm apt-key. Dazu gehört ein Schlüsselring mit allen GPG-Schlüsseln der Paketquellen, aus denen Pakete bezogen wurden. Bei Debian sind diese Schlüssel Bestandteil des Pakets debian-archive-keyring [Debian-Paket-debian-archive-keyring], bei Ubuntu heißt das Paket hingegen ubuntu-keyring [Ubuntu-Paket-ubuntu-keyring].

Der primäre Schlüsselring für lokale, als vertrauenswürdig eingestufte Schlüssel ist die Datei /etc/apt/trusted.gpg. Für zusätzliche Schlüsselbunde und Dateifragmente weiterer vertrauenswürdiger Schlüssel ist das Verzeichnis /etc/apt/trusted.gpg.d/ vorgesehen. Insbesondere o.g. Schlüsselbund-Pakete speichern ihre Schlüsselbund-Dateien in diesem Verzeichnis.

Die einzelnen Dateien in /etc/apt/trusted.gpg.d/ gelten als Konfigurationsdateien, können also vom lokalen Administrator verändert oder gelöscht werden. Deswegen sind diese Schlüssel zusätzlich auch noch in der Datei /usr/share/keyrings/debian-archive-keyring.gpg gespeichert.

Die Schlüssel haben eine begrenzte Gültigkeit oder können auch zurückgezogen werden. Daher sind in der Schlüsselbund-Datei /usr/share/keyrings/debian-archive-removed-keys.gpg auch noch die abgelaufenen oder zurückgezogenen Schlüssel vergangener Debian-Veröffentlichungen verfügbar.

Ähnliche Schlüsselringe gibt es auch für andere Veröffentlichungen, bspw. debian-edu-archive-keyring für Skolelinux/DebianEdu [Skolelinux] und debian-ports-archive-keyring für das Debian-Ports-Projekt (siehe [debian-architekturen-ports-projekt]).

Mit apt-key greifen Sie auf ihren gespeicherten Schlüsselring zu. Damit lassen Sie sich bspw. die gemerkten Schlüssel anzeigen, fügen neue Schlüssel zum Schlüsselring hinzu oder entfernen diese daraus wieder. Diese Vorgänge kommen meist dann zum tragen, wenn Sie Ihr Debian-System von Ballast befreien und nicht mehr benötigte Schlüssel austragen oder weitere Paketquellen einbinden möchten, deren Schlüssel (noch) nicht offiziell hinterlegt ist.

Die vier Unterkommandos list, finger, export und exportall haben rein informativen Charakter. Mit den ersten beiden zeigen sie zu den gespeicherten, vertrauenswürdigen Schlüsseln deren Erstell- und Verfallsdatum sowie den Eigentümer bzw. Aussteller des Schlüssels an. Im vorliegenden Fall ist dieser keine Person, sondern eine Debian-Veröffentlichung bzw. deren Verantwortlicher. Als E-Mail-Adresse ist hier diejenige der FTP-Master hinterlegt (siehe [fig.apt-key-list]).

Mit dem Aufruf apt-key finger zeigen Sie zusätzlich deren Fingerabdruck an
[Da die Datei /etc/apt/trusted.gpg teilweise für normale User nicht lesbar ist, kann es sein, dass Sie dieses Kommando mit Root-Rechten ausführen müssen.]
. Nachfolgend sehen Sie beispielhaft die Signaturen zum Opera Software Archive, dem Mendeley Desktop Team und dem Debian Archive für die beiden Veröffentlichungen Wheezy und Jessie.

Mit dem Aufruf apt-key export Schlüssel geben Sie hingegen nur einen bestimmten Schlüssel auf der Standardausgabe als als PGP-Block aus. Der Schalter apt-key exportall führt das gleiche für alle Schlüssel durch.

Mit apt-key add Schlüsseldatei und apt-key del Schlüssel-ID verändern Sie den Inhalt des Schlüsselbundes. Mit ersterem fügen Sie einen neuen Schlüssel aus einer Datei hinzu, mit letzterem löschen Sie den Schlüssel mit der angegebenen Schlüssel-ID aus dem Schlüsselring.

Die Option update synchronisiert hingegen den lokalen Schlüsselbund mit dem Archivschlüsselbund. Dabei werden die Schlüssel aus dem lokalen Schlüsselbund entfernt, die nicht mehr gültig sind. In Ubuntu ist auch die Option net-update anwendbar, die eine Synchronisation mit einem Schlüsselbund über das Netzwerk ermöglicht.

Nutzen Sie beispielsweise den Webbrowser Opera, finden Sie dazu keine Pakete in den offiziellen Debian-Paketquellen. Opera ist nicht als freie Software eingeordnet, aber als deb-Paket von der Herstellerwebseite beziehbar. Daher fügen Sie in Schritt eins die Paketquelle zur Datei /etc/apt/sources.list hinzu (siehe auch [etc-apt-sources.list-verstehen]):

Als Schritt zwei benötigen Sie noch den dazugehörigen Schlüssel der Paketquelle. Der Hersteller empfiehlt auf seiner Seite den Bezug mittels wget wie folgt:

Der bezogene Schlüssel befindet sich nun im aktuellen Verzeichnis in der lokalen Datei archive.key. Diesen Schlüssel fügen Sie nun über den Aufruf apt-key add archive.key Ihrem lokalen Schlüsselbund hinzu:

Hat alles geklappt, meldet sich apt-key mit einem schlichten OK zurück. Von nun an werden alle Pakete von dieser Paketquelle als vertrauenswürdig eingestuft. Auch Aktualisierungen über APT und aptitude sind problemlos möglich.

Es bleibt jedoch ein unangenehmer Beigeschmack erhalten. Aufgrund der ungesicherten Übertragung des bezogenen Schlüssels können Sie nicht sicher sein, ob der bezogene Schlüssel wirklich von Opera ist und Sie ihm vertrauen können, oder ob nicht zufällig eine Man-in-the-Middle-Attacke im Gange ist.

Seit APT 2.1.8 ist apt-key offiziell abgekündigt. Ersatz ist das Ablegen von Keyring-Dateien im Verzeichnis /etc/apt/trusted.gpg.d/, z.B. als Bestandteil eines Paketes. Solche Pakete heißen typischerweise <herausgeber>-archive-keyring, z.B. debian-archive-keyring, ubuntu-archive-keyring oder pkg-mozilla-archive-keyring.

Die Abkündigung von apt-key ist auch einer der Gründe, warum sich niemand mehr darum gekümmert hat, gui-apt-key [Debian-Paket-gui-apt-key], das verwaiste GUI-Frontend zu apt-key, weiterzuentwickeln. Entsprechend ist auch die darauf aufbauende, curses-basierende TUI-Programm curses-apt-key [curses-apt-key] nicht mehr weiterentwickelt wird.

Bevor Sie Veränderungen am Paketbestand veranlassen, empfehlen wir Ihnen, stets die Liste der lokal genutzten Pakete auf den neuesten Stand zu bringen. Damit arbeiten Sie mit den aktuellen Referenzen auf die bestehenden Softwarepakete. Diesen Schritt ermöglichen alle Werkzeuge zur Paketverwaltung.

Dazu bestehen verschiedene Möglichkeiten, die im Endeffekt alle das gleiche bewirken:

Führen Sie eines der o.g. Aufrufe aus, wird zunächst die Liste der Paketquellen in der Datei /etc/apt/sources.list und dem Verzeichnis /etc/apt/sources.list.d (siehe [etc-apt-sources.list-verstehen]) gelesen. Jeder Eintrag darin bezeichnet eine Paketquelle. Von diesen Paketquellen wird nacheinander jeweils eine aktuelle Liste der Pakete bezogen, die von dieser angegebenen Paketquelle verfügbar sind.

Jede bezogene Liste wird danach auf deren Echtheit geprüft. Dazu ist diese digital signiert (siehe [paketquelle-auf-echtheit-ueberpruefen]). Mit Hilfe des GPG-Schlüssels für die Paketquelle prüfen apt', `apt-get bzw. aptitude automatisch deren Authentizität und falls ohne Beanstandung, vereinigen sie die bezogene Liste mit der bereits bestehenden, lokalen Paketliste (siehe [lokale-paketliste-und-paketcache]). Dabei geben insbesondere apt-get und aptitude eine Reihe von Mitteilungen auf dem Terminal aus. Diese bedeuten:

Am Ende der Ausgabe erfolgt noch eine Zusammenfassung, welche Datenmenge in welcher Zeitspanne bezogen wurde. Nachfolgend sehen Sie die Ausgabe am Beispiel von apt-get update:

Neuere Versionen ergänzen die Ausgabe um zusätzliche Zeilen und teilen Ihnen darüber mit, ob und wieviele aktualisierbare Pakete vorliegen. Nachfolgend sehen Sie in [fig.apt-update-aktualisierbare-pakete], dass für zwölf Pakete neue Varianten bereitstehen. Um welche Pakete es sich konkret handelt, listen Sie mit Hilfe des Kommandos apt list --upgradable auf (siehe [aktualisierbare-pakete-anzeigen]).

Für diese Mitteilungen greifen apt-get und apt auf das Werkzeug daptup aus dem gleichnamigen Paket zurück [Debian-Paket-daptup]. Es ist als eine direkte Abhängigkeit zu beiden definiert und wird daher automatisch installiert.

Konnten bei der Aktualisierung für neue Paketlisten keine gültigen Signaturen gefunden werden, wird eine Warnung ausgegeben. Entsprechende Zeilen beginnen mit W:. Bei einer Paketquelle ohne Schlüssel beschwert sich APT wie folgt:

Pakete, die nicht korrekt signiert sind, können Schadcode enthalten und sollten nicht installiert werden. aptitude warnt Sie in diesem Fall sehr deutlich:

Zur Überprüfung auf korrekte Pakete tragen Sie bitte den passenden GPG-Key für die Paketliste der Veröffentlichung nach.

Bitte planen Sie freien Platz für den Paketcache ein. Die aktualisierten Paketlisten und Pakete benötigen Speicherplatz, bevor diese ausgepackt und eingerichtet werden können.

Möchten Sie neuere Versionen von Paketen installieren oder auf eine andere Veröffentlichung von Debian wechseln, ist zusätzlich ein upgrade bzw. dist-upgrade erforderlich. Weitere Informationen dazu erhalten Sie unter „Pakete aktualisieren“ in [pakete-aktualisieren] bzw. „Distribution aktualisieren“ in [distribution-aktualisieren].

Sollten die Fehler trotz Ihrer intensiven Bemühungen bestehen bleiben, bleibt noch eine Überprüfung, ob der angefragte Spiegelserver auch aktuell ist. Eine Zustandsübersicht über alle offiziellen Spiegelserver, die bei Debian registriert sind, finden Sie auf der Debian Mirror Status-Seite [Debian-Mirror-Status] (siehe [fig.debian-mirror-checker]).

Wann die letzte Aktualisierung des von Ihnen gewählten Debian-Mirrors passiert ist, sehen Sie im Unterverzeichnis project/trace/, z.B. unter http://debian.ethz.ch/debian/project/trace/ für den Paketmirror der ETH Zürich. In dieser Liste suchen Sie nach dem Datumsstempel der Datei, die dem Hostnamen Ihres Spiegelservers entspricht. Wenn der Spiegelserver unter mehreren Namen erreichbar ist, finden Sie dort trotzdem nur einen davon. Es sollte immer die neuste Datei sein.

Wenn die gefundene Datei deutlich älter als sechs Stunden ist, prüfen Sie bitte zuerst, wann die letzte Aktualisierung des Mirror-Netzwerkes stattgefunden hat
[Bei Ausfällen oder Umbauten in der Infrastruktur wie auch kurz vor neuen Veröffentlichungen kann es durchaus vorkommen, dass der Abstand zwischen zwei Aktualisierungen des Mirrors deutlich mehr als sechs Stunden dauert, teilweise auch einen oder wenige Tage.]
. Unter [dinstall-status] finden Sie eine Datei, in der festgehalten wird, in welchem Schritt der Aktualisierung und Zustand sich der Master-Mirror gerade befindet. Ein Eintrag „all done“ bedeutet, dass zur Zeit keine Aktualisierung läuft. Das Endedatum zeigt den Zeitpunkt an, an dem die erste Stufe des Mirror-Netzwerkes mit den neuen Paketlisten und Paketen versorgt wurde.

Ob zur Zeit eine Aktualisierung Ihres gewählten Mirrors läuft, sehen sie an der Existenz einer Datei Archive-Update-in-Progress (ggf. erweitert um den bzw. einen Hostnamen des Spiegelservers) im Wurzelverzeichnis des APT-Repositorys, z.B. http://debian.ethz.ch/debian/Archive-Update-in-Progress-debian.ethz.ch.

Die folgenden Schlüsselworte werden in Binärpaketen (siehe [binaerpakete]) und den Paketlisten von diesen verwendet:

Das nachfolgende Beispiel zeigt alle genutzten Elemente anhand der PDF-Bibliothek poppler-utils:

In Sourcepaketen (siehe [sourcepakete]) sind neben den weiter oben genannten Schlüsselworten auch die folgenden Einträge zulässig:

In den Paketlisten unter /var/lib/apt/lists/ sind außerdem noch weitere generierte Metadaten zu den Paketen enthalten. Das beinhaltet bspw. die Debian Tags (siehe [erweiterte-paketklassifikation-mit-debtags]), den Pfad und Dateinamen im Paketmirror, die Paketgröße und verschiedene Prüfsummen. Letztere dienen dazu, sicherzustellen, dass die Pakete fehlerfrei zwischen dem Paketmirror und ihrem Debian-System übertragen wurden und es zwischenzeitlich keine Veränderungen gab (siehe dazu Paketquelle überprüfen in [paketquelle-auf-echtheit-ueberpruefen] und Bezogenes Paket verifizieren in [bezogenes-paket-verifizieren]).

Das Paket poppler-utils umfasst beispielsweise die folgenden Metadaten:

Debianpakete beinhalten stets zwei Komponenten – Daten und Metainformationen. Die Daten sind die tatsächlichen Inhalte des Pakets, d.h. entweder der Quellcode oder die übersetzten Programmdateien, die bei der Installation auf Ihr System kopiert werden.

Die Metainformationen sind zusätzliche Informationen zu einem Paket, die dieses näher beschreiben. Dazu zählen erstens die Relationen zu anderen Paketen. Diese legen die Voraussetzungen fest, nach denen das Paket überhaupt übersetzt („gebaut“) und später auf Ihrem Linux-System installiert werden kann. Insbesondere zählen dazu die Abhängigkeiten und Konflikte zu anderen Paketen. Diese Relationen beschreiben wir ausführlich unter „Konzepte und Ideen dahinter“ in [konzepte-und-ideen-dahinter].

Zweitens gehören die sogenannten Maintainer-Skripte namens preinst, postinst, prerm und postrm dazu. Die beiden Skripte preinst und postinst regeln alle Aktivitäten vor und nach der Installation, prerm und postrm hingegen vor und nach der Entfernung des Pakets von Ihrem System. Diese vier Skripte sind üblicherweise distributionsspezifische Shellskripte, die der Maintainer des jeweiligen Pakets pflegt.

Für das Paket dpkg-www [Debian-Paket-dpkg-www] beinhaltet das bspw. das Starten des Webservers nach der Installation des Pakets, das Anhalten (vorher) und Neustarten (nachher) im Zuge einer Aktualisierung des Pakets und das Anhalten des Dienstes, bevor das Paket vom System wieder entfernt wird. In [fig.postinst] sehen Sie einen Ausschnitt aus dem postinst-Skript zu besagtem Paket.

Ein Source-Paket beinhaltet einerseits den Quellcode der Software und andererseits die Anweisungen, nach denen aus dem Quellcode der Software eines oder mehrere Binärpakete entstehen [Krafft-Debian-System]. Dazu besteht es aus mindestens 2, meistens jedoch 3 und ggf. auch noch weiteren Dateien:

Als Paketformate existieren die Versionen 1.0, 2.0 (wurde offiziell nie unterstützt) und 3.0 [Debian-DebSrc3.0]. Letzteres existiert in den zwei Varianten quilt (benannt als „3.0 (quilt)“) und native (benannt als „3.0 (native)“) und hat sich seit dessen Einführung mit Debian 6 Squeeze im Jahr 2011 mittlerweile etabliert. Dabei umfassen die Namen der Varianten für Version 3.0 jeweils auch die Leerzeichen und die beiden Klammern.

Wie bereits in „Übergangs- und Metapakete“ (siehe [uebergangs-und-metapakete]) deutlich wurde, handelt es sich hierbei um Binärpakete, die eine spezielle Charakteristik haben: sie haben meist außer der Dokumentation keine weiteren Inhalte. Der eigentliche Inhalt sowie Sinn und Zweck liegen in der Beschreibung der Abhängigkeiten der Pakete.

Übergangspakete werden auch Dummypakete oder Transitionspakete genannt. Deren Aufgabe ist es, Paketumbenennungen bei der Aktualisierung auf eine neue Veröffentlichung sauber zu handhaben und in diesem Zusammenhang auftretende Abhängigkeitskonflikte zu verhindern. Metapakete erleichtern dagegen nur die Installation einer Gruppe von zusammenhängenden Paketen.

Ein Paket dieser Art beinhaltet meist nur zwei Dateien unterhalb von /usr/share/doc — die Informationen zum Copyright und die bisherigen Änderungen. Letzteres liegt in der Datei changelog.Debian.gz. Beide Dateien können aus Gründen der Platzersparnis durch einen symbolischen Link auf eine der Abhängigkeiten ersetzt werden, falls diese aus dem gleichen Sourcepaket gebaut wurden.

Darüberhinaus können die Pakete einen Wrapper oder einen symbolischen Link zur Wahrung der Rückwärtskompatibilität beinhalten. Beispielsweise umfasst das Paket ash nur eine Abhängigkeit auf das Paket dash und einen symbolischen Verweis (Symlink) von /bin/ash zu /bin/dash:

Basierend auf der Einordnung in die unterschiedlichen Softwarestapel und Ebenen (siehe [softwarestapel-und-ebenen]) lässt sich der Aufgabenbereich und damit der Funktionsumfang eines Programms zur Paketverwaltung konkreter fassen. Dabei kommen häufig die UNIX-Prinzipien „Ein Werkzeug für eine Aufgabe“ und „Keep it simple, stupid“ (sinngemäß: Mach’s so einfach wie möglich) sehr stark zum tragen.

Zur unteren Ebene gehört das Programm dpkg. Es bietet grundsätzliche Funktionen, die ein erforderliches Minimum abdecken. Die Funktionen betreffen nur das lokale System und setzen voraus, dass alle notwendigen Informationen und deb-Pakete bereits vorliegen. Dazu gehören die Fähigkeiten, Informationen über installierte und noch zur Verfügung stehende Pakete und Paketdateien anzuzeigen sowie bereits lokal als Datei vorliegende Pakete zu installieren, zu konfigurieren und wieder vom System zu entfernen. dpkg fokussiert dabei eher auf Einzelpakete, bspw. der Aufruf dpkg -i Paketname zur Installation eines Pakets (siehe auch [pakete-installieren]).

Die obere Ebene beinhaltet im weitesten Sinne alle übergeordneten Aufgaben, wie bspw. komplexere Verwaltungsfunktionen. Dazu zählt das Herunterladen der Paketlisten von den vorher von Ihnen festgelegten Paketmirrors, das Aktualisieren der lokalen Paketlisten, das Auswählen und Beziehen eines Pakets von einem passenden Paketmirror, das Auflösen der Paketabhängigkeiten und das Klären weiterer, dazu benötigter oder empfohlener Pakete, die zum ausgewählten Paket passen und welche für Sie als Benutzer interessant sein könnten. Ebenso gehört die Validierung eines Pakets anhand seines GPG-Schlüssels (siehe [bezogenes-paket-verifizieren]) dazu. Zur oberen Ebene zählen bspw. Programme wie tasksel, APT, aptitude, SmartPM, das Ubuntu Software Center und die PackageKit-Varianten apper (KDE) und gnome-packagekit (GNOME).

Eine Mischform stellen hingegen die Programme cupt, wajig und gdebi dar. Deren Anspruch ist es, beide Ebenen in einem einzigen Programm abzudecken und alle erforderlichen Funktionen zur Paketverwaltung bereitzustellen. Die genannten Programme kommen diesem Ziel derzeit in unterschiedlicher Qualität nahe. Dabei erfolgt ein Zugriff auf die bestehenden Bibliotheken, der durch eigene, zusätzliche Funktionalitäten ergänzt wird.

Es gibt keine Regelung oder Empfehlung dafür, welches Programm aus obiger Liste Sie benutzen sollen. Dafür sind die Wissensstände, Gewohnheiten und Vorlieben im Umgang mit Software zu unterschiedlich (siehe auch „Ausblick und Empfehlungen für Einsteiger“ in [ausblick-empfehlungen-fuer-einsteiger]).

In der Praxis zeigt sich, dass apt-get häufig die schnellste und effizienteste Variante ist, sofern Sie den exakten Namen eines Debian-Pakets (siehe dazu [benennung-eines-debian-pakets]) oder zumindest einen Großteil davon wissen. Die Kommandozeilenwerkzeuge sind sehr flexibel und verfügen über eine hohe Anzahl von Funktionen. Diese sprechen Sie über vielfältige Unterkommandos, Schalter und Parameter an.

Viele Schalter und Parameter der Kommandozeilenwerkzeuge werden in den TUI, GUI und WUI nicht oder nur unzureichend abgebildet, sind zudem in den meisten Fällen geschickt versteckt, anders benannt oder auch mitunter sinnentstellend übersetzt. Das sorgt vielfach für Unmut und Verzweiflung bei der Suche nach einer bestimmten Funktionalität. Erfahrenere Benutzer vermissen häufig die Flexibilität der vielen Optionen und greifen daher bevorzugt zur Kommandozeile oder zum TUI, da das schneller und einfacher geht. Das hoffnungs- und erwartungsvolle Herumklicken in einer graphischen Anwendung möchten sie den Marketingfritzen und Mausschubsern überlassen.

Die Komplexität der Kommandozeilenwerkzeuge kann Einsteiger überfordern — gleiches gilt aber auch für graphische Oberflächen. In jedem Fall setzt es bei Ihnen den Willen zur Einarbeitung voraus — gleich welches Werkzeug es auch ist. Der Vorteil der Kommandozeilenwerkzeuge liegt darin, dass sie meist zur Basisinstallation Ihres Debian-Systems gehören und somit auch auf ferngewarteten Serversystemen zur Verfügung stehen. Graphische Werkzeuge sind in der Regel nur auf Desktopsystemen installiert. Webbasierte Benutzerschnittstellen sind deutlich in der Minderheit und haben den Exotenstatus. Steigt der Verbreitungsgrad UNIX/Linux-basierter Smartphones und TabletPCs mit Android bzw. Ubuntu weiter an, ist mit einer Zunahme von Programmen wie Appnr (siehe [webbasierte-programme-appnr]) im Alltag zu rechnen.

dpkg ist das Debian-Programm für grundlegende Paketoperationen und bildet in Bezug auf Funktionsumfang und Handhabung das Äquivalent zu rpm auf RedHat-basierten Linuxsystemen. Es kürzt den Namen Debian GNU/Linux package manager ab. Im Anhang unter ``Kommandos zur Paketverwaltung im Vergleich`` (siehe [kommandos-zur-paketverwaltung-im-vergleich]) stellen wir die verschiedenen Schalter zu den beiden Kommandos dpkg und rpm gegenüber.

dpkg agiert nur mit Paketen, die schon auf ihrem Linuxsystem lokal vorliegen — entweder als deb-Datei in einem Verzeichnis oder als bereits installiertes Paket. dpkg kann keine Pakete von einem Paketmirror beziehen.

Sie erreichen dpkg ausschließlich über die Kommandozeile und starten es mit diversen Schaltern und Optionen. Die wichtigsten Parameter für den Gebrauch im Alltag sind
[Weitere Optionen zu dpkg entnehmen Sie bitte der Manpage zum Programm]
:

Mit dpkg zeigen Sie die installierten Pakete und deren Zustand an, suchen nach Paketinhalten und konfigurieren im Bedarfsfall ein Paket nach.

Für alle anderen Aktionen sind hingegen die Werkzeuge apt-get ([apt]), apt-cache, aptitude ([aptitude]) und apt-file oder die Benutzeroberflächen via Ncurses oder GTK besser geeignet (siehe [ncurses-basiert] und [gui-zur-paketverwaltung]). Diese fassen viele Einzelschritte von dpkg zusammen und vereinfachen Ihnen die Wartung ihres Systems erheblich.

Das in der Programmiersprache Python geschriebene Programm wajig [Debian-Paket-wajig] ist vorrangig ein Wrapper um dpkg ([dpkg]) und APT ([apt]). Es zählt zur gleichen Kategorie wie die nicht mehr verfügbare aptsh, beinhaltet aber auch Elemente von cupt ([Cupt]) und aptitude ([aptitude]) auf der Kommandozeile
[Bis einschließlich Debian 6 Squeeze bestand zudem eine graphische Variante namens gjig, die mittlerweile obsolet und in keiner unterstützten Debian- oder Ubuntu-Veröffentlichung mehr verfügbar ist.]
.

wajig zielt darauf ab, alle im Alltag erforderlichen Aktionen zur Paketverwaltung in einem einzigen Werkzeug für die Kommandozeile zusammenzufassen. Daher haben sich die wajig-Entwickler das Ziel gesetzt, die APT-Bibliotheken (siehe [apt-und-bibliotheken]) vollständig auszureizen und nach Möglichkeit auch alle Optionen, die dpkg und APT bieten, im Programm zu integrieren. Gleichzeitig stehen auch Funktionen bereit, die von den separaten Werkzeugen wie bspw. apt-cdrom ([physische-installationsmedien-mit-apt-cdrom-einbinden]) oder alien (siehe [fremdformate-mit-alien-hinzufuegen]) entlehnt wurden.

Sie bedienen wajig ausschließlich über die Tastatur. Möglich sind zwei Modi — mit dem gewünschten Unterkommando beim Aufruf, oder ohne. Bei ersterem erfolgt die Ausgabe direkt im Terminal, bei letzterem öffnet sich dann zunächst die wajig-Shell und wartet auf Ihre Eingabe. In dieser können Sie dann alle Unterkommandos zur Paketverwaltung benutzen. Dazu zählen bspw. install zur Paketinstallation, detail zur Darstellung der Paketinformationen, listfiles zu Auflistung des Paketinhalts und remove zum Entfernen eines Pakets. Mittels find-file erstöbern Sie eine gewünschte Datei in den bereits installierten Paketen, wohingegen Ihnen list-orphans die Paketwaisen (siehe [umgang-mit-waisen]) anzeigt.

Als Besonderheit ist einerseits die Anbindung an apt-get.org [apt-get.org] zu nennen, um darüber den Paketmirror nach Bedarf auszuwählen. Ebenso ist die Umwandlung und Installation von .rpm-Paketen mittels rpm2deb und rpminstall sowie die ausführliche, integrierte Hilfe hervorzuheben.

Weitere Informationen zum Programm finden Sie auf der Webseite des Projekts [wajig-Webseite]. Um die Feinheiten der Kommandos zwischen dpkg, APT und wajig besser vergleichen zu können, hilft ein Blick in das Wiki von xtronics [xtronics-Wiki].

sysget ist ein Wrapper, welches den Aufruf zu den verschiedenen, tatsächlichen Paketwerkzeugen übernimmt. Ziel ist dabei, eine einheitliche Schnittstelle zu den Programmen wie APT, yum oder DNF herzustellen und damit auch Einsteigern die ersten Schritte nach einem Wechsel der Distribution zu erleichtern. sysget wird als Projekt auf GitHub gepflegt [sysgetGitHub].

Das Werkzeug orientiert sich an APT und versteht derzeit die folgenden Unterkommandos:

Cupt beschreibt sich selbst als High-level Package Manager und integriert Kommandos unter einem Dach, die Sie von den Werkzeugen dpkg und APT her kennen. Dafür nutzt es auf der Serverseite die gleiche Infrastruktur wie APT. Die Clientseite wurde hingegen komplett neu entwickelt. Sie rufen das in der Programmiersprache C++ entwickelte Werkzeug über das gleichnamige Kommando cupt auf.

Wie bereits oben angerissen, vereinigt Cupt zwar Kommandos aus dpkg und APT, jedoch bislang noch nicht alle davon. Offen ist bspw. der Support für multiarch ([debian-architekturen-multiarch]). Gleichzeitig bietet es auch weitere Features, die APT noch fehlen (siehe [Debian-Wiki-cupt]), bspw. Debdelta [Debdelta] und die Synchronisation anhand der Version des Sourcepakets. Ebenso kennt es ein Kommando satisfy, um auf der Kommandozeile angegebene Paketbedingungen zu erfüllen, z.B. cupt satisfy ``kmail (>= 4:4.2), wget (>= 1.10.0)''.

Cupt kann problemlos parallel zu APT verwendet werden, ist jedoch gemäß seinem Autor noch nicht sehr weit verbreitet und auch entsprechend wenig durch Benutzer in der Praxis getestet [Cupt-Tutorial]. Wir gehen im Buch nicht weiter darauf ein.

tasksel gehört zu den Anwendungen, die Sie vielleicht nur aus der textbasierten Installation von Debian her kennen. Nach der Zusammenstellung des Debian-Basissystems wird dieses Werkzeug üblicherweise einmal automatisch im Installationsprozess aufgerufen und gerät danach vollständig in Vergessenheit. Stattdessen helfen Ihnen APT und aptitude bei den Routineaufgaben.

Der Name ist eine Abkürzung und steht für task select, auf Deutsch übersetzbar mit „Aufgabe auswählen“. Das Paket tasksel [Debian-Paket-tasksel] beinhaltet lediglich die Benutzeroberfläche, das Paket tasksel-data [Debian-Paket-tasksel-data] hingegen eine Liste mit vorab festgelegten Standardaufgaben. Jeder genannten Aufgabe sind eine Reihe von Paketen zugeordnet.

Die beiden tasksel-Generationen 2.x und 3.x unterscheiden sich massiv voneinander. Während Generation 2 noch von aptitude abhängt, setzt Generation 3 hingegen verstärkt auf die Nutzung von Metapaketen (siehe [uebergangs-und-metapakete]). Das zeigt sich sehr deutlich in den Ausgaben im Terminal, auf die wir unten genauer eingehen.

Über die textbasierte Benutzeroberfläche und der dargestellten Liste wählen Sie zunächst mittels Pfeil- und Leertaste die gewünschten Aufgaben aus. Daraufhin werden alle Pakete „in einem Rutsch“ auf Ihrem Linuxsystem installiert, die diesen Aufgaben zugeordnet sind. Daß das durchaus etwas mehr Zeit in Anspruch nehmen kann, zeigt [fig.tasksel-download].

Bei Debian und Ubuntu existieren viele Aufgaben als separate, vorgefertigte Pakete, die Ihnen die Einrichtung gemäß eines spezifischen Zwecks erleichtern, indem benötigte Pakete gruppiert werden. Diese Pakete tragen die Bezeichnung task- am Anfang des Paketnamens (siehe [debian-pakete-varianten]). Dazu zählen bspw. die Aufgaben Mailserver, Webserver, Desktopumgebung und Laptop (siehe [fig.tasksel]).

Die textbasierte Benutzeroberfläche von tasksel ist jedoch nur eine Seite der Medaille. Das Programm ist ebenso für eine Steuerung über die Kommandozeile empfänglich. Die nachfolgende Liste zeigt die möglichen Schalter:

Über den Schalter --list-tasks stellt Ihnen tasksel alle vorab definierten Aufgaben zusammen (Debian). Am Buchstaben in der ersten Spalte der Ausgabe erkennen Sie, ob diese Aufgabe vollständig auf ihrem Linuxsystem umgesetzt wurde. Daneben sehen Sie das vergebene Kürzel und eine Kurzbeschreibung zur jeweiligen Aufgabe.

Für jede Aufgabe ist eine Beschreibung der Aufgabe hinterlegt. Diese zeigen Sie mit dem Schalter --task-desc an
[Unter Debian 7 Wheezy ist die Ausgabe derzeit defekt und als Bug #756841 hinterlegt, siehe https://bugs.debian.org/756841]
. Auf einem Ubuntu mit tasksel in der Version 2.88 sehen Sie diese Ausgabe:

tasksel zeigt Ihnen mit Hilfe des Schalters --task-packages auch die Pakete an, die zu der entsprechenden Aufgabe gehören. Bei Debian und der Aufgabe ssh-server sieht das wie folgt aus — es verweist auf ein entsprechendes Debianpaket:

Der gleiche Aufruf auf einem Ubuntu — hier für das Paket openssh-server — ergibt diese Liste (Auszug) mit allen benötigten Einzelpaketen:

Im Vergleich mit den anderen vorgestellten Programmen zur Paketverwaltung ist aptitude eine recht komplexe und umfangreiche Anwendung. Es ermöglicht Ihnen zwei unterschiedliche Wege der Bedienung — einerseits über die Kommandozeile mit Unterkommandos und Schaltern, andererseits über eine Ncurses-basierte, interaktive, farbige Bedienoberfläche im Terminal. Wieder aufgegeben wurden zwischenzeitlich die Versuche, aptitude auch mit einer graphischen Bedienoberfläche auszustatten (siehe [Beckert-Blog-Aptitude-Gtk-Will-Vanish]).

Das Programm ist verteilt auf die beiden Pakete namens aptitude und aptitude-common. Da das Programm nicht zur Standardauswahl bei der Installation von Debian GNU/Linux und Ubuntu gehört, richten Sie es am besten über den Aufruf apt-get install aptitude auf ihrem Linuxsystem ein. Das Paket aptitude-common wird über Paketabhängigkeiten automatisch mitinstalliert.

Ähnlich wie APT arbeitet aptitude mit Paketen, die sich entweder bereits lokal auf ihrem System befinden, oder noch auf einem Paketmirror vorliegen und vor der Installation noch von dort bezogen werden. Desweiteren bietet Ihnen das Programm die folgenden Funktionen (Auswahl, jeweils Angabe der Unterkommandos auf der Kommandozeile):

Wie bereits oben angerissen, können Sie aptitude über die Kommandozeile benutzen. Die Unterkommandos und Schalter sind bzgl. der Schreibweise und Bedeutung ähnlich derer von APT (siehe [apt]).

Um hingegen über die Ncurses-basierte Bedienoberfläche zu agieren, starten Sie zunächst aptitude ohne weitere Optionen. Die mehrfarbige Bedienoberfläche enthält mehrere Elemente. Ganz oben finden Sie die verfügbaren, aktiven Tasten und deren Funktion. Über die Funktionstaste F10 oder alternativ mit Hilfe der Tastenkombination Ctrl+T aktivieren Sie bspw. die Menüleiste. Einige Terminals wie bspw. das Gnome-Terminal fangen die Funktionstaste ab und belegen diese für die eigene Menüleiste. Über den Eintrag Bearbeiten ▸ Tastenkombinationen ▸ Menütastenkombinationen aktivieren (de)aktivieren Sie das Verhalten. Mit Hilfe der Pfeiltasten navigieren Sie zwischen den einzelnen Menüeinträgen hin und her bzw. wählen die gewünschte Aktion aus.

Die beiden Fensterhälften darunter geben Ihnen eine Übersicht zu den Softwarepaketen. In der oberen Hälfte stellt aptitude in einer aufklappbaren Baumstruktur die Paketkategorien ([sortierung-der-pakete-nach-verwendungszweck]), den Distributionsbereich ([distributionsbereiche]) und den Paketnamen mit Versionsnummer dar. Sichtbar wird dabei die Version des installierten Pakets sowie der möglichen Aktualisierung ([benennung-versionsnummer]). Die Auswahl in der Baumstruktur erfolgt analog zu vi(m) mittels j und k (oder über die Pfeiltasten) und Enter. Die einzelnen Strukturebenen klappen Sie mit den Tasten Enter, [ und ] auf und zu.

Dabei hinterlegt aptitude die einzelnen Pakete mit verschiedenen Farben, deren Bedeutung Sie [tab.aptitude-farben] entnehmen. Das Farbschema können Sie auch nach Gutdünken anpassen, genauer gehen wir darauf in [aptitude-farbschema-anpassen] ein.

Im unteren Fenster erhalten Sie eine Beschreibung — entweder zur ausgewählten Paketkategorie oder zum jeweiligen Paket. Zwischen den beiden Fensterhälften wechseln Sie mittels der Tab-Taste hin und her. Die Belegung weiterer Tasten entnehmen Sie bitte [tab.aptitude-tasten].

Auch wenn sich APT und aptitude größtenteils sehr ähnlich sind, bestehen eine Reihe von feinen Unterschieden, die erst während der Benutzung der Programme präsent werden. aptitude hat nützliche Erweiterungen, wie z.B. einen interaktiven Abhängigkeitsauflöser (siehe [fig.aptitude-dependency-solver]). Verändern Sie den geplanten Paketbestand, indem Sie beispielsweise ein zusätzliches Paket markieren und somit zur Installation vormerken, werden automatisch die notwendigen Abhängigkeiten aufgelöst und ebenfalls vorgemerkt. Sie sehen somit unmittelbar, welche Pakete im nächsten Schritt noch hinzukommen oder wieder entfernt werden müssen.

Sollte es dabei zu Paketkonflikten kommen, so werden Ihnen vorab verschiedene Lösungsvarianten und deren Auswirkungen auf den Paketbestand zur Auswahl gestellt. Im Gegensatz dazu präsentiert Ihnen APT nur stets einen einzigen Vorschlag zur Aktualisierung.

Aus diesen angebotenen Varianten wählen Sie die Ihnen am besten passende aus. In den letzten beiden Zeilen des Terminals listet aptitude auf, wieviele Varianten es ermittelt hat, mit welchen Tasten Sie zwischen diesen Varianten wechseln (siehe auch [tab.aptitude-konflikte-loesen]) und wie Sie die gewünschte Variante letztendlich auswählen.

Darüber hinaus verfügt aptitude über eine Ansicht, in der Sie Pakete nach Debian-Tags (Debtags) (siehe dazu [erweiterte-paketklassifikation-mit-debtags]) sortiert betrachten können. Damit stöbern Sie sehr effizient im Paketbestand. Das ist insbesondere dann interessant, wenn Sie lediglich wissen, nach welcher Funktionalität oder Art von Paket Sie suchen, jedoch den konkreten Paketnamen nicht kennen.

Der ebenfalls im Menü in [fig.aptitude-debtags-browser] (noch) angezeigte Kategoriebrowser gilt als veraltet
[Es handelt sich dabei um eine hart in aptitude verdrahtete und schon sehr lange nicht mehr gepflegte Kategorisierung der Pakete]
, funktioniert seit einigen Versionen nicht mehr und wird voraussichtlich demnächst ganz entfernt [aptitude-categorical-browser-to-be-removed]. Der oben angerissene Debtags-Browser ist der offizielle, wesentlich aktuellere und besser gepflegte Ersatz dafür.

Im Erweiterungsteil gehen wir darauf ein, was passiert, wenn Sie APT und aptitude miteinander mischen ([apt-und-aptitude-mischen]). Auch der Konfiguration des Programms ist ein eigener Abschnitt gewidmet (siehe „APT und aptitude auf die eigenen Bedürfnisse anpassen“ in [apt-und-aptitude-auf-die-eigenen-beduerfnisse-anpassen]).

Das Werkzeug Nala [Debian-Paket-nala] ist bislang noch recht unbekannt und versteht sich als Frontend für APT. Ziel ist, eine übersichtlichere Darstellung vom aktuellen Paketbestand sowie bei dessen Änderungen zu erhalten, indem graphische Elemente in die Ausgabe einfließen. [fig.nala] zeigt den Dialog auf der Kommandozeile zur Entfernung des Paketes xsnow.

Das gesamte Verhalten und die Bedienung von Nala lehnt sich an DNF an - DNF für APT wäre somit eine gute Zusammenfassung. An Schaltern versteht es die Unterkommandos von APT, bspw. install zur Installation von Softwarepaketen, remove zum Löschen sowie purge und remove --purge zum vollständigen Löschen eines Softwarepakets. Mit dem Unterkommando history stöbern Sie in der Historie von Nala, sprich: Sie sehen daraus, welche Paketaktionen bereits vorher durchgeführt wurden.

Nala benutzt dabei nicht die APT-Bibliotheken, sondern stattdessen die Python-apt-API zur Verwaltung der Pakete. Seit dem Frühsommer 2023 mit der Veröffentlichung von Debian 12 bookworm ist Nala in der stabilen Veröffentlichung von Debian GNU/Linux enthalten.

Das Programm steht im gleichnamigen Paket synaptic [Debian-Paket-synaptic] bereit. Es verfügt über eine graphische Bedienoberfläche auf der Basis des Gimp Toolkits (GTK2) und war lange Zeit das empfohlene Programm zur Paketverwaltung für die Benutzer des Ubuntu-Desktops. Zwischenzeitlich sind bei Ubuntu diverse, mehr an Apples App-Store denn an Aptitude erinnernde GUI-Frontends gekommen und wieder gegangen. Aber zumindest scheint sich Ubuntu auf PackageKit als Middleware zwischen GUI und dem eigentlichen Pakete installieren, aktualisieren und entfernen eingeschossen zu haben.

Synaptic bedienen Sie über die Menüleiste, eine Reihe von Knöpfen darunter und eine dreispaltige Paketübersicht. Die Darstellung konfigurieren Sie über die Menüpunkte Einstellungen ▸ Einstellungen und Einstellungen ▸ Werkzeugleiste. [fig.synaptic-setup-farben] zeigt als Beispiel das Dialogfenster, über welches Sie die Farben zum jeweiligen Installationsstatus eines Pakets festlegen.

Über den Knopf Eigenschaften erfahren Sie mehr über das gerade von Ihnen ausgewählte Paket. Dazu zählen Allgemeine Informationen, die Paketabhängigkeiten, die installierten Dateien, die verfügbaren Paketversionen sowie eine ausführliche Paketbeschreibung. [fig.synaptic-paketinfo] zeigt die Informationen zum Paket ding.

Unter der Menüleiste und den Knöpfen finden Sie die dreispaltige Paketübersicht. Links finden Sie verschiedene Auswahlknöpfe, oben rechts die Paketliste und unten rechts die Paketbeschreibung im Detail. [fig.synaptic] zeigt Ihnen die Gesamtansicht anhand des Pakets a2ps.

Die linke Spalte zeigt zunächst die Architektur ([debian-architekturen]). Über die einzelnen Knöpfe darunter schalten Sie zur Ansicht nach den Paketkategorien (Sektionen) ([sortierung-der-pakete-nach-verwendungszweck]) sowie dem Ursprung bzw. der Herkunft der Pakete ([paketquellen]), der Veröffentlichung ([veroeffentlichungen]) und dem Distributionsbereich ([distributionsbereiche]) um.

In der Paketliste oben rechts beinhalten die Spalten den Installationsstatus (Status), eine Information zur Herkunft des Pakets, den Paketnamen, die installierte und die verfügbare Version und eine kurze Paketbeschreibung. Zusätzlich können Sie als Spalten den Distributionsbereich, die Veröffentlichung und die Größe des Pakets nach der Installation ergänzen. Mit einem Mausklick auf den jeweiligen Spaltenkopf sortieren Sie die Paketliste nach der jeweiligen Eigenschaft.

Die rechte untere Spalte zeigt die ausführliche Paketbeschreibung an. Über den linken Knopf (Bildschirmfoto herunterladen) beziehen Sie ein Bildschirmfoto, sofern dieses hinterlegt ist
[Die Bildschirmfotos kommen von [screenshots.debian.net]. Falls für Ihr Lieblingspaket ein Screenshot fehlt, können Sie selbst einen anfertigen und dort hochladen. Nach einem Review wird das hochgeladene Bild im Normalfall freigeschaltet und ist dann für alle Nutzer der Webseite und der Programme, die die Daten von dort verwenden, sichtbar.]
. Über den rechten Knopf (Änderungsprotokoll abrufen) zeigt Ihnen Synaptic die Änderungsdatei (engl. Changelog) zum ausgewählten Paket an.

Um ein Paket zu installieren, wählen Sie dieses zuerst über den Menüeintrag Paket ▸ Zum installieren vormerken (alternativ Strg+I oder einen Rechtsklick) aus. Über den Menüeintrag Bearbeiten ▸ Vorgemerkte Änderungen anwenden (alternativ Strg+P oder den Knopf Anwenden) lösen Sie die Installation aus. In ähnlicher Art und Weise verfahren Sie beim Löschen und Aktualisieren von Paketen. Synaptic prüft bei jeder Aktion die Paketabhängigkeiten und bezieht die weiteren Pakete in die Verarbeitung mit ein, damit ihr Linuxsystem stets in einem konsistenten Zustand bleibt.

Möchten Sie hingegen eine ganze Paketgruppe installieren, bietet Synaptic die gleiche Funktionalität wie das Werkzeug tasksel (siehe [tasksel]). Dazu nutzen Sie den Menüpunkt Bearbeiten ▸ Pakete nach Aufgaben vormerken. Daraufhin erscheint ein ähnliches Auswahlfenster wie in [fig.synaptic-tasksel], aus deren Liste sie die gewünschte Aktion markieren. Alle Pakete, die der ausgewählten Aufgabe zugeordnet sind, gelangen damit in die Vorauswahl und können daraufhin über den Knopf Anwenden installiert werden.

Muon ist ein Paketmanager für KDE und als Klon von Synaptic (siehe [gui-synaptic]) einzustufen. Es setzt auf dem graphischen Framework Qt auf und kommt bislang speziell in der Distribution Kubuntu [Kubuntu] zum Einsatz. Für Debian ist das gleichnamige Paket muon [Debian-Paket-muon] seit der Veröffentlichung Debian 9 Stretch verfügbar, für Ubuntu bereits ab der Veröffentlichung 12.04 Precise Pangolin.

Pakete können durch Auswahllisten nach der Softwarekategorie, dem Paketstatus, der Architektur und der Herkunft gefiltert werden. Dazu kommt ein Filter nach Zeichenketten in Paketnamen und -beschreibung. Zu beachten ist dabei, dass die verschiedenen Auswahlmenüs der Filter mit "und" verknüpft werden. Beim Wechsel in eine andere Filterkategorie kommt es daher schnell vor, dass kein Paket mehr in der Paketliste angezeigt wird, falls man vergessen hat, den Filter einer vorherigen Suche wieder zu entfernen bzw. auf "Alle" zu setzen.

Wählen Sie ein Paket mit einem Mausklick aus, so stellt Muon im Fensterbereich unter der Paketliste Metadaten und Details über das Paket dar. Dies umfaßt u.a. die Paketbeschreibung, die Paketabhängigkeiten, verfügbare Versionen, den Paketinhalt (Dateien im Paket), den Paketbetreuer, die installierte Größe der Software, die Downloadgröße und das Quellpaket, aus dem das Binärpaket gebaut wurde.

Im Paket smartpm [Debian-Paket-smartpm] verbirgt sich das gleichnamige Programm zur Paketverwaltung. Zunächst etwas unscheinbar, entpuppt es sich aber bei näherer Betrachtung als eine Art Alleskönner und mindestens gleichwertiges Pendant zu Synaptic (siehe [gui-synaptic]).

SmartPM verfügt über drei Bedienmodi. Erstens hat es ebenfalls eine graphische Bedienoberfläche auf der Basis des Gimp Toolkits (GTK2), lässt sich jedoch zweitens auch über die Kommandozeile mit mehreren Schaltern steuern und verfügt als drittes noch über eine Paketverwaltungsshell analog zu wajig ([wajig]) und zu cupt ([Cupt]).

Für ersteres rufen Sie SmartPM im Terminal über das Kommando smart --gui auf oder wählen den entsprechenden Eintrag aus dem Menü Ihrer Desktop-Umgebung aus. In [fig.smartpm] sehen Sie die zweispaltige Darstellung — links die Paketkategorien, rechts oben die Paketliste mit Paketname samt Versionsnummer und rechts unten die ausführliche Paketbeschreibung — hier am Beispiel des Pakets kexi. Unter dem Reiter General verbergen sich die Basisinformationen zum Paket, Description bietet die Paketbeschreibung, Content die Dateien aus dem Paket, Changelog die Veränderungen zur vorherigen Version, Relations die darüber bereitgestellten, verfügbaren und zusätzlich benötigten Pakete. Unter dem Reiter URLs verbergen sich weitere Referenzen zum Paket.

Für die Benutzung von SmartPM über die Kommandozeile starten Sie das Programm über den Aufruf smart mit der gewünschten Aktion und dem Paketname. Analog zu APT bzw. aptitude stehen bspw. die Unterkommandos install, remove und upgrade bereit.

Über den Aufruf smart --shell erreichen Sie die Paketverwaltungsshell. Darin nutzen Sie die gleichen Unterkommandos und Schalter wie bei obigem Aufruf über die Kommandozeile. Nachfolgendes Beispiel zeigt das Unterkommando info, welches hier alle Paketinformationen zum Paket kexi ausgibt.

SmartPM wirkt sehr ausgereift und verfügt zudem über eine Reihe von Besonderheiten. Es kann sowohl mit Paketen im deb- als auch in den verschiedenen rpm-Formaten umgehen. Das kann recht praktisch in gemischten Umgebungen sein. Im Gegensatz zu APT und aptitude gestattet es die Auswahl einer oder mehrerer Paketquellen zur Aktualisierung — bei APT sind nur alle aktiven auf einmal möglich.

Analog zu APT und aptitude kennt SmartPM auch diverse Markierungen. Das sind beispielsweise Flags, die anzeigen lassen, ob ein Paket seit der letzten Aktualisierung der Paketlisten neu hinzukam, ob ein Paket nicht aktualisiert werden darf („lock“, „hold“), oder ob ein Paket automatisch installiert wurde
[Bislang scheint SmartPM diese Markierungen nicht mit APT oder aptitude zu synchronisieren. Dieses Verhalten ist als Bug registriert.]
.

Allerdings stammt die letzte Veröffentlichung von SmartPM von 2011 [SmartPM] und es wurde 2019 aus Debian entfernt [SmartPM-RM], nachdem ebenfalls seit 2011 kein Änderungen mehr am Paket passiert und es auf Python 2 und PyGTK aufbaute, die beide "End of Life" sind, d.h. keinerlei Sicherheitsaktualisierungen mehr bekommen. Noch enthalten ist es in Debian 10 Buster und Ubuntu 18.04 LTS Bionic.

PackageKit ist eine allgemeine, distributionsneutrale Schnittstelle für unterschiedliche Paketverwaltungen, eine sogenannte Abstraktionsebene für die Paketverwaltung (package management abstraction layer). Das Designziel besteht darin, alle graphischen Werkzeuge zu vereinigen, die bei den verschiedenen Linuxdistributionen im Einsatz sind und gleichzeitig auf die neueste Technologie wie PolicyKit
[Berechtigungsdienst, der die Kommunikation von Software via DBus-Protokoll untereinander regelt]
umzustellen. PackageKit ist nicht dafür gedacht, hochspezialisierte Paketverwaltungssoftware zu ersetzen.

Seit 2009 nutzt die Linuxdistribution Kubuntu [Kubuntu] diese Schnittstelle für seine Paketverwaltung im Rahmen von Muon (siehe [gui-muon]). Weitere Anwendungen, die auf PackageKit aufsetzen, sind z.B. das Paket apper [Debian-Paket-apper] für den KDE, das Paket gnome-packagekit [Debian-Paket-gnome-packagekit] für GNOME (siehe [fig.gnome-packagekit]) und das Installationsprogramm zu Openmoko [OpenMoko].

PackageKit kann über die Interfaces APT und aptcc (Paket packagekit-backend-aptcc [Debian-Paket-packagekit-backend-aptcc]) an APT andocken. Ähnliches liefert das Paket packagekit-backend-smart [Debian-Paket-packagekit-backend-smart] für die Zusammenarbeit mit SmartPM ([gui-smartpm]) bzw. packagekit-command-not-found [Debian-Paket-packagekit-command-not-found] für die Installation fehlender Pakete via command-not-found. Das Werkzeug command-not-found steht unter „Fehlende Pakete bei Bedarf hinzufügen“ in [fehlende-pakete-bei-bedarf-hinzufuegen] im Mittelpunkt.

Initial nur für Ubuntu entwickelt, verbirgt sich unter dem Namen GDebi [gdebi] ein kleines, seit 2004 von Michael Vogt betreutes Programm. Auf den ersten Blick wirkt GDebi recht unscheinbar, füllt aber genau die kleine Lücke zwischen den Kommandos dpkg -i und apt-get install (siehe [dpkg], [apt] und [pakete-installieren]). Die Besonderheit von GDebi liegt darin, dass es lokal vorliegende deb-Pakete installieren kann, während es deren Abhängigkeiten aus den Repositories via APT auflöst und daraus die zusätzlich benötigten Pakete bezieht. Damit eignet es sich besonders gut, um zugesandte, selbst erstellte oder auch manuell heruntergeladene Pakete zu installieren.

GDebi besteht aus mehreren Komponenten — einem Kommandozeilenprogramm namens gdebi (aus dem Paket gdebi-core [Debian-Paket-gdebi-core]) und einer, ehemals zwei graphischen Bedienoberflächen. Die GTK-basierte Variante namens gdebi-gtk (aus dem Paket gdebi [Debian-Paket-gdebi] — siehe [fig.gdebi-gtk]) wird aktiv gepflegt und weiterentwicklet. Die KDE-Variante namens gdebi-kde (aus dem gleichnamigen Paket gdebi-kde [Debian-Paket-gdebi-kde]) wird nicht mehr weiterentwickelt und gab es zuletzt in Debian 9 Stretch..

Dabei dient das Kommandozeilenprogramm gdebi den beiden graphischen Werkzeugen als Backend und wird von diesen intern aufgerufen, um die jeweiligen Paketoperationen auszuführen. Sie können es aber auch alleine auf der Kommandozeile benutzen, ohne dass eine der beiden graphischen Komponenten installiert sein muss. Rufen Sie dazu GDebi auf der Kommandozeile mit einem deb-Paket als Parameter auf, erhalten Sie die Paketbeschreibung. Stimmen Sie danach der abschließenden Frage zur Installation mit j zu, führt gdebi ihren Wunsch aus und das deb-Paket landet auf ihrem Linuxsystem.

Die graphischen Werkzeuge starten Sie entweder über den Aufruf gdebi-gtk bzw. gdebi-kde im Terminal, oder aber durch Doppelklicken auf eine deb-Datei im Dateimanager ihrer Desktop-Umgebung. In letzterem Fall wird das von Ihnen angeklickte Paket jedoch nicht sofort installiert. Sie erhalten zunächst ein Fenster mit vielfältigen Informationen über das ausgewählte Paket (analog zu [fig.gdebi-gtk]). Erst mit einem weiteren Klick auf Paket installieren lösen Sie die Installation tatsächlich aus. Dieses Vorgehen hilft Ihnen dabei, herum(f)liegende Pakete nicht aus Versehen zu installieren. Somit vergewissern Sie sich nochmals, aus welcher ggf. auch unverifizierten Quelle dieses Paket stammt, bevor Sie es auf Ihrem Rechner installieren.

Neben der Installation und Aktualisierung ermöglicht Ihnen GDebi auch das Begutachten und Löschen von lokal vorliegenden Paketen. Dies können auch bereits vorher via APT heruntergeladene Pakete sein, die noch im Paketcache unter /var/cache/apt/archives/ herumdümpeln (siehe [paketcache]).

Das Begutachten von Paketen gelingt Ihnen über die einzelnen Reiter Beschreibung, Details und enthaltene Dateien. Neben der Paketbeschreibung zeigt Ihnen GDebi alle sonstigen Metadaten aus der Control-Datei (siehe [aufbau-und-format]) sowie den tatsächlichen Paketinhalt an, sofern es sich dabei um Textdateien handelt. Dies umfasst auch die Maintainer-Skripte.

Darüberhinaus zeigt Ihnen GDebi ab Version 0.9
[Verfügbar ab Debian 8 Jessie und Ubuntu 14.04 LTS Trusty Tahr]
auch sämtliche Warnungen des Programms lintian [Debian-Paket-lintian] an, die von dem ausgewählten Paket verursacht werden. Dies erlaubt Ihnen sowohl als Entwickler, als auch als normaler Benutzer, schnell einen groben Eindruck von der Qualität des Pakets zu bekommen, bevor Sie dieses auf ihrem Linux-System installieren und benutzen. Wie Sie mit dem referenzierten Programm lintian im Detail umgehen, lesen Sie unter „Nicht installierte Pakete mit lintian prüfen“ in [bugreports-lintian].

Ergibt sich bei der Veränderung des Paketbestands die Notwendigkeit, zusätzliche Paketabhängigkeiten aufzulösen, springt GDebi in die Bresche und klärt diese Situation automatisch mit Hilfe von APT [Vogt-gdebi]. Fehlende Pakete werden von den vorab konfigurierten Paketmirrors (siehe [etc-apt-sources.list-verstehen]) nachgezogen. Diese Eigenschaft hebt GDebi deutlich von dpkg ab, das nur meckern kann, falls es auf nicht-erfüllte Abhängigkeiten stößt.

Einziger Wermutstropfen bei GDebi ist, dass sowohl die beiden graphischen Tools, als auch gdebi bislang pro Aufruf nur ein einziges deb-Paket akzeptieren. APT ab Version 1.1 kann allerdings ebenfalls mit lokalen Paketen umgehen und dabei deren Abhängigkeiten über APT-Repositories auflösen — und das auch mit mehr als einem Paket auf einmal. Damit bietet es sich zukünftig als veritable Alternative zu gdebi an und soll dieses auch langfristig ersetzen
[Letzteres ist auch kein Wunder, da sowohl gdebi als auch diese Funktionalität von APT vom gleichen Autor stammen.]
.

Canonical stellt mit Ubuntu Landscape [Ubuntu-Landscape] seit 2008 eine zentrale Administrationsoberfläche für Einzelrechner und Serversysteme bereit. Ubuntu Landscape ist Teil des kostenpflichtigen Servicepakets Ubuntu Advantage und sowohl als gehosteter Dienst nutzbar oder auch lokal installierbar
[Die Pakete dafür heißen landscape-client, landscape-client-ui, landscape-client-ui-install und landscape-common]
. Darüberhinaus steht eine API zur individuellen Ansteuerung bereit.

Die erhoffte Nutzergruppe von Ubuntu Landscape sind weniger die Endbenutzer, sondern Unternehmen und deren gesamte Infrastruktur. Das Ziel besteht dabei in der möglichst vollständigen, weitestgehend automatisierten und zentralen Systemadministration für bis zu 40000 Computer. Das Angebot umfasst daher eine webbasierte Schnittstelle für das Patch- und Änderungsmanagement, die rollenbasierte Verwaltung für Einzelbenutzer und Gruppen sowie Sicherheitseinstellungen von Ubuntu-Desktop-Systemen und -Servern (siehe [fig.ubuntu-landscape-rollback]).

Im Bereich der Paketverwaltung und Systemaktualisierung erhalten Sie einerseits Informationen zu den einzelnen Softwarepaketen und deren Verfügbarkeit und sehen auf den betreuten und über Ubuntu Landscape gepflegten Computern deren Installationsstatus. Wie bei Communtu (siehe [webbasierte-programme-communtu]) kommen auch hier Metapakete (siehe [uebergangs-und-metapakete]) verstärkt zum Einsatz. Darüber werden Paketgruppen und ganze Softwareprofile für die betreuten System realisiert und abgebildet.

Seit 2008 betreibt der Japaner Akira Ohgaki in Eigenregie seine nichtkommerzielle Plattform Appnr [appnr]. Darüber stehen deb-Pakete verschiedener Repositories bereit, die Sie für ihr jeweiliges Ubuntu-Linuxsystem beziehen und installieren können (siehe [fig.appnr]). Der Name des Projekts orientiert sich am Neusprech „App“, da Sie die Installation im Webbrowser beginnen und die Handhabung der Nutzung einer „App“ auf Geräten mit einem berührungsempfindlichen Bildschirm entspricht.

Aus technischer Sicht verfügt Appnr nicht über ein eigenes Repository. Stattdessen stellt der angebotene Dienst eine browserbasierte, übersichtliche Schnittstelle für Repositories von Ubuntu und verschiedenen Drittanbietern bereit, die entsprechend dem aktuellen Zeitgeschmack gestaltet ist. In der linken Spalte der Darstellung finden Sie die Paketkategorien und in der mittleren Spalte die dazugehörigen Softwarepakete. Über das Eingabefeld am oberen Rand spezifizieren Sie ihren Suchbegriff, nach welchem danach sowohl in den Paketnamen, der Paketbeschreibung, als auch in der Liste der enthaltenen Dateien gesucht wird.

Im Ergebnis sehen Sie eine Kurzbeschreibung zum Paket, Bildschirmfotos von screenshots.debian.net [screenshots.debian.net] (sofern hinterlegt und verfügbar), eine Bewertung und eine Information zur Häufigkeit der Installation. Letzteres bezieht sich auf die Informationen, die Ubuntu im Rahmen seiner statistischen Erhebung durch den Popularity Contest gesammelt hat.

Zum Bezug der ausgewählten Pakete und sofortiger Installation benötigen Sie das Paket apturl ([Ubuntu-apturl] und [Vogt-apturl]), welches wir Ihnen in [webbasierte-installation-von-paketen-mit-apturl] genauer vorstellen.

Communtu ist eine Plattform, die seit 2008 vom Bremer Verein Natur, Geist und Technik — Verein zur Förderung der Allgemeinbildung e.V. betrieben und gepflegt wird. Über die Webseite stellen Sie sich aufgabenbezogene deb-Pakete für Ubuntu zusammen, die Sie danach auf ihrem Linuxsystem einspielen können. Dabei löst die Paketverwaltung alle Abhängigkeiten zwischen den einzelnen Paketen auf. Den Quellcode der Plattform hat der Verein unter der Affero GNU Public License (AGPL) freigegeben. Für Debian GNU/Linux gibt es seit 2004 ein ähnliches Konzept unter dem Namen Debian Pure Blends (siehe [Debian-Pure-Blends]).

Hintergrund ist die Idee, alle benötigten Programme für eine Aufgabe zu kombinieren und als Paketbündel abzulegen. Ein solches „Bündel“ ist stets einer Kategorie zugeordnet, beispielsweise Audio, Büro oder Komplettinstallation (siehe [fig.communtu]). Die Webseite stellt die Infrastruktur zur Zusammenstellung bereit und ermöglicht Ihnen einerseits, Detailinformationen zu den Paketbündeln abzurufen, erstellte Paketbündel zu hinterlegen und damit auch anderen Benutzer zugänglich zu machen sowie bestehende Paketbündel zu beziehen, online zu bewerten und auch zu verbessern.

Es „vereinfacht [Ihnen] damit die Auswahl und Installation von Software, die nicht durch die Standardinstallation des Ubuntu-Systems abgedeckt ist“ (Quelle: UbuntuUsers-Wiki [Communtu]). Zudem integriert es auch Pakete von Fremdquellen und erleichtert somit die sich wiederholende Installation gleichartiger Systeme, bspw. für einen Klassenraum in einer Schule.

Die technische Basis hinter dem Angebot der Plattform bilden Metapakete (siehe [uebergangs-und-metapakete]) sowie das Werkzeug apturl (siehe [webbasierte-installation-von-paketen-mit-apturl]). Nachdem Sie über die Webseite Ihre gewünschte Software ausgewählt haben, wird automatisch ein erstes passendes Metapaket erzeugt. Dieses beinhaltet lediglich die Abhängigkeiten zu den von Ihnen zuvor ausgewählten Softwarepaketen. Gleichzeitig stellt die Plattform ein weiteres, spezifisches Metapaket bereit, welches ihre Liste der Paketquellen entsprechend anpasst, um damit die Anbindung von weiteren Paketquellen zu ermöglichen. Mittels apturl beziehen Sie die erzeugten Metapakete über ihrem Webbrowser, so dass die Paketverwaltung diese Pakete auch einspielen kann.

Der Univention Corporate Server (UCS) [UCS] ist ein auf kommerzieller Basis vertriebenes OpenSource-Produkt für Infrastrukturlösungen in Unternehmen und Behörden. Neben dem Univention (Linux) Client werden alle „domänenfähigen Betriebssysteme“ (Windows, Mac OS, Linux) via Samba 4 unterstützt.

Die Erweiterung UCS at School ist für den Einsatz in Lehr- und Forschungseinrichtungen verfügbar, welche spezielle Softwarekomponenten für die Unterstützung des Lehrbetriebes enthält und damit die Infrastruktur für Bildungseinrichtungen abdeckt. Dazu zählt bspw. Klassenraummanagement, Verteilung und Einsammeln von Arbeitsmaterialien sowie die Moderation von Druckern und Druckaufträgen. Die Entwicklung von UCS begann 2002, der Server ist seit 2004 und der Client seit 2009 verfügbar.

Basis des vom Bremer Unternehmen Univention GmbH zusammengestellten, entwickelten und vertriebenen Produktes ist Debian GNU/Linux, welche um einige Komponenten erweitert wurde. Mit diesen Komponenten werden Skalierbarkeit, Konfigurationsmanagement und weitere Möglichkeiten zur Verfügung gestellt, die in dieser Form in der Linux-Distribution nicht vorhanden sind. Durch regionale Kooperationspartner vor Ort und den Hersteller Univention GmbH werden die Kunden technisch betreut und der Support sichergestellt.

Den Ausgangspunkt bildet stets eine stabile Debian-Veröffentlichung — UCS 5.0 basieert z.B. auf Debian 10 Buster, UCS 4.4 auf Debian 9 Stretch. Für diese Softwarebasis pflegt Univention eine Reihe von Eigenentwicklungen und Anpassungen.

Konkret zeigt sich das bereits im Paketnamen. Alle von Univention modifizierten Pakete tragen das Präfix univention, so bspw. univention-dns zur Einrichtung des Domain Name Systems. Weiterhin besteht eine geänderte Konfiguration der bereitgestellten Softwarepakete über zusätzliche Vorlagen, sogenannte univention templates. Diese Vorlagen und deren Einstellungen richten sich nach der von Ihnen vergebenen Systemrolle und damit der Funktion der jeweiligen, spezifischen UCS-Instanz.

Die Paketverwaltung ist mehrstufig und setzt auf den bereits bewährten und beschriebenen Mechanismen von Debian mittels dpkg und APT auf. Univention ergänzt diese Werkzeuge um eine zusätzliche Ebene, um die Softwarepakete passend zur vorher festgelegten Systemrolle und den Vorlagen zu installieren und automatisch konfigurieren zu können.

Die Basis bildet der Univention Installer, welcher im Prinzip ein modifizierter Debian-Installer ist. Bei der Grundinstallation wählen Sie danach ihre gewünschten Softwarekomponenten über ein modifiziertes Tasksel [tasksel] aus. Installieren Sie zu einem späteren Zeitpunkt Software nach, stehen Ihnen auf der Kommandozeile die beiden Werkzeuge univention-install und univention-remove zur Verfügung. Diese akzeptieren Paketnamen als Parameter und versorgen dpkg und APT mit den zusätzlichen Daten aus den dazugehörigen, von Univention bereitgestellten Vorlagen.

dpkg und APT können Sie jederzeit für die grundlegenden Paketoperationen nutzen, um beispielsweise nach Paketen zu suchen, deren Installationszustand zu erfragen oder um die Paketinhalte anzuzeigen. Installieren Sie hingegen Pakete mit dpkg und APT eigenhändig nach, müssen Sie die Angaben aus den Vorlagen selbständig in die Konfiguration des Pakets und die zentrale Konfigurationsdatei namens Univention Configuration Registry (UCR) übertragen.

Erweiterungen und Werkzeuge von Drittanbietern wählen Sie webbasiert über das sogenannte Univention App Centre (siehe [fig.univention-app-centre]) aus. In der darüber angebotenen Paketmenge sind Programme enthalten, die zuvor von Univention freigegeben wurden. Das beinhaltet bspw. Software für Wikis, Groupwares oder auch Werkzeuge zur Inventarisierung. Die Konfiguration der Pakete erfolgt nicht direkt über die Webschnittstelle, sondern ist programmspezifisch. Das gilt auch für Aktualisierungen der Pakete, die hier nicht Updates, sondern Errata heißen (siehe [univention-errata]).

Es kann jedoch vorkommen, dass das Herunterladen eines oder mehrerer Pakete fehlschlägt. Ursachen können beispielsweise sein, dass die Netzwerkverbindung unterbrochen oder der Spiegelserver neugestartet wurde. Möglich ist auch, dass just zwischen dem letzten Aufruf von apt-get update und dem Herunterladen der Pakete eine Aktualisierung des Paketspiegels stattfindet und genau das Paket durch ein neueres ersetzt wird, welches Sie gerade zum installieren oder aktualisieren herunterladen möchten.

apt-get bricht in diesem Fall ab, aptitude fragt Sie hingegen als Benutzer, ob Sie trotzdem fortsetzen oder den Vorgang abbrechen möchten. Zu überlegen ist das beispielsweise, wenn nur ein einziges Paket fehlschlug, welches von den anderen unabhängig ist.

Wenn die Netzwerkverbindung (wieder) in Ordnung ist, beheben Sie eine solche Situation in den meisten Situationen ohne viel Aufwand. Das gilt inbesondere aber im letztgenannten Fall. Mit einem weiteren Aufruf von apt-get update bringen Sie die Paketlisten auf aktuellen Stand und starten die geplante Aktualisierung oder Installation von Paketen danach nochmals.

APT benutzt zwei Caches — einen im RAM, und einen auf einem (lokalen) Speichermedium. Die Informationen dazu bedurften aufwendiger Recherche.

Die Größe des APT-Caches im RAM erhalten Sie über den Aufruf von apt-cache stats in Kombination mit grep, wobei Sie die Zeile "Gesamtmenge an Speicher" aus der Ausgabe von apt-cache stats herausfiltern.

apt-cache liefert hingegen keine Information darüber, wieviel Platz es auf einem physischen Datenträger belegt. Dazu greifen Sie auf ein klassisches UNIX/Linux-Werkzeug zurück — du mit den beiden Schaltern -s(Langform: --summarize) und -h (Langform: --human-readable) angewendet auf das Verzeichnis des Paketcaches. Sofern nicht anders von Ihnen zuvor konfiguriert, ist der Pfad /var/cache/apt/archives.

Der Defaultwert ist mit 0 festgelegt, d.h. es besteht keine Größenbegrenzung seitens APT. In diesem Fall ergeben sich die Limits aus der physikalischen Größe der Partition, der das Verzeichnis für den Paketcache zugeordnet ist sowie dem Dateisystem auf der Partition selbst. Im Dateisystem sind wiederum die Anzahl der Inodes (Einträge) und die Blockgröße festgelegt, die letztendlich regeln, wieviele Pakete als Datei gespeichert werden können.

Während APT Softwarepakete von der hinterlegten Paketquelle bezieht — in der Regel von einem Paketmirror — behält APT die Pakete im Verzeichnis /var/cache/apt/archives/partial. Ist der Download abgeschlossen, werden diese in das Verzeichnis /var/cache/apt/archives verschoben, anschließend ausgepackt und installiert.

Die bezogenen Pakete verbleiben im Cache. Werden die Pakete zu einem späteren Zeitpunkt nochmals benötigt und die Paketversion ist (noch) identisch, schaut APT zuerst im Paketcache nach und entnimmt diese von dort, bevor es die Pakete erneut von der Quelle bezieht. Das geht meist schneller, als diese erneut herunterzuladen.

Nachteil ist, dass diese Pakete Speicherplatz auf dem Datenträger ihres Debian-Systems belegen. Wird es damit knapp, raten wir Ihnen daher, diesen Speicherplatz regelmäßig aufzuräumen. Mittlerweile ist die Bezugszeit der Pakete über das Internet vielfach so gering, dass sich ein längerfristiges Vorhalten im Paketcache eigentlich erübrigt. Es ist in diesem Fall Abwägungssache und hängt davon ab, wie häufig Sie Pakete entfernen und später wieder einspielen.

Den Paketcache finden Sie im Verzeichnis /var. Je nach Partitionierung ihres Datenträgers ist der Bereich nicht separat und möglicherweise Bestandteil der /-Partition. Ist diese vollständig mit Daten gefüllt, funktioniert vieles auf ihrem Linuxsystem nicht mehr.

Bei ausgefeilteren Installationen bestehen häufig separate Partitionen für /var oder /var/cache. Läuft einer dieser Bereiche voll, können im einfachsten Fall keine weiteren Pakete zwischengespeichert und auch nicht temporär entpackt werden. Falls der Bereich /var vollständig belegt ist, können auch keine Logdateien mehr angelegt oder weitere Informationen daran angehängt werden.

Einen Ausweg aus diesem Dilemma gelingt Ihnen mit dem Anlegen einer separaten Partition für /var/cache/apt/archives. Wie Sie diese einrichten und mit welchen Vor- und Nachteilen dieser Schritt verbunden ist, zeigen wir Ihnen unter „Cache-Verzeichnis auf separater Partition“ in [cache-verzeichnis-auf-separater-partition].

Die Programme dpkg, apt-get, aptitude und Synaptic räumen den Paketcache in der Standardeinstellung nicht eigenständig auf und belassen die Pakete nach der Installation oder Aktualisierung im Paketcache. Ob überhaupt, wann und insbesondere wie aufgeräumt wird, entscheiden Sie als Systembetreuer selbst und müssen dazu das von ihnen verwendete Werkzeug entsprechend konfigurieren.

Aus unserer Sicht sind die einzelnen Werkzeuge in Debian GNU/Linux wie folgt konfiguriert:

Grundsätzlich gibt es mehrere, unterschiedlich radikale Ansätze zum Aufräumen des Paketcaches. Die Variante eins umfasst das Löschen von Paketen aus dem Cache, die in keinem der verwendeten APT-Repositories mehr verfügbar sind. Die beiden Aufrufe apt-get autoclean und aptitude autoclean implementieren diesen Ansatz. Bei Synaptic nutzen Sie dazu den Menüpunkt Einstellungen ▸ Dateien und selektieren im Dialogfenster den Eintrag „Nur Pakete löschen, die nicht länger verfügbar sind“ (siehe [fig.synaptic-paketcache-leeren]). In der Standardeinstellung erleichtern diese Kommandos den Cache auch um Pakete, die Sie in der vorliegenden Version nicht mehr vom Spiegelserver beziehen können, die aber noch auf ihrem Linuxsystem installiert sind.

Um hingegen lediglich die Pakete aus dem Cache zu löschen, die auch nicht, oder nicht mehr installiert sind, hilft Ihnen die Konfigurationsoption APT::Clean-Installed=off in der Konfiguration von APT. Alternativ teilen Sie das apt-get mit diesem Aufruf explizit mit:

Allerdings besteht keine Möglichkeit mehr, diese Pakete mittels APT zu einem späteren Zeitpunkt wieder zu installieren, da sie ja in keiner Paketliste mehr vorkommen. Benötigen Sie eines der Pakete später doch wieder, hilft Ihnen nur der Rückgriff auf dpkg in Kombination mit dem dazugehörigen deb-Paket weiter. Dazu benutzen Sie den Aufruf dpkg -i Paketname. Paketname bezeichnet den Namen und Pfad der lokalen Datei für das benötigte deb-Paket (siehe [pakete-installieren]).

Variante zwei umfasst das Löschen sämtlicher Pakete aus dem Paketcache — damit schaffen Sie radikal Platz. Die passenden Kommandos dazu lauten apt-get clean und aptitude clean. Übrig bleiben danach nur die beiden Verzeichniseinträge für die Sperrdatei lock und das Unterverzeichnis partial, in dem die Fragmente für Pakete landen, die nur teilweise bezogen wurden.

Bei Synaptic bildet zunächst der Eintrag Einstellungen ▸ Dateien den Ausgangspunkt. Über den Knopf „Alle Paketdateien im Zwischenspeicher löschen“ lösen Sie die Aufräumaktion aus (siehe [fig.synaptic-paketcache-leeren]).

Selbstverständlich können Sie auch als Administrator agieren und dabei gezielt nur ausgewählte oder auch alle vorliegenden deb-Dateien manuell aus dem Verzeichnis /var/cache/apt/archives/ mittels rm Paketdatei löschen. Gerade bei den Paketen, die Daten für Spiele beinhalten — z.B. 0ad-data mit ca. 530 MB Paketdateigröße — , reicht es oft aus, diese einzelnen Dateien aus dem Paketcache zu entfernen, um dort wieder ausreichend Platz zu haben.

Alle derzeit von Debian unterstützten Versionen von APT klagen nicht, wenn Sie das gesamte Verzeichnis /var/cache/apt/archives/partial/ klammheimlich hinter dem Rücken der beiden Programme einfach komplett entsorgen. APT und aptitude legen es bei einem späteren Bedarf einfach von selbst wieder an. Anders sieht es hingegen bei älteren Veröffentlichungen wie z.B. Debian 4.0 Etch oder Debian 5.0 Lenny, Ubuntu 10.04 LTS Lucid Lynx sowie Debian-Derivaten aus der Zeit vor Mitte 2010 aus. Beachten Sie bitte, dass APT vor Version 0.8 beim Löschen eines der beiden Verzeichnisse /var/cache/apt/archives/partial/ oder /var/lib/apt/lists/partial/ dann einfach den Dienst verweigert. Sie beheben das Problem flink, indem Sie die genannten Verzeichnisse manuell wieder anlegen. Haben Sie /var/cache/ als tmpfs-Dateisystem eingehängt (siehe [cache-verzeichnis-auf-separater-partition]), so können Sie mit dem Aufruf mkdir -p /var/cache/apt/archives/partial als Eintrag in der Datei /etc/rc.local dauerhaft Abhilfe schaffen.

Wann Sie am besten aufräumen, hängt etwas von der Nutzung und dem verfügbaren Plattenplatz ab. In den meisten Fällen ist nach dem Installieren und Aktualisieren der Pakete ein guter Zeitpunkt. aptitude bietet dies sogar über die Option Aptitude::Autoclean-After-Update an (siehe unten).

Ist jedoch der Plattenplatz recht knapp, so kann auch es auch helfen, den Cache bereits vor dem Installieren und Aktualisieren aufzuräumen. Das ist insbesondere dann sinnvoll, wenn Sie dies selbst nicht regelmäßig machen und diese Aktion stattdessen per Cron-Job oder über die Konfiguration der Paketverwaltung ausführen lassen. Es macht jedoch keinen Sinn, wenn Sie beispielsweise gleichzeitig die APT-Option APT::Periodic::Download-Upgradeable-Packages eingeschaltet haben und damit nachts automatisch alle aktualisierbaren Pakete herunterladen lassen. Leeren Sie den Paketcache danach mit apt-get clean komplett, hat das zur Folge, dass die frisch bezogenen Pakete wieder gelöscht werden und ein nachfolgendes apt-get upgrade diese erneut herunterladen muss.

Das manuelle Aufrufen der o.g. Kommandos kostet Zeit. Daher bieten APT und aptitude unterschiedliche Möglichkeiten, um diese Vorgänge zu automatisieren.

Das Paket apt bringt mit dem Skript /etc/cron.daily/apt einen Cron-Job mit, der diverse Aufgaben einmal pro Tag ausführen kann. Konfiguriert wird das Skript ebenfalls über die Datei /etc/apt/apt.conf. Den Paketcache betreffen die beiden Einstellungen APT::Periodic::Download-Upgradeable-Packages und APT::Periodic::AutocleanInterval.

Die Dokumentation zu diesem Skript finden Sie in den Kommentarzeilen am Anfang der Datei /etc/cron.daily/apt. Dort finden sich noch weitere und feinere Einstellmöglichkeiten zum automatischen Aufräumen des Paketcaches, z.B. anhand des Alters der Pakete.

aptitude dagegen bietet eine Zeitsteuerung über Schalter und Optionen an. Damit erfolgt das Aufräumen via autoclean oder clean vor oder nach der Installation von Paketen automatisch:

Ähnliches ermöglicht Ihnen aptitude auch über die Text-Modus-Bedienoberfläche. Setzen Sie in den Einstellungen unter „Veraltete Paketdateien nach dem Laden von neuen Paketlisten löschen“ ein Häkchen, entspricht das der Konfigurationsoption Aptitude::AutoClean-After-Update. Damit löscht Aptitude nach jeder Aktualisierung der Paketlisten (durch aptitude) alle Paketdateien aus dem Paketcache, die nicht mehr von einem in /etc/apt/sources.list aufgeführten Paketmirror heruntergeladen werden können.

Mit diesen beiden Aufrufen ermitteln Sie den Status eines installierten Pakets. Die Langform zu -s ist --status. Intern greift dpkg auf dpkg-query zurück, so daß Sie die gleichen Schalter verwenden können. Paketname bezeichnet hier den Namen eines Debianpakets.

Die Ausgabe beinhaltet bspw. die Paketfelder Paketname (siehe [benennung-eines-debian-pakets]), Status, Priorität (siehe [paket-prioritaet-und-essentielle-pakete]), Paketkategorie (siehe [sortierung-der-pakete-nach-verwendungszweck]), installierte Größe, Maintainer, Architektur ( siehe [debian-architekturen]) und Version (siehe [benennung-eines-debian-pakets]) aus. Darunter listet dpkg die dazugehörige, hinterlegte Paketbeschreibung auf.

Der nachfolgende Aufruf ist zudem identisch zu grep-status -F Package -X htop, wobei Sie mit -F das entsprechende Paketfeld und mit -X den Paketnamen angeben. Das Kommando grep-status ist Bestandteil des Pakets dctrl-tools [Debian-Paket-dctrl-tools].

Im Gegensatz zu dpkg -s verarbeitet der Schalter -I (Langform --info) lokal vorliegende deb-Dateien. Daraus extrahiert dpkg bzw. dessen Hilfsprogramm dpkg-deb die Einträge der Steuerdatei sowie die Paketinformationen.

apt-cache ist Bestandteil des Debian-Pakets apt [Debian-Paket-apt]. Der Aufruf apt-cache show Paketname liefert ein ähnliches Ergebnis wie obiges dpkg -s Paketname, ist jedoch noch ausführlicher. Neben einer übersetzten Paketbeschreibung (Lokalisierung, sofern vorhanden) erscheinen zusätzlich die Debtags (siehe [erweiterte-paketklassifikation-mit-debtags]) zum Paket, der Dateiname und Pfad im Paketmirror und die GPG-Keys zur Validierung des Pakets (siehe [bezogenes-paket-verifizieren]).

Desweiteren verfügt apt-cache über das Unterkommando showpkg. Primär dient es dazu, die verfügbaren Paketvarianten samt deren Abhängigkeiten und Übersetzungen darzustellen. Die Ermittlung der einfachen und umgekehrten Paketabhängigkeiten besprechen wir ausführlicher unter „Paketabhängigkeiten anzeigen“ in [paketabhaengigkeiten-anzeigen].