Die Linux-Paketverwaltung wird ja immer für ihre Effizienz gelobt. Es kommen Updates nur an den notwendigen Stellen und eine Bibliothek ist nur ein einziges Mal installiert und nicht Dutzende Male, wenn unterschiedliche Programme sie benötigen. Das ist nette Theorie, hilft aber nicht, wenn Entwickler sie unterlaufen.
Das openSUSE-Projekt hat für Tumbleweed die nette Tradition, auf der Mailingliste die Changelogs für neue Snapshots zu veröffentlichen. Als Beispiel möchte ich einfach mal auf den Snaptshot 20220620 verweisen. An dem Tag rollte ein Bugfix-Update für Plasma rein. Das bedeutet auf meinem System den Download und die Aktualisierung von ~200 Paketen. Beim Durchsehen des Changelogs fällt aber auf, dass die große Mehrheit der Pakete folgende Zeile im Changelog hat:
No code changes since 5.22.0
Ein Einzelfall? Nein, leider nicht. Insbesondere bei Bugfix-Releases wird bei KDE die große Mehrheit der Programme und Pakete gar nicht angefasst. Wenn ein Plasma-Release nur 5 Bugs behebt, ist das wohl auch logisch. Noch schlimmer ist das bei KDE Gear (ehm. Applications), wo das Verhältnis aktiv gepflegter Pakete zu “mitgeschleppten” Programmen noch ungünstiger ist.
Ich persönlich finde es deshalb auch nicht vorteilhaft, wenn immer mehr Programme unter solche “Dächer” schlüpfen. Das Problem ist bei KDE wegen der absurd hohen Update-Frequenz (bei gleichzeitig nur moderater Entwicklung) der drei Säulen – Plasma, Gear und KDE Framework – besonders ausgeprägt, aber sicher nicht darauf beschränkt. Auch bei einem GNOME-Release oder einem von MATE wird nicht jedes Paket angefasst. Genau so auf Bibliotheken-Ebene, wenn man sich z. B. Qt anschaut.
Bei manchen Programmen wie LibreOffice ist das logisch, weil die Trennung in mehrere Pakete hier künstlich durch die Distributionen herbeigeführt wurde und Updates immer alle Pakete tangieren. Bei anderen Software-Sammlungen sind das aber eigentlich eigenständige Programme ohne Interdependenzen.
Früher haben Linux-Anwender sich über Windows oder macOS lustig gemacht, wenn ein Bugfix-Update mal wieder 1,5 GB groß war. Heute sind wir selbst nicht mehr anders.
Ich finde das ärgerlich. Aus mehreren Gründen:
- Es gibt immer noch Anwender mit schmalen Internetverbindungen oder Volumen-Tarifen. Man ist mit seinem Mobilgerät ja auch mal längere Zeit nicht im heimischen Internet (1 GB im Hotel WLAN zu beziehen ist nicht erstrebenswert).
- Es kostet gerade auf älteren Systemen lange Zeit Ressourcen.
- Es ist ineffizient.
- Es konterkariert die Vorteile der Paketverwaltung
- Es erzeugt die Illusion von Softwarepflege, wo eigentlich nichts passiert.
Etwas überspitzt gesagt: Wenn das so weiter geht können wir auch die Paketverwaltung einstampfen und ähnlich wie bei FreeBSD oder macOS Updates als riesiger “Blob” einmal alle 1-2 Monate ins System bügeln.
Die Frage, die sich mir stellt: Wer ist hier eigentlich in der Pflicht? Müsste Upstream diese ineffiziente Sammlung von Software einstellen oder müssten die Distributoren hier eingreifen? Verkürzt: Habe ich ein KDE- oder habe ich ein openSUSE-Problem?
Nachtrag 01. Juli 2020
Passend zu diesem Artikel ist die Diskussion um die sinnlosen KDE-Updates inzwischen auch auf der openSUSE-Factory Mailingliste angekommen.
Keine Sorge, es gibt doch jetzt FlatSnap oder wie der Kram heißt, da kriegst du alles als Gesamtpaket und es ist so schön klickedibunt…
Das Programm build compare des openSUSE build service prüft ob sich der Inhalt des Paketes seit der letzten Kompilation geändert hat. Das funktioniert nicht, wenn z.B. Timestamps reinkompiliert werden, Versionen gebumpt werden oder wenn jemand einen Changelog ergänzt, der mitausgeliefert wird. Deine Schuldzuweisungen am Ende des Artikels sind unnötig. Koordinierte Veröffentlichungen sind schon ein Zeugnis von Professionalität. Bei Hotfixes oder Sommerloch Veröffentlichungen ist das natürlich unnötiger Ballast. Anders herum gefragt: wie würdest du das Problem lösen?
Ich würde mir weniger Software in solchen Kollektionen wünschen. Ich meine, was für Software landet denn neu bei KDE Gear? Das sind in der Regel nicht die aktiv gepflegten und weiterentwickelten Programme (wie DigiKam oder Krita), sondern jene, die bei KDE unter “Community maintenance” laufen. Warum brauchen die denn 1x pro Monat ein Release und alle 4 Monate ein Feature-Release? Leider ist genau das Gegenteil der Fall und es landen immer mehr Programme unter dem Dach.