Das AppStream-Projekt

AppStream-Architektur

In den letzten Tagen ging ja das AppStream-Projekt durch die (Linux-affinen) Medien. (Siehe auch den Blog-Beitrag von Picomol für eine kurze Zusammenfassung) Dem Projekt vorrausgegangen war eine Mini-Konferenz in Nürnberg, parallel zum “Bretzn”-Meeting des openSUSE/KDE Projektes, über die ich im englischen Teil dieses Blogs bereits berichtet habe. Da ich nun mit dem Listaller-Projekt ein Tool entwickle, welches Teile der im Meeting angesprochenen Probleme (leider ungenügend) abdeckt, betrifft diese Konferenz mich bzw. das Listaller-Projekt direkt. Ich wurde gefragt, ob ich auch kommen könnte, aber leider ging das bei mir terminlich nicht. Stattdessen habe ich die Entwicklung des Konzeptes vom Schreibtisch aus mitverfolgt. (Und gebe jetzt meinen Senf dazu :P)

Herausgekommen bei der Minikonferenz, bei der unter anderem Vertreter von Debian, Ubuntu, OpenSUSE, Fedora, Megeia und viele mehr anwesend waren, ist ein konkreter Aktionsplan unter dem Arbeitstitel AppStream. Aber worum geht es dabei genau? Viele News-Seiten haben das leider etwas verzerrt wieder gegeben. (Hallo, Golem!) Grob gesagt geht es darum, Software-Installationen und Software-Management unter Linux distributionsübergreifend zu verbessern.

Gleich vorweg: Die im folgenden genannten Punkte sind mitnichten statisch, es handelt sich dabei um einen groben Plan des AppStream-Projektes, welcher sich natürlich noch ändern kann.

Der wichtigste Punkt ist das distributionsübergreifende Handling von Metadaten und nutzergeneriertem Inhalt. Metadaten sind dabei z.B. Programmbeschreibungen, Symbole, Zusatzinfos oder Screenshots zu einer Anwendung. Dabei präsentiert AppStream dem Nutzer grundsätzlich Anwendungen und keine Pakete, wie das momentan noch der Fall ist. Zur Verdeutlichung hat Richard Hughes, PackageKit-Autor, dieses Architekturdiagramm angefertigt:

AppStream-Architektur

Die Distributionen extrahieren auf einem “Compose Server” Metadaten aus ihren Paketen (Icons/Beschreibungen etc. Allgemeine Infos über alle Anwendungen, welche im Software-Repositorium enthalten sind) und stellen diese als Paket bereit. Diese Daten werden dann – wie heute schon bei Debian/Ubuntu üblich – vom Nutzer heruntergeladen. Dabei kann jedes Repositorium ein eigenes Paket mit Metadaten bereitstellen. Alle diese Daten werden dann auf dem System des Nutzers in eine Xapian-Datenbank eingepflegt. Diese Datenbank wird nun vom für den Nutzer sichtbaren Software-Center gelesen und somit werden die Anwendungen angezeigt.

Als “Software-Center” wurde das aktuell in Ubuntu installierte “Ubuntu Software Center” (USC) gewählt. Das USC wird in SC umbenannt und auf PackageKit portiert, womit es automatisch distributionsunabhängig und auf z.B. Fedora nutzbar wird. (Auf PackageKit zu wechseln war sowieso schon lange geplant) Dies geschieht jedoch nur dann, wenn Canonical sein Copyright-Assignment für das Software-Center aufgibt, da nur so Mitarbeiter anderer Distributionen Code beisteuern können. Aktuell laufen Gespräche darüber.

Im Software-Center werden dann auch Nutzergenerierte Inhalte angezeigt, wie z.B. Bewertungen oder Kommentare. Dafür wird ein Tool entwickelt, welches Pakete zwischen den Distributionen vergleicht und gleiche Pakete erkennt. So kann Fedora dann zum Beispiel für die Anwendung im Paket “FooBar-2” genau die Bewertung anzeigen, welche ein Debian-Nutzer zuvor der selben Anwendung, welche unter Debian jedoch im Paket “foobar-bin” enthalten ist, gegeben hat. Somit ist es möglich, Bewertungen zwischen den Distributionen zu teilen. Zudem kann so der Debian-Screenshot-Service unter screenshots.debian.net von anderen Distributionen genutzt werden. Gleichzeitig wird auch das DebTags-System von Debian für alle anderen Distributionen nutzbar. (Mit Debtags kann man einfach Pakete “taggen”, also mit Stichwörtern versehen) (Übrigens: Es scheint nicht nur so, dass viel Debian-Technik übernommen wird, es ist einfach so. (Und zeigt, wie cool Debian ist ;))) Als netten Nebeneffekt können in Zukunft auch Patches zwischen Distributionen einfacher geteilt werden. So kann man unter Debian über dieses “Package-Mapping” sehen, dass Fedora gerade das Paket A, welches das gleiche Modul enthält wie Debian-Paket B, gepatcht hat und dann die Initiative ergreifen und den Fedora-Patch auch unter Debian in Debian-Paket B anwenden.

Alles in Allem wird dieses Projekt der gesamten Linux-Platform eine richtig tolle Infrastruktur bieten, um Software zu verwalten, zu bewerten und neue Anwendungen zu installieren. Außerdem werden die Distributionen in Zukunft noch besser zusammenarbeiten können. (Der O-Ton des Meetings war sehr positiv, die Zusammenarbeit funktioniert anscheinend hervorragend und ist definitiv produktiv)

Auch an ein einheitliches Format zur Software-Verteilung am Paketmanager vorbei wird gedacht: Da alle Listaller-Ziele mit AppStream in einer Dimension erreicht wurden, von der ich nie zu träumen gewagt habe, bleibt als einziges Listaller-Feature sein distributionsunabhängiges Installer-Format und der NewStuff-Installer. Aktuell integriere ich gerade den Listaller in PackageKit, um ihn für Distributionen einfach nutzbar zu machen. Dies bedeutet aber nicht, dass der Listaller zum einheitlichen Linux-Installer werden wird. Viele Entwickler liebäugeln auch mit einer Klik-Ähnlichen Lösung wie Glick. (Halte ich für schlecht, aber wofür diskutiert man?) Vielleicht wird aber auch ein völlig neues Format geschaffen… Fest steht, dass wenn es überhaupt jemals ein Cross-Distro-AppInstall-Format geben wird, eine Sandbox wie z.B. Arkose in jedem Fall mit dazu gehört, um die Rechte des 3rd-Party Programms genau zu kontrollieren. Aber wie gesagt, die Diskussion läuft. (Achja, um den üblichen Spruch nicht zu vergessen: Der Listaller braucht dringend Entwickler, also wer Interesse hat…! :D)

Ich halte das AppStream-Projekt für einen absoluten Meilenstein in der Geschichte der Kooperation zwischen Distributionen. Wenn der aktuelle Plan, welcher noch viel mehr Details beinhaltet, die ich hier ausgelassen habe, aufgeht, dann wird das das coolste Stück Linux-Software dieses Jahres. (vllt. mit GNOME3 und KDE4.7 zusammen :P)

Mal sehen, was in Zukunft passiert. Für Interessierte möchte ich noch auf die Wiki-Seite des Projektes auf fd.o verweisen, welche den aktuellen Stand hervorragend dokumentiert. (Auch das Video ist zu empfehlen, wenn man viel Zeit hat ;))

5 thoughts on “Das AppStream-Projekt

  1. Sehr schöner Artikel! Vielen Dank für die Informationen. Es ist natürlich was anderes, wenn man selbst an der Quelle sitzt und die Geschichte schon seit einiger Zeit mitverfolgt. Für mich war das gestern das erste mal, dass ich davon was gehört habe. Klingt aber wirklich gut, hoffentlich funktioniert alles so wie geplant.

  2. Sehr schöne Zusammenfassung. Danke dafür. Gibt es schon so etwas wie einen Zeitplan? Wann können wir wohl erste Implementierungen erwarten?

    1. Ziel ist es, alles bis Ende diesen Jahres in allen Distributionen integriert zu haben.
      Der Zeitplan sieht so aus: Specs bis April grob fertig stellen, ab April die Metadaten in den Distributionen zu Verfügung stellen, parallel das Ubuntu Software Center für alle anderen Distributionen portieren. Bis Juli den ganzen Social-Network kram, statistiken, bewertungen, kommentare auf basis der OCS integrieren und im November dann alles den Nutzern zu Verfügung stellen.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.