Listaller 0.5.1 – Kurzvorschau

Vielleicht habt ihr es mitbekommen: Listaller 0.5.1 (alpha) wurde vor ein paar Tagen veröffentlicht. Listaller 0.5.1 wurde vollständig in Vala neugeschrieben. Aber der Wechsel der Programmiersprache ist nicht der einzige Aspekt, der dieses Release “besonders” macht: Dies ist das erste Listaller-Release seit 10 Monaten! Und dies ist die erste Veröffentlichung des neu orientierten Listallers. Während der 0.4.x Serie lag der Fokus des Projektes noch darauf, Software-Management mit dem Listaller so nutzerfreundlich wie möglich zu machen. Das AppStream Projekt macht eine Menge dieser Listaller-Funktionalität nun überflüssig, weshalb wir uns jetzt auf den zweiten Aspekt des Projektes konzentrieren: Distributionsübergreifende Softwareinstallationen. (Natürlich ist der Management-Teil noch immer wichtig, dieser wird aber nun von AppStream-Anwendungen mit Listaller-Unterstützung geregelt.)

Während alle vorigen Listaller-Veröffentlichungen so ausgelegt waren, den Paketerstellern so viel Freiheit und Kontrolle über das Paket wie möglich zu geben, wird der “neue Listaller” selbst den Setup-Vorgang fast völlig alleine steuern.

Es hat eine Weile gedauert, mich zu überzeugen, dass das eine gute Idee ist, aber das neue Konzept ist wirklich viel besser. Da Paketmaintainer nun weniger Kontrolle haben sind die Chancen das System mit einem Listaller-Paket zu beschädigen nur sehr gering: Es gibt einfach nur noch wenige Möglichkeiten, Mist zu bauen. Und da der Listaller nicht dafür da ist, Systemkomponenten zu installieren ist die fehlende Flexibilität in der Regel auch kein Problem. (Natürlich werden noch Features aufgenommen, das aber erst nach einer Prüfung – und dann werden diese Funktionen direkt im Listaller implementiert, sodass keine Maintainer-Scripts nötig sein sollten, was auch die Erstellung von IPK-Paketen sehr einfach macht.)

Der neue Setupprozess erlaubt auch den Distributoren die interne “Setup-Policy” des Listallers an ihre eigenen Richtlinien anzupassen. Somit werden dann alle mit dem Listaller installierten 3rd-party Anwendungen gemäß der Distributionsrichtlinien installiert. Last but not least kann man nun auch “schlechte” Pakete einfacher erkennen und zurückweisen. (Über die check-Anwendung livalidator)

So, jetzt reicht’s mit der allgemeinen Listaller-Info, wenn ihr dieses Blog kennt habt ihr wahrscheinlich eh eine ungefähre Ahnung worum es beim Listaller geht 😛

Das Listaller 0.5.1 Release enthält momentan nur eine Programmbibliothek und einen Satz Kommandozeilenanwendungen – wie laaaangweilig! Sehr viele Leute können mit dieser Shared Library nichts anfangen, daher wurde ich gefragt ob ich nicht einen kurzen Artikel über das, was der Listaller im Moment kann, schreiben könnte. Naja, momentan kann der Listaller eher wenig, aber trotzdem ist das IMHO eine sehr gute Idee, auch da momentan keine validen Listaller-Pakete zum Testen verfügbar sind. Also, legen wir los:

Kurze Vorbemerkung: Wenn ihr euch über die GNOME-Screenshots wundert, weil ihr mich eher als KDE-Nutzer kennt: Ich benutze natürlich noch immer KDE, aber auch die GNOME-Fraktion kann coole Dinge entwickeln, und ich teste grade wie sich die GNOME-Shell bei produktivem Arbeiten macht 😉

Listaller macht momentan ein paar Kommandozeilenanwendungen (CLI) verfügbar, mit welchen man IPK-Softwarepakete bauen kann:

autocompile ist ein automatischer Anwendungs-Kompilierer. Wer Debian kennt, kennt vielleicht auch dh_auto_build, was genau das gleiche wie autocompile tut. Wer Debians Paketbau-Hilfsscripte nicht kennt: Appcompile erkennt das Build-System einer Anwendung und führt die nötigen Schritte zum kompilieren automatisch aus. (z.B. ./configure && make) Es fügt zudem einige allgemeine Compiler-Flags und ein paar Listaller-Spezifika hinzu.

depscan scannt die Abhängigkeiten einer Anwendung. Zur Zeit kann es nur die Abhängigkeiten von Software mittels ldd erkennen, soll aber später erweitert werden um z.B. Python Abhängigkeiten oder Abhängigkeiten von C-Quelltext herauszufinden.

libuild setzt IPK-Pakete aus Quellen zusammen.Es benötigt einen Satz von “Definitionsdateien”, welche Anweisungen enthalten, wie ein Paket gebaut werden soll um zu funktionieren. Ich werde später, wenn das IPK-Format stabiler geworden ist mal Anleitungen zum Paketbau veröffentlichen.

runapp ist eine Hilfsanwendung um Anwendungen, welche mit Listaller installiert wurde, zu starten. Mehr Informationen darüber findet ihr, wenn ihr weiterlest 😛

Ein CLI zur Installation/Entfernung von Listaller-Anwendungen (das “lipa”-Tool aus der Listaller 0.4.x serie) fehlt noch und wird eventuell später hinzugefügt.

Okay, genug über Kommandozeilenanwendungen. Da Listaller selbst eigentlich nur eine Shared Library ist, wird ein Frontend benötigt, um irgend etwas auf dem Bildschirm zu sehen. Ich zeige hier das Listaller-GNOME Frontend. Es existiert noch ein KDE-Frontend, was momentan aber noch nicht fertig und fehlerhaft ist. (Als erstes muss ich Listallers Qt4 Bindungen neu schreiben 🙁 )

Wir wollen jetzt mal ein IPK-Paket installieren, in diesem Fall das Spiel “Osmos” von Hemisphere Games. Osmos ist ein perfekter Testfall für den Listaller, da es wenige Abhängigkeiten hat und eine dieser typischen Anwendungen ist, welche sich nicht in den Distributions-Spezifischen Paketquellen finden. Zur Erinnerung, Listaller möchte einen direkten Pfad von Upstream-Softwareautoren zu ihren Nutzern bieten – für OpenSource-Entwickler genauso wie für Firmen, welche ihr Geld mit proprietärer Software machen. Und – auch ein Grund für Osmos – mir gefällt dieses Spiel wirklich sehr, sehr gut, ausprobieren lohnt sich 😉

Also, führen wir folgenden Befehl aus, um die Anwendung mit Listaller-GNOME zu installieren:

lisetup-gtk ./OsmosDemo-1.6.0_install.ipk

Ja, dieser Setup-Assistent ist hässlich – und ich bin mir absolut sicher, dass besonders die GNOME-Usability-Typen mich dafür schlagen wollen würden 😀 Aber ich bin kein Experte in GTK+-Entwicklung & Design, also wer die GUI verbessern möchte kann sich sehr gerne bei mir melden ^^ (Ich habe mit GTK+ erst vor ca. zwei Monaten angefangen)

Wie man sehen kann, zeigt die erste Seite ein wenig allgemeine Sicherheitsinformation. Die “Should be safe” wird deshalb angezeigt, da der Listaller die GPG Signatur des Osmos-Paketes überprüft hat. Da ich mir selber ultimativ vertraue (ob mit Recht ist eine andere Frage :P) wird dieses Paket generell als sicher eingestuft. Natürlich soll hier noch ein wenig mehr Information über die Paketsicherheit und den Paketautor angezeigt werden, entsprechendes ist schon auf meiner TODO-Liste.

Da jede Listaller-Anwendung standardmäßig in einer Sandbox ausgeführt wird, sollte das Risiko, das System zu beschädigen generell nur marginal sein.

Auf dieser ersten Seite kann der Nutzer auch die Checkbox “Install for all users” setzen – Dies weist den Listaller an, die Software mit Superuser-Rechten systemweit zu installieren.Normalerweise wird sie ins  $HOME-Verzeichnis des aktuellen Nutzers installiert. Alles was mit systemweiten Installationen und Shared-Apps-Kram zu tun hat wird über PackageKits Listaller-Erweiterung erledigt, mehr dazu später 🙂

Natürlich wird noch mehr Information über die Anwendung angezeigt, wie etwa deren Beschreibung oder – wie im Screenshot oben – die Softwarelizenz.

Schließlich wird die Installation dann ausgeführt. Wenn der Listaller die Anwendung systemweit installieren will, wird ein entsprechender PolicyKit-Dialog angezeigt, der eine Authorisierung verlangt.

Der Listaller wird dann alle Abhängigkeiten der Software auflösen. Momentan unterstützt der Listaller nur die nativen Distributionsquellen als Quelle für Abhängigkeiten, aber er wird später auch ZeroInstall-Feeds als Alternative unterstützen.

Wenn die Installation abgeschlossen ist, erscheint Osmos genau wie jede andere Anwendung auch im Anwendungsmenü von KDE oder GNOME:

Eine Besonderheit hat dieser Anwendungsstarter jedoch: Anstatt Osmos direkt zu starten, wird Listallers runapp Werkzeug mit dem Anwendungsnamen als Parameter ausgeführt.

Das ist aus verschiedenen Gründen notwendig: In erster Linie setzt “runapp” einige Umgebungsvariablen, welche es Osmos ermöglichen, seine Abhängigkeiten zu finden. Zweitens ist “runapp” auch dafür da, Osmos in einer Sandbox auszuführen, damit es mit minimalen Rechten ausgeführt werden kann. Sandbox-Unterstützung ist aktuell in Arbeit, geplant ist die Arkose Sandbox als Sandbox zu verwenden. Das “runapp” Werkzeug ermöglicht auch einfaches Scripten, zudem kann es die Ausführung von Anwendungen verhindern, z.B. wenn der Systemadministrator 3rd-party software (z.B. Skype) blockieren will. (natürlich kann man das leicht umgehen, aber immerhin hat man ‘ne Warung gesehen, dass man es besser nicht versuchen sollte.) Ein paar dieser Features müssen noch implementiert werden. (Und ich bin mir nocht nicht Sicher, ob das Anwendung-Blocken überhaupt sinn macht, daher ist dieses Feature auch noch auf der Liste mit “Possible Features” (und hat geringe Priorität))

So, Osmos funktioniert nun also (mit “runapp”)

Wenn man das freisch installierte Osmos-Spiel wieder loswerden will (warum?) könnte man sehr einfach limanager-gtk starten, ein grafisches Werkzeug was für das Entfernen von (Listaller) Anwendungen verantwortlich ist. Wenn Osmos als gemeinsame Anwendung mit Superuser-Rechten installiert wurde, gibt es aber auch einen anderen, besseren weg es wieder zu entfernen: PackageKit.

Wenn PackageKit mit einem Patch für Listaller übersertzt wurde, können alle PK frontens Listaller-Anwendungen entfernen und updaten. Damit sind Listaller-Anwendungen wirklich perfekt ins restliche System integriert. Natürlich kommuniziert Listaller auch mit Modulen des AppStream-Projektes, was es z.B. auch dem Ubuntu Software Center ermöglicht, mit Listaller-Software fertig zu werden. (entsprechender Code ist aber von beiden Seiten – Listaller und AppStream – noch nicht fertig)

Wie zu sehen ist, wird Osmos (Demo) in GNOME-PackageKit angezeigt und zum Entfernen angeboten, genau wie jedes andere, native Paket.

Das funktioniert natürlich auch mit Apper unter KDE und jedem anderen PackageKit Frontend.

Okay, das war der kurze Überblick über das, was der Listaller momentan kann. Es gibt noch immer unglaublich viel Arbeit zu tun, z.B. der Code zum Auflösen von Abhängigkeiten muss verbesert werden (und vor allem erweitert) und die grafischen Oberflächen sind auch noch keine Freude.

Daher suchen wir natürlich noch immer Hilfe für dieses Projekt, Kontakt geht z.B. über die Mailingliste. Und nicht vergessen: Listaller-Releases wird es jetzt häufiger geben, dank geändertem Release-Modell 🙂 (aber natürlich bekommt nicht jedes Release einen Blogpost wie diesen :D)

Achja, im englischen Beitrag habe ich’s ja schon fast vergessen:

Freue mich drauf 🙂

Dieser Beitrag erschien zuerst in Englisch.