Programme sind selten eigenständig. Ein Webserver benötigt SSL-Bibliotheken für HTTPS, Kompression-Libraries für gzip, reguläre Ausdrücke für URL-Rewriting. Diese Abhängigkeiten (Dependencies) müssen installiert sein, bevor das Programm läuft. Die Paketverwaltung löst Abhängigkeiten automatisch - installiert fehlende Bibliotheken, prüft Versions-Kompatibilität, verhindert Konflikte.
Ein nginx-Paket deklariert Abhängigkeiten: libc6, libssl3, libpcre2-8-0. Die Paketverwaltung prüft: Sind diese Pakete installiert? Stimmen die Versionen? Falls nicht, werden Dependencies automatisch mit-installiert. Der Nutzer gibt install nginx ein, das System installiert nginx plus 15 benötigte Bibliotheken.
Bibliotheken und dynamisches Linken
Bibliotheken sind wiederverwendbarer Code. Die C-Standard-Bibliothek (libc) hat grundlegende Funktionen - Strings, Dateizugriff, Speicherverwaltung. OpenSSL bietet Kryptographie. libpng handhabt PNG-Bilder. Programme nutzen diese Bibliotheken statt alles selbst zu implementieren.
Dynamisches Linken lädt Bibliotheken zur Laufzeit. Ein nginx-Binary enthält nur nginx-Code, keine SSL-Implementierung. Beim Start lädt das System /usr/lib/libssl.so.3 - die OpenSSL-Bibliothek. Mehrere Programme können dieselbe Bibliothek nutzen - libssl liegt einmal im RAM, nginx und curl teilen sich diese Instanz.
Statisches Linken kopiert Bibliotheks-Code ins Binary. Das resultierende Programm ist größer, braucht aber keine externen Abhängigkeiten. Ein statisch gelinktes nginx hat SSL-Code eingebaut, läuft ohne libssl-Installation. Distributionen bevorzugen dynamisches Linken - kleinere Binaries, geteilte Updates.
Bibliotheks-Versionen sind in Dateinamen kodiert: libssl.so.3 ist OpenSSL Version 3.x. libssl.so.1.1 war Version 1.1.x. Programme linken gegen spezifische Versionen - ein für libssl.so.3 kompiliertes nginx findet libssl.so.1.1 nicht kompatibel. Die Paketverwaltung garantiert: Wenn nginx libssl.so.3 braucht, ist libssl3 installiert.
Abhängigkeits-Graphen und Transitiv-Closure
Abhängigkeiten bilden gerichtete Graphen. Paket A hängt von B ab, B von C und D. Das System berechnet den transitiven Abschluss: Installiert A, müssen B, C, D mit-installiert werden. Die Reihenfolge ist wichtig - zuerst C und D, dann B, zuletzt A.
Ein komplexer Desktop mit Gnome hat tausende Abhängigkeiten. Das gnome-shell-Paket braucht grafische Bibliotheken, die brauchen Treiber, die brauchen Kernel-Module. Der Abhängigkeits-Graph hat mehrere Ebenen Tiefe. Die Paketverwaltung berechnet die komplette Installationsreihenfolge automatisch.
Zyklische Abhängigkeiten sind problematisch. Paket A braucht B, B braucht A - was wird zuerst installiert? Moderne Paketverwaltungen lösen bestimmte Zyklen durch split-Pakete oder pre-depends-Mechanismen. Debian verbietet echte Zyklen in Dependencies, erlaubt sie nur für Empfehlungen.
Die Berechnung wird bei großen Systemen komplex. Ein Desktop mit 2000 Paketen hat zehntausende Abhängigkeits-Beziehungen. Die Paketverwaltung cached bereits aufgelöste Graphen - nur bei Updates werden betroffene Teile neu berechnet. Ein nginx-Update löst Neuberechnung für nginx und direkte Abhängigkeiten aus, nicht für das gesamte System.
Versions-Constraints und Kompatibilität
Abhängigkeiten haben Versions-Anforderungen. nginx braucht libssl3 (>= 3.0.0) - Version 3.0.0 oder neuer. libc6 (>= 2.34) bedeutet “glibc ab Version 2.34”. Diese Constraints garantieren API-Kompatibilität - nginx nutzt Funktionen, die erst ab libssl 3.0 existieren.
Obere Grenzen sind seltener: libfoo (<< 2.0) bedeutet “libfoo älter als 2.0”. Ein Paket, das gegen libfoo 1.x kompiliert wurde, ist mit 2.x inkompatibel. Die Bibliothek hat ihre ABI (Application Binary Interface) gebrochen - Funktions-Signaturen geändert, Structs umstrukturiert.
Semantic Versioning hilft: Major-Version-Sprünge (1.x → 2.x) brechen Kompatibilität, Minor-Updates (2.1 → 2.2) bleiben kompatibel. Bibliotheken folgen diesem Prinzip idealerweise. Die Realität ist komplexer - manche Projekte brechen ABI in Minor-Updates, andere garantieren Kompatibilität über Major-Versionen.
Die Paketverwaltung prüft alle Constraints. Installation von Paket A mit libfoo (>= 2.0) scheitert, wenn nur libfoo 1.9 installiert ist. Das System bietet Upgrade von libfoo an - aktualisiert auf 2.0, installiert dann A. Oder es zeigt Konflikt: “libfoo 2.0 würde Paket B brechen, das libfoo (« 2.0) braucht”.
Konflikte und Alternativen
Konflikte deklarieren Unverträglichkeit. Ein Paket definiert Conflicts: apache2 - es kann nicht parallel zu apache2 laufen. Beide Webserver wollen Port 80 binden, nur einer kann gewinnen. Die Paketverwaltung verhindert Installation beider gleichzeitig.
Replacement erlaubt Substitution. Ein Paket deklariert Provides: mail-transport-agent - es erfüllt die Rolle eines MTAs. Andere Pakete können Depends: mail-transport-agent fordern. Postfix, Exim, Sendmail - alle providen mail-transport-agent. Der Nutzer wählt einen, Dependencies sind erfüllt.
Alternatives-Systeme verwalten Symlinks. Mehrere Programme können /usr/bin/editor sein - vim, nano, emacs. Das Alternatives-System hält Prioritäten, der Administrator wählt. Pakete hängen von /usr/bin/editor ab, egal welcher Editor tatsächlich installiert ist.
Virtual Packages sind reine Provides-Mechanismen. libc-dev ist ein Virtual Package - libc6-dev und libc-dev-bin providen es. Dependencies auf libc-dev werden durch beliebigen Provider erfüllt. Das abstrahiert von konkreten Implementierungen.
Update-Strategien: Rolling vs. Stable
Rolling Release aktualisiert kontinuierlich. Neue Software-Versionen erscheinen täglich, Updates fließen direkt zu Nutzern. Arch rollt täglich 50-200 Paket-Updates. Dependencies ändern sich - ein Update von libssl 3.0 auf 3.1 löst Rebuilds aller abhängigen Pakete aus.
Die Abhängigkeits-Auflösung ist dynamisch. Ein Update kann hunderte Pakete betreffen - neue libfoo-Version braucht neue libbar, die braucht aktualisiertes libbaz. Die Paketverwaltung berechnet Upgrade-Pfad: “Diese 247 Pakete werden aktualisiert”. Der Nutzer bestätigt, System führt Update durch.
Stable Release friert Dependencies ein. Debian Bookworm hat libssl 3.0.11 - diese Version bleibt für die gesamte Bookworm-Lebensdauer (2-3 Jahre). Nur Sicherheits-Patches werden eingepflegt - 3.0.11 → 3.0.12, nie 3.0 → 3.1. Abhängigkeits-Graphen bleiben stabil, keine Überraschungen.
Das verhindert Dependency-Hell. Alte Software läuft weiter, Abhängigkeiten brechen nicht. Der Preis: Alte Versionen, fehlende Features. Ein Entwickler braucht neue Library-Features - Stable hat diese nicht. Backports oder selbst kompilieren sind Workarounds.
Partial Upgrades und Mixed Sources
Gemischte Repositories (Stable + Testing) sind riskant. Debian Stable mit einzelnen Testing-Paketen kann Abhängigkeits-Chaos verursachen. Ein Testing-Paket braucht neuere libfoo, die zieht weitere Testing-Dependencies, plötzlich ist halbes System auf Testing.
APT Pinning (Debian) oder Package Masks (Gentoo) steuern dies. Der Admin definiert: “nginx aus Testing, alles andere aus Stable”. Die Paketverwaltung respektiert Präferenzen, löst Abhängigkeiten korrekt. PostgreSQL 16 aus Testing installiert automatisch neue libpq aus Testing, aber base-system bleibt Stable.
Backports sind sicherere Alternative. Debian Backports kompiliert Testing-Software gegen Stable-Libraries. Ein nginx-Backport läuft mit Stable-libssl, nutzt keine Testing-Dependencies. Weniger Risiko, aber auch weniger aktuell - manche Features fehlen ohne neueste Libraries.
Flatpak und Snap umgehen System-Dependencies komplett. Jede App bringt eigene Library-Versionen mit, isoliert in Container. Das löst Dependency-Hell, kostet Disk-Space und RAM - jede App hat eigene libssl-Kopie. System-Integration ist schlechter - keine gemeinsamen Updates, doppelte Bibliotheken im RAM.
Dependency-Hell und Lösungsstrategien
Dependency-Hell entsteht bei inkompatiblen Anforderungen. Paket A braucht libfoo >= 2.0, Paket B braucht libfoo <= 1.9. Beide gleichzeitig zu installieren ist unmöglich. Die Paketverwaltung meldet Konflikt, verweigert Installation.
Die Lösungen variieren:
Library-Parallel-Installation: libfoo1 und libfoo2 koexistieren. Paket A linkt gegen libfoo2.so, B gegen libfoo1.so. Beide Versionen sind installiert, keine Konflikte. Der Disk-Space-Overhead ist akzeptabel - Libraries sind klein.
ABI-Bumps in Paketnamen: libssl1.1 und libssl3 sind separate Pakete. Ein System-Upgrade hält beide Versionen für Übergangszeit. Alte Software läuft mit libssl1.1, neue mit libssl3. Nach Migration aller Software wird libssl1.1 entfernt.
Rebuild aller abhängigen Pakete: Gentoo-Ansatz. libfoo-Update triggert Rebuilds aller Pakete, die von libfoo abhängen. Nach Rebuild-Welle ist System konsistent - alles linkt gegen neue libfoo. Aufwendig, aber sauber.
Containers und Isolation: Docker-Ansatz. Jeder Container hat eigene Library-Versionen, keine System-Dependencies. Service A mit libfoo 1.9 in Container, Service B mit libfoo 2.0 in separatem Container. Problem gelöst, aber höherer Resource-Verbrauch.
Automatische vs. manuelle Auflösung
Die Paketverwaltung berechnet Abhängigkeiten automatisch. Der Nutzer sagt “installiere A”, System berechnet Dependencies, installiert A plus 20 benötigte Pakete. Kein manuelles Dependency-Management nötig. Das funktioniert für 99% der Fälle.
Seltene Konflikte erfordern manuellen Eingriff. Das System findet keine automatische Lösung - mehrere Pakete fordern inkompatible Versionen. Der Admin entscheidet: Welches Paket ist wichtiger? Kann eines entfernt werden? Gibt es alternative Provides?
Solver-Failure-Messages sind oft kryptisch. “The following packages have unmet dependencies: A depends on B (>= 2.0) but 1.9 is to be installed”. Die Ursache liegt tiefer - warum wird 1.9 installiert? Weil Paket C das Paket B in Version <= 1.9 fordert. Der Admin muss den kompletten Dependency-Graph verstehen.
Dry-Run-Modi helfen: “Was würde passieren bei Installation von A?”. Die Paketverwaltung simuliert, zeigt Auswirkungen. “Diese 47 Pakete würden aktualisiert, diese 5 entfernt”. Der Admin sieht Konsequenzen vor echter Änderung, kann abbrechen oder Alternativen suchen.
Empfohlene und optionale Abhängigkeiten
Hard Dependencies sind zwingend. Paket A funktioniert nicht ohne B - Installation ohne B ist unmöglich. Die Paketverwaltung installiert B automatisch, keine Diskussion.
Recommended Dependencies sind optional aber empfohlen. Paket A funktioniert ohne B, aber mit eingeschränkten Features. nginx ohne geoip-Bibliothek läuft, hat aber keine Geo-Lokalisierung. Debian installiert Recommends standardmäßig, erlaubt Deaktivierung.
Suggested Dependencies sind reine Hinweise. “nginx suggests monitoring-tool” - nginx läuft vollständig ohne, aber monitoring-tool wäre nützlich. Die Paketverwaltung ignoriert Suggests bei Installation, zeigt sie nur als Information.
Build Dependencies sind temporär. Zum Kompilieren von Paket A werden B, C, D benötigt (Compiler, Header-Files). Nach Build können diese entfernt werden - das resultierende Binary läuft ohne Build-Tools. Quellcode-basierte Systeme unterscheiden Build- und Runtime-Dependencies explizit.
Orphaned Packages und Autoremove
Verwaiste Pakete wurden als Dependencies installiert, sind nicht mehr nötig. nginx wurde entfernt, libssl ist jetzt orphaned - kein anderes Paket braucht sie. Die Paketverwaltung markiert solche Pakete, bietet Entfernung an.
Autoremove-Mechanismen säubern automatisch. Nach nginx-Entfernung zeigt die Paketverwaltung: “Die folgenden Pakete werden nicht mehr benötigt und können entfernt werden: libssl3, libpcre2-8-0”. Ein Befehl löscht alle Orphans, räumt System auf.
Manche Pakete sind explizit installiert vs. automatisch als Dependency. Ein apt install libssl3 markiert libssl3 als explizit gewünscht - Autoremove entfernt sie nicht. Eine automatische Installation als nginx-Dependency markiert sie als Kandidat für Autoremove nach nginx-Entfernung.
Das reduziert Disk-Space und Komplexität. Alte Dependencies verschwinden automatisch, das System bleibt sauber. Der Nachteil: Versehentliches Entfernen von Libraries, die tatsächlich noch benötigt werden (von selbst kompilierter Software oder externen Programmen).
Update-Abfolge und Bruchpunkte
System-Updates haben kritische Reihenfolgen. Basis-Libraries zuerst, dann darauf aufbauende Pakete. Ein libc-Update erfolgt vor allen anderen Paketen - libc ist fundamentalste Dependency. Nach libc-Update folgen Core-Tools, dann Userland-Software.
Ein unterbrochenes Update kann System brechen. Libc wurde aktualisiert, aber nicht alle abhängigen Programme. Diese Programme linken gegen alte libc-Version, die ABI hat sich geändert - Programme crashen. Paketverwaltungen verwenden Transaktionen - entweder alles erfolgreich oder nichts.
Post-Installation-Scripts konfigurieren Services. Nach nginx-Installation läuft postinst - registriert Systemd-Service, startet nginx. Diese Scripts können fehlschlagen - Konfigurationsfehler, Port bereits belegt. Die Paketverwaltung loggt Fehler, aber Paket bleibt “installiert aber nicht konfiguriert”.
Rollback ist schwierig. Ein fehlgeschlagenes Update lässt System teilweise aktualisiert. Downgrade einzelner Pakete ist möglich, aber riskant - alte und neue Versionen mit Abhängigkeits-Mismatch. Snapshots (Dateisystem-Level) oder VM-Backups sind verlässlicher für Rollback.
Zusammenfassung
Abhängigkeitsauflösung automatisiert Library-Management. Programme deklarieren Dependencies, Paketverwaltungen berechnen Installationsreihenfolge, garantieren Kompatibilität. Versions-Constraints, Konflikte, Alternatives ermöglichen komplexe Szenarien.
Rolling Release aktualisiert dynamisch mit sich ändernden Dependencies. Stable Release friert Abhängigkeits-Graphen ein für Stabilität. Beide Ansätze haben Berechtigung - unterschiedliche Ziele, unterschiedliche Kompromisse.
Die Paketverwaltungs-Konzepte gelten distributionsübergreifend. APT, pacman, pkg_add - alle lösen Abhängigkeiten mit ähnlichen Algorithmen. Die nächsten Schritte sind distributions-spezifische Artikel zu APT, pacman und OpenBSD Packages.
Verwendete Software und Versionen
Diese Betrachtung bezieht sich auf:
- Dependency-Konzepte: Universal für alle Unix-Systeme
- Beispiele: Debian, Arch Linux, Gentoo, OpenBSD
- Kontext: Distributionsübergreifende Grundlagen
- Stand: Oktober 2025
Weiterführende Schritte:
- Repository-Systeme →
- Binär-Pakete vs. Quellcode →
- Debian Grundlagen (geplant)
