Die meisten werden bereits vom AppStream-Projekt gehört haben. Kurz gesagt versucht AppStream, das Software-Management unter Linux zu vereinfachen, z.B. in dem dem Nutzer Anwendungen anstelle von Paketen präsentiert werden und über weitere Kollaborationsfunktionen (Kommentare etc.). Dies alles läuft auf einer distributionsübergreifenden Ebene. – Aber Moment – war nicht gerade das das ultimative Endziel des Listaller-Projektes?
Stimmt. Listaller wurde im Jahr 2007 von mir als experimentelles Projekt gestartet, um Software-Management und Installation unter Linux so einfach wie möglich zu machen. Um es klar auszudrücken: Im Grunde hat das Projekt dieses Ziel komplett verfehlt. Grund dafür war Entwicklermangel und damit eine langsame Entwicklung, so wie meine Idee, Listaller möglichst sofort allen Recht zu machen. Listaller sollte das ultimative Werkzeug zum Anwendungsmanagement werden, also kam Feature um Feature hinzu. Gleichzeitig sollte Listaller aber auch so gut wie möglich werden, was nicht enden wollende Testreihen auf verschiedenen Distributionen nach sich zog. (Und mit jedem Feature kommen auch neue Bugs mit rein) Damit wurde Listaller 0.5 praktisch bis heute nicht fertig gestellt. Zudem habe ich zu wenig mit den Distributoren kommuniziert, was auch damit zusammen hing, dass ich ein fertiges Konzept vorweisen wollte.
AppStream hingegen hat alles richtig gemacht, in Sachen Kommunikation mit dem AppInstaller-Meeting in Nürnberg und in Sachen Konzept sowieso. Zudem wurde es von bekannten Entwicklern aus drei Distributions-Communities ins Leben gerufen.
Jetzt könnte man denken, Listaller einfach wegzuwerfen und stattdessen komplett auf AppStream umzuschwenken, da AppStream doch alles besser macht, was Listaller kann. Das stimmt so nicht. AppStream macht alles, was mit Software-Management zu tun hat. Aber Listaller hat zusätzlich noch das Modul für distributionsübergreifende Software-Installation, was Listallers build-tools und das IPK-Format als cross-distro Setup-Format einschließt. Diese Funktionen sind auch für AppStream wertvoll, als eine Ergänzung zum aktuellen Konzept. Daher habe ich das Konzept, wie Listaller entwickelt wird und was er momentan kann, grundlegend überarbeitet, um eine klare Linie für die Zukunft festzulegen:
Entwicklungsprozess
Listaller 0.5, was schon vor Monaten released werden sollte, wird offiziell nicht erscheinen. 0.5 wird stattdessen eine reine unstable-serie werden, um die aktuellen Listaller-Entwicklungen zu testen. Listaller 0.6 wird dann wieder ein stabiles Release werden.
Zudem wird die aktuelle Codebasis in drei Teile aufgesplittet: listaller-core, listaller-devtools und listaller-gui. Listaller in drei Module aufzuteilen, macht das Verwalten des Codes viel einfacher. Zudem können die einzelnen Module nun unabhängig veröffentlicht werden, sodass GUI-bugs nicht erst auf ein neues Release des Listaller-Gesamtpaketes warten müssen, um behoben zu werden. (gleiches gilt für die devtools) Listaller-core wird alles enthalten, was zum Betrieb des Listallers allgemein nötig ist, dazu zählen wichtige Kommandozeilenanwendungen, die Sprachbindungen, wie z.B. die Qt-Bibliothek etc.. Listaller-devtools wird alles enthalten, was zum bauen von IPK-Paketen oder nur für Entwickler relevant ist, wie z.B. “libuild”, “binreloc” oder “visual-ldd”. Listaller-gui wird die grafischen Nutzerschnittstellen für GTK+ und Qt bereitstellen.
Generelle Konzepte
Obwohl ich Pascal für eine tolle Sprache halte, ist es keine gute Wahl für ein projekt wir Listaller. Zusammenarbeit mit anderen Projekten wird dadurch schwerer, zudem verbringt man einige Zeit mit dem schreiben von Bindungen für Pascal. Also habe ich nach alternativen Sprachen gesucht, alleine schon, um die Sprachvielfalt in der Codebasis zu reduzieren. In die engere Wahl kamen C++, GLib/C und Vala. Erst wollte ich C++ nehmen, habe mich dann aber doch für Vala entschieden, primär auf Grund der besseren Integration mit allen anderen in GLib/C geschriebenen Sprachen, und weil man Pascal Code relativ leicht in Vala-Code umschreiben kann. (Vala wird in GLib/C umgewandelt und dann erst kompiliert) Zunächst wird nur der Management-Teil des Listallers in Vala geschrieben, der IPK-Installer bleibt Pascal. Nach und nach werden dann die Kommandozeilentools umgewandelt, bis später alles Vala ist.
Die Spezifikationen von IPK gestehen dem Software-Entwickler momentan eine große Menge an Freiheiten zu, wie seine Software installiert wird. Nach einem Gespäch mit anderen AppStream-Entwicklern wurde ich aber davon überzeugt, dass es besser ist, gar nicht erst so viele Möglichkeiten zu lassen. Daher werden die IPK/IPS specs angepasst, um weniger Möglichkeiten zu bieten, wie z.B. Installationen in Systemeigene Ordner oder das Nachladen von nativen Paketen aus dem Netz. Zudem wird das “runapp” tool modifiziert, um Listaller-Anwendungen in Zukunft in einer Sandbox auszuführen. Damit wird das Risiko, das System zu beschädigen, weiter minimiert. Momentan ziehe ich Arkose als Sandbox für Listaller in Betracht. Listaller wird insgesamt größere Verantwortung über IPK-Pakete übernehmen, damit distributoren Listaller ihrer eigenen Politik anpassen können und nicht jedes Softwarepaket eigene Regeln aufstellen kann. (Alles im Dienste der Systemsicherheit) Zudem wird der gesamte Prozess, wie Abhängigkeiten verarbeitet werden überarbeitet.
Ich hoffe, dies wirft Licht in die Zukunft des Listallers. Das Projekt ist längst noch nicht tot 🙂
Wie immer: Wir suchen noch Listaller Entwickler 😉
Hi.
Prinzipiell ne geile Idee, aber wäre es nicht sinnvoll, sich mit dem AppStream-Projekt zusammen zu tun und nur das fehlende Installationsgedöhns 😉 einzupflegen? Wäre deutlich weniger Arbeit, soweit ich das von Außen beurteilen kann. Dann würde man nicht vor so einer riesigen Aufgebe stehen, sondern hätte nur sein “kleines” Spezialgebiet.
Genau das tue ich 😛 AppStream ist ja nicht mehr als eine Sammlung an Spezifikationen und Anwendungen, welche diese implementieren.
Die folgenden Versionen von Listaller werden sich genau an die AppStream specs halten, womit der Listaller dann nur ein weiteres Tool im AppStream Spektrum wäre. (Momentan ist aber noch nicht sicher, ob Listaller “dazu gehören” wird, da einige Entwickler auch einen Klik-ähnlichen Ansatz bevorzugen. (Welcher aber in der Realität extreme Nachteile hat))
Einziges Problem an der Sache: Der Listaller wird in Zukunft auf Distributionen ohne AppStream-Unterstützung nicht mehr laufen. Auch PackageKit ist eine zwingende Vorraussetzung. (wird aber kein soo großes Problem, da alle großen Distributionen AppStream-Komponenten ausliefern werden.)