Bild von harshahars via Pixabay / Lizenz: CC0 Creative Commons
Snaps, Flatpaks und andere vergleichbare Systeme sind momentan eine der wenigen spannenden Entwicklungen am Linux-Desktop. Die Entwickler aus dem Umfeld von Canonical und RedHat wollen damit viele Probleme angehen: Der hohe Aufwand für Firmen Pakete für alle möglichen Distributionen und Versionen zur Verfügung zu stellen, der sinkende Anteil an Maintainern für die bisherigen Paketsammlungen der Distributionen und vieles weiteres. Damit stellt man den Heiligen Gral der Linuxwelt in Frage: Die Paketverwaltung.
Grundsätzlich sind tiefgreifende Änderungen im Linux-Desktop immer schwerer durchzusetzen. Meiner Meinung nach liegt das auch strukturell an der Zusammensetzung der Linux-Community (siehe: Nabelschau und Phantomschmerzen – die Linux Community auf dem Weg in die Bedeutungslosigkeit?). Richtig schön sieht man das an der neuen Auseinandersetzung um die neuen Paketformate vs. die alten Lösungen. In den Foren ist die Empörung allgegenwärtig, Aussagen wie “Braucht kein Mensch”, “zu aufgeblasen”, “Wer soll, die integrierten Bibliotheken warten?” und “Das bisherige System funktioniert doch, wozu braucht es was neues?” decken wohl die meisten Reaktionen ab. Der Linux-Desktop ist bekanntermaßen perfekt, Änderungen unerwünscht.
Doch funktioniert das alte System wirklich so gut oder wird nicht nur der Status quo verherrlicht? Paketverwaltungen waren prinzipiell einer der großen Vorteile von Linux gegenüber alternativen Betriebssystemen. Anstatt Betriebssystem und Programme unabhängig davon über dutzende Updateroutinen zu aktualisieren, hebt man das gesamte System mit einem Befehl auf einen aktuellen Stand. Andere Betriebssysteme haben aber nachgezogen und mit den heutigen App Stores erreicht man einen ähnlichen Effekt bei macOS und Windows. Sofern man natürlich nicht alles manuell an diesen Programmsammlungen vorbei installiert, aber das gilt auch für die Paketverwaltung.
Der zweite Vorteil ist natürlich, dass eine Bibliothek exakt ein mal installiert haben muss und dann jedem Programm zur Verfügung steht. Das spart Speicherplatz, aber der ist inzwischen selbst in SSD-Form preiswert und reichlich vorhanden. Zudem kann das auch problematisch sein, wenn Programme unterschiedliche Versionen einer Bibliothek benötigen.
Das System Paketverwaltung hat in den letzten Jahren aber auch einige Exzesse hinter sich. Insbesondere Debian-basierte Distributionen haben die Pakete förmlich atomisiert. Jedes Programm wird in dutzende, von einander abhängige, Pakete zerlegt – ein Trend der mit jeder Version extremer wurde. Ein KDE-Desktop in Debian Lenny hatte noch deutlich weniger als 700 Pakete, heute hat man leicht weit über tausend installierte Pakete. Das liegt nicht nur daran, dass Desktopumgebungen an Umfang gewonnen haben. Manuelle Aktualisierungen sind dadurch kaum noch möglich, weil man ziemlich schnell in einer Abhängigkeitshölle landet.
Dies führt unweigerlich zu einem hohen Einsatz von Fremdquellen, da nur diese eine partielle Aktualisierung von Programmen ermöglichten. Fremdquellen sind jedoch ein riesiges Sicherheitsproblem. Ohne ein durchdachtes Priorisierungssystem (das gegenwärtig, abgesehen von YaST in openSUSE, keine grafische Oberfläche unterstützt) sind Fremdquellen nämlich dazu in der Lage Systempakete zu überschreiben. Dies kann auch nachträglich geschehen, wenn der Maintainer der Fremdquelle diese Pakete der Quelle hinzufügt. Dieses Sicherheitsrisiko ist viel realer als die abstrakte Gefahr von irgendwelchen nicht ganz aktuellen Bibliotheken in Snaps und Flatpaks.
Viele Vorteile von klassischen Paketverwaltungen existieren zudem real gar nicht mehr. Ein klassisches Argument lautet, dass eine Sicherheitslücke ja potenziell nur in einem Paket gepatcht werden muss und nur dieses aktualisiert wird. Real ziehen moderne Build-Prozesse immer die Versionsnummern von ganzen Paketgruppen hoch. Ob Qt dann z.B. in zig Unterpakete gesplittet ist, kann dem Anwender eigentlich egal sein, aktualisieren muss er meistens eh alle Pakete der Programmgruppe. Deltapakete haben das Problem der großen Downloads auch schon lange behoben, werden jedoch nur von RPM-basierten Distributionen verwendet.
Weiterhin sind die Synergieeffekte doch eher überschaubar. Nimmt man zum Beispiel LibreOffice: Das Paket ist bei den meisten Distributionen vorbildhaft zerlegt in seine Einzelteile. Die Bestandteile Calc, Writer & Co, die man abwählen kann, sind jedoch vergleichsweise klein. Der dicke Brocken ist LibreOffice-Core und den braucht man immer. Andere Bibliotheken wie uno braucht man nur für LibreOffice. Ihre Ausgliederung ist also ohne Mehrwert für den Benutzer.
Die Beschränkungen der klassischen Paketverwaltung, die fast zwangsläufig zum Antagonismus Rolling Release vs. Stabile Distribution führt, ist zudem ein großes Problem für den Linux-Desktop. Viele langjährige Nutzer merken das nicht mehr, weil sie es nichts anders kennen, aber es ist eben nicht normal, dass man entweder das komplette Betriebssystem permanent aktualisieren muss oder sonst komplett auf alten Versionen sitzen bleibt
Die neuen Paketformate haben natürlich auch ihre Probleme. Es wird sich zeigen müssen, ob sie langfristig gepflegt werden oder letztlich zu viele veraltete Bibliotheken mit Sicherheitslücken aufweisen. Für einen wirklichen Mehrwert muss sich zudem noch klären, ob sich Snaps oder Flatpaks durchsetzen. Erfahrungsgemäß muss Canonical irgendwann seine eigene Lösung einstampfen.
Der Mehrwert ist aber offensichtlich. Die Pakete von z. B. Flathub laufen auf allen Distributionen, die Flatspaks unterstützen (eigentlich alle außer Ubuntu) und müssen nicht permanent für jede Version neu gebaut werden.
Flatpaks & Co werden natürlich die Paketverwaltung nicht komplett ersetzen. Solche Bestrebungen wurden vom Fedora-Team nicht umsonst aufgegeben. Für das eigentliche Basissystem und den Desktop ist die Paketverwaltung nach wie vor bestens geeignet. Es gibt aber keinen Grund klassische Endanwenderprogramme genau so wie den Kernel zu verwalten. Außer natürlich man ist der Meinung, der Linux-Desktop wäre perfekt und ausentwickelt.
