Hinweis:
Dieser Artikel gehört der Kategorie Kwami an. Er spiegelt damit allein die Meinung des Autors und nicht zwingend die des ubuntuusers.de-Teams wider.
Worum geht es?¶
Wie viele sicherlich mitbekommen haben, plant Canonical ein eigenes Paketformat für Ubuntu zu entwickeln, um die Bereitstellung von Anwendungen z.B. für das kommende Ubuntu Phone zu erleichtern. Dabei geht es ausdrücklich nicht um einen Ersatz für dpkg, sondern um eine Ergänzung dazu. So sollen Anwendungen von Drittanbietern einfach installiert werden können, ohne diese erst als DEB-Pakete in einer Paketquelle bereitzustellen.
Nun gibt es jedoch bereits sehr ähnliche Lösungen, welche die Installation von Drittanbietersoftware vereinfachen, z.B. 0install 🇬🇧 oder eben Listaller. Auf das Listaller-Projekt 🇬🇧 möchte ich im Folgenden näher eingehen.
Ein Projekt für jede Aufgabe¶
 |
| Listaller Logo |
Listaller baut auf einer Reihe weiterer Projekte auf, um zu funktionieren. So benötigt es zwingend PackageKit. PackageKit ist eine Abstraktionsschicht für Paketmanager, welche Schnittstellen zum Paketmanagement über DBus bereitstellt. Im Klartext bedeutet das, dass jede Anwendung über eine standardisierte Schnittstelle einfach Anfragen an den Paketmanager stellen kann (z.B. „Ist Paket X installiert?“ oder „Bitte entferne Paket Y.“). Ubuntu verwendet kein PackageKit, stellt aber über eine Kompatibilitätsschicht die meisten der Schnittstellen bereit.
Des Weiteren gibt es noch das AppStream-Projekt. AppStream stellt Metadaten für die Paketverwaltung bereit, die z.B. beschreiben, welche Anwendung in welchem Paket ist, welches Icon sie hat, etc. Damit ist AppStream das Projekt, welches Anwendungen wie das Ubuntu Software Center möglich macht. Zudem enthalten die AppStream-Spezifikationen Dinge wie einen „Ratings&Reviews“-Dienst, welcher die Bewertung und Kommentierung von Anwendungen ermöglicht. Ubuntu verwendet AppStream, was kein Wunder ist, da AppStream gestartet wurde, nachdem das Ubuntu Software Center bereits existierte, und AppStream zu einem großen Teil aus einer Verallgemeinerung dieses Systems für alle Distributionen besteht.
Was ist das Listaller-Projekt?¶
Ziel des Listaller-Projektes ist es, Installationen von Software unter allen Linux-Distributionen mit nur einem Softwarepaket zu ermöglichen. Es komplettiert damit AppStream und PackageKit – mehr noch, es ist fest mit beiden Projekten verdrahtet (jedoch gibt es keine fixe Abhängigkeit der beiden vorigen Projekte).
Listaller hat folgende Design-Prinzipien zu erfüllen:
Integration: Nutzer sollen nicht merken, dass sie Listaller verwenden. Das bedeutet zum Beispiel, dass sich Listaller-Anwendungen über die globale Update-Anwendung aktualisieren, und dass sie wenn möglich mit existierenden Tools verwaltet werden können.
Cross-Distro: Listaller soll auf möglichst allen Distributionen gleich funktionieren.
Sicherheit: Skripte in Paketen sind verboten, ebenso wie eine Menge anderer Dinge. Der Installer kontrolliert den gesamten Setup-Prozess automatisch, das Paket selber kann darauf nur indirekt Einfluss nehmen. Zudem sind Listaller-Pakete mit GPG-Schlüsseln signiert.
Konfliktfrei: Es gibt keine Konflikte mit der distributionseigenen Paketdatenbank, Listaller-Anwendungen sind unabhängig.
Reduktion & Vereinfachung: Listaller-Pakete haben nur eine sehr einfache Art, Abhängigkeiten zu deklarieren. Zudem enthält das System viele andere Vereinfachungen, welche zwar die Möglichkeiten leicht einschränken, aber letztendlich den Installationsprozess robuster machen (und die fehlenden Features werden auch hauptsächlich von Anwendungen gebraucht, die eh besser als natives Paket ausgeliefert werden sollten).
Tools zur Cross-Distro-Entwicklung: Listaller stellt Werkzeuge bereit, um Anwendungen auf möglichst vielen Distributionen lauffähig zu halten und Abhängigkeiten zu minimieren.
Was plant Ubuntu?¶
Das Ubuntu-Installationssystem („Click“) soll nach Colin Watsons Angaben folgende Aufgaben zu erfüllen (sinngemäß aus der Ankündigungsmail übersetzt):
keine Abhängigkeiten zwischen Anwendungen, keine Konflikte
deklarative Pakete, keine Maintainerscripte
keine Limitierung auf Installationen mit Superuser-Rechten
Möglichkeit, Pakete auf nicht-Linux-Systemen bauen zu können
Binärpakete mit ähnlichem Design zum DEB-Paketformat
Möglichkeit, für „hooks“ in existierende Distributionspakete
testgetriebene Entwicklung
Warum eine Eigenentwicklung?¶
Das ist die interessante Frage. Schaut man sich die Anforderungen an das Ubuntu-Paketsystem an, so wurden nahezu eins zu eins die Design-Prinzipien des Listaller-Projektes übernommen. Es gibt genau genommen nur zwei Unterschiede: Listaller wird nicht testgetrieben entwickelt und das Listaller-Projekt läuft nur auf Linuxsystemen. Beides sind meiner Meinung nach keine Kriterien, um eine neue Lösung zu schreiben. Testgetriebene Entwicklung resultiert nicht automatisch in besserer Software (manchmal genau im Gegenteil) und eine Entwicklungsmethode ist kein Argument, sich nicht an einem bestehenden Projekt zu beteiligen. Listaller-Pakete unter anderen Plattformen zu bauen, gehört nicht zu dessen Zielen, jedoch würde niemand Canonical daran hindern, eine Möglichkeit dafür zu implementieren.
Zur Frage, warum nicht eine existierende Lösung verwendet wird, schreibt Colin, dass das „vermutlich keinen Unterschied machen würde“. (Ich weiß nicht, was das für ein Argument ist …) Zum Listaller Projekt meint er, dass er darüber besorgt sei, dass der Listaller einen kompletten Dependency-Solver enthält. Ein Dependency-Solver ist ein Algorithmus, welcher Abhängigkeiten zwischen Paketen möglichst clever auflöst. Alle Paketmanager haben einen, um das Paketsystem in einem konsistenten Zustand zu halten. Der Listaller teilt Abhängigkeiten von Drittanbieterpaketen in zwei „Welten“: „Frameworks“ und „Module“. Framework-Abhängigkeiten müssen vom Distributor zu Verfügung gestellt werden. Zu den Frameworks zählen z.B. die KDE-Frameworks, die GNOME3-Plattform oder auch systemd 🇬🇧 und PolicyKit. Module dagegen können vom Listaller nachinstalliert (Module sind z.B. kleinere Softwarebibliotheken oder aber auch Dinge wie z.B. Wörterbücher). Für letzteres benötigt der Listaller theoretisch eine Möglichkeit, Abhängigkeiten aufzulösen. Da jedoch Module untereinander konfliktfrei sind, ist das Auflösen der Abhängigkeiten sehr einfach. Zudem existiert im Listaller momentan überhaupt kein Dependency-Solver und Distributoren können das Nachladen von Modulen aus Drittanbieterquellen komplett abschalten (das mag in manchen Fällen die Sicherheit erhöhen).
Canonical will in ihrem Design nur „Frameworks“ zulassen, vermutlich sogar nur eine Abhängigkeit zu einem bestimmten API-Level von Unity. Das macht Installationen noch einfacher, schränkt aber auch die Möglichkeiten der Entwickler massiv ein. Für ein OS für Mobiltelefone mit definierter API mag das okay sein. Auf dem sehr heterogenen Linux-Desktop würde eine solche Lösung jedoch nicht gut funktionieren. Ein Installationssystem sollte mit möglichst vielen Konfigurationen zurecht kommen, während der Ubuntu-Installer vermutlich nur für einen einzigen Zweck und ein System designt wird.
Für Canonical wäre es aber insgesamt kein Problem, den Listaller unter diesen Gesichtspunkten zu verwenden. So können z.B. erlaubte Abhängigkeiten vom Distributor im Listaller eingeschränkt werden. Diese Informationen wäre auch Canonical bekannt, wenn sie vorher mal jemanden aus dem Listaller-Projekt gefragt hätten.
Canonical redet nicht mit anderen¶
Und das ist auch die Sache, die ich wirklich kritisiere: Anstelle die Entwickler der Software, die man vielleicht verwenden könnte, zu kontaktieren und Fragen dazu zu stellen, um zu evaluieren, ob sich die Verwendung der Software lohnt, wird einfach direkt etwas Neues entwickelt. Alle Ziele des Ubuntu-Paketformates sind im Listaller enthalten, nur distributionsübergreifend. Canonical mag spezielle Anforderungen haben, aber anstelle dass man auf die Entwickler der jeweils anderen Lösung zugeht und anfragt, ob man diese Ziele Upstream verwirklichen kann, wird lieber sofort eine Insellösung geschaffen. Als Canonical Mir gestartet hat, hatten sie sich offenbar ebenso wenig über Wayland informiert, geschweige denn mit den Wayland-Entwicklern gesprochen (wie sich später gezeigt hat) wie in diesem Fall. Upstream-Entwickler sind bei weitem nicht Canonical-feindlich und wenn die Entwicklung gut abgestimmt ist, werden auch sehr gerne Patches akzeptiert. Insbesondere das Listaller-Projekt hat sehr wenige Entwickler, und könnte jede Hilfe gebrauchen.
Stattdessen durfte ich mich in den letzten Tagen vor allem rechtfertigen, warum der Listaller eben kein exzessives Auflösen von Abhängigkeiten betreibt, da dies in der Ubuntu-Ankündigung nicht korrekt beschrieben war. Außerdem kommt auch häufig die Kritik „Wenn das Listaller-Projekt schneller gewesen wäre, dann ...“ oder „Konkurrenz belebt das Geschäft“. Das ist in diesem Fall genauso wenig wahr wie im Fall Wayland vs. Mir. Listaller ist ein Projekt mit vielen Aspekten, von denen einige Zeit brauchten, um realisiert zu werden. So musste z.B. erst PackageKit verbessert werden oder die Desktopumgebungen stabile Entwicklungsplattformen bereit stellen, damit das Listaller-Konzept funktionieren kann. Auch AppStream ist ein wichtiger Bestandteil davon. An allen diesen Dingen wurde über die Jahre gearbeitet. Ebenso mussten für Wayland Toolkits angepasst werden und Code aufgeräumt werden. Canonical erntet jetzt die Früchte dieser Arbeit. Eine neue Lösung zu schaffen ist immer nur dann wirklich sinnvoll, wenn man etwas schafft, was die vorigen Projekte nicht konnten und was aus verschiedensten Gründen nicht mit diesen hätte realisiert werden können.
Warum also wirklich eine Eigenentwicklung?¶
Für mich ist der Grund für den Alleingang ganz klar die Kontrolle über den Software-Stack und die Möglichkeit, Änderungen schneller durchzuführen. Dadurch, dass Canonical einen Großteil des Stacks kontrolliert (Upstart, Unity, Mir, Aptd, Compiz, Click, ...) können Änderungen noch schneller umgesetzt werden. Arbeiten Canonical-Mitarbeiter an einem Upstream-Projekt, so muss man sich immer mit anderen Parteien abstimmen, um ein Feature umzusetzen. Kontrolliert man hingegen die Entwicklung, entfällt dieser Schritt. Zudem „besitzt“ Canonical über die CLAs erweiterte Rechte am Code, was das Unternehmen natürlich an sich wertvoller macht. Weiterhin schafft sich Ubuntu so natürlich auch Alleinstellungsmerkmale.
Ich sehe diese Entwicklung sehr zwiespältig, da vor allem das Abstimmen mit den anderen Entwicklern nahezu immer zu besseren Lösungen und erfolgreichen Projekten führt. Insbesondere wenn einige Entwickler bereits Jahre an einem bestimmten Problem arbeiten, kann man häufig „Expertenhilfe“ bekommen. Andererseits kann ich auch teilweise nachvollziehen, dass Canonical und Mark möglichst viel der Entwicklung kontrollieren wollen, denn nur so lässt sich vermutlich die „Ubuntu-Vision“ am besten umsetzen.
Allgemeines zu Canonicals Entwicklung¶
Für mich und einige aus der Community hingegen ist die Ubuntu-Entwicklung teils sehr frustrierend, vor allem weil man nicht weiß, was Canonical hinter verschlossenen Türen zusammenkocht. Man kann sich nicht sicher sein, ob Ubuntu-Entwickler nicht gerade an einem weiteren geheimen Projekt arbeiten, was ein Upstream-Projekt ersetzt. Dadurch sind Planungen unmöglich. Z.B. hatten einige Leute bereits viel Arbeit in „Ubuntu on Wayland“ gesteckt, während Canonical-Entwickler bereits längst von Mir wussten (aber nichts sagen durften). Ebenso hätte man zumindest die Verantwortlichen der Ubuntu-Derivate informieren sollen.
Auch vorgeschobene Argumente gegen andere Projekte sind in meinen Augen ganz schlechter Stil, wenn man dagegen einfach sagen würde „Wir wollen eine Lösung unter unserer Kontrolle, welche wir eng ins System integrieren können“ wäre das völlig in Ordnung. Ebenso kann es nicht sein, dass der Projektleiter Community-Mitgliedern Spaltung der Community vorwirft, anstelle zu versuchen, diese Probleme zu lösen (ich denke da an Mark Schuttleworths Kommentar zu Jonathan Riddell).
Alles in allem habe ich selber das Vetrauen in Canonical verloren, nicht zuletzt auch durch diverse technisch unsinnige Entscheidungen des Projektes und die etlichen Rewrites von Unity.
Konsequenzen?¶
Ein eigenes Paketformat für Ubuntu-Apps ist bei weitem nicht so problematisch wie ein zweiter Displayserver. Es ist dennoch sehr schade, da das Ubuntu-Format sehr wahrscheinlich Ubuntu-spezifisch wird und die Chance auf eine distributionsübergreifende Lösung vertan wird.
In der Diskussion um den Paketmanager erklärte Colin Watson, dass sie gerade die Listaller-Dokumentation lesen – was an sich gut ist. Bis heute habe ich jedoch keine Rückfragen bekommen, ebenso wenig wie eine Anfrage, vielleicht mal auf dem Ubuntu Developer Summit darüber zu sprechen. Insofern glaube ich nicht, dass Ubuntu noch eine externe Lösung verwenden wird.
Links¶
listaller – Projekt auf Launchpad
Listaller 🇬🇧 – Projekt-Website
Listaller - Anwendungen einfach installieren/deinstallieren – ubuntuusers.de-Forum
Blogeintrag 🇬🇧 über aktuelle Entwicklungen bei PackageKit, AppStream und Listaller
Über den Autor
Matthias Klump, in diesem Portal als Ximion bekannt, ist unter anderem Maintainer von Listaller, arbeitet aber auch an Projekten wie Debian, freedesktop.org oder PackageKit mit. Zudem ist er einer der Mitinitiatoren von Tanglu, einer Debian-basierten Linux-Distrubution.
