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:

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.

10 Comments

  • FERNmann commented on 25. June 2011 Reply

    Schönes Release, da steckt sicher viel Arbeit drin! Besonders gut gefällt mir die PackageKit-Integration, sodass man die Anwendungen über ein Frontend verwalten kann und die Wahlmöglichkeit zwischen Root- und Home-Install.

    Weil du wegen dem Dialog gefragt hast: Ich bin zwar nicht so der Gtk-Guru (und Vala hab ich noch gar nicht benutzt), aber trotzdem:
    -Die Buttonreihenfolge sollte lauten: Abbrechen – Zurück – Vor, das ist eher die Konvention bei GNOME, siehe Evolution oder Empathy.
    -Die Checkbox “Install for all Users” sollte unter den Dependency details sein. Ich finde, es ist hier besser Info- und Control-Widgets räumlich zu trennen.
    -“Security information” sieht linksbündig besser aus, damit es zu den Dependency details passt.
    -Vielleicht nutzt dus eh schon, aber in Gtk gibt es das Widget GtkAssistant, das einem hier die Arbeit abnimmt. Die erstellten Assistenten sehen dann auch recht ordentlich aus.

    • Ximion commented on 25. June 2011 Reply

      Danke!
      Alle Oberflächen sind mittels Glade realisiert und sollten das auch bleiben, dadurch ist der Vala-Code nämlich schön kompakt.
      Die unteren grafischen Elemente müssen nochmal genau überdacht werden, vielleicht gibt’s für diese Einstellungen dann auch eine Extraseite, da ich sie auf der ersten Seite sehr störend finde.
      Ich würde sehr gerne einen GtkAssistant verwenden, aber irgendwie lässt mich Glade keine eigenen Seiten zum Assistent hinzufügen und alle anderen Entwickler setzen GtkAssistants immer im Quellcode zusammen (während für den Rest Glade benutzt wird) – Ich denke ich frage mal auf der Glade-Mailingliste nach, ob das ein Bug ist.

      • FERNmann commented on 26. June 2011 Reply

        Hm, das ist bei mir auch so (Glade 3.8, GTK+ 2.24). Ich kann zwar die Seitenzahl des Assistenten erhöhen, aber in den Seiten keine eigenen Widgets hinterlegen.

  • Pa_trick17 commented on 26. June 2011 Reply

    In was für einer Programmiersprache war Listaller denn vorher verfasst und was waren die Entscheidungsgründe für ein Refactoring mit Vala?

    Gruß

    Patrick

    • Ximion commented on 26. June 2011 Reply

      Zuvor waren große Teile des Listaller in Object Pascal (mit der LCL-Widgetset-Abstraktion) geschrieben, was zur Folge hatte, dass ich die Hälfte der Zeit mit dem Schreiben von Pascal-Bindings beschäftigt war.
      Erst wollte ich Teile des Listaller in GLib/C refactor’n, allerdings gab es da schon mit Vala eine Alternative, die mir nativen C-Code beschafft und die nicht so Wartungsintensiv bzw. aufwändig in der Handhabung ist wie C.
      Ich würde Vala jederzeit wieder wählen – die Sparche hat sich zu 100% bewährt, vor allem da man sie wirklich toll mit GLib/C und C++-Code kombinieren kann.

  • Tomboy commented on 26. June 2011 Reply

    Listaller Finde ich eine Tolle Sache. Könnte man damit auch einem Programm schon bei der Installation den Internet-Zugriff verweigern? (Vorausgesetzt die Sandbox ist fertig integriert)

    Befehle wie “lisetup-gtk” oder “limanager-gtk” finde ich viel zu lang. “lis” oder “lim” fände ich viel angenehmer.

    dein Projekt tönt schon mal spannend. Vor allem für leute wie mich, die gerne auch mal weniger vertrauenswürdige software installiert weil er neugierig ist. damit könnte ich ein weiteres Sicherheitselement einbauen.

    • Ximion commented on 27. June 2011 Reply

      Die Befehle wirst du später nicht mehr eingeben müssen, dann reicht ein Doppelklick auf das Programmpaket oder einen Menüeintrag.
      Die Sandbox ist genau für solche Zwecke da – ich könnte mir z.B. vorstellen, dass Anwendungen wie ein Webbrowser bei der Installation wie bei Android Web-Zugriff verlangen können (was man aber natürlich auch ablehnen kann)
      Per Default wir eine Anwendung aber mit so wenig Rechten wie möglich laufen, d.h. kein Zugang zum Internet und kein direkter Zugriff auf $HOME.

  • Ubukus commented on 26. June 2011 Reply

    Läßt sich dieser Listiller irgendwo runterladen und unter Ubuntu installieren und benutzen?
    Ich habe mal rumgesucht und leider nichts finden können.

    • Ximion commented on 27. June 2011 Reply

      Produktiv verwenden lässt sich momentan noch nichts, hat alles noch eher den Status eines Experiments.
      Ich würde empfehlen, den Listaller zum Testen direkt aus dem Quellen zu kompilieren (die sind übrigens hier: http://gitorious.org/listaller )
      Es existiert zwar auch ein Ubuntu-PPA, das ist aber wirklich 100% experimentell: https://edge.launchpad.net/~ximion/+archive/packagekit

      • Ubukus commented on 27. June 2011 Reply

        Na ja, dann warte ich erst mal die weitere Entwicklung ab. Klar ist, daß ein ditributionsübergreifendes Installationstool schon seit Jahren überfällig ist…

Leave a Reply

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