Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03495.jsonl.gz/1309

Ubuntu-Flavours verzichten auf Flatpaks
Do, 23. Februar 2023, Ralf Hersel
Wie Canonical auf dem Ubuntu-Discourse-Kanal vorgestern mitteilte, hat man sich zusammen mit den Ubuntu-Flavors entschieden, zukünftig das Paketformat Flatpak nicht mehr standardmässig zu unterstützen. Die Begründung für diesen Schritt ist lang und nachvollziehbar. Ich möchte diese herausdestillieren und anschliessend meine Meinung zu dieser Entscheidung mitteilen.
Da die Begründung lang und salbungsvoll ist, gebe ich hier die Essenz wieder:
Die Ubuntu-Flavours werden als Ökosystem von Linux-Variationen bezeichnet, die Auswahl und Vielfalt fördern. Sie bauen auf einem gemeinsamen Kern auf, bei dem sofort klar ist, dass man Ubuntu verwendet, und bieten darüber hinaus ihre eigenen Feinheiten.
Ein solcher grundlegender Aspekt einer jeden Linux-Distribution ist die Paketierung. Die grossen Distributionen haben alle ihre eigenen Entscheidungen getroffen, um Konsistenz in ihrem Ökosystem zu gewährleisten. Ubuntu baut auf einer Grundlage von Deb-Paketen auf und glaubt an die Vorteile von Snaps. Das Ziel ist es, eine sichere und einfache Benutzererfahrung zu bieten und die Wartung von Paketen zu vereinfachen.
In einer idealen Welt gibt es für die Benutzer nur eine einzige Möglichkeit, Software zu installieren. Dabei kann man erwarten, dass dieser Mechanismus von der Gemeinschaft unterstützt wird und die meiste Aufmerksamkeit erhält, wenn es um die Lösung von Problemen in Softwarepaketen geht. Wenn eine neue Paketierungstechnologie standardmässig bereitgestellt wird, wird erwartet, dass die Distribution die Community unterstützt und sich an der Entwicklung beteiligt, um Probleme zu lösen. Dies führt zu einer Fragmentierung, anstatt sich auf die Verbesserung der für die Distribution ausgewählten Technologien zu konzentrieren.
Ubuntu und seine Varianten betrachten Debs und Snaps als ihren Standard. Die Benutzer haben die freie Wahl, ihre Software aus anderen Quellen zu beziehen, einschliesslich Flatpak. Eine Möglichkeit, diese Alternativen zu installieren, ist und wird auch weiterhin zur Verfügung stehen.
Das Flatpak-Format sowie die Pakete zur Integration von Flatpak in das jeweilige Software-Center werden in der nächsten, im April 2023 erscheinenden Version, Lunar Lobster, nicht mehr standardmässig installiert. Nutzer, die bisher Flatpak verwendet haben, sind vom Upgrade nicht betroffen. Diejenigen, die noch nicht mit Flatpak gearbeitet haben, werden Software aus den Ubuntu-Repositories und dem Snap Store 11 erhalten.
Meine Meinung
Ich halte die vorgebrachten Argumente für gut und richtig. In den alten Zeiten haben wir GNU/Linux-Distributionen dafür gelobt, dass sie die Repository-basierte Softwarebereitstellung hatten, lange bevor andere Betriebssystem-Hersteller auf diese Idee kamen. Zwar gab und gibt es die nativen Paketformate, die zu einem Distributions-Stamm gehören (deb, rpm, usw.); man hatte jedoch nur eine Paketquelle für die Distro seiner Wahl zur Verfügung. Das war die ideale Welt, die Canonical weiter oben beschreibt.
Mit dem Aufkommen der Container-Formate (Flatpak, Snap, AppImage) sollte primär eine Herausforderung für Entwickler:innen gelöst werden, nämlich die Plattform-übergreifende Erzeugung von Paketen. Dieses Ziel hätte erreicht werden können, wenn man sich auf ein Format geeinigt und die nativen Formate damit abgelöst hätte.
Bisher wurde eher das Gegenteil erreicht. Es gibt immer noch die "alten" Formate und drei der neuen. Somit werden immer noch DEBs, RPMs, Arch-Pakete, sowie Flatpaks, AppImages und Snaps gebaut. Der Turmbau von Babel schreitet voran. Hoffentlich befinden wir uns in einer Konsolidierungsphase, an deren Ende ein Paketformat herauskommen wird. Ich schätze die Situation so ein, dass Flatpak sich als Standardformat durchsetzen wird.
Aus der Sicht von Anwenderinnen und Anwendern hat sich auch nichts verbessert. Während man bisher einen Paketmanager hatte, der die gesamte Softwarepalette in einem Format anbot (z.B.: Apt für DEB-Pakete), findet der User heute eine Vielzahl von Formaten im Paketmanager der Distribution. Hier ein Beispiel aus Pamac, dem grafischen Paketmanager von Manjaro:
Dort seht ihr Inkscape als Arch-Paket, Flatpak und aus dem AUR (Arch User Repository). Hätte ich Snap eingeschaltet, würdet ihr auch dieses sehen. Für die Endanwenderin ist diese Situation nicht optimal. Welches Paket soll man installieren? Die meisten Anwender sind mit dieser Entscheidung überfordert. Für Fortgeschrittene muss das kein Nachteil sein, weil nicht alle Pakete gleich gut funktionieren. Ich führe eine Liste von Anwendungen, in der ich notiere, welches Paketformat am besten läuft (ja, Paket ist nicht gleich Paket).
Auch dieses Beispiel zeigt, dass die Entscheidung von Canonical und den Ubuntu-Flavours richtig ist. Die Anwenderin möchte für eine Applikation gerne ein Paket angeboten bekommen, statt vier verschiedene. Ein gut gepflegtes Software-Repository, welches von der Distribution optimal unterstützt wird, ist besser als vier schlecht gepflegte.
Somit haben die Ubuntus alles richtig gemacht, bis auf einen entscheidenden Fehler. Sie hätten das Snap-Format in die Wüste schicken und stattdessen Flatpak zum Standard erklären sollen. Warum? Weil sich die Mehrheit der Entwickler-Community bereits für das Flatpak-Format entschieden hat und die Mehrheit der Distributionen dieses Format bevorzugen. Ausserdem möchte niemand ein proprietäres Backend haben. Die Entscheidung von Canonical führt zum Gegenteil des Wünschenswerten. Statt das Paket-Babel einzufrieden, wird nun die Paket-Spaltung zementiert.
Auf lange Zeit werden wir ein unnötiges Nebeneinander von Snaps und Flatpak sehen. AppImages spielen keine grosse Rolle und die nativen Formate werden langfristig verschwinden. Meiner Meinung nach hat sich Canonical erneut für die Spaltung der Community entschieden. Hätte Mark Shuttleworth seine Snaps aufgegeben und sich für Flatpaks entschieden, hätte die Freie Software Welt einen grossen Schritt vorwärtsgemacht.
Quelle: https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defaults/34061?u=d0od