Paketabhängigkeiten – Die Nachteile
Als einer der großen Vorteile von Linux-Distributionen wird oft die Paketverwaltung genannt. Man muss sich nicht mehr mühsam irgendwelche Software im Netz von Drittanbietern suchen, sondern erhält eigentlich alles, was man braucht, aus einem großen Pakettopf (Repository), dessen Inhalt dazu noch getestet ist. Ein weiterer Vorteil davon ist auch, dass sich die Programme darüber aktuell halten lassen. Man muss also nicht mehr manuell wie in anderen Betriebssystem das Netz nach Updates durchgrasen (falls die Software das nicht bereits alleine macht), sondern erhält hier auch alles frei Haus.
Schlecht ist es natürlich, wenn man mal Software benötigt, die nicht im Repository vorhanden ist. Sei es, weil man eine neuere Version eines Programmes benötigt (z.B. wegen nerviger Bugs in der im Repository vorhandenen Version) oder ein Programm keinen Paketverwalter (Maintainer) gefunden hat, sodass es gar nicht im Repository zu finden ist. Das eigenständige Bauen der Pakete kann da schon ein Kampf gegen diverse Abhängigkeiten sein.
Wieso Abhängigkeiten? Auch das wird oft als Vorteil der Linux-Pakete gepriesen. Ein Paket enthält nur das, was es selbst mitbringt, nicht mehr, was es benötigt. Wenn man also beispielsweise eine GUI in Qt (einem GUI-Framwork von Nokia/Trolltech) schreibt, muss man nicht Qt selbst mit ausliefern. Da man es aber zur Benutzung der GUI braucht, muss jeder Qt auf seinem Rechner haben. In der Regel funktioniert dieses Modell sehr gut, da die Linux-Distributionen meist Repositorys mit ähnlicher Paketauswahl haben.
Was daraus als Vorteil abgeleitet wird: Wenn in einem Paket X ein Fehler auftritt und zwanzig andere Pakete (Paket A bis Paket T) dieses benutzen, muss dennoch nur Paket X aktualisiert werden. Würden die Pakete A bis T den Inhalt von X immer selbst mitliefern, müssten Pakete A bis T ausgebessert und aktualisiert werden.
So weit die Theorie, in der Praxis funktioniert das nämlich aus dem einfachen Grund der Paketabhängigkeiten nicht. Die Pakete A bis T oben hängen nämlich nicht nur von Paket X ab, sondern von Paket X in der Version Y. Wenn der Fehler ausgebessert wird, entsteht ein Paket X in der Version Y', man könnte es auch X' nennen. Die Pakete A bis T hängen nach wie vor vom fehlerhaften Paket X ab. Um denen also klar zu machen, dass sie X' nehmen soll, muss man sie anpassen. Es entstehen neue Pakete A' bis T'.
Das Ende vom Lied? Tritt ein Fehler in einem Paket auf, von dessen Version (!) viele andere Pakete abhängig sind, müssen alle diese zusammen aktualisiert werden.
Schön zu sehen, war dies an einem Qt4-Fehler letzte Woche, der für Abstürze in Webkit-Browsern sorgte. Behoben wurde der Fehler (vermutlich) in dem Paket libqtcore4. Das Paket hat nur 1 MB und wäre schön leicht herunterzuladen. Mit der Fehlerbehebung hat sich die Versionsnummer aber ebenso von 4:4.6.2-0ubuntu5 auf 4:4.6.2-0ubuntu5.1 geändert. Das führte dazu, dass so gut wie alle anderen Qt-Pakete, die von der Core-Bibliothek abhängen (21 Stück an der Zahl), ebenfalls aktualisiert werden mussten. Das resultierte dann im Endeffekt zu einem Download von 22,7 MB. Und das nur, weil eine Zeile Code (übertrieben ausgedrückt, ich weiß nicht, wie viel Code geändert wurde) angepasst werden musste.
Natürlich ist die Downloadgröße ein Problem der Paketverwaltung. Gäbe es in Ubutnu inkrementelle Updates (es wird aus einem Paket nur neu heruntergeladen, was sich wirklich geändert hat), bestünde das Problem nicht. Es würde in den abhängigen Paketen einfach nur die Datei ausgetauscht werden, in der steht, dass das Paket X mit der neuen Version Y' benutzt werden sollte. Aber selbst dieses inkrementelle Update beseitigt nicht die Anzahl der anzupassenden Pakete.
Mit dem Beitrag will ich klarmachen, dass auch Schatten ist, wo es Licht gibt. Für mich hat die Paketverwaltung immense Vorteile. Und da ich Erfahrung im Kompilieren habe, ist auch die Installation neuerer Software selten ein Problem (auf meinem Heimrechner; auf Rechnern, auf denen ich keine Root-Rechte besitze und somit keine benötigten Abhängigkeiten nachinstallieren kann, fällt das meist flach). Dennoch wandelt sich der Vorteil des Änderns eines Fehlers in einem Paket manchmal auch zum Nachteil.
Ein geändertes Paket zieht 21 weitere Anpassungen nach sich.