Die Paketformate Flatpak, Snap und AppImage funktionieren zwar distributionsübergreifend, bringen jedoch auch spezifische Nachteile mit sich.

Für den Bezug von Programmen und anderen Software-Komponenten bieten Distributionen komfortable Werkzeuge an: Mithilfe einer Paketverwaltung wie Apt oder Yum können Anwender nach Software suchen und in Form von Paketen herunterladen sowie installieren.

Klassische Formate für Pakete stellen pro Software ein Paket bereit, das die gewünschte Software und einige Metadaten enthält. Letztere umfassen Informationen wie den Namen, die Version und den Autor der Software sowie Abhängigkeiten zu anderer Software. Die Paketverwaltung liest die Metadaten ein und löst alle Abhängigkeiten sorgfältig auf, sodass die Installation eines Pakets unter Umständen einen Rattenschwanz an zusätzlichen Downloads und Installationen nach sich zieht.

Als Ergebnis erhalten Sie jedoch einen Zustand, in dem das gewünschte Programm dank erfüllter Abhängigkeiten lauffähig auf der Platte liegt. Bemerkenswert ist zudem, dass die Installation von anderer Software mit gleichen Abhängigkeiten wesentlich schneller vonstattengeht, da die benötigten Pakete ja bereits lokal bereitstehen. Mehrere Pakete dürfen also auf dieselben Komponenten zurückgreifen, etwa auf OpenSSL.

Oldtimer

Es war nicht zuletzt dieses Konzept der Modularität von RPM, DEB und anderen Paketformaten, das zum Siegeszug von Linux beitrug: Der Anwender musste meist nicht, wie etwa unter Windows, erst umständlich im Internet nach Bezugsquellen für eine Software suchen und brauchte deren Vertrauenswürdigkeit nicht zu überprüfen.

Ein großer Teil der heute weit verbreiteten Formate entstand allerdings Mitte der 1990er-Jahre, als die Anforderungen an Workstations und Server noch andere waren als heute. So verwundert es nicht, dass die Grundideen hinter diesen Formaten aus heutiger Sicht einige Nachteile mit sich bringen.

So gelingt es bei den meisten klassischen Paketformaten per Definition nicht, unterschiedliche Versionen der gleichen Software zu installieren und zwischen diesen hin- und herzuwechseln. Es gibt vereinzelt (durchaus erfolgreiche) Ansätze innerhalb der klassischen Mechanismen, die hier Abhilfe schaffen sollen. Allerdings handelt es sich dabei um zusätzliche Funktionen, die nicht im Format der Pakete selbst verankert sind und damit mehr Verwaltungsaufwand verursachen.

Ähnliches gilt beim Auflösen von Abhängigkeiten: Benötigen etwa zwei Web-Applikationen auf einem Server unterschiedliche PHP-Versionen, kommt es bei der Installation vermutlich zu einem Konflikt. Das erzwingt dann eine Entscheidung: Lohnt es, eine der Applikationen auszulagern oder gar die Pakete so von Hand anzupassen und gegebenenfalls neu zu bauen, um die Abhängigkeiten sauber zu erfüllen? Beide Wege klingen nicht sehr verlockend und setzen voraus, dass sich Administratoren zusätzliche Zeit nehmen. Das gilt besonders dann, wenn für die eingesetzten Pakete Updates in den Paketquellen landen.

Das Handhaben neuer Versionen gestaltet sich oft etwas umständlich: Steht eine neue Version eines bereits installierten Pakets bereit, lädt der Paketmanager das gesamte Archiv neu herunter. Einige Formate kappen diesen oft nicht notwendigen Overhead, indem sie nur die Differenz zwischen den zwei Versionen herunterladen. Diese Vorgehensweise ist jedoch nicht weit verbreitet und keinesfalls in allen Distributionen Standard.

Besonders beim Verwalten größerer Umgebungen wirkt sich negativ aus, dass die klassischen Pakete kaum Schnittstellen zur Kommunikation von außen bieten. In der Praxis bedeutet das für Systeme wie Puppet oder Ansible, dass ein Paket während der Installation zuerst die Konfiguration des Betreuers ablegt. Danach muss der Anwender diese überschreiben oder zumindest anpassen, damit die aktualisierte Applikation mit den gewünschten Parametern läuft.

Nicht nur aus Benutzersicht, auch aus der Perspektive von Software-Herstellern stellen die klassischen Formate ein gewisses Ärgernis dar: Sie müssen ihre Software für viele verschiedenen Distributionen bauen und aktuell halten. Wer viele Plattformen unterstützen möchte, baut also für Debian, Ubuntu, CentOS, Red Hat, Fedora, OpenSuse, Arch Linux – die Liste lässt sich beliebig ergänzen.

In einigen Fällen übernehmen Maintainer der Communities diese Arbeit, in anderen Fällen ist dieser Build-Prozess über die Grenzen von Distributionen hinweg automatisiert. Dennoch muss der Paketierer an alle möglichen Abhängigkeiten und Besonderheiten der verschiedenen Plattformen denken.

Das Installieren von Software bleibt grundsätzlich Benutzern mit entsprechenden Rechten vorbehalten.

Ideenreichtum

An kreativen Ideen zum Korrigieren der Nachteile mangelt es nicht: Die Container-Automatisierung Docker [1] etwa folgt dem Prinzip, wonach ein einzelnes Image eines Containers für die darin laufende Applikation alle Bibliotheken und andere Abhängigkeiten mitbringt. Der Container lässt sich also überall ausführen, wo Docker installiert ist. Viele Anwender schreckt jedoch die Komplexität von Docker und der Aufwand beim Einarbeiten ab, sodass sie lieber auf die Vorteile der Technologie verzichten.

Es geht aber eine Nummer kleiner: Schon seit gut einem Jahrzehnt greifen Entwickler das Grundprinzip einer distributionsübergreifenden Laufzeitumgebung für Programme immer wieder auf und entwerfen verschiedene modernisierte Formate, die einige der zuvor angesprochenen Probleme lösen. Einmal verpackt, laufen die Anwendungen überall, wo die entsprechende Umgebung bereitsteht – egal, ob unter OpenSuse, Ubuntu oder Fedora.

Diese modernen Ansätze stammen aus unterschiedlichen Communities oder Firmen und entwickeln sich dementsprechend nicht unbedingt in dieselbe Richtung. Um herauszufinden, welche Formate sich womöglich in Zukunft durchsetzen und welche davon für Anwender empfehlenswert sind, lohnt ein Blick auf die drei bekanntesten Vertreter der Gattung: Flatpak, Snap und AppImage.

Youngsters

Als die großen Distributionen Debian und Red Hat das Licht der Welt erblickten, entstanden gleichzeitig die noch heute primär eingesetzten Formate DEB [2] und RPM [3].

Im Kontrast dazu wirkt insbesondere der moderne Gegenspieler Flatpak [4] extrem jugendlich. Die Arbeit an dem Projekt begann bereits im Jahr 2007, als der schwedische Entwickler Alexander Larsson – damals noch anhand des Bundle-Formats Glick [5] – in Sachen Paketierung quasi dem Möbelhersteller Ikea nacheifern wollte. Einige Jahre später entstand daraus das gereifte Format XDG-App, das schließlich im Juni 2016 den Namen Flatpak erhielt [6]. Larsson selbst ist unter anderem für Red Hat und das Fedora-Projekt tätig, womit seine Entwicklung auf viele Komponenten zurückgreift, die primär bei Red Hat entstanden.

Snap [7] dagegen stammt aus der Feder des Ubuntu-Herstellers Canonical. Es handelt sich um eine Weiterentwicklung des Paketformats Klik, das 2013 auf dem Ubuntu Phone zum Einsatz kam. Im folgenden Jahr führte das Unternehmen das Prinzip der Apps unter dem Namen Snappy auf der IoT-Plattform Ubuntu Core weiter, bis Snap schließlich mit Ubuntu 16.04 Einzug auf der Desktop-Variante des Systems hielt. Im Juni 2016 entschloss sich Canonical, das Format für andere Distributionen und Zwecke zu öffnen.

Die Geschichte von AppImage reicht zurück bis in das Jahr 2004, als der Entwickler Simon Peter das bereits erwähnte Format Klik entwickelte. Damals konnten Anwender über den Browser und spezielle URLs sogenannte Rezepte beziehen, die lokal die ausführbare Datei für das Programm generierten. Dadurch erzielte Peter einen gewissen Grad an Unabhängigkeit von Plattformen, da dieses System die ausführbaren Dateien nicht von Anfang ausliefert. Neue Versionen von Klik kamen nie über den Beta-Status hinaus, weshalb Simon Peter 2011 den anders funktionierenden Nachfolger PortableLinuxApps veröffentlichte. Das Projekt reifte und erhielt 2013 eine neue Lizenz sowie den neuen Namen AppImage.

Einen zusammenfassenden Vergleich der drei Formate Flatpak, Snap und AppImage finden Sie in der Tabelle “Vergleich moderner Paketformate”.

Design und Sicherheit

RPM- und DEB-Pakete legen nach Installation mit Root-Privilegien Inhalte im Dateisystem ab. Es obliegt dann dem Anwender oder einem Init-System, das neue Programm mit den gewünschten Rechten auszuführen. Ohne zusätzlichen Eingriff durch den Benutzer läuft die Anwendung im gleichen Namensraum wie der Kernel und alle anderen Prozesse. Eine Isolation gegen den Rest der Umgebung findet nur statt, wenn Sie selbst Hand anlegen und sich bekannter Werkzeuge wie Chroot [8], SELinux [9] oder AppArmor [10] bedienen.

Der Aufbau von Flatpak hingegen erlaubt eine gänzlich andere Vorgehensweise: Entsprechende Pakete zielen primär auf den Desktop-Einsatz ab und setzen eine sogenannte Laufzeitumgebung voraus. Die stellt grundlegende Inhalte für den Betrieb von Anwendungen bereit und nimmt mit 150 bis 300 MByte durchaus ein wenig Platz auf der Festplatte ein. Eine Liste an vorhandenen Umgebungen findet sich auf der Webseite des Projekts [11].

Ein Entwickler muss jedes Paket gegen eine dieser Runtimes erstellen. Es läuft dann überall dort, wo die fragliche Laufzeitumgebung installiert ist. Das System erkennt während der Installation, ob die nötige Runtime bereits vorliegt, und zieht sie gegebenenfalls nach. Ein System darf mehrere Laufzeitumgebungen in verschiedenen Varianten vorhalten, was es ermöglicht, mit Flatpak geschnürte Anwendungen in verschiedenen Versionen vorzuhalten. Wenn ein Programm über die Runtime hinaus zusätzliche Abhängigkeiten benötigt, landen diese gleich mit im Paket.

Die Installation sowohl der Runtime als auch der Applikation erfordert Root-Rechte. Da ein Flatpak-Paket jedoch in einer eigenen, isolierten Umgebung läuft, darf jeder Benutzer das enthaltene Programm auch ohne erweiterte Privilegien starten.

Im Hintergrund bedient sich Flatpak diverser bekannter Technologien, die unter anderem auch im Container-Umfeld zum Einsatz kommen. Bubblewrap [12] etwa sorgt dafür, dass die Software im Kontext des aktuellen Benutzers im eigenen Namespace [13] läuft. Dadurch sieht sie nur sich selbst und die benötigte Laufzeitumgebung.

Techniken wie Cgroups [14] reglementieren den Zugriff auf Dateien, das Netzwerk, die grafische Oberfläche und diverse Subsysteme streng. Mittels vordefinierter Schnittstellen aus den “Portals” [15] kann eine in der Sandbox laufende Applikation bei Bedarf auf Ressourcen auf dem Host zugreifen (Abbildung 1). Diese Arbeitsweise brachte Flatpak die Bezeichnung “Desktop-Container” ein.

Abbildung 1: Die Topologie von Flatpak-Paketen erinnert ein wenig an typische Container-Architekturen.

Die Arbeitsweise von Snaps ist ähnlich: Die Software-Bundles benötigen zum Funktionieren das minimale Betriebssystem Ubuntu Core, das Sie mithilfe von klassischen Debian-Paketen auf dem lokalen System hinterlegen (Abbildung 2). Die Umgebung umfasst etwas mehr als 80 MByte an grundlegenden Komponenten. Sobald Sie ein erstes Snap installieren, zieht das System fehlende Teile automatisch nach.

Abbildung 2: Der logische Aufbau von Snap, wobei Ubuntu Core hier os snap heißt.

Da Ubuntu Core aus offiziellen Quellen stammt und damit aus Sicht des Systems als vertrauenswürdig gilt, betreibt es diese Laufzeitumgebung im normalen Namespace. Die Anwendungen selbst hingegen laufen in einem abgeschotteten Namensraum, mittels Cgroup ist der Einsatz von Ressourcen limitiert.

Als Anwender installieren Sie die Snaps über Sudo beziehungsweise mit Root-Privilegien, während das Ausführen der Software selbst keine erweiterten Rechte benötigt. Das Paketformat Snap taugt gleichermaßen für Systeme mit und ohne grafische Benutzeroberfläche.

AppImage unterscheidet sich in einigen Merkmalen von den Kontrahenten Snap und Flatpak. Bei einem entsprechenden Paket handelt es sich um eine komprimierte Image-Datei, die Sie ohne erweiterte Privilegien herunterladen und ausführen (Abbildung 3). Jedes Image enthält alle Abhängigkeiten für die jeweilige Software.

Abbildung 3: Logischer Aufbau des AppImage-Formats.

Nutzen Sie ein solches Paket, hängt das System das darin befindliche Image temporär nur lesend ein und startet die darin verpackte Anwendung. Eine Installation aus dem Paket heraus, wie etwa bei RPM- oder DEB-Paketen, gibt es nicht. Standardmäßig laufen Anwendungen aus AppImage-Paketen heraus nicht isoliert vom Rest des Systems. Wer ein Sandboxing-Verfahren [16] nutzen möchte, benötigt daher optionale Zusatzprogramme. Entsprechende Anleitungen existieren aber [17].

Einige Entwickler hinter dem Projekt AppImage haben zudem den Daemon Appimaged [18] ins Leben gerufen. Er scannt bestimmte Benutzerverzeichnisse auf AppImage-Dateien, registriert diese auf Wunsch hin im System und führt Images bei Bedarf in einer Sandbox aus. Die typische Zielgruppe von mittels AppImage verpackten Programmen sind Benutzer, die ihr System mit grafischer Oberfläche betreiben.

Distributionsunabhängig

Flatpak wurde von Beginn an dafür konzipiert, unter gängigen Distributionen wie Arch Linux, CentOS, Debian, Fedora, OpenSuse, Red Hat oder Ubuntu zu funktionieren. Ursprünglich war es vorgesehen, dass Anwender im Internet selbst nach Software-Quellen suchen.

Eine Quelle stellt in klassischer Form die Datei flatpakref bereit, in der sich diverse Angaben zum Paket finden, wie etwa die URL zu den eigentlichen Inhalten. Diese Datei nutzt dann die Paketverwaltung von Flatpak, um das entsprechende Paket herunterzuladen und einzurichten.

Mittlerweile haben die Entwickler die Werkzeuge zum Verwalten der Pakete aber um die Möglichkeit erweitert, sogenannte Remotes oder Repositories hinzuzufügen, die Sie dann durchsuchen dürfen. Der Bezug eines Pakets funktioniert anschließend wie gewohnt: Zunächst suchen Sie über das entsprechende Kommando nach einem Programm, im Anschluss installieren Sie es mit der Paketverwaltung (Abbildung 4).

Abbildung 4: Flatpak macht es leicht, den Messenger Signal zu installieren und auszuführen.

Einmal installiert, besteht die Möglichkeit, die Flatpaks aufzulisten, zu aktualisieren und wieder zu entfernen. Der Start einer Anwendung erfolgt ebenfalls über die passenden Werkzeuge. Als Software-Quellen dienen sowohl einzelne Webseiten (etwa von Software-Herstellern) als auch Repositories wie Flathub [19].

Beim Paketformat Snap und der dazugehörigen Verwaltung Snappy lag der Fokus ursprünglich auf Ubuntu als Plattform. Langfristig war das Ziel, DEB-Pakete und Apt sowie Aptitude abzulösen. Im Juni 2016 haben Entwickler die Paketverwaltung und das Format für weitere Linux-Distributionen portiert [20]. Seitdem besteht unter Arch Linux, CentOS, Debian, Fedora, Gentoo, OpenSuse und Red Hat die Möglichkeit, Snap-Pakete zu verwenden.

Dabei ist Snappy auf jeder Distribution dazu in der Lage, die Metadaten von Snap-Paketen auszulesen und gewisse Regeln je nach Distribution umzusetzen, etwa im Security-Bereich. Aus diesem Grund braucht ein solches System nicht zwingend AppArmor zu beinhalten, damit Anwendungen aus entsprechenden Paketen heraus starten.

Die Snap-Werkzeuge interagieren mit dem Daemon Snapd, mit dem Sie Pakete aus offiziellen Quellen beziehen, sogenannten Stores. Canonicals offizielle Quelle für Snaps ist der Ubuntu-Store [21]. Wer sich mit der Paketverwaltung im Store einloggt, darf übrigens Pakete ohne Sudo- oder Root-Rechte installieren.

Gelangen Sie über andere Wege an Pakete mit der Dateiendung .snap, können Sie diese vom lokalen Dateisystem aus installieren. Snappy unterstützt eine Vielzahl an Aktionen für Pakete, darunter die üblichen Verdächtigen wie Installation, Suche, Aktualisieren, Auflisten und Entfernen. Snaps hinterlegen auf dem lokalen System Kommandos, über die Sie die frisch installierte Anwendung direkt ansprechen (Abbildung 5).

Abbildung 5: Installation und Ausführung der Snap-Anwendung hello unter Ubuntu 16.04.

Anders als bei RPM, DEB oder Snap existierte bei AppImage lange kein klassisches Paketmanagement, um Software zu suchen und zu installieren. Stattdessen beziehen Sie ein Paket etwa von den Webseiten der Hersteller oder anderer Anbieter. Das ist ganz im Sinn des Erfinders: Auf der Webseite des Projekts kann man nachlesen, dass das Paketformat das Ziel hat, Software direkt vom Hersteller zu beziehen, und nicht etwa über Repositories, die zwangsläufig irgendwann veraltete Versionen anbieten. Allerdings weicht das Projekt selbst dieses Konzept auf: Auf der GitHub-Seite findet sich zumindest eine Liste, die auf vorgefertige Images verweist [22].

Einmal heruntergeladen, verschieben Sie die entsprechende Datei an die gewünschte Stelle und führen sie wie eine gewöhnliche Anwendung aus. Weder das Herunterladen der Pakete noch das Ausführen erfordern eine besondere Berechtigung.

Wie erwähnt, existiert mit Appimaged mittlerweile ein optionales Werkzeug, das sich langfristig Richtung Paketmanagement entwickelt. Bis die Software ausgereift und offiziell integriert ist, greifen die meisten Anwender beim Bezug von Anwendungen vermutlich auf den Browser zu. Damit fehlt aber eine Möglichkeit, bereits heruntergeladene AppImage-Pakete zu aktualisieren oder aufzulisten – diese Aufgaben obliegen allein Ihnen.

AppImage unterstützt alle größeren Distributionen, darunter Arch Linux, CentOS, Debian, Fedora, OpenSuse, Red Hat und Ubuntu. Die via AppImage verpackten Programme rufen Sie direkt auf (Abbildung 6).

Abbildung 6: Unter AppImage laden Sie Anwendungen direkt herunter und führen diese aus, so wie hier geschehen mit Cantata.

Akzeptanz

Der Verbreitungsgrad der drei modernen Formate lässt sich schwer einschätzen, da es keine offiziellen Zahlen und Statistiken von den jeweiligen Projekten gibt. Viele Software-Hersteller bieten auf der eigenen Webseite neben RPM- und DEB-Paketen mittlerweile Downloads als Flatpak, Snap oder AppImage an, da besonders die Benutzer in den Foren und auf Github vermehrt danach fragen.

Die wenigen Repositories, die es (wenn überhaupt) für die neuen Pakete gibt, beherbergen teils nur wenige hundert, in einem Fall immerhin deutlich über tausend Pakete. Wer ein Desktop- oder Server-System ausschließlich mit neuen Formaten verwalten möchte, hat im Moment das Nachsehen: Die häufig eingesetzten Programme gibt es in der Regel nur über die bislang bekannten Paketformate. Immerhin bietet Canonical mit Snapcraft ein Werkzeug an, um aus vorhandenen Debian-Paketen Snap-Bundles zu schnüren. Dann besteht die Möglichkeit, diese direkt auf der Webseite bereitzustellen.

Möchten Sie Software im Snap-Format zudem in die zentrale Bezugsquelle für Snap-Pakete hochladen, den Ubuntu-Store, dann setzt das voraus, dass Sie zuvor mit Canonical ein sogenanntes Contributor License Agreements abschließen. Da solche Vereinbarungen auf Entwickler aus der Open-Source-Community meist abschreckend wirken, verzichten viele auf einen Eintrag im offiziellen Verzeichnis oder meiden das Format ganz.

Auch Flatpak und AppImage bieten Werkzeuge an, um eigene Pakete zu erstellen. Anders als bei Snap sehen sie allerdings keinen offiziellen Konverter für RPM- oder DEB-Paketen vor. Der Grund: Die klassischen Formate enthalten in der Regel spezifische Anweisungen für die Distributionen, die sich nur schwer in plattformübergreifende Prozeduren übersetzen lassen, wenn überhaupt.

Wer sein Flatpak-Paket in eines der wenigen existierenden Repositories hochladen möchte, braucht in der Regel keine Besonderheiten zu beachten. Ersteller von AppImage-Dateien haben immerhin die Möglichkeit, ihr Paket auf inoffiziellen Listen einzutragen, die im Netz kursieren und eine Art Gelbe Seiten für die Image-Dateien bilden.

Licht und Schatten

Die modernen Gegenspieler zu RPM und DEB machen vieles richtig: Endlich droht dem Anwender keine “Dependency Hell” mehr, in der Pakete untereinander derart verschachtelte Abhängigkeiten aufweisen, dass diese sich teils gar nicht mehr auflösen lassen. Flatpak, Snap und AppImage liefern meist in einem einzigen Bundle alles, was man zum Betrieb der Software braucht. Selbst die Installation und das Ausführen geschehen zum Teil ohne Root-Rechte.

In Sachen Sicherheit setzen die modernen Formate die Messlatte dennoch hoch: Zumindest Flatpak- und Snap-Pakete laufen isoliert vom Rest des Systems in einer Sandbox, AppImage bietet zumindest optional entsprechende Funktionen. Wer mag, darf zudem verschiedene Versionen einer Software auf seinem System installieren und teils sogar gleichzeitig betreiben – ein Traum für jeden Systemadministrator, da so der Wechsel zwischen alten und neuen Programmversionen leichtfällt.

In der Regel bieten die Formate ausreichend Möglichkeiten, um Rollbacks anzustoßen und sogenannte Delta-Updates vorzunehmen. Letzteres bewirkt, dass das System beim Aktualisieren unter Flatpak, Snap und AppImage nur die Unterschiede zur älteren Version herunterlädt. Anders als RPM und DEB sehen die modernen Formate dieses Feature schon von Haus aus vor; es setzt jedoch voraus, dass der Ersteller des Pakets die Möglichkeit nutzt.

Der größte Vorteil der neuen Formate liegt sicher in der Tatsache, dass sie über Grenzen von Distributionen funktionieren. Egal, ob Sie Debian, Ubuntu, OpenSuse, CentOS oder eine andere Plattform verwenden: Die Applikation läuft überall gleichermaßen, wenn Sie sie als Datei mitnehmen und auf andere Zielsysteme kopieren. Damit entfällt die Notwendigkeit, Software unter verschiedenen Distributionen unterschiedlich zu verwalten. Wenn Sie mit den neuen Formaten zentrales Software-Management betreiben möchten, macht es wenig Mühe, dafür eine eigene, zentrale Komponente zu bauen und zu nutzen.

Da Flatpak, Snap und AppImage nahezu alle Abhängigkeiten ins Paket stopfen, entstehen allerdings recht große Dateien – bis zu vier Mal so groß wie ein Paket im klassischen Format. Zwar kostet Platz auf dem Massenspeicher heute nicht mehr die Welt, trotzdem stört dieser Umstand gelegentlich: Es ist durchaus möglich, dass etwa 20 AppImage-Dateien, die Sie herunterladen, auch 20 Mal dieselben oder ähnliche Abhängigkeiten mitbringen und dadurch Redundanz schaffen, gegen die Sie nichts unternehmen können. Auch der Download der Anwendungen verlängert sich entsprechend – ärgerlich, wenn etwa der langsame Proxy im Zug oder im Büro nur geringe Transferrate zulässt.

Die große Stärke von den klassischen Formaten liegt in den zentralen, meist (aber nicht nur) von Distributionen gepflegten Repositories. Für den Anwender existiert eine Paketverwaltung, über die er alle Pakete bezieht. Nur vereinzelt muss er im Internet nach anderen Quellen zu suchen. Diesen Luxus bieten Flatpak, Snap und AppImage nur unzureichend: Falls überhaupt so etwas wie eine zentrale Paketquelle existiert, umfasst sie nur wenige Anwendungen, von denen vermutlich noch weniger interessant für den eigenen Bedarf sind. Optimalerweise bieten also Software-Hersteller direkt Pakete in den neuen Formaten zum Download an.

Die klassischen Software-Repositories erfüllen bei den Distributionen einen bestimmten Zweck: Mitarbeiter der Community, sogenannte Package Maintainer, sorgen nach strengen Vorgaben für das standardisierte Paketieren von Open-Source-Software und damit für das Einhalten bestimmter Standards. Gleichzeitig findet eine Art Sicherheitsprüfung statt, bei dem die Community ein Stück Software und dessen Installation unter die Lupe nimmt.

Wenn Hersteller nun direkt Software auf ihren Webseiten anbieten, entfällt dieser Zwischenschritt. Dieser Umstand wirkt sich sowohl positiv wie negativ aus. Glücklich dürfen sich jene Anwender schätzen, die möglichst rasch neue Versionen einer Software beziehen wollen, während sie weiterhin auf eine LTS-Distribution setzen möchten: Das funktioniert in diesem Verfahren gut, da kein Maintainer das Paket neu zu bauen braucht, und die neuen Formate lassen den Rest des Systems nahezu unangetastet. Wer allerdings hofft, dass zuvor Dritte einen prüfenden Blick auf das Flatpak, Snap oder AppImage geworfen haben, sollte sich nicht zu viel Hoffnungen machen.

Anders verhält es sich, wer auf Snap setzt und nur den Ubuntu-Store als offiziellen Bezugspunkt nutzt. Die Entwickler prüfen dort die Pakete bis zu einem gewissen Grad und geben sie explizit frei. Zudem entsteht durch das Unterzeichnen eines Agreements eine gewisse Verantwortung beim Eigentümer des Pakets.

Die neuen, modernen Formate sehen wenig oder gar keine Interaktion mit Automatisierungswerkzeugen vor. Wer etwa via AppImage Anwendungen auf seinen Systemen ausrollen und dort nachträglich individualisiert konfigurieren möchte, der tut sich im ersten Anlauf vermutlich schwer. Auch der Umstand, dass Anwendungen bei Flatpak und Snap in einer Sandbox starten, macht es für Administratoren schwer, nachträglich die Konfiguration zu verändern. Da die Interaktion mit Werkzeugen zum Automatisieren aber bei den klassischen Paketen ebenfalls eher umständlich ist, wäre es unfair, das alleine den modernen Formaten als Nachteil anzulasten.

Fazit

RPM und DEB versus Flatpak, Snap und AppImage: Wem gehört die Zukunft? Die modernen Formate lösen viele, teils uralte Probleme und stellen die Welt der Software damit gewaltig auf den Kopf. Tatsächlich nimmt die Community die Formate aber nur zögerlich an: Zu komfortabel lassen sich RPMs, DEBs und andere Klassiker über riesige Repositories beziehen. Eines ist aber schon jetzt klar: Die Art, wie Systeme unter Linux Software verwalten und ausrollen, hat sich Dank Docker schon jetzt grundlegend verändert.

Es kann daher durchaus sein, dass sich die neuen Formate über ihren Sandbox- und All-inclusive-Ansatz in irgendeiner Form durchsetzen. Möchten Sie jetzt schon umsteigen, fahren Sie mit Flatpak vermutlich am besten: Es sieht die Isolation vom Rest des Systems von Anfang an vor, Repositories ermöglichen in einem gewissen Umfang den zentralen Bezug von Software.

In der Community gibt es übrigens schon länger Stimmen, die dafür plädieren, dass jede Software künftig standardmäßig oder gar ausschließlich in einer eigenen Umgebungen läuft, sprich: in einem Container. Offen ist bislang, wie die konkrete technische Implementation aussehen könnte. Gut möglich, dass am Ende beispielsweise Docker auf jedem Linux-System landet oder sich einer der neuen Standards durchsetzt.