Debian-Paketmanagement

Axel Beckert

Frank Hofmann

Das Buch "Debian-Paketmanagement" von Frank Hofmann und Axel Beckert ist lizenziert unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Versionsgeschichte
Version debian/0_2017.01.16-17-g1152e502017-03-10T15:47:32+00:00

Zusammenfassung

Die Debian-Distribution setzt sich aus mehreren zehntausend Bausteinen zusammen, die alle aufeinander abgestimmt sind und sich bei Bedarf in eine Installation integrieren. Diese sogenannten Pakete (Packages) sind so eigenständig, dass sie von einem oder mehreren Debian-Entwicklern für das Debian-Projekt gepflegt werden, interagieren aber zugleich so intensiv mit allen anderen, dass wechselseitige Abhängigkeiten erkannt und bei Bedarf automatisch aufgelöst werden. Nur so ist die Modularität des komplexen Gesamtsystems gewährleistet, die Administratoren weltweit die Möglichkeit bietet, Debian-Installationen sehr genau für die jeweilige Anforderung vom Embedded-Gerät über den Desktop bis zum Großrechner zu konfigurieren.

Effizientes Paketmanagement ist also für jeden Debian-Administrator ein ebenso interessantes wie lohnendes Feld, das in der Praxis aber oft nicht ausreichend beachtet und mit wenigen Standardbefehlen "erledigt" wird. Zwei ausgewiesene Debian-Experten nehmen dies zum Anlass, das Debian-Paketmanagement erstmals derart umfassend darzustellen. Das Buch kommt von den Konzepten, die der Struktur und dem Zusammenspiel der Pakete zugrunde liegen, über die Werkzeuge zu deren Nutzung immer auch zu den Best Practices der professionellen Systemadministration. Es wendet sich an Einsteiger ebenso wie an Berufsadministratoren, indem es, ausgehend von den Grundlagen, das Optimierungspotential in zunehmend umfangreichen Szenarien ausschöpft. So entsteht ein aktuelles Handbuch der Debian-Administration, das als praxisorientiertes HowTo ebenso dient wie als Nachschlagewerk für die unerwartet zahlreichen Optionen und Kombinationsmöglichkeiten.


Inhaltsverzeichnis

Über dieses Buch
1. Kann Paketmanagement Spaß machen?
2. Zum Buch
2.1. Über die Autoren
2.2. Wie und warum dieses Buch entstand
2.3. Motivation
2.4. Technische Basis
2.5. Quellcode und Lizenz
2.6. Organisatorisch
2.7. Grundlagenwissen für Administratoren
2.8. Dokumentation deb vs. rpm
2.9. Was ist das Buch – und was nicht …
2.10. Zielgruppe und Lernziele
2.11. Vorkenntnisse
2.12. Und das können Sie nach der Lektüre …
2.13. Buchinfo
3. Danksagung
I. Konzepte
1. Willkommen im Linux-Dschungel!
1.1. Was ist Debian?
1.2. Debian-Architekturen
1.2.1. Debian-Ports-Projekt
1.2.2. Pakete für alle Architekturen
1.2.3. Multiarch: Mehrere Architekturen gleichzeitig auf einem System
1.2.4. Bevor es Multiarch gab
1.3. Vom tar.gz zur Linux-Distribution
1.4. Debians Paketsystem
1.5. Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement
2. Software in Paketen organisieren
2.1. Was ist Paketmanagement
2.2. Varianten und Formate für Softwarepakete
2.3. Softwarestapel und Ebenen
2.3.1. Ebenen
2.3.2. Untere Ebene
2.3.3. Obere Ebene
2.3.4. Paketformate und -werkzeuge anderer Distributionen
2.3.5. Werkzeuge, die verschiedene Paketformate unterstützen
2.4. Alternativen zu APT
2.5. Zusammenspiel von dpkg und APT
2.6. Vom monolithischen Programm zu Programmkomponenten
2.7. Debian-Pakete (Varianten)
2.7.1. Binärpakete (deb)
2.7.2. Übergangspakete, Metapakete und Tasks
2.7.3. Mikro-Binärpakete
2.7.4. Source-Pakete (dsc und weitere Dateien)
2.7.5. Virtuelle Pakete
2.7.6. Pseudopakete im Debian Bug Tracking System
2.8. Sortierung der Pakete nach Verwendungszweck
2.9. Distributionsbereiche
2.9.1. Einordnung der Distributionsbereiche in Debian
2.9.2. Einordnung der Distributionsbereiche bei anderen Distributionen
2.9.3. Handhabung von geschützten Namen und Logos
2.9.4. Softwareverteilung
2.9.5. Hintergrund der Einteilung in Distributionsbereiche
2.10. Veröffentlichungen
2.10.1. Bedeutung der verschiedenen Entwicklungsstände
2.10.2. Alias-Namen
2.10.3. Zusammenhang von Alias-Namen und Entwicklungsständen
2.10.4. Pakete auf Wanderschaft von einem Entwicklungsstand in den nächsten
2.10.5. Organisation der Pakete im Paketpool
2.11. Benennung einer Paketdatei
2.11.1. Paketname
2.11.2. Versionsnummer
2.11.3. Architektur oder Plattform
2.12. Multiarch einsetzen
2.12.1. Multiarch-Beispiel: Installieren eines 32-Bit-Pakets auf einem 64-Bit-System
2.13. Paket-Priorität und essentielle Pakete
2.13.1. Prioritätsstufe „erforderlich“ (required)
2.13.2. Prioritätsstufe „wichtig“ (important)
2.13.3. Prioritätsstufe „standard“ (standard)
2.13.4. Prioritätsstufe „optional“ (optional)
2.13.5. Prioritätsstufe „extra“ (extra)
2.13.6. Markierung „essentiell“ (essential)
2.14. Verbreitungsgrad von Paketen
2.14.1. Verschiedene Metriken
2.14.2. Vergleichen von Paketen
2.15. Lokale Paketmarkierungen
2.15.1. Paketmarkierungen, die von verschiedenen Programmen genutzt werden
2.15.2. Aptitude-spezifische Paketmarkierungen
2.15.3. Lesen und Anzeigen einer Markierung mit aptitude
2.15.4. Lesen und Anzeigen einer Markierung mit apt-mark
2.15.5. Setzen und Entfernen einer Markierung mit apt-mark
2.15.6. Was passiert, wenn Paketmarkierungen geändert werden?
2.15.7. Setzen und Entfernen einer Markierung mit aptitude
2.16. Wie finde ich passende Pakete
2.16.1. Paketquellen
2.16.2. Paketnamen
2.16.3. Paketeigenschaften und Einordnung
II. Werkzeuge
3. Paketquellen und Werkzeuge
3.1. Paketquellen
3.1.1. Begriff und Hintergrund
3.1.2. Benutzte Paketquellen
3.1.3. Aufbau und Struktur einer Paketquelle
3.2. Empfehlung zum Ablauf für das Hinzufügen und Ändern von Paketquellen
3.3. /etc/apt/sources.list verstehen
3.3.1. Format der Paketliste
3.3.2. Format eines Eintrags
3.3.3. Beispieleinträge für offizielle Pakete
3.3.4. Verzeichnis als Paketquelle
3.3.5. Einträge für Sicherheitsaktualisierungen
3.3.6. Einträge für zusätzliche, nicht-offizielle Pakete
3.3.7. Einträge für Quellpakete
3.3.8. Einträge für Deutschland
3.4. Geeigneten Paketmirror auswählen
3.4.1. Paketmirror bei Debian
3.4.2. Paketmirror für andere Distributionen
3.4.3. Pakete ohne Paketmirror beziehen
3.5. Am besten erreichbaren Paketmirror finden
3.5.1. netselect und netselect-apt
3.5.2. Paketquellen mit apt-spy einstellen
3.6. Automatisiertes Auswählen von Paketquellen
3.6.1. DNS Round Robin
3.6.2. Paketquellen über GeoIP auswählen
3.6.3. Immer per GeoIP: Security-Updates
3.6.4. GeoIP per DNS
3.6.5. GeoIP per HTTP-Redirect
3.6.6. Automatische Paketmirror-Auswahl per Mirror-Liste
3.6.7. Welcher Paketmirror wird schlussendlich benutzt?
3.7. apt-setup — Erstellung der Paketliste während der Installation
3.8. Physische Installationsmedien mit apt-cdrom einbinden
3.9. Einträge mit add-apt-repository im Griff behalten
3.9.1. Aufruf und Optionen
3.9.2. Beispiele
3.10. Einstellungen mit Synaptic und im Ubuntu Software Center
3.11. Debian und Ubuntu Sources List Generator
3.11.1. Feinheiten für Debian
3.11.2. Feinheiten für Ubuntu
3.12. Paketquelle auf Echtheit überprüfen
3.12.1. Basiswissen
3.12.2. Schlüsselverwaltung mit apt-key (Überblick)
3.12.3. Unterkommandos von apt-key
3.12.4. Beispiel: Ergänzung eines Schlüssels
3.12.5. Alternative Benutzerschnittstellen zur APT-Schlüsselverwaltung
3.13. Liste der verfügbaren Pakete aktualisieren
3.14. Lokale Paketliste und Paketcache
3.15. Lokale Paketliste reparieren
3.15.1. Aktualität des Mirrors überprüfen
4. Debian-Paketformat im Detail
4.1. Konzepte und Ideen dahinter
4.1.1. Binärpakete
4.1.2. Sourcepakete
4.1.3. Weitere Metadaten
4.2. Aufbau und Format
4.2.1. Generell: 2 Ebenen
4.2.2. Source-Pakete
4.2.3. Binärpakete
4.2.4. Übergangs- und Metapakete
5. APT und Bibliotheken
5.1. Bibliothek libapt-pkg
5.2. Bibliothek libapt-pkg-perl
5.3. Bibliothek python-apt
5.4. Bibliothek libapt-pkg-doc
5.5. Bibliothek libapt-inst
6. Werkzeuge zur Paketverwaltung (Überblick)
6.1. Frontends für das Paketmanagement
6.1.1. Aufgaben, Sinn und Zweck des Frontends
6.1.2. Anmerkungen zur Programmauswahl
6.2. Für die Kommandozeile
6.2.1. dpkg
6.2.2. APT
6.2.3. Die aptsh
6.2.4. wajig
6.2.5. Cupt
6.3. ncurses-basierte Programme
6.3.1. tasksel
6.3.2. aptitude
6.4. GUI zur Paketverwaltung
6.4.1. Synaptic
6.4.2. Muon
6.4.3. Smart Package Management (SmartPM)
6.4.4. Ubuntu Software Center
6.4.5. PackageKit
6.4.6. GDebi
6.5. Webbasierte Programme
6.5.1. Ubuntu Landscape
6.5.2. Appnr
6.5.3. Communtu
6.5.4. Univention Corporate Server (UCS)
7. Paketcache
7.1. Hintergrundwissen
7.1.1. Was passiert, wenn nicht alle Pakete heruntergeladen werden konnten?
7.2. Paketcache-Status
7.3. Paketcache aufräumen
7.3.1. Weshalb aufräumen?
7.3.2. Kommandos zum Aufräumen
7.3.3. Empfehlungen zum Zeitpunkt des Aufräumens
7.3.4. Automatisch und regelmäßig Aufräumen
8. Paketoperationen
8.1. Paketoperationen und deren Abfolge
8.2. Paketlisten und Muster
8.3. Bekannte Paketnamen auflisten
8.4. Paketstatus erfragen
8.4.1. dpkg -s Paketname und dlocate -s Paketname
8.4.2. dpkg -I deb-Datei
8.4.3. apt-cache show Paketname
8.4.4. apt-cache showpkg Paketname
8.4.5. aptitude show Paketname
8.4.6. Anfragen mit apt-mark
8.5. Liste der installierten Pakete anzeigen und deuten
8.5.1. dpkg -l Paketname (Langform --list)
8.5.2. aptitude search ~i
8.5.3. Weitere Möglichkeiten
8.6. Liste der installierten Kernelpakete anzeigen
8.7. Liste der installierten, nicht-freien Pakete anzeigen
8.8. Neue Pakete anzeigen
8.9. Pakete nach Prioritäten finden
8.10. Automatisch installierte Pakete anzeigen
8.10.1. apt-mark benutzen
8.10.2. aptitude benutzen
8.11. Obsolete Pakete anzeigen
8.11.1. Recherche auf der Kommandozeile
8.11.2. Recherche in graphischen Programmen
8.11.3. Umgang mit diesen Paketen
8.12. Aktualisierbare Pakete anzeigen
8.13. Installationsgröße eines Pakets
8.14. Größtes installiertes Paket finden
8.14.1. dpigs
8.14.2. aptitude
8.15. Warum ist ein Paket installiert
8.16. Liste der zuletzt installierten Pakete anzeigen
8.16.1. Statusdaten von dpkg
8.16.2. Statusdaten von apt
8.17. Paketabhängigkeiten anzeigen
8.17.1. Die Abhängigkeiten eines Pakets auflisten
8.17.2. Anzeige der umgekehrten Paketabhängigkeiten
8.17.3. Prüfen, ob die Abhängigkeiten des gesamten Systems erfüllt sind
8.17.4. Zusammenfassung aller unerfüllten Abhängigkeiten im Paketcache
8.18. Aus welchem Repo kommen die Pakete
8.18.1. Paketquelle untersuchen mit apt-cache policy
8.18.2. Verfügbare Paketversionen mit apt-cache madison ermitteln
8.18.3. Verfügbare Paketversionen mit apt-show-versions ermitteln
8.18.4. APT 1.0 mit dem Unterkommando list
8.18.5. Aktualisierbare Pakete mit aptitude ermitteln
8.19. Pakete über den Namen finden
8.19.1. Systemwerkzeuge
8.19.2. Browserbasierte Suche
8.20. Pakete über die Paketbeschreibung finden
8.21. Paket nach Maintainer finden
8.21.1. Welche Pakete betreut ein Debian-Maintainer
8.21.2. Rückrichtung: Wer betreut ein bestimmtes Paket
8.22. Paket zu Datei finden
8.22.1. Suche in bereits installierten Paketen
8.22.2. Suche in noch nicht installierten Paketen
8.22.3. Suche über die Webseite des Debian-Projekts
8.23. Paketinhalte anzeigen (apt-file)
8.23.1. dpkg -L Paketname
8.23.2. dlocate -L Paketname
8.23.3. dlocate -ls Paketname
8.23.4. dpkg -c deb-Datei
8.23.5. apt-file show Paketname und apt-file list Paketname
8.23.6. Einsatz von dglob
8.24. Nach Muster in einem Paket suchen
8.25. Ausführbare Dateien anzeigen
8.26. Manpages anzeigen
8.26.1. Manpages erstöbern
8.26.2. Manpages aus noch nicht installierten Paketen anzeigen
8.27. Konfigurationsdateien eines Pakets anzeigen
8.28. Paketänderungen nachlesen
8.29. Paket auf Veränderungen prüfen
8.29.1. MD5-Summen zur Erkennung von Änderungen
8.29.2. Dateien paketbezogen mit dlocate überprüfen
8.29.3. Dateien überprüfen mit debsums
8.29.4. Dateien mit dpkg -V überprüfen
8.30. Liste der zuletzt geänderten Abhängigkeiten
8.31. Paketdatei nur herunterladen
8.32. Installation zwischengespeicherter Pakete aus dem Paketcache
8.33. Sourcepakete beziehen
8.34. Sourcepakete anzeigen
8.35. Bezogenes Paket verifizieren (GPG-Key)
8.35.1. Basis
8.35.2. Nur ein Einzelpaket prüfen
8.35.3. Alle bereits installierten Pakete und Dateien prüfen
8.36. Pakete installieren
8.36.1. Vorbereitungen
8.36.2. Durchführung
8.36.3. Begutachtung
8.36.4. Weitere, nützliche APT-Optionen für den Alltag (Auswahl)
8.36.5. Besonderheiten bei aptitude
8.36.6. Erweiterungen ab APT 1.1
8.37. Pakete erneut installieren
8.37.1. Wiederinstallieren vollständig entfernter Pakete
8.37.2. Wiederinstallieren von Paketen mit vorhandenen Konfigurationsdateien
8.37.3. Wiederinstallieren bereits installierter Pakete
8.37.4. Typische Stolperfallen bei Wiederinstallieren mehrerer Pakete
8.38. Pakete konfigurieren
8.38.1. Bestehende Konfiguration eines Pakets anzeigen
8.38.2. Konfiguration für alle Pakete auslesen
8.38.3. Bestehende Konfiguration anwenden
8.38.4. Konfiguration mit dpkg-reconfigure erneut durchführen
8.39. Pakete aktualisieren
8.39.1. update
8.39.2. upgrade und safe-upgrade
8.39.3. dist-upgrade und full-upgrade
8.39.4. Empfohlene Schrittfolge zur Aktualisierung von Paketen
8.39.5. Aktualisierung mit Synaptic
8.40. Pakete downgraden
8.40.1. Hintergrund und Fragen zum Downgrade
8.40.2. Ablauf und Durchführung
8.41. Pakete deinstallieren
8.41.1. Fall 1: Paket einfach löschen
8.41.2. Fall 2: Suche von Konfigurationsdateien bereits deinstallierter Pakete
8.41.3. Fall 3: Löschen von Konfigurationsdateien bereits deinstallierter Pakete
8.41.4. Fall 4: Paket samt Konfigurationsdateien deinstallieren
8.42. Umgang mit Waisen
8.42.1. APT und aptitude
8.42.2. debfoster
8.42.3. deborphan
8.42.4. Orphaner und Editkeep
8.42.5. gtkorphan
8.42.6. aptsh
8.42.7. wajig
8.43. Paketoperationen erzwingen
8.44. Paketstatusdatenbank reparieren
8.44.1. Bit-Dreher reparieren
8.44.2. Die Paketstatusdatenbank aus dem lokalen Backup wiederherstellen
8.44.3. Die Paketstatusdatenbanken von APT und aptitude
8.45. Distribution aktualisieren (update und upgrade)
8.45.1. Vorworte
8.45.2. Vom upgrade zum dist-upgrade
8.45.3. Unsere empfohlene Reihenfolge
8.45.4. Anmerkungen
9. Dokumentation
9.1. Die apt-dpkg-Referenzliste
9.2. apt-doc — das Benutzerhandbuch zu APT
9.3. APT-Spickzettel von Nixcraft
9.4. Pacman Rosetta
9.5. Handbuch zu aptitude
9.6. The Debian Administrator’s Handbook
9.7. Weitere Bücher
III. Praxis
10. APT und aptitude auf die eigenen Bedürfnisse anpassen
10.1. Konfigurationsdateien von APT
10.1.1. Verhalten von APT und Hooks: /etc/apt/apt.conf(.d)
10.1.2. Konfigurationsdateien von Aptitude
10.1.3. APT-Hooks
10.1.4. cron.daily/apt
10.2. Konfiguration von APT anzeigen
10.3. Interaktives Ändern von Optionen
10.4. aptitude Format Strings
10.5. Für aptitude die Ausgabebreite festlegen
10.6. Bei aptitude die Ausgabe sortieren
10.7. aptitude-Gruppierung
10.7.1. Kommandozeile
10.7.2. Textoberfläche
10.8. aptitude-Farbschema anpassen
10.8.1. Standardvorgaben
10.8.2. Zwischen aptitude-Themes wechseln
10.8.3. Eigene Farben vergeben
11. Mit aptitude Vormerkungen machen
11.1. Vormerkungen über die Kommandozeile durchführen
11.2. Vormerkungen über die Textoberfläche durchführen
11.3. Bestehende Vormerkungen anzeigen
11.4. Vormerkungen simulieren
11.5. Vormerkungen wieder aufheben
11.6. Vormerkungen ausführen
11.7. Risiken und Seiteneffekte
12. APT und aptitude mischen
12.1. Hintergrund
12.2. Sollten Sie das überhaupt machen?
12.3. Was ist zu beachten, wenn Sie das machen
12.4. Empfehlungen für Dokumentation und Beispiele
13. Erweiterte Paketklassifikation mit Debtags
13.1. Einführung
13.2. Kurzinfo zum Debtags-Projekt
13.3. Webseite zum Projekt
13.4. Debtags-Werkzeuge
13.5. Vergebene Schlagworte anzeigen
13.5.1. Auf der Kommandozeile
13.5.2. Integration in aptitude
13.5.3. Graphische Programme
13.5.4. Über den Webbrowser
13.6. Suche anhand der Schlagworte
13.6.1. Über die Kommandozeile
13.6.2. Textoberfläche von aptitude
13.6.3. Graphische Programme
13.6.4. Suche über den Webbrowser
13.7. Pakete um Schlagworte ergänzen
13.8. Verwendetes Vokabular bearbeiten und erweitern
13.8.1. Alle verfügbaren Schlagworte anzeigen
13.8.2. Informationen zu Schlagworten anzeigen
13.8.3. Schlagworte bearbeiten
14. Mehrere Pakete in einem Schritt ändern
14.1. Mit apt-get
14.2. aptitude
15. Ausgewählte Pakete aktualisieren
15.1. Nur ein einzelnes Paket aktualisieren
15.1.1. Auf der Kommandozeile
15.1.2. Über die Textoberfläche von aptitude
15.1.3. Durchführung bei Synaptic
15.2. Aktualisierung mit Wechsel der Veröffentlichung
16. Ausgewählte Pakete nicht aktualisieren
16.1. Auf der Kommandozeile
16.2. Textoberflächen
16.3. Graphische Programme
17. Fehlende Pakete bei Bedarf hinzufügen
17.1. Neue Hardware
17.2. Neue Software
17.2.1. Installation bei Bedarf mittels auto-apt
17.2.2. Empfehlungen mittels command-not-found und apprecommender
18. Alternative Standard-Programme mit Debians Alternativen-System
18.1. Hintergrund: Warum alternative Standardprogramme?
18.2. Standardprogramme anzeigen
18.3. Standardprogramm ändern
19. Backports
19.1. Ausgangssituation
19.2. Gegenüberstellung der verschiedenen Lösungsansätze
19.3. Debian Backports
19.4. Welche Pakete gibt es als offiziellen Backport?
19.5. Welche Versionen gibt es als offizielle Backports?
19.6. Einbindung in den Paketbestand
19.7. Die installierten Pakete anzeigen
19.8. Weiterführende Dokumentation
19.9. Backports bei Ubuntu
19.10. Wichtige Fragen, die sich bei Backports ergeben
20. Veröffentlichungen mischen
20.1. Die bevorzugte Veröffentlichung für alle Pakete festlegen
20.2. apt-get mit expliziter Angabe der Veröffentlichung
20.3. Von APT zu APT-Pinning
20.4. Paketweise festlegen
20.5. Praktische Beispiele
21. Pakete bauen mit checkinstall
21.1. Pakete aus zusätzlichen Quellen ergänzen
21.2. Software selbst übersetzen und einspielen
21.3. Software selbst übersetzen und als deb-Paket einspielen
21.4. Beispiel
21.5. Vor- und Nachteile
21.5.1. Weitere noch unbearbeitete Notizen
22. Paketformate mischen
22.1. Einführung
22.2. Fremdformate mit alien hinzufügen
22.2.1. Einführung
22.2.2. Pakete umwandeln
22.2.3. Pakete umwandeln und einspielen
22.2.4. Umgewandelte Pakete einspielen
22.2.5. deb-Pakete in rpm-Strukturen
23. Umgang mit LTS
23.1. Kurzzeitiges Abschalten
23.2. Dauerhaftes Abschalten
24. Webbasierte Installation von Paketen mit apturl
24.1. Sinn und Zweck
24.2. Risiken und Bedenken
24.3. apturl in der Praxis
25. Paketverwaltung beschleunigen
25.1. Hintergrund
25.2. Möglichkeiten zur Beschleunigung
25.3. Empfehlungen zum Umgang im Alltag
26. Einen APT-Cache einrichten
26.1. Begriff
26.2. approx
26.3. apt-cacher
26.4. apt-cacher-ng
26.5. debtorrent
27. Cache-Verzeichnis auf separater Partition
27.1. Paketarchiv als tmpfs-Partition
27.2. Paketcache als separate Partition einrichten
27.3. Cache-Verzeichnis als Unterverzeichnis auf anderer Partition
28. Einen eigenen APT-Mirror aufsetzen
28.1. apt-mirror
28.1.1. Wichtige Dateien aus dem Paket
28.1.2. Ablauf
28.1.3. Beispiel/HowTo
28.1.4. Hinweise
28.2. debmirror
28.3. debpartial-mirror
28.4. ubumirror
28.5. reprepro
29. Plattenplatz sparen mit der Paketverwaltung
30. Automatisierte Installation
30.1. FAI
30.2. Kickstart
30.3. Erfahrungen aus der Praxis
31. Automatisierte Aktualisierung
31.1. apt-dater
32. Qualitätskontrolle
32.1. Nicht installierte Pakete mit lintian prüfen
32.1.1. lintian verstehen
32.1.2. lintian verwenden
32.2. Bereits installierte Pakete mit adequate prüfen
32.3. Bugreports anzeigen
32.3.1. Hintergrundwissen
32.3.2. Bugreports mit apt-listbugs lesen
32.3.3. Ergänzende Bugreports mit apt-listchanges herausfiltern
32.3.4. Release-kritische Fehler mit popbugs finden
32.3.5. Release-kritische Fehler mit rc-alert finden
32.3.6. Welche der von mir genutzten Pakete benötigen Hilfe?
32.4. Auslaufende Sicherheitsaktualisierungen mit check-support-status anzeigen
33. Versionierte Paketverwaltung
34. Pakete und Patche datumsbezogen auswählen
35. Paketkonfiguration sichern
35.1. apt-clone
36. Paketverwaltung mit eingeschränkten Ressourcen für Embedded und Mobile Devices
36.1. localepurge
37. Paketverwaltung ohne Internet
37.1. Hintergrund und Einsatzfelder
37.2. Strategien
37.2.1. Benötigte Pakete vorher explizit herunterladen
37.2.2. Einbindung fester Installationsmedien
37.2.3. Einbindung eines lokalen Paketmirrors
37.3. Werkzeuge
37.3.1. Offline-Verwaltung mit apt-get und wget
37.3.2. Das Projekt apt-offline
37.3.3. apt-zip
37.3.4. Pakete mit dpkg-split aufteilen
37.3.5. aptoncd
38. Systeme mit schlechter Internet-Anbindung warten
38.1. debdelta
38.2. PDiffs
39. Der APT- und aptitude-Wunschzettel
IV. Ausblick
40. Notizen
41. Pakete selber bauen
42. Ein eigenes Debian-Repository aufbauen
43. Zukunft von APT, dpkg und Freunden
44. Fazit / Zusammenfassung
44.1. Empfehlungen für Einsteiger
44.1.1. Mit welchem Programm zur Paketverwaltung soll ich anfangen?
A. Bibliography
V. Anhang
45. Debian-Architekturen
45.1. Offizielle Architekturen
45.2. Veraltete Architekturen
45.3. Architekturen, deren Unterstützung vorgesehen ist
46. Kommandos zur Paketverwaltung im Vergleich
46.1. Zusammenfassung
46.2. Paket installieren
46.3. Paket aktualisieren
46.4. Paket löschen / entfernen
46.5. Alle installierten Pakete auflisten
46.6. Einzelpaket auflisten
46.7. Abhängigkeiten anzeigen
46.8. Alle Dateien eines installierten Pakets anzeigen
46.9. Paket identifizieren, aus dem eine Datei stammt
46.10. Paketstatus anzeigen
46.11. Aktualisierbare Pakete anzeigen
46.12. Verfügbare Pakete anzeigen
46.13. Paketsignatur überprüfen
46.14. Paket auf Veränderungen prüfen
46.15. Transaktionshistorie anzeigen
47. Paketformat im Einsatz
47.1. Embedded-Geräte
47.2. Bildung
47.3. Desktop
47.4. Live-CD
47.5. Minimalsysteme
47.6. Spieleplattform
47.7. Mobile Architekturen
47.8. Anstatt Linux
47.9. Nachbauten und Derivate
47.10. Weitere Debian-Derivate
Stichwortverzeichnis

Abbildungsverzeichnis

1. Orte, an denen das vorliegende Buch entstand
2.1. Schichtenmodell zur deb-basierten Paketverwaltung
2.2. Paketabhängigkeiten von APT
2.3. Paketabhängigkeiten von dpkg
2.4. Paketabhängigkeiten von aptitude und APT
2.5. Inhalt des Pakets x-display-manager in Aptitude
2.6. Auflistung der verschiedenen Paketkategorien in aptitude
2.7. Paketliste mit Skype als unfreies Paket in Aptitude
2.8. Beschreibung der Filmserie Toy Story im Disney Wiki
2.9. Erfasster Verbreitungsgrad für das Paket nginx
2.10. Vergleich Installationen und Nutzung der Pakete screen und tmux
2.11. Ausgabe der Paketmarkierungen in der Textoberfläche von aptitude
3.1. /etc/apt/sources.list im Texteditor nano
3.2. Auswahl der Paketmirror für Linux Mint
3.3. Standortlokalisierung über das GeoIP Tool [geoiptool]
3.4. Auswahl des Paketmirrors über den Debian Redirector [Debian-Redirector]
3.5. Auswahl der Paketquellen über apt-setup
3.6. Einstellung der Komponenten in Synaptic
3.7. Festlegung der Paketquellen für andere Software im Ubuntu Software Center
3.8. Auswahl der Komponenten im Debian Sources List Generator
3.9. Erzeugte sources.list durch den Debian Sources List Generator
3.10. Auswahl der Komponenten im Ubuntu Sources List Generator
3.11. Auflistung der gespeicherten, vertrauenswürdigen Schlüssel
3.12. Darstellung der Fingerabdrücke der vertrauenswürdigen Schlüssel
3.13. Hauptfenster von gui-apt-key
3.14. curses-apt-key in einem xterm
3.15. Auflistung der verfügbaren Paketquellen in SmartPM
3.16. Status der verschiedenen Debian-Paketmirror
4.1. Auszug aus dem postinst-Skript zum Paket dpkg-www
4.2. Detailinformationen zum Paket debsums (deb-gview)
4.3. Detailinformationen zum Paket debsums (Synaptic)
4.4. Detailinformationen zum Paket debsums in apt-browse.org (Ausschnitt)
6.1. aptsh mit der Ausgabe der umgekehrten Paketabhängigkeiten mit rdepends
6.2. wajig mit der Ausgabe des Kommandos listfiles
6.3. Softwareauswahl in tasksel
6.4. package dependency solver in aptitude
6.5. Softwareauswahl in synaptic
6.6. Farbige Markierungen der Pakete gemäß ihrem Installationsstatus (Synaptic)
6.7. Allgemeine Paketeigenschaften für das Paket ding (Synaptic)
6.8. Paketauswahl einer ganzen Aufgabengruppe (Synaptic)
6.9. Softwareauswahl in muon
6.10. Softwareauswahl in smartpm
6.11. Softwareauswahl im Ubuntu Software Center (aus Xubuntu 13.04)
6.12. Verlauf der Änderungen im Paketbestand
6.13. Gnome Packagekit mit ausgewähltem Paket dctrl-tools
6.14. gdebi mit den Informationen zum Paket apt-doc
6.15. gdebi-gtk mit den Informationen zum Paket zsh
6.16. Rollback eines ausgewählten Pakets
6.17. Vorauswahl für Appnr im Webbrowser Iceweasel
6.18. Verfügbare Bündel auf der Webseite
6.19. Univention App Centre
7.1. Großreinemachen mit Hilfe von Synaptic
8.1. Ausgabe der Statusinformationen zum Paket htop mittels aptitude
8.2. Icons zur Darstellung des Paketstatus
8.3. Ansicht der automatisch installierten Pakete in aptitude
8.4. Ansicht der obsoleten Pakete in Synaptic
8.5. Ansicht der aktualisierbaren Pakete in Synaptic
8.6. Darstellung der umgekehrten Paketabhängigkeiten mit dotty
8.7. Ergebnis der Limitierung nach xpdf über die Aptitude-TUI
8.8. Ergebnis der Suche nach dem Fragment fce in Synaptic
8.9. Ergebnis der Suche nach dem Fragment top in SmartPM
8.10. Auswahl der Hilfeseiten zum Menüpunkt Netzwerkkommunikation
8.11. Auswahl der Hilfeseiten zu Synaptic
8.12. Ergebnis der Paketsuche nach iftop über https://packages.debian.org/
8.13. Ergebnis der Paketsuche nach aptsh über http://packages.ubuntu.com/
8.14. Ergebnis der Paketsuche nach kdm über http://packages.linuxmint.com/
8.15. Ergebnis der Paketsuche nach htop über https://apt-browse.org/
8.16. Auswahl der Paketmirror für bei apt-get.org
8.17. Suchergebnis der Recherche bei apt-get.org
8.18. Ergebnis der Paketsuche nach htop über http://www.rpmseek.com/
8.19. Recherche nach Paketen mittels ara
8.20. Ergebnis der Suche nach dem Paketmaintainer in Synaptic
8.21. Suche nach xara-gtk über die Webseite
8.22. Suche nach dem Paket xara-gtk über die Webseite des Debian-Projekts (Suchergebnis)
8.23. Suche in der Manpages-Sammlung nach htop
8.24. Bezug des Pakets bash-doc über den Webbrowser
8.25. Informationen zu einem ausgewählten Schlüssel in gui-apt-key anzeigen
8.26. Ausgabe einer deutlichen Warnung bei aptitude
8.27. Konfiguration des Pakets debconf
8.28. Konfiguration des Pakets tzdata und regionale Auswahl
8.29. Das Debian-Paketarchiv
8.30. Suchergebnis nach dem Paket openvpn im Paketarchiv
8.31. Nicht verwendete Pakete automatisch entfernen in aptitude
8.32. orphaner bei der Arbeit
8.33. editkeep im Einsatz
8.34. gtkorphan bei der Arbeit
8.35. aptsh mit der Ausgabe des Kommandos orphans
8.36. aptsh mit der Ausgabe des Kommandos orphans-all
8.37. wajig mit der Ausgabe des Kommandos orphans
9.1. Die apt-dpkg-Referenzliste im PDF-Betrachter xpdf
9.2. Ausschnitt aus der APT-Dokumentation mit apt-doc
9.3. Spickzettel zu apt-get
9.4. Die Pacman Rosetta (Ausschnitt)
9.5. Dokumentation zu aptitude
9.6. Cover des Buches
11.1. Paketoperationen anzeigen, die zur Ausführung anstehen
11.2. Vormerkungen abbrechen
13.1. Suche nach Spielen anhand von Debtags
13.2. Debian Tags zum Paket xara-gtk
13.3. Darstellung der Schlagworte zum Paket xpdf in aptitude
13.4. Darstellung der Schlagworte zum Paket xara-gtk in Xara
13.5. Auswahl des Debtags-Browsers in aptitude
13.6. PackageSearch im Einsatz
13.7. Xara im Einsatz
13.8. Suche anhand der Debtags über den Webbrowser
13.9. Auswahl der Pakete anhand der Debtags Cloud
13.10. Webseite zum Debtags-Projekt mit den Informationen zum Paket gimp
13.11. debtags-edit im Einsatz
13.12. Informationen zur Facette protocol::pop3
16.1. Setzen des Paketflags hold in Synaptic
18.1. Auswahl mit Hilfe des Programms galternatives
32.1. Ausgabe der Paketvalidierung mittels lintian zum Paket mp4h
32.2. Auflistung der bekannten, kritischen Fehler nach der Analyse von popbugs
32.3. Auflistung der Paket ohne zukünftige Sicherheitsaktualisierungen nach der Analyse von debian-security-support
37.1. aptoncd im Einsatz

Tabellenverzeichnis

2.1. Übersicht zu Paketformaten und deren Verbreitung
2.2. Übersicht zu Containerformaten und deren Verbreitung
2.3. Paketierung der Komponenten am Beispiel von APT
4.1. Relationen für versionierte Abhängigkeiten
6.1. Frontends zur Paketverwaltung
6.2. Farben und deren Bedeutung bei aptitude
6.3. Tasten bei aptitude
6.4. Tasten zur interaktiven Konfliktlösung bei aptitude
8.1. Paketzustand deuten
8.2. Alltägliche Kombinationen zum Paketzustand
10.1. Format Strings in aptitude
11.1. Tastenkombination für Vormerkungen in aptitude
14.1. Zusätzliche Optionen für den Aufruf bei aptitude
20.1. Verwendete Prioritäten beim APT-Pinning
20.2. Zulässige Parameter beim APT-Pinning
21.1. Schalter für die verschiedenen unterstützten Paketformate
21.2. Spezifische Schalter für ein Debian-Binärpaket
32.1. Klassifikation der lintian-Fehlermeldungen
46.1. Installation eines Pakets
46.2. Aktualisieren eines Pakets
46.3. Entfernen eines Pakets
46.4. Softwarepakete auflisten
46.5. Einzelnes Softwarepaket auflisten
46.6. Paketabhängigkeiten anzeigen
46.7. Paketinhalte anzeigen
46.8. Paket zu Datei finden
46.9. Paketstatus erfragen
46.10. Aktualisierbare Pakete anzeigen
46.11. Verfügbare Pakete anzeigen
46.12. Paketsignatur überprüfen
46.13. Paket auf Veränderungen prüfen
46.14. Transaktionshistorie anzeigen

Über dieses Buch

1. Kann Paketmanagement Spaß machen?

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

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

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

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

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

  • Es funktioniert verlässlich.
  • Es ist ausführlich und meist auch verständlich dokumentiert. Leider ist die Dokumentation aber nicht ganz einheitlich und recht verstreut – weshalb nicht zuletzt auch dieses Buch entstanden ist.
  • Pakete für Debian GNU/Linux sind aufeinander abgestimmt, wurden vorab intensiv getestet und unterliegen strengen Qualitätskontrollen.
  • Pakete für Debian GNU/Linux werden nach ihrer Veröffentlichung (Release) bzw. ihrem Entwicklungszweig kategorisiert: oldoldstable, oldstable, stable, testing, unstable oder experimental. Ein Paket für Debian GNU/Linux kann in mehreren dieser Zweige parallel vorliegen und unterscheidet sich nur in seinem jeweiligen „Reifegrad“. Als Benutzer wissen Sie daher genau, worauf Sie sich einlassen, wenn Sie einen bestimmten Entwicklungsstand benutzen (falls nicht, lesen Sie in Abschnitt 2.10, „Veröffentlichungen“ nach). Das Debian-Derivat namens Ubuntu handhabt das etwas anders: Es unterscheidet nur zwischen mehreren stabilen Veröffentlichungen und dem Entwicklungszweig. Im Rahmen einer halbjährlichen Freigabe wird aus dem Entwicklungszweig die nachfolgende, stabile Veröffentlichung.
  • Kein Stress mit Lizenzen. Es ist klar geregelt, welche Bedingungen ein Paket erfüllen muss, damit es überhaupt in den offiziellen Bestand von Debian GNU/Linux unter den Distributionsbereich main Eingang findet. Alle anderen Pakete werden in die Bereiche contrib oder non-free einsortiert. Ubuntu kennt kein Äquivalent zu contrib und verwendet statt non-free die beiden Bereiche restricted und multiverse (siehe Abschnitt 2.9, „Distributionsbereiche“).
  • Die beiden Debian-Entwicklungszweige unstable und testing (siehe Abschnitt 2.10, „Veröffentlichungen“) wie auch der Bereich Debian Backports (siehe Kapitel 19, Backports) bekommen regelmäßig neue Pakete, die das Paketverwaltungswerkzeug aptitude (siehe Abschnitt 6.3.2, „aptitude) in einer eigenen Liste übersichtlich darstellt. Das ist fast wie Weihnachten, nur günstiger und häufiger.

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

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

2. Zum Buch

2.1. Über die Autoren

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

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

2.2. Wie und warum dieses Buch entstand

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

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

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

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

2.3. Motivation

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

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

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

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

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

2.4. Technische Basis

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

Versionsverwaltung mit Git

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

2.5. Quellcode und Lizenz

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

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

2.6. Organisatorisch

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

Viele Texte verfassen wir zudem von unterwegs aus. Die bisherigen Stationen umfassen Ålesund (Norwegen), Andorra, Augsburg, Beauvais (Picardie), Bergneustadt, Berlin, Besançon, Biel, Bottighofen (Bodensee, Schweiz), Bratland (bei Bergen, Norwegen), Bruchsal, Cudrefin, Chemnitz, Delémont, Essen, Frankfurt/Main, Freiburg im Breisgau, Friedrichshafen, Genf, Germersheim, Goizueta (Baskenland, Spanien), Hamburg, Heidelberg, Hout Bay (Western Cape, Südafrika), Kapstadt, Koblenz, Lauchringen (Baden, Wutachtal), Lausanne, Meersburg, Montpellier, München, Orø (Dänemark), Port del Cantó (Katalanische Pyrenäen, Spanien), Radebeul bei Dresden, Rømø (Dänemark), Rostock-Warnemünde, Saint Cergue (Jura, Schweiz), Saint-Jouin-Bruneval (Normandie), Insel Sokn (bei Stavanger, Norwegen), Tübingen, Tvinnefossen (Norwegen), Zernez (Engadin) und Zürich (siehe Abbildung 1, „Orte, an denen das vorliegende Buch entstand“). 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.

Abbildung 1. Orte, an denen das vorliegende Buch entstand

kann-denn-paketmanagement-spass-machen/zum-buch/buchkarte.png

2.7. Grundlagenwissen für Administratoren

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

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

Material für Ihre LPIC-Prüfungen

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

Dokumentation zu aptitude

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

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

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

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

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

2.8. Dokumentation deb vs. rpm

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

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

Ein vergleichbares Buch zur Debian-basierten Paketverwaltung fehlte bislang. Viele hervorragende Kompendien (siehe dazu Abschnitt 9.7, „Weitere Bücher“) 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.

2.9. Was ist das Buch – und was nicht …

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

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

Unser Buch ist kein allgemeines Linux-Einsteiger-Buch in der Geschmacksrichtung „Debian GNU/Linux“, sondern widmet sich mit der Paketverwaltung bei Debian-Systemen einem speziellen Teilaspekt der Systembetreuung. Folglich spielen andere Paketformate als deb allenfalls eine Nebenrolle (siehe Abschnitt 2.2, „Varianten und Formate für Softwarepakete“). Andere Debian-Derivate (siehe Abschnitt 1.5, „Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement“) 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.

2.10. Zielgruppe und Lernziele

Dieses Buch richtet sich in erster Linie an Systemadministratoren und „Gehäusedeckelabschrauber“[2]. 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.

2.11. Vorkenntnisse

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

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

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

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

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

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

Sie müssen auf Ihrem System über administrative Benutzerrechte verfügen, um manche Beispiele nachvollziehen zu können. Wir weisen nicht jedes Mal explizit darauf hin[3]. In den Beispielen für die Kommandozeile erkennen Sie anhand des Prompt-Zeichens, ob administrative Rechte notwendig sind oder nicht (# falls ja, und $, falls nicht). Auf Ausnahmen weisen wir Sie an der betreffenden Stelle explizit hin.

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

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

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

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

  • Debian-Pakete sauber verwalten
  • kleinere und mittlere Debian-basierte Infrastrukturen pflegen
  • die richtigen Werkzeuge für die Pflege benutzen und mit der Paketverwaltung sowie den Werkzeugen effektiv umgehen
  • nicht nur die Software verwenden, sondern auch wissen, warum etwas funktioniert
  • Pakete und Software nach Wunschkriterien finden
  • alternative Auflösungen für Paketabhängigkeiten finden, verstehen und anwenden

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

2.13. Buchinfo

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!

3. Danksagung

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

  • Elmar Heeb (für aptitude-robot und viele interessante Diskussionen)
  • Dirk Deimeke (für Tipps zum Autor-Werden) [Hackerfunk]
  • Arne Wichmann (für das Diagramm der Vertrauenskette in Debian – unter GPL)
  • Annette Kalbow (für inhaltliche Vorschläge mit apt-file, dpkg -l und dpkg -L sowie die graphische Umsetzung der Landkarte)
  • Mechtilde Stehmann (für die Sprachkorrekturen und die Vorschläge für die FAQ)
  • Marco Uhl (für die Idee zum FAQ-Eintrag über Debian Snapshots [Debian-Snapshots] bei Testing- vs. Produktiv-Umgebung)
  • Werner Heuser (für die Installation und den Umgang auf Embedded und Mobile Devices)
  • Claude Becker (für Ideen und Korrekturlesen rund um das Parsen von Debian-Versionsnummern und APT-Pinning)
  • Christoph Berg (für Tipps und Tricks rund um reprepro und seine Erfahrungen mit apt.postgresql.org) [APT-Repo-PostgreSQL]
  • Dr. Thomas Fricke (für Ergänzungen rund um die Verteilung von Paketen auf mehrere Maschinen)
  • Jens Wilke (Konfigurationsmanagement)
  • Martin Schütte (reprepro)
  • Michael Vogt (für Erklärungen rund um APTs mirror:// Methode und gdebi)
  • David Kalnischkies (für viele Detailerklärungen – z.B. zur Parameterverarbeitung von apt-get – und die endlosen Diskussionen darüber, die dennoch meist irgendwann in Erleuchtung endeten)
  • Albrecht Barthel (für die vielen Infos und Einblicke zum Univention Corporate Server, UCS)
  • Martin Venty Ebnöther (für ein weiteres paar Augen und Ohren zum Thema Paketmanagement)
  • Dr. Markus Wirtz für die lange Unterstützung und Hilfe, das Buch auf seinen Weg zu bringen, für den Klappentext sowie fürs Lektorat der Einleitung und dem erstem Kapitel.
  • Oliver Rath für seine Vorschläge zur besseren Lesbarkeit von Programmcode
  • Karsten Merker für viele kleine Korrekturen
  • Wolfram Schneider für den Hinweis zu dh-make-perl als spezialisierte Variante von checkinstall sowie zum Aktualisieren von LTS-Versionen (siehe Kapitel 23, Umgang mit LTS)
  • Jörg Brühe für die Anregungen zu den Paketabhängigkeiten
  • Sebastian Andres für seine Anregungen zu Debian Backports

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



[1] Jörg, bitte nicht böse sein!

[2] Dieter Thalmayr in: Oberflächliches – Enlightenment als Alternative zu Gnome und KDE, Vortrag im Rahmen des 11. Linux-Infotages Augsburg, 24. März 2012

[3] Sie erlangen diese je nach Konfiguration Ihres Systems über die Kommandos su oder sudo – oder indem Sie sich als Benutzer root auf Ihrem System anmelden.

Teil I. Konzepte

Kapitel 1. Willkommen im Linux-Dschungel!

1.1. Was ist Debian?

Je nach Kontext bezeichnet „Debian“ entweder

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

oder

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

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

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

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

Debian stellt dafür ein ausgereiftes, stabiles und zuverlässiges Betriebssystem inklusive aller Software dar. Es ist ein Betriebssystem, das die Debian-Entwickler selbst benutzen wollen[4]. Daher unterstützt Debian viele verschiedene Architekturen und ermöglicht eine einheitliche Administration auf verschiedensten Plattformen (siehe Abschnitt 1.2, „Debian-Architekturen“). Ausführliches Testen und das Bereinigen von Fehlern hat Vorrang vor brandaktueller Software.

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

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

1.2. Debian-Architekturen

Debian kommt mit den unterschiedlichsten Hardware-Architekturen zurecht. Die offizielle Liste der aktuell unterstützten Architekturen finden Sie auf der Debian-Webseite [Debian-Architekturen] sowie im Anhang dieses Buches (siehe Abschnitt 45.1, „Offizielle Architekturen“). Neben den veralteten Architekturen (siehe Abschnitt 45.2, „Veraltete Architekturen“) werfen wir auch einen Blick in die Zukunft (siehe Abschnitt 45.3, „Architekturen, deren Unterstützung vorgesehen ist“).

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

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

Architekturen, die das Werkzeug dpkg unterstützt (Ausschnitt). 

$ dpkg-architecture -L
uclibc-linux-armel
uclibc-linux-alpha
uclibc-linux-amd64
m68k
sparc
sparc64
...
$

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

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

Perl-Aufruf zur Ermittlung der GNU-Triplets einer Debian-Architektur. 

$ perl \
    -MDpkg::Arch=debarch_to_gnutriplet \
    -E 'map { say "$_ = ".debarch_to_gnutriplet($_) } @ARGV' \
    ppc64 powerpcspe arm armel armhf

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

1.2.1. Debian-Ports-Projekt

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

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

1.2.2. Pakete für alle Architekturen

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

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

Auswahl der installierten, architektur-unabhängigen Pakete. 

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

1.2.3. Multiarch: Mehrere Architekturen gleichzeitig auf einem System

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

  • Systeme, auf denen Sie Pakete unterschiedlicher Architekturen nebeneinander benutzen können.
  • Architekturspezifische Pakete, die explizit auf mehreren Architekturen installierbar sind.

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

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

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

  • Systeme, die gemischte Prozessorbefehle unterstützen – entweder als Emulation in Hardware oder per Software. Dazu gehören z.B. i386/ia64 mittels Hardware-Emulation und arm/jede Plattform (via Qemu Userland-Emulation).
  • gemischte Betriebssystemumgebungen. Darunter fallen die Verwendung und Ausführung von Binärcode anderer Plattformen über eine Kompatibilitätsebene. Beispiele dafür sind Linux/i386 auf FreeBSD/i386 und Solaris/sparc auf Linux/sparc.
  • Cross-Kompilieren. Darunter fällt das Übersetzen von Programmcode für eine andere Zielplattform.

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

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

1.2.4. Bevor es Multiarch gab

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

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

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

1.3. Vom tar.gz zur Linux-Distribution

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

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

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

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

1.4. Debians Paketsystem

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

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

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

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

Heute stehen weitere textbasierte und graphische Benutzeroberflächen für dpkg zur Verfügung. Neben aptitude sind das Synaptic (siehe Abschnitt 6.4.1, „Synaptic“), PackageKit (siehe Abschnitt 6.4.5, „PackageKit“) – als Basis für Gnome-PackageKit und Apper bei KDE – sowie Muon (siehe Abschnitt 6.4.2, „Muon“), PackageSearch (siehe Abschnitt 13.4, „Debtags-Werkzeuge“), Xara [Debian-Paket-xara-gtk] und SmartPM (siehe Abschnitt 6.4.3, „Smart Package Management (SmartPM)“). Einen genaueren Blick werfen wir auf diese Programme in Kapitel 6, Werkzeuge zur Paketverwaltung (Überblick).

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

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

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



[4] „The project consists of a group of people who are working together to create something that, primarily, we all want to use“ [Allbery-Debian-Popularity]

Kapitel 2. Software in Paketen organisieren

2.1. Was ist Paketmanagement

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

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

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

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

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

Im Detail erklären wir Ihnen die Thematik unter Pakete aktualisieren (siehe Abschnitt 8.39, „Pakete aktualisieren“), Distribution aktualisieren (siehe Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“), Paket downgraden (siehe Abschnitt 8.40, „Pakete downgraden“) und dem Debian Backports Archiv (siehe Kapitel 19, Backports).

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

Ausgabe aller derzeit installierten Pakete für Abiword mit dpkg

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

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

Auflistung der Paketdetails zum Paket abiword-common mittels apt-cache

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


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

2.2. Varianten und Formate für Softwarepakete

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

Tabelle 2.1. Übersicht zu Paketformaten und deren Verbreitung

Abkürzung Format in Verwendung Distribution

deb

Debian-Paketformat

seit 1993

Debian, Ubuntu, Grml, Knoppix, Linux Mint …

rpm

Redhat Package Manager

seit 1995

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

apk

Android-Paketformat

seit 2003

Android

ipkg

Itsy Package Management System, Vorbild deb

2001 bis 2006

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

opkg

OpenMoko Package Management System, ipkg-Fork

seit 2006

OpenMoko, OpenWrt, OpenZaurus, OpenEmbedded

pkg.tar.gz

Pacman

seit 2002

Arch Linux

tar.gz, tar.xz

mit gzip bzw. xz komprimiertes tar-Archiv

seit 1993 (2009)

Slackware


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

Tabelle 2.2. Übersicht zu Containerformaten und deren Verbreitung

Abkürzung Format in Verwendung Distribution

Docker

Containerformat

seit 2014

Debian, Ubuntu, RedHat/Fedora

Flatpack

Containerformat

seit 2015

RedHat/Fedora, Ubuntu

OpenContainer

Containerformat

seit 2015

Virtualisierer

Snappy

Containerformat

seit 2015

Ubuntu


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

2.3. Softwarestapel und Ebenen

2.3.1. Ebenen

Die Paketverwaltung kann man leicht in zwei Ebenen aufteilen. Dabei wird jede Ebene durch eine Reihe von Programmen und Bibliotheken repräsentiert (siehe Abbildung 2.1, „Schichtenmodell zur deb-basierten Paketverwaltung“).

Abbildung 2.1. Schichtenmodell zur deb-basierten Paketverwaltung

konzepte/software-in-paketen-organisieren/werkzeugebenen-2.png

2.3.2. Untere Ebene

Die Basis bildet dpkg. Dessen Aufgabe ist es a) ein bereits lokal vorliegendes deb-Paket auszupacken und auf dem System einzuspielen und b) die Inhalte eines bereits installierten deb-Pakets wieder aus dem System zu entfernen. Ersteres entspricht dabei dem Kommandozeilenaufruf dpkg -i Paketdatei, das zweite hingegen dpkg -r Paketdatei (siehe Abschnitt 8.36, „Pakete installieren“ und Abschnitt 8.41, „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 Abschnitt 8.23, „Paketinhalte anzeigen (apt-file)“) sowie -l zur Auflistung der installierten Pakete (siehe Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“), -s zum Erfragen des Paketstaus (siehe Abschnitt 8.4, „Paketstatus erfragen“) und -S, um das Paket zu finden, in dem eine bestimmte Datei vorkommt (siehe Abschnitt 8.22, „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.

Paketverwaltung bei anderen Linux-Distributionen

Das Analogon zu dpkg bei rpm-basierten Distributionen ist rpm, bei Arch Linux ist es Pacman und bei Gentoo erreichen Sie die Funktionalität durch die beiden Programme emerge und equery. Eine komplette Übersicht zu den verschiedenen Programmen finden Sie einerseits in der Pacman-Rosetta (siehe Abschnitt 9.4, „Pacman Rosetta“) sowie in unserer Übersicht im Anhang des Buches (siehe Kapitel 46, Kommandos zur Paketverwaltung im Vergleich).

2.3.3. Obere Ebene

Bei deb-basierten Distributionen besteht die obere Ebene typischerweise aus dem Werkzeug APT (siehe Abschnitt 6.2.2, „APT“). Häufig ist mindestens eines der weiteren Programme wie aptitude (siehe Abschnitt 6.3.2, „aptitude), Synaptic (siehe Abschnitt 6.4.1, „Synaptic“), Ubuntu Software Center (siehe Abschnitt 6.4.4, „Ubuntu Software Center“), Muon (siehe Abschnitt 6.4.2, „Muon“) oder auch PackageKit (siehe Abschnitt 6.4.5, „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 Kapitel 5, APT und Bibliotheken) und andererseits auf die Werkzeuge aus der unteren Ebene, d.h. vor allem auf dpkg. Es übernimmt die eigentliche Installation, Entfernung oder Aktualisierung (siehe untere Ebene). Sichtbar wird dies insbesondere, wenn Sie ein Paket mit apt-get oder aptitude installieren. Einen Teil der Ausgaben auf dem Terminal steuern dpkg und die o.g. Bibliotheken bei.

2.3.4. Paketformate und -werkzeuge anderer Distributionen

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

2.3.5. Werkzeuge, die verschiedene Paketformate unterstützen

Darüber hinaus gibt es Programme, die mit mehreren unterschiedlichen Paketformaten umgehen können. Dazu zählen Muon (siehe Abschnitt 6.4.2, „Muon“), der Smart Package Manager (SmartPM) (siehe Abschnitt 6.4.3, „Smart Package Management (SmartPM)“) und PackageKit (siehe Abschnitt 6.4.5, „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 Abschnitt 6.1, „Frontends für das Paketmanagement“.

2.4. Alternativen zu APT

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

Alternative Benutzerschnittstellen
Hierzu zählen u.a. die im Buch vorgestellten Programme aptitude, Muon, Synaptic und wajig (siehe Abschnitt 6.3.2, „aptitude, Abschnitt 6.4.2, „Muon“, Abschnitt 6.4.1, „Synaptic“ und Abschnitt 6.2.4, „wajig). Diese setzen auf den APT-Bibliotheken auf und sind nur Alternativen zu den Kommandozeilentools apt-get und apt-cache, nicht aber zu APT als Ganzes.
Vorgänger
Bevor es APT gab und an Popularität gewann, wurden Paketlisten und Pakete mit dselect heruntergeladen (Recherchen ergaben etwa das Jahr 1998). dselect ist Bestandteil des dpkg-Projekts und wird heute noch aus den Quellen von dpkg gebaut. Allerdings benutzt es für viele Funktionalitäten mittlerweile ebenfalls APT als Backend, insbesondere für das Herunterladen von Paketen. dselect hat heute keine Relevanz mehr (liegt quasi im Wachkoma) und wird daher im Buch nicht weiter besprochen.
Potentielle Nachfolger
APT ist nicht mehr ganz jung, und es wurden in der Vergangenheit Design-Entscheidungen getroffen, welche aus heutiger Sicht eher als weniger gelungen gelten, sich aber nicht mehr oder zumindest nur mit sehr viel Aufwand korrigieren lassen. Eugene V. Lyubimkin war einer der APT-Entwickler und hat sich aus o.g. Grund aus der APT-Entwicklung zurückgezogen und eine Re-Implementierung von APT namens Cupt [Debian-Wiki-cupt] geschrieben (siehe Abschnitt 6.2.5, „Cupt“).

2.5. Zusammenspiel von dpkg und APT

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

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

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

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

Abbildung 2.2. Paketabhängigkeiten von APT

konzepte/software-in-paketen-organisieren/apt.png

Abbildung 2.3. Paketabhängigkeiten von dpkg

konzepte/software-in-paketen-organisieren/dpkg.png

Abbildung 2.4. Paketabhängigkeiten von aptitude und APT

konzepte/software-in-paketen-organisieren/aptitude+apt.png

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

Erzeugung der Abhängigkeitsgraphen zu dpkg mittels debtree

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

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

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

Erzeugung der Abhängigkeitsgraphen und Speicherung als Rastergrafik. 

$ debtree dpkg | dot -Tpng > dpkg.png
$

2.6. Vom monolithischen Programm zu Programmkomponenten

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

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

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

Tabelle 2.3. Paketierung der Komponenten am Beispiel von APT

Paketname Paketkategorie Komponente und Bedeutung

apt

Administration (admin)

Paketmanager für die Kommandozeile (siehe Abschnitt 6.2.2, „APT“)

apt-doc

Dokumentation (doc)

Dokumentation zum Paket apt

apt-transport-https

Administration (admin)

APT-Plugin für HTTPS-Support

apt-utils

Administration (admin)

Hilfsprogramme für APT

libapt-inst

Bibliotheken (libs)

Laufzeitbibliothek zum Paketformat

libapt-pkg

Bibliotheken (libs)

Laufzeitbibliothek zur Paketverwaltung

libapt-pkg-dev

Bibliotheken zur Entwicklung (libdevel)

Entwicklerdateien zu libapt-pkg

libapt-pkg-doc

Dokumentation (doc)

Dokumentation zur Laufzeitbibliothek libapt-pkg

libapt-pkg-perl

Bibliotheken (libs)

Laufzeitbibliothek zur Paketverwaltung, Perl-Schnittstelle


Benennung eines Debianpakets und Paketkategorien

In Abschnitt 2.11, „Benennung einer Paketdatei“ beleuchten wir die Benennung und Abfolge der Komponenten in den Paketnamen. Eine genaue Auflistung und zur Bedeutung der Paketkategorien lesen Sie in Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“ nach.

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

2.7. Debian-Pakete (Varianten)

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

Darüberhinaus gibt es aber auch noch andere Paketarten in Debian. Das wichtigste davon sind die Sourcepakete (siehe Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“), die den Quellcode enthalten, aus dem später eines oder mehrere Binärpakete (siehe Abschnitt 2.7.1, „Binärpakete (deb)“) gebaut werden.

2.7.1. Binärpakete (deb)

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

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

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

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

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

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

2.7.2. Übergangspakete, Metapakete und Tasks

Es gibt ein paar besondere Varianten von Binärpaketen – Übergangspakete und Metapakete. Vom Aufbau her unterscheiden sich diese nicht von normalen Binärpaketen, aber vom Inhalt.

Übergangspakete und Metapakete sind reguläre Binärpakete, die jedoch im Normalfall keine eigenen Programme, Daten oder ähnliches beinhalten. Stattdessen liefern diese Abhängigkeiten auf andere Pakete.

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

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

  • gitgnuit und dann später git-coregit
  • chromiumchromium-bsu und dann später chromium-browserchromium
  • diffdiffutils
  • ttf-mplusfonts-mplus

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

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

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

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

2.7.3. Mikro-Binärpakete

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

Aufbau und Format von Übergangs- und Metapaketen

Mehr Informationen zum Aufbau dieser Pakete finden Sie unter „Aufbau und Format von Übergangs- und Metapaketen“ in Abschnitt 4.2.4, „Übergangs- und Metapakete“.

2.7.4. Source-Pakete (dsc und weitere Dateien)

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

  • der Originalquellcode als ein oder mehrere komprimierte tar-Archive. Je nach verwendetem Komprimierungsverfahren lauten die Dateiendungen orig.tar.gz, orig.tar.bz2 oder orig.tar.xz.
  • die Änderungen vom Original zum Debianpaket als komprimierter Patch. Diese Dateien haben klassisch die Endung diff.gz und wurden mit gzip gepackt. Liegen die Änderungen wie bei moderneren Sourcepaketen als komprimiertes tar-Archiv vor, wird als Dateiendung debian.tar.gz oder debian.tar.xz genutzt. Bei Letzterem kommt anstatt von gzip das Komprimierungswerkzeug xz zum Einsatz.
  • eine Datei mit den Metadaten (Größe, Hashsummen, etc.) über die vorher genannten Dateien. Genutzt wird die Dateiendung dsc als Abkürzung für Debian Source Control.

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

Auspacken von Debian-Source-Paketen

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

2.7.5. Virtuelle Pakete

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

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

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

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

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

konzepte/software-in-paketen-organisieren/aptitude-virtuelle-pakete.png

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

2.7.6. Pseudopakete im Debian Bug Tracking System

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

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

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

Fehler zu einem Paket anzeigen

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

2.8. Sortierung der Pakete nach Verwendungszweck

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

Abbildung 2.6, „Auflistung der verschiedenen Paketkategorien in aptitude zeigt die Sichtbarkeit der Kategorien bei der Paketauswahl in aptitude. In jeder Kategorie sind die Pakete zusätzlich nach ihrem Distributionsbereich (siehe Abschnitt 2.9, „Distributionsbereiche“) – main, contrib und non-free – gruppiert. Der jeweilige Entwicklungszweig (siehe Abschnitt 2.10, „Veröffentlichungen“) – bspw. stable, unstable oder testing – wird in dieser Darstellung nicht angezeigt, lässt sich aber bei Bedarf als weitere Ebene in der Anzeigehierarchie konfigurieren.

Abbildung 2.6. Auflistung der verschiedenen Paketkategorien in aptitude

konzepte/software-in-paketen-organisieren/aptitude-paketbereiche.png

Nachfolgende Übersicht listet die derzeit verwendeten Kategorien mit Beispielpaketen auf. Der Begriff in Klammern benennt die Kurzbezeichnung der Kategorie. Diese Zusammenstellung basiert auf Frank Ronneburgs Auflistung aus dem Debiananwenderhandbuch [Debian-Anwenderhandbuch] sowie der Übersicht auf der Debian-Webseite [Debian-Paketliste]. Die Kategorien introspection, Debian/tasks, education und metapackages sind derzeit noch nicht in allen Übersichten eingepflegt. Die einzige Referenz hierfür ist das Debian Policy Manual [Debian-Policy-Subsections].

Administration (admin)
Programme zur Systemadministration (dpkg, apt, aptitude, adduser)
Alte Bibliotheken und Übergangspakete (oldlibs)
Versionen von Bibliotheken, die nicht mehr verwendet werden sollten sowie Übergangspakete (gcalctool, iproute, libgnome2-0)
Amateurfunk/Ham Radio (hamradio)
Software für Amateurfunker (ax25-tools, hamfax)
Andere Betriebs- und Dateisysteme (otherosfs)
Software, um Programme zu benutzen, die für andere Betriebssysteme kompiliert wurden und um die Dateisysteme anderer Betriebssysteme zu benutzen (avr-libc, bochs, cpmtools, dosemu, fatsort)
Aufgaben (Debian/tasks)
Pakete, die Ihren Rechner für eine bestimmte Aufgabe vorbereiten (siehe Abschnitt 2.7, „Debian-Pakete (Varianten)“) (task-german-desktop, task-xfce-desktop)
Bibliotheken (libs)
Programmbibliotheken (Libraries) (libc6, e2fslibs)
Bildung (education)
Lern- und Schulprogramme (auto-multiple-choice, gcompris, scratch)
Datenbanken (database)
Datenbankserver und -clients (sqlite, mysql-server, mongodb)
Debug-Pakete (debug)
Pakete, die Debug-Informationen für Programme und Laufzeitbibliotheken bereitstellen (cups-dbg, evolution-data-server-dbg)
Dienstprogramme (utils)
verschiedene Werkzeuge (clamav, coreutils, debian-goodies)
Dokumentation (doc)
HOWTOs, FAQs und andere Dokumentation sowie Programme, um diese zu lesen (aptitude-doc-en, debian-faq, debian-handbook, zsh-doc)
Editoren (editors)
Textverarbeitungsprogramme, Editoren für Programmierer und Entwickler (abiword, emacs, kate, vim)
Elektronik (electronics)
Programme zur Entwicklung und Simulation elektronischer Schaltungen (arduino, verilog)
Embedded (embedded)
Software, die für die Benutzung in oder mit Embedded Systemen geeignet ist (gpe, matchbox, usbprog, urjtag)
Entwicklung (devel)
Entwicklungswerkzeuge und -umgebungen, Compiler, usw. (automake, binutils, g++)
Entwicklungsbibliotheken (libdevel)
Header-Dateien zu Bibliotheken (libc6-dev, okular-dev, zathura-dev)
E-Mail (mail)
alles rund um E-Mail; Mailserver, Mailprogramme, Spamfilter, etc. (postfix, mutt, spamassassin)
GNOME (gnome)
Programme zur GNOME-Desktop-Umgebung (etherape, evince, gnome-control-center, gnome-media)
GNU R (gnu-r)
Programme um die freie Implementierung der Statistik-Sprache R (r-base, r-mathlib)
GNUstep (gnustep)
Programme zur GNUstep-Umgebung (gnustep, gnustep-icons)
Grafik (graphics)
Programme zur Bildbearbeitung (dia, epub-utils, giftrans, gimp)
Haskell (haskell)
alles rund um die Programmiersprache Haskell (haskell-platform, happy)
GObject Introspection (introspection)
GObject Introspection Middleware, Schnittstellen zwischen GObject-C-Bibliotheken und anderen Programmiersprachen [GObject-Introspection] (gir1.2-ebook-1.2)
Interpreter (interpreters)
Interpretierte Programmiersprachen wie bspw. Tcl/Tk (luajit, m4, tcl)
Java (java)
alles rund um die Programmiersprache Java (ant, tomcat8, openjdk-7-jre)
KDE (kde)
Programme zum KDE-Desktop (apper, kdm, knotes)
Kernel (kernel)
Betriebssystem-Kernel und zugehörige Module und Programme (dkms, firmware-atheros, firmware-linux, kernel-package, linux-image-amd64)
Klang (sound)
alles für den guten Ton (alsa-utils, audacious, playmidi, xmms2)
Kommunikation (comm)
Kommunikationsprogramme für externe Schnittstellen, Modems und Telefonanlagen (cu, asterisk, hylafax-server, wvdial)
Lisp (lisp)
alles zur Programmiersprache Lisp und Dialekten davon (lush, mit-scheme, picolisp)
Mathematik (math)
mathematische und wissenschaftliche Programme (bc, concalc, euler, freemath)
Metapakete (metapackages)
Paketgruppen (siehe Abschnitt 2.7, „Debian-Pakete (Varianten)“) (games-finest, gnome, kde-full, gis-devel)
Mono/CLI (cli-mono)
alles rund um die C#-Implementierung Mono und die Common Language Infrastructure (monodoc-browser)
Netzwerk (net)
Netzwerkserver und Clientprogramme, Programme zur Netzwerkkonfiguration (bind9, centerim, debmirror, isc-dhcp-client)
Usenet News (news)
Software für Usenet-Newsgruppen (slrn, nget, tin)
OCaml (ocaml)
alles zur Programmiersprache OCaml (cameleon, libcurl-ocaml, ocamlwc)
Perl (perl)
alles zur Programmiersprache Perl, CPAN-Module (libaudio-file-perl, perl, perl-doc)
PHP (php)
alles zur Programmiersprache PHP (icinga-web, php5)
Python (python)
alles zur Programmiersprache Python (python3, idle)
Ruby (ruby)
alles zur Programmiersprache Ruby (ruby, ruby-xmmsclient)
Schriften (fonts)
Schriften und Programme zum Verarbeiten von Schriften (fontforge, fontconfig, xfonts-cyrillic)
Shells (shells)
verschiedene Shells (bash, fish, zsh)
Spiele (games)
Spiele und Unterhaltung (freeciv-server, gcompris, openttd)
Sprachpakete (localization)
Lokalisierungsunterstützung für große Softwarepakete (iceweasel-l10n-all, kde-l10n-es, libreoffice-l10n-ar)
TeX (tex)
alles zum Schriftsatzsystem TeX, inkl. LaTeX und XeTeX (dvi2ps, biblatex, gummi)
Textverarbeitung (text)
Werkzeuge zum Umgang mit Textdateien (a2ps, xpdf, wordnet, wogerman)
udeb-Pakete des Debian-Installers (debian-installer)
spezielle Pakete zur Verwendung im Debian-Installer, siehe Abschnitt 2.7.3, „Mikro-Binärpakete“ (archdetect, cdrom-detect)
Verschiedenes (misc)
Diverses, was sonst nirgends hineinpasst (bochsbios, cpuburn, screen)
Versionskontrollsysteme (vcs)
Versionskontrollsysteme und zugehörige Hilfswerkzeuge (bzr, cvs, git)
Video (video)
Videobetrachter, -editoren, -rekorder, -sender (dvb-apps, dvbstream, gnome-mplayer, mpv)
Web (web)
Webbrowser, Download-Tools, HTML-Editoren, usw. (bluefish, iceweasel)
Webserver (httpd)
Webserver und ihre Module (apache2, nginx, lighttpd, libapache2-mod-perl2, libapache2-mod-php5)
Wissenschaft (science)
Programme zum wissenschaftlichen Arbeiten (celestia, garlic)
X Window (x11)
X-Server, Window-Manager und Anderes (xterm, xsensors, xorg-xserver)
XFCE (xfce)
Programme zum XFCE-Desktop (thunar, xfwm4, xfwm4-themes)
Zope/Plone (zope)
alles rund um das Zope-Framework (zope-common, zope2.13)

Erweiterung um Debtags

Das Kategorienkonzept hat eine Reihe von Limitierungen, insbesondere die Einordnung eines Pakets in nur eine einzige Kategorie. Um diese Grenzen aufzuheben, gibt es das Debtags-Projekt, welches jedes Paket um passende Schlagworte ergänzt. Dieses Konzept und die dazugehörigen Werkzeuge stehen unter „Erweiterte Paketklassifikation mit Debtags“ (siehe Kapitel 13, Erweiterte Paketklassifikation mit Debtags) im Mittelpunkt.

2.9. Distributionsbereiche

Die verschiedenen Distributionsbereiche ordnen die einzelnen Pakete anhand ihrer Lizenzen. Das hilft Ihnen dabei, die Kontrolle über die verwendeten Lizenzen auf Ihrem System zu behalten. Mit der Auswahl von Paketen aus bestimmten Distributionsbereichen legen Sie somit den „Freiheitsgrad“ Ihrer Installation fest.

In Debian sind die Softwarepakete in die folgenden drei Bereiche unterteilt:

main
Freie Software, die den Debian-Richtlinien für freie Software (DFSG) entspricht.
contrib
Freie Software, die von unfreier Software abhängt.
non-free
Software, die nicht den Debian-Richtlinien für freie Software (DFSG) entspricht, aber frei verteilbar ist.

2.9.1. Einordnung der Distributionsbereiche in Debian

Obwohl vielfach von außen anders wahrgenommen, zählt zur Debian-Distribution nur der Bereich main. Die anderen beiden 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 beiden anderen Bereiche contrib und/oder non-free 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:

  • Eine freie Spiele-Engine braucht die Spieldaten eines kommerziellen Spiels.
  • Ein Emulator braucht Software für die zu emulierende Hardware, um zu funktionieren.
  • Die Software ist nur zum Herunterladen (und ggf. installieren und/oder paketieren) von nicht-freier Software da.
  • Die Software muss mit einem nicht-freien Compiler übersetzt werden.

Im Bereich non-free 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 im Bereich non-free sind:

  • Der Quellcode liegt nicht (komplett) vor.
  • Die Software oder einzelne Teile davon – z.B. Teile der Dokumentation – dürfen nicht modifiziert werden.
  • Die Software darf nur für nicht-kommerzielle Zwecke genutzt werden.
  • Die Software darf nur für „Gutes“ verwendet werden.
  • Die Software darf nicht in kompilierter Form verteilt werden.

Vor der Nutzung von Software aus diesem Bereich 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 dem Bereich non-free 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.

Abbildung 2.7, „Paketliste mit Skype als unfreies Paket in Aptitude“ 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.

Abbildung 2.7. Paketliste mit Skype als unfreies Paket in Aptitude

konzepte/software-in-paketen-organisieren/aptitude-unfreie-pakete.png

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

2.9.2. Einordnung der Distributionsbereiche bei anderen Distributionen

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 Kapitel 47, Paketformat im Einsatz) oder nicht-offizielle Paketquellen (siehe „Paketquellen“ in Abschnitt 3.1, „Paketquellen“) können ebenfalls ihre eigenen Distributionsbereiche haben. Auf diese gehen wir hier nicht weiter ein.

2.9.3. Handhabung von geschützten Namen und Logos

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 steht an, dass ab Debian 9 Stretch Firefox und Thunderbird wieder zu Debian zurückkehren und Iceweasel und Icedove aufgegeben werden.

2.9.4. Softwareverteilung

Bezogen auf die Anzahl der verfügbaren Softwarepakete findet sich der überwiegende Teil der Pakete im Bereich main, danach folgen contrib und non-free. 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.

2.9.5. Hintergrund der Einteilung in Distributionsbereiche

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.

2.10. Veröffentlichungen

Debian GNU/Linux wird in verschiedenen Veröffentlichungen angeboten, die jeweils als „Releases“ bezeichnet werden. Eine solche Veröffentlichung kann wie folgt referenziert werden:

2.10.1. Bedeutung der verschiedenen Entwicklungsstände

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

unstable
Hier findet die aktive Entwicklung von Debian statt. Neue Pakete und Versionen landen fast immer zuerst hier. Dieser Entwicklungszustand kann inkonsistent sein und beispielsweise unerfüllte Abhängigkeiten beinhalten. Er ist primär für Entwickler gedacht.
testing
Pakete, die in unstable für eine gewisse Zeit keine schwerwiegenden Fehler aufweisen und deren Abhängigkeiten bereits ebenfalls in testing erfüllt werden können, wandern automatisch von unstable hierher. Dieser Entwicklungsstand sollte konsistent sein und alle Paketabhängigkeiten erfüllt sein.
stable
Das ist die jeweils aktuelle stabile Veröffentlichung. Dieser Entwicklungsstand ist für die normale Nutzung von Debian empfohlen. Eine neue stabile Veröffentlichung wird ca. alle zwei Jahre auf Basis von testing erstellt. Pakete werden nur aktualisiert, um sicherheitskritische oder sonstige schwerwiegende Fehler zu beheben. Dabei werden (mit sehr wenigen Ausnahmen) ausschließlich die entsprechenden Fehler durch Patches behoben, anstatt neuere Versionen der Programme auszuliefern.
oldstable

Das ist die jeweils vorherige stabile Veröffentlichung. Bevor eine neue stabile Veröffentlichung freigegeben wird, erfolgt eine Umbenennung der aktuellen stabilen Veröffentlichung in oldstable. Diese wird von da an im Normalfall noch für ein Jahr weiter gepflegt und mit Sicherheitsaktualisierungen versehen.

Im Frühjahr 2014 wurden zusätzlich sogenannte Long Term Support-Varianten – kurz LTS – eingeführt, die den Zeitraum der weiteren Verfügbarkeit und Pflege auf bis zu fünf Jahre verlängern. In Folge wird die im Jahr 2011 freigegebene und 2013 durch Debian 7 Wheezy abgelöste Veröffentlichung von Debian 6 Squeeze bis 2016 mit Aktualisierungen versorgt.

oldoldstable
Wenn vorhanden, ist dies die jeweils vorvorherige stabile Veröffentlichung. Zum ersten Mal trat dieser Entwicklungsstand auf, als im Frühjahr 2015 Debian 8 Jessie zur stabilen Veröffentlichung erklärt wurde. Gleichzeitig wurde Debian 6 Squeeze zur neuen Suite oldoldstable und wird per Long Term Support (LTS) weiterhin noch eingeschränkt unterstützt.
experimental
Dies ist der einzige Entwicklungsstand, der keine alleinstehende Veröffentlichung ist, sondern nur ein Zusatz-Repository. Es fungiert als Erweiterung zu unstable und beinhaltet Pakete, bei denen der Paketbetreuer davon ausgeht, dass sie noch und ggf. sogar grobe Fehler beinhalten. experimental wird genutzt, um Pakete im größeren Umfeld zu testen, bevor diese nach unstable hochgeladen werden.

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 Kapitel 19, Backports ein.

2.10.2. Alias-Namen

Jede Veröffentlichung von Debian GNU/Linux hat einen Alias-Namen, der nach einer Figur aus Pixars Filmreihe Toy Story benannt ist. Für die bisherigen Veröffentlichungen standen die folgenden Figuren aus dem Film Pate:

  • Debian 1.0 wurde nie offiziell veröffentlicht.
  • Debian 1.1 Buzz (17. Juni 1996; benannt nach Buzz Lightyear, dem Astronauten)
  • Debian 1.2 Rex (12. Dezember 1996; benannt nach dem Plastikdinosaurier)
  • Debian 1.3 Bo (5. Juni 1997; benannt nach Bo Peep, der Schäferin)
  • Debian 2.0 Hamm (24. Juli 1998; benannt nach dem Sparschwein)
  • Debian 2.1 Slink (9. März 1999; benannt nach dem Hund Slinky Dog)
  • Debian 2.2 Potato (15. August 2000; benannt nach der Puppe Mr. Potato Head)
  • Debian 3.0 Woody (19. Juli 2002; benannt nach dem Cowboy Woody Pride, der Hauptfigur der Filme)
  • Debian 3.1 Sarge (6. Juni 2005; benannt nach dem Feldwebel der grünen Plastiksoldaten)
  • Debian 4.0 Etch (8. April 2007; benannt nach der Zeichentafel Etch-A-Sketch)
  • Debian 5.0 Lenny (Februar 2009; benannt nach dem aufziehbaren Fernglas)
  • Debian 6.0 Squeeze (Februar 2011; benannt nach den grünen dreiäugigen Aliens)
  • Debian 7 Wheezy (Mai 2013; benannt nach Wheezy the Penguin, dem Gummi-Spielzeugpinguin mit der roten Fliege)
  • Debian 8 Jessie (25. April 2015; benannt nach der jodelnden Kuhhirtinnen-Puppe Jessica Jane „Jessie“ Pride)
  • Debian 9 Stretch (noch kein Veröffentlichungstermin zum Zeitpunkt der Drucklegung festgelegt, voraussichtlich 2017; benannt nach dem lila Kraken)
  • Debian 10 Buster (noch kein Veröffentlichungstermin zum Zeitpunkt der Drucklegung festgelegt, voraussichtlich 2019; benannt nach dem Welpen aus Toy Story 2)

Mehr Details zu den einzelnen Veröffentlichungen finden sich in der Debian-Historie [Debian-History]. Die Figuren aus Toy Story und insbesondere deren Charakterzüge sind ausführlich im Disney Wiki [ToyStory] dokumentiert (siehe Abbildung 2.8, „Beschreibung der Filmserie Toy Story im Disney Wiki“).

Abbildung 2.8. Beschreibung der Filmserie Toy Story im Disney Wiki

konzepte/software-in-paketen-organisieren/toystory.png

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.

2.10.3. Zusammenhang von Alias-Namen und Entwicklungsständen

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äßt sich sinngemäß als „in dieser Form ungeeignet zur Aufnahme in eine Veröffentlichung“ übersetzen.

2.10.4. Pakete auf Wanderschaft von einem Entwicklungsstand in den nächsten

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:

  • Die Version des Pakets in unstable führt keine neuen veröffentlichungskritischen Fehler in testing ein.
  • Alle notwendigen Abhängigkeiten des Pakets sind in testing verfügbar oder werden gleichzeitig nach testing migriert.
  • Es darf keine Abhängigkeiten von Paketen zerstören, die bereits in testing enthalten sind und damit deren Installation verhindern.
  • Das Paket hat ein Mindestalter an Tagen erreicht. Dieses Mindestalter hängt vom Wert des Felds urgency (engl. für Dringlichkeit) im aktuellen Changelog-Eintrag ab und beträgt entweder 10, 5 oder 2 Tage. Die Dringlichkeit wird dabei vom Paketmaintainer entschieden. Bei Korrekturen von sicherheitsrelevanten Fehlern ist es durchaus üblich, dass die Dringlichkeit auf „hoch“ gesetzt wird und damit nur 2 Tage beträgt.
  • Das Paket muss auf allen Architekturen, auf denen es gebaut wird, in der aktuellsten Version verfügbar sein.
  • Das Paket muss auf allen Architekturen bereitstehen, auf denen es vorher bereits gebaut wurde. Für Ausnahmen muss zuerst das alte Paket aus dem Archiv manuell entfernt werden.

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:

  • Die bisherige Veröffentlichung stable wird zu oldstable. Sie behält dabei ihren Alias-Namen bei.
  • Eine Kopie des aktuellen Zweigs testing wird zum neuen Zweig stable. Der Alias-Name zieht mit um.
  • testing bekommt einen neuen Alias-Namen.
  • Der Freeze wird aufgehoben und die Pakete propagieren wieder automatisch von unstable nach testing.

2.10.5. Organisation der Pakete im Paketpool

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 Abschnitt 8.18, „Aus welchem Repo kommen die Pakete“) genauer.

2.11. Benennung einer Paketdatei

Während der Benutzung von dpkg, APT oder aptitude sind Sie sicher schon mit den etwas langen und auf den ersten Blick kurios anmutenden Dateinamen der einzelnen Pakete in Berührung gekommen. Die Benennung einer Paketdatei folgt einem ausgeklügelten Schema [Krafft-Debian-System144]. Dieses Schema ist eine Konvention, die leider bei Paketen aus Drittquellen oft nicht eingehalten wird.

Der Dateinamen besteht aus den drei Felder Paketname, Version und Architektur, welche durch einen Unterstrich _ voneinander abgegrenzt werden, plus einem Punkt und der Dateiendung .deb. Gemäß den Debian-Richtlinien [Debian-Policy-Manual] sind in o.g. Feldern nur ASCII-Zeichen zulässig. Unterstriche, Leerzeichen und Umlaute sind nicht gestattet. Das hilft dabei, Missverständnissen vorzubeugen und die Paketenamen mit allen Zeichensätzen anzeigen zu können.

2.11.1. Paketname

Feld 1 bezeichnet den Namen des Pakets, welche 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.

2.11.2. Versionsnummer

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 Abschnitt 6.4.3, „Smart Package Management (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.

+nmu<n>
Non-Maintainer-Upload (NMU) eines nativen Pakets. Das bezeichnet eine Paketversion, die nicht vom Verantwortlichen (Maintainer) des Pakets stammt. Bspw. bezeichnet die Datei adduser_3.113+nmu3_all.deb das Paket adduser als dritten Non-Maintainer-Upload basierend auf der Version 3.113 des Maintainers.
-<x>.<y>
Debian-Revisionsnummer eines Non-Maintainer-Upload (NMU) eines nicht-nativen Pakets. Dabei bezeichnet <x> die letzte Revision des Maintainers (oder 0, falls es keine solche gab) und <y> die Nummer des NMU basierend auf dieser Revision des Maintainers. So ist z.B. die Datei bash_4.2+dfsg-0.1_i386.deb das Debianpaket bash als Non-Maintainer-Upload einer neuen Upstreamversion basierend auf der Veröffentlichung 4.2. Hingegen bezeichnet die Angabe 4.2-2.1 den ersten Non-Maintainer-Upload, welcher auf der Basis der Maintainer-Version 4.2-2 erstellt wurde.
+b<n>
Kennzeichnung eines Binären Non-Maintainer-Uploads (BinNMU). Das bezeichnet eine Übersetzung des Pakets ohne vorherige Änderung des Quellcodes. Das tritt bspw. dann auf, wenn sich die Abhängigkeiten zum Bauen des Pakets geändert haben (sogenannte build-dependencies). Die Angabe 123-4+b2 steht dabei für den zweiten Erstellungsdurchlauf des Pakets aus den Quellen der Version 123-4. Ubuntu verwendet dafür stattdessen die Syntax 123-4build2.
~bpo<x>+<y>
Backports (siehe Kapitel 19, Backports) bezeichnen eine Rückportierung einer neueren Version auf die aktuelle Veröffentlichung. Dabei steht das Kürzel bpo für backports.org, dem Namen des Backports-Projektes, bevor es in Debian integriert wurde. Die Angabe 123-3~bpo8+2 steht bspw. für eine Rückportierung der Upstream-Version 123-3 auf Debian 8 Jessie. Die Ziffer 2 deklariert das Paket die zweite Backports-Revision des Paket.
+deb<x>u<y>
stabiles Update. Die Angabe 121-3+deb7u2 steht für das zweite stabile Update des Pakets mit der Version 121-3 in Debian 7 Wheezy (<x>=7 und <y>=2).
ubuntu<n>
ein Debianpaket, welches für Ubuntu angepaßt wurde. <n> bezeichnet die Ubuntu-Revisionsnummer, so bspw. 121-3ubuntu4 für die vierte Ubuntu-Revision des Debian-Pakets mit der Versionsnummer 121-3.

2.11.3. Architektur oder Plattform

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 Abschnitt 1.2, „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.

2.12. Multiarch einsetzen

dpkg führt eine Liste mit allen Architekturen, für die es Pakete installiert bzw. installieren darf. Diese Liste befindet sich in der Datei /var/lib/dpkg/arch und existiert allerdings nur, sofern Sie zuvor auch Fremdarchitekturen ergänzt haben. Das nachfolgende Beispiel stammt von einem System mit amd64 als Basisarchitektur und i386 als Fremdarchitektur.

Inhalt der Liste der Architekturen. 

$ cat /var/lib/dpkg/arch
amd64
i386
$

Die erste Architektur in dieser Datei ist die Basisarchitektur. Diese geben Sie mit der dpkg-Option --print-architecture aus. Früher bzw. bei älteren dpkg-Versionen heißt die Option --print-installation-architecture. Die Fremdarchitekturen zeigen Sie mit dpkg --print-foreign-architectures an.

Über die beiden dpkg-Optionen --add-architecture und --remove-architecture erweitern bzw. reduzieren Sie die Liste entsprechend. Beim Aufruf geben Sie dazu jeweils noch die gewünschte Architektur als Parameter an, bspw. dpkg --add-architecture i386, wenn Sie zusätzlich die Architektur für 32-Bit-PCs nutzen wollen, weil es die von Ihnen gewünschte Software nur für 32-Bit-Systeme gibt.

Während des Vorgangs schreibt dpkg diese Änderung zuerst in eine temporäre Datei namens /var/lib/dpkg/arch-new. Wurden alle anderen Änderungen erfolgreich vorgenommen, benennt dpkg diese Datei in /var/lib/dpkg/arch um.

Installation von Paketen für fremde Architekturen

Bitte berücksichtigen Sie bei Ihrer Softwareplanung, dass nicht jedes Paket für alle Plattformen verfügbar ist. Wenn es verfügbar ist und Sie es erfolgreich auf Ihrem System installieren konnten, heißt das nicht automatisch, dass es auch auf Ihrer Architektur funktioniert, sondern nur, dass die Paketverwaltung alle benannten Paketabhängigkeiten erfüllen konnte.

Löschen einer Fremdarchitektur

Das Entfernen einer Fremdarchitektur gelingt Ihnen nur dann, wenn keine Pakete (mehr) für diese Architektur auf Ihrem System installiert sind. Wie Sie Pakete architekturbezogen deinstallieren, lesen Sie in Abschnitt 8.41, „Pakete deinstallieren“ nach.

2.12.1. Multiarch-Beispiel: Installieren eines 32-Bit-Pakets auf einem 64-Bit-System

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.

Hinzufügen einer weiteren genutzten Paketarchitektur mittels dpkg

# dpkg --print-architecture
amd64
# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
#

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.

Aktualisieren der Paketlisten. 

# apt-get update
Ign http://ftp.ch.debian.org jessie InRelease
Hit http://ftp.ch.debian.org jessie Release.gpg
Hit http://ftp.ch.debian.org jessie Release
Hit http://ftp.ch.debian.org jessie/main amd64 Packages
Get:1 http://ftp.ch.debian.org jessie/main i386 Packages [6769 kB]
Hit http://ftp.ch.debian.org jessie/main Translation-en
Fetched 6769 kB in 6s (1005 kB/s)
Reading package lists... Done

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 Abschnitt 8.18, „Aus welchem Repo kommen die Pakete“.

Prüfung auf Verfügbarkeit für eine Architektur mittels apt-cache

# apt-cache policy pforth
pforth:i386:
  Installed: (none)
  Candidate: 21-12
  Version table:
     21-12 0
        990 http://ftp.ch.debian.org/debian/ jessie/main i386 Packages
#

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.

Installation des i386-Pakets pforth auf amd64-Debian. 

# apt-get install pforth
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  gcc-4.9-base:i386 libc6:i386 libgcc1:i386
Suggested packages:
  glibc-doc:i386
Recommended packages:
  libc6-i686:i386
The following NEW packages will be installed:
  gcc-4.9-base:i386 libc6:i386 libgcc1:i386 pforth:i386
0 upgraded, 4 newly installed, 0 to remove and 27 not upgraded.
Need to get 4,252 kB of archives.
After this operation, 9,727 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.ch.debian.org/debian/ jessie/main gcc-4.9-base i386 4.9.1-15 [158 kB]
Get:2 http://ftp.ch.debian.org/debian/ jessie/main libc6 i386 2.19-11 [3,977 kB]
Get:3 http://ftp.ch.debian.org/debian/ jessie/main libgcc1 i386 1:4.9.1-15 [48.2 kB]
Get:4 http://ftp.ch.debian.org/debian/ jessie/main pforth i386 21-12 [69.1 kB]
Fetched 4,252 kB in 0s (20.5 MB/s)
Preconfiguring packages ...
Selecting previously unselected package gcc-4.9-base:i386.
(Reading database ... 474485 files and directories currently installed.)
Preparing to unpack .../gcc-4.9-base_4.9.1-15_i386.deb ...
Unpacking gcc-4.9-base:i386 (4.9.1-15) ...
Selecting previously unselected package libc6:i386.
Preparing to unpack .../libc6_2.19-11_i386.deb ...
Unpacking libc6:i386 (2.19-11) ...
Replacing files in old package libc6-i386 (2.19-11) ...
Selecting previously unselected package libgcc1:i386.
Preparing to unpack .../libgcc1_1%3a4.9.1-15_i386.deb ...
Unpacking libgcc1:i386 (1:4.9.1-15) ...
Selecting previously unselected package pforth.
Preparing to unpack .../archives/pforth_21-12_i386.deb ...
Unpacking pforth (21-12) ...
Processing triggers for man-db (2.7.0-1) ...
Setting up gcc-4.9-base:i386 (4.9.1-15) ...
Setting up libc6:i386 (2.19-11) ...
Setting up libgcc1:i386 (1:4.9.1-15) ...
Setting up pforth (21-12) ...
Processing triggers for libc-bin (2.19-11) ...
#

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.

Installationsstatus für das Paket libc6

# dpkg -l pforth libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  libc6:amd64    2.19-11      amd64        GNU C Library: Shared libraries
ii  libc6:i386     2.19-11      i386         GNU C Library: Shared libraries
ii  pforth         21-12        i386         portable Forth interpreter
#

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.

Ausführung von pforth

$ pforth
PForth V21
pForth loading dictionary from file /usr/lib/pforth/pforth.dic
     File format version is 8
     Name space size = 120000
     Code space size = 300000
     Entry Point     = 0
     Little  Endian Dictionary
Begin AUTO.INIT ------
...
$

2.13. Paket-Priorität und essentielle Pakete

Jedes Paket beinhaltet ein Feld namens Priority – englisch für „Priorität“. Dabei geht es aber weniger um eine Rangfolge von Paketen, sondern um die Wichtigkeit eines Pakets bzw. um die Wahrscheinlichkeit, dass Sie dieses Paket installieren möchten.

Debian kennt die folgenden fünf Prioritätsstufen:

  • erforderlich (required)
  • wichtig (important)
  • standard (standard)
  • optional (optional)
  • extra (extra)

Die Begriffe in Klammern geben die Schlüsselworte wieder, die in der Paketbeschreibung genutzt werden. Jede dieser o.g. Stufen hat eine bestimmte Bedeutung.

Auflistung der Pakete mit einer festgelegten Priorität

In Abschnitt 8.9, „Pakete nach Prioritäten finden“ lesen Sie, wie Sie mit aptitude Pakete mit einer spezifischen Priorität finden.

2.13.1. Prioritätsstufe „erforderlich“ (required)

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

2.13.2. Prioritätsstufe „wichtig“ (important)

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 Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“) 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.

2.13.3. Prioritätsstufe „standard“ (standard)

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[7]), 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 Abschnitt 32.3, „Bugreports anzeigen“).

2.13.4. Prioritätsstufe „optional“ (optional)

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.

2.13.5. Prioritätsstufe „extra“ (extra)

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.

2.13.6. Markierung „essentiell“ (essential)

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

Eintrag in der Paketbeschreibung. 

Essential: yes

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 Abschnitt 8.9, „Pakete nach Prioritäten 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 Abschnitt 8.43, „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].

Eingabeaufforderung von apt-get vor der Entfernung des essentiellen Pakets init

# apt-get remove init
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  init
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
  init
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 29,7 kB Plattenplatz freigegeben.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.
 ?]

2.14. Verbreitungsgrad von Paketen

Wie bereits deutlich wurde, besteht die Distribution Debian GNU/Linux aus einer sehr großen Anzahl Paketen. In dieser Vielfalt spiegeln sich die Interessen der Benutzer sehr deutlich wieder.

Das Debian Quality Assurance Team (kurz QA Team) [DebianQA] sorgt dafür, dass eine möglichst hohe Softwarequalität in Debian gehalten wird. Neben den Werkzeugen zur Qualitätssicherung (siehe „Qualitätskontrolle“ in Kapitel 32, Qualitätskontrolle) gehören dazu die Trendforschung, die Bestandsaufnahme und eine Auswertung darüber, ob und vor allem wie häufig ein Paket installiert wird. Das sagt zwar nicht unbedingt etwas darüber aus, ob es tatsächlich verwendet wird, aber es zeigt, ob an einem Softwarepaket prinzipiell Interesse besteht. Dieser Aspekt fließt mit ein, um zu entscheiden, ob ein Paket weiterhin Bestandteil des Softwareumfangs von Debian bleibt.

Diese Analyse geht direkt auf den Ursprung von Debian zurück und versucht eine Antwort darauf zu geben, welche Software die Benutzer verwenden. Unmittelbare Ergebnisse sind die Auswahl der Softwarepakete, die in Debian bereitstehen und für diese Distribution gepflegt werden, weiterhin die Einordnung in die entsprechenden Kategorien (siehe Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“) und die Priorisierung (siehe Abschnitt 2.13, „Paket-Priorität und essentielle Pakete“). Für die Zusammenstellung von Installationsimages spielt der Nutzungsgrad eine große Rolle – Pakete, die häufiger genutzt werden, haben eine größere Chance, auf die ersten Installationsimages zu gelangen.

Grundlage für die erfassten Daten ist das Projekt Popcon – der Debian Popularity Contest [Debian-Popularity-Contest]. Die Benutzung ist freiwillig und über dessen Teilnahme entscheiden Sie als Benutzer selbst. Voraussetzung dafür ist die Installation des Pakets popularity-contest und dessen Aktivierung.

Danach wird in regelmäßigen Abständen — i.d.R. wöchentlich — der Softwarebestand (d.h. die installierten Pakete) erfasst, an das Popcon-Projekt übertragen und danach anonymisiert ausgewertet. Über die Projektwebseite erfolgt eine tabellarische Übersicht und eine graphische Auswertung. Abbildung 2.9, „Erfasster Verbreitungsgrad für das Paket nginx zeigt beispielhaft das Ergebnis für das Paket nginx.

Abbildung 2.9. Erfasster Verbreitungsgrad für das Paket nginx

konzepte/software-in-paketen-organisieren/popcon-nginx.png

2.14.1. Verschiedene Metriken

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

  • Wann wurde das Paket zuletzt aktualisiert oder installiert? Dies wird für den Graphen recent (kürzlich) verwendet und anhand des Zeitstempels der Dateien des Pakets unter /var/lib/dpkg/info eruiert.
  • Wann wurde zuletzt auf ausführbare Dateien des Pakets zugegriffen? Dies wird für die Graphen vote (dafür stimmen) und old (alt) verwendet und anhand der Zeitstempel des Zugriffs (atime) von Programmdateien des Paketes eruiert.

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

2.14.2. Vergleichen von Paketen

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

Abbildung 2.10. Vergleich Installationen und Nutzung der Pakete screen und tmux

konzepte/software-in-paketen-organisieren/popcon-screen-vs-tmux.png

2.15. Lokale Paketmarkierungen

Ein installiertes Debianpaket kann zusätzliche, lokale Markierungen besitzen. Diese beeinflussen z.B. dessen Aktualisierung oder — wenn kein anderes Paket mehr von ihm abhängt — veranlassen oder verhindern auch seine automatische Deinstallation.

2.15.1. Paketmarkierungen, die von verschiedenen Programmen genutzt werden

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:

automatisch installiert (automatic)
das Paket wurde automatisch installiert, i.d.R. als Abhängigkeit eines anderen Pakets (siehe „Paketabhängigkeiten anzeigen“ in Abschnitt 8.17, „Paketabhängigkeiten anzeigen“). Diese Markierung veranlasst, dass dieses Paket wieder entfernt wird, wenn keine weiteren, installierten Pakete mehr von diesem abhängen.
manuell installiert (manual)
das Paket wurde manuell, d.h. explizit installiert. Diese Markierung verhindert, dass dieses Paket automatisch mit entfernt wird, wenn kein weiteres Paket mehr von ihm abhängt (siehe „Umgang mit Waisen“ in Abschnitt 8.42, „Umgang mit Waisen“).
halten (hold)
das Paket wird in der vorliegenden, installierten Version auf dem System gehalten und nicht aktualisiert (upgrade) oder deinstalliert (siehe „Pakete aktualisieren“ in Abschnitt 8.39, „Pakete aktualisieren“ und „Pakete deinstallieren“ in Abschnitt 8.41, „Pakete deinstallieren“).

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[8]

Informationen zu jedem Paket in der Datei /var/lib/apt/extended_states (Ausschnitt). 

...

Package: gnome-menus
Auto-Installed: 0
Architecture: i386

Package: libfont-afm-perl
Auto-Installed: 1
Architecture: i386

Package: libhtml-parser-perl
Auto-Installed: 1
Architecture: i386

...

Ein Paket "auf hold" in der Datei /var/lib/dpkg/status (Ausschnitt). 

...

Package: awesome
Status: hold ok installed
Priority: optional
Section: x11
Installed-Size: ...
...

2.15.2. Aptitude-spezifische Paketmarkierungen

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

Verbotene Versionen (forbid-version/ForbidVer)
Von Ihnen als lokaler Administrator nicht erwünschte Version, die nicht installiert wird, auf die nicht aktualisiert wird bzw. die beim Aktualisieren übersprungen wird.
Neue Pakete (New Packages/Unseen)
aptitude pflegt eine Liste mit neuen Paketen, die in den Paketlisten der abonnierten APT-Repositories aufgetaucht sind. Diese Markierung können Sie mit dem Aufruf aptitude forget-new zurücksetzen.
Entfernungsgrund (Remove-Reason)
aptitude zeigt an, warum ein Paket entfernt wird: wegen nicht (mehr) erfüllter Abhängigkeiten, wegen Konflikten mit anderen Paketen, oder weil es nicht mehr gebraucht wird (sprich: kein Paket mehr davon abhängt). Wird solch eine Paketentfernung nur vorgemerkt, so speichert aptitude bis zur Entfernung auch den Grund für diese.
Benutzerspezifische Markierungen (User Tags)
Sie als Benutzer dürfen für Pakete mit dem Unterkommando add-user-tag eigene Markierungen setzen. Nach diesen suchen Sie im Paketbestand mit dem Muster ?user-tag(Muster). Muster bezeichnet hier einen Regulären Ausdruck, mit dem Sie die Markierung spezifizieren.

aptitude-spezifische Zusatzinformationen zu Paketen (Ausschnitt). 

...

Package: python3-pkg-resources
Architecture: amd64
Unseen: no
State: 1
Dselect-State: 1
Remove-Reason: 0
ForbidVer: 18.8-1
User-Tags: broken-by-807773

...

Die benutzerspezifischen Markierungen werden auch in der TUI von aptitude angezeigt, jedoch können Sie diese dort nicht ändern.

2.15.3. Lesen und Anzeigen einer Markierung mit aptitude

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.

Darstellung der Markierungen zum Paket python-pkg-resources mittels aptitude

$ aptitude show python-pkg-resources
Paket: python-pkg-resources
Zustand: Installiert
Verbotene Version: 18.8-1
Automatisch installiert: ja
Version: 18.7-1
…
Benutzermarkierungen: broken-by-807773

...
$

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 Abbildung 2.11, „Ausgabe der Paketmarkierungen in der Textoberfläche von aptitude).

Abbildung 2.11. Ausgabe der Paketmarkierungen in der Textoberfläche von aptitude

konzepte/software-in-paketen-organisieren/aptitude-hold.png

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 Abschnitt 8.10.2, „aptitude benutzen“.

2.15.4. Lesen und Anzeigen einer Markierung mit apt-mark

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 drei Unterkommandos showauto, showmanual und showhold für alle automatisch oder manuell installierten Pakete bzw. die Pakete, deren Zustand beibehalten wird.

Nachfolgend sehen Sie beispielhaft nur das Ergebnis des Aufrufs für die manuell installierten Pakete. Auf automatisch installierte Pakete gehen wir genauer in Abschnitt 8.10, „Automatisch installierte Pakete anzeigen“ ein. Dem Umgang mit dem hold-Flag in der Praxis ist der Abschnitt „Ausgewählte Pakete nicht aktualisieren“ in Kapitel 16, Ausgewählte Pakete nicht aktualisieren gewidmet.

Auflistung aller manuell installierten Pakete mittels apt-mark

# apt-mark showmanual
abiword
acpi
acpi-support
acpi-support-base
...
#

Liste der Pakete eingrenzen, die überprüft werden

Geben Sie beim Aufruf keine weiteren Parameter an, werden alle Pakete geprüft. Übergeben Sie hingegen eine eigene Paketliste als Datei, untersucht apt-mark die darin genannten Pakete auf das Vorhandensein des jeweiligen Paketmarkierungen.

2.15.5. Setzen und Entfernen einer Markierung mit apt-mark

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 die drei Schalter auto für automatisch, manual für manuell und hold für gehalten, mit dem Sie die entsprechende Markierung für ein angegebenes Paket explizit setzen können. 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.

Setzen der Paketmarkierungen manual für das Paket wireshark

# apt-mark manual wireshark
wireshark wurde als manuell installiert festgelegt.
#

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 Kapitel 16, Ausgewählte Pakete nicht aktualisieren.

2.15.6. Was passiert, wenn Paketmarkierungen geändert werden?

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“ (Kapitel 16, Ausgewählte Pakete nicht aktualisieren) ausführlicher.

2.15.7. Setzen und Entfernen einer Markierung mit aptitude

Alternativ zu apt-mark bietet sich auch aptitude an. Dort heissen 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.

Setzen von Paketmarkierungen mit aptitude

# aptitude markauto wireshark zshdb
Die folgenden Pakete werden ENTFERNT:
  zshdb{u}
0 Pakete aktualisiert, 0 zusätzlich installiert, 1 werden entfernt und 26 nicht aktualisiert.
0 B an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 451 kB frei werden.
Möchten Sie fortsetzen? [Y/n/?] n
Abbruch.
#

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

Aufheben von Paketmarkierungen mit aptitude

# aptitude unmarkauto wireshark zshdb
Es werden keine Pakete installiert, aktualisiert oder entfernt.
0 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 26 nicht aktualisiert.
0 B an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 0 B zusätzlich belegt sein.
#

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:

Setzen eines Paketes auf hold mit aptitude

# aptitude search '~U'
i A awesome                         - Hochkonfigurierbarer Fenstermanager für X
# aptitude hold awesome
Es werden keine Pakete installiert, aktualisiert oder entfernt.
0 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 26 nicht aktualisiert.
0 B an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 0 B zusätzlich belegt sein.
# aptitude search '~U'
ihA awesome                         - Hochkonfigurierbarer Fenstermanager für X
# aptitude unhold awesome
Es werden keine Pakete installiert, aktualisiert oder entfernt.
0 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 26 nicht aktualisiert.
0 B an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 0 B zusätzlich belegt sein.
# aptitude search '~U'
i A awesome                         - Hochkonfigurierbarer Fenstermanager für X
#

2.16. Wie finde ich passende Pakete

2.16.1. Paketquellen

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 Abschnitt 3.4, „Geeigneten Paketmirror auswählen“ 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 Kapitel 28, Einen eigenen APT-Mirror aufsetzen.

2.16.2. Paketnamen

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 Abschnitt 6.4.1, „Synaptic“), SmartPM (siehe Abschnitt 6.4.3, „Smart Package Management (SmartPM)“) oder auch PackageKit (siehe Abschnitt 6.4.5, „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 Abschnitt 8.19, „Pakete über den Namen finden“ genauer vor.

2.16.3. Paketeigenschaften und Einordnung

Bei den oben angesprochenen Varianten können Sie neben der Einordnung in die jeweilige Paketkategorie (siehe dazu „Sortierung der Pakete nach Verwendungszweck“ in Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“) bspw. auch über die Veröffentlichungen (siehe Abschnitt 2.10, „Veröffentlichungen“), den Maintainer (siehe Abschnitt 8.21, „Paket nach Maintainer finden“), den Paketinhalt (siehe Abschnitt 8.22, „Paket zu Datei finden“) oder ein Fragment aus dem Paket (siehe Abschnitt 8.24, „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 Kapitel 13, Erweiterte Paketklassifikation mit Debtags.



[5] das „u“ soll den griechischen Buchstaben Mu („µ“) darstellen

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

[7] Perl selbst und ein paar wenige Perl-Module sind im Paket perl-base welches „essentiell“ ist.

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

Teil II. Werkzeuge

Kapitel 3. Paketquellen und Werkzeuge

3.1. Paketquellen

3.1.1. Begriff und Hintergrund

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

3.1.2. Benutzte Paketquellen

Welche Paketquellen Sie verwenden, legen Sie bei Debian in der Datei /etc/apt/sources.list (oder alternativ in auf *.list endende Dateien im Verzeichnis /etc/apt/sources.list.d/) fest. Diese Dateien zählen damit 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 bevorzugten Paketspiegels.

3.1.3. Aufbau und Struktur einer Paketquelle

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 Kapitel 28, Einen eigenen APT-Mirror aufsetzen).

3.2. Empfehlung zum Ablauf für das Hinzufügen und Ändern von Paketquellen

Wie bereits in Abschnitt 3.1, „Paketquellen“ ausgeführt, sind die Datei /etc/apt/sources.list und das Verzeichnis /etc/apt/sources.list.d/ Dreh- und Angelpunkte für alle verwendeten Paketquellen. Erfolgen Änderungen darin, muss die Paketverwaltung anschließend noch über diese Modifikation informiert werden, damit sie den Paketcache anhand der aktualisierten Liste von Repositories auf den neuesten Stand bringt. Die Paketverwaltung erkennt die Änderungen nicht von sich aus und wartet auf ihren „Anstoß“. Danach synchronisiert sie die lokal vorliegenden Informationen über verfügbare Pakete und deren Abhängigkeiten (siehe Kapitel 7, Paketcache) mit den konfigurierten Paketquellen (Abschnitt 3.1, „Paketquellen“).

Wir empfehlen Ihnen zur Aktualisierung den folgenden Ablauf:

  1. Erstellen Sie zuerst eine Sicherheitskopie der entsprechenden Datei, z.B. cp -pv /etc/apt/sources.list /etc/apt/sources.list.backup. Gegebenenfalls macht das auch Ihr Texteditor automatisch.
  2. Tragen Sie die neuen oder veränderten Paketquellen in die Datei /etc/apt/sources.list nach und speichern diese ab. Wenn Sie nur neue Paketquellen hinzufügen wollen, können Sie alternativ auch eine neue Datei im Verzeichnis /etc/apt/sources.list.d/ anlegen. Der Name dieser Datei muss dann auf .list enden.
  3. Sofern dies keine offiziellen Debian-Repositories sind, verifizieren Sie die Paketquelle, die Sie hinzugefügt oder geändert haben. Unter „Paketquelle auf Echtheit überprüfen“ in Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“ erfahren Sie, wie das zu erfolgen hat. Offizielle Paketquellen sollten alle mit den bereits mitgelieferten Schlüsseln ihrer Debian-Installation verifiziert werden können.
  4. Aktualisieren Sie die lokalen Paketlisten mit einem der Kommandos apt-get update, aptitude update oder ab Debian 8 Jessie auch mit apt update. Bitte beachten Sie dazu auch unsere Anmerkungen unter „Liste der verfügbaren Pakete aktualisieren“ in Abschnitt 3.13, „Liste der verfügbaren Pakete aktualisieren“. Handelt es sich um ein Upgrade auf eine neue Version Ihrer Distribution, lesen Sie bitte dazu zusätzlich unter „Distribution aktualisieren“ in Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“ nach.

Mit dieser Vorgehensweise ist sichergestellt, dass die Paketverwaltung Ihre Veränderungen in der Liste der Paketquellen beachtet hat. Nun können Sie die Pakete aus den geänderten oder neuen Paketquellen zu Ihrem System hinzufügen.

Mit etwas Automatisierung den Ablauf vereinfachen

Möchten Sie diese Schrittfolge automatisieren, hilft Ihnen das Kommando add-apt-repository weiter. Dessen Möglichkeiten besprechen wir genauer in Abschnitt 3.9, „Einträge mit add-apt-repository im Griff behalten“.

Im Bedarfsfall können Sie auch auf den Stand vor Ihren Veränderungen zurückgreifen. Sollte dies erforderlich sein, restaurieren Sie die im ersten Schritt angelegte Sicherheitskopie oder — falls Sie nur eine neue Datei im Verzeichnis /etc/apt/sources.list.d/ angelegt haben, löschen Sie diese — und führen das Kommando apt-get update respektive aptitude update erneut aus. Ab Debian 8 Jessie ist auch der Aufruf apt update zulässig.

Versionierung statt manuellem Backup

Anstatt manuell Backups zu machen, können Sie auch das Verzeichnis /etc/apt/ mit einer Versionsverwaltung wie z.B. Git versionieren. Das Debian-Paket etckeeper [Debian-Paket-etckeeper] bietet dies sogar automatisiert bei jeder Paketinstallation, -Aktualisierung oder -Entfernung an, versioniert dann aber gleich das ganze Verzeichnis /etc/.

3.3. /etc/apt/sources.list verstehen

3.3.1. Format der Paketliste

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

Abbildung 3.1. /etc/apt/sources.list im Texteditor nano

werkzeuge/paketquellen-und-werkzeuge/etc-apt-sources.list-verstehen/sources-list-nano.png

Änderungen nehmen Sie mit Hilfe eines beliebigen Texteditors als Benutzer root vor, bspw. mittels vim, emacs oder nano (siehe Abbildung 3.1, „/etc/apt/sources.list im Texteditor nano). Haben Sie in Ihrem Texteditor die Syntaxhervorhebung aktiviert, erfassen Sie die Struktur der einzelnen Einträge leichter und bemerken sofort fehlerhafte Änderungen durch eine entsprechende Einfärbung des Textes.

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 entsprechenden Listeneintrag. 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.

Anzahl der Einträge

Es gibt keine Begrenzung für die Anzahl der Einträge. Bitte beachten Sie aber, dass die Zeit und das Übertragungsvolumen für die Aktualisierung der Paketlisten umso größer wird, je mehr Einträge vorhanden sind.

Bei der späteren Aktualisierung der lokalen Paketliste mittels apt-get update oder aptitude update (siehe Abschnitt 8.39, „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.

Empfehlung zur Abfolge

Für das Hinzufügen und Ändern der Paketquellen empfehlen wir Ihnen eine bestimmte Reihenfolge (siehe Abschnitt 3.2, „Empfehlung zum Ablauf für das Hinzufügen und Ändern von Paketquellen“). Damit erleben Sie zukünftig keine bösen Überraschungen mehr.

Zur Automatisierung des Vorgangs wurden ebenfalls eine Reihe von Programmen entwickelt. Dazu zählen apt-cdrom (siehe dazu Abschnitt 3.8, „Physische Installationsmedien mit apt-cdrom einbinden“), add-apt-repository (siehe dazu Abschnitt 3.9, „Einträge mit add-apt-repository im Griff behalten“) und apt-spy (siehe dazu ???). Sind Sie hingegen weniger tastaturaffin, bieten sich als weitere Möglichkeiten sowohl Synaptic, das Ubuntu Software Center sowie der Sources List Generator für Debian und Ubuntu an. Diese Programme stellen wir Ihnen in Abschnitt 3.10, „Einstellungen mit Synaptic und im Ubuntu Software Center“ und Abschnitt 3.11, „Debian und Ubuntu Sources List Generator“ ausführlicher vor.

3.3.2. Format eines Eintrags

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

Art_der_Quelle URI Distribution [Komponente 1] [Komponente 2] [...]

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

Art der Quelle
bezeichnet den verwendeten Pakettyp, deb für Debian-Binärpakete und deb-src für Debian-Quellpakete. Genauer gehen wir dazu unter „Debians Paketvarianten“ in Abschnitt 2.7, „Debian-Pakete (Varianten)“ und „Debian-Paketformat“ im Detail in Kapitel 4, Debian-Paketformat im Detail ein.
URI

legt die Art der Installationsquelle fest. Hierbei stehen:

  • file: Installationsquelle ist ein Verzeichnis. Dieses kann sowohl lokal vorliegen, als auch von extern eingebunden sein, bspw. über ein Netzwerkdateisystem wie AFS, NFS oder SMB
  • cdrom: CD, DVD oder Blu-ray
  • http: HTTP-Server
  • ftp: FTP-Server
  • copy: identisch zu file, aber die bezogenen Debianpakete werden zusätzlich im lokalen Verzeichnis /var/cache/apt/archives/ abgelegt
  • mirror: Auswahl einer Installationsquelle anhand der GeoIP des Servers (siehe Abschnitt 3.6.2, „Paketquellen über GeoIP auswählen“)
  • debtorrent: die Pakete werden über DebTorrent auf der Basis des BitTorrent-Protokolls bezogen [Debian-Wiki-DebTorrent]. Basis dafür ist das Debianpaket apt-transport-debtorrent [Debian-Paket-apt-transport-debtorrent].
Distribution

benennt die Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“), aus der Pakete installiert werden sollen. Typisch ist hier die Angabe des Entwicklungsstands (siehe Abschnitt 2.10.1, „Bedeutung der verschiedenen Entwicklungsstände“) wie bspw. stable, unstable oder testing sowie die Nennung des alternativen Distributionsnamens wie bspw. Wheezy, Jessie oder Sid (siehe Abschnitt 2.10.2, „Alias-Namen“).

Bitte beachten Sie bei Debian und Ubuntu die Kleinschreibung des Namens. Nicht-offizielle Paketquellen können an dieser Stelle jedoch auch sonstige Zeichenketten bis hin zu einem . verlangen.

Komponente
bestimmt den Distributionsbereich, d.h. bspw. bei Debian main, contrib oder non-free. Ausführlicher gehen wir darauf in Abschnitt 2.9, „Distributionsbereiche“ ein.

3.3.3. Beispieleinträge für offizielle Pakete

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

deb http://ftp.de.debian.org/debian/ stable main

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. wheezy oder jessie 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 Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“).

Um hingegen zusätzlich die Pakete aus weiteren Paketbereichen wie bspw. contrib und non-free zu verwenden, ändern Sie den Eintrag auf das Folgende, hier wiederum mit expliziter Angabe des Aliasnamens jessie. In welcher Reihenfolge Sie die Paketbereiche angeben, spielt keine Rolle. Üblich ist jedoch die Abfolge anhand des Freiheitsgrades der Softwarelizenz in der Form von main contrib non-free.

deb http://ftp.de.debian.org/debian/ jessie main contrib non-free

Auswahl eines Paketmirrors

Mehr Informationen zur Auswahl eines für Sie am besten geeigneten Paketmirrors erfahren Sie unter „Geeigneten Paketmirror auswählen“ in Abschnitt 3.4, „Geeigneten Paketmirror auswählen“. Mit dieser Angabe können Sie die Bezugszeiten für Aktualisierungen der Paketlisten und der Pakete erheblich zu ihren Gunsten beeinflussen.

3.3.4. Verzeichnis als Paketquelle

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:

deb file:/home/benutzer/debian stable main contrib non-free

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:

deb cdrom:[Ubuntu 12.04 LTS _Precise Pangolin_ - Release i386 (20120423)]/ precise main restricted

Automatisierung der Eintragung

Obige Einträge können Sie von Hand vornehmen. Das Werkzeug apt-cdrom vereinfacht den Vorgang jedoch erheblich. Unter „Physische Installationsmedien mit apt-cdrom einbinden“ in Abschnitt 3.8, „Physische Installationsmedien mit apt-cdrom einbinden“ besprechen wir das Programm genauer.

3.3.5. Einträge für Sicherheitsaktualisierungen

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, ergänzen Sie die Datei /etc/apt/sources.list um den folgenden Eintrag:

deb http://security.debian.org/ jessie/updates main contrib non-free

Obige Angabe beinhaltet beispielhaft wiederum die explizite Angabe des Aliasnamens der Veröffentlichung Debian 8 Jessie. Dieser Name wird gefolgt vom Unterverzeichnis updates und den daraus gewünschten Distributionsbereichen main, contrib und non-free.

3.3.6. Einträge für zusätzliche, nicht-offizielle Pakete

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 7 Wheezy:

deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main
deb http://packages.x2go.org/debian wheezy main

Ä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[9] auf den Bereich non-free auf dessen Paketserver:

deb http://deb.opera.com/opera stable non-free

Ergänzung der Signatur der Paketquelle

Damit Debian dieser zusätzlichen Paketquelle auch vertraut, überprüft es dazu eine entsprechende digitale Signatur. Wie dieses Konzept funktioniert und Sie einen passenden Schlüssel beziehen, lesen Sie unter „Paketquelle auf Echtheit überprüfen“ in Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“.

Eigene .list-Datei für fremde Paketquellen.

Anstatt alle Einträge direkt in die Datei /etc/apt/sources.list zu schreiben, können Sie einen oder mehrere Einträge auch in separate Dateien unter /etc/apt/sources.list.d/ ablegen. Dateien in diesem Verzeichnis bedürfen der Endung .list, um von APT beachtet zu werden.

So könnten Sie z.B. die Beispiele in diesem Abschnitt in den Dateien /etc/apt/sources.list.d/postgresql.list, /etc/apt/sources.list.d/x2go.list und /etc/apt/sources.list.d/opera.list speichern. Damit behalten Sie bereits anhand des Dateinamens den Überblick, aus welchen Fremdquellen weitere Pakete bezogen werden.

3.3.7. Einträge für Quellpakete

Um Debian-Quellpakete (siehe Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“) 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 8 Jessie:

deb-src http://ftp.de.debian.org/debian/ jessie main

3.3.8. Einträge für Deutschland

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:

deb http://ftp.de.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

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 8 Jessie 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.

3.4. Geeigneten Paketmirror auswählen

Zentraler Anlaufpunkt für netzbasierte Installationen sind die offiziellen Paketmirrors – auf deutsch auch Spiegelserver genannt – welche die Debianpakete für Sie bereithalten. Diese Paketmirrors sind weltweit verteilt und werden meist ehrenamtlich von einem Verantwortlichen für den jeweiligen Standort oder im Rahmen seiner administrativen Aufgaben vor Ort betreut. Viele Spiegelserver werden automatisch über neue Pakete informiert und abgeglichen und verfügen somit stets über den aktuelle Paketbestand.

Wir empfehlen Ihnen, bei der Auswahl eines Paketmirrors einen solchen zu bevorzugen, der eine möglichst kurze Entfernung zu ihrem Standort hat, mit hoher Verfügbarkeit glänzt und über eine gute Netzanbindung verfügt. Damit erhöht sich die Zuverlässigkeit ihrer Infrastruktur und insbesondere auch der Komponenten, die von externen Bestandteilen und Diensten abhängig sind.

Mit der oben beschriebenen, dezentralen Verteilung ist gewährleistet, dass Sie bei einem Ausfall oder der Nichtverfügbarkeit des von ihnen gewählten Paketmirrors problemlos auf eine adäquate Alternative zurückgreifen können, auch wenn diese netztechnisch etwas weiter von ihrem aktuellen Standort entfernt ist. Für die Infrastruktur des Debian-Projekts heißt das außerdem, dass sich die Anfrage- oder Netzlast auf unterschiedliche Mirrors und deren Standorte verteilt.

Für Sie bedeutet das im Alltag, dass sich neben der Verringerung der Ausfallwahrscheinlichkeit insbesondere die Bezugszeiten für Debianpakete erheblich verringern, da Sie nicht auf einen einzigen Spiegelserver angewiesen sind. Verwenden Sie einen Spiegelserver in ihrer Nähe, merken Sie das insbesondere dann, wenn größere Aktualisierungen erfolgen, bspw. bei einem Distributionswechsel oder -upgrade (siehe Abschnitt 8.39.3, „dist-upgrade und full-upgrade).

Jeder Interessierte kann einen solchen Paketmirror betreiben. Wie Sie diesen einrichten, erfahren Sie unter „Einen eigenen APT-Mirror aufsetzen“ in Kapitel 28, Einen eigenen APT-Mirror aufsetzen.

3.4.1. Paketmirror bei Debian

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:

ftp.Länderkennung.debian.org

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 Abschnitt 1.2, „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 Abschnitt 1.2, „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. [10]

Informationen zum Paketmirror ftp.de.debian.org (TU Dresden). 

Site: ftp.de.debian.org
Alias: ftp1.de.debian.org
Alias: debian.inf.tu-dresden.de
Type: Push-Primary
Archive-architecture: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
Archive-upstream: ftp-master.debian.org
Archive-method: push
Backports-ftp: /debian-backports/
Backports-http: /debian-backports/
Backports-rsync: debian-backports/
Backports-upstream: syncproxy3.eu.debian.org
Backports-method: push
CDImage-ftp: /debian-cd/
CDImage-http: /debian-cd/
CDImage-rsync: debian-cd/
Old-ftp: /debian-archive/
Old-http: /debian-archive/
Old-rsync: debian-archive/
Volatile-ftp: /debian-volatile/
Volatile-http: /debian-volatile/
Volatile-rsync: debian-volatile/
Volatile-upstream: kassia.debian.org
Ports-architecture: alpha arm64 hppa m68k powerpcspe ppc64 sh4 sparc64 x32
Ports-ftp: /debian-ports/
Ports-http: /debian-ports/
Ports-rsync: debian-ports/
Ports-upstream: ftp.debian-ports.org
Country: DE Germany
Location: Dresden
Sponsor: Technical University of Dresden, Dept. of Computer Science http://www.inf.tu-dresden.de/
Comment: DFN
IPv6: no

3.4.2. Paketmirror für andere Distributionen

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 Abbildung 3.2, „Auswahl der Paketmirror für Linux Mint“ sehen Sie die Zusammenstellung für die Distribution Linux Mint.

Abbildung 3.2. Auswahl der Paketmirror für Linux Mint

werkzeuge/paketquellen-und-werkzeuge/linuxmint-mirrors.png

3.4.3. Pakete ohne Paketmirror beziehen

Steht Ihnen lediglich ein Zugang über einen Webbrowser zur Verfügung, sind Sie trotzdem nicht vom Paketarchiv abgeschnitten. Unter „Browserbasierte Suche“ in Abschnitt 8.19.2, „Browserbasierte Suche“ erfahren Sie, wie Sie die benötigten Pakete mit Hilfe ihres Webbrowsers recherchieren und beziehen. Unter „Webbasierte Programme“ in Abschnitt 6.5, „Webbasierte Programme“ stellen wir Ihnen weitere clevere Lösungen für verschiedene Linux-Distributionen vor.

3.5. Am besten erreichbaren Paketmirror finden

Jeder Paketmirror hat eine spezifische Leistungsfähigkeit, die sich an den beiden Kriterien Netzanbindung und Hardwareausstattung messen lässt. Auf diese Merkmale haben Sie zwar nur begrenzt Einfluss, steuern jedoch über die Einträge in der Datei /etc/apt/sources.list (siehe Abschnitt 3.3, „/etc/apt/sources.list verstehen“), welchen verfügbaren Paketmirror Sie benutzen.

Anstatt diese Schritte aufwendig über die Kombination einzelner Werkzeuge wie ping oder traceroute zu ermitteln, sind hier die beiden Programme netselect [Debian-Paket-netselect] und netselect-apt [Debian-Paket-netselect-apt] die besseren Mittel der Wahl. Damit finden Sie den Paketmirror heraus, der netztechnisch von ihrem aktuellen Standort aus am besten erreichbar ist.

Bis einschließlich Debian 7 Wheezy war das Programm apt-spy [Debian-Paket-apt-spy] fester Bestandteil der Veröffentlichung. Es wurde nicht in Debian 8 Jessie übernommen, steht jedoch weiterhin für unstable zur Verfügung.

3.5.1. netselect und netselect-apt

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.

Der Unterschied zwischen netselect und netselect-apt ist folgender: netselect gibt nur den ermittelten Zahlenwert für den evaluierten Spiegelserver aus, während netselect-apt eine Datei namens sources.list im aktuellen Verzeichnis erzeugt. Diese beinhaltet die besten gefundenen Spiegelserver und kann von Ihnen sofort als neue Liste der Paketquellen benutzt werden.

Aktualisierung der Liste der Paketquellen

Zu Änderungen an den Paketquellen beachten Sie bitte auch unsere Hinweise unter „/etc/apt/sources.list verstehen“ in Abschnitt 3.3, „/etc/apt/sources.list verstehen“. Wir raten Ihnen dazu, die neue Liste der Paketquellen zuerst lokal zu erstellen und danach manuell in das Verzeichnis /etc/apt/ zu verschieben.

Paketquellen nach Pingzeiten und Entfernung auswählen

netselect und netselect-apt akzeptieren beim Aufruf eine Menge verschiedener Schalter und Parameter. Stets anzugeben ist mindestens ein Spiegelserver, der zu testen ist. Geben Sie hingegen eine ganze Liste an, werden alle daraus nacheinander überprüft. Die nachfolgende Ausgabe zeigt das Ergebnis für fünf angefragte Paketmirrors.

Aufruf von netselect mit fünf verschiedenen Paketmirrors. 

# netselect -v ftp.debian.org http.us.debian.org ftp.at.debian.org download.unesp.br ftp.debian.org.br
netselect: unknown host ftp.debian.org.br
Running netselect to choose 1 out of 8 addresses.
...............................................................
   73 ftp.debian.org
#

Mit dem zusätzlichen Schalter -v regeln Sie die Ausführlichkeit der Ausgabe. Ohne den Schalter geben beide Programme nur den Paketmirror aus, der den besten Wert hat, mit -vv bzw. -vvv oder sogar -vvvv entsprechend mehr Details.

Etwas ausführlichere Ausgabe zu den Paketmirrors. 

# netselect -vv ftp.debian.org http.us.debian.org ftp.at.debian.org download.unesp.br ftp.debian.org.br
netselect: unknown host ftp.debian.org.br
Running netselect to choose 1 out of 8 addresses.
...............................................................
128.61.240.89          141 ms   8 hops   88% ok ( 8/ 9) [  284]
ftp.debian.org          41 ms   8 hops  100% ok (10/10) [   73]
128.30.2.36            118 ms  19 hops  100% ok (10/10) [  342]
64.50.233.100          112 ms  14 hops   66% ok ( 2/ 3) [  403]
64.50.236.52           133 ms  15 hops  100% ok (10/10) [  332]
ftp.at.debian.org       47 ms  13 hops  100% ok (10/10) [  108]
download.unesp.br      314 ms  10 hops   75% ok ( 3/ 4) [  836]
ftp.debian.org.br     9999 ms  30 hops    0% ok
   73 ftp.debian.org
#

In der Ausgabe erscheinen die IP-Adresse bzw. der Hostname (Spalte 1), nachdem aufgelöst wird, die durchschnittliche Paketlaufzeit (Spalte 2), die Anzahl der Zwischenknoten (Spalte 3) sowie die Verlustrate der Pakete auf dem Transportweg (Spalte 4 bis 6). Die Angabe ok besagt dabei, dass der Paketmirror über das Netz erreichbar ist. Die Angabe 9999ms für die Paketlaufzeit besagt hingegen, dass der Paketmirror zum Testzeitpunkt leider nicht erreichbar war.

Die Werte in den runden Klammern in Spalte 6 zeigen, wie der Prozentwert der Verlustrate der Pakete in Spalte 4 zustandekam. Dieser basiert auf der Anzahl Pakete, die der Paketmirror als empfangen bestätigt hat, jeweils gegenübergestellt der Anzahl gesendeter Pakete. Die Zahl in den eckigen Klammern am Ende jeder ausgegebenen Zeile (Spalte 7) ist der Wert, den netselect für den jeweiligen Paketmirror ermittelt hat.

Noch mehr Informationen zu den Paketmirrors. 

# netselect -vvv ftp.debian.org http.us.debian.org ftp.at.debian.org download.unesp.br ftp.debian.org.br
netselect: unknown host ftp.debian.org.br
Running netselect to choose 1 out of 8 addresses.
128.30.2.36            122 ms   15 hops - HIGHER
64.50.233.100          112 ms   15 hops - OK
ftp.at.debian.org       49 ms   15 hops - OK
min_lag is now 49
64.50.236.52           140 ms   15 hops - OK
ftp.debian.org          42 ms   15 hops - OK
min_lag is now 42
ftp.at.debian.org       48 ms    8 hops - HIGHER
128.30.2.36            117 ms   23 hops - OK
ftp.debian.org          41 ms    8 hops - OK
min_lag is now 41
64.50.233.100          112 ms    8 hops - HIGHER
64.50.236.52           112 ms    8 hops - HIGHER
ftp.debian.org          28 ms    4 hops - HIGHER
ftp.at.debian.org       49 ms   12 hops - HIGHER
ftp.debian.org          38 ms    6 hops - HIGHER
ftp.at.debian.org       48 ms   14 hops - OK
128.30.2.36            119 ms   19 hops - OK
64.50.233.100          113 ms   12 hops - HIGHER
ftp.debian.org          53 ms    7 hops - HIGHER
ftp.at.debian.org       49 ms   13 hops - OK
64.50.236.52           114 ms   12 hops - HIGHER
ftp.debian.org          42 ms    8 hops - OK
download.unesp.br      306 ms   15 hops - OK
ftp.at.debian.org       48 ms   13 hops - OK
ftp.debian.org          42 ms    8 hops - OK
ftp.at.debian.org       49 ms   13 hops - OK
64.50.233.100          114 ms   14 hops - OK
128.30.2.36            118 ms   17 hops - HIGHER
ftp.debian.org          42 ms    8 hops - OK
64.50.236.52           138 ms   14 hops - HIGHER
ftp.at.debian.org       49 ms   13 hops - OK
ftp.debian.org          41 ms    8 hops - OK
ftp.at.debian.org       49 ms   13 hops - OK
ftp.debian.org          41 ms    8 hops - OK
128.30.2.36            119 ms   18 hops - HIGHER
ftp.debian.org          43 ms    8 hops - OK
ftp.at.debian.org       48 ms   13 hops - OK
64.50.236.52           132 ms   15 hops - OK
ftp.debian.org          43 ms    8 hops - OK
ftp.at.debian.org       48 ms   13 hops - OK
ftp.debian.org          42 ms    8 hops - OK
128.30.2.36            118 ms   19 hops - OK
ftp.at.debian.org       48 ms   13 hops - OK
download.unesp.br      313 ms    8 hops - HIGHER
64.50.236.52           134 ms   15 hops - OK
128.30.2.36            122 ms   19 hops - OK
64.50.236.52           133 ms   15 hops - OK
128.30.2.36            129 ms   19 hops - OK
download.unesp.br      307 ms   12 hops - OK
64.50.236.52           140 ms   15 hops - OK
128.30.2.36            124 ms   19 hops - OK
64.50.236.52           133 ms   15 hops - OK
128.30.2.36            117 ms   19 hops - OK
128.30.2.36            117 ms   19 hops - OK
64.50.236.52           134 ms   15 hops - OK
download.unesp.br      308 ms   10 hops - OK
128.30.2.36            118 ms   19 hops - OK
64.50.236.52           134 ms   15 hops - OK
128.30.2.36            118 ms   19 hops - OK
64.50.236.52           133 ms   15 hops - OK
download.unesp.br      305 ms    9 hops - HIGHER
64.50.236.52           131 ms   15 hops - OK


download.unesp.br      307 ms  10 hops   75% ok ( 3/ 4) [  818]
128.30.2.36            119 ms  19 hops  100% ok (10/10) [  345]
64.50.233.100          113 ms  14 hops   66% ok ( 2/ 3) [  405]
64.50.236.52           134 ms  15 hops  100% ok (10/10) [  335]
128.61.240.89         9999 ms  30 hops    0% ok
ftp.at.debian.org       48 ms  13 hops  100% ok (10/10) [  110]
ftp.debian.org          41 ms   8 hops  100% ok (10/10) [   73]
ftp.debian.org.br     9999 ms  30 hops    0% ok
   73 ftp.debian.org
#

Ergebnis des obigen Aufrufs ist eine Empfehlung für einen der Paketmirrors, die Sie im Aufruf benannt haben. Dieser Paketmirror ist von ihrem Standort aus derzeit am besten erreichbar. Das ermittelte Ergebnis schwankt und hängt stets von der aktuellen Netzauslastung ab.

Die Empfehlung und der ermittelte Zahlenwert stehen in der letzten Zeile der Ausgabe und zeigen hier den Wert 73 für den Server ftp.debian.org. Die angegebene Zahl errechnet sich aus den bereits zu Beginn genannten Kriterien und ist vergleichbar mit einem Punktwert, hat jedoch offiziell keine Einheit. Je höher der Wert ist, umso schlechter ist der Paketmirror von Ihrem aktuellen Standort im Netz zu erreichen.

Anzahl der Hops begrenzen

Die Auswahl des Paketmirrors läßt sich auch von der Anzahl der Zwischenknoten (Hops) abhängig machen. netselect kennt dazu den Schalter -m gefolgt von der Anzahl der Zwischenknoten. Nachfolgende Ausgabe zeigt das für den Server ftp.at.debian.org. Die Ausgabe ist sortiert, d.h. der Paketmirror mit den wenigsten Hops steht ganz oben in der Liste.

Paketmirror mit den wenigsten Zwischenknoten. 

# netselect -m 10 -vvv ftp.at.debian.org
Running netselect to choose 1 out of 1 address.
ftp.at.debian.org                       33 ms    5 hops - HIGHER
ftp.at.debian.org                       51 ms    8 hops - HIGHER
ftp.at.debian.org                       51 ms    9 hops - HIGHER
ftp.at.debian.org                       47 ms   10 hops - OK
min_lag is now 47
ftp.at.debian.org                       49 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK
ftp.at.debian.org                       56 ms   10 hops - OK
ftp.at.debian.org                       49 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK
ftp.at.debian.org                       48 ms   10 hops - OK


ftp.at.debian.org                       48 ms  10 hops  100% ok (10/10) [   96]
   96 ftp.at.debian.org
#

Einen geschützten Paketmirror abfragen

Ist der Paketmirror beispielweise von einer Firewall geschützt und diese blockiert UDP-Pakete, kann die Option -I von größerem Nutzen sein. Damit sendet netselect zur Abfrage stattdessen ICMP-Pakete und umgeht das Hindernis. Das Ergebnis sehen Sie in der nachfolgenden Ausgabe:

Paketmirror mit ICMP-Paketen abfragen. 

# netselect -I -vvv ftp.de.debian.org
Running netselect to choose 1 out of 1 address.
ftp.de.debian.org            37 ms   15 hops - OK
min_lag is now 37
ftp.de.debian.org            36 ms    8 hops - OK
min_lag is now 36
ftp.de.debian.org            27 ms    4 hops - HIGHER
ftp.de.debian.org            36 ms    6 hops - HIGHER
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            36 ms    7 hops - OK
ftp.de.debian.org            37 ms    7 hops - OK
ftp.de.debian.org            38 ms    7 hops - OK


ftp.de.debian.org            36 ms   7 hops  100% ok (10/10) [   61]
   61 ftp.de.debian.org
#

Liste der Paketquellen mit netselect-apt generieren lassen

Wie oben bereits angesprochen, erzeugt netselect-apt eine Datei sources.list im aktuellen Verzeichnis. Dazu verfügt es über den Schalter -o (Langform --outfile), mit dem Sie die entsprechende Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“) angeben und eine passende Liste dazu generieren lassen. netselect-apt akzeptiert dazu Angaben wie stable oder unstable, aber auch die Alternativnamen der Veröffentlichung wie Wheezy oder Sid.

Desweiteren kennt netselect-apt diese Schalter:

-a (Langform --arch)
Erzeugung der Liste für die angegebene Prozessorarchitektur. Eine Übersicht zu den von Debian unterstützten Architekturen finden Sie unter „Debian-Architekturen“ in Kapitel 45, Debian-Architekturen. Geben Sie keinen Wert an, benutzt netselect-apt den Wert, den dpkg als Architektur zurückliefert.
-c (Langform --country)
Die Einträge kommen nur aus dem angegebenen Land.
-f (Langform --ftp)
Benutze FTP-Quellen anstatt von HTTP-Quellen.
-n (Langform --nonfree)
Ergänzung der Einträge um den Distributionsbereich nonfree (siehe „Distributionsbereiche“ in Abschnitt 2.9, „Distributionsbereiche“).
-s (Langform --sources)
zusätzliche Erzeugung von Einträgen für den Bezug von Quellpaketen (siehe „Sourcepakete“ in Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“ und „Einträge für Quellpakete“ in Abschnitt 3.3.7, „Einträge für Quellpakete“).

Im nachfolgenden Beispiel kommt lediglich der Schalter -o test.list zum Einsatz. Das führt dazu, dass netselect-apt die ermittelten Paketmirrors in die Datei test.list im lokalen Verzeichnis ausgibt.

Speicherung der ermittelten Paketmirrors in einer separaten Datei. 

# netselect-apt stable -o test.list
Using distribution stable.
Retrieving the list of mirrors from www.debian.org...

--2014-02-13 14:55:02--  http://www.debian.org/mirror/mirrors_full
Auflösen des Hostnamen »www.debian.org (www.debian.org)«... 5.153.231.4, 130.89.148.14, 2001:610:1908:b000::148:14, ...
Verbindungsaufbau zu www.debian.org (www.debian.org)|5.153.231.4|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 338381 (330K) [text/html]
In »»/tmp/netselect-apt.WrCIoS«« speichern.

100%[============================================================>] 338.381      959K/s   in 0,3s

2014-02-13 14:55:03 (959 KB/s) - »»/tmp/netselect-apt.WrCIoS«« gespeichert [338381/338381]

Choosing a main Debian mirror using netselect.
netselect: 347 (23 active) nameserver request(s)...
Duplicate address 218.100.43.30 (http://ftp.au.debian.org/debian/, http://mirror.waia.asn.au/debian/); keeping only under first name.
netselect: 343 (23 active) nameserver request(s)...
Duplicate address 195.222.33.229 (http://ftp.ba.debian.org/debian/, http://mirror.debian.com.ba/debian/); keeping only under first name.
...
Running netselect to choose 10 out of 333 addresses.
...
The fastest 10 servers seem to be:

        http://artfiles.org/debian/
        http://ftp.plusline.de/debian/
        http://ftp5.gwdg.de/pub/linux/debian/debian/
        http://debian.netcologne.de/debian/
        http://ftp.uni-erlangen.de/debian/
        http://deb-mirror.de/debian/
        http://mirror.de.leaseweb.net/debian/
        http://mirror.1und1.de/debian/
        http://deb-mirror.de/debian/
        http://ftp.uni-bayreuth.de/debian/

Of the hosts tested we choose the fastest valid for HTTP:
        http://artfiles.org/debian/

Writing test.list.
Done.
#

Die von netselect-apt erzeugte Datei test.list enthält neben den Paketmirrors auch eine ganze Reihe Kommentare. Diese helfen Ihnen dabei, zu verstehen, wofür jeder einzelne Eintrag gedacht ist.

Inhalt der automatisch generierten Liste der Paketmirrors. 

# cat test.list

# Debian packages for stable
deb http://artfiles.org/debian/ stable main contrib
# Uncomment the deb-src line if you want 'apt-get source'
# to work with most packages.
# deb-src http://artfiles.org/debian/ stable main contrib

# Security updates for stable
deb http://security.debian.org/ stable/updates main contrib
#

netselect und netselect-apt im Alltagseinsatz

Aus unserer Sicht lohnt sich der Aufruf von netselect bzw. netselect-apt bei stationären Systemen (Servern) mit fester Anbindung nur bedingt. Hilfreich ist das Vorgehen bspw. nach der ersten Einrichtung, einem Standortwechsel des Gerätes oder der Änderung der Infrastruktur, da letztere in der Regel häufig recht konstant ist. Bei Endsystemen an einem festen Ort raten wir Ihnen, die Werkzeuge nur interessehalber auszuprobieren, weil die Zugriffszeiten in diesem Kontext nicht immer eine so große Relevanz haben. Bei Systemen für die Infrastruktur wirkt sich die Optimierung hingegen meist weitaus stärker aus.

Bei mobilen Geräten sieht das hingegen deutlich anders aus. Mit Laptops oder Smartphones sind Sie variabler und den damit einhergehenden Schwankungen in der Netzanbindung stärker ausgesetzt. Auffällig wird die Anpassung dann, wenn Sie größere Entfernungen zurücklegen, bspw. ein Land oder einen Kontinent gewechselt haben.

3.5.2. Paketquellen mit apt-spy einstellen

Verfügbarkeit von apt-spy

apt-spy ist bis einschließlich Debian 7 Wheezy fester Bestandteil des Paketbestands. Für Debian 8 Jessie gibt es kein offizielles Paket, jedoch weiterhin in unstable.

Das Werkzeug apt-spy aus dem gleichnamigen Debian-Paket [Debian-Paket-apt-spy] erstellt eine Liste der Paketquellen für eine netzbasierte Installation. Basis dafür sind die verfügbaren Paketmirror und deren Erreichbarkeit.

Paketquellen nach Bandbreite auswählen

In den meisten Fällen wissen Sie, welche Paketquellen Sie als Bezugspunkt für ihr Linuxsystem verwenden möchten, sei es aus Gewohnheit, langjähriger Erfahrung als Systembetreuer oder auf der Grundlage von Vorgaben für eine bereits bestehende Infrastruktur. Sind Sie hingegen frei in ihrer Entscheidung, kann Ihnen das Programm apt-spy [Debian-Paket-apt-spy] helfen, die Paketquellen für eine netzbasierte Installation zu ermitteln, die von ihrem Standort aus am besten erreichbar sind.

Dazu untersucht apt-spy die Paketmirrors für die angefragte Region bzgl. ihrer Bandbreite, Erreichbarkeit und damit indirekt zur Verlustrate der übertragenen Netzwerkpakete. Ohne Belang ist dabei, wie weit der Paketmirror netztechnisch von ihrem Standort aus entfernt ist, sprich: wieviele Zwischenknoten (Hops) zu berücksichtigen sind.

Das kann auch dazu führen, dass schwächere, lokale Paketmirrors außen vor bleiben, wenn ein anderer, erreichbarer Paketmirror schneller und mit einer höheren Bandbreite verfügbar ist. Um einen Paketmirror einschätzen zu können, lädt apt-spy pro Spiegelserver etwa 10 MB an Daten herunter. Da die Liste der verfügbaren Paketmirrors mehr als einhundert Einträge umfasst, können Sie damit durchaus an das Limit ihrer Transferrate stoßen (wie bei uns im Test geschehen).

Im Ergebnis verringert sich die Bezugszeit von Paketen insgesamt. Insbesondere bei der Aktualisierung ihres Paketbestands und im Rahmen eines Distributionsupgrades (siehe „Distribution aktualisieren“ unter Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“) ist das deutlich spürbar.

apt-spy erzeugt dazu eine spezifische Liste der Paketquellen in der Datei /etc/apt/sources.list.d/apt-spy.list. Den Ausgangspunkt dafür bildet die aktuelle Liste der Paketmirrors von ftp.debian.org. Jeder darin enthaltene Eintrag wird von apt-spy auf dessen Erreichbarkeit von ihrem aktuellen Standort aus überprüft. Die vielversprechendsten Einträge landen in o.g. Liste.

apt-spy konfigurieren

Zu apt-spy gehört eine Konfigurationsdatei unter /etc/apt-spy.conf. Diese enthält die Länderkennungen sowie die Zuordnung von Länderkennungen und Kontinenten. Nachfolgender Ausschnitt zeigt die Bereiche für Nordamerika und Ozeanien.

Konfiguration von apt-spy für Nordamerika und Ozeanien (Ausschnitt). 

$ cat /etc/apt-spy.conf
...
North-America:

CA
US
MX

Oceania:

AU
NZ
...
$

Schalter und Beispiele

apt-spy versteht eine ganze Reihe von Schaltern zur Konfiguration, von denen wir Ihnen eine Auswahl vorstellen. Weitere Optionen entnehmen Sie bitte der Manpage zum Programm.

-d distribution
Debian-Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“), für die die Paketliste erstellt werden soll
-a area
geographische Region, aus der die Paketmirrors kommen sollen
-e Anzahl
early finish — legt die Anzahl der Paketmirrors fest, die Sie abfragen möchten
-p proxy
Proxyserver in der Schreibweise Hostname:Port
-s Land
eine Komma-separierte Liste von Länderkürzeln, aus der die Paketmirrors kommen sollen
update
Aktualisieren der Liste der Paketmirrors

Nun folgen eine Reihe von Beispielen aus der Praxis. Beispiel 1 zeigt Ihnen den schnellsten Debian-Paketmirror in Europa für die Veröffentlichung Debian stable:

Ermittlung der Debian-Paketmirrors für die Region Europa. 

# apt-spy -d stable -a Europe

SERVER: ftp.at.debian.org
Benchmarking FTP...
                Downloaded 9001094 bytes in 3.22 seconds
                Download speed: 2731.88 kB/sec

SERVER: debian.sil.at
Benchmarking FTP...
                Downloaded 9001094 bytes in 4.19 seconds
                Download speed: 2096.46 kB/sec

SERVER: debian.sil.at
Benchmarking FTP...
                Downloaded 9001094 bytes in 3.66 seconds
                Download speed: 2404.31 kB/sec

SERVER: gd.tuwien.ac.at
Benchmarking HTTP...
                Downloaded 9001094 bytes in 2.31 seconds
                Download speed: 3810.42 kB/sec
...
Writing new sources.list file: /etc/apt/sources.list.d/apt-spy.list
#

In Beispiel 2 sehen Sie, wie sie ähnliches für Deutschland ermitteln. Als Kürzel dient hier de für Deutschland:

Ermittlung der Debian-Paketmirrors für die Region Deutschland. 

# apt-spy -d stable -s de

SERVER: ftp.de.debian.org
Benchmarking FTP...
                Downloaded 8990025 bytes in 2.75 seconds
                Download speed: 3190.72 kB/sec

SERVER: debian.inf.tu-dresden.de
Benchmarking FTP...
                Downloaded 8990025 bytes in 3.32 seconds
                Download speed: 2643.16 kB/sec

...
Writing new sources.list file: /etc/apt/sources.list.d/apt-spy.list
#

Die dazu von apt-spy erzeugte Datei unter /etc/apt/sources.list.d/apt-spy.list sieht bspw. so aus:

Erzeugte Datei sources.list für Deutschland. 

# sources.list generated by apt-spy v3.2.2
#
# Generated using:
#
# apt-spy \
#       -d stable \
#       -s de
#
deb ftp://ftp.uni-erlangen.de/debian/ stable main #contrib non-free
deb-src ftp://ftp.uni-erlangen.de/debian/ stable main #contrib non-free
deb http://security.debian.org/ stable/updates main

Bitte beachten Sie, dass die ermittelten Paketmirrors stets von ihrem aktuellen Standort und der dort vorliegenden Netzwerkanbindung abhängen. Führen Sie das gleiche Kommando auf ihrem Linuxsystem aus, können die Ergebnisse von der hier im Buch gezeigten Ausgabe abweichen.

3.6. Automatisiertes Auswählen von Paketquellen

3.6.1. DNS Round Robin

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.

IP-Verteilung des primären Debian-Paketmirrors für die USA. 

$ host ftp.us.debian.org
ftp.us.debian.org has address 64.50.236.52
ftp.us.debian.org has address 128.61.240.89
ftp.us.debian.org has address 64.50.233.100
ftp.us.debian.org has IPv6 address 2610:148:1f10:3::89
$

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.

3.6.2. Paketquellen über GeoIP auswählen

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.

Abbildung 3.3. Standortlokalisierung über das GeoIP Tool [geoiptool]

werkzeuge/paketquellen-und-werkzeuge/geoiptool.png

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.

3.6.3. Immer per GeoIP: Security-Updates

Security-Updates kommen bei Debian 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 immer GeoIP per DNS und gibt stets eine Liste von Paketspiegeln auf demselben Kontinent zurück, auf dem Sie sich netztechnisch gerade aufhalten.

3.6.4. GeoIP per DNS

Mit dem Hostnamen cdn.debian.net[11] erreichen Sie seit vielen Jahren (fast) immer einen offiziellen Debian-Spiegelserver in ihrer Nähe. cdn.debian.net war daher für einige Jahre die Voreinstellung im Debian-Installer, wenn Sie nicht explizit einen anderen Paketmirror ausgewählt haben.

Die Nähe wird bei diesem System über die Quell-IP der DNS-Anfrage bestimmt und hängt somit auch davon ab, wo der zwischenspeichernde DNS-Server steht, an den die DNS-Anfrage gesendet wurde. Netzwerktechnisch betrachtet stehen diese DNS-Server im Normalfall immer unweit des anfragenden Rechners.

Da hier die Auswahl des Paketmirrors bereits auf DNS-Ebene passiert, funktioniert diese Methode nicht nur mit HTTP, sondern auch mit FTP und theoretisch sogar auch mit rsync. Allerdings bieten nicht alle Paketmirror den Inhalt auch per rsync an. Somit funktioniert cdn.debian.net stets zuverlässig mit HTTP als auch mit FTP in der /etc/apt/sources.list. Nachfolgendes Beispiel zeigt Eintragungen für Debian Wheezy mit HTTP wie auch FTP:

deb http://cdn.debian.net/debian/ wheezy main contrib non-free
deb ftp://cdn.debian.net/debian/ wheezy main contrib non-free

Eine tatsächliche Nähe zum zurückgegebenen Paketmirror ist jedoch nicht immer gegeben. Zeitweise funktioniert dieser Dienst in manchen Ländern auch weniger gut. Nachfolgend sehen Sie einige Beispiele für ausgewählte Regionen. Das erste Beispiel stammt aus Deutschland:

Erreichbarkeit des Paketmirrors cdn.debian.net von Deutschland aus. 

$ host cdn.debian.net
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 137.226.34.42
deb.cdn.araki.net has address 129.143.116.10
deb.cdn.araki.net has address 195.71.68.86
$

In Frankreich bekommen Sie ggf. die folgende Ausgabe:

Erreichbarkeit des Paketmirrors cdn.debian.net von Frankreich aus. 

$ host cdn.debian.net
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 91.121.124.139
$

Ein Beispiel aus Schweden:

Erreichbarkeit des Paketmirrors cdn.debian.net von Schweden aus. 

$ host cdn.debian.net
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 213.129.232.18
$

Machen Sie die Anfrage hingegen aus Großbritannien, kann es so aussehen:

Erreichbarkeit des Paketmirrors cdn.debian.net von Großbritannien aus. 

$ host cdn.debian.net
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 83.142.228.128
$

Für die Schweiz sah es zum Zeitpunkt unserer Recherche leider etwas enttäuschend aus. Der Dienst war nicht verfügbar — wie man sieht, funktionert der Dienst eben nicht überall perfekt.

Erreichbarkeit des Paketmirrors cdn.debian.net von der Schweiz aus. 

$ host cdn.debian.net
Host cdn.debian.net not found: 3(NXDOMAIN)
$

3.6.5. GeoIP per HTTP-Redirect

Raphael Geissert hat den Debian Redirector [Debian-Redirector] entwickelt, der eine Alternative zu cdn.debian.net darstellt. Ursprünglich lief dieser Dienst unter der URL http://http.debian.net/ außerhalb der Debian-internen Infrastruktur. Seit Mai 2015 ist der Dienst auf Debian-eigene Server umgezogen und dort unter http://httpredir.debian.org/ zu erreichen. Die ursprüngliche Adresse http://http.debian.net/ leitet seitdem automatisch auf http://httpredir.debian.org/ um. Tragen Sie als Paketquelle http://httpredir.debian.org/debian/ ein, sendet APT zuerst eine HTTP-Anfrage an httpredir.debian.org und bekommt als Antwort eine Weiterleitung an den eigentlichen Paketmirror. Die nachfolgende Ausschnitt zeigt den Eintrag für Debian 7 Wheezy in der Datei /etc/apt/sources.list:

deb http://httpredir.debian.org/debian/ wheezy main contrib non-free

Interessant ist auch die Netzwerkkommunikation, die (unbemerkt) im Hintergrund abläuft. Wir zeigen das anhand eines Beispiels aus der Schweiz genauer. Zur Analyse kommt das Kommando GET aus dem Paket libwww-perl zum Einsatz. Zu sehen ist, dass die Anfrage an httpredir.debian.org aufgelöst wird und eine Weiterleitung (Redirect) zum Debian-Paketmirror an der ETH Zürich erfolgt.

Auswertung der Netzwerkkommunikation bei der Auflösung der IP. 

$ GET -SUsed http://httpredir.debian.org/debian/
GET http://httpredir.debian.org/debian/
User-Agent: lwp-request/6.03 libwww-perl/6.04

302 Found
Connection: close
Date: Thu, 10 Jul 2014 00:32:59 GMT
Location: http://debian.ethz.ch/debian/
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/plain
Client-Date: Thu, 10 Jul 2014 00:32:59 GMT
Client-Peer: 46.4.205.44:80
Client-Response-Num: 1

GET http://debian.ethz.ch/debian/
User-Agent: lwp-request/6.03 libwww-perl/6.04

200 OK
Connection: close
Date: Thu, 10 Jul 2014 00:32:59 GMT
Server: Apache/2.2.22 (Debian)
Vary: Accept-Encoding
Content-Type: text/html;charset=UTF-8
Client-Date: Thu, 10 Jul 2014 00:32:59 GMT
Client-Peer: 129.132.53.171:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Title: Index of /debian
$

Von Vorteil ist hier die höhere Genauigkeit. Die GeoIP kann nicht nur auf den zwischenspeichernden DNS-Servern, sondern auch auf den anfragenden Rechner selbst angewendet werden. Dabei wird auch das genutzte Netzwerkprotokoll berücksichtigt. Nutzen Sie IPv6, erhalten Sie dann eine Empfehlung für einen passenden, IPv6-fähigen Paketmirror in ihrer Nähe [Debian-Mirror-Doku].

Desweiteren kann der Redirect auch in Abhängigkeit der angefragten Datei passieren. So werden z.B. Anfragen nach Paketen aus dem Bereich Backports nur an Paketmirrors weitergeleitet, die auch die Paketquellen für Backports spiegeln[12]. Darüber hinaus muss die Paketquelle nicht auf jeden Paketspiegel unter dem gleichen Pfad liegen. Möglich sind z.B. statt der Empfehlung /debian/ auch /pub/debian/ oder /mirror/debian/.

Das Verfahren mit HTTP-Weiterleitungen hat jedoch auch Nachteile. Einerseits funktioniert es ausschließlich per HTTP (oder HTTPS), da FTP keine Weiterleitungen kennt. Aus dieser Einschränkung leitet sich auch der Hostname httpredir.debian.org ab. Andererseits werden pro Paketliste sowie pro heruntergeladenem Paket stets zwei HTTP-Anfragen gesendet.

Da sich dieses Verfahren trotz der o.g. Einschränkung in der Praxis als zuverlässiger, flexibler, genauer und leichter wartbar erwies[13], setzt es sich gegenüber dem Dienst cdn.debian.net und somit innerhalb von Debian immer mehr als Voreinstellung durch.

3.6.6. Automatische Paketmirror-Auswahl per Mirror-Liste

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:

deb mirror://mirrors.ubuntu.com/mirrors.txt precise main restricted universe multiverse

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:

http://ubuntu.ethz.ch/ubuntu/
http://archive.ubuntu.csg.uzh.ch/ubuntu/
http://mirror.switch.ch/ftp/mirror/ubuntu/
http://archive.ubuntu.com/ubuntu/

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

http://ubuntu.lagis.at/ubuntu/
http://ubuntu.inode.at/ubuntu/
http://ubuntu.uni-klu.ac.at/ubuntu/
http://gd.tuwien.ac.at/opsys/linux/ubuntu/archive/
http://archive.ubuntu.com/ubuntu/

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

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:

deb mirror://mirrors.ubuntu.com/DE.txt trusty main restricted universe multiverse

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:

deb mirror://www.debian-paketmanagement.de/hetzner-mirrors.txt wheezy main contrib non-free

3.6.7. Welcher Paketmirror wird schlussendlich benutzt?

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.

Informationen zum tatsächlich genutzten Paketmirror bei der Verwendung von apt-get

# apt-get -o Debug::pkgAcquire::Worker=true install netselect-apt
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  netselect
The following NEW packages will be installed:
  netselect netselect-apt
0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
Starting method '/usr/lib/apt/methods/http'
...
  -> http:600%20URI%20Acquire%0aURI:%20http://ftp.ch.debian.org/debian/pool/main/n/netselect/netselect_0.3.ds1-25_amd64.deb%0aFilename:%20/var/cache/apt/archives/partial/netselect_0.3.ds1-25_amd64.deb%0a%0a
  <- http:102%20Status%0aURI:%20http://ftp.ch.debian.org/debian/pool/main/n/netselect/netselect_0.3.ds1-25_amd64.deb%0aMessage:%20Connecting%20to%20ftp.ch.debian.org%20(129.132.53.171)
...
#

Deutlich übersichtlicher ist jedoch die Demo-Seite des Debian Redirectors [Debian-Redirector]. Neben dem aktuellen Standort — hier Berlin — zeigt Abbildung 3.4, „Auswahl des Paketmirrors über den Debian Redirector [Debian-Redirector]“ die ausgewählten Paketquellen als Hostname an.

Abbildung 3.4. Auswahl des Paketmirrors über den Debian Redirector [Debian-Redirector]

werkzeuge/paketquellen-und-werkzeuge/debian-net-demo.png

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 Abschnitt 3.5, „Am besten erreichbaren Paketmirror finden“ ausführlich vor.

3.7. apt-setup — Erstellung der Paketliste während der Installation

ToDo: Abschnitt veraltet?

Bei der Erst- oder Neuinstallation des Debian-Systems stellt der Debian Installer eine /etc/apt/sources.list zusammen, da diese ja bis dato noch nicht existiert. Bei der textbasierten Installation kommt das Programm apt-setup [Debian-Paket-apt-setup] zum Einsatz. Die Auswahl und Konfiguration der Paketquellen erfolgt dabei über diese schlichte Ncurses-Oberfläche.

Einschränkung zur Verwendung

Verwenden Sie dieses Programm nicht auf einem bereits installierten System — es ist nur für den Debian Installer gedacht. Daher beinhaltet der Paketname auch das Suffix -udeb (siehe Übergangs- und Metapakete in Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“).

Abbildung 3.5. Auswahl der Paketquellen über apt-setup

werkzeuge/paketquellen-und-werkzeuge/apt-setup.png

3.8. Physische Installationsmedien mit apt-cdrom einbinden

Nutzen Sie keine netzbasierte Installation, sondern greifen auf die altbewährte Form anfassbarer Installationsmedien zurück, ist in diesem Fall das Programm apt-cdrom aus dem Paket apt die richtige Wahl (das Paket mit dem ähnlichen Namen apt-cdrom-setup [Debian-Paket-apt-cdrom-setup] ist lediglich für den Debian Installer vorgesehen). Damit fügen Sie ein bereitstehendes Installationsmedium zu Ihrer Liste der Paketquellen in der Datei /etc/apt/sources.list (siehe Abschnitt 3.3, „/etc/apt/sources.list verstehen“) hinzu.

Während vor wenigen Jahren noch eine CD gebräuchlich war, ist es heute aufgrund der Datenmenge eher eine DVD, eine Blu-ray oder ein entsprechendes Abbild eines Datenträgers, kurz genannt ISO-Image. apt-cdrom kann mit allen diesen Medien und Formaten umgehen, d.h. auch mit ISO-Images, welches Sie bspw. auf einem USB-Stick vorbereitet haben. Letzteres zählt häufig zu den ersten Schritten einer Netzwerkinstallation.

Die Alternative zu apt-cdrom ist, alle neuen Medien von Hand nachzutragen. Das kann ein wenig aufwendig werden. apt-cdrom erleichtert Ihnen die Arbeit und übernimmt folgende Schritte:

  • Medium (CD, DVD, Blu-ray, ISO-Image) auf Vollständigkeit und dessen Struktur überprüfen
  • Validierung der Indexdateien des Mediums

Voraussetzung dafür ist jedoch, dass sich das Medium bereits im Laufwerk befindet, das Medium eingehängt ist und das dazugehörige Gerät (DVD-Laufwerk, etc.) einen passenden Mountpoint in der Datei /etc/fstab hat.

apt-cdrom unterstützt die folgenden nützlichen Schalter und Aufrufe:

apt-cdrom
kurze Information (Hilfeseite) zu apt-cdrom
apt-cdrom add
Installationsmedium hinzufügen
apt-cdrom -d Verzeichnis add (Langform --cdrom)
Installationsmedium aus dem angegebenen Verzeichnis hinzufügen, bspw. von einem USB-Stick
apt-cdrom ident
Identität des Installationsmediums ausgeben (siehe nachfolgende Beispielausgabe)
apt-cdrom -r (Langform --rename)
Umbenennen eines Mediums. Ändert den Namen eines Mediums oder überschreibt den Namen, der dem Medium gegeben wurde.

Identifikation eines Installationsmediums. 

# apt-cdrom ident
Verwendeter CD-ROM-Einbindungspunkt: /media/cdrom/
CD-ROM wird eingebunden.
Identifizieren ... [3e81e0fb1b74074c6e427e18afef3ab7-2]
Gespeicherte Kennzeichnung:
Einbindung der CD-ROM wird gelöst ...
#

3.9. Einträge mit add-apt-repository im Griff behalten

add-apt-repository ist ein Python-Skript, um Einträge automatisiert und damit leichter zur Liste der Paketquellen (siehe Abschnitt 3.3, „/etc/apt/sources.list verstehen“) hinzuzufügen oder auch wieder auszutragen. Es öffnet dazu die bestehende Liste der Paketquellen, ergänzt bzw. korrigiert die Einträge und überprüft diese zusätzlich auf Echtheit (siehe Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“). Fehlende GPG-Schlüssel trägt es dabei automatisch in ihrem lokalen Schlüsselring nach. Indem es die vielen Einzelschritte kombiniert, spart es Zeit und lässt sich darüber hinaus auch problemlos zur Automatisierung in ihre eigenen Skripte integrieren.

add-apt-repository ist bis Debian 7 Wheezy Bestandteil des Pakets python-software-properties [Debian-Paket-python-software-properties] und ab Debian 8 Jessie in software-properties-common [Debian-Paket-software-properties-common]. Es stellt graphische Komponenten bereit, die bspw. auch im Rahmen von Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) und dem Ubuntu Software Center (siehe Abschnitt 6.4.4, „Ubuntu Software Center“) zum Einsatz kommen. Diese graphischen Komponenten beschreiben wir ausführlich unter Einstellungen mit Synaptic und im Ubuntu Software Center in Abschnitt 3.10, „Einstellungen mit Synaptic und im Ubuntu Software Center“.

Um die Handhabung auf der Kommandozeile noch weiter zu vereinfachen und insbesondere die Vertauschung der beiden Begriffe apt und add abzufangen, existiert zusätzlich das Kommando apt-add-repository. Dies ist durch einen symbolischen Link auf add-apt-repository realisiert.

3.9.1. Aufruf und Optionen

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 Abschnitt 3.3, „/etc/apt/sources.list verstehen“):

add-apt-repository deb uri distribution [component1] [component2] [...]

3.9.2. Beispiele

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

add-apt-repository 'deb http://packages.linuxmint.com/ petra main'

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

add-apt-repository ppa:gnome-desktop

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:

add-apt-repository --remove 'https://packages.medibuntu.org non-free'

3.10. Einstellungen mit Synaptic und im Ubuntu Software Center

Auch mittels Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) und dem Ubuntu Software Center (siehe Abschnitt 6.4.4, „Ubuntu Software Center“) können Sie die Datei /etc/apt/sources.list anpassen. Dazu öffnen Sie den entsprechenden Dialog unter dem Menüpunkt EinstellungenPaketquellen. Unter Gnome/GTK erfolgt daraufhin ein Aufruf des Programms software-properties-gtk aus dem bereits weiter oben genannten Projekt Python Software Properties [Debian-Paket-python-software-properties]. Das Pendant unter KDE heißt software-properties-kde.

Über die verschiedenen Reiter stellen Sie die gewünschten Paketquellen ein. Abbildung 3.6, „Einstellung der Komponenten in Synaptic“ zeigt die Einstellungen zu den Standard-Debian-Repositories, Abbildung 3.7, „Festlegung der Paketquellen für andere Software im Ubuntu Software Center“ zu weiteren Paketquellen anhand des Ubuntu Software Center.

Abbildung 3.6. Einstellung der Komponenten in Synaptic

werkzeuge/paketquellen-und-werkzeuge/synaptic-paketquellen.png

Abbildung 3.7. Festlegung der Paketquellen für andere Software im Ubuntu Software Center

werkzeuge/paketquellen-und-werkzeuge/ubuntu-software-center-repositories.png

3.11. Debian und Ubuntu Sources List Generator

Möchten Sie ihre Liste der Paketquellen nicht von Hand zusammentragen, sondern stattdessen über eine Software erstellen lassen, bieten sich der Debian Sources List Generator [Debian-Sources-List-Generator] und der Ubuntu Sources List Generator [Ubuntu-Sources-List-Generator] von Jonhnatha Trigueiro an. Dabei handelt es sich um eine JavaScript-Anwendung, die Sie über ihren Webbrowser benutzen. Als Ergebnis erhalten Sie am Ende eine Textdatei, die Sie überprüfen und in Ihr System einpflegen können. Vor der Übernahme empfehlen wir, für alle Fälle von der derzeit genutzten Datei eine Sicherheitskopie anzulegen, sodass Sie im Bedarfsfall darauf zurückgreifen können.

3.11.1. Feinheiten für Debian

Zunächst wählen Sie ihre geographische Region aus, danach die Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“), die Architektur (siehe Abschnitt 1.2, „Debian-Architekturen“) Ihres Systems und die Distributionsbereiche (siehe Abschnitt 2.9, „Distributionsbereiche“). In der rechten Spalte wählen Sie die gewünschten Repositories von Drittanbietern aus, sofern Sie dazu Bedarf haben (siehe Abbildung 3.8, „Auswahl der Komponenten im Debian Sources List Generator“). Über den Knopf Generate sources list erstellt Ihnen das Programm eine passende Liste der Paketquellen (siehe Abbildung 3.9, „Erzeugte sources.list durch den Debian Sources List Generator“). Diese Datei können Sie nun als neue /etc/apt/sources.list in Ihr System übernehmen.

Abbildung 3.8. Auswahl der Komponenten im Debian Sources List Generator

werkzeuge/paketquellen-und-werkzeuge/debian-sources-list-generator.png

Abbildung 3.9. Erzeugte sources.list durch den Debian Sources List Generator

werkzeuge/paketquellen-und-werkzeuge/debian-sources-list-generator-list.png

3.11.2. Feinheiten für Ubuntu

Die Abfolge ist ähnlich zu Debian, nur wesentlich umfangreicher. Nach der geographischen Region und der Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“) wählen Sie die Distributionsbereiche (siehe Abschnitt 2.9, „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 Abschnitt 1.2, „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.

Abbildung 3.10. Auswahl der Komponenten im Ubuntu Sources List Generator

werkzeuge/paketquellen-und-werkzeuge/ubuntu-sources-list-generator.png

3.12. Paketquelle auf Echtheit überprüfen

3.12.1. Basiswissen

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 Abschnitt 2.10, „Veröffentlichungen“), als auch die Paketquellen (siehe Abschnitt 3.1, „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 Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“).

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.

3.12.2. Schlüsselverwaltung mit apt-key (Überblick)

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 (Abschnitt 1.2.1, „Debian-Ports-Projekt“.

3.12.3. Unterkommandos von apt-key

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 Abbildung 3.11, „Auflistung der gespeicherten, vertrauenswürdigen Schlüssel“).

Mit dem Aufruf apt-key finger zeigen Sie zusätzlich deren Fingerabdruck an (siehe Abbildung 3.12, „Darstellung der Fingerabdrücke der vertrauenswürdigen Schlüssel“). Mit apt-key export Schlüssel geben Sie 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.

Abbildung 3.11. Auflistung der gespeicherten, vertrauenswürdigen Schlüssel

werkzeuge/paketquellen-und-werkzeuge/apt-key-list.png

Abbildung 3.12. Darstellung der Fingerabdrücke der vertrauenswürdigen Schlüssel

werkzeuge/paketquellen-und-werkzeuge/apt-key-finger.png

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.

3.12.4. Beispiel: Ergänzung eines Schlüssels

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 Abschnitt 3.3, „/etc/apt/sources.list verstehen“):

deb http://deb.opera.com/opera stable non-free

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:

Bezug des Schlüssels zur Paketquelle, hier für Opera mittels wget

# wget http://deb.opera.com/archive.key
--2014-06-17 23:54:43--  http://deb.opera.com/archive.key
Auflösen des Hostnamen »deb.opera.com (deb.opera.com)«... 185.26.183.130
Verbindungsaufbau zu deb.opera.com (deb.opera.com)|185.26.183.130|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 2437 (2,4K) [application/pgp-keys]
In »»archive.key«« speichern.

100%[=======================================================================>] 2.437       --.-K/s   in 0s

2014-06-17 23:54:43 (63,0 MB/s) - »»archive.key«« gespeichert [2437/2437]
#

Unverschlüsselte Übertragung von Schlüsseln

Bitte beachten Sie, dass dieser Schlüssel jedoch nicht über gesicherte Kanäle (z.B. per HTTPS) heruntergeladen wurde und Sie damit nicht hundertprozentig sicher sein können, dass dieser Schlüssel wirklich von Opera ist. Leider scheint der Schlüssel auch nicht mit allzu vielen Signaturen ausgestattet zu sein, sodass eine Verifizierung über die Signaturen ebenfalls nicht möglich ist.

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:

Hinzufügen des bezogenen Schlüssels mittels apt-key

# apt-key add archive.key
OK
#

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.

3.12.5. Alternative Benutzerschnittstellen zur APT-Schlüsselverwaltung

Neben dem Kommandozeilenprogramm apt-key existieren auch noch zwei interaktive Bedienoberflächen dazu: das auf GTK aufbauende gui-apt-key aus dem gleichnamigen Paket [Debian-Paket-gui-apt-key] und das auf Ncurses aufbauende curses-apt-key [curses-apt-key]. Beide besprechen wir hier nur kurz.

gui-apt-key starten Sie zunächst als Benutzer root oder mittels sudo. Im Dialogfenster (Abbildung 3.13, „Hauptfenster von gui-apt-key“) sehen Sie die Inhaber und das Ablaufdatum aller von APT als vertrauenswürdig eingestuften GPG-Schlüssel. Über das Menü haben Sie die Möglichkeit, weitere Schlüssel aus Dateien zu importieren, die Schlüssel gegen den Debian-Archiv-Schlüsselring zu aktualisieren (analog zu apt-key update), einen Schlüssel aus der Liste zu löschen oder Details wie einen Fingerabdruck zu einem Schlüssel anzeigen zu lassen.

Abbildung 3.13. Hauptfenster von gui-apt-key

werkzeuge/paketquellen-und-werkzeuge/gui-apt-key.png

curses-apt-key nutzt dieselben Backend-Bibliotheken wie gui-apt-key. Daher bietet es die gleichen Funktionalitäten, braucht jedoch dazu keine graphische Umgebung und eignet sich daher insbesondere für die Nutzung auf Servern (siehe Abbildung 3.14, „curses-apt-key in einem xterm“).

Abbildung 3.14. curses-apt-key in einem xterm

werkzeuge/paketquellen-und-werkzeuge/curses-apt-key.png

Derzeit ist curses-apt-key noch nicht Bestandteil von Debian und nur auf GitHub verfügbar [curses-apt-key]. Eine Aufnahme in Debian ist jedoch geplant [curses-apt-key-itp].

3.13. Liste der verfügbaren Pakete aktualisieren

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:

  • Das klassische Kommando, das auch stets auf älteren Veröffentlichungen funktioniert, ist apt-get update. Auf neueren Veröffentlichungen, die das Kommando apt kennen, funktioniert auch apt update (siehe Abschnitt 6.2.2, „APT“).
  • aptitude (siehe Abschnitt 6.3.2, „aptitude) gestattet einen Aufruf über die Kommandozeile mittels aptitude update. Möchten Sie die Paketliste aktualisieren und danach interaktiv im Text-Modus weiterarbeiten, so rufen Sie aptitude -u auf. Sind Sie bereits im interaktiven Text-Modus von aptitude, sorgt der Tastendruck u für frische Paketlisten und die aktualisierte Darstellung in aptitude. Alternativ stoßen Sie die Aktion über den Menüeintrag Aktionen -> Paketlisten aktualisieren an.
  • Bei Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) verbirgt sich dieser Vorgang hinter dem Menüeintrag Bearbeiten -> Paketinformationen neu laden. Alternativ nutzen Sie dafür die Tastenkombination Ctrl+R.
  • Im Programm SmartPM (siehe Abschnitt 6.4.3, „Smart Package Management (SmartPM)“) lösen Sie die Aktualisierung für alle Paketquellen über den Menüpunkt File -> Update channels aus. Möchten Sie nur eine einzige Paketquelle auf den neuesten Stand bringen, wählen Sie stattdessen zunächst File -> Update selected channels ... aus und entscheiden danach, welche Paketquelle Ihres Erachtens eine Auffrischung verdient hat (siehe dazu Abbildung 3.15, „Auflistung der verfügbaren Paketquellen in SmartPM“).

Abbildung 3.15. Auflistung der verfügbaren Paketquellen in SmartPM

werkzeuge/paketquellen-und-werkzeuge/smartpm-paketquellen-auswaehlen.png

Aktualisierung mit dpkg

dpkg kennt auch die beiden Schalter --update-avail und --merge-avail. Es setzt dafür lokal bereitstehende Paketlisten voraus, mit denen es dann seine Paketdatenbank unter /var/lib/dpkg/available aktualisiert. Diesen Schalter von dpkg betrachten wir hier nicht näher.

Führen Sie eines der o.g. Aufrufe aus, wird zunächst die Liste der Paketquellen in /etc/apt/sources.list (siehe Abschnitt 3.3, „/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 Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“). Mit Hilfe des GPG-Schlüssels für die Paketquelle prüfen apt-get bzw. aptitude automatisch deren Authentizität und falls ohne Beanstandung, vereinigen sie die bezogene Liste mit der bereits bestehenden, lokalen Paketliste (siehe Abschnitt 3.14, „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:

Aktualisierung der Paketliste durch apt-get update

# apt-get update
OK   http://ftp.de.debian.org wheezy Release.gpg
Holen: 1 http://security.debian.org wheezy/updates Release.gpg [836 B]
Holen: 2 http://security.debian.org wheezy/updates Release [102 kB]
OK   http://ftp.de.debian.org wheezy Release
OK   http://ftp.de.debian.org wheezy/main Sources
Holen: 3 http://security.debian.org wheezy/updates/main Sources [79,2 kB]
OK   http://ftp.de.debian.org wheezy/contrib Sources
OK   http://ftp.de.debian.org wheezy/non-free Sources
OK   http://ftp.de.debian.org wheezy/main i386 Packages
Holen: 4 http://security.debian.org wheezy/updates/contrib Sources [14 B]
OK   http://ftp.de.debian.org wheezy/contrib i386 Packages
Holen: 5 http://security.debian.org wheezy/updates/non-free Sources [14 B]
OK   http://ftp.de.debian.org wheezy/non-free i386 Packages
Holen: 6 http://security.debian.org wheezy/updates/main i386 Packages [150 kB]
OK   http://ftp.de.debian.org wheezy/contrib Translation-en
OK   http://ftp.de.debian.org wheezy/main Translation-de_DE
OK   http://ftp.de.debian.org wheezy/main Translation-de
Holen: 7 http://security.debian.org wheezy/updates/contrib i386 Packages [14 B]
OK   http://ftp.de.debian.org wheezy/main Translation-en
Holen: 8 http://security.debian.org wheezy/updates/non-free i386 Packages [14 B]
OK   http://ftp.de.debian.org wheezy/non-free Translation-en
Holen: 9 http://security.debian.org wheezy/updates/contrib Translation-en [14 B]
Holen: 10 http://security.debian.org wheezy/updates/main Translation-en [88,7 kB]
Holen: 11 http://security.debian.org wheezy/updates/non-free Translation-en [14 B]
Es wurden 421 kB in 0 s geholt (428 kB/s).
Paketlisten werden gelesen... Fertig
#

Überprüfung der Paketsignaturen

Konnten bei der Aktualisierung für neue Paketlisten keine gültigen Signaturen gefunden werden, wird eine Warnung ausgegeben. Entsprechende Zeilen beginnen mit W:. Pakete, die nicht korrekt signiert sind, können Schadcode enthalten und sollten nicht installiert werden. Zur Überprüfung auf korrekte Pakete tragen Sie bitte den passenden GPG-Key nach. Näheres dazu finden Sie unter „Bezogenes Paket verifizieren“ in Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“.

Veröffentlichung wechseln

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 Abschnitt 8.39, „Pakete aktualisieren“ bzw. „Distribution aktualisieren“ in Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“.

3.14. Lokale Paketliste und Paketcache

Die Paketverwaltung — genauer APT — pflegt lokale Paketlisten im Verzeichnis /var/lib/apt/lists. Diese Paketlisten dienen als Nachschlagewerk für APT. Wollen Sie den Paketbestand auf Ihrem Debian-System ändern, benutzt APT diese Paketliste, um die Existenz, die Verfügbarkeit von einer Paketquelle und die Abhängigkeiten eines Pakets zu bestimmen, bevor diese tatsächlich bezogen werden. Installieren Sie ein Paket nach (Abschnitt 8.36, „Pakete installieren“), weiß APT aus der lokalen Paketliste, von welcher Paketquelle und unter welcher URL es dieses herunterladen kann.

Die hier verwendete mehrstufige Vorgehensweise hat ihren Ursprung in der Anfangszeit von Debian, bei der der Internetzugang und dessen (nahezu) permanenter Verfügbarkeit noch nicht so selbstverständlich wie heute waren. Lokal verfügbare Informationen waren (und sind) stets mit geringerer Verzögerung nutzbar als externe Ressourcen und reduzieren zudem die Netzlast.

Die nachfolgende Auflistung ist typisch, wenn Sie als Paketmirror ftp.de.debian.org und die Distributionsbereiche main, contrib und non-free benutzen:

Übersicht zu den lokalen Dateien, in denen die Paketlisten hinterlegt sind. 

$ ls /var/lib/apt/lists
ftp.de.debian.org_debian_dists_wheezy_contrib_source_Sources
ftp.de.debian.org_debian_dists_wheezy_main_source_Sources
ftp.de.debian.org_debian_dists_wheezy_non-free_source_Sources
ftp.de.debian.org_debian_dists_wheezy_Release
ftp.de.debian.org_debian_dists_wheezy_Release.gpg
lock
partial/
security.debian.org_dists_wheezy_updates_contrib_binary-i386_Packages
security.debian.org_dists_wheezy_updates_contrib_i18n_Translation-en
security.debian.org_dists_wheezy_updates_contrib_source_Sources
security.debian.org_dists_wheezy_updates_main_binary-i386_Packages
security.debian.org_dists_wheezy_updates_main_i18n_Translation-en
security.debian.org_dists_wheezy_updates_main_source_Sources
security.debian.org_dists_wheezy_updates_non-free_binary-i386_Packages
security.debian.org_dists_wheezy_updates_non-free_i18n_Translation-en
security.debian.org_dists_wheezy_updates_non-free_source_Sources
security.debian.org_dists_wheezy_updates_Release
security.debian.org_dists_wheezy_updates_Release.gpg
$

Für jede Paketquelle aus /etc/apt/sources.list wird eine eigene, lokale Datei gepflegt. Diese ist eine Textdatei und beinhaltet alle Informationen zu den beziehbaren Paketen, bspw. den genauen Paketnamen und dessen Version (Abschnitt 2.11, „Benennung einer Paketdatei“), den Maintainer des Pakets, die Paketabhängigkeiten zum Bauen des Pakets, die genutzte Architektur (Abschnitt 1.2, „Debian-Architekturen“), das Format des Debianpakets sowie die Checksummen der Pakete und das Sourcepaket (Abschnitt 2.7, „Debian-Pakete (Varianten)“), aus der das Paket entstanden ist. Danach folgen die Projektwebseite sowie das Verzeichnis, in dem das Paket auf dem Paketmirror abgelegt ist. Zum Schluss stehen die Priorität, der Distributionsbereich (Abschnitt 2.9, „Distributionsbereiche“) und die Paketkategorie (Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“). Nachfolgender Kasten zeigt die Informationen anhand des Pakets easyspice aus der Paketkategorie Elektronik (electronics).

Paketinformationen zum Paket easyspice

Package: easyspice
Binary: easyspice
Version: 0.6.8-2
Maintainer: Gudjon I. Gudjonsson <gudjon@gudjon.org>
Build-Depends: debhelper (>= 5), autotools-dev, libgtk2.0-dev, quilt
Architecture: any
Standards-Version: 3.7.3
Format: 1.0
Files:
 2a6ef8e1bd3e38220d44754e107c55ca 1037 easyspice_0.6.8-2.dsc
 6ffaab8c2dcdfc30ecdca52f3c8bcded 201627 easyspice_0.6.8.orig.tar.gz
 e4b3a00ad900341424cb6052e9f56a53 2607 easyspice_0.6.8-2.diff.gz
Checksums-Sha1:
 d76bcb68824a1866598bc453c81af2e0c4a4366d 1037 easyspice_0.6.8-2.dsc
 37ae8dea4522254c3de25f300f6fc9b568b87c10 201627 easyspice_0.6.8.orig.tar.gz
 ec13581034d9ef441a2cd7acddc0f5289c5f6c57 2607 easyspice_0.6.8-2.diff.gz
Checksums-Sha256:
 5b119deafa50846c6736b8b63e0be8c18e407e18b31c17a43590e2301cc39bec 1037 easyspice_0.6.8-2.dsc
 55158436e05e372d48e03e59edc2dc2b49fbf366629a2943b265eb4562f1e975 201627 easyspice_0.6.8.orig.tar.gz
 7c5d3460457e89f69d050e42d394a89d95536b1efd178c99c49e505e7807f3fa 2607 easyspice_0.6.8-2.diff.gz
Homepage: http://easy-spice.sourceforge.net
Directory: pool/contrib/e/easyspice
Priority: source
Section: contrib/electronics

TODO: Querverweis auf cron-apt und /etc/cron.daily/apt.

Die Paketlisten ändern sich, wenn Aktualisierungen sowie neue Versionen von Paketen verfügbar werden und die Paketquellen auf den Spiegelservern entsprechend aktualisiert wurden. Daher raten wir Ihnen, die lokalen Paketlisten in regelmäßigen Abständen ebenfalls zu aktualisieren, bspw. mit den Aufrufen apt-get update, aptitude update oder einem anderen Werkzeug zur Paketverwaltung (Kapitel 6, Werkzeuge zur Paketverwaltung (Überblick)). Wie das genau vorsichgeht, erklären wir unter Liste der verfügbaren Pakete aktualisieren in Abschnitt 3.13, „Liste der verfügbaren Pakete aktualisieren“ genauer.

Sollte die Aktualisierung fehlschlagen, könnte sich die Paketliste in einem inkonsistenten Zustand befinden. Wie Sie mit dieser Situation umgehen, erklären wir Ihnen unter Lokale Paketliste reparieren in Abschnitt 3.15, „Lokale Paketliste reparieren“ genauer.

3.15. Lokale Paketliste reparieren

Es kann vorkommen, dass eine lokale Paketliste, die im Verzeichnis /var/lib/apt/lists liegt, bei deren Aktualisierung (siehe Abschnitt 3.13, „Liste der verfügbaren Pakete aktualisieren“) kaputtgeht. Das kommt sehr selten vor, aber bspw. dann, wenn nicht mehr genügend freier Speicherplatz für die neue Paketliste zur Verfügung steht oder das Entpacken der komprimierten Liste fehlschlägt. Sie bekommen das mit, wenn APT jammert und in Folge seine Arbeit verweigert.

APT versucht von sich aus, eine defekte oder nicht mehr vorhandene Liste wieder zu reparieren. Dazu beauftragen Sie APT mit dem Kommando apt-get update. Es bezieht die aktuellen Paketlisten von den in /etc/apt/sources.list angebenen Paketquellen und ersetzt die bereits bestehenden lokalen Paketlisten. Falls diese nicht mehr vorhanden sein sollten, legt APT diese Listen neu an.

Ist das erfolglos, räumen Sie als nächsten Schritt das Verzeichnis /var/lib/apt/lists/partial auf. Darin hinterlegt APT alle Zwischenstände und Teillisten. Löschen Sie dazu in besagtem Verzeichnis sämtliche Dateien und wiederholen danach das Kommando apt-get update.

Wenn das noch nicht geholfen hat, bereinigen Sie auch das Verzeichnis /var/lib/apt/lists. Danach wiederholen Sie das Kommando apt-get update.

Sollte das Vorgehen immer noch nicht von Erfolg gekrönt sein, warten Sie bitte sieben Stunden und wiederholen danach das Kommando apt-get update erneut. Hintergrund für die Bitte um Geduld ist die Erneuerung der Debian-Paketquellen auf den Paketmirrors (siehe Abschnitt 3.4, „Geeigneten Paketmirror auswählen“). Diese Erneuerung erfolgt automatisiert alle sechs Stunden und bereinigt auch eventuelle Inkonsistenzen der Paketlisten auf dem Paketmirror. Um auch sicherzugehen, dass die Liste der Paketquellen auf dem neuesten Stand ist, warten Sie lieber einen kleinen Moment länger.

3.15.1. Aktualität des Mirrors überprüfen

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 unter dem Debian Mirror Checker [Debian-Mirror-Checker] (siehe Abbildung 3.16, „Status der verschiedenen Debian-Paketmirror“).

Abbildung 3.16. Status der verschiedenen Debian-Paketmirror

werkzeuge/paketquellen-und-werkzeuge/debian-mirror-checker.png

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



[9] Die aktuelle Konfiguration des APT-Repositories erlaubt nur die Verwendung von stable als Veröffentlichung. Verwenden Sie z.B. jessie anstatt von stable, so beschwert sich APT, dass dies nicht vorgesehen sei.

[10] Die Auswahl des Mirrors erfolgte aus zwei Gründen – erstens tief verwurzeltem Lokalpatriotismus von Frank, und zweitens aus dem angebotenen Leistungsumfang heraus. Von diesem Mirror bekommen Sie das ganze Debian-Spektrum.

[11] CDN steht für Content Distribution Network

[12] Dies ist nur noch für Debian 6 Squeeze relevant. Ab Debian 7 Wheezy sind die Backports in den normalen Debian-Paketquellen enthalten.

[13] Es ist wesentlich leichter installierbar als ein autoritativer DNS-Server für eine bestimmte Zone und der Quellcode ist per Git verfügbar.

[14] Um keine unübersichtlich langen Beispiele abzudrucken, wurden hier absichtlich die beiden Beispiele aus dem deutschsprachigen Raum gewählt, die relativ kurze Listen ergeben.

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

Kapitel 4. Debian-Paketformat im Detail

4.1. Konzepte und Ideen dahinter

Die Paketbeschreibung ist eine Textdatei[16]. Die Paketbeschreibung in den Paketen selbst erfolgt in englischer Sprache, wird aber für die Paketlisten auf den Spiegelservern von Debians Übersetzungsteams auch in andere Sprachen übersetzt.

Jedes Element der Beschreibung ist ein Schlüssel-Wert-Paar, wobei die Trennung zwischen Schlüssel und Wert durch einen Doppelpunkt erfolgt. Der Schlüssel ist ein aus der Umgangssprache abgeleiteter Begriff, der die Relation zwischen zwei oder mehr Paketen näher beschreibt. Wert ist hingegen eine Aufzählung von Paketen, die mit einem Komma voneinander getrennt werden. Ein ähnliches Konzept kommt bei den Kopfzeilen von E-Mails zum Tragen.

Zusätzlich kann ein Wert mit einer Aussage zu einer bestimmten Softwareversion ergänzt worden sein. Eine solche versionierte Abhängigkeit kann unterschiedliche Relationen umfassen. Tabelle 4.1, „Relationen für versionierte Abhängigkeiten“ zeigt die derzeit zulässigen Operatoren samt einem Beispiel aus der Praxis.

Tabelle 4.1. Relationen für versionierte Abhängigkeiten

Operator Beschreibung Beispiel

<<

früher als

xpdf-utils (<< 3.00)

<=

früher oder gleich

python-cairo (<= 1.85)

=

exakt gleich

xfwm4 (= 4.1)

>=

gleich oder später

libc6 (>= 2.4)

>>

später als

libaa1 (>> 1.4)


4.1.1. Binärpakete

Die folgenden Schlüsselworte werden in Binärpaketen (siehe Abschnitt 2.7.1, „Binärpakete (deb)“) und den Paketlisten von diesen verwendet:

Package
zu dt.: Paket; Name des Pakets ohne Versionsnummer und Architektur, siehe auch Benennung eines Debian-Pakets in Abschnitt 2.11, „Benennung einer Paketdatei“
Source
zu dt.: Quelle; Name des Quellpakets („source package“), aus dem das Binärpaket gebaut wurde, siehe auch Sourcepakete in Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“
Version
zu dt.: Version oder Variante; Versionsnummer des Pakets, siehe Benennung eines Debian-Pakets in Abschnitt 2.11, „Benennung einer Paketdatei“
Architecture
zu dt. Architektur oder Plattform; Basis, für die das Paket gebaut wurde oder all, falls das Paket architekturunabhängig ist, siehe Debian-Architekturen in Abschnitt 1.2, „Debian-Architekturen“
Maintainer
zu dt.: Betreuer, Verantwortlicher; Für das Paket verantwortliche Person oder Gruppe („Maintainer“ des Pakets) und dessen Erreichbarkeit als E-Mail-Adresse (siehe auch Paket nach Maintainer finden in Abschnitt 8.21, „Paket nach Maintainer finden“)
Homepage
zu dt.: Internetpräsenz; Webseite des Projekts der paketierten Software oder Daten
Installed-Size
zu dt.: Installationsgröße; Speicherplatz, den das Paket auf dem Zielsystem belegen wird, nachdem es dort installiert wurde
Depends
zu dt.: hängt ab von; Name der installierten und konfigurierten Pakete und ggf. deren Versionsnummer, von dem das vorliegende Paket abhängt
Pre-Depends
zu dt.: hängt ab vorher von; Name der installierten und konfigurierten Pakete und ggf. deren Versionsnummer, von dem das vorliegende Paket und dessen Installationsskripte abhängen. Dies bedeutet, dass diese Abhängigkeiten vollständig installiert und ausgepackt sein müssen, bevor das Paket von dpkg ausgepackt werden darf.
Recommends
zu dt.: empfiehlt; Name der Pakete, welche als Ergänzung empfohlen werden und in den meisten Fällen ebenfalls gebraucht werden. Es ist ein Gegenstück zum Schlüsselwort Enhances.
Suggests
zu dt.: schlägt vor; Name der Pakete, welche als Ergänzung empfohlen werden. Es ist ein Gegenstück zum Schlüsselwort Enhances
Conflicts
zu dt.: kollidiert bzw. steht in Konflikt mit; Name der Pakete und ggf. deren Versionsnummer, mit denen es nicht gleichzeitig installiert sein darf
Breaks
zu dt.: bricht, verhindert, beschädigt; Name der Pakete und ggf. deren Versionsnummer, mit denen es nicht gleichzeitig verwendet werden kann
Enhances
zu dt.: erweitert, ergänzt, wertet auf; Benennt das Paket, welches es erweitert. Es ist das Gegenstück zu den Schlüsselworten Suggests und Recommends
Replaces
zu dt.: ersetzt; Name der Pakete, dessen Dateien es (teilweise) ersetzt
Provides
zu dt.: stellt bereit; Name der virtuellen Pakete, welche es bereitstellt, siehe Virtuelle Pakete in Abschnitt 2.7.5, „Virtuelle Pakete“
Section
zu dt.: Sektion oder Paketkategorie, in die das Paket einsortiert ist, siehe Paketkategorien in Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“
Priority
zu dt.: Priorität; Prioritätsstufe des Pakets, siehe Paket-Priorität und essentielle Pakete in Abschnitt 2.13, „Paket-Priorität und essentielle Pakete“
Essential
zu dt.: essentiell; Ihr Debian-System kann kaputt gehen, wenn dieses Paket entfernt wird, siehe dazu auch Markierung Essentiell in Abschnitt 2.13.6, „Markierung „essentiell“ (essential)“
Description
zu dt.: Beschreibung; Dieses Feld enthält die Paketbeschreibung. Dabei ist die erste Zeile ein kurzer, einzeiliger Text und die darauf folgenden, eingerückten Zeilen beinhalten eine lange und ggf. über mehrere Absätze gehende, ausführlichere Beschreibung. Zwischen der Kurz- und Langbeschreibung kann auch ein Punkt (.) stehen.
Built-Using
zu dt.: gebaut mit; Dieses Feld muss gemäß Debian Policy Manual §7.8 [Debian-Policy-Manual] vorhanden sein, sofern der Inhalt des Binärpakets nicht nur aus Quellcode aus dessen Quellpaket besteht und die Lizenz dieses Quellpakets vorschreibt, dass auch sämtlicher mit einkompilierter Quellcode frei verfügbar sein muss. Dies ist z.B. der Fall, wenn eine unter GNU GPL stehende Software statisch kompiliert wird oder Quellcode unter GNU GPL aus einem anderen Paket in das Binärpaket hineinkopiert wird (bspw. bei Stylesheets oder Hintergrundbildern für generierte Dokumentationen im HTML-Format).

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

 Package: poppler-utils
 Source: poppler
 Version: 0.18.4-6
 Architecture: amd64
 Maintainer: Loic Minier <lool@dooz.org>
 Installed-Size: 445
 Depends: libc6 (>= 2.4), libcairo2 (>= 1.10.0), libfreetype6 (>= 2.2.1), liblcms1 (>= 1.15-1), libpoppler19 (>= 0.18.4), libstdc++6 (>= 4.1.1)
 Recommends: ghostscript
 Conflicts: pdftohtml
 Breaks: xpdf-utils (<< 3.02-2~)
 Replaces: pdftohtml, xpdf-reader, xpdf-utils (<< 3.02-2~)
 Provides: pdftohtml, xpdf-utils
 Section: utils
 Priority: optional
 Multi-Arch: foreign
 Homepage: http://poppler.freedesktop.org/
 Description: PDF utilities (based on Poppler)
  Poppler is a PDF rendering library based on Xpdf PDF viewer.
  .
  This package contains command line utilities (based on Poppler) for getting
  information of PDF documents, convert them to other formats, or manipulate
  them:
   * pdffonts -- font analyzer
   * pdfimages -- image extractor
   * pdfinfo -- document information
   * pdfseparate -- page extraction tool
   * pdftocairo -- PDF to PNG/JPEG/PDF/PS/EPS/SVG converter using Cairo
   * pdftohtml -- PDF to HTML converter
   * pdftoppm -- PDF to PPM/PNG/JPEG image converter
   * pdftops -- PDF to PostScript (PS) converter
   * pdftotext -- text extraction
   * pdfunite -- document merging tool

4.1.2. Sourcepakete

In Sourcepaketen (siehe Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“) sind neben den weiter oben genannten Schlüsselworten auch die folgenden Einträge zulässig:

Source
zu dt.: Quelle; Name des Quellpakets.
Binary
zu dt.: Binärdatei; Liste aller Binärpakete, die aus diesem Quellpaket gebaut werden.
Package-List
zu dt. Paketliste; Auflistung aller Binärpakete, die aus diesem Quellpaket gebaut werden. Zusätzlich werden das Paketformat (deb oder udeb), die Paketkategorie („Sektion“), die Priorität und die Architektur benannt.
Format
zu dt.: Format; verwendetes Format des Quellpakets, z.B. 1.0, 3.0 (quilt) oder 3.0 (native) (siehe Aufbau und Format in Abschnitt 4.2, „Aufbau und Format“).
Architecture
zu dt. Architektur oder Plattform; Im Gegensatz zu den Binärpaketen sind hier mehr als nur eine einzige Architektur zulässig. Es beinhaltet alle Architekturen, auf denen das Paket gebaut werden kann. Der Wert any bedeutet, dass das Paket auf jeder Architektur gebaut werden kann und soll (siehe Abschnitt 1.2, „Debian-Architekturen“).
Uploaders
zu dt.: Hochlader; bezeichnet die Liste der Co-Maintainer und Beitragenden des Pakets.
Standards-Version
zu dt.: Version der Standardisierung; Angabe, welcher Version des Debian Policy Manuals [Debian-Policy-Manual] dieses Paket entspricht.
Vcs-Git, Vcs-Svn, Vcs-Hg, Vcs-Cvs, Vcs-Mtn
zu dt.: Versionskontrollsystem; Angabe, von wo Sie eine aktuelle Entwicklungskopie des Quellpakets aus einem Versionskontrollsystems auschecken können.
Vcs-Browser
zu dt.: Versionskontrollsystem und Webbrowser; URL einer Webansicht des unter Vcs-Git u.a. genannten Repositories des Versionskontrollsystems.
Build-Depends
zu dt.: Abhängigkeiten beim Bauen von Paketen; Pakete, die notwendig sind, um alle architektur-abhängigen Binärpakete aus diesem Quellpaket zu bauen, sowie um das Build-Verzeichnis zu säubern („clean“-Ziel). Pakete, die als „essential“ (unbedingt notwendig) oder „build-essential“ (für den Bau von Paketen unbedingt notwendig) markiert sind, müssen nicht aufgelistet werden (Kommt fast immer vor.)
Build-Depends-Indep
zu dt.: Abhängigkeiten beim Bauen von Paketen (architekturunabhängig); Pakete, die zusätzlich zu den unter Build-Depends aufgelisteten Paketen notwendig sind, um auch die architektur-unabhängigen Pakete aus diesem Quellpaket zu bauen. Hier sind meist die Pakete aufgelistet, die notwendig sind, um die Dokumentation oder Übersetzungsdateien zu bauen. (Kommt meist nur bei komplexeren Quellpaketen vor.)
Build-Conflicts
zu dt. Bau-Konflikte; Pakete, die nicht installiert sein dürfen, wenn die architektur-abhängigen Binärpakete aus diesem Quellpaket gebaut werden sollen. Dies sind meistens Pakete, die das configure-Skript beim Testen der notwendigen Bibliotheken stören oder aber Pakete, die zusätzliche, unerwünschte Abhängigkeiten in den gebauten Binärpaketen verursachen würden. (Kommt selten vor.)
Build-Conflicts-Indep
zu dt. Bau-Konflikte (architekturunabhängig); Pakete, die nicht installiert sein dürfen, wenn die architektur-unabhängigen Binärpakete aus diesem Quellpaket gebaut werden sollen. (Kommt sehr selten vor.)
Files, Checksums-Sha1, Checksums-Sha256
MD5-, SHA1- und SHA256-Checksummen sowie Dateinamen und -größen der enthaltenen Quellcode-Archive.
Testsuite
Optionales Feld, das angibt, mit welchem Programm das installierte Paket auf Funktionalität getestet werden kann. Derzeit ist der einzige mögliche Wert autopkgtest (siehe Debian Enhancement Proposal DEP 8 [DEP-8] und das gleichnamige Debianpaket dazu [Debian-Paket-autopkgtest].

4.1.3. Weitere Metadaten

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 Kapitel 13, 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 Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“ und Bezogenes Paket verifizieren in Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“).

Das Paket poppler-utils umfasst beispielsweise die folgenden Metadaten:

Description-md5: cd43e3ed14322253876488d6f9911888
Tag: implemented-in::c++, interface::commandline, role::program,
 scope::utility, use::converting, use::filtering,
 works-with-format::pdf, works-with-format::xml, works-with::text
Filename: pool/main/p/poppler/poppler-utils_0.18.4-6_amd64.deb
Size: 162034
MD5sum: 0f0254920f85b6190ba7b03f4d2a7d73
SHA1: 77fb9d39145c60421462a8fe8315d0adaa49a38c
SHA256: 38f2d13ccddac9e3d05abff7c5fab353d3fea550c8f39293850651e03c3f8be4

4.2. Aufbau und Format

4.2.1. Generell: 2 Ebenen

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 Abschnitt 4.1, „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 Abbildung 4.1, „Auszug aus dem postinst-Skript zum Paket dpkg-www sehen Sie einen Ausschnitt aus dem postinst-Skript zu besagtem Paket.

Abbildung 4.1. Auszug aus dem postinst-Skript zum Paket dpkg-www

werkzeuge/debian-paketformat-im-detail/postinst.png

4.2.2. Source-Pakete

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:

.dsc
Meta-Datei, die alle anderen Dateien mitsamt deren Hashsummen auflistet und ggf. signiert. Über die Hashsummen sind gleichzeitig alle anderen Dateien ebenfalls abgesichert.
Debian-spezifische Daten
  • Bei Source-Format 1.0 ist es ein komprimierter Patch — erkennbar an der Erweiterung diff.gz. Dieser kann nur Textdateien enthalten.
  • Bei Source-Format 3.0 ist es ein komprimiertes tar-Archiv — heutzutage meist mit debian.tar.xz benannt. Zulässig sind die Komprimierungsverfahren gzip, bzip2, lzma und xz. lzma wurde von Debian GNU/Linux allerdings nie unterstützt, wohl aber von anderen deb-basierten Distributionen (Abschnitt 1.5, „Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement“).
  • Software, die nur im Debian-Paketformat vertrieben wird, verfügt weder über den komprimierten Patch noch das o.g. Archiv. In diesem Fall wird von sogenannten nativen Paketen gesprochen.
Upstream-Quellcode
Der Originalquellcode der paketierten Software. Es wird versucht, diesen soweit wie möglich unverändert zu lassen. Es muss sich jedoch dabei um ein tar-Archiv handeln. Andere Container-Formate wie z.B. zip werden nicht unterstützt. Offerieren die Entwickler der Software den Quellcode z.B. nur als zip- oder rar-Archiv, so muss der Quellcode zunächst in ein tar-Archiv umgepackt werden. Der Dateiname des tar-Archivs endet dabei in orig.tar.endung, wobei das Suffix endung vom Komprimierungsformat abhängt. Erlaubt sind ebenfalls wieder gzip, bzip2, lzma und xz. lzma wird vom Debian-Archiv nicht unterstützt, aber von anderen deb-basierten Distributionen (Abschnitt 1.5, „Welche UNIX-artigen Betriebssysteme verwenden das Paketformat und das APT-Paketmanagement“). Ab dem Source-Format 3.0 kann ein Quellpaket (Abschnitt 2.7.4, „Source-Pakete (dsc und weitere Dateien)“) mehr als ein tar-Archiv mit Upstream-Quellcode beinhalten. Diese haben dann die Endung orig-komponente.tar.endung, wobei komponente nur alphanumerische Zeichen und Bindestriche beinhalten darf.

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.

4.2.3. Binärpakete

Komponenten

Ein Debian-Binärpaket ist ein BSD-ar-Archiv, welches weitere, komprimierte tar-Archive beinhaltet. Nachfolgendes Beispiel zeigt das für das Paket autotools-dev.

Auspacken von Paketen mit ar

$ ar t autotools-dev_20100122.1_all.deb
debian-binary
control.tar.gz
data.tar.gz
$

Dabei stehen die einzelnen Komponenten eines Pakets für:

debian-binary
Kennzeichnung für ein Debian-Paket. debian-binary ist eine Textdatei, welche lediglich die Versionsnummer des verwendeten Binär-Paketformats enthält. Nachfolgender Auszug zeigt die Versionsnummer für das Paket mplayer:
$ ar t mplayer_2%3a1.0~rc4.dfsg1+svn34540-1+b2_i386.deb
debian-binary
control.tar.gz
data.tar.gz
$ ar x mplayer_2%3a1.0~rc4.dfsg1+svn34540-1+b2_i386.deb debian-binary
$ cat debian-binary
2.0
$
control.tar.gz
mit gzip komprimiertes tar-Archiv; dieses enthält die Kontrollinformationen für die Paketverwaltung
data.tar.gz, data.tar.xz, data.tar.bz2
eigentliche Dateien des Pakets plus Speicherort, jeweils mit gzip, xz oder bzip2 komprimiert

Benennung

Ein Debian-Binärpaket ist eine Datei mit der Erweiterung deb oder udeb im Dateinamen. Ersteres beinhaltet ausführbare Dateien, Daten, Dokumentation, Konfigurationsdateien und Copyright-Informationen [Krafft-Debian-System]. Bei udeb-Dateien handelt es sich hingegen um einen Sonderfall. Es ist ein Paket mit reduziertem Paketinhalt, welches speziell für den Debian-Installer gedacht ist (siehe [Debian-udeb]).

Steuerdateien und Skripte

Wie bereits oben angesprochen, beinhaltet jedes Debianpaket auch sogenannte Control-Files (nach [Krafft-Debian-System144]). Diese Steuerdateien werden in der Komponente control.tar.gz aufbewahrt und bestehen aus diesen Dateien:

control
Das ist eine Steuerdatei und diese muss immer vorhanden sein. Sie beinhaltet die Metainformationen für die Paketverwaltung, bspw. zur Prüfung der Paketabhängigkeiten vor der Installation. Diese Steuerdatei kann beim Bauen des Pakets generiert worden sein, z.B. aus der Datei control.in mit Hilfe des Pakets autotools.
conffiles
Das ist eine Liste mit Konfigurationsdateien zum Paket. Erfolgt eine Paketaktualisierung, werden die Dateien, die in dieser Liste aufgeführt sind, auf dem System beibehalten und nicht durch die Daten aus dem neuen Paket überschrieben. Damit bleiben bereits bestehende lokale Änderungen erhalten, bspw. von spezifisch angepassten Konfigurationsdateien. Diese Liste wird meist automatisiert generiert.
preinst
Skriptdatei mit paketspezifischen Anweisungen. Diese Anweisungen werden vor der Installation oder Aktualisierung des Pakets (Upgrade) mit bestimmten Parametern aufgerufen.
postinst
Skriptdatei mit paketspezifischen Anweisungen. Diese Anweisungen werden nach der Installation oder Aktualisierung (Upgrade) sowie zur Konfiguration des Pakets mit bestimmten Parametern aufgerufen.
prerm
Skriptdatei mit paketspezifischen Anweisungen. Diese Anweisungen werden mit bestimmten Parametern aufgerufen, bevor das Paket entfernt wird.
postrm
Skriptdatei mit paketspezifischen Anweisungen. Diese Anweisungen werden mit bestimmten Parametern aufgerufen, nachdem das Paket entfernt wurde.
md5sums
MD5-Summen der Dateien, welche im Paket enthalten sind. Damit wird sichergestellt, dass beispielsweise keine Übertragungsfehler (Bitfehler) oder Änderungen zwischen dem Paketmirror und ihrem lokalen System erfolgt sind (siehe auch „Bezogenes Paket verifizieren“ in Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“).
shlibs
Diese Datei listet Bibliotheken und Shared Object Name (kurz SONAME) auf, welches das Paket gemeinsam mit dem Paketnamen zur Verfügung stellt.
config
Skriptdatei. Diese erfragt vom Benutzer Konfigurationsparameter, welche für das Paket zur Einrichtung benötigt werden. Die Anworten werden direkt in der debconf-Datenbank abgelegt und bspw. im postinst-Skript verarbeitet.
templates
Diese Datei enthält Texte zu den Fragen und Hinweisen, die debconf während der Paketkonfiguration anzeigt (siehe dazu auch „Pakete konfigurieren“ in Abschnitt 8.38, „Pakete konfigurieren“).

Daten im Paket

Die eigentlichen Dateien zu einem Paket liegen in der Datenkomponente. Damit dpkg die zu installierenden Programme und Daten aus dem Binärpaket auch an die richtige Position in der Dateisystemhierarchie ihres Systems kopieren kann, spiegelt der Inhalt dieser Komponente die entsprechende Verzeichnisstruktur auf dem Zielsystem vollständig wieder.

Diese Struktur, die zu installierenden Dateien sowie deren Typ und Größe zeigen Sie mit dem Kommando dpkg-deb -c Paketdatei an. Das nachfolgende Beispiel anhand des Pakets vnstat zeigt, dass darin sowohl Programme (ausführbare Dateien in /usr/bin und /usr/sbin) als auch Dokumentation (in /usr/share/doc und /usr/share/man), Konfigurationsdateien (in /etc) und ein Verzeichnis für variable Daten (unterhalb von /var/lib) enthalten sind:

Inhalt des Pakets vnstat mit dpkg-deb anzeigen. 

$ dpkg-deb -c vnstat_1.10-1_i386.deb
drwxr-xr-x root/root         0 2010-04-20 20:38 ./
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/bin/
-rwxr-xr-x root/root    106424 2010-04-20 20:38 ./usr/bin/vnstat
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/sbin/
-rwxr-xr-x root/root     56184 2010-04-20 20:38 ./usr/sbin/vnstatd
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/doc/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/doc/vnstat/
-rw-r--r-- root/root      1604 2010-04-20 18:38 ./usr/share/doc/vnstat/changelog.Debian.gz
-rw-r--r-- root/root      2101 2010-01-02 01:32 ./usr/share/doc/vnstat/README
-rw-r--r-- root/root      3050 2010-01-02 02:36 ./usr/share/doc/vnstat/changelog.gz
-rw-r--r-- root/root      1501 2010-04-20 18:18 ./usr/share/doc/vnstat/copyright
-rw-r--r-- root/root      2077 2010-01-02 01:33 ./usr/share/doc/vnstat/FAQ.gz
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/man/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/man/man1/
-rw-r--r-- root/root      2558 2010-04-20 20:38 ./usr/share/man/man1/vnstatd.1.gz
-rw-r--r-- root/root      4085 2010-04-20 20:38 ./usr/share/man/man1/vnstat.1.gz
drwxr-xr-x root/root         0 2010-04-20 20:38 ./usr/share/man/man5/
-rw-r--r-- root/root      2488 2010-04-20 20:38 ./usr/share/man/man5/vnstat.conf.5.gz
drwxr-xr-x root/root         0 2010-04-20 20:38 ./etc/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./etc/init.d/
-rwxr-xr-x root/root      1466 2010-04-20 17:52 ./etc/init.d/vnstat
-rw-r--r-- root/root      2889 2010-04-20 20:38 ./etc/vnstat.conf
drwxr-xr-x root/root         0 2010-04-20 20:38 ./var/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./var/lib/
drwxr-xr-x root/root         0 2010-04-20 20:38 ./var/lib/vnstat/
$

Wünschen Sie stattdessen eine graphische oder webbasierte Darstellung des Paketinhalts, stehen Ihnen als Alternativen die Werkzeuge deb-gview, Synaptic, dpkg-www und apt-browse zur Verfügung. Im Detail agiert hier jedes der genannten Programme anders.

deb-gview und Synaptic erlauben Ihnen nur den Zugriff auf ihr lokales System. Während deb-gview dabei den Inhalt von deb-Dateien ausliest, beschränkt sich Synaptic auf bereits installierte Debianpakete. dpkg-www hingegen inspiziert bereits installierte Debianpakete sowohl auf ihrem lokalen System, als auch auf einem anderen Rechner. apt-browse greift stattdessen ausschließlich auf seinen eigenen Datenbestand auf dem Webserver zurück und wertet die Informationen aus den Paketen aus.

deb-gview finden Sie im gleichnamigen Paket [Debian-Paket-deb-gview]. Abbildung 4.2, „Detailinformationen zum Paket debsums (deb-gview)“ zeigt die Bedienoberfläche beispielhaft anhand des Pakets debsums [Debian-Paket-debsums]. Die dreispaltige Aufteilung beinhaltet die Daten- und Steuerdateien, die darin enthaltenen Programmdateien und Metadaten zum Paket.

Abbildung 4.2. Detailinformationen zum Paket debsums (deb-gview)

werkzeuge/debian-paketformat-im-detail/deb-gview.png

Abbildung 4.3, „Detailinformationen zum Paket debsums (Synaptic)“ zeigt die Programmdateien zum gleichen Paket, wie es Synaptic darstellt. Sie erreichen dieses Dialogfenster über PaketEigenschaften und danach im Reiter „Installierte Dateien“. Ausführlicher besprechen wir Synaptic in Abschnitt 6.4.1, „Synaptic“.

Abbildung 4.3. Detailinformationen zum Paket debsums (Synaptic)

werkzeuge/debian-paketformat-im-detail/synaptic-paketinhalt.png

Die spezialisierten Suchmaschinen für Pakete namens dpkg-www und apt-browse listen die Paketdetails ebenfalls auf (siehe Abbildung 4.4, „Detailinformationen zum Paket debsums in apt-browse.org (Ausschnitt)“). Genauer besprechen wir diese unter „In Paketen blättern mittels dpkg-www“ in „In Paketen blättern mittels dpkg-www sowie „Suche über apt-browse.org“ in „Suche über apt-browse.org“.

Abbildung 4.4. Detailinformationen zum Paket debsums in apt-browse.org (Ausschnitt)

werkzeuge/debian-paketformat-im-detail/apt-browse-paketinhalt.png

4.2.4. Übergangs- und Metapakete

Wie bereits in „Übergangs- und Metapakete“ (siehe Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“) 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:

Symbolischer Verweis auf eine andere Komponente am Beispiel der ash

$ ls -la /bin/ash
lrwxrwxrwx 1 root root 4 Mär  1  2012 /bin/ash -> dash
$



[16] früher teilweise im Encoding ISO 8859-1, heute nur noch in UTF-8

Kapitel 5. APT und Bibliotheken

Wie bereits in der Übersicht in „Softwarestapel und Ebenen“ (siehe Abschnitt 2.3, „Softwarestapel und Ebenen“) deutlich wurde, ist die Paketverwaltung von Debian GNU/Linux mehrstufig und modular aufgebaut. Hinter den Bedienoberflächen dpkg, APT und aptitude (siehe „Werkzeuge zur Paketverwaltung“ in Kapitel 6, Werkzeuge zur Paketverwaltung (Überblick)) stecken mächtige Bibliotheken, die den Zugriff auf die einzelnen Softwarepakete und die Paketdatenbank kapseln. Mit Hilfe der nachfolgend vorgestellten Bibliotheken und den Funktionen daraus können Sie eigene Anwendungen zur Paketverwaltung entwickeln.

5.1. Bibliothek libapt-pkg

Diese Bibliothek aus dem Paket libapt-pkg4.12 [Debian-Paket-libapt-pkg4.12] enthält die Basiskomponenten zum Zugriff auf die einzelnen Softwarepakete. Das umfasst Funktionen zur Suche nach Paketen, deren Verwaltung sowie die Ausgabe der Paketinformationen. Dazu gehören:

  • der Abruf von Informationen zu einem Paket aus den verschiedenen Paketquellen
  • der Abruf eines Pakets und der vollständigen Auflösung der Paketabhängigkeiten dieses Pakets
  • die Authentifizierung der Paketquellen und Überprüfung der abgerufenen Daten (Validierung)
  • die Installation und Entfernung von Paketen aus ihrem Linux-System
  • der Zugriff auf den Paketcache (siehe Kapitel 7, Paketcache)
  • die Bereitstellung von Schnittstellen zu Netzwerkprotokollen, um Daten und Pakete über diese beziehen zu können. Dazu gehören bspw. CD-ROM, FTP, HTTP/S, rsh und DebTorrent (APT über BitTorent) ([Debian-Paket-apt-transport-debtorrent] und [Debian-Wiki-DebTorrent]).

5.2. Bibliothek libapt-pkg-perl

Diese Bibliothek aus dem Paket libapt-pkg-perl [Debian-Paket-libapt-pkg-perl] beinhaltet die Perl-Schnittstelle zum Zugriff auf die einzelnen Softwarepakete. Es hat die gleiche Funktionalität wie das weiter oben beschriebene Paket libapt-pkg.

5.3. Bibliothek python-apt

Diese Bibliothek aus dem Paket python-apt [Debian-Paket-python-apt] beinhaltet die Python-Schnittstelle zum Zugriff auf die einzelnen Softwarepakete. Es hat die gleiche Funktionalität wie die weiter oben beschriebenen Pakete libapt-pkg und libapt-pkg-perl.

5.4. Bibliothek libapt-pkg-doc

Dieses Paket [Debian-Paket-libapt-pkg-doc] stellt die Dokumentation zur Verfügung, auf deren Grundlage Sie eigene Entwicklungen in APT anstoßen können. Die Dokumentation steht als Plaintext und als HTML-Dokument bereit.

5.5. Bibliothek libapt-inst

Um Informationen aus deb-Paketen zur erhalten, nutzen Sie diese Bibliothek aus dem Paket libapt-inst [Debian-Paket-libapt-inst]. Darüber steht eine Schnittstelle zur Abfrage der Paketinterna bereit, die sowohl den Paketinhalt, als auch die Steuerdaten der Komponente control.tar.gz umfassen (siehe „Debian-Paketformat im Detail“ in Abschnitt 4.2, „Aufbau und Format“).

Kapitel 6. Werkzeuge zur Paketverwaltung (Überblick)

6.1. Frontends für das Paketmanagement

Unter einem Frontend verstehen wir ein Programm oder ein Werkzeug mit einer Bedienoberfläche, welches im Alltag von Ihnen für die Verwaltung der Softwarepakete verwendet wird. Es deckt alle dafür notwendigen Aktionen auf ihrem System ab und umfasst die grundsätzliche Pflege des Paketbestands. Dazu zählen bspw. die Installation, die Aktualisierung und die restlose Entfernung von Softwarepaketen, wobei das Gesamtsystem stets in einem konsistenten, benutzbaren Zustand verbleibt.

Frontends existieren in recht unterschiedlichen Varianten und folgen divergierenden Bedienkonzepten. Die nachfolgende Übersicht orientiert sich daher an der Benutzerschnittstelle und dem Paketformat, für das Sie das jeweilige Programm benutzen können. Einige Programme sind Zwitter und stellen mehrere Bedienmodi zur Verfügung, so bspw. SmartPM (Abschnitt 6.4.3, „Smart Package Management (SmartPM)“), welches Sie sowohl über die Kommandozeile, als auch über eine graphische Oberfläche (GUI) bedienen können. aptitude (Abschnitt 6.3.2, „aptitude), aptsh (Abschnitt 6.2.3, „Die aptsh), cupt (Abschnitt 6.2.5, „Cupt“) und wajig (Abschnitt 8.42.7, „wajig) stellen über die Kommandozeile hinaus auch ein eigenes Text User Interface (TUI) bereit. Die nachfolgende Zusammenstellung in Tabelle 6.1, „Frontends zur Paketverwaltung“ ist daher nicht ganz diskussionsfrei und erhebt zudem keinen Anspruch auf Vollständigkeit.

Tabelle 6.1. Frontends zur Paketverwaltung

Kategorie deb-basierte Systeme rpm-basierte Systeme andere Paketformate

Kommandozeile

dpkg, dpkg-www, APT, aptitude, aptsh, cupt, SmartPM, gdebi (gdebi-core), wajig

rpm, yum, urpmi, zypper, SmartPM

emerge, pacman

Text User Interface (TUI)

tasksel, aptitude, Debian Installer, Univention Installer für Univention Corporate Server (UCS)

Yet another Setup Tool (YaST), DrakConf oder Mandriva Linux Control Center (MCC) [Mandriva-Wiki] bzw. Mageia Control Center (MCC) (Textkonsole)

pcurses

Graphical User Interface (GUI)

Synaptic, SmartPM, Ubuntu Software Center, Muon, PackageKit, Apper (früher KPackageKit), gdebi

Yet another Setup Tool 2 (YaST2), DrakConf oder Mandriva Linux Control Center (MCC) [Mandriva-Wiki] bzw. Mageia Control Center (MCC)

PacmanXG4, PacmanExpress, tkPacman, GNOME PackageKit, Zenity Pacman GUI, Octopi

webbasierte Verwaltung (WUI)

IP Brick [ipbrick], Univention Management Console für Univention Corporate Server (UCS), Ubuntu Landscape , Appnr, Communtu, Debian Pure Blends


6.1.1. Aufgaben, Sinn und Zweck des Frontends

Basierend auf der Einordnung in die unterschiedlichen Softwarestapel und Ebenen (siehe Abschnitt 2.3, „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 Abschnitt 8.36, „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 Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“) 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 aptsh, 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.

6.1.2. Anmerkungen zur Programmauswahl

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 Abschnitt 44.1, „Empfehlungen für 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 Abschnitt 2.11, „Benennung einer Paketdatei“) 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 Abschnitt 6.5.2, „Appnr“) im Alltag zu rechnen.

6.2. Für die Kommandozeile

6.2.1. dpkg

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 Kapitel 46, 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[17]:

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 (Abschnitt 6.2.2, „APT“), apt-cache, aptitude (Abschnitt 6.3.2, „aptitude) und apt-file oder die Benutzeroberflächen via Ncurses oder GTK besser geeignet (siehe Abschnitt 6.3, „ncurses-basierte Programme“ und Abschnitt 6.4, „GUI zur Paketverwaltung“). Diese fassen viele Einzelschritte von dpkg zusammen und vereinfachen Ihnen die Wartung ihres Systems erheblich.

6.2.2. APT

Überblick

APT ist das Debian-Programm für etwas komplexere Paketoperationen und steht als Abkürzung für Advanced Packaging Tool. Sie finden es im Paket apt [Debian-Paket-apt], welches zur Standardinstallation Ihres Debian-Systems gehört.

APT ist für den Alltagseinsatz konzipiert. Es eignet sich sowohl für Recherchezwecke (Abfrage von Status- und Zustandsinformationen), als auch für die Installation und Aktualisierung einzelner Pakete sowie gesamter Paketstrukturen (Veröffentlichungen).

Im Gegensatz zu aptitude (siehe Abschnitt 6.3.2, „aptitude) ist es deutlich weniger anspruchsvoll. Das betrifft die Anforderungen an die Hardware und insbesondere den benötigten Speicher für die Ausführung. APT hat zudem eine deutlich höhere Ausführungsgeschwindigkeit als aptitude.

APT ist sehr mächtig und kann mit Paketen umgehen, die sich entweder bereits lokal auf Ihrem System befinden, oder noch auf einem Paketmirror vorliegen. Es kombiniert i.d.R. mehrere Einzelaktionen von dpkg. Es greift dabei aber nicht direkt auf dpkg zurück, sondern kapselt dafür die Aufrufe mit Hilfe der Bibliothek libapt-pkg (siehe dazu „APT und Bibliotheken“ unter Kapitel 5, APT und Bibliotheken).

Komponenten und Funktionen

APT umfasst ausschließlich Programme für die Kommandozeile. Dazu zählen apt-cache, apt-cdrom (siehe Abschnitt 3.8, „Physische Installationsmedien mit apt-cdrom einbinden“), apt-config zur Konfiguration von APT (siehe Kapitel 10, APT und aptitude auf die eigenen Bedürfnisse anpassen), apt-get, apt-key (siehe Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“) und apt-mark (siehe Abschnitt 8.4.6, „Anfragen mit apt-mark). Jedes der genannten Programme verfügt über umfangreiche Unterkommandos, die Sie wiederum mit diversen Optionen und Schaltern kombinieren können. Die gebräuchlichsten Aktionen für den Alltag sind:

Nachfolgend geben wir Ihnen eine Übersicht zu allen Unterkommandos, die die einzelnen APT-Werkzeuge bereithalten. Neben dem jeweiligen Unterkommando finden Sie den Verweis auf den entsprechenden Abschnitt im Buch, in dem wir auf dieses genauer eingehen.

apt-cache

apt-cache bietet die folgenden Unterkommandos:

depends
Paketabhängigkeiten anzeigen (siehe Abschnitt 8.17, „Paketabhängigkeiten anzeigen“)
dotty
einen Abhängigkeitsgraphen im dot-Format für die benannten Pakete erzeugen (siehe das Beispiel in Abschnitt 2.5, „Zusammenspiel von dpkg und APT“)
dump
eine kurze Programminformation von jedem Paket im Paketcache anzeigen
dumpavail
die Liste der verfügbaren Pakete anzeigen
gencaches
den Paketzwischenspeicher von APT erzeugen
madison
verfügbare Versionen eines Pakets anzeigen (siehe Abschnitt 8.18, „Aus welchem Repo kommen die Pakete“ und Abschnitt 8.18.2, „Verfügbare Paketversionen mit apt-cache madison ermitteln“)
pkgnames
die Namen aller Pakete auflisten, die APT kennt (siehe Abschnitt 8.3, „Bekannte Paketnamen auflisten“)
policy
die Quellen und deren Prioritäten auflisten (siehe Abschnitt 8.18, „Aus welchem Repo kommen die Pakete“)
rdepends
umgekehrte Paketabhängigkeiten anzeigen (siehe Abschnitt 8.17, „Paketabhängigkeiten anzeigen“)
search
Paket über den Namen finden (siehe Abschnitt 8.19, „Pakete über den Namen finden“)
show
Paketinformationen ausgeben und Paketstatus erfragen (siehe Abschnitt 8.4, „Paketstatus erfragen“)
showsrc
Informationen zum Sourcepaket anzeigen (siehe Abschnitt 8.34, „Sourcepakete anzeigen“)
showpkg
Informationen über das Paket anzeigen (siehe Abschnitt 8.4, „Paketstatus erfragen“)
stats
Statistik zum Paketcache ausgeben (siehe Abschnitt 7.2, „Paketcache-Status“)
unmet
eine Zusammenfassung aller unerfüllten Abhängigkeiten im Paketcache ausgeben (siehe „Paketstatus erfragen“ in Abschnitt 8.4, „Paketstatus erfragen“)
xvcg
einen Abhängigkeitsgraphen für xvcg für die benannten Pakete erzeugen

apt-get

apt-get gehört mit Sicherheit zur Menge der gebräuchlichsten Kommandos der APT-Familie und verfügt über die folgenden Unterkommandos:

autoclean
Paketcache aufräumen (siehe Abschnitt 7.3, „Paketcache aufräumen“)
autoremove
Paketwaisen löschen (siehe Abschnitt 8.42, „Umgang mit Waisen“)
build-dep
Abhängigkeiten eines Sourcepakets erfüllen (findet Verwendung beim Erstellen von Paketen)
check
Paketcache auf beschädigte Paketabhängigkeiten prüfen (siehe Abschnitt 8.17, „Paketabhängigkeiten anzeigen“)
clean
Paketcache aufräumen (siehe Abschnitt 7.3, „Paketcache aufräumen“)
dist-upgrade
Distribution aktualisieren (siehe Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“)
download
Paketdatei nur herunterladen (siehe Abschnitt 8.31, „Paketdatei nur herunterladen“)
dselect-upgrade
Aktualisierung der Pakete über dselect
install
Paket installieren (siehe Abschnitt 8.36, „Pakete installieren“)
purge
Paket inklusive Konfigurationsdateien des Pakets entfernen (siehe Abschnitt 8.41, „Pakete deinstallieren“)
remove
Paket deinstallieren (siehe Abschnitt 8.41, „Pakete deinstallieren“)
source
Beziehen der Sourcepakete (siehe Abschnitt 8.33, „Sourcepakete beziehen“)
update
Paketliste aktualisieren (siehe Abschnitt 3.13, „Liste der verfügbaren Pakete aktualisieren“)
upgrade
Pakete auf eine neue Version aktualisieren (siehe Abschnitt 8.39, „Pakete aktualisieren“)

apt-key und apt-mark

Für apt-key sind die Unterkommandos add, adv, del, export, exportall, finger, list, net-update und update zulässig. Diese besprechen wir ausführlich unter „Paketquelle auf Echtheit überprüfen“ in Abschnitt 3.12, „Paketquelle auf Echtheit überprüfen“.

Die Unterkommandos von apt-mark lauten auto, manual, showauto und showmanual. Dazu gehen wir unter „Paketstatus erfragen“ in Abschnitt 8.4, „Paketstatus erfragen“ detailliert ein.

Weiterentwicklung von APT

Dieser Prozess geht stetig voran. Seit mehreren Jahren gibt es Bestrebungen, APT grundlegend zu erneuern bzw. dessen verteilte Funktionalität unter einer einzigen Benutzeroberfläche zusammenzufassen. Unter dem Namen APT2 [apt2] existiert zwar ein Prototyp mit neuer API, jedoch gab es dort nach unserer Recherche seit 2011 keine weitere Entwicklung mehr.

Eine weniger tiefgreifende, aber dennoch erfrischende Modernisierung gibt es seit APT Version 1.0. Von da an enthält das Paket apt das zusätzliche, gleichnamige Kommandozeilenprogramm apt. Dieser Programmname wurde bis dato von einem Java-Programm zur Annotationsverarbeitung (Annotation Processing Tool) belegt [Java-Apt]. Es wird seit Java 7 als veraltet deklariert und ist seit Java 8 nicht mehr Bestandteil von Java.

Somit wurde der Weg für ein neues Programm frei, ohne große Verwirrung zu stiften. apt vereint die gängigsten Unterkommandos von apt-get und apt-cache in einem kürzeren Befehl und mit moderneren Standardeinstellungen wie z.B. einem Fortschrittsbalken und farbiger Ausgabe auf dem Terminal (siehe [Vogt-Apt-1.0]). Neben den bekannten Unterkommandos list, search, show, update, install und upgrade kennt es auch die neuen Aktionen full-upgrade als Ersatz für dist-upgrade und edit-sources zur direkten Veränderung der Datei /etc/apt/sources.list (siehe Abschnitt 8.39, „Pakete aktualisieren“ und Abschnitt 3.3, „/etc/apt/sources.list verstehen“). Darüber hinaus verfügt es ab APT Version 1.1 über die Fähigkeit, lokal vorliegende deb-Pakete zu installieren und dabei die dazugehörigen Paketabhängigkeiten mit zu berücksichtigen.[18]

In LinuxMint gibt es dagegen schon länger einen Befehl apt [LinuxMint-apt], welcher allerdings ein in Python geschriebener Wrapper um apt-get, apt-cache und neuerdings auch apt ist. Dieser befindet sich in /usr/local/bin/ und hat weitere LinuxMint-spezifische Features, wie z.B. das automatische Aufrufen der eigentlichen Befehle via sudo wo notwendig.

Ebenfalls in produktivem Zustand und teilweise intensiver Benutzung befinden sich die Werkzeuge cupt, aptitude und SmartPM. Während sich und cupt nur auf die Kommandozeile beschränken, bieten Ihnen aptitude zusätzlich eine textbasierte bzw. SmartPM eine graphische Benutzeroberfläche. Auf diese Werkzeuge gehen wir nachfolgend genauer ein (siehe, Abschnitt 6.2.5, „Cupt“, Abschnitt 6.3.2, „aptitude und Abschnitt 6.4.3, „Smart Package Management (SmartPM)“).

aptsh war ebenfalls lange Zeit produktiv nutzbar, ist aber mit neueren APT-Versionen (1.2 und höher) nicht mehr kompatibel und wir voraussichtlich in neueren Debian- und Ubuntu-Veröffentlichungen nicht enthalten sein, da es nicht mehr weiterentwickelt wird [aptsh-verwaist-Bug-Report-831493]. Bis Debian 8 Jessie ist aptsh aber durchaus noch benutzbar. Siehe auch Abschnitt 6.2.3, „Die aptsh.

6.2.3. Die aptsh

Bei der aptsh handelt es sich um eine Shell für die Paketverwaltung. Die Grundlage dafür bildet die Bibliothek libapt-pkg (siehe „apt und Bibliotheken“ in Kapitel 5, APT und Bibliotheken). Als Inspirationsquelle für die Shellkommandos dienen die Unterkommandos von APT und aptitude, die hiermit in einem Werkzeug zusammengefasst wurden, somit die Handhabung erleichtern und den Tippaufwand deutlich verringern.

Vom Umfang her kombiniert die aptsh eine Vielzahl der Unterkommandos von apt-get, apt-cache und aptitude. Einerseits agiert es als Shell, andererseits kann es die Aufrufe mit den Optionen über die Kommandozeile direkt verarbeiten. Zu den üblichen Kommandos zählen bspw. install, remove, purge, search, update und upgrade. Weiterhin sind auch zur Paketsuche ls und rls verfügbar, ebenso depends und rdepends für die Anzeige der Paketabhängigkeiten (siehe Abbildung 6.1, „aptsh mit der Ausgabe der umgekehrten Paketabhängigkeiten mit rdepends) sowie changelog, show, showpkg, showsrc und whatis für Informationen zu einem Paket.

Abbildung 6.1. aptsh mit der Ausgabe der umgekehrten Paketabhängigkeiten mit rdepends

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/fuer-die-kommandozeile/aptsh-rdepends.png

2012 probierten Thomas Winde und Frank Hofmann die aptsh aus und waren von dem Werkzeug in kürzester Zeit hellauf begeistert. Dazu entstand zunächst ein Beitrag im Magazin Linux User [Hofmann-Winde-Aptsh-LinuxUser], der die kleine Entdeckungsreise mit dem Programm beschreibt. Erst später erschienen andere Möglichkeiten wie wajig [Debian-Paket-wajig] und cupt [Debian-Paket-cupt] auf unserem Radar, welche wir dann für das vorliegende Buch genauer inspizierten (siehe nachfolgende Abschnitte).

Hintergrund für die Recherche nach Alternativen zur aptsh war der Fakt, dass das Projekt seit Debian 6 Squeeze leider verwaist ist [aptsh-verwaist-Bug-Report-831493]. Alle später veröffentlichten Pakete sind lediglich Non-Maintainer-Uploads (NMU) und damit ohne kontinuierliche Betreuung.

Zudem kommt hinzu, dass das Projekt seit dem Auf-und-Ab von berliOS [berliOS] unter wechselnden Adressen auffindbar war. Die Projektseite [aptsh-Projekt] finden Sie mittlerweile nur noch in der "Wayback-Machine" des Web-Archives. Da das Projekt BackupTheBerlios u.a. die aptsh-Subversion-Versionsgeschichte auf GitHub importiert hat [aptsh-BackupTheBerlios-Git-Repository], erleichert eine zukünftige Weiterentwicklung.

6.2.4. wajig

Das in der Programmiersprache Python geschriebene Programm wajig [Debian-Paket-wajig] ist vorrangig ein Wrapper um dpkg (Abschnitt 6.2.1, „dpkg) und APT (Abschnitt 6.2.2, „APT“). Es zählt zur gleichen Kategorie wie die aptsh (siehe Abschnitt 6.2.3, „Die aptsh), beinhaltet aber auch Elemente von cupt (Abschnitt 6.2.5, „Cupt“) und aptitude (Abschnitt 6.3.2, „aptitude) auf der Kommandozeile. Bis einschließlich Debian 6 Squeeze bestand zudem eine graphische Variante namens gjig, die mittlerweile obsolet 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 Kapitel 5, 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 (Abschnitt 3.8, „Physische Installationsmedien mit apt-cdrom einbinden“) oder alien (siehe Abschnitt 22.2, „Fremdformate mit alien hinzufügen“) 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 Abschnitt 8.42, „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.

Suche nach der Datei sources.list mit Hilfe von wajig

$ wajig find-file sources.list
apt: /usr/share/man/es/man5/sources.list.5.gz
apt: /usr/share/man/ja/man5/sources.list.5.gz
apt: /usr/share/man/pt/man5/sources.list.5.gz
debtags: /etc/debtags/sources.list
apt: /usr/share/man/fr/man5/sources.list.5.gz
apt: /usr/share/doc/apt/examples/sources.list
debtags: /etc/debtags/sources.list.d
apt: /usr/share/man/de/man5/sources.list.5.gz
debtags: /etc/debtags/sources.list.d/source-example
apt: /usr/share/man/pl/man5/sources.list.5.gz
apt: /etc/apt/sources.list.d
apt: /usr/share/man/man5/sources.list.5.gz
$

Abbildung 6.2. wajig mit der Ausgabe des Kommandos listfiles

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/fuer-die-kommandozeile/wajig-listfiles.png

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

6.2.5. Cupt

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 (Abschnitt 1.2.3, „Multiarch: Mehrere Architekturen gleichzeitig auf einem System“). 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.

6.3. ncurses-basierte Programme

6.3.1. tasksel

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 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 Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“). Das zeigt sich sehr deutlich in den Ausgaben im Terminal, auf die wir unten genauer eingehen.

Abbildung 6.3. Softwareauswahl in tasksel

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/ncurses-basiert/tasksel.png

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

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 Abschnitt 2.7, „Debian-Pakete (Varianten)“). Dazu zählen bspw. die Aufgaben Mailserver, Webserver, Desktopumgebung und Laptop (siehe Abbildung 6.3, „Softwareauswahl in tasksel).

tasksel und andere Programme

Wenn das Paket tasksel installiert ist, zeigen sowohl Aptitude wie auch Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) ebenfalls alle verfügbaren Aufgaben an. Aptitude verwendet dafür einen eigenen Ast als Sektion „Debian“ und Distributionsbereich „Tasks“, bei Synaptic hingegen heißt der Bereich (Sektion) „Tasks“.

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:

install Aufgabe
installiert alle Pakete, die für die Aufgabe notwendig sind
remove Aufgabe
entfernt alle Pakete, die zur angegebenen Aufgabe gehören
--list-tasks
listet alle Aufgaben auf, die tasksel kennt
--task-desc Aufgabe
zeigt eine Beschreibung der gewählten Aufgabe an
--task-packages Aufgabe
zeigt alle Pakete an, die zur gewählten Aufgabe gehören
-t (Langform --test)
Trockendurchlauf, Ausführung der gewünschten Aktion ohne echte Auswirkung

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

Ausgabe aller festgelegten Aufgaben von tasksel

$ tasksel --list-tasks
u desktop         Debian desktop environment
u web-server      Web server
u print-server    Printserver
u database-server SQL database
u dns-server      DNS Server
u file-server     File server
u mail-server     Mail server
u ssh-server      SSH server
u laptop          Laptop
$

Für jede Aufgabe ist eine Beschreibung der Aufgabe hinterlegt. Diese zeigen Sie mit dem Schalter --task-desc an[19]. Auf einem Ubuntu mit tasksel in der Version 2.88 sehen Sie diese Ausgabe:

Ausgabe der Aufgabenbeschreibung eines tasks (Ubuntu). 

$ tasksel --task-desc openssh-server
Selects packages needed for an Openssh server.
$

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:

Pakete, die zu einer Aufgabe gehören (Debian). 

$ tasksel --task-packages ssh-server
task-ssh-server
$

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

Pakete, die zu einer Aufgabe gehören (Ubuntu). 

$ tasksel --task-packages openssh-server
python-six
python-chardet
python2.7
tcpd
openssh-server
ncurses-term
ssh-import-id
...
$

6.3.2. aptitude

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

Dokumentation zu aptitude

Für den vollständigen Funktionsumfang und als Einstieg zum Programm ist das Lesen der Dokumentation zu aptitude [aptitude-dokumentation] empfehlenswert. Neben der Bedienung enthält es alle Unterkommandos, Optionen, Schalter und Möglichkeiten zur Konfiguration.

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 Abschnitt 6.2.2, „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 BearbeitenTastenkombinationenMenü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 (Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“), den Distributionsbereich (Abschnitt 2.9, „Distributionsbereiche“) und den Paketnamen mit Versionsnummer dar. Sichtbar wird dabei die Version des installierten Pakets sowie der möglichen Aktualisierung (Abschnitt 2.11.2, „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 Tabelle 6.2, „Farben und deren Bedeutung bei aptitude entnehmen. Das Farbschema können Sie auch nach Gutdünken anpassen, genauer gehen wir darauf in Abschnitt 10.8, „aptitude-Farbschema anpassen“ ein.

Tabelle 6.2. Farben und deren Bedeutung bei aptitude

Farbkombination Bedeutung

schwarzer Hintergrund mit weißer Schrift

das Paket wird nicht verändert

roter Hintergrund mit weißer Schrift

das Paket ist defekt oder kann nicht installiert werden

blauer Hintergrund mit weißer Schrift

das Paket wird aktualisiert

weißer Hintergrund mit schwarzer Schrift

die Paketversion bleibt erhalten, kann jedoch aktualisiert werden

grüner Hintergrund mit schwarzer Schrift

Paket wird installiert

lila Hintergrund mit schwarzer Schrift

Paket wird entfernt („deinstalliert“)


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 Tabelle 6.3, „Tasten bei aptitude.

Tabelle 6.3. Tasten bei aptitude

Aktion Tastenbelegung

Hilfe

?

aptitude beenden (Vormerkungen werden gespeichert)

Shift+ q

aptitude abbrechen (alle Vormerkungen gehen verloren)

Ctrl+kbd[C]

Info-Fenster ein- und ausblenden

Shift+ D

Zwischen den Info-Ansichten wechseln

i

Zwischen beiden Fenstern hin- und herwechseln

Tab

In das Menü von aptitude wechseln

Ctrl+ t oder F10

Paketlisten aktualisieren

u

Ausgewähltes Paket auswählen

+

Ausgewähltes Paket entfernen

-


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 Abbildung 6.4, „package dependency solver in aptitude). 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 Tabelle 6.4, „Tasten zur interaktiven Konfliktlösung bei aptitude) und wie Sie die gewünschte Variante letztendlich auswählen.

Abbildung 6.4. package dependency solver in aptitude

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/ncurses-basiert/aptitude-dependency-solver.png

Tabelle 6.4. Tasten zur interaktiven Konfliktlösung bei aptitude

Aktion Tastenbelegung

Vorschläge zur Konfliktlösung anzeigen

e

Nächsten Vorschlag anzeigen

.

Vorherigen Vorschlag anzeigen

,

Ersten Vorschlag anzeigen

<

Letzten Vorschlag anzeigen

>

Teilvorschlag akzeptieren

a

Teilvorschlag ablehnen („reject“)

r

Vorschlag anwenden

!


Darüber hinaus verfügt aptitude über eine Ansicht, in der Sie Pakete nach Debian-Tags (Debtags) (siehe dazu Kapitel 13, 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 Abbildung 13.5, „Auswahl des Debtags-Browsers in aptitude (noch) angezeigte Kategoriebrowser gilt als veraltet[20], 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 (Kapitel 12, 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 Kapitel 10, APT und aptitude auf die eigenen Bedürfnisse anpassen).

6.4. GUI zur Paketverwaltung

6.4.1. Synaptic

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. Inzwischen hat das mehr an Apples App-Store denn an Aptitude erinnernde Ubuntu Software Center (Abschnitt 6.4.4, „Ubuntu Software Center“) viele Fans abgeworben.

Abbildung 6.5. Softwareauswahl in synaptic

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/synaptic.png

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 EinstellungenEinstellungen und EinstellungenWerkzeugleiste. Abbildung 6.6, „Farbige Markierungen der Pakete gemäß ihrem Installationsstatus (Synaptic)“ zeigt als Beispiel das Dialogfenster, über welches Sie die Farben zum jeweiligen Installationsstatus eines Pakets festlegen.

Abbildung 6.6. Farbige Markierungen der Pakete gemäß ihrem Installationsstatus (Synaptic)

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/synaptic-setup-farben.png

Ü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. Abbildung 6.7, „Allgemeine Paketeigenschaften für das Paket ding (Synaptic)“ zeigt die Informationen zum Paket ding.

Abbildung 6.7. Allgemeine Paketeigenschaften für das Paket ding (Synaptic)

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/synaptic-paketinfo.png

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. Abbildung 6.5, „Softwareauswahl in synaptic zeigt Ihnen die Gesamtansicht anhand des Pakets a2ps.

Die linke Spalte zeigt zunächst die Architektur (Abschnitt 1.2, „Debian-Architekturen“). Über die einzelnen Knöpfe darunter schalten Sie zur Ansicht nach den Paketkategorien (Sektionen) (Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“) sowie dem Ursprung bzw. der Herkunft der Pakete (Abschnitt 3.1, „Paketquellen“), der Veröffentlichung (Abschnitt 2.10, „Veröffentlichungen“) und dem Distributionsbereich (Abschnitt 2.9, „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[21]. Ü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 PaketZum installieren vormerken (alternativ Strg+I oder einen Rechtsklick) aus. Über den Menüeintrag BearbeitenVorgemerkte Ä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 Abschnitt 6.3.1, „tasksel“). Dazu nutzen Sie den Menüpunkt BearbeitenPakete nach Aufgaben vormerken. Daraufhin erscheint ein ähnliches Auswahlfenster wie in Abbildung 6.8, „Paketauswahl einer ganzen Aufgabengruppe (Synaptic)“, 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.

Abbildung 6.8. Paketauswahl einer ganzen Aufgabengruppe (Synaptic)

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/synaptic-tasksel.png

6.4.2. Muon

Muon ist ein Paketmanager für KDE und als Klon von Synaptic (siehe Abschnitt 6.4.1, „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] ab der Veröffentlichung Debian 9 Stretch verfügbar, für Ubuntu bereits ab der Veröffentlichung 12.04 Precise Pangolin.

Abbildung 6.9. Softwareauswahl in muon

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/muon.png

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.

6.4.3. Smart Package Management (SmartPM)

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 Abschnitt 6.4.1, „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 zur aptsh (Abschnitt 6.2.3, „Die aptsh), zu wajig (Abschnitt 8.42.7, „wajig) und zu cupt (Abschnitt 6.2.5, „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 Abbildung 6.10, „Softwareauswahl in 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.

Abbildung 6.10. Softwareauswahl in smartpm

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/smartpm.png

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.

Paketinformationen zu kexi in der Shell von SmartPM. 

$ smart --shell
Smart Package Manager 1.4 - Shell Mode

Loading cache...
Updating cache...              ####################################### [100%]

smart> info kexi
Name: kexi
Version: 1:2.4.4-3
Priority: 0
Source: calligra_1:2.4.4-3
Group: database
License:
Installed Size: 8.8MB
Reference URLs: http://www.calligra-suite.org/kexi/
Flags:
Channels: DEB System
Summary: integrated database environment for the Calligra Suite
Description:
 Kexi is an integrated data management application. It can be used for
 creating database schemas, inserting data, performing queries, and
 processing data. Forms can be created to provide a custom interface to
 your data. All database objects - tables, queries and forms - are stored
 in the database, making it easy to share data and design.
 .
 Kexi is considered as a long awaited Open Source competitor for MS Access,
 Filemaker and Oracle Forms. Its development is motivated by the lack of
 Rapid Application Development (RAD) tools for database systems that are
 sufficiently powerful, inexpensive, open standards driven and portable
 across many operating systems and hardware platforms.
 .
 This package is part of the Calligra Suite.

smart>

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

Zusätzlicher Lesestoff

Eine ausführliche Beschreibung zum Programm mit weiteren Beispielen zur Konfiguration und zur Handhabung entnehmen Sie bitte dem Linux-User-Artikel zum gleichen Thema [Hofmann-Smartpm-LinuxUser].

6.4.4. Ubuntu Software Center

Canonical bietet mit dem Ubuntu Software Center [Ubuntu-Software-Center] eine weitere graphische Verwaltung zur Auswahl und Pflege ihres Softwarebestands an. Dieses Paket wurde 2010 auch in den Bestand von Debian als Paket namens software-center [Debian-Paket-software-center] übernommen, aber bereits 2014 wieder ausgelistet. Die Begründung ist, dass das Programm nicht mehr aktuell in Debian sei und auch bessere Alternativen existieren [RM-software-center]. Es ist daher in Debian 6 Squeeze und Debian 7 Wheezy enthalten, aber nicht mehr ab Debian 8 Jessie. Für Ubuntu steht es weiterhin stets in aktualisierter Form zur Verfügung [Ubuntu-Paket-software-center].

Wie bei den anderen bereits weiter oben vorgestellten Programmen können Sie damit nicht nur die benutzten Paketquellen verwalten, d.h. hinzufügen, ändern, löschen und verifizieren, sondern auch den Softwarebestand ihrer Systeme verändern. Über die Benutzeroberfläche erhalten Sie eine Anwendungsübersicht nach Kategorien, wählen daraus die gewünschten Softwarepakete aus und installieren, entfernen und aktualisieren diese (siehe Abbildung 6.11, „Softwareauswahl im Ubuntu Software Center (aus Xubuntu 13.04)“).

Abbildung 6.11. Softwareauswahl im Ubuntu Software Center (aus Xubuntu 13.04)

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/ubuntu-software-center.png

Bis zur Jahresmitte 2014 bestand seitens Canonical der Datenaustauschdienst Ubuntu One (siehe dazu [Ubuntu-One] und [Ubuntu-One-Wikipedia]). Das Ubuntu Software Center war in diesen Dienst integriert und bot Ihnen die Möglichkeit, über das Programm den Softwarebestand zwischen verschiedenen Rechnern abzugleichen. Das beinhaltete ebenso die Veränderungen im Paketbestand und listete auf, welche Pakete wann installiert, aktualisiert oder gelöscht wurden (siehe Abbildung 6.12, „Verlauf der Änderungen im Paketbestand“). Wie Ihnen das gleiche auf der Kommandozeile gelingt, lesen Sie unter Liste der zuletzt installierten Pakete anzeigen in Abschnitt 8.16, „Liste der zuletzt installierten Pakete anzeigen“.

Abbildung 6.12. Verlauf der Änderungen im Paketbestand

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/ubuntu-software-center-verlauf.png

Bei der Benutzung des Programms beachten Sie bitte, dass das Programm viele graphische Elemente und Inhalte enthält, die über das Internet bereitgestellt werden. Daher empfehlen wir Ihnen zur Benutzung eine Internetverbindung, da ansonsten viele Informationen in der Bedienoberfläche nicht angezeigt werden können. Desweiteren ist das Programm nur weitestgehend mit der Maus bedienbar und kaum über die Tastatur. Das ist nicht für alle Nutzungskonstellationen und Anwender hilfreich.

6.4.5. PackageKit

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[23] 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 Abschnitt 6.4.2, „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 Abbildung 6.13, „Gnome Packagekit mit ausgewähltem Paket dctrl-tools) und das Installationsprogramm zu Openmoko [OpenMoko].

Abbildung 6.13. Gnome Packagekit mit ausgewähltem Paket dctrl-tools

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/gnome-packagekit.png

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 (Abschnitt 6.4.3, „Smart Package Management (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 Kapitel 17, Fehlende Pakete bei Bedarf hinzufügen im Mittelpunkt.

6.4.6. GDebi

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 Abschnitt 6.2.1, „dpkg, Abschnitt 6.2.2, „APT“ und Abschnitt 8.36, „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 drei Komponenten — einem Kommandozeilenprogramm namens gdebi (aus dem Paket gdebi-core [Debian-Paket-gdebi-core]) und zwei graphischen Bedienoberflächen. Es existiert eine GTK-basierte Variante namens gdebi-gtk (aus dem Paket gdebi [Debian-Paket-gdebi] — siehe Abbildung 6.14, „gdebi mit den Informationen zum Paket apt-doc) und eine KDE-Variante namens gdebi-kde (aus dem gleichnamigen Paket gdebi-kde [Debian-Paket-gdebi-kde]).

Abbildung 6.14. gdebi mit den Informationen zum Paket apt-doc

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/gdebi-gtk.png

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.

Anzeige der Paketbeschreibung bei manuellem Aufruf von gdebi

# gdebi Desktop/odeskteam_3.10.5_debian_7.2_i386.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done
Building data structures... Done


oDesk Team - complete time-logging and verification system
 Who needs it: All providers are required to run oDesk Team in order to have a
 verified record of their work. oDesk Team is optional for buyers, however a
 lot of our buyers run it to have an online record of their work and be able to
 collaborate better with their remote team.
 .
 Note: This single-install download is the full oDesk Team client application,
 which will only be fully functional if used in conjunction with an oDesk Team
 Online Account with a valid license to access the Service. Review carefully
 our License Agreement before downloading.
Wollen Sie das Software-Paket installieren? [j/N]:
...
#

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 Abbildung 6.14, „gdebi mit den Informationen zum Paket apt-doc). 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 Kapitel 7, 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 Abschnitt 4.2, „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[24] 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 Abschnitt 32.1, „Nicht installierte Pakete mit lintian prüfen“.

Abbildung 6.15. gdebi-gtk mit den Informationen zum Paket zsh

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/gui-zur-paketverwaltung/gdebi-new.png

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 Abschnitt 3.3, „/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[25].

6.5. Webbasierte Programme

6.5.1. Ubuntu Landscape

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[26]. 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 Abbildung 6.16, „Rollback eines ausgewählten Pakets“).

Abbildung 6.16. Rollback eines ausgewählten Pakets

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/webbasierte-programme/ubuntu-landscape-rollback.png

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 Abschnitt 6.5.3, „Communtu“) kommen auch hier Metapakete (siehe Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“) verstärkt zum Einsatz. Darüber werden Paketgruppen und ganze Softwareprofile für die betreuten System realisiert und abgebildet.

6.5.2. Appnr

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 Abbildung 6.17, „Vorauswahl für Appnr im Webbrowser Iceweasel). 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.

Abbildung 6.17. Vorauswahl für Appnr im Webbrowser Iceweasel

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/webbasierte-programme/appnr.png

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 Kapitel 24, Webbasierte Installation von Paketen mit apturl genauer vorstellen.

6.5.3. Communtu

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 Abbildung 6.18, „Verfügbare Bündel auf der Webseite“). 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.

Abbildung 6.18. Verfügbare Bündel auf der Webseite

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/webbasierte-programme/communtu.png

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 Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“) sowie Kapitel 24, 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 einspielen kann.

6.5.4. Univention Corporate Server (UCS)

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 ein aktuelles Debian — derzeit die Version 7 Wheezy. 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 Abschnitt 6.3.1, „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 Abbildung 6.19, „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]).

Abbildung 6.19. Univention App Centre

werkzeuge/werkzeuge-zur-paketverwaltung-ueberblick/webbasierte-programme/univention-app-centre.png



[17] Weitere Optionen zu dpkg entnehmen Sie bitte der Manpage zum Programm

[18] Diese Eigenschaft stammt vom Programm gdebi (siehe Abschnitt 6.4.6, „GDebi“), welches ebenfalls vom APT-Entwickler Michael Vogt gepflegt wird.

[19] Unter Debian 7 Wheezy ist die Ausgabe derzeit defekt und als Bug #756841 hinterlegt, siehe https://bugs.debian.org/756841

[20] Es handelt sich dabei um eine hart in aptitude verdrahtete und schon sehr lange nicht mehr gepflegte Kategorisierung der Pakete

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

[22] Bislang scheint SmartPM diese Markierungen nicht mit APT oder aptitude zu synchronisieren. Dieses Verhalten ist als Bug registriert.

[23] Berechtigungsdienst, der die Kommunikation von Software via DBus-Protokoll untereinander regelt

[24] Verfügbar ab Debian 8 Jessie und Ubuntu 14.04 LTS Trusty Tahr

[25] Letzteres ist auch kein Wunder, da sowohl gdebi als auch diese Funktionalität von APT vom gleichen Autor stammen.

[26] Die Pakete dafür heißen landscape-client, landscape-client-ui, landscape-client-ui-install und landscape-common

Kapitel 7. Paketcache

7.1. Hintergrundwissen

Die deutsche Übersetzung zum Wort cache ist Zwischenspeicher oder Puffer. In der Manpage von apt-get wird dafür auch der Begriff lokales Depot verwendet.

Laden Sie mittels der APT-Infrastruktur Debian-Pakete vom Spiegelserver herunter, werden diese nicht sofort entpackt, sondern zunächst lokal zwischengespeichert („gecacht“). Vollständig heruntergeladene Pakete liegen im Verzeichnis /var/cache/apt/archives/, hingegen nur teilweise heruntergeladene Pakete unter /var/cache/apt/archives/partial/.

Erst wenn alle zur Installation oder Aktualisierung benötigten Pakete von APT oder aptitude heruntergeladen wurden und auch im Paketcache liegen, wird mit dem Auspacken und Installieren der Pakete begonnen. So ist garantiert, dass alle durch Abhängigkeiten notwendigen Pakete auch lokal verfügbar sind und nichts mehr fehlt. Die Pakete werden daraufhin von dpkg unter Verwendung der Bibliotheken (siehe Kapitel 5, APT und Bibliotheken) ausgepackt, die Dateien an die angegebene Stelle im Verzeichnisbaum kopiert und abschließend ggf. noch automatisch konfiguriert (siehe dazu Abschnitt 8.38, „Pakete konfigurieren“).

7.1.1. Was passiert, wenn nicht alle Pakete heruntergeladen werden konnten?

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 (TODO: Verifizieren), aptitude fragt Sie hingegen als Benutzer, ob Sie trotzdem fortsetzen oder 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.

7.2. Paketcache-Status

Den aktuellen Zustand des Paketcaches erfahren Sie mit Hilfe das Kommandos apt-cache stats. Es wertet den Paketcache hinsichtlich der gefundenen Symbole aus — d.h. die Namen, die Varianten und die Bezüge zwischen den Paketen, die sich derzeit im Cache befinden.

Informationen zum Zustand des Paketcache ausgeben. 

$ apt-cache stats
Gesamtzahl an Paketnamen: 47488 (950 k)
Gesamtzahl an Paketstrukturen: 47488 (2.279 k)
  davon gewöhnliche Pakete: 35987
  davon rein virtuelle Pakete: 371
  davon einzelne virtuelle Pakete: 4324
  davon gemischte virtuelle Pakete: 1029
  davon fehlend: 5777
Gesamtzahl an unterschiedlichen Versionen: 37547 (2.403 k)
Gesamtzahl an unterschiedlichen Beschreibungen: 87385 (2.097 k)
Gesamtzahl an Abhängigkeiten: 222388 (6.227 k)
Gesamtzahl an Version/Datei-Beziehungen: 40866 (654 k)
Gesamtzahl an Beschreibung/Datei-Beziehungen: 87385 (1.398 k)
Gesamtzahl an Bereitstellungen: 7563 (151 k)
Gesamtzahl an Mustern: 164 (1.732 )
Gesamtmenge des Abhängigkeits-/Versionsspeichers: 911 k
Gesamtmenge an Slack: 73,0 k
Gesamtmenge an Speicher: 11,8 M
$

Ist der Platz auf ihrem Speichermedium knapp, sehen Sie in der letzten Zeile der Ausgabe, welche Menge durch den Paketcache gerade belegt wird. Wie Sie darin wieder für Ordnung sorgen, lesen Sie unter „Paketcache aufräumen“ in Abschnitt 7.3, „Paketcache aufräumen“ nach.

7.3. Paketcache aufräumen

7.3.1. Weshalb aufräumen?

Der Paketcache belegt Speicherplatz auf dem Datenträger ihres Debian-Systems. Da dieser Bereich lediglich temporäre Daten beinhaltet, raten wir Ihnen, diesen regelmäßig aufzuräumen.

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

Bei ausgefeilteren Installationen bestehen häufig separate Partitionen für /var, /var/cache oder gar /var/cache/apt/archives. Läuft nur 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 Kapitel 27, Cache-Verzeichnis auf separater Partition.

7.3.2. Kommandos zum Aufräumen

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

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 EinstellungenDateien und selektieren im Dialogfenster den Eintrag „Nur Pakete löschen, die nicht länger verfügbar sind“ (siehe Abbildung 7.1, „Großreinemachen mit Hilfe von Synaptic“). 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:

Aufruf von apt-get mit ausdrücklicher Konfiguration. 

# apt-get -o APT::Clean-Installed=off autoclean
...
#

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 Abschnitt 8.36, „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.

Aufräumen mittels apt-get clean

# apt-get clean
# ls /var/cache/apt/archives/
lock  partial
#

Bei Synaptic bildet zunächst der Eintrag EinstellungenDateien den Ausgangspunkt. Über den Knopf „Alle Paketdateien im Zwischenspeicher löschen“ lösen Sie die Aufräumaktion aus (siehe Abbildung 7.1, „Großreinemachen mit Hilfe von Synaptic“).

Abbildung 7.1. Großreinemachen mit Hilfe von Synaptic

werkzeuge/paketcache/synaptic-paketcache-leeren.png

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 Kapitel 27, 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.

7.3.3. Empfehlungen zum Zeitpunkt des Aufräumens

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.

7.3.4. Automatisch und regelmäßig Aufräumen

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.

Einstellung APT::Periodic::Download-Upgradeable-Packages
Damit legen Sie die Regelmäßigkeit der Aktualisierung fest. Setzen Sie den Wert auf 1, so füllt der Cron-Job den Paketcache einmal pro Tag, falls Paketaktualisierungen verfügbar sind. Setzen Sie den Wert hingegen auf 7, so lädt er verfügbare Paketaktualisierungen nur einmal die Woche herunter. Der Wert 0 (Null) ist die Standardeinstellung und deaktiviert die Funktionalität vollständig.
Einstellung APT::Periodic::AutocleanInterval
Damit regeln Sie die Häufigkeit, mit der das Kommando apt-get autoclean ausgeführt wird. Auch hier steht der Wert für den Abstand in Tagen zwischen zwei Ausführungen. Der Wert 0 (Null) schaltet das nächtliche Aufräumen ganz ab und ist auch die Standardvorgabe.

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:

Schalter --clean-on-startup
entspricht dem Aufruf aptitude autoclean
Schalter --autoclean-on-startup
entspricht dem Aufruf aptitude clean

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

Kapitel 8. Paketoperationen

8.1. Paketoperationen und deren Abfolge

Als Paketoperation verstehen wir hier im Buch ein Kommando oder einen Aufruf eines Programms zur Paketverwaltung, mit dem Sie entweder den aktuellen Paketbestand ausgeben, in diesem Paketbestand nach bestimmten Kriterien suchen oder Änderungen im Paketbestand veranlassen. Für letzteres heißt das bspw. Paketlisten aktualisieren oder modifizieren, Pakete hinzufügen und auch Pakete wieder deinstallieren.

Wir besprechen die Paketoperationen in gleicher Reihenfolge. Den Anfang machen Aufrufe ohne Änderung des Paketbestands, d.h. bspw. Statusinformationen erhalten und die Recherche nach bestimmten Kriterien (Abschnitt 8.3, „Bekannte Paketnamen auflisten“ bis Abschnitt 8.31, „Paketdatei nur herunterladen“). Daran schließen sich Aufrufe an, die den Paketbestand verändern, d.h. neue Pakete hinzufügen und einrichten sowie Pakete deinstallieren und der Umgang mit Waisen (Abschnitt 8.32, „Installation zwischengespeicherter Pakete aus dem Paketcache“ bis Abschnitt 8.44, „Paketstatusdatenbank reparieren“). Den Abschluss bildet der Vorgang, eine ganze Distribution auf den neuen Stand zu bringen oder zu einer anderen Veröffentlichung zu wechseln (siehe Abschnitt 8.45, „Distribution aktualisieren (update und upgrade)“).

8.2. Paketlisten und Muster

Auch wenn bei den nachfolgend vorgestellten Paketoperationen und Beispielen stets Paketname im Singular steht, können Sie beim Aufruf einen oder mehrere exakte Paketnamen angeben. Diese Liste trennen Sie durch Leerzeichen, wobei die Reihenfolge der genannten Pakete im Allgemeinen keine Rolle spielt. Nachfolgend soll das an einem Aufruf mit apt-get zur Installation der Pakete xpdf, kile und cssed deutlich werden.

Installation der Pakete xpdf, kile und cssed mittels APT in einem Aufruf. 

# apt-get install xpdf kile cssed
...
#

Zulässig sind ebenfalls ein Fragment eines Namens oder auch ein Paketmuster über einen regulären Ausdruck. Dann werden alle Pakete ausgewählt, die auf das Fragment bzw. Muster passen. Das betrifft insbesondere die Kommandozeilenwerkzeuge dpkg, APT, aptitude und ara. Bei den graphischen Programmen wird das hingegen sehr unterschiedlich gehandhabt.

Auflistung aller Dokumentationspakete zu aptitude über ein Muster. 

# dpkg -l aptitude-doc*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name               Version        Architektur    Beschreibung
+++-==================-==============-==============-==========================================
un  aptitude-doc       <keine>                       (keine Beschreibung vorhanden)
ii  aptitude-doc-cs    0.6.8.2-1      all            Czech manual for aptitude, a terminal-base
ii  aptitude-doc-en    0.6.8.2-1      all            English manual for aptitude, a terminal-ba
ii  aptitude-doc-es    0.6.8.2-1      all            Spanish manual for aptitude, a terminal-ba
ii  aptitude-doc-fi    0.6.8.2-1      all            Finnish manual for aptitude, a terminal-ba
ii  aptitude-doc-fr    0.6.8.2-1      all            French manual for aptitude, a terminal-bas
ii  aptitude-doc-it    0.6.8.2-1      all            Italian manual for aptitude, a terminal-ba
ii  aptitude-doc-ja    0.6.8.2-1      all            Japanese manual for aptitude, a terminal-b

Verwenden Sie das multiarch-Feature (siehe Abschnitt 1.2.3, „Multiarch: Mehrere Architekturen gleichzeitig auf einem System“), geben Sie hinter dem Paketnamen noch einen Doppelpunkt und danach die gewünschte Architektur an. Damit werden nur die Pakete berücksichtigt, die für die angegebene Architektur bereitstehen. Benennen Sie keine Architektur explizit, werden die Pakete ihrer Systemarchitektur benutzt.

Suche nach Paketen für die Architektur i386

# dpkg -l "*:i386"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  libc6:i386     2.19-11      i386         GNU C Library: Shared libraries
#

8.3. Bekannte Paketnamen auflisten

APT kann Ihnen ausgeben, welche Pakete es überhaupt kennt. Dazu verfügt das Werkzeug apt-cache über das Unterkommando pkgnames. Die Ausgabe, die Sie nach dessen Aufruf erhalten, hängt von den von Ihnen genutzten Paketquellen und den darüber verfügbaren Paketen ab.

Die nachfolgende Ausgabe listet die Pakete zusätzlich alphabetisch aufsteigend sortiert und seitenweise auf. Im Aufruf kommen dazu die beiden UNIX-Kommandos sort und more zum Einsatz.

Seitenweise und alphabetisch sortierte Ausgabe der Paketnamen, die APT kennt. 

$ apt-cache pkgnames | sort | more
0ad
0ad-data
0ad-dbg
2ping
2vcard
3270-common
389-console
3dchess
...
$

In eine ähnliche Richtung gehen die beiden Werkzeuge grep-available und grep-aptavail aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools]. Beide liefern Ihnen Informationen darüber, ob und in welcher Version das von Ihnen angefragte Paket aus den Paketquellen zur Verfügung steht. Während grep-available weitestgehend die Informationen ausgibt, die Sie mittels dpkg -s erhalten, liefert Ihnen grep-aptavail die vollständigen Informationen, so bspw. auch, wo Sie das Paket in der Verzeichnishierarchie der Paketquellen finden. Nachfolgendes Beispiel zeigt die Recherche anhand des Pakets xpdf.

Paketinformationen zu xpdf

$ grep-aptavail -PX xpdf
Package: xpdf
Version: 3.03-10
Installed-Size: 447
Maintainer: Michael Gilbert <mgilbert@debian.org>
Architecture: i386
Provides: pdf-viewer
Depends: lesstif2 (>= 1:0.94.4), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler19 (>= 0.18.4), libstdc++6 (>= 4.1.1), libx11-6, libxt6
Recommends: poppler-utils, poppler-data, gsfonts-x11, cups-bsd
Description: Portable Document Format (PDF) reader
Homepage: http://www.foolabs.com/xpdf/
Description-md5: fa7a14f325304cc49bbc0086a88d330e
Tag: implemented-in::c++, interface::x11, role::program, scope::application,
 uitoolkit::motif, use::viewing, works-with-format::pdf,
 works-with::text, x11::application
Section: text
Priority: optional
Filename: pool/main/x/xpdf/xpdf_3.03-10_i386.deb
Size: 196690
MD5sum: 02e96c8b0c4b82a496deb2c386ed1042
SHA1: 233ddb2074f1694e8fda75c63fb714464d42e15b
SHA256: 2cced2a99c1b028bd5b2c5e37c3a6206c643167b1a5465481e5621f2d3f390a3
$

Kennen Sie jedoch nur ein Fragment eines Paketnamens, gibt es einen üblichen Weg und eine Abkürzung. Der übliche Weg kombiniert apt-cache und das UNIX-Kommando grep über eine Pipe miteinander. Muster bezeichnet hier das Ihnen bereits bekannte Fragment. Nachfolgend sehen Sie die Recherche nach dem Muster aptitude.

Suche nach dem Muster aptitude

$ apt-cache pkgnames | grep aptitude
aptitude
aptitude-common
aptitude-doc-cs
aptitude-doc-fi
aptitude-doc-en
aptitude-doc-es
aptitude-doc-fr
aptitude-doc-ja
aptitude-doc-it
aptitude-dbg
$

Die Abkürzung führt über das Werkzeug dglob aus dem Paket debian-goodies [Debian-Paket-debian-goodies]. Es setzt auf apt-file auf und liefert eine identische Ausgabe – aber der Tippaufwand ist geringer. Nachfolgende Ausgabe zeigt Ihnen das Suchergebnis zu den Paketen, die das Muster ttd beinhalten. Damit finden Sie beispielsweise alle Pakete, die zum Spiel Open Transport Tycoon Deluxe (openttd) gehören.

Die im Aufruf verwendete Option -a listet Ihnen alle Pakete in alphabetisch aufsteigender Reihenfolge auf – unabhängig davon, ob diese jeweils auf Ihrem System installiert sind oder nicht. Ohne die Option beschränkt sich dglob nur auf die bereits installierten Pakete.

Rechercheergebnis von dglob mit dem Muster ttd

$ dglob -a ttd
liblttd-dev
liblttd0
openttd
openttd-data
openttd-dbg
openttd-opengfx
openttd-openmsx
openttd-opensfx
$

8.4. Paketstatus erfragen

Diese Aktion betrifft meist nur ein einzelnes Paket, welches auf dem System installiert ist oder war. Im Alltag ergeben sich mehrere Situationen, in denen das Wissen über den Zustand eines Pakets wichtig ist.

Die Grundfrage ist häufig, ob derzeit ein bestimmtes Paket oder Programm auf Ihrem Linuxsystem installiert ist, und falls ja, in welchem Zustand befindet sich dieses Paket. Es kann vollständig oder nur teilweise installiert sein, liegt in nicht konfiguriertem Status vor oder wurde möglicherweise bereits wieder entfernt. Zu klären ist in dem Fall auch, ob es vollständig entfernt wurde oder noch „Reste“ übrig sind. Dazu zählen die Konfigurationsdateien zu den Paketen bzw. den Programmen daraus. Darüberhinaus ist interessant, welche zusätzlichen Dateien verfügbar sind, bspw. Übersetzungen bzw. Sprachpakete.

Eine kompakte Übersicht erhalten Sie mit Hilfe des Kommandos dpkg -l Paketname. In Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“ besprechen wir das genauer. Ausführlicher sind die Ausgaben zu den dpkg-Schaltern -s und -I sowie den Aufrufen von aptitude show, apt-cache show sowie apt-mark.

8.4.1. dpkg -s Paketname und dlocate -s Paketname

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 Abschnitt 2.11, „Benennung einer Paketdatei“), Status, Priorität (siehe Abschnitt 2.13, „Paket-Priorität und essentielle Pakete“), Paketkategorie (siehe Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“), installierte Größe, Maintainer, Architektur ( siehe Abschnitt 1.2, „Debian-Architekturen“) und Version (siehe Abschnitt 2.11, „Benennung einer Paketdatei“) 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].

Status des Pakets htop mittels dpkg ermitteln. 

$ dpkg -s htop
Package: htop
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 195
Maintainer: Eugene V. Lyubimkin <jackyf@debian.org>
Architecture: i386
Version: 1.0.1-1
Depends: libc6 (>= 2.3.4), libncursesw5 (>= 5.6+20070908), libtinfo5
Suggests: strace, ltrace
Description: interactive processes viewer
 Htop is an ncursed-based process viewer similar to top, but it
 allows one to scroll the list vertically and horizontally to see
 all processes and their full command lines.
 .
 Tasks related to processes (killing, renicing) can be done without
 entering their PIDs.
Homepage: http://htop.sourceforge.net
$

8.4.2. dpkg -I deb-Datei

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.

Detailinformationen des Pakets htop mittels dpkg ermitteln. 

$ dpkg -I htop_1.0.3-1_amd64.deb
 neues Debian-Paket, Version 2.0.
 Größe 75316 Byte: control-Archiv= 1156 Byte.
     593 Byte,    17 Zeilen      control
     618 Byte,    10 Zeilen      md5sums
     185 Byte,     7 Zeilen   *  postinst             #!/bin/sh
     160 Byte,     5 Zeilen   *  postrm               #!/bin/sh
 Package: htop
 Version: 1.0.3-1
 Architecture: amd64
 Maintainer: Eugene V. Lyubimkin <jackyf@debian.org>
 Installed-Size: 204
 Depends: libc6 (>= 2.15), libncursesw5 (>= 5.6+20070908), libtinfo5
 Suggests: strace, ltrace
 Section: utils
 Priority: optional
 Homepage: http://hisham.hm/htop/
 Description: interactive processes viewer
  Htop is an ncursed-based process viewer similar to top, but it
  allows one to scroll the list vertically and horizontally to see
  all processes and their full command lines.
  .
  Tasks related to processes (killing, renicing) can be done without
  entering their PIDs.
$

8.4.3. apt-cache show Paketname

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 Kapitel 13, Erweiterte Paketklassifikation mit Debtags) zum Paket, der Dateiname und Pfad im Paketmirror und die GPG-Keys zur Validierung des Pakets (siehe Abschnitt 8.35, „Bezogenes Paket verifizieren (GPG-Key)“).

Status des Pakets htop mit apt-cache ermitteln. 

$ apt-cache show htop
Package: htop
Version: 1.0.1-1
Installed-Size: 195
Maintainer: Eugene V. Lyubimkin <jackyf@debian.org>
Architecture: i386
Depends: libc6 (>= 2.3.4), libncursesw5 (>= 5.6+20070908), libtinfo5
Suggests: strace, ltrace
Description-de: Interaktiver Prozessbetrachter
 Htop ist ein ncurses-basierter Prozessbetrachter ähnlich wie top, jedoch
 ermöglicht er Ihnen die Liste vertikal und horizontal zu durchlaufen, um
 alle Prozesse und deren vollständige Kommandozeilen zu sehen.
 .
 Mit Prozessen verbundene Aufgaben wie das (zwangsweise) Beenden und die
 Neufestlegung der Priorität können ohne Eingabe der PIDs erledigt werden.
Homepage: http://htop.sourceforge.net
Description-md5: 8eb5aa19b3c92a975dc78e2165f6688d
Tag: admin::monitoring, interface::text-mode, role::program, scope::utility,
 uitoolkit::ncurses, use::monitor, works-with::software:running
Section: utils
Priority: optional
Filename: pool/main/h/htop/htop_1.0.1-1_i386.deb
Size: 71634
MD5sum: 9a12ed8d648a0b16a08f16aa06a6ee9c
SHA1: 25eb706b210a165efae3a149338c129c383b82df
SHA256: b41970322366d8a8fd174aa32b223dd54d05e4ab1dafddd97390e0fc5f17ed41
$

8.4.4. apt-cache showpkg Paketname

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 Abschnitt 8.17, „Paketabhängigkeiten anzeigen“.

Die nachfolgenden Ausgaben zeigen die Detailansicht für die Pakete htop und openvpn. Für ersteres steht nur ein Paket zur Verfügung, bei dem zweiten hingegen eine aktualisierte Variante. Daher umfaßt die Ausgabe zwei Einträge mit den Versionen 2.3.4-5 und 2.3.4-5+deb8u1, wobei die letztgenannte Version noch auf dem Paketmirror liegt.

Detailansicht zum Paket htop via apt-cache showpkg (Debian 7 Wheezy). 

$ apt-cache showpkg htop
Package: htop
Versions:
1.0.1-1 (/var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages
                  MD5: 8eb5aa19b3c92a975dc78e2165f6688d
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-de
                  MD5: 8eb5aa19b3c92a975dc78e2165f6688d
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_i18n_Translation-en
                  MD5: 8eb5aa19b3c92a975dc78e2165f6688d


Reverse Depends:
  education-common,htop
Dependencies:
1.0.1-1 - libc6 (2 2.3.4) libncursesw5 (2 5.6+20070908) libtinfo5 (0 (null)) strace (0 (null)) ltrace (0 (null))
Provides:
1.0.1-1 -
Reverse Provides:
$

Detailansicht zum Paket openvpn via apt-cache showpkg (Debian 8 Jessie). 

apt-cache showpkg openvpn
Package: openvpn
Versions:
2.3.4-5+deb8u1 (/var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_binary-amd64_Packages)
 Description Language:
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_binary-amd64_Packages
                  MD5: 2ebe91e411d46309a61861db507e5c2f
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_i18n_Translation-de
                  MD5: 2ebe91e411d46309a61861db507e5c2f
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_i18n_Translation-en
                  MD5: 2ebe91e411d46309a61861db507e5c2f

2.3.4-5 (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_binary-amd64_Packages
                  MD5: 2ebe91e411d46309a61861db507e5c2f
 Description Language: de
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_i18n_Translation-de
                  MD5: 2ebe91e411d46309a61861db507e5c2f
 Description Language: en
                 File: /var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_i18n_Translation-en
                  MD5: 2ebe91e411d46309a61861db507e5c2f


Reverse Depends:
  openvpn:i386,openvpn
  openvpn-auth-radius,openvpn 2
  openvpn-auth-ldap,openvpn 2
  network-manager-openvpn,openvpn 2.1~rc9
  kvpnc,openvpn
  gadmin-openvpn-server,openvpn
  gadmin-openvpn-client,openvpn
  eurephia,openvpn 2
  collectd-core,openvpn
Dependencies:
2.3.4-5+deb8u1 - debconf (18 0.5) debconf-2.0 (0 (null)) libc6 (2 2.15) liblzo2-2 (0 (null)) libpam0g (2 0.99.7.1) libpkcs11-helper1 (2 1.11) libssl1.0.0 (2 1.0.0) init-system-helpers (2 1.18~) initscripts (2 2.88dsf-13.3) iproute2 (0 (null)) openssl (0 (null)) resolvconf (0 (null)) easy-rsa (0 (null)) openvpn:i386 (0 (null))
2.3.4-5 - debconf (18 0.5) debconf-2.0 (0 (null)) libc6 (2 2.15) liblzo2-2 (0 (null)) libpam0g (2 0.99.7.1) libpkcs11-helper1 (2 1.11) libssl1.0.0 (2 1.0.0) init-system-helpers (2 1.18~) initscripts (2 2.88dsf-13.3) iproute2 (0 (null)) openssl (0 (null)) resolvconf (0 (null)) easy-rsa (0 (null)) openvpn:i386 (0 (null))
Provides:
2.3.4-5+deb8u1 -
2.3.4-5 -
Reverse Provides:
$

8.4.5. aptitude show Paketname

Das Ergebnis des Aufrufs von aptitude show Paketname kombiniert die Ausgabe von dpkg -s mit Teilen von apt-cache show. Hervorzuheben sind die vollständig übersetzte Ausgabe samt Paketbeschreibung (Lokalisierung), die Paketflags (siehe Abschnitt 2.15, „Lokale Paketmarkierungen“) und die Debtags (siehe Kapitel 13, Erweiterte Paketklassifikation mit Debtags) zum Paket.

Abbildung 8.1. Ausgabe der Statusinformationen zum Paket htop mittels aptitude

werkzeuge/paketoperationen/aptitude-show.png

8.4.6. Anfragen mit apt-mark

apt-mark ist ebenfalls ein Kommando aus dem Paket apt. Es zeigt Ihnen einerseits die Pakete an, die bereits mit einem bestimmten Paketflag (siehe Abschnitt 2.15, „Lokale Paketmarkierungen“) versehen wurden, andererseits erlaubt es Ihnen auch, diese Paketflags explizit zu setzen.

Mit den beiden Schaltern showauto und showmanual zeigen Sie die automatisch bzw. manuell installierten Pakete an. Die nachfolgende Ausgabe zeigt letzteres, auf automatisch installierte Pakete gehen wir in Abschnitt 8.10, „Automatisch installierte Pakete anzeigen“ genauer ein.

Manuell installierte Pakete anzeigen. 

$ apt-mark showmanual '.*tex$'
dblatex
texlive-xetex
$

Für Pakete, deren aktueller Zustand gehalten werden soll, hilft Ihnen dieser Aufruf mit dem Schalter showhold. Hier sehen Sie das in Kombination mit den beiden Schaltern hold und unhold zum Setzen und Entfernen der Markierung am Beispiel des Pakets xpdf.

Pakete, deren Zustand gehalten wird. 

# apt-mark hold xpdf
xpdf auf Halten gesetzt.
# apt-mark showhold xpdf
xpdf
# apt-mark unhold xpdf
Halten-Markierung für xpdf entfernt.
#

Weiterführende Informationen zu den vier Schaltern auto, manual, hold und unhold erhalten Sie unter „Paketflags“ (siehe Abschnitt 2.15, „Lokale Paketmarkierungen“), „Festlegen einer Paketversion durch explizites Setzen einer Markierung mit apt-mark“ (siehe Kapitel 16, Ausgewählte Pakete nicht aktualisieren) sowie in „Warum ist ein Paket (nicht) installiert“ (siehe Abschnitt 8.15, „Warum ist ein Paket installiert“).

8.5. Liste der installierten Pakete anzeigen und deuten

Diese Aktion betrifft häufig nicht nur ein einzelnes Paket, sondern den Gesamtbestand an Software, die auf Ihrem Linuxsystem installiert sind oder waren. Im Alltag ergeben sich eine ganze Reihe von Anwendungsfällen, bei denen diese Aktion durchgeführt wird.

Hintergrund für den Fall 1 ist der Wunsch nach einem Überblick zum Gesamtzustand eines Systems und vor allem der Software, die darauf installiert ist. Das betrifft insbesondere die Rechnersysteme, die Sie nicht selbst eingerichtet haben und deren Betreuung Ihnen obliegt, bspw. Geräte im Auslieferungszustand oder im Rahmen der Wartung als Bestandteil eines Kundenauftrags. Dabei kommt häufig die Berücksichtigung „gewachsener Infrastruktur“ ins Spiel.

Fall 2 betrifft „großflächige“ Änderungen auf einem Rechnersystem. Sie überprüfen, ob diese korrekt abgelaufen sind. Fall 3 betrifft die Entwicklung, hier ist die Fehlersuche bei den Paketwerkzeugen zu nennen.

Zu den konkreten Aktionen zählt weiterhin das Herausfinden, ob ein bestimmtes Paket oder Programm auf Ihrem Rechnersystem überhaupt installiert ist, und falls ja, ob dieses vollständig installiert und (bereits) konfiguriert wurde. Wurde es hingegen entfernt, ist zu klären, ob es vollständig entfernt wurde oder noch „Reste“ übrig sind, bspw. paketspezifische Konfigurationsdateien.

Für die Kommandozeile existieren zwei grundlegende Möglichkeiten. Einerseits ist das dpkg -l und andererseits aptitude search ~i. Die Darstellung in den graphischen Programme klären wir weiter unten genauer.

8.5.1. dpkg -l Paketname (Langform --list)

dpkg wird für diese Aufgabe sehr häufig genutzt. Ohne die Angabe des Paketnamens zeigen Sie alle Pakete und Paketreste an, die auf Ihrem System derzeit installiert sind. Geben Sie ein oder mehrere Pakete als Parameter durch Leerzeichen getrennt an, erhalten Sie nur Informationen zu diesen benannten Paketen. In nachfolgender Paketliste zeigen die einzelnen Spalten nacheinander den Paketzustand, den Namen des Pakets (siehe Abschnitt 2.11, „Benennung einer Paketdatei“), dessen Version und die Kurzbeschreibung dazu.

Vollständige Paketliste mit dpkg

$ dpkg -l
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                      Version                              Beschreibung
+++-=========================================-====================================-==========================
====================================================
ii  a2ps                                      1:4.14-1.1                           GNU a2ps - 'Anything to Po
stScript' converter and pretty-printer
rc  bsh                                       2.0b4-12                             Java scripting environment
 (BeanShell) Version 2
...
un  xfce4-icon-theme                          <keine>                              (keine Beschreibung vorhanden)
$

Die ersten drei Spalten jeder ausgegebenen Zeile interpretieren Sie anhand der Tabelle 8.1, „Paketzustand deuten“. Die Begriffe in Klammern nennen die englischen Übersetzungen – i.d.R. ist das die Langform der jeweiligen Option. Mit Ausnahme von W für aWaited trigger entspricht dabei der verwendete Buchstabe in der Spalte jeweils dem Anfangsbuchstaben der Langform der Option.

Tabelle 8.1. Paketzustand deuten

gewünschte Aktion durch den Paketmanager Paketstatus Fehler-Schalter

u: Unbekannt (unknown)

n: Paket ist nicht installiert (not installed)

(leer): kein Fehler

i: Installieren (installed)

c: nur die Konfigurationsdatei ist vorhanden (configured)

R: eine Neuinstallation ist notwendig (reinstall)

h: Halten (hold)

H: Paket ist nur halb installiert (half installed)

r: Entfernen (remove)

U: Paket wurde entpackt (unpacked)

p: Vollständig Löschen (purge)

F: Fehlgeschlagene Konfiguration (failed)

W: Trigger erwartet (aWaited trigger)

t: Trigger anhängig (trigger)

i: Installiert (installed)


Kleinbuchstaben zeigen dabei an, dass alles im grünen Bereich ist. Großbuchstaben heben hingegen Fehlerfälle oder auch Zustände hervor, die ihrerseits eine genauere Begutachtung und eine Aktion zu diesem Paket erfordern. Obige Darstellung mit Buchstaben verwendet sowohl dpkg, als auch aptitude. Tabelle 8.2, „Alltägliche Kombinationen zum Paketzustand“ zeigt Ihnen die Status-Kombinationen, die Ihnen häufig im Alltag begegnen werden.

Tabelle 8.2. Alltägliche Kombinationen zum Paketzustand

Paketstatus Beschreibung

ii

das Paket ist vollständig und fehlerfrei installiert sowie konfiguriert.

rc

das Paket wurde gelöscht, aber die Konfigurationsdateien sind noch gespeichert (Abkürzung für removed, configured, no error).

un

unbekanntes, nicht installiertes Paket (Abkürzung für unknown, not installed).

hi

das Paket ist installiert, aber auf hold gesetzt. Bei Softwareaktualisierungen wird das Paket nicht berücksichtigt und in seinem derzeitigen Zustand belassen (siehe Paketflags in Abschnitt 2.15, „Lokale Paketmarkierungen“).


8.5.2. aptitude search ~i

aptitude kennt dazu das Unterkommando search und erwartet danach entweder einen Paketnamen oder ein Flag. In diesem Fall ist es das Flag ~i für „installierte Pakete“ (Langform ?installed).

Wie bereits oben genannt, verwendet aptitude in der Ausgabe die gleichen Buchstaben wie dpkg (siehe Tabelle 8.1, „Paketzustand deuten“). Der Buchstabe i bezeichnet ein installiertes Paket, A in der dritten Spalte markiert „automatisch installiert“ und deutet auf eine automatisch erfüllte Paketabhängigkeit hin (siehe dazu Abschnitt 8.10, „Automatisch installierte Pakete anzeigen“). Daneben sehen Sie in der Ausgabe noch den Namen und die Kurzbeschreibung zum jeweiligen Paket.

aptitude listet die installierten LaTeX-Pakete auf. 

$ aptitude search ~i | grep texlive
i   texlive                         - TeX Live: Eine anständige Auswahl der TeX-
i A texlive-base                    - TeX Live: Grundlegende Programme und Datei
i A texlive-bibtex-extra            - TeX Live: Extra BibTeX styles
i A texlive-binaries                - Binärdateien für TeX Live
i A texlive-common                  - TeX Live: Basiskomponenten
i A texlive-doc-base                - TeX Live: Dokumentation für TeX Live
$

8.5.3. Weitere Möglichkeiten

Graphische Programme wie beispielsweise Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) und SmartPM (siehe Abschnitt 6.4.3, „Smart Package Management (SmartPM)“) verwenden keine Buchstaben zur Kennzeichnung des Paketstaus, sondern nutzen stattdessen verschiedenfarbige Kästchen („Icons“). In Abbildung 8.2, „Icons zur Darstellung des Paketstatus“ sehen Sie alle Möglichkeiten in der vollständigen Übersicht. Installierte Pakete erkennen Sie an der grünen Farbe, weiß/hellgrau kennzeichnet nicht installierte Pakete und rot steht hier für defekte Pakete (Status „broken“).

Abbildung 8.2. Icons zur Darstellung des Paketstatus

werkzeuge/paketoperationen/smartpm-icons.png

8.6. Liste der installierten Kernelpakete anzeigen

Bei dieser Aufgabe hilft Ihnen das Werkzeug dlocate [Debian-Paket-dlocate] und zeigt Ihnen an, welche Linux-Kernel und dazugehörigen Pakete auf Ihrem Linuxsystem installiert sind. Es kennt dazu zwei Aufrufvarianten – dlocate -k für die Basisinformationen und dlocate -K für eine ausführlichere Darstellung.

Die Basisvariante enthält lediglich eine Auflistung der installierten Pakete und zeigt daher nur den Paketnamen (siehe Abschnitt 2.11, „Benennung einer Paketdatei“) an. Die Ausgabe erfolgt dabei ohne Sortierung.

Auflistung der installierten Kernelpakete mit dlocate

$ dlocate -k
linux-image-686-pae
linux-headers-3.2.0-4-686-pae
linux-image-2.6-686
linux-image-3.2.0-4-686-pae
linux-headers-3.2.0-4-common
linux-headers-686-pae
$

Die ausführliche Darstellung entspricht einer Ausgabe von dpkg und zeigt den Installationsstatus, den Paketnamen, die Version und die Paketbeschreibung.

Auflistung der installierten Kernelpakete analog zu dpkg

$ dlocate -K
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                 Version              Description
+++-====================-====================-==========================================================
ii  linux-headers-3.2.0- 3.2.51-1             i386 Header files for Linux 3.2.0-4-686-pae
ii  linux-headers-3.2.0- 3.2.51-1             i386 Common header files for Linux 3.2.0-4
ii  linux-headers-686-pa 3.2+46               i386 Header files for Linux 686-pae configuration (meta-pack
ii  linux-image-2.6-686  3.2+46               i386 Linux for modern PCs (dummy package)
ii  linux-image-3.2.0-4- 3.2.51-1             i386 Linux 3.2 for modern PCs
ii  linux-image-686-pae  3.2+46               i386 Linux for modern PCs (meta-package)
$

8.7. Liste der installierten, nicht-freien Pakete anzeigen

Mit dem Kommando vrms aus dem gleichnamigen Paket vrms [Debian-Paket-vrms] erhalten Sie eine Übersicht, welche nicht-freien Pakete auf Ihrem System installiert sind. vrms steht dabei als Abkürzung für „Virtual Richard M. Stallman“ und erinnert an den Initiator der GNU-Lizenzen.

Das nachfolgende Beispiel listet die einzelnen Pakete auf, die aus den beiden Bereichen non-free und contrib ausgewählt wurden, Neben jedem Paket sehen Sie eine Kurzbeschreibung. Die Darstellung entspricht dem Schalter -e (Langform --explain) und ist seit Debian 8 Jessie die Standardeinstellung.

Ausgabe von vrms -e auf einem Desktop-System (Debian 7 Wheezy). 

$ vrms -e

             Non-free packages installed on efho-mobil

firmware-iwlwifi                    Binary firmware for Intel PRO/Wireless 3945 and 802.11
nautilus-dropbox                    Dropbox integration for Nautilus
openttd-opensfx                     sound set for use with the OpenTTD game
opera                               Fast and secure web browser and Internet suite
skype                               Skype
unrar                               Unarchiver for .rar files (non-free version)

             Contrib packages installed on efho-mobil

flashplugin-nonfree                 Adobe Flash Player - browser plugin

  6 non-free packages, 0.2% of 2696 installed packages.
  1 contrib packages, 0.0% of 2696 installed packages.
$

Benötigen Sie hingegen lediglich eine Paketliste ohne zusätzliche Informationen, hilft Ihnen der Schalter -s (Langform --sparse) weiter. Der Name jedes Pakets wird in einer einzelnen Zeile ausgegeben.

Nach den Paketen aus dem Bereich non-free listet vrms die contrib-Pakete auf. Die Auflistung beider Bereiche wird durch eine schlichte Leerzeile voneinander getrennt und erlaubt somit eine leichte Weiterverarbeitung, bspw. in einem Shellskript.

Ausgabe von vrms -s auf einem Desktop-System (Debian 8 Jessie). 

$ vrms -s
firmware-iwlwifi
ldraw-parts
skype

flashplugin-nonfree
virtualbox
virtualbox-dkms
virtualbox-guest-dkms
virtualbox-guest-utils
virtualbox-guest-x11
virtualbox-qt
$

8.8. Neue Pakete anzeigen

Zu den neuen Paketen zählen die Pakete, die derzeit nicht installiert sind bzw. die noch nie installiert waren. Wurde ein Paket von Ihnen deinstalliert, aber die Konfigurationsdatei blieb erhalten, gilt das entsprechende Paket hingegen nicht mehr als neu. Haben Sie jedoch die Konfigurationsdatei mittels purge ebenfalls gelöscht, hat aptitude keine Erinnerung mehr an das Paket und betrachtet es wieder als neu.

aptitude verfügt mit ~N (Langform ?new) über ein Suchmuster, um diese Pakete aufzuspüren. Jede ausgegebene Zeile beginnt mit dem Paketstatus — hier der Kleinbuchstabe p zur Kennzeichnung als neues Paket --, gefolgt vom Paketnamen und der Kurzbeschreibung zum Paket.

Auflistung aller neuen Pakete mittels aptitude (Auszug). 

$ aptitude search ~N
p   0ad              - Echtzeit-Strategiespiel über antike Kriegs
p   0ad-data         - Real-time strategy game of ancient warfare
p   0ad-dbg          - Echtzeit-Strategiespiel über antike Kriegs
p   2ping            - Ping-Hilfswerkzeug, um gerichteten Paketve
p   2vcard           - Perl-Skript zur Konvertierung eines Adress
...
$

8.9. Pakete nach Prioritäten finden

Wie bereits in „Paket-Priorität und essentielle Pakete“ in Abschnitt 2.13, „Paket-Priorität und essentielle Pakete“ beschrieben, ist jedem Debianpaket eine bestimmte Wichtigkeit zugeordnet. Dazu zählen erforderlich (required), wichtig (important), standard (standard), optional (optional), extra (extra) und die Markierung essentiell (essential).

Mit aptitude können Sie die Paketliste nach diesen Mustern filtern. Dafür kennt das Programm die Suchoption ?priority(wichtigkeit) bzw. ~pWichtigkeit als Kurzform. Als Wichtigkeit tragen Sie das entsprechende englische Schlüsselwort ein, bspw. extra für ?priority(extra). Nachfolgend sehen Sie die Pakete, die entsprechend markiert wurden.

Auflistung der extra-Pakete durch aptitude

$ aptitude search '?priority(extra)'
p   0ad-dbg          - Echtzeit-Strategiespiel über antike Kriegs
p   389-console      - 389 Management Console
p   4digits          - Zahlenratespiel oder »Bulls and Cows«
p   4store           - Engine zur Datenbankspeicherung und -abfra
p   7kaa-dbg         - Seven Kingdoms Ancient Adversaries - Debug
...
$

Essentielle Pakete bezeichnen grundlegende Pakete im Paketbestand. aptitude verfügt über eine spezielle Option ~E (alternativ als Langform ?essential), um diese essentiellen Pakete anzuzeigen. Dazu rufen Sie es wiederum mit dem Unterkommando search auf und erhalten eine Ausgabe auf dem Terminal, die ähnlich zu nachfolgender ist:

Auflistung der essentiellen Pakete durch aptitude

$ aptitude search ~E
i A apt              - Paketverwaltung für die Befehlszeile
i   base-files       - Verschiedene Dateien für das Debian-Basiss
i   base-passwd      - Debian Base System Password- und Group-Dat
i   bash             - GNU Bourne Again SHell
i   bsdutils         - Minimalauswahl von Kommandos aus 4.4BSD-Li
i   coreutils        - Grundlegende GNU-Werkzeuge
i A dash             - POSIX-konforme Shell
i   debianutils      - Verschiedene Hilfsprogramme speziell für D
i A diffutils        - Hilfsprogramme zum Dateivergleich
i   dpkg             - Debian-Paketverwaltungssystem
i   e2fsprogs        - ext2-/ext3-/ext4-Dateisystemwerkzeuge
i   findutils        - Werkzeuge zum Auffinden von Dateien - find
i   grep             - GNU grep, egrep und fgrep
i   gzip             - GNU-Werkzeuge zur Dateikomprimierung
i   hostname         - Werkzeug zum Einrichten und Anzeigen des H
i A libc-bin         - Die »Embedded GNU C Library«: Binärdateien
i   login            - System-Login-Werkzeuge
i   mount            - Tools für das Mounten und die Manipulation
i   ncurses-base     - Beschreibungen gebräuchlicher Terminaltype
i   ncurses-bin      - terminalbezogene Programme und Handbuchsei
i   perl-base        - Minimales Perl-System
i   sed              - Der GNU Streameditor sed
i   sysvinit         - System-V-artige Init-Werkzeuge
i   sysvinit-utils   - System-V-artige Init-Werkzeuge
i   tar              - GNU-Version des tar-Archivierungsprogramms
i   util-linux       - Verschiedene System-Kommandos
$

Auffällig an obiger Auflistung ist, dass diese das Paket apt enthält, obwohl wir in Abschnitt 2.13, „Paket-Priorität und essentielle Pakete“ geschrieben haben, dass Sie ein autarkes System auch problemlos ohne APT betreiben können. Der Grund hierfür ist, dass APT sich selbst als essentiell ansieht und sich deswegen selbst nicht deinstallieren will. Da Aptitude zum Teil APTs Bibliotheken benutzt, sieht es diesen Fall genauso[27].

8.10. Automatisch installierte Pakete anzeigen

Darunter fallen Pakete, die automatisch von der Paketverwaltung auf Ihrem System installiert wurden. Das geschieht, wenn Abhängigkeiten von anderen Paketen erfüllt werden müssen. dpkg kann diese Information nicht auswerten, jedoch stehen Ihnen mit apt-mark und aptitude gleich zwei Varianten auf dem Terminal bereit.

8.10.1. apt-mark benutzen

Das Paket apt [Debian-Paket-apt] beinhaltet das Werkzeug apt-mark. Über das Unterkommando showauto erhalten Sie alle entsprechend markierten Pakete. Möchten Sie die Liste einschränken, akzeptiert apt-mark als weiteren Parameter ein Textfragment des Paketnamens oder einen passenden regulären Ausdruck. Das nachfolgende Beispiel zeigt Ihnen alle automatisch installierten Pakete, deren Paketnamen auf die Zeichenfolge tex enden. Das Muster ist als regulärer Ausdruck formuliert.

Automatisch installierte Pakete mit apt-mark anzeigen. 

$ apt-mark showauto '.*tex$'
jadetex
luatex
texlive-luatex
$

8.10.2. aptitude benutzen

Auf der Kommandozeile suchen Sie im Paketbestand Ihres Linuxsystems mittels aptitude über das Unterkommando search und dem speziellen Muster ~M (Langform ?automatic). Sie erhalten danach eine Liste, die den Paketstatus, den Paketnamen und eine kurze Paketbeschreibung enthält. Alle Pakete sind mit dem Buchstaben A für automatisch installiert gekennzeichnet.

Automatisch installierte Pakete mit aptitude anzeigen. 

$ aptitude search ~M | more
i A a2ps                            - GNU a2ps - »Alles nach PostScript«-Konvert
i A abiword-common                  - Effiziente, mächtige Textverarbeitung, unt
i A abiword-plugin-grammar          - Grammatik-Prüfung für AbiWord
i A abiword-plugin-mathview         - Gleichungs-Editor-Erweiterung für AbiWord
i A accountsservice                 - Abfragen und Ändern von Informationen von
i A acl                             - Programme für Zugriffskontroll-Listen
...
$

Die gleiche Liste erhalten Sie über die Textoberfläche. Dazu filtern Sie die Paketliste mit der Taste l und tragen im Suchfeld entweder die Kurzform ~M oder die Langvariante ?automatic ein. Das Ergebnis entspricht Abbildung 8.3, „Ansicht der automatisch installierten Pakete in aptitude.

Abbildung 8.3. Ansicht der automatisch installierten Pakete in aptitude

werkzeuge/paketoperationen/aptitude-automatisch-installiert.png

8.11. Obsolete Pakete anzeigen

Softwarepakete und insbesondere deren Verfügbarkeit unterliegen einem stetigen Wandel. Im Alltag kommt es ab und zu vor, dass ein Paket, welches Sie auf ihrem System installiert haben, nicht mehr von einem Paketmirror in aktualisierter Form beziehen können. Die Ursachen dafür können sehr vielfältig sein [Hertzog-Obsolete-Packages]:

  • Das Paket wurde umbenannt und ist inzwischen unter einem anderen Namen verfügbar. Der Maintainer des Pakets hat die Übergangspakete (siehe „transitional packages“ in Abschnitt 2.7.2, „Übergangspakete, Metapakete und Tasks“) für die aktuelle Veröffentlichung unter dem bisherigen Namen belassen. Später wurden die Übergangspakete entfernt.
  • Die letzte verfügbare Version der Software könnte unter einem anderen Namen paketiert worden sein. Entweder waren die Menge der Änderungen so wichtig, dass eine automatische Aktualisierung auf die letzte verfügbare Version nicht bevorzugt wurde, oder einfach weil der Maintainer Ihnen als Benutzer die Möglichkeit geben möchte, mehrere Versionen parallel zu installieren. Ersteres betrifft beispielsweise request-tracker und nagios, letzteres den Linuxkernel, den Python-Interpreter und viele Bibliotheken.
  • Der Entwickler („upstream author“) hat bereits vor längerer Zeit aufgehört, die Software weiter zu warten und niemand anderes hat die Aufgabe von ihm übernommen. Daraufhin hat sich der zuständige Maintainer entschlossen, das Paket aus Debian wieder zu entfernen. Üblicherweise existieren in diesem Fall adäquate Alternativen im Paketbestand.
  • Das Paket war seit längerer Zeit in Debian verwaist, niemand hat sich des Pakets angenommen und zusätzlich gab es nur wenige Nutzer. Das Debian-Team zur Qualitätssicherung könnte um dessen Entfernung gebeten haben.
  • Das Paket ist ein Kernel-Modul und wurde mit dem Werkzeug module-assistant [Debian-Paket-module-assistant] gebaut und installiert[28]
  • Das Paket wurde mit dpkg -i installiert und war nie über eine APT-Paketquelle verfügbar.

Diese Pakete werden als obsolete Pakete bezeichnet und profitieren nicht oder nicht mehr von den regelmäßigen Sicherheitsaktualisierungen. Je länger diese Pakete auf Ihrem System erhalten bleiben, um wahrscheinlicher wird es, dass sich aufgrund der Abhängigkeiten zu anderen Paketen die Aktualisierung ihres gesamten Softwarebestands verzögert und vor allem schwieriger gestaltet. Die Probleme bei der Auflösung von Paketabhängigkeiten nehmen zu.

8.11.1. Recherche auf der Kommandozeile

Mit Hilfe von aptitude, dessen Suchfunktion und dem speziellen Muster ~o (Langform ?obsolete) spüren Sie diese obsoleten Pakete auf. Trotz des Namens des Suchmusters werden diese Pakete in der Text-Modus-Bedienoberfläche von aptitude unter dem Eintrag Veraltete und selbst erstellte Pakete (engl.: „Obsolete and Locally Created Packages“) aufgelistet. Dies wird insbesondere dem letzten o.g. Punkt gerecht.

Die nachfolgende Ausgabe umfasst den Paketstatus, den Paketnamen und die entsprechende Kurzbeschreibung zum Paket. Sie sehen dabei auch, dass hierbei für das Paket pdfstudio keine Kurzbeschreibung vorliegt und dieses damit nicht die üblichen Qualitätsstandards von Debian erfüllt.

Suche nach obsoleten Paketen mittels aptitude

$ aptitude search ~o
i   cupswrapperhl2250dn - Brother HL2250DN CUPS wrapper driver
i   foxitreader         - FoxitReader is a browsing program designed for read
i   gtkdiskfree         - A program to show free/used space on filesystems
i   hl2250dnlpr         - Brother HL-2250DN LPR driver
i   language-env        - simple configuration tool for native language envir
i A libdvdcss2          - Simple foundation for reading DVDs - runtime librar
i A libqt3-mt           - Qt GUI Library (Threaded runtime version), Version
i   odeskteam           - oDesk Team - complete time-logging and verification
i   opera               - Fast and secure web browser and Internet suite
i   pdfedit             - Editor for manipulating PDF documents
i   pdfstudio           -
i   skype               - Wherever you are, wherever they are
i   tpp                 - text presentation program
i   youtube-dl          - downloader of videos from YouTube and other sites
$

8.11.2. Recherche in graphischen Programmen

Bei diesen kann u.E. lediglich Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) die obsoleten Pakete anzeigen. Bei den anderen Programmen fehlt bislang diese Möglichkeit.

Dazu wählen Sie zunächst aus der linken Spalte den Knopf Status aus. Aus der darüberliegenden Liste selektieren Sie danach den Eintrag installiert (lokal oder veraltet). Als Ergebnis erhalten Sie eine Paketliste, welche nur noch die obsoleten Pakete enthält. In Abbildung 8.4, „Ansicht der obsoleten Pakete in Synaptic“ wurden daraus beispielhaft foxitreader und libdvdcss2 markiert.

Abbildung 8.4. Ansicht der obsoleten Pakete in Synaptic

werkzeuge/paketoperationen/synaptic-obsolete-pakete.png

8.11.3. Umgang mit diesen Paketen

Ein obsoletes Paket wird aus Sicht der Paketverwaltung wie alle anderen Pakete behandelt und bleibt auf Ihrem Linuxsystem unverändert erhalten, solange dessen Abhängigkeiten nicht verletzt werden. Problematisch ist jedoch die Aktualisierung, da kein Nachfolgepaket existiert. In diesem Fall bestehen nur zwei Möglichkeiten – das Beibehalten der aktuell installierten Version oder der Wechsel auf eine andere, ähnliche Software. Ersteres ist insofern bedenklich, da es die Aktualisierung anderer Pakete über die definierten Paketabhängigketen verhindert. Dieser Schritt ist genauso abzuwägen wie der Wechsel zu einer anderen Software, welche vielleicht nicht in allen Punkten ihren Erwartungen und Bedürfnissen entspricht.

8.12. Aktualisierbare Pakete anzeigen

Sowohl APT als auch aptitude zeigen Ihnen an, für welche Pakete eine neuere Version bereitsteht. Beide Werkzeuge bieten dafür recht unterschiedliche Parameter und Ausgaben auf dem Terminal.

APT mit dem Kommando apt-get upgrade -u (Langform --show-upgraded) zeigt Ihnen an, welche Pakete aktualisiert werden. Sie erhalten eine Ausgabe, die der nachfolgenden ähnelt. Die mögliche Option -s (Langform --simulate) simuliert die Ausführung der Aktualisierung. Letzteres ist nützlich, um zu sehen, was sich ändern wird, wenn Sie das Kommando ausführen.

Anzeige aller Pakete, für die eine neue Version bereitsteht. 

# apt-get upgrade -u -s
Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
Die folgenden Pakete werden aktualisiert (Upgrade):
  icedove libc-bin libc-dev-bin libc6 libc6-dev libc6-i686 libnss3 libnss3-1d
  linux-headers-3.2.0-4-686-pae linux-headers-3.2.0-4-common
  linux-image-3.2.0-4-686-pae linux-libc-dev virtualbox-guest-source
  virtualbox-ose virtualbox-ose-dkms virtualbox-ose-guest-source
  virtualbox-ose-guest-utils virtualbox-ose-source virtualbox-source
19 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Inst libc-bin [2.13-38+deb7u1] (2.13-38+deb7u4 Debian-Security:7.0/stable [i386]) [libc6:i386 ]
Conf libc-bin (2.13-38+deb7u4 Debian-Security:7.0/stable [i386]) [libc6:i386 ]
...
#

aptitude kennt für diesen Zweck die Suchoption ~U. Diese steht als Kurzform für ?upgradable.

Aktualisierbare Pakete mit aptitude anzeigen. 

$ aptitude search ~U
i A cups-common                - Common UNIX Printing System(tm) - gemeinsa
i   iceweasel                  - Webbrowser auf Basis von Firefox
i A libc-bin                   - Die »Embedded GNU C Library«: Binärdateien
i A libc-dev-bin               - Embedded GNU C Library: Entwicklungsbinärd
i   libc6                      - Die »Embedded GNU C Library«: Laufzeitbibl
i A libc6-dev                  - Die »Embedded GNU C Library«: Entwicklungs
...
$

Um alle verfügbaren Varianten eines Pakets für alle Veröffentlichungen anzuzeigen, nutzen Sie die aptitude-Option versions. Nachfolgende Ausgabe illustriert die Recherche nach den Paketen, in denen die Zeichenkette tzdata im Paketnamen enthalten ist. Hier werden zudem ausschließlich Pakete aus der Veröffentlichung stable bezogen. Die Sortierung erfolgt paketweise, d.h. zunächst erhalten Sie eine Zeile mit dem Paketnamen und darunter zusätzliche Informationen zur verfügbaren Version. Die erste Spalte zeigt dabei den Paketstatus an, danach die Versionsnummer, die Veröffentlichung und als letztes die Priorität (siehe dazu „Veröffentlichungen mischen“ in Kapitel 20, Veröffentlichungen mischen).

Die verfügbaren Versionen zu den Paketen tzdata anzeigen. 

aptitude versions 'tzdata'
Paket tzdata:
p   2015f-0+deb8u1               stable  500
i   2015g-0+deb8u1               stable- 500

Paket tzdata-java:
p A 2015f-0+deb8u1               stable  500
i A 2015g-0+deb8u1               stable- 500
$

Wünschen Sie nur eine kompakte Ausgabe zu einem konkreten Paket ohne Darstellung des Paketnamens, helfen Ihnen die beiden Schalter --show-package-names mit dem Wert never und --group-by mit dem Wert none weiter. Ersteres blendet den Paketnamen aus, während der zweite Schalter die Gruppierung in der Ausgabe deaktiviert. Ausführlicher gehen wir auf die Gruppierung in Abschnitt 10.7, „aptitude-Gruppierung“ ein.

Kompakte Ausgabe ohne Paketname. 

$ aptitude versions 'tzdata-java' --show-package-names=never --group-by=none
p A 2015f-0+deb8u1               stable  500
i A 2015g-0+deb8u1               stable- 500
$

Als gleichwertige Alternative steht Ihnen auch das zusätzliche Werkzeug apt-show-versions aus dem gleichnamigen Debianpaket zur Verfügung [Debian-Paket-apt-show-versions] (siehe auch „Aus welchem Repo kommen die Pakete“ in Abschnitt 8.18, „Aus welchem Repo kommen die Pakete“). Die nachfolgende Ausgabe zeigt den Status des Pakets base-files an. Daraus erkennen Sie, daß für dieses ein neueres Paket bereitsteht.

Kompakte Ausgabe mittels apt-show-versions

$ apt-show-versions base-files
base-files:amd64/jessie 8+deb8u2 upgradeable to 8+deb8u3
$

Bei den graphischen Programmen zur Paketverwaltung kann lediglich Synaptic (siehe Abschnitt 6.4.1, „Synaptic“) die aktualisierbaren Pakete anzeigen. Dazu wählen Sie zunächst den Knopf Benutzerdefinierte Filter aus der linken Spalte aus. Aus der darüberliegenden Liste selektieren Sie danach den Eintrag Aktualisierbar (Upstream). Als Ergebnis erhalten Sie eine Paketliste, welche nur noch die Pakete enthält, die erneuerbar sind (siehe Abbildung 8.5, „Ansicht der aktualisierbaren Pakete in Synaptic“).

Abbildung 8.5. Ansicht der aktualisierbaren Pakete in Synaptic

werkzeuge/paketoperationen/synaptic-aktualisierbare-pakete.png

8.13. Installationsgröße eines Pakets

Die Frage, wieviel Platz ein installiertes Paket auf dem Speichermedium belegt, beantworten Sie am besten mit dem Aufruf dlocate -du Paketname [Debian-Paket-dlocate]. Als Ergebnis erhalten Sie eine Auflistung mit einer Datei pro Zeile, bei der die jeweilige Größe in der ersten Spalte in Kilobyte angegeben ist. Die letzte Zeile summiert die Einzelwerte auf. Nachfolgendes Listing zeigt den Aufruf für das Paket htop.

Ermittlung der Installationsgröße des Pakets htop mit dlocate

$ dlocate -du htop
136 /usr/bin/htop
4   /usr/share/applications/htop.desktop
4   /usr/share/doc/htop/AUTHORS
8   /usr/share/doc/htop/changelog.Debian.gz
8   /usr/share/doc/htop/changelog.gz
4   /usr/share/doc/htop/copyright
4   /usr/share/doc/htop/README
4   /usr/share/man/man1/htop.1.gz
4   /usr/share/menu/htop
4   /usr/share/pixmaps/htop.png
180 insgesamt
$

Möchten Sie den benötigten Speicherplatz bereits vor der Installation wissen, hilft Ihnen aptitude weiter. Mit Hilfe des zusätzlichen Schalters -Z ergänzt aptitude die Größenangabe hinter jedem Paket, hier beispielhaft für aptitude-doc-it und aptitude-doc-ru. Wird ein + vor der Zahl dargestellt, wird dieser Speicherplatz zur Installation des Paketes benötigt, ein - vor der Zahl gibt hingegen den frei werdenden Platz an, wenn das Paket entfernt wird. Die Gesamtsumme der Änderungen erfahren Sie in der Statusnachricht darunter.

Ausgabe der Installationsgröße eines Pakets mit aptitude

# aptitude -Z install aptitude-doc-it aptitude-doc-ru
Die folgenden NEUEN Pakete werden zusätzlich installiert:
   aptitude-doc-it <+1.082 kB>  aptitude-doc-ru <+1.408 kB>
   0 Pakete aktualisiert, 2 zusätzlich installiert, 0 werden entfernt
   und 14 nicht aktualisiert.
   636 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken
   werden 2.490 kB zusätzlich belegt sein.
...
#

8.14. Größtes installiertes Paket finden

8.14.1. dpigs

Mit dem Programm dpigs[29] aus dem Paket debian-goodies [Debian-Paket-debian-goodies] zeigen Sie die Programme bzw. Programmpakete an, die den meisten Speicherplatz auf ihrem Debiansystem belegen. Es wertet dazu die Ausgabe des Kommandos grep-status aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools] aus. Ausführlicher besprechen wir die Werkzeuge im Abschnitt Schlagworte verwenden (Debtags) (siehe Abschnitt 13.6, „Suche anhand der Schlagworte“)].

Ein Aufruf ohne weitere Parameter listet Ihnen die zehn größten Speicherfresser auf ihrem System auf. Dabei enthält die erste Spalte die Größe in Kilobyte und die zweite Spalte den Paketnamen.

Ausgabe von dpigs

$ dpigs
399871 texlive-fonts-extra
377071 texlive-latex-extra-doc
129158 libreoffice-core
91551 pdfstudio
88963 libgl1-mesa-dri
86913 texlive-lang-greek
86446 texlive-pstricks-doc
80298 libwine
80178 openjdk-6-jre-headless
80175 linux-image-3.2.0-4-686-pae
$

dpigs verfügt nur über einige wenige, aber durchaus nützliche Schalter. Um beispielsweise die Anzahl der ausgegebenen Pakete zu begrenzen, nutzen Sie die Option -nZahl (Langform --lines=Zahl), wobei Zahl der Wert für die gewünschte Anzahl ist. Der Schalter -S zeigt die Pakete an, die hingegen die größten Quelldaten haben. Mit dem Schalter -H rechnet dpigs die Größenangaben in menschlich lesbare Werte um. Der Schalter -H steht hierbei als Abkürzung für human readable. Kombinieren Sie die drei letztgenannten Schalter, sieht die Recherche nach den fünf Paketen, die am meisten Quellcode benötigen, folgendermaßen aus:

Ausgabe von dpigs mit Einschränkung auf die fünf Spitzenreiter für den Quelltext. 

$ dpigs -S -n5 -H
   1.0G texlive-extra
 299.7M libreoffice
 274.7M texlive-base
 131.4M chromium-browser
 120.5M calligra
$

8.14.2. aptitude

aptitude kann mit dem o.g. vorgestellten Programm dpigs problemlos mithalten. Es macht nur ein wenig mehr Mühe, die gewünschten Informationen zu erhalten.

Mit dieser Schrittfolge erhalten Sie eine entsprechend sortierte Liste in aufsteigender Reihenfolge in der Text-Modus-Oberfläche:

  1. Mit Ctrl+t oder F10 öffnen Sie die Menüleiste.
  2. Dort wählen Sie den Eintrag AnsichtenNeue einfache Paketansicht aus.
  3. Darin schränken Sie nun die Ansicht auf die installierten Pakete ein. Dazu drücken Sie l (für „limit“) und geben als Filter ~i für „nur installierte Pakete“ ein. Den Vorgang schließen Sie mit der Eingabetaste ab.
  4. Nun fehlt nur noch die passende Sortierung. Diese erhalten Sie durch das Drücken von S und der Eingabe von installsize. Mit der Eingabetaste schließen Sie den Vorgang ab.
  5. Jetzt springen Sie mit der Ende-Taste ans Ende der Liste und sehen die schlimmsten Plattenplatzverbraucher ihres Systems.

Im Terminal finden Sie die zehn Pakete mit dem meisten Plattenplatzverbrauch durch eine Kombination von aptitude und dem Standard-UNIX-Kommando tail. An aptitude übergeben Sie dabei neben dem Unterkommando search mehrere Optionen. Während --sort installsize für die Sortierung nach dem Paketattribut „belegter Plattenplatzverbrauch“ sorgt, filtert '~i' nur alle installierten Pakete aus der Liste heraus. Die Ausgabe enthält den Paketstatus, den Namen des Pakets und die Paketbeschreibung in Kurzform (siehe Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“). Der anschließende Aufruf des Kommandos tail ohne weitere Optionen beschränkt die Darstellung auf die letzten zehn Zeilen der Ausgabe von aptitude und somit die zehn größten Pakete.

Suche nach den größten installierten Paketen mit aptitude (Namensliste). 

$ aptitude search --sort installsize '~i' | tail
i A cube2-data                 - demo game and content for the Cube2 engine
i A nexuiz-data                - Nexuiz game data files
i A torcs-data-tracks          - data files for TORCS game - Tracks set
i A supertuxkart-data          - 3D kart racing game (data)
i A flightgear-data-aircrafts  - FlightGear Flight Simulator -- standard ai
i A flightgear-data-ai         - FlightGear Flight Simulator -- standard AI
i A nexuiz-textures            - Textures for Nexuiz
i A sauerbraten                - 3D first-person shooter game
i A flightgear-data-base       - FlightGear Flight Simulator -- base files
i A 0ad-data                   - Real-time strategy game of ancient warfare
$

Möchten Sie zudem wissen, wieviel Platz die einzelnen Pakete verbrauchen, hilft Ihnen der Schalter -F (Langform --display-format) gefolgt von einem Formatstring weiter. Darüber steuern Sie die Ausgabe des Suchergebnisses von aptitude. Mit einem Formatstring legen Sie die Informationen und deren Reihenfolge fest, in der diese ausgegeben werden sollen (siehe aptitude-Formatstrings in Abschnitt 10.4, „aptitude Format Strings“).

In unserem Fall benötigen wir lediglich den Plattenplatzverbrauch und den Paketnamen. Die beiden Spalteninhalte spezifizieren Sie über die beiden Formatbezeichner %I für die Installationsgröße (engl. „installed size“) und %p für den Paketnamen (engl. „package name“). Nachfolgende Darstellung ist aufsteigend, d.h. das zehntkleinste Paket sehen Sie in der ersten und das größte in der letzten Zeile der Auflistung.

Suche nach den größten Paketen mit aptitude (Größe und Paketname), aufsteigende Sortierung. 

$ aptitude search -F '%I %p' --sort installsize '~i' | tail
272 MB   cube2-data
278 MB   nexuiz-data
302 MB   torcs-data-tracks
306 MB   supertuxkart-data
320 MB   flightgear-data-aircrafts
466 MB   flightgear-data-ai
523 MB   nexuiz-textures
652 MB   sauerbraten
751 MB   flightgear-data-base
1359 MB  0ad-data
$

Für eine umgekehrte, absteigende Darstellung kommt noch das hilfreiche UNIX-Kommando tac ins Spiel. Über eine Pipe leiten Sie die Ausgabe von tail and tac weiter. Dieses dreht die Ausgabe um, sodass die letzte Zeile zuerst ausgegeben wird, danach die vorletzte u.s.w. Die nachfolgende Ausgabe zeigt eine Auflistung der fünf größten Pakete in absteigender Reihenfolge. Da tail ohne Parameter stets 10 Zeilen ausgibt, wurde dessen Aufruf noch um die Angabe -5 ergänzt.

Suche nach den größten Paketen mit aptitude (Größe und Paketname), absteigende Sortierung. 

$ aptitude search -F '%I %p' --sort installsize '~i' | tail -5 | tac
1359 MB  0ad-data
751 MB   flightgear-data-base
652 MB   sauerbraten
523 MB   nexuiz-textures
466 MB   flightgear-data-ai
$

8.15. Warum ist ein Paket installiert

Mit der Zeit sammeln sich auf Ihrem System recht viele Pakete an. Bedingt durch die vorab definierten Paketabhängigkeiten schaufelt die Paketverwaltung etliches an Daten auf die Platte und füllt den verfügbaren Speicherplatz stetig, aber gnadenlos.

Möchten Sie klären, warum ein Paket installiert wurde, gibt Ihnen aptitude dazu bereitwillig Auskunft. Es versteht dazu das Unterkommando why, mit dem es Ihnen die Gründe auflistet, die zur Installation des besagten Pakets geführt haben. Grundlage dafür sind einerseits die Paketflags (siehe dazu Abschnitt 2.15, „Lokale Paketmarkierungen“) und andererseits die Einträge in der Paketbeschreibung. aptitude wertet daraus die fünf Felder Recommends, Conflicts, Depends, Replaces und Provides aus (siehe Abschnitt 4.1, „Konzepte und Ideen dahinter“). Über diese vorgenannten Felder legt der Paketmaintainer die Beziehungen zu anderen Paketen fest.

Nachfolgendes Beispiel zeigt den Aufruf zum Paket xpdf. Ersichtlich wird daraus, dass das Paket texpower wiederum xpdf oder ein Paket aus der Gruppe pdf-viewer empfiehlt. Die Alternative wird hier durch einen senkrechten Strich – das Pipe-Symbol – dargestellt. Das Paket xpdf ist bereits installiert, wird jedoch wiederum auch vom Paket texlive-latex-extra genutzt. Das Paket texpower wurde automatisch installiert, was Sie anhand des Buchstabens A in der dritten Spalte der dritten Zeile in nachfolgender Ausgabe sehen können.

Ausgabe von aptitude zur Klärung der Installation (Variante 1). 

$ aptitude why xpdf
i   texlive-latex-extra Empfiehlt texpower (>= 0.2-2)
i A texpower            Empfiehlt xpdf | pdf-viewer
$

Für eine wesentlich ausführlichere Ausgabe nutzen Sie den Schalter -v. Dieser besitzt die übliche Langform --verbose und ergänzt die Ausgabe um alle Pakete, die zur Installation führen können. Hintergrund dafür ist, dass aptitude aus den Paketinformationen sämtliche Abhängigkeits- und Installationspfade errechnet und Ihnen diese auflistet.

Ausführliche Darstellung der Installationspfade (Ausschnitt). 

$ aptitude --verbose why xpdf
i   mc Schlägt vor xpdf | pdf-viewer

i   nautilus Schlägt vor evince | pdf-viewer
i   xpdf     Liefert     pdf-viewer

i   dot2tex          Empfiehlt    pgf (>= 2.00) | texlive-pstricks
i A texlive-pstricks Hängt ab von texlive-base (>= 2012.20120516)
i A texlive-base     Schlägt vor  xpdf-reader | pdf-viewer
i   xpdf             Liefert      pdf-viewer

...
$

In Kombination mit dem Schalter --show-summary fassen Sie diese Informationen zusammen und erhalten eine kompaktere Darstellung. Der Schalter erlaubt die fünf Werte no-summary, first-package, first-package-and-type, all-packages und all-packages-with-dep-versions. Geben Sie den Schalter beim Aufruf nicht an, wird show-summary auf den Wert no-summary gesetzt. Spezifizieren Sie keinen Wert für show-summary, wird hingegen first-package angenommen. Damit erhalten Sie bei einem Aufruf die folgende Ausgabe – hier beispielhaft für das Paket foomatic-db:

Zusammenfassung für das Paket foomatic-db

$ aptitude -v --show-summary why foomatic-db
Pakete, die foomatic-db erfordern:
  bluetooth
  cups-pdf
  printer-driver-gutenprint
$

Der Wert first-package-and-type liefert Ihnen zudem eine Begründung für die Abhängigkeit:

Zusammenfassung für das Paket foomatic-db (mit Begründung). 

$ aptitude -v --show-summary=first-package-and-type why foomatic-db
Pakete, die foomatic-db erfordern:
  [Hängt ab von] bluetooth
  [Hängt ab von] cups-pdf
  [Hängt ab von] printer-driver-gutenprint
$

Eine Übersicht zu allen Paketpfaden, die zum genannten Paket führen, erhalten Sie mit Hilfe des Wertes all-packages. Dabei stehen die Buchstaben hinter den Paketnamen für Recommends (R), Conflicts (C), Depends (D), Replaces (?) und Provides (P).

Zusammenfassung für das Paket foomatic-db (ausführlicher). 

$ aptitude -v --show-summary=all-packages why foomatic-db
Pakete, die foomatic-db erfordern:
  bluetooth E: bluez-cups H: cups E: foomatic-filters E: foomatic-db-engine E: foomatic-db
  cups-pdf H: cups E: foomatic-filters E: foomatic-db-engine E: foomatic-db
  printer-driver-gutenprint H: cups E: foomatic-filters E: foomatic-db-engine E: foomatic-db
$

Benötigen Sie zudem noch die Versionsnummer, von der dieses Paket abhängt, setzen Sie den Wert von --show-summary auf den Wert all-packages-with-dep-versions:

Zusammenfassung für das Paket foomatic-db (ausführlicher mit Versionsangabe). 

$ aptitude -v --show-summary=all-packages-with-dep-versions why foomatic-db
Pakete, die foomatic-db erfordern:
  bluetooth E: bluez-cups H: cups E: foomatic-filters (>= 4.0) E: foomatic-db-engine (>= 4.0) E: foomatic-db
  cups-pdf H: cups E: foomatic-filters (>= 4.0) E: foomatic-db-engine (>= 4.0) E: foomatic-db
  printer-driver-gutenprint H: cups (>= 1.3.0) E: foomatic-filters (>= 4.0) E: foomatic-db-engine (>= 4.0) E: foomatic-db
$

Bestehen hingegen keine Gründe für eine Installation oder aptitude kann diese nicht zweifelsfrei ermitteln, liefert es die nachfolgende Ausgabe – hier am Beispiel des Pakets libruby-extras:

Ausgabe von aptitude zur Klärung der Installation (Variante 2). 

$ aptitude why libruby-extras
Kann keinen Grund für die Installation von libruby-extras finden.
$

Das Gegenstück zum Unterkommando why ist why-not. aptitude listet damit den Grund auf, warum das Paket bislang nicht installiert oder bereits wieder entfernt wurde. Nachfolgendes Beispiel zeigt das anhand des Audioprogramms mplayer. Dieses Paket wird von rtmpdump vorgeschlagen, welches automatisch installiert wurde und vom Paket youtube-dl empfohlen wird. Außerdem kollidieren die beiden Pakete mplayer und mplayer2 miteinander, sodass im Bedarfsfall nur eines von beiden auf ihrem System installiert sein darf.

Ausgabe von aptitude zur Klärung der Installation (Variante 3). 

$ aptitude why-not mplayer
i   youtube-dl Empfiehlt      rtmpdump
i A rtmpdump   Schlägt vor    mplayer
p   mplayer2   Liefert        mplayer
p   mplayer2   Kollidiert mit mplayer
$

Kann aptitude keinen Grund für die Entfernung finden, meldet es sich mit einer kurzen Meldung dazu zurück – hier am Beispiel des KDE Desktop Managers aus dem Paket kdm:

Ausgabe von aptitude zur Klärung der Installation (Variante 4). 

$ aptitude why-not kdm
Kann keinen Grund für die Entfernung von kdm finden.
$

8.16. Liste der zuletzt installierten Pakete anzeigen

Als Verantwortlicher für Ihr Linuxsystem möchten Sie ab und an wissen, was zuletzt auf dem System passiert ist. Dazu zählt insbesondere das Auswerten der Logdateien und beinhaltet die Änderungen der Paketliste – was wurde installiert, gelöscht bzw. aktualisiert etc. Sowohl dpkg, als auch apt lassen Sie die Aktionen nachverfolgen.

8.16.1. Statusdaten von dpkg

dpkg erfasst alle Änderungen im Paketbestand in der Logdatei /var/log/dpkg.log. Ältere dpkg-Logdateien werden vom Programm logrotate nach dem Rotationsprinzip archiviert und irgendwann auch komprimiert. Die zweit- und drittjüngsten Logdateien finden Sie beispielsweise in den beiden Dateien /var/log/dpkg.log.1 und /var/log/dpkg.log.2.gz wieder. Nachfolgender Auszug zeigt die Suche in der aktuellen Logdatei von dpkg mittels grep anhand des Schlüsselwortes „install“.

Recherche in den Logdateien von dpkg mittels grep

$ grep " install " /var/log/dpkg.log
2014-08-06 15:12:19 install texlive-games:all <keine> 2012.20120611-2
2014-08-06 15:59:34 install qxw:i386 <keine> 20110923-1
2014-08-08 10:46:42 install games-thumbnails:all <keine> 20120227
2014-08-08 10:46:43 install goplay:i386 <keine> 0.5-1.1
2014-08-08 19:42:14 install ocrad:i386 <keine> 0.22~rc1-2
$

Reicht Ihnen dieses Ergebnis noch nicht aus, suchen Sie zusätzlich noch in allen wegrotierten Logdateien. Zur Anwendung kommt hier das Kommando zcat aus dem Paket gzip, welches ein essentielles Paket darstellt. Dies ist auf einer Standard-Installation der Fall. Es gibt jedoch auch noch eine alternative Implementation im Paket zutils [Debian-Paket-zutils].

Untenstehende Ausgabe wurde zusätzlich mittels sort aufsteigend nach Datum sortiert, d.h. die untersten Einträge enthalten die jüngsten Änderungen im Paketbestand. Mit dem UNIX-Kommando tail beschränken Sie die Ausgabe des Rechercheergebnisses auf lediglich zehn Einträge.

Recherche in den Logdateien von dpkg mittels zcat

$ zcat -f /var/log/dpkg.log* | grep " install " | sort | tail
2014-07-23 20:18:35 install libparse-debianchangelog-perl:all <keine> 1.2.0-1
2014-07-23 20:18:36 install libxml-simple-perl:all <keine> 2.20-1
2014-07-23 20:18:36 install patchutils:i386 <keine> 0.3.2-1.1
2014-07-23 20:18:37 install lintian:all <keine> 2.5.10.4
2014-07-26 16:03:02 install libapt-pkg-doc:all <keine> 0.9.7.9+deb7u2
2014-08-06 15:12:19 install texlive-games:all <keine> 2012.20120611-2
2014-08-06 15:59:34 install qxw:i386 <keine> 20110923-1
2014-08-08 10:46:42 install games-thumbnails:all <keine> 20120227
2014-08-08 10:46:43 install goplay:i386 <keine> 0.5-1.1
2014-08-08 19:42:14 install ocrad:i386 <keine> 0.22~rc1-2
$

Die hier verwendete Option -f benötigen Sie, damit zcat auch nicht-komprimierte Dateien – in diesem Fall /var/log/dpkg.log – ausgibt.[30]

Alternativ können Sie auch zgrep verwenden, das spart ein klein wenig Tipparbeit. Damit die Sortierung gelingt, muss dort allerdings die Ausgabe von vorangestellten Dateinamen mit der Option -h unterdrückt werden:

Recherche in den Logdateien von dpkg mittels zgrep

$ zgrep -h " install " /var/log/dpkg.log* | sort | tail -7
2014-07-23 20:18:37 install lintian:all <keine> 2.5.10.4
2014-07-26 16:03:02 install libapt-pkg-doc:all <keine> 0.9.7.9+deb7u2
2014-08-06 15:12:19 install texlive-games:all <keine> 2012.20120611-2
2014-08-06 15:59:34 install qxw:i386 <keine> 20110923-1
2014-08-08 10:46:42 install games-thumbnails:all <keine> 20120227
2014-08-08 10:46:43 install goplay:i386 <keine> 0.5-1.1
2014-08-08 19:42:14 install ocrad:i386 <keine> 0.22~rc1-2
$

8.16.2. Statusdaten von apt

apt erfasst alle Änderungen im Paketbestand in der Logdatei /var/log/apt/history.log. Neben dem vollständigen Aufruf sind alle Pakete berücksichtigt, die in einer anderen Version eingespielt wurden. Nachfolgender Auszug zeigt die Installation des Paketes apt-rdepends am 20. Juli 2016:

Installation des Paketes apt-rdepends

Start-Date: 2016-07-20  16:00:48
Commandline: apt-get install apt-rdepends
Install: apt-rdepends:amd64 (1.3.0-3)
End-Date: 2016-07-20  16:00:49

Nehmen Sie eine Aktualisierung der Software vor, resultiert das bspw. in folgendem Eintrag:

Aktualisierung des Paketes wireshark samt dessen Abhängigkeiten. 

Start-Date: 2016-07-08  15:41:42
Upgrade: wireshark-common:amd64 (1.12.1+g01b65bf-4+deb8u6, 1.12.1+g01b65bf-4+deb8u7), wireshark-qt:amd64 (1.12.1+g01b65bf-4+deb8u6, 1.12.1+g01b65bf-4+deb8u7), wireshark:amd64 (1.12.1+g01b65bf-4+deb8u6, 1.12.1+g01b65bf-4+deb8u7)
End-Date: 2016-07-08  15:41:48

Analog zu dpkg werden ältere Logdateien vom Programm logrotate nach dem Rotationsprinzip archiviert und von Zeit zu Zeit komprimiert. Die zweit- und drittjüngsten Logdateien finden Sie beispielsweise in den beiden Dateien /var/log/apt/history.log.1.gz und /var/log/apt/history.log.2.gz wieder.

8.17. Paketabhängigkeiten anzeigen

Wie in der Einführung zum Buch bereits genannt, besteht Debian aus einer riesigen Menge einzelner Pakete. Dabei werden größere, komplexe Funktionalitäten in kleine, separate Bausteine zerlegt. Diese Bausteine sind als einzelne deb-Pakete verfügbar, die häufig einander bedingen. In der Paketbeschreibung jedes deb-Pakets ist der Bezug zu den anderen Paketen hinterlegt — die Paketabhängigkeiten. Wie diese konkret formuliert werden, lesen Sie unter „Debian-Paketformat im Detail“ in Kapitel 4, Debian-Paketformat im Detail nach.

Vor der Veränderung des Paketbestands – d.h. dem Hinzufügen, Entfernen und Aktualisieren eines oder mehrerer Pakete – prüfen APT und aptitude, ob diese Paketabhängigkeiten nach den Änderungen des Bestand auf ihrem System weiterhin erfüllt sind. Die Abhängigkeiten müssen erfüllt sein, damit Ihr Linuxsystem weiterhin zuverlässig funktioniert und dieses für Sie benutzbar bleibt.

Sind die Abhängigkeiten jedoch nicht erfüllt, weigern sich APT und aptitude zunächst, Software einzuspielen. Sie zeigen Ihnen an, welche Pakete und Einzelschritte erforderlich sind, die zur Wiedererlangung eines sauberen Paketbestands durchzuführen sind. Nur mit etwas Nachdruck können Sie den Zustand auf eigene Verantwortung hin übergehen — mehr dazu erfahren Sie in „Paketoperationen erzwingen“ in Abschnitt 8.43, „Paketoperationen erzwingen“.

8.17.1. Die Abhängigkeiten eines Pakets auflisten

Hier sehen Sie, von welchen weiteren Paketen ein Paket abhängt. Zu dieser Information gelangen Sie mit mehreren Werkzeugen. Dazu zählen dpkg-deb, apt-cache mit den beiden Unterkommandos show und depends, aptitude mit speziellen Suchoptionen, apt-rdepends sowie grep-aptavail und grep-status aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools]. Als weitere Information benötigen die genannten Programme noch den Namen des Pakets, zu dem es die Paketabhängigkeiten ausgeben sollen. Die nachfolgenden Ausgaben illustrieren die Wirkung anhand des Pakets xpdf.

Unterschied zwischen apt-cache und aptitude bei der Suche nach Abhängigkeiten

Hier ist die Bedeutung der Unterkommandos bzw. Schalter zwischen den beiden Werkzeugen genau entgegengesetzt. Während apt-cache depends alle Abhängigkeiten eines gegebenen Pakets heraussucht, „denkt“ aptitude search ?depends(…) andersherum und durchsucht die Abhängigkeiten aller Pakete nach einem Muster, sucht also nach Abhängigkeiten auf ein Paket bzw. einer Zeichenkette oder einem regulären Ausdruck.

Daher entspricht apt-cache depends dem Aufruf aptitude search ~R bzw. aptitude search ?reverse-depends(…) sowie apt-cache rdepends dem Aufruf aptitude search ~D bzw. aptitude search ?depends(…).

Ausgabe der Paketabhängigkeiten mit dpkg-deb

Das Kommando dpkg-deb ist Bestandteil des essentiellen Pakets dpkg [Debian-Paket-dpkg]. Über den Schalter -f (Langform --field) und der Angabe des Feldnamens liest es die Paketinformationen und gibt anschließend den Inhalt des spezifizierten Feldes aus. Das ist identisch zum Aufruf von dpkg -f (Langform dpkg --field).

Beachten Sie bitte beim Aufruf die etwas unintuitiven Abfolge der Parameter — erst den Schalter, danach den Dateinamen der deb-Datei und am Ende der Feldname. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, sondern nur als Datei in einem Verzeichnis liegen und erreichbar sein.

Ausgabe der Abhängigkeiten mittels dpkg-deb

$ dpkg-deb -f xpdf_3.03-17+b1_amd64.deb Depends
libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler46 (>= 0.26.2), libstdc++6 (>= 4.1.1), libx11-6, libxm4 (>= 2.3.4), libxt6
$

Ausgabe der Paketabhängigkeiten mit apt-cache

Variante 1 verfolgt einen typischen UNIX-Ansatz — es kombiniert die beiden Werkzeuge apt-cache und grep miteinander. Dazu filtert es die Ausgabe der vollständigen Paketinformationen, wie es apt-cache mit dem Unterkommando show liefert. Über eine Pipe und mittels grep filtert es danach die Zeile mit den Abhängigkeiten heraus, die mit dem Schlüsselwort Depends beginnt. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, sondern nur in der Paketdatenbank als Paket gelistet sein.

Suche mittels grep in der Ausgabe von apt-cache

$ apt-cache show xpdf | grep Depends
Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler46 (>= 0.26.2), libstdc++6 (>= 4.1.1), libx11-6, libxm4 (>= 2.3.4), libxt6
$

Variante 2 verwendet das spezifische Unterkommando depends. apt-cache gibt jedes benötigte Debianpaket in einer einzelnen Zeile in alphabetisch aufsteigender Reihenfolge und ohne die Versionsnummer aus. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Detaillierte Ausgabe der Paketabhängigkeiten. 

$ apt-cache depends xpdf
xpdf
  Hängt ab von: libc6
  Hängt ab von: libgcc1
  Hängt ab von: libpoppler46
  Hängt ab von: libstdc++6
  Hängt ab von: libx11-6
  Hängt ab von: libxm4
  Hängt ab von: libxt6
  Empfiehlt: poppler-utils
    poppler-utils:i386
  Empfiehlt: poppler-data
  Empfiehlt: gsfonts-x11
  Empfiehlt: cups-bsd
    cups-bsd:i386
  Kollidiert mit: <xpdf-common>
  Kollidiert mit: <xpdf-common:i386>
  Kollidiert mit: <xpdf-reader>
  Kollidiert mit: <xpdf-reader:i386>
  Ersetzt: <xpdf-common>
  Ersetzt: <xpdf-common:i386>
  Ersetzt: <xpdf-reader>
  Ersetzt: <xpdf-reader:i386>
  Kollidiert mit: xpdf:i386
$

Ohne weitere Optionen enthält die Ausgabe alle Abhängigkeiten, Empfehlungen und Konflikte zu dem Paket. Mit den folgenden Optionen spezifizieren Sie die Ausgabe noch genauer.

-i (Langform --important)
Einschränkung auf die wichtigen Abhängigkeiten, d.h. nur unerfüllte (unmet) und direkte Abhängigkeiten (depends und pre-depends). Es entspricht damit exakt den Angaben im Feld Depends der Paketinformationen.

Beschränkung auf die wichtigen Abhängigkeiten mittels -i

$ apt-cache depends -i xpdf
xpdf
  Hängt ab von: libc6
  Hängt ab von: libgcc1
  Hängt ab von: libpoppler46
  Hängt ab von: libstdc++6
  Hängt ab von: libx11-6
  Hängt ab von: libxm4
  Hängt ab von: libxt6
$

--no-pre-depends
blendet die Pakete aus, die vorher installiert sein müssen
--no-depends
direkte Abhängigkeiten ausblenden
--no-recommends
die Empfehlungen für weitere Pakete ausblenden
--no-suggests
Angaben für Vorschläge werden unterdrückt
--no-conflicts
blendet die Pakete aus, die mit dem Paket in Konflikt stehen, d.h. nicht gleichzeitig installiert sein dürfen
--no-breaks
blendet die Pakete aus, die das Paket funktionsunfähig machen
--no-replaces
Pakete, die das aktuelle Paket ersetzen, werden nicht angezeigt
--no-enhances
Pakete, die das aktuelle Paket erweitern, werden nicht angezeigt
--installed
begrenzt die Ausgabe nur auf die installierten Pakete
--recurse
führt die Unterkommandos depends und rdepends rekursiv aus, so dass alle erwähnten Pakete einmal ausgegeben werden. Diese Liste kann sehr lang sein.

Die nachfolgende Ausgabe grenzt die Auflistung auf die Pakete ein, die lediglich als Vorschlag oder Empfehlung hinterlegt sind. Im Aufruf nutzen Sie dafür die Option --no-depends.

Ausgabe der vorgeschlagenen und empfohlenen Pakete zu xpdf

$ apt-cache depends xpdf --no-depends
xpdf
  Empfiehlt: poppler-utils
    poppler-utils:i386
  Empfiehlt: poppler-data
  Empfiehlt: gsfonts-x11
  Empfiehlt: cups-bsd
    cups-bsd:i386
  Kollidiert mit: <xpdf-common>
  Kollidiert mit: <xpdf-common:i386>
  Kollidiert mit: <xpdf-reader>
  Kollidiert mit: <xpdf-reader:i386>
  Ersetzt: <xpdf-common>
  Ersetzt: <xpdf-common:i386>
  Ersetzt: <xpdf-reader>
  Ersetzt: <xpdf-reader:i386>
  Kollidiert mit: xpdf:i386
$

Recherche mit apt-rdepends

Deutlicher wird apt-rdepends aus dem gleichnamigen Paket. Es löst die Abhängigkeiten noch weitaus stärker auf. Nachfolgende Darstellung zeigt daher nur einen Ausschnitt. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Ausgabe der Paketabhängigkeiten mit apt-rdepends (Ausschnitt). 

$ apt-rdepends xpdf | more
xpdf
  Depends: libc6 (>= 2.4)
  Depends: libgcc1 (>= 1:4.1.1)
  Depends: libpoppler46 (>= 0.26.2)
  Depends: libstdc++6 (>= 4.1.1)
  Depends: libx11-6
  Depends: libxm4 (>= 2.3.4)
  Depends: libxt6
libc6
  Depends: libgcc1
libgcc1
  Depends: gcc-4.9-base (= 4.9.2-10)
...
$

Das Ergebnis von apt-rdepends wird vielleicht leichter verständlich, wenn Sie die Paketabhängigkeiten graphisch darstellen. Bei der Veranschaulichung hilft Ihnen das Programm dotty aus dem Paket graphviz [Graphviz]. Für das Paket tcpdump sieht der Aufruf wie folgt aus.

Erzeugung der Abhängigkeiten als dot-Datei. 

$ apt-rdepends -d tcpdump | dot > tcpdump.dot
Reading package lists... Done
Building dependency tree
Reading state information... Done
$

Das Ergebnis der von apt-rdepends zu dot weitergeleiteten und in der Datei tcpdump.dot abgespeicherten Relationsmenge zeigen Sie mit dem Programm dotty an (siehe Abbildung 8.6, „Darstellung der umgekehrten Paketabhängigkeiten mit dotty).

Aufruf von dotty

$ dotty tcpdump.dot
$

Abbildung 8.6. Darstellung der umgekehrten Paketabhängigkeiten mit dotty

werkzeuge/paketoperationen/tcpdump-apt-rdepends.png

Ausgabe der Paketabhängigkeiten mit aptitude

aptitude versteht eine Reihe von speziellen Suchmustern. Eines davon ist ~Rmuster als Abkürzung für die Langform ?reverse-depends(Paketname), welches Sie mit dem Unterkommando search kombinieren. muster bezeichnet hier den Namen oder das Textfragment eines Pakets. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Mit dem nachfolgenden Aufruf erhalten Sie alle Pakete, die xpdf benötigt. Es entspricht dem Aufruf apt-cache depends -i xpdf. Die Ausgabe beinhaltet nur die notwendigen Abhängigkeiten ohne weitere Empfehlungen. Analog zur Ausgabe von dpkg umfaßt die verwendete Darstellungsform den Installationsstatus, den Namen und die Kurzbeschreibung des Pakets (siehe dazu „Liste der installierten Pakete anzeigen und deuten“ in Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“).

Anzeige der Paketabhängigkeiten mit aptitude

$ aptitude search ~Rxpdf
i   libc6                           - GNU C-Bibliothek: Dynamische Bibliotheken
i   libgcc1                         - GCC Support-Bibliothek
i A libpoppler46                    - Bibliothek zur PDF-Darstellung
i   libstdc++6                      - GNU-Implementierung der Standard-C++-Bibli
i A libx11-6                        - Clientseitige X11-Bibliothek
i A libxm4                          - Motif - X/Motif shared library
i A libxt6                          - X11-Bibliothek mit wesentlichen Werkzeugen
$

Ausgabe der Paketabhängigkeiten mit grep-status

Die beiden Werkzeuge grep-aptavail und grep-status aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools] filtern die gewünschten Felder aus der Paketbeschreibung heraus. Während grep-status eher die Sichtweise von dpkg benutzt und sich nur auf die (jemals) installierten Pakete in der aktuellen Architektur bezieht, entspricht grep-aptavail eher aptitude und durchsucht alle lokalen Paketlisten. Benutzen Sie bspw. mehrere Archtekturen (Multiarch), erhalten Sie einen Suchtreffer pro Paketliste der Architektur.

Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Im nachfolgenden Aufruf kommen -F Package zum Abgleich des Musters mit dem Paketnamen und -s Depends zur Ausgabe des Feldes für die Paketabhängigkeiten zum Einsatz.

Ausgabe der Paketabhängigkeiten mit grep-status

$ grep-status -F Package -s Depends xpdf
Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler46 (>= 0.26.2), libstdc++6 (>= 4.1.1), libx11-6, libxm4 (>= 2.3.4), libxt6
$

Eine kürzere Schreibweise erlaubt der Schalter -P, welcher dem Schalter -F Package entspricht. Nachfolgende Ausgabe zeigt grep-aptavail mit den Feldern für die Paketabhängigkeit (Depends), den Paketnamen (Package) und die Architektur (Architecture).

Ausgabe der Paketabhängigkeiten mit grep-aptavail

$ grep-aptavail -P -s Package,Depends,Architecture xpdf
Package: xpdf
Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler46 (>= 0.26.2), libstdc++6 (>= 4.1.1), libx11-6, libxm4 (>= 2.3.4), libxt6
Architecture: amd64

Package: xpdf
Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libpoppler46 (>= 0.26.2), libstdc++6 (>= 4.1.1), libx11-6, libxm4 (>= 2.3.4), libxt6
Architecture: i386

$

8.17.2. Anzeige der umgekehrten Paketabhängigkeiten

Diese Aktivität übersetzen Sie mit der Frage „Welche anderen Pakete benötigen Paket x?“, auch genannt Rückwärtsabhängigkeit. Zur Beantwortung der Frage helfen Ihnen einerseits wiederum apt-cache mit dem Unterkommando depends, andererseits das Kommando apt-rdepends aus dem gleichnamigen Paket apt-rdepends [Debian-Paket-apt-rdepends] und auch aptitude selbst weiter.

Unterschied zwischen apt-cache und aptitude bei der Suche nach Abhängigkeiten

Hier ist die Bedeutung der Unterkommandos bzw. Schalter zwischen den beiden Werkzeugen genau entgegengesetzt. Während apt-cache depends alle Abhängigkeiten eines gegebenen Pakets heraussucht, „denkt“ aptitude search ?depends(…) andersherum und durchsucht die Abhängigkeiten aller Pakete nach einem Muster, sucht also nach Abhängigkeiten auf ein Paket bzw. einer Zeichenkette oder einem regulären Ausdruck.

Daher entspricht apt-cache depends dem Aufruf aptitude search ~R bzw. aptitude search ?reverse-depends(…) sowie apt-cache rdepends dem Aufruf aptitude search ~D bzw. aptitude search ?depends(…).

Recherche mit apt-cache

Über das Unterkommando rdepends zeigt apt-cache alle Pakete an. Pakete, die von weiteren Paketen abhängen, sind in der Ausgabe von apt-cache mit einem senkrechten Strich („Pipe“) gekennzeichnet. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Ausgabe der umgekehrten Paketabhängigkeiten mit apt-cache für das Paket xpdf

$ apt-cache rdepends xpdf
xpdf
Reverse Depends:
 |xmds-doc
  xfe
  wiipdf
 |vim-latexsuite
  python-scapy
 |ruby-tioga
 |python-tables-doc
 |page-crunch
 |octave-doc
 |muttprint-manual
  mozplugger
  mlpost
  libmlpost-ocaml-dev
 |mc
 |libjgoodies-forms-java-doc
 |libinventor1
 |gprolog-doc
 |geomview
  libfontconfig1
  eficas
 |auctex
$

Recherche mit apt-rdepends

apt-rdepends löst die Abhängigkeiten der Pakete zueinander noch weitaus stärker auf. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank gelistet sein.

Ausgabe der umgekehrten Paketabhängigkeiten mit apt-rdepends

$ apt-rdepends -r xpdf
Reading package lists... Done
Building dependency tree
Reading state information... Done
xpdf
  Reverse Depends: eficas (6.4.0-1-1.1)
  Reverse Depends: muttprint-manual (0.73-5.1)
  Reverse Depends: wiipdf (1.4-2)
eficas
muttprint-manual
wiipdf
$

Recherche mit aptitude

Mit einer Reihe von speziellen Suchmustern zum Unterkommando search unterstützt Sie aptitude bei der Recherche in der Paketdatenbank. Eines davon ist ~Dmuster und dessen Langform ?depends(muster). Sie suchen in den Abhängigkeiten\footnote{Engl. Dependencies; ohne weitere Angaben wird in den Abhängigkeiten des Feldes Depends gesucht.} aller Pakete nach dem regulrären Ausdruck muster. Dabei findet es nicht nur vollständige Paketnamen sondern auch Bestandteile von Paketnamen. Für diese Information muss das entsprechende Paket nicht auf ihrem System installiert sein, aber in der Paketdatenbank vorhanden sein.

Um beispielsweise alle Pakete zu erhalten, die eine Abhängigkeit auf ein Paket mit der Zeichenkette xpdf im Paketnamen haben, nutzen Sie das Kommando aptitude search ~Dxpdf. Das Ergebnis ist eine mehrspaltige Auflistung der Pakete mit deren Installationsstatus, Paketnamen und Kurzbeschreibung (siehe dazu „Liste der installierten Pakete anzeigen und deuten“ in Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“).

Auflistung aller Pakete, deren Abhängigkeiten die Zeichenkette xpdf beinhalten, mit aptitude

$ aptitude search '~Dxpdf'
p   eficas               - Graphical editor for Code Aster command files
p   impressive           - Werkzeug zur Präsentation von PDF-Dateien mit
p   muttprint-manual     - Handbuch für muttprint
p   page-crunch          - PDF and PS manipulation for printing needs
p   wiipdf               - Präsentiert eine PDF-Datei mittels Wiimote
$

Diese Liste beinhaltet auch das Paket impressive, welches eine Abhängigkeit auf poppler-utils | mupdf-tools | xpdf-utils hat. Will man nur Abhängigkeiten auf das Paket xpdf, so muß man Anfangs- und End-Anker verwenden:

Auflistung aller Pakete, die eine harte Abhängigkeit auf das Paket xpdf beinhalten, mit aptitude

$ aptitude search '~D^xpdf$'
p   eficas               - Graphical editor for Code Aster command files
p   muttprint-manual     - Handbuch für muttprint
p   wiipdf               - Präsentiert eine PDF-Datei mittels Wiimote
$

8.17.3. Prüfen, ob die Abhängigkeiten des gesamten Systems erfüllt sind

APT liefert über das Werkzeug apt-get und dessen Unterkommando check ein kleines Diagnosewerkzeug mit. Es aktualisiert den Paketzwischenspeicher (siehe Kapitel 7, Paketcache) und prüft, ob auf Ihrem Linuxsystem beschädigte Abhängigkeiten vorliegen. Das beinhaltet alle installierten Pakete sowie die bereits entpackten, aber noch nicht konfigurierten Pakete [Debian-Anwenderhandbuch-apt-optionen].

Prüfung auf beschädigte Abhängigkeiten mit apt-get check

# apt-get check
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
#

8.17.4. Zusammenfassung aller unerfüllten Abhängigkeiten im Paketcache

Das Werkzeug apt-cache zeigt Ihnen eine Zusammenfassung aller unerfüllten Abhängigkeiten im Paketzwischenspeicher (siehe Kapitel 7, Paketcache). Dazu bietet es das Unterkommando unmet, welches Sie auch noch um einen Paketnamen bzw. eine Liste davon ergänzen können. Die dargestellte Liste zeigt die Funktionalität zum Paket wireshark und beinhaltet auch die nicht installierten Vorschläge der Pakete.

Auflistung aller unerfüllten Abhängigkeiten für Pakete, die mit wireshark beginnen. 

$ apt-cache unmet wireshark*
Paket wireshark Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: ethereal (< 1.0.0-3)
Paket libwireshark2 Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: wireshark-common (< 1.4.0~rc2-1)
Paket libwireshark-data Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: wireshark-common (< 1.4.0~rc2-1)
Paket wireshark-common Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: ethereal-common (< 1.0.0-3)
Paket libwireshark-dev Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: wireshark-dev (< 1.4.0~rc2-1)
Paket wireshark-dev Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: ethereal-dev (< 1.0.0-3)
frank@efho-mobil:~$ apt-cache unmet wireshark
Paket wireshark Version 1.8.2-5wheezy10 hat eine unerfüllte Abhängigkeit:
 Ersetzt: ethereal (< 1.0.0-3)
$

8.18. Aus welchem Repo kommen die Pakete

Nutzen Sie Pakete aus verschiedenen Paketquellen in /etc/apt/sources.list (siehe Abschnitt 3.3, „/etc/apt/sources.list verstehen“), ist es hilfreich zu wissen, woher APT ein Paket bei der Installation oder Aktualisierung entnehmen würde. Bei der Beantwortung dieser Frage helfen Ihnen die Programme apt-cache, apt-show-versions, apt und aptitude weiter – aber jedes auf seine Art.

8.18.1. Paketquelle untersuchen mit apt-cache policy

Rufen Sie apt-cache lediglich mit dem Schalter policy und ohne die weitere Angabe eines Pakets auf, untersucht das Programm jede einzelne Paketquelle, die Sie in /etc/apt/sources.list eingetragen haben. Das Ergebnis der Analyse ist zweispaltig. In der linken Spalte erscheint ein Zahlenwert zur Priorität des jeweiligen Eintrags, wie er von apt-pinning genutzt wird (siehe dazu Kapitel 22, Paketformate mischen). In der rechten Spalte sehen Sie die Paketquelle anhand der heruntergeladenen, lokalen Paketliste mit zusätzlichen Informationen wie bspw. der Veröffentlichung oder des Distributionsbereichs. Nachfolgende Darstellung zeigt die Ausgabe für eine Standardinstallation von Debian Wheezy in der Version 7.5 mit dem Nutzungsschwerpunkt Deutschland.

Bewertung der Paketquellen mit apt-cache policy

$ apt-cache policy
Paketdateien:
 100 /var/lib/dpkg/status
     release a=now
 500 http://security.debian.org/ wheezy/updates/non-free Translation-en
 500 http://security.debian.org/ wheezy/updates/main Translation-en
 500 http://security.debian.org/ wheezy/updates/contrib Translation-en
 500 http://security.debian.org/ wheezy/updates/non-free i386 Packages
     release v=7.0,o=Debian,a=stable,n=wheezy,l=Debian-Security,c=non-free
     origin security.debian.org
 500 http://security.debian.org/ wheezy/updates/contrib i386 Packages
     release v=7.0,o=Debian,a=stable,n=wheezy,l=Debian-Security,c=contrib
     origin security.debian.org
 500 http://security.debian.org/ wheezy/updates/main i386 Packages
     release v=7.0,o=Debian,a=stable,n=wheezy,l=Debian-Security,c=main
     origin security.debian.org
 500 http://ftp.de.debian.org/debian/ wheezy/non-free Translation-en
 500 http://ftp.de.debian.org/debian/ wheezy/main Translation-en
 500 http://ftp.de.debian.org/debian/ wheezy/main Translation-de_DE
 500 http://ftp.de.debian.org/debian/ wheezy/main Translation-de
 500 http://ftp.de.debian.org/debian/ wheezy/contrib Translation-en
 500 http://ftp.de.debian.org/debian/ wheezy/non-free i386 Packages
     release v=7.5,o=Debian,a=stable,n=wheezy,l=Debian,c=non-free
     origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian/ wheezy/contrib i386 Packages
     release v=7.5,o=Debian,a=stable,n=wheezy,l=Debian,c=contrib
     origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
     release v=7.5,o=Debian,a=stable,n=wheezy,l=Debian,c=main
     origin ftp.de.debian.org
Mit Pinning verwaltete Pakete:
$

Geben Sie hingegen beim Aufruf als Parameter einen Paketnamen an, prüft apt-cache, ob das Paket bereits auf Ihrem System installiert ist oder ob es ein neueres Paket gibt und falls ja, von welchem Paketmirror das Paket in diesem Fall käme.

Beispiel 1 zeigt das Vorgehen anhand des Pakets gdm3. Im vorliegenden Fall ist dieses bereits installiert (Status von dpkg) Falls es das noch nicht wäre, käme das Paket aus dem deutschen Debian-Repository.

Verfügbarkeit für das Paket gdm3 feststellen. 

$ apt-cache policy gdm3
gdm3:
  Installiert:           3.4.1-8
  Installationskandidat: 3.4.1-8
  Versionstabelle:
 *** 3.4.1-8 0
        500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
        100 /var/lib/dpkg/status
$

Beispiel 2 betrifft das Paket linux-libc-dev. Dieses ist bereits in Version 3.2.51-1 installiert, aber es gibt eine aktuellere Variante (3.2.57-3) sowie zusätzlich eine Sicherheitsaktualisierung (Security-Update) mit der Versionsnummer 3.2.46-1+deb7u1. In diesem Fall ist die Version 3.2.57-3 der Installationskandidat, da dieses Paket die aktuellste Variante darstellt.

Verfügbarkeit für das Paket linux-libc-dev feststellen. 

$ apt-cache policy linux-libc-dev
linux-libc-dev:
  Installiert:           3.2.51-1
  Installationskandidat: 3.2.57-3
  Versionstabelle:
     3.2.57-3 0
        500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
 *** 3.2.51-1 0
        100 /var/lib/dpkg/status
     3.2.46-1+deb7u1 0
        500 http://security.debian.org/ wheezy/updates/main i386 Packages
$

Als Beispiel 3 steht das Paket kteatime im Fokus. Dieses ist noch nicht installiert und könnte nachgezogen werden. Dabei käme das Paket aus dem deutschen Debian-Repository.

Verfügbarkeit für das Paket kteatime feststellen. 

$ apt-cache policy kteatime
kteatime:
  Installiert:           (keine)
  Installationskandidat: 4:4.8.4-1
  Versionstabelle:
     4:4.8.4-1 0
        500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
$

8.18.2. Verfügbare Paketversionen mit apt-cache madison ermitteln

apt-cache verfügt ebenso über ein Unterkommando namens madison. Damit finden Sie heraus, welche Pakete derzeit von den Spiegelservern in einer neueren Version verfügbar sind. Nachfolgender Ausdruck zeigt das für das Paket apt-doc.

Ausgabe von apt-cache mit dem Unterkommando madison für apt-doc

$ apt-cache madison apt-doc
   apt-doc | 0.9.7.9+deb7u2 | http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
   apt-doc | 0.9.7.9+deb7u2 | http://security.debian.org/ wheezy/updates/main i386 Packages
       apt | 0.9.7.9+deb7u2 | http://ftp.de.debian.org/debian/ wheezy/main Sources
       apt | 0.9.7.9+deb7u2 | http://security.debian.org/ wheezy/updates/main Sources
$

Wollen Sie diese Informationen nicht nur für die auf Ihrem System genutzten Architekturen und Veröffentlichungen sehen, sondern für alle Architekturen und Veröffentlichungen von Debian, so können Sie das Programm rmadison aus dem Paket devscripts [Debian-Paket-devscripts] verwenden. Es fragt dazu per HTTP eine regelmäßig aktualisierte Quelle im Internet ab, d.h. Sie brauchen Internetzugriff, um rmadison zu nutzen.

Als Parameter erwartet rmadison einen oder mehrere Paketnamen, nach denen es dann recherchiert. Als Ergebnis sehen Sie in der linken Spalte den Paketnamen, gefolgt von der Versionsnummer des Pakets, der Veröffentlichung und am Schluss die Architektur, für die das Paket verfügbar ist. Im nachfolgenden Beispielaufruf ist die Architektur all, da es sich um das Dokumentationspaket apt-doc handelt, welches auf allen Plattformen gleich ist.

Ausgabe von rmadison für apt-doc

$ rmadison apt-doc
 apt-doc | 0.8.10.3+squeeze1 | squeeze         | all
 apt-doc | 0.8.10.3+squeeze2 | squeeze-lts     | all
 apt-doc | 0.9.7.9+deb7u2    | wheezy-security | all
 apt-doc | 0.9.7.9+deb7u2    | wheezy          | all
 apt-doc | 1.0.6             | jessie          | all
 apt-doc | 1.0.6             | sid             | all
 apt-doc | 1.1~exp1          | experimental    | all
 apt-doc | 1.1~exp2          | experimental    | all
$

Sowohl das apt-cache-Unterkommando madison als auch rmadison sind benannt nach madison, einem Programm welches beim Verwalten der Debian-APT-Archive zum Einsatz kommt. Da das originale madison aber direkt auf dem Server aufgerufen werden muss, auf dem das Debian-APT-Archiv zusammengebaut wurde, ist es nur für Debian-Entwickler nutzbar – und selbst für diese eher umständlich, da sie sich erst per SSH auf jenem Server einloggen müssen. Diese beiden Ersatzkommandos sind da doch wesentlich einfacher und vor allem für jedermann zu benutzen.

8.18.3. Verfügbare Paketversionen mit apt-show-versions ermitteln

apt-show-versions [Debian-Paket-apt-show-versions] ist ein Paket, welches jedoch nicht zur Standardinstallation von Debian zählt. Als Parameter geben Sie dem gleichnamigen Programm den Namen des gewünschten Pakets an, für welches Sie Informationen zu den verfügbaren Varianten wünschen. Das Programm ist insbesondere in gemischten Umgebungen interessant, d.h. wenn Pakete aus verschiedenen Veröffentlichungen gleichzeitig verwendet werden.

Nachfolgendes Beispiel zeigt die Ausgabe für das Paket zsh auf einem Debian 7 Wheezy. Hier ist kein neueres Paket verfügbar:

Versionen anzeigen für das Paket zsh

$ apt-show-versions zsh
zsh/wheezy uptodate 4.3.17-1
$

Anders als bei dem obigen Beispiel ist es für das Paket vlc unter Debian 8 Jessie, für das ein aktuelleres Paket bereitsteht:

Versionen anzeigen für das Paket vlc

$ apt-show-versions vlc
vlc:amd64/jessie 2.2.0~rc2-2+deb8u1 upgradeable to 1:2.2.1-dmo3
$

8.18.4. APT 1.0 mit dem Unterkommando list

Ab Debian 8 Jessie und Ubuntu 14.04 LTS Trusty Tahr wird APT auf der Basis der Version 1.0 ausgeliefert. Ab dieser Version verlieren die zuvor vorgestellten Kommandos apt-cache und apt-show-versions etwas an Bedeutung, da das Kommando apt mit dem neuen Unterkommando list und einem Paketnamen als Parameter ähnliches leistet. Die Ausgabe des Paketnamens auf dem Terminal erfolgt in Farbe, nur lässt sich das hier im Buch leider weniger gut illustrieren.

Nachfolgend sehen Sie wiederum die Ausgabe für das Paket zsh. Nach dem Paketnamen erscheinen die Veröffentlichung, die Versionsnummer und die genutzte Architektur (hier amd64). In den Klammern sehen Sie neben dem Installationsstatus eine kurze Angabe, auf welche Version Sie das Paket aktualisieren können.

Neue Möglichkeiten mit APT 1.0. 

$ apt list zsh
Listing... Done
zsh/unstable,testing,now 5.0.5-3 amd64 [installed,upgradable to: 5.0.5-4]
$

8.18.5. Aktualisierbare Pakete mit aptitude ermitteln

Auch aptitude hilft Ihnen dabei, die Pakete zu finden, für die es Neuerungen gibt. Näheres dazu lesen Sie unter „Aktualisierbare Pakete anzeigen“ in Abschnitt 8.12, „Aktualisierbare Pakete anzeigen“.

8.19. Pakete über den Namen finden

Diese Suchvariante ist der häufigste Weg zur Recherche nach gewünschten Paketen. Alle Werkzeuge zur Paketverwaltung bieten eine entsprechende Suchfunktion an, variieren dabei jedoch stark in der Form sowie der Menge der Möglichkeiten. Namentlich ähnliche Pakete sind mit dpkg, apt-cache und aptitude über ein Unterkommando und ein Muster auffindbar. dpkg hat ein eigenes Musterformat, apt-cache und aptitude unterstützen hingegen Reguläre Ausdrücke. Bei den graphischen Programmen ist die Suche über Muster bislang nicht oder lediglich eingeschränkt implementiert.

Ergänzend stehen Ihnen mehrere Dienste für eine Recherche mittels Webbrowser zur Verfügung. Das umfaßt Dienste, die vom Debianprojekt unterhalten und gepflegt werden, aber auch kommerzielle Anbieter und private Initiativen.

8.19.1. Systemwerkzeuge

dpkg

dpkg sucht nur in der Paketliste. Dazu bietet es die Option -l (Langform --list) und listet darüber nur derzeit oder früher schon einmal installierte Pakete auf. Es erwartet als weiteren Parameter entweder einen vollständigen Paketnamen oder einen Suchausdruck mit Platzhalter (engl. Wildcard). Bitte schließen Sie den Suchausdruck in einfache oder doppelte Hochkommata ein, damit die Shell nicht versucht, den Platzhalter selbst auszuwerten.

Fahndung nach den Paketen für xpdf mittels dpkg

$ dpkg -l 'xpdf*'
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version      Architektur  Beschreibung
+++-==============-============-============-=================================
ii  xpdf           3.03-10      amd64        Portable Document Format (PDF) re
un  xpdf-reader    <keine>                   (keine Beschreibung vorhanden)
un  xpdf-utils     <keine>                   (keine Beschreibung vorhanden)
$

Obiger Ausgabe entnehmen Sie, dass nur das Paket xpdf installiert ist. Die beiden anderen Pakete namens xpdf-reader und xpdf-utils waren schon einmal installiert und sind daher dpkg bereits bekannt. Deswegen erscheint als Paketstatus die Buchstabenfolge un für „nicht mehr installiert“.

Ausgabeformat des Paketstatus

Das Ausgabeformat sowie die Buchstaben am Zeilenanfang erklären wir ausführlicher in den beiden Abschnitten dpkg und „Liste der installierten Pakete anzeigen und deuten“ (siehe Abschnitt 8.5, „Liste der installierten Pakete anzeigen und deuten“).

APT

Das Kommando apt-cache liefert in der Standardeinstellung das umfangreichste Suchergebnis auf der Kommandozeile. Ohne weitere Suchoptionen durchsucht apt-cache search die Paketliste und erstöbert den Paketnamen, die Paketabhängigkeiten sowie die kurze als auch die ausführliche Paketbeschreibung.

apt-cache erwartet nach dem Unterkommando search ein Textfragment als Suchbegriff. Nachfolgend sehen Sie das Suchergebnis zum Paket lintian [Debian-Paket-lintian]. Es beinhaltet das gefundene Paket sowie dessen Kurzbeschreibung.

Suche nach einem Paket. 

$ apt-cache search lintian
dput - Debian package upload tool
elida - pbuilder mail interface
fixincludes - Fix non-ANSI header files
libdebian-package-html-perl - generates HTML from a Debian source/binary package
debaux - Debian-Hilfsprogramme
devscripts - Skripte, die das Leben eines Debian-Paketbetreuers erleichtern
lintian - Debian-Paketprüfer
$

aptitude

aptitude berücksichtigt bei der Suche üblicherweise nur den Paketnamen. Es sucht jedoch auf Wunsch auch in der Paketliste und der Paketbeschreibung. Beinhaltet der Paketname eine Tilde (~) oder ein Fragezeichen (?), wird der Paketname als Suchmuster aufgefasst. In Folge werden alle Pakete berücksichtigt, die diesem Suchmuster entsprechen. Dazu füttern Sie aptitude mit den folgenden Optionen:

~dsuchbegriff (Langform ?description(suchbegriff))
Suche nach dem suchbegriff in der Paketbeschreibung.
~nsuchbegriff (Langform ?name(suchbegriff))
Suche nach suchbegriff im Namen des Pakets. suchbegriff wird hier als Teilzeichenkette betrachtet und findet bspw. bei apt die Pakete apt, aptitude und synaptic.
?exact-name(suchbegriff)
Suche nach Paketen, deren Paketnamen exakt mit dem Suchbegriff übereinstimmen.
?term(suchbegriff)
Volltextsuche nach suchbegriff im Namen und der Beschreibung des Pakets.
?term-prefix(suchbegriff)
Volltextsuche nach Begriffen, die den suchbegriff als Präfix beinhalten.
?user-tag(suchbegriff)
Suche nach Begriffen, die den suchbegriff als benutzerdefinierte Markierung beinhalten.

Der Kommandozeilenaufruf von aptitude ist ähnlich zu apt-cache – auch hier folgt auf das Unterkommando search die Suchoption oder nur das Textfragment zur Recherche. Beispielhaft interessierte uns das Paket xpdf. Wie Sie der nachfolgenden Ausgabe entnehmen können, sucht aptitude per Default nur in den Paketnamen. Das Suchergebnis zeigt, dass insgesamt drei Pakete verfügbar sind, die xpdf im Namen tragen. Davon ist nur das erste auf dem System installiert.

Suche nach xpdf mittels aptitude

$ aptitude search xpdf
i   xpdf          - Leseprogramm für das Portable Document Format (PDF)
p   xpdf-reader   - Übergangspaket für xpdf
p   xpdf-utils
$

In der Textoberfläche von aptitude begrenzen Sie zunächst die Auswahl mit der Taste l. In das Eingabefeld tragen Sie den Suchtext oder das o.g. Suchmuster ein. Daraufhin erscheinen in der Übersicht alle Pakete, die diesem Muster entsprechen (siehe Abbildung 8.7, „Ergebnis der Limitierung nach xpdf über die Aptitude-TUI“).

Abbildung 8.7. Ergebnis der Limitierung nach xpdf über die Aptitude-TUI

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/aptitude-limit-xpdf.png

Synaptic

Bis zur Version 0.8 bot Ihnen Synaptic aus Abschnitt 6.4.1, „Synaptic“ zwei Varianten zur Suche an – einerseits eine Schnellsuche und andererseits eine ausführliche Suche. Die Schnellsuche verschwand mit der Version 0.8.

Erstere verbirgt sich hinter dem Suchfenster oben rechts und ist mit dem Begriff Schnellauswahl-Filter betitelt. Geben Sie dort einen Text ein, durchsucht Synaptic die Paketliste und filtert nur die heraus, deren Paketname mit dem Text beginnen. Dabei werden Platzhalter und Reguläre Ausdrücke nicht unterstützt. Als Ergebnis wird die dargestellte Paketliste auf die gefundenen Pakete eingeschränkt.

Die ausführlichere Suche erreichen Sie mittels Ctrl+ F, dem Menüeintrag BearbeitenSuchen … oder alternativ über den Knopf mit der Lupe in der Werkzeugleiste. Es öffnet sich ein Fenster mit einem Eingabefeld für den Suchtext. Darunter befindet sich ein Auswahlfeld, wo Sie die Suche entweder nach Paketname, Beschreibung und Paketname, Betreuer („Maintainer“), Paketversion, Abhängigkeiten und den bereitgestellten Paketen genauer spezifizieren können. Bei dieser Suche versteht Synaptic auch Fragmente, d.h. es interpretiert den Suchtext als Teilstring. Reguläre Ausdrücke versteht es hingegen nicht. Abbildung 8.8, „Ergebnis der Suche nach dem Fragment fce in Synaptic“ zeigt das Suchergebnis für das Fragment fce.

Abbildung 8.8. Ergebnis der Suche nach dem Fragment fce in Synaptic

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/synaptic-suche-nach-namen.png

SmartPM

SmartPM (Abschnitt 6.4.3, „Smart Package Management (SmartPM)“) besitzt nur eine einfachere Suchfunktion. Diese ist als Suchfeld in die graphische Bedienoberfläche integriert. Das Suchfeld erreichen Sie ebenfalls über die Tastenkombination Ctrl+ F. SmartPM versteht auch Fragmente, d.h. es interpretiert den Suchtext als Teilstring, sucht bislang jedoch nur im Paketnamen. Reguläre Ausdrücke bei der Formulierung des Suchstrings unterstützt es bislang nicht.

Abbildung 8.9. Ergebnis der Suche nach dem Fragment top in SmartPM

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/smartpm-suche.png

8.19.2. Browserbasierte Suche

In Paketen blättern mittels dpkg-www

Das Projekt dpkg-www umfasst ein CGI-Skript und stellt Ihnen damit den Zugang zu sämtlicher Dokumentation zu den einzelnen Paketen zur Verfügung, die auf ihrem eigenen oder einem fremden Debian-System installiert sind. Dazu analysiert dpkg-www zunächst das Verzeichnis /usr/share/doc. Als Ergebnis erhalten Sie zu jedem Paket eine graphische Auflistung der dazugehörigen, verfügbaren Textdateien, README-Dokumente, Manpages und GNU Info-Dokumente. Auch das manuelle Durchblättern des Verzeichnisses /usr/share/doc gehört dazu. Ist ebenfalls das Paket dctrl-tools [Debian-Paket-dctrl-tools] installiert, können Sie mittels dpkg-www auch nach anderen Paketen und insbesondere nach den darin enthaltenen Dateien suchen.

Die Grundlage bildet das gleichnamige Paket dpkg-www [Debian-Paket-dpkg-www]. Obwohl dieses seine letzte reguläre Aktualisierung bereits 2008 erhielt und derzeit als verwaist eingestuft ist (d.h, dass das Paket keinen Maintainer mehr hat), sind gemäß Popularity Contest [Debian-Popularity-Contest] noch etwa 350 Installationen in Benutzung (siehe dazu auch „Verbreitungsgrad von Paketen“ in Abschnitt 2.14, „Verbreitungsgrad von Paketen“).

Bitte beachten Sie, dass Sie ohne Anpassung der Konfiguration lediglich im Paketbestand des Systems stöbern können. Aus der Bedienoberfläche heraus können Sie im Auslieferungszustand keine Veränderung ihres Paketbestands vornehmen. Auch die Autoren raten davon ab, da sie es als Sicherheitsrisiko einstufen. Um das dennoch zu ermöglichen, sind zunächst noch Änderungen an den beiden Konfigurationsdateien /etc/dpkg-www.conf (Apache) und /etc/dwww/dwww.conf (Webserver) erforderlich. Die Informationen dazu entnehmen Sie bitte der Dokumentation zu dpkg-www.

dpkg-www setzt auf einem installierten Webserver wie Apache oder Nginx auf. Daher ist die primäre Schnittstelle zur Bedienung des Programms auch ihr Webbrowser. Das Analyseergebnis stellt dpkg-www zweispaltig dar. Links stehen die verschiedenen Paketkategorien (siehe Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“), rechts finden Sie die einzelnen Pakete, die der jeweiligen Kategorie zugeordnet sind (siehe Abbildung 8.10, „Auswahl der Hilfeseiten zum Menüpunkt Netzwerkkommunikation). Jedes Paket wird dabei mit seinem Titel, einer Kurzbeschreibung, dem dazugehörigen Paketnamen und mit der Angabe der bereitstehenden Formate der Dokumentation oder der weiterführenden Dokumente aufgelistet. In der Regel sind das HTML, Plaintext, PDF, Postscript oder SGML.

Abbildung 8.10. Auswahl der Hilfeseiten zum Menüpunkt Netzwerkkommunikation

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/dpkg-www.png

Wählen Sie ein Paket aus der Liste aus, erhalten Sie detailliertere Informationen dazu. Abbildung 8.11, „Auswahl der Hilfeseiten zu Synaptic“ zeigt das Vorgehen beispielhaft anhand des Pakets synaptic [Debian-Paket-synaptic].

Abbildung 8.11. Auswahl der Hilfeseiten zu Synaptic

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/dpkg-www-synaptic.png

dpkg-www verfügt auch über eine sekundäre Schnittstelle — die Kommandozeile. Darüber fragen Sie sowohl Informationen zu ihrem eigenen System, als auch zu entfernten Rechnern ab. Letzteres gelingt nur, sofern dort dpkg-www auch installiert und über das Netzwerk erreichbar ist. Nutzen Sie den Apache Webserver, muss diese Funktionalität zuvor in der Datei /etc/apache2/conf.d/dpkg-www freigeschaltet worden sein.

Neben dem Paketnamen versteht das Programm die folgenden beiden Schalter:

-s (Langform --stdout)
die Ausgabe erfolgt nicht im Webbrowser, sondern auf dem Terminal.
-h Hostname
Hostname des angefragten Rechners.

Für das Paket bash auf dem lokalen Rechner und der späteren Ausgabe im Webbrowser nutzen Sie den nachfolgenden Aufruf. Dazu aggregiert dpkg-www nacheinander die Ergebnisse drei Kommandos dpkg-query -S bash, dpkg-query -l bash und dpkg-query -L bash zur Paketsuche und zur Bestimmung der Dateien in dem angefragten Paket (siehe auch Abschnitt 8.23, „Paketinhalte anzeigen (apt-file)“). Zur Ausgabe im Webbrowser wertet dpkg-www die Umgebungsvariable $BROWSER aus, startet das darüber benannte Programm und öffnet ein zusätzliches Fenster zur Darstellung (siehe dazu auch Kapitel 18, Alternative Standard-Programme mit Debians Alternativen-System).

Lokale Hilfedokumente zum Paket bash mittels dpkg-www anzeigen. 

$ dpkg-www bash
$

Um die Informationen zu dem gleichen Paket zu erhalten, welches jedoch auf dem entfernten Rechner mit dem Hostnamen kiste installiert ist, funktioniert dieser Aufruf mit dem zusätzlichen Schalter -h:

Entfernte Hilfedokumente zum Paket bash mittels dpkg-www im Webbrowser anzeigen. 

$ dpkg-www -h kiste bash
$

Möchten Sie diese Informationen stattdessen auf ihrem aktuellen Terminal ausgeben, ergänzen Sie den obigen Aufruf um den Parameter -s wie folgt (hier am Beispiel des Pakets htop):

Entfernte Hilfedokumente zum Paket htop mittels dpkg-www im Terminal anzeigen. 

$ dpkg-www -h kiste -s htop
Package: htop
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 195
Maintainer: Eugene V. Lyubimkin <jackyf@debian.org> [Debian Bug Report]
Architecture: i386
Version: 1.0.1-1
Depends: libc6 (>= 2.3.4), libncursesw5 (>= 5.6+20070908), libtinfo5
Suggests: strace, ltrace
Description: interactive processes viewer
 Htop is an ncursed-based process viewer similar to top, but it
 allows one to scroll the list vertically and horizontally to see
 all processes and their full command lines.

 Tasks related to processes (killing, renicing) can be done without
 entering their PIDs.

Homepage: http://htop.sourceforge.net

Files owned by package htop:

/usr
/usr/bin
/usr/bin/htop
/usr/share
/usr/share/applications
/usr/share/applications/htop.desktop
/usr/share/doc
/usr/share/doc/htop
/usr/share/doc/htop/AUTHORS
/usr/share/doc/htop/README
/usr/share/doc/htop/changelog.Debian.gz
/usr/share/doc/htop/changelog.gz
/usr/share/doc/htop/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/htop.1.gz
/usr/share/menu
/usr/share/menu/htop
/usr/share/pixmaps
/usr/share/pixmaps/htop.png
$

Suche über die Webseite des Debian-Projekts

Nicht nur für den Einstieg, sondern auch für den Alltag ist die Paketsuche über die Webseite des Debian-Projekts (siehe [Debian-Paketsuche]) äußerst hilfreich und insbesondere sehr schnell. Abbildung 8.12, „Ergebnis der Paketsuche nach iftop über https://packages.debian.org/“ zeigt das Ergebnis der Recherche nach dem Paket iftop im Webbrowser Iceweasel an.

Neben dem Paketnamen beinhaltet jeder Suchtreffer die Distribution (siehe Abschnitt 2.9, „Distributionsbereiche“), gefolgt von der Veröffentlichung (hier genannt „Suite“) (siehe Abschnitt 2.10, „Veröffentlichungen“), der Paketkategorie (siehe Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“) und den Debian-Architekturen (siehe Abschnitt 1.2, „Debian-Architekturen“), für die passende Pakete zur Verfügung stehen. Damit sehen Sie sofort, ob das Paket für ihre Veröffentlichung und Architektur existiert.

Klicken Sie einen der Links unterhalb des Suchfeldes an, schränken Sie das Suchergebnis auf die jeweilige Veröffentlichung oder Architektur weiter ein und erhalten daraufhin detailliertere Informationen zu dem spezifisch ausgewählten Paket. Neben der Paketbeschreibung sehen Sie die Debian Tags, die Paketabhängigkeiten und am rechten Rand weiterführende Informationen zum Paket. Dazu zählen ein Screenshot von screenshots.debian.net (sofern verfügbar), Fehlerberichte, die Liste der Änderungen („Changelog“), die Quellcodepakete, den Paketbetreuer („Maintainer“), die Projektwebseite und eine Liste ähnlicher Pakete.

Abbildung 8.12. Ergebnis der Paketsuche nach iftop über https://packages.debian.org/

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/paketsuche-debian-webseite.png

Aber nicht nur das — Sie können mit bestimmten Kurzformen der URL direkt die entsprechende Suche einleiten oder ein gewünschtes Paket anzeigen lassen:

https://packages.debian.org/suchbegriff
sucht nach Binärpaketen mit suchbegriff im Paketnamen, wobei der Paketname nicht mit dem Suchbegriff beginnen muß. Ebenso unterscheidet die Suche nicht zwischen Groß- und Kleinschreibung, sperrt sich aber gegenüber Regulären Ausdrücken. So sieht bspw. der Aufruf für Pakete mit screen im Paketnamen aus:
https://packages.debian.org/screen
https://packages.debian.org/src:suchbegriff
sucht nach Quellpaketen mit suchbegriff im Paketnamen, z.B. so für Pakete mit screen im Namen:
https://packages.debian.org/src:screen
https://packages.debian.org/release/paketname
zeigt die Informationen zum Binärpaket paketname in der Veröffentlichung release an, z.B. so für die Paketbeschreibung und die Abhängigkeiten des Paketes screen in der aktuellen, stabilen Debian-Veröffentlichung:
https://packages.debian.org/stable/screen
https://packages.debian.org/sprachkürzel/release/paketname
zeigt die Informationen zum Paket paketname in der Veröffentlichung release in der gewählten Sprache an, z.B. so für die Paketbeschreibung und die Abhängigkeiten des Paketes screen im aktuellen Stable-Release von Debian auf Deutsch:
https://packages.debian.org/de/stable/screen
https://packages.debian.org/source/release/sourcepaketname
zeigt die Informationen zum Quellpaket sourcepaketname in der Veröffentlichung release an, z.B. so für die Paketbeschreibung und die Abhängigkeiten des Paketes screen in Debian Testing:
https://packages.debian.org/source/testing/screen

Analog zu den Binärpaketen können Sie hier auch noch ein Sprachkürzel an den Anfang des Pfades setzen, um eine bestimmte Sprache zu erzwingen.

https://packages.debian.org/release/
zeigt alle Kategorien in der benannten Veröffentlichung (release) an, hier für Debian unstable:
https://packages.debian.org/unstable
https://packages.debian.org/release/kategorie
zeigt alle Binärpakete in der entsprechenden Kategorie der gewählten Veröffentlichung (release) an (siehe „Sortierung der Pakete nach Verwendungszweck“ in Abschnitt 2.8, „Sortierung der Pakete nach Verwendungszweck“), z.B. alle Binärpakete in der Kategorie Mail in der aktuellen, stabilen Veröffentlichung von Debian:
https://packages.debian.org/stable/mail/

Auch hier können Sie wieder ein Sprachkürzel an den Anfang des Pfades setzen, um eine bestimmte Sprache auszuwählen.

Anstelle des Namens einer Veröffentlichung — jessie, stretch, sid, etc. — kann auch stets ein Entwicklungsstand — stable, testing, unstable, etc. — verwendet werden.

Suche über die Webseite von Debian-Derivaten

Einige Derivate von Debian nutzen dieselbe Webanwendung zur Auflistung ihrer Pakete im Web. Den Autoren des Buches sind bisher bekannt:

Ubuntu (https://packages.ubuntu.com/)
unterstützt bisher keine Suite-Namen, denn es gibt bei Ubuntu bisher aber auch nur genau einen Suite-Namen namens devel. Der Aufruf für die Kategorie mail aus der Veröffentlichung Xenial Xerus in deutscher Sprache sieht wie folgt aus:
http://packages.ubuntu.com/de/xenial/mail/
Tanglu (http://packages.tanglu.org/)
unterstützt z.Zt. kein HTTPS. Daher erfolgt der Aufruf für die Kategorie mail aus der stabilen Veröffentlichung in deutscher Sprache wie folgt:
http://packages.tanglu.org/de/staging/mail/

Die für die Webseite des Debian-Projekts genannten Kurzformen sollten ebenfalls mit diesen Hostnamen funktionieren. Jedoch ist dabei zu beachten, dass andere Distributionen aufgrund anderer Release-Politiken ggf. keine Namen für Entwicklungsstände nutzen und damit auch diese Kurzformen nicht ermöglichen.

Abbildung 8.13. Ergebnis der Paketsuche nach aptsh über http://packages.ubuntu.com/

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/paketsuche-ubuntu-webseite.png

Bei Linux Mint gibt es zwar auch die Webseite http://packages.linuxmint.com/, aber diese verwendet eine auf PHP basierende Software zur Recherche. Als Suchkriterien stehen Ihnen die Veröffentlichung, ein Schlüsselwort für den Paketnamen und die Paketbeschreibung sowie der Distributionsbereich zur Verfügung. Letzteres Auswahlfeld ist als Section gekennzeichnet und stellt die Bereiche Main, Upstream, Import, Backport, Romeo und Any bereit (siehe Abbildung 8.14, „Ergebnis der Paketsuche nach kdm über http://packages.linuxmint.com/“). Nach unseren Recherchen funktionieren bislang keine der vom Debian-Projekt bekannten Kurzformen.

Abbildung 8.14. Ergebnis der Paketsuche nach kdm über http://packages.linuxmint.com/

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/paketsuche-linux-mint-webseite.png

Suche über apt-browse.org

Diese Webseite pflegt Thomas Orozco [apt-browse]. Vorrangiges Ziel von ihm ist, die Suche in Paketen nach bestimmten Dateien und Inhalten zu vereinfachen. Es ist ein nicht-kommerzieller Dienst, der in der Programmiersprache Python entwickelt wurde und die Python-APT-Bibliothek aus dem Paket python-apt [Debian-Paket-python-apt] benutzt (siehe auch „APT und Bibliotheken“ in Kapitel 5, APT und Bibliotheken).

Die Suche erlaubt die gleichzeitige Recherche in mehreren Architekturen und in mehreren Veröffentlichungen. Eingepflegt sind bis dato die Veröffentlichungen Debian stable und unstable sowie die Ubuntu-Varianten der letzten 4 Jahre.

Das Suchergebnis hebt die exakten Treffer hervor, andere Einträge folgen in der Auflistung darunter (siehe Abbildung 8.15, „Ergebnis der Paketsuche nach htop über https://apt-browse.org/“). Die Auswahl eines Suchtreffers öffnet detaillierte Angaben zum Paketinhalt mit dem Paketnamen, der Architektur, der Paketbeschreibung und den Paketabhängigkeiten. Die ebenso angezeigte Dateiliste des Paketinhalts läßt Sie in dem Paket datei- und verzeichnisweise schmökern.

Abbildung 8.15. Ergebnis der Paketsuche nach htop über https://apt-browse.org/

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/paketsuche-apt-browse-webseite.png

Suche über apt-get.org

apt-get.org [apt-get.org] bietet Ihnen die Möglichkeit zur Recherche nach Paketen aus einem inoffiziellen Repository (siehe Abbildung 8.16, „Auswahl der Paketmirror für bei apt-get.org). Das können neuere Paketversionen sein, aber auch Pakete, die noch nicht oder nicht mehr Bestandteil der Debian-Distribution sind.

Bitte beachten Sie bei der Auswahl der Paketquelle über diesen Dienst, dass nicht jedes der angezeigten Repositories Pakete für alle Architekturen (siehe Abschnitt 1.2, „Debian-Architekturen“) und Veröffentlichungen (siehe Abschnitt 2.10, „Veröffentlichungen“) bereithält. Die Auswahl der Paketquelle sagt zudem nichts über die Qualität der darüber angebotenen Pakete aus. Auch wenn diese im Allgemeinen sehr hoch ist, bergen nicht verifizierbare Pakete ein gewisses Risiko.

Abbildung 8.16. Auswahl der Paketmirror für bei apt-get.org

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/apt-get-org.png

Sehr hilfreich und zumeist auch der erste Anlaufpunkt ist die Paketsuche unter dem Menüpunkt Search. Im Eingabefeld geben Sie ein Textfragment aus dem Namen eines Pakets ein, nachdem dann apt-get.org seine Liste der Spiegelserver durchforstet. Das Ergebnis ist eine Liste, aus der Sie entnehmen können, von welchem Spiegelserver Sie das gewünschte Paket beziehen können. Neben der Architektur (siehe Abschnitt 1.2, „Debian-Architekturen“) sehen Sie auch die Veröffentlichung (siehe Abschnitt 2.10, „Veröffentlichungen“) und den Distributionsbereich (siehe Abschnitt 2.9, „Distributionsbereiche“), in die das gefundene Paket einsortiert ist.

Abbildung 8.17, „Suchergebnis der Recherche bei apt-get.org zeigt beispielhaft das Suchergebnis nach dem Paket libdvdcss an, welches bei älteren Veröffentlichungen wie Debian 3 Woody, Debian 3.1 Sarge oder auch bei Sid für die drei Debian-Architekturen all, i386 und powerpc zum Lesen von DVDs benötigt wird und hierüber zur Verfügung steht.

Abbildung 8.17. Suchergebnis der Recherche bei apt-get.org

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/apt-get-org-search.png

Rpmseek.com

Die bereits oben angesprochenen Möglichkeiten zur Recherche über die Webseiten des Debian- bzw. Ubuntu-Projekts beinhalten nur Pakete, die in den offiziellen Repositories der jeweiligen Distribution enthalten sind. Für andere, externe Pakete existieren hingegen spezielle Suchmaschinen und Verzeichnisdienste.

Rpmseek [rpmseek] kann sowohl rpm- als auch deb-Pakete erstöbern. Es erlaubt die Suche anhand des Paketnamens, des Paketformats, der Linux-Distribution und der Architektur. Dabei sucht es entweder in der Paketliste oder der Beschreibung und kann ebenso die Paketabhängigkeiten berücksichtigen.

Gefundene Pakete können Sie nicht nur inspizieren, sondern direkt von der angegebenen Quelle beziehen und installieren. Bitte beachten Sie aber, dass mit diesen Suchmaschinen gefundene Pakete oft nicht den Qualitätsansprüchen von Debian entsprechen, einer nicht-freien Lizenz unterliegen oder schlicht nicht auf Ihrem System installierbar sind, weil z.B. manche Abhängigkeiten nicht erfüllt werden.

Abbildung 8.18. Ergebnis der Paketsuche nach htop über http://www.rpmseek.com/

werkzeuge/paketoperationen/pakete-ueber-den-namen-finden/rpmseek.png

Integration distributionsfremder deb-Pakete

Wie die Einbindung und Verifizierung von deb-Paketen aus den Paketquellen erfolgt, erklären wir Ihnen unter „Paketquellen und Werkzeuge“ in Kapitel 3, Paketquellen und Werkzeuge genauer. Möchten sie auch rpm-Pakete einpflegen, sorgt „Fremdformate mit alien hinzufügen“ in Abschnitt 22.2, „Fremdformate mit alien hinzufügen“ für Erleuchtung. Andere Paketformate betrachten wir im Buch nicht weiter.

8.20. Pakete über die Paketbeschreibung finden

Bleibt ihre Recherche über den Paketnamen ohne Erfolg, dehnen Sie ihre Suche am besten auf die gesamte Paketbeschreibung aus. Zur Recherche darin helfen Ihnen die darauf spezialisierten Programme grep-available und grep-status aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools].

Ohne die Angabe weiterer Parameter durchsucht grep-available die gesamte Paketbeschreibung. Mit Hilfe der Option -F (Langform --field) schränken Sie den Vorgang auf einen darüber ausgewählten Feldnamen ein. Nachfolgender Aufruf zeigt Ihnen von allen verfügbaren Paketen die Paketnamen an, bei denen in der Beschreibung und im Paketnamen die Zeichenfolge xpdf enthalten ist. Durch den Schalter -i (Langform --ignore-case) erfolgt die Suche dabei unabhängig von der Groß- und Kleinschreibung. Das abschließende sort-Kommando sorgt darüber hinaus für eine Ausgabe in alphabetisch aufsteigender Abfolge.

Verfügbare Pakete anzeigen, bei denen in der Beschreibung und im Paketnamen die Zeichenfolge xpdf enthalten ist. 

$ grep-available -F Description -F Package -i xpdf | grep Package | sort
Package: flpsed
Package: libpoppler19
Package: libpoppler3
Package: libpoppler5
Package: libpoppler-cpp0
Package: libpoppler-glib3
Package: libpoppler-glib4
Package: libpoppler-glib8
Package: libpoppler-qt2
Package: libpoppler-qt4-3
Package: poppler-utils
Package: python-poppler
Package: xpdf
$

Um den Aufruf für den Paketnamen zu vereinfachen, stellt Ihnen grep-available zudem die beiden Abkürzungen -P für -FPackage und -S für -FSource:Package bereit.

Obige Liste enthält alle Pakete – unabhängig davon, ob diese auf ihrem System installiert sind, oder nicht. Mit dem nachfolgenden Aufruf reduzieren Sie die Liste entsprechend. Dabei kommt der Schalter -s (Langform --show-field) zum tragen, der den Paketstatus passend auswertet.

Lediglich die installierten Pakete anzeigen, bei denen in der Beschreibung und im Paketnamen die Zeichenfolge xpdf enthalten ist. 

$ grep-status -F Description -P -i -s Package xpdf | grep Package | sort
Package: flpsed
Package: libpoppler19
Package: libpoppler-cpp0
Package: libpoppler-glib8
Package: libpoppler-qt4-3
Package: poppler-utils
Package: python-poppler
Package: xpdf
$

Analog zu grep verfügt grep-status ebenfalls über den hilfreichen Schalter -v (Langversion --invert-match). Bei Bedarf verkehren Sie mit diesem das Suchergebnis in das Gegenteil.

8.21. Paket nach Maintainer finden

Als Debian Maintainer versteht sich diejenige Einzelperson oder das Team, welche(s) eine Software betreut und für das entsprechende Debian-Paket verantwortlich zeichnet. Maintainer kümmern sich darum, dass das Paket gepflegt wird, d.h. Änderungen und Verbesserungen aus dem Upstream in das Paket unter Berücksichtigung der Debian-Spezifika einfließen, dieses dabei weiterhin den Debian-Richtlinien entspricht und in möglichst stabiler Form verfügbar bleibt [Debian-Wiki-Maintainer].

8.21.1. Welche Pakete betreut ein Debian-Maintainer

Diese Information liefern Ihnen mehrere Werkzeuge – aptitude, grep-dctrl sowie ara und Synaptic. Die Unterschiede liegen im Aufruf und den Parametern.

aptitude kennt den Schalter ~m gefolgt von der Emailadresse des Maintainers. Damit finden Sie die Binärpakete, in denen dieser Maintainer als Verantwortlicher eingetragen ist. Für Axel Beckert und seine Emailadresse abe@debian.org lautet der komplette Aufruf aptitude search '~m abe@debian.org'. In der Schreibweise ist aptitude sehr tolerant – es gestattet den Aufruf mit und auch ohne Leerzeichen zwischen der Option und der Emailadresse.

Paketfilterung nach der Emailadresse des Maintainers mittels aptitude

$ aptitude search '~m abe@debian.org'
p   aha                               - Konvertiert ANSI-Farben nach HTML
p   amora-applet                      - use a bluetooth device as X remote control (
p   amora-cli                         - use a bluetooth device as X remote control (
p   autossh                           - SSH-Sitzungen und -Tunnel automatisch neu st
p   conkeror                          - Tastaturbedienbarer Webbrowser mit Emacs-ähn
p   conkeror-spawn-process-helper     - spawn external processes in Conkeror
p   dillo                             - Kleiner und schneller Webbrowser
p   dphys-config                      - Werkzeug zum Verteilen von Konfigurationsdat
p   dphys-swapfile                    - Automatisches Generieren und Nutzen einer Au
p   libapache2-mod-macro              - Create macros inside Apache config files
p   links                             - Textmodus-Webbrowser
i   links2                            - Webbrowser für den grafischen und den Textmo
...
$

Obige Ausgabe basiert auf dem Formatstring -F '%c%a%M %p - %d'. Die einzelnen Buchstaben stehen für den aktuellen Paketstatus (%c), die Aktion des Pakets (%a), automatische Installation (%M), den Paketnamen (%p) und die Paketbeschreibung (%d). Eine detaillierte Übersicht zu allen zulässigen Formatoptionen erklären wir Ihnen unter „aptitude Format Strings“ in Abschnitt 10.4, „aptitude Format Strings“. Eine Alternative bietet zudem das Aptitude Handbuch [aptitude-dokumentation-paketdarstellung].

Möchten Sie in der Ausgabe stattdesen nur den Paketnamen, die Paketbeschreibung und den Paketmaintainer ausgeben, helfen Ihnen dabei die drei Optionen %p, %d und %m weiter. Letztgenanntes steht als Abkürzung für maintainer.

Paketsuche nach Paketnamen, Paketbeschreibung und Paketmaintainer. 

$ aptitude search -F '%p - %d - %m' '~mabe@debian.org'
aha            - Konvertiert ANSI-Farben nach HTML  - Axel Beckert <abe@debian.org>
amora-applet   - use a bluetooth device as X remote - Axel Beckert <abe@debian.org>
amora-cli      - use a bluetooth device as X remote - Axel Beckert <abe@debian.org>
autossh        - SSH-Sitzungen und -Tunnel automati - Axel Beckert <abe@debian.org>
...
$

Das Programm grep-dctrl aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools] sucht alle Pakete heraus, bei dem als Maintainer oder Uploader die angefragte Person hinterlegt ist und gibt diese zum gefundenen Paketnamen aus. Als weiteren Parameter benötigt es noch die lokal gespeicherte Paketliste, die es durchsuchen soll. Im nachfolgenden Beispiel ist das die Paketliste für den Paketmirror ftp.de.debian.org für die Distribution Debian 7 Wheezy sowie daraus der Bereich main und die Architektur i386.

Suche nach Maintainer und Uploader in der lokalen Paketliste (Ausschnitt). 

$ grep-dctrl -F Maintainer,Uploaders abe@debian.org -s Package,Maintainer,Uploaders /var/lib/apt/lists/ftp.de.debian.org_debian_dists_wheezy_main_binary-i386_Packages
Package: aha
Maintainer: Axel Beckert <abe@debian.org>

Package: amora-applet
Maintainer: Axel Beckert <abe@debian.org>

Package: amora-cli
Maintainer: Axel Beckert <abe@debian.org>

Package: autossh
Maintainer: Axel Beckert <abe@debian.org>

...
$

Das Programm ara aus dem gleichnamigen Paket [Debian-Paket-ara] erlaubt eine sehr kompakte Schreibweise. Es sucht dabei in den Binär- und den Sourcepaketen, sofern diese vorhanden sind und gibt dabei trotzdem die Namen der dazugehörigen Binärpakete aus. Nachfolgender Aufruf zeigt die Recherche nach den Feldern uploaders und maintainer für den Benutzer mit der Emailadresse abe@debian.org. Bitte berücksichtigen Sie bei eigenen Experimenten die unterschiedlichen Trennzeichen zwischen den Komponenten und den abschließenden Schrägstrich nach der Emailadresse.

Einfache Recherche nach Paketen mit Hilfe von ara

$ ara uploaders,maintainer:/abe@debian.org/
aha
amora-applet
amora-cli
amora-server
autocutsel
autossh
conkeror
conkeror-spawn-process-helper
...
$

Besonders schön sehen Sie das bei der nachfolgenden Abfrage in Abbildung 8.19, „Recherche nach Paketen mittels ara. Die verwendeten Schalter -progress und -table zählen nicht nur die überprüften Pakete und zeigen die gerade untersuchte Paketquelle an, sondern zeichnen auch noch eine hübsche Tabelle ringsrum. Zu jedem gefundenen Source-Paket werden in der jeweiligen Spalte die dazugehörigen Binärpakete aufgelistet.

Abbildung 8.19. Recherche nach Paketen mittels ara

werkzeuge/paketoperationen/ara-suche.png

Das graphische Programm Synaptic (Abschnitt 6.4.1, „Synaptic“) handhabt das ganze etwas anders und bietet Ihnen einen passenden Menüeintrag an. Unter dem Eintrag BearbeitenSuchen bzw. mit der Tastenkombination Ctrl+F erreichen Sie den Suchdialog. Im Auswahlfeld selektieren Sie den Eintrag Betreuer und tragen im Eingabefeld dessen Namen ein. Daraufhin liefert Ihnen Synaptic ein Ergebnis wie in Abbildung 8.20, „Ergebnis der Suche nach dem Paketmaintainer in Synaptic“. In der linken Spalte der Paketauswahl erscheint zudem ein zusätzlicher Eintrag mit dem Namen des Paketmaintainers.

Abbildung 8.20. Ergebnis der Suche nach dem Paketmaintainer in Synaptic

werkzeuge/paketoperationen/synaptic-suche-nach-maintainer.png

8.21.2. Rückrichtung: Wer betreut ein bestimmtes Paket

Interessant ist natürlich auch die Rückrichtung: das Ausgeben aller Maintainer und Co-Maintainer zu einer Liste von Source- und Binärpaketen. Das gelingt Ihnen mit dem Kommando dd-list aus dem Paket devscripts [Debian-Paket-devscripts]. Als Parameter geben Sie die Namen der Pakete an, die Sie interessieren. Leider werden in der Ausgabe die Co-Maintainer irreführend als Uploader mit einem großen U benannt.

Ausgabe der Maintainer und Co-Maintainer mittels dd-list

$ dd-list screen xymon fping ack-grep
Anibal Monsalve Salazar <anibal@debian.org>
   fping

Axel Beckert <abe@debian.org>
   ack-grep (U)
   fping (U)
   screen
   xymon (U)

Christoph Berg <myon@debian.org>
   xymon

Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
   ack-grep
Jan Christoph Nordholz <hesso@pool.math.tu-berlin.de>
   screen (U)

Ryan Niebur <ryan@debian.org>
   ack-grep (U)
$

Viele Entwickler mögen dieses Kommando sehr. Sie verwenden es, um Listen von einem bestimmten Problem oder einer Migration betroffenen Pakete zu erhalten. Darin suchen sie nach ihrem eigenen Namen und wenn dieser nicht mehr darin auftaucht, haben sie keine Arbeit mehr damit ;-)

8.22. Paket zu Datei finden

Häufig ist Ihnen nur der Dateiname bekannt, aber nicht das Paket, aus dem diese Datei stammt. Das wird insofern spannend, wenn das Paket anders als die gesuchte Datei heißt. Es gibt derzeit fünf Möglichkeiten, diese Zuordnung zu ermitteln – einerseits über dpkg, dpkg-query oder dlocate [Debian-Paket-dlocate] mit deren Option -S Muster, andererseits mittels apt-file und dessen Option search Muster und fünftens über die Webseite des Debian-Projekts. aptitude verfügt nicht über einen solchen Schalter zur Suche.

Die vier Kommandos finden alle Pfade, in denen das angegebene „Muster“ vorkommt. Der Unterschied zwischen den vier Programmen besteht darin, dass dpkg, dpkg-query und dlocate nur in bereits installierten Paketen suchen, apt-file hingegen hingegen in allen verfügbaren Paketen, d.h. unabhängig davon, ob diese bereits auf ihrem System installiert sind oder nicht. Verfügbare Pakete bezeichnet die Menge von Paketen, die APT über einen Eintrag in der Liste der Paketquellen in der Datei /etc/apt/sources.list und aus der dazugehörigen Paketliste entnehmen kann (siehe dazu Abschnitt 3.1, „Paketquellen“). Pakete, die sich hingegen in Paketquellen befinden, die nicht in obiger Liste referenziert sind, kann apt-file nicht untersuchen.

Bei der Suche über die Webseite bildet zunächst der gesamte Paketbestand aller Veröffentlichungen die Grundlage. Sie können das jederzeit entsprechend über die Auswahlfelder zur Veröffentlichung oder Architektur einschränken.

8.22.1. Suche in bereits installierten Paketen

Dafür genügen der Aufruf dpkg -S Muster, dpkg-query -S Muster oder die flinke Abkürzung dlocate Muster. Zur Suche ist bei dlocate der Schalter -S optional, dpkg und dpkg-query kennen hingegen dafür die Langform --search. Das Textfragment oder Muster beschreibt, wonach die Programme in der Dateiliste der installierten Pakete suchen sollen. Beginnt das Textfragment mit einem /, wird die Zeichenkette als absoluter Pfad interpretiert. Nachfolgendes Beispiel illustriert den Aufruf nach dem Muster aptsh mittels dpkg in allen installierten Paketen.

Suche nach dem Muster aptsh mittels dpkg

$ dpkg -S aptsh
aptsh: /usr/lib/aptsh/aptsh_ls
aptsh: /usr/share/doc/aptsh/changelog.gz
aptsh: /usr/share/man/man1/aptsh.1.gz
aptsh: /usr/share/doc/aptsh/copyright
aptsh: /usr/share/doc/aptsh
aptsh: /etc/aptsh.conf
aptsh: /usr/lib/aptsh/aptsh_printer
aptsh: /usr/bin/aptsh
aptsh: /usr/share/doc/aptsh/HOWTO.gz
aptsh: /usr/lib/aptsh/aptsh_rls
aptsh: /usr/lib/aptsh
$

dlocate liefert im Allgemeinen ein identisches Ergebnis zu dpkg bzw. dpkg-query. Da dlocate zur Suche auf grep zurückgreift, hat es mitunter eine höhere Trefferrate. Nachfolgendes Beispiel zeigt die Suche nach dem absoluten Pfad /xara-gtk – sowohl für dpkg, als auch zu dlocate im Vergleich.

Suche nach der Pfadangabe /xara-gtk

$ dpkg -S /xara-gtk
dpkg-query: Kein Pfad gefunden, der auf Muster /xara-gtk passt
$ dlocate -S /xara-gtk
xara-gtk: /etc/xara-gtkrc-2.0
xara-gtk: /usr/share/menu/xara-gtk
xara-gtk: /usr/share/doc/xara-gtk
xara-gtk: /usr/share/doc/xara-gtk/copyright
xara-gtk: /usr/share/doc/xara-gtk/changelog.gz
$

8.22.2. Suche in noch nicht installierten Paketen

Dafür gibt es apt-file. Grundlage seiner Aktivitäten ist die Liste der Paketquellen in /etc/apt/sources.list/ und die Liste der Dateien in jedem der Pakete, die von dort bezogen werden. Letztere befindet sich im Verzeichnis /var/cache/apt/apt-file/.

Liste der Paketquellen anzeigen. 

$ ls /var/cache/apt/apt-file
ftp.de.debian.org_debian_dists_wheezy_contrib_Contents-i386.gz
ftp.de.debian.org_debian_dists_wheezy_main_Contents-i386.gz
ftp.de.debian.org_debian_dists_wheezy_non-free_Contents-i386.gz
httpredir.debian.org_debian_dists_wheezy_contrib_Contents-i386.gz
httpredir.debian.org_debian_dists_wheezy_main_Contents-i386.gz
httpredir.debian.org_debian_dists_wheezy_non-free_Contents-i386.gz
$

Sollte diese Liste noch nicht vorhanden sein, erhalten Sie diese mit dem Aufruf apt-file update. Danach bezieht apt-file ein durchaus größeres Archiv (20 MB) von den angegebenen Paketmirrors und legt diese Dateien im Verzeichnis /var/cache/apt/apt-file/ ab.

Im nachfolgenden Beispiel zu apt-file update wird der Paketmirror dynamisch ausgewählt. Hintergrundinformationen dazu finden Sie in Abschnitt 3.3, „/etc/apt/sources.list verstehen“ und Abschnitt 3.6.2, „Paketquellen über GeoIP auswählen“:

Suchdatenbank von APT aktualisieren. 

# apt-file update
Downloading complete file http://httpredir.debian.org/debian/dists/wheezy/main/Contents-i386.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 20.6M  100 20.6M    0     0  3917k      0  0:00:05  0:00:05 --:--:-- 4111k
Downloading complete file http://httpredir.debian.org/debian/dists/wheezy/contrib/Contents-i386.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 73552  100 73552    0     0   302k      0 --:--:-- --:--:-- --:--:--  302k
Downloading complete file http://httpredir.debian.org/debian/dists/wheezy/non-free/Contents-i386.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  723k  100  723k    0     0  1428k      0 --:--:-- --:--:-- --:--:-- 1428k
Ignoring source without Contents File:
  http://security.debian.org/dists/wheezy/updates/main/Contents-i386.gz
Ignoring source without Contents File:
  http://security.debian.org/dists/wheezy/updates/contrib/Contents-i386.gz
Ignoring source without Contents File:
  http://security.debian.org/dists/wheezy/updates/non-free/Contents-i386.gz
#

apt-file verfügt über eine ganze Reihe von Unterkommandos und Schaltern, von denen wir Ihnen die wichtigsten vorstellen. Weitere Schalter entnehmen Sie bitte der Manpage zum Programm.

search Muster
Suche danach, in welchem Paket die als Muster angegebene Datei enthalten ist. Ergebnis ist eine Liste aller Pakete, die das angegebene Muster enthalten. apt-file sucht dabei nur nach Dateinamen, nicht jedoch nach Verzeichnisnamen.
find Muster
Alias für den Schalter search.
list Muster
gibt den Paketinhalt aus, auf den das Muster passt. Diese Aktion ist sehr ähnlich zum Aufruf dpkg -L, nur das hier die Pakete noch nicht installiert sein müssen.
show Muster
Alias für den Schalter list.
-a (Langform --architecture)
Einschränkung der Suche auf die angegebene Architektur (siehe Abschnitt 1.2, „Debian-Architekturen“).
-i (Langform --ignore-case)
Suche unabhängig von Groß- und Kleinschreibung des Musters.
-l (Langform --package-only)
Das Ergebnis ist nur der Paketname, auf den das Muster passt. Dateinamen werden nicht berücksichtigt.
-x (Langform --regexp)
interpretiert das Muster als Regulären Ausdruck, so wie ihn Perl versteht (PCRE). Ohne diesen Schalter wird das Muster als schlichte Zeichenkette aufgefasst.
-v (Langform --verbose)
verbose, d.h. die Ausgabe wird deutlich ausführlicher.

Etwas nachteilig an apt-file ist, dass es alle Paketquellen durchsucht und Ihnen dabei nicht anzeigt, in welcher davon es den Treffer gefunden hat. Das führt zu Verwirrung, bspw. wenn in der Liste der Paketquellen die Veröffentlichungen stable und stable-backports eingetragen sind. apt-file verfügt bislang nicht über einen Schalter, um die Ausgabe dementsprechend zu beeinflussen.

Aktuelle Strukturdatenbank

Um vernünftig mit apt-file arbeiten zu können, empfehlen wir Ihnen, zuerst mit apt-file update die bestehende Dateiliste zu aktualisieren und danach darin zu stöbern. Damit nutzen Sie eine aktuelle Datenbasis.

Das nachfolgende Beispiel zeigt die Suche der Zeichenkette aptsh. Zusätzlich kommt der Schalter -v (Langform --verbose) zum Einsatz, um eine ausführlichere Ausgabe zu erhalten.

Suche über die Strukturdatenbank mittels apt-file

# apt-file -v show aptsh
D: Using cache directory /var/cache/apt/apt-file
D: reading sources file /etc/apt/sources.list
D: got 'deb http://httpredir.debian.org/debian/ wheezy main contrib non-free'
D: kept 'deb http://httpredir.debian.org/debian/ wheezy main contrib non-free'
D: got 'deb http://security.debian.org/ wheezy/updates main contrib non-free'
D: kept 'deb http://security.debian.org/ wheezy/updates main contrib non-free'
D: regexp: ^\s*(.*?)\s+(\S*/\S*aptsh\S*)\s*$
D: Search in \/var\/cache\/apt\/apt\-file\/httpredir\.debian\.org_debian_dists_wheezy_main_Contents\-i386\.gz using zfgrep  -- aptsh
.........
D: Search in \/var\/cache\/apt\/apt\-file\/httpredir\.debian\.org_debian_dists_wheezy_contrib_Contents\-i386\.gz using zfgrep  -- aptsh

D: Search in \/var\/cache\/apt\/apt\-file\/httpredir\.debian\.org_debian_dists_wheezy_non\-free_Contents\-i386\.gz using zfgrep  -- aptsh

aptsh: /etc/aptsh.conf
aptsh: /usr/bin/aptsh
aptsh: /usr/lib/aptsh/aptsh_ls
aptsh: /usr/lib/aptsh/aptsh_printer
aptsh: /usr/lib/aptsh/aptsh_rls
aptsh: /usr/share/doc/aptsh/HOWTO.gz
aptsh: /usr/share/doc/aptsh/changelog.gz
aptsh: /usr/share/doc/aptsh/copyright
aptsh: /usr/share/man/man1/aptsh.1.gz
#

8.22.3. Suche über die Webseite des Debian-Projekts

Die Webseite bietet ebenfalls eine Suche anhand einer Zeichenfolge an (siehe Abbildung 8.21, „Suche nach xara-gtk über die Webseite“). Über verschiedene Auswahlfelder grenzen Sie ein, ob die Zeichenfolge auf feste Verzeichnisse passen soll, die mit einem Suchwort enden oder Pakete mit Dateien beinhalten soll, die so benannt sind oder deren Namen das Suchwort enthalten. Desweiteren filtern Sie die Suchergebnisse nach der gewünschten Veröffentlichung und Architektur (siehe dazu Abschnitt 2.10, „Veröffentlichungen“ und Abschnitt 1.2, „Debian-Architekturen“).

Abbildung 8.21. Suche nach xara-gtk über die Webseite

werkzeuge/paketoperationen/paketsuche-web1.png

Die Abbildung 8.22, „Suche nach dem Paket xara-gtk über die Webseite des Debian-Projekts (Suchergebnis)“ zeigt das Suchergebnis für die Veröffentlichung Wheezy, welches hier recht übersichtlich ausfällt. Beide Treffer zeigen das Paket xara-gtk samt der dazu gefundenen Dateien mit dem Suchmuster. Klicken Sie auf einen der Links zwischen dem Suchfeld und dem Suchergebnis, schränken Sie die Suche anhand der gewählten Veröffentlichung bzw. Architektur weiter ein.

Abbildung 8.22. Suche nach dem Paket xara-gtk über die Webseite des Debian-Projekts (Suchergebnis)

werkzeuge/paketoperationen/paketsuche-web2.png

8.23. Paketinhalte anzeigen (apt-file)

In einem Paket sind stets mehrere Dateien zusammengefasst. Mit den sechs Werkzeugen dpkg, dpkg-deb, dpkg-query, dlocate, apt-file und dglob zeigen Sie den Inhalt eines Pakets an. Dabei sind dpkg-deb und dpkg-query Hilfsprogramme von dpkg und verstehen die gleichen Schalter.

Es sind mehrere Fälle zu unterscheiden, die jeweils unterschiedliche Aufrufe nachsichziehen:

das Paket ist bereits installiert
dpkg -L Paketname, dpkg-query -L Paketname, dlocate -ls Paketname sowie mittels dglob -f Paketname. Der Parameter Paketname bezeichnet lediglich den Namen des Pakets (siehe Abschnitt 2.11, „Benennung einer Paketdatei“) ohne Angabe der Versionsnummer.
das Paket ist noch nicht installiert
dpkg -c deb-Datei oder dpkg-deb -c deb-Datei. Der Parameter deb-Datei ist ein Paketarchiv in Form einer lokal vorliegenden Datei. Befindet sich die Datei nicht im aktuellen Verzeichnis, von dem aus Sie das Kommando aufrufen, ergänzen Sie im Aufruf den dazugehörigen Verzeichnispfad, in dem das Paketarchiv liegt.
das Paket muss nicht installiert sein, kann aber
apt-file show Paketname, apt-file list Paketname und dglob -af Paketname. Der Parameter Paketname bezeichnet hier lediglich den Namen eines Pakets (siehe Abschnitt 2.11, „Benennung einer Paketdatei“) ohne Angabe der Versionsnummer.

8.23.1. dpkg -L Paketname

Die Langform des Schalters ist --listfiles. Beide Schalter versteht ebenso das Hilfsprogramm dpkg-query und erzeugt die gleiche Ausgabe. Damit listen Sie den Paketinhalt mit allen Pfaden auf. Jede Verzeichnisebene ist separat aufgeführt. Das nachfolgende Beispiel verdeutlicht das am Paket xara-gtk.

Auflistung des Paketinhalts mit allen Pfaden via dpkg

$ dpkg -L xara-gtk
/.
/etc
/etc/xara.config
/etc/xara-gtkrc-2.0
/usr
/usr/bin
/usr/bin/xara
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/xara.1.gz
/usr/share/menu
/usr/share/menu/xara-gtk
/usr/share/doc
/usr/share/doc/xara-gtk
/usr/share/doc/xara-gtk/copyright
/usr/share/doc/xara-gtk/changelog.gz
$

8.23.2. dlocate -L Paketname

Eine identische Ausgabe zum vorherigen dpkg-Aufruf ermöglicht Ihnen das Programm dlocate [Debian-Paket-dlocate] mit dem Schalter -L. Beachten Sie hierbei jedoch, dass dlocate die Angabe des Paketnamens als regulären Ausdruck interpretiert.

8.23.3. dlocate -ls Paketname

Nutzen Sie statt -L hingegen den Schalter -ls, wird die Ausgabe sehr ausführlich. Es entspricht dem Aufruf des UNIX-Kommandos ls -ldF bezogen auf alle Dateien, die in dem Paket enthalten sind.

Auflistung des Paketinhalts in ausführlicherer Form via dlocate

$ dlocate -ls xara-gtk
drwxr-xr-x   24 root root    4096 Mär 13 09:44 /./
drwxr-xr-x  182 root root   12288 Jun 22 23:21 /etc/
-rw-r--r--    1 root root     658 Jun 11  2010 /etc/xara.config
-rw-r--r--    1 root root     136 Jun 11  2010 /etc/xara-gtkrc-2.0
drwxr-xr-x   11 root root    4096 Jan  8 00:44 /usr/
drwxr-xr-x    2 root root  110592 Jun 13 16:34 /usr/bin/
-rwxr-xr-x    1 root root 1828064 Mai 21  2012 /usr/bin/xara*
drwxr-xr-x  396 root root   12288 Jun 13 16:34 /usr/share/
drwxr-xr-x 2292 root root   77824 Jun 13 16:34 /usr/share/doc/
drwxr-xr-x    2 root root    4096 Jan  8 01:55 /usr/share/doc/xara-gtk/
-rw-r--r--    1 root root    5488 Mai 20  2012 /usr/share/doc/xara-gtk/changelog.gz
-rw-r--r--    1 root root    1281 Apr 18  2011 /usr/share/doc/xara-gtk/copyright
drwxr-xr-x   50 root root    4096 Jan  8 01:56 /usr/share/man/
drwxr-xr-x    2 root root  131072 Jun 13 16:34 /usr/share/man/man1/
-rw-r--r--    1 root root    6121 Mai 21  2012 /usr/share/man/man1/xara.1.gz
drwxr-xr-x    2 root root    4096 Jun 13 16:34 /usr/share/menu/
-rw-r--r--    1 root root     160 Apr 18  2011 /usr/share/menu/xara-gtk
$

8.23.4. dpkg -c deb-Datei

Sie verwenden den Schalter -c, um sich den Inhalt eines deb-Pakets anzeigen zu lassen (Langform --contents). Dieses Paket wird dpkg als Parameter übergeben und kann sowohl eine Datei in einem lokalen Verzeichnis bezeichnen, als auch den Namen eines Archivs. Im Gegensatz zu dpkg -L muss das Paket nicht auf ihrem System installiert sein. Intern übergibt dpkg die Ausführung an dpkg-deb, welches Sie auch separat aufrufen können.

Auflistung des Paketinhalts mit allen Informationen via dpkg

$ dpkg -c /var/cache/apt/archives/xara-gtk_1.0.31_i386.deb
drwxr-xr-x root/root         0 2012-05-21 01:04 ./
drwxr-xr-x root/root         0 2012-05-21 01:04 ./etc/
-rw-r--r-- root/root       658 2011-04-18 19:29 ./etc/xara.config
-rw-r--r-- root/root       136 2011-04-18 19:29 ./etc/xara-gtkrc-2.0
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/bin/
-rwxr-xr-x root/root   1828064 2012-05-21 01:04 ./usr/bin/xara
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/man/
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/man/man1/
-rw-r--r-- root/root      6121 2012-05-21 01:04 ./usr/share/man/man1/xara.1.gz
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/menu/
-rw-r--r-- root/root       160 2011-04-18 19:28 ./usr/share/menu/xara-gtk
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/doc/
drwxr-xr-x root/root         0 2012-05-21 01:04 ./usr/share/doc/xara-gtk/
-rw-r--r-- root/root      1281 2011-04-18 19:28 ./usr/share/doc/xara-gtk/copyright
-rw-r--r-- root/root      5488 2012-05-20 23:18 ./usr/share/doc/xara-gtk/changelog.gz
$

8.23.5. apt-file show Paketname und apt-file list Paketname

Die beiden Optionen show und list des Werkzeugs apt-file sind synonym zueinander und liefern den gleichen Inhalt wie dpkg -L. Dabei ist die Darstellung von apt-file jedoch deutlich kompakter.

Paketinhalt in kompakter Form mittels apt-file

$ apt-file show xara-gtk
xara-gtk: /etc/xara-gtkrc-2.0
xara-gtk: /etc/xara.config
xara-gtk: /usr/bin/xara
xara-gtk: /usr/share/doc/xara-gtk/changelog.gz
xara-gtk: /usr/share/doc/xara-gtk/copyright
xara-gtk: /usr/share/man/man1/xara.1.gz
xara-gtk: /usr/share/menu/xara-gtk
$

8.23.6. Einsatz von dglob

Analog zu apt-file arbeitet das Werkzeug dglob aus dem Paket debian-goodies [Debian-Paket-debian-goodies]. Die Ausgabe ist ähnlich kompakt wie von apt-file. Der Schalter -f dient dabei zur Ausgabe der Dateien im angefragten Paket, was wir nachfolgend erneut anhand des Pakets xara-gtk illustrieren.

Ergebnis der Recherche zum Paket xara-gtk

$ dglob -f xara-gtk
/etc/xara.config
/etc/xara-gtkrc-2.0
/usr/bin/xara
/usr/share/man/man1/xara.1.gz
/usr/share/menu/xara-gtk
/usr/share/doc/xara-gtk/copyright
/usr/share/doc/xara-gtk/changelog.gz
$

Das Kommando dglob agiert üblicherweise nur auf den bereits installierten Paketen. Mit dem Schalter -a weiten Sie Ihre Recherche auf alle verfügbaren Pakete aus — auch auf diejenigen, die noch nicht installiert sind. Für diesen Schritt setzt dglob auf das Programm grep-aptavail aus dem Paket dctrl-tools [Debian-Paket-dctrl-tools] auf. Nähere Informationen zu dctrl-tools erfahren Sie unter Kapitel 13, Erweiterte Paketklassifikation mit Debtags.

8.24. Nach Muster in einem Paket suchen

Zur Lösung dieser Aufgabe steht Ihnen das Programm dgrep mit seinen drei Varianten degrep, dfgrep und dzgrep aus dem Paket debian-goodies [Debian-Paket-debian-goodies] zur Verfügung. Dieses Shellskript kombiniert das Programm dpkg mit dem Suchwerkzeug grep und dessen Kollegen egrep, fgrep und zgrep miteinander. Je nach Bedarf suchen Sie darüber entweder in den Dateien aller bereits installierten Pakete oder lediglich in einer Auswahl davon. Nutzen Sie dzgrep, werden auch komprimierte Dateien in die Recherche mit einbezogen. Die Auflösung, welche Datei zu einem Paket gehört, erfolgt über das Programm dglob aus dem gleichen Paket.

Aufgrund der Verknüpfung der Programme können Sie zur Recherche nach dem gesuchten Muster auch die meisten der Optionen, die Sie von den grep-Varianten her kennen, einsetzen. Das schließt bspw. reguläre Ausdrücke und die farbige Hervorhebung der Suchtreffer in der Ausgabe mit ein. Ausgenommen sind jedoch Verzeichnisse und das Verfolgen von symbolischen Links.

In der nachfolgenden Ausgabe sehen Sie einen Ausschnitt des Rechercheergebnisses nach dem Muster regular im Paket bash-doc. Dabei beinhaltet die linke Spalte die Datei, in welcher das Muster auftrat, und in der rechten Spalte das Muster samt Kontext drumherum.

Suche nach dem Vorkommen des Musters regular im Paket bash-doc

$ dgrep --color regular bash-doc
/usr/share/doc/bash/examples/scripts.v2/where:    # Find all pattern matches that are executable regular files.
/usr/share/doc/bash/examples/complete/bash_completion:                  # so we can set them before handing off to regular
/usr/share/doc/bash/examples/scripts/bcsh.sh:#  A cshell-style "setenv" command is turned into a regular "set" command.
...
$

Benötigen Sie hingegen nur eine kurze Liste mit den Dateinamen, hilft Ihnen die grep-Option -l (Langfassung --files-with-matches) weiter. Für zusätzliche Optionen werfen Sie bitte einen Blick in die Manpage zu grep. Nachfolgend sehen Sie einen Ausschnitt des Suchergebnisses nach dem Muster regular über alle installierten Pakete ohne Berücksichtig