AA_leather_swer_rock_sxc_1208703.jpg

© Swer_rock, sxc.hu

Nahtlos eingepasst

Software-Installation aus systemeigenen und anderen Quellen

21.11.2012 Die Integration von Listaller in die PackageKit-Infrastruktur eröffnet neue Perspektiven auf das plattformübergreifende Installieren von Software.

Das Paketmanagement von Linux symbolisiert für einerseits den ultimativen Vorteil gegenüber Windows. Auf der anderen Seite scheitern Einsteiger trotz aller unbestreitbaren Vorteile einer konsistenten Paketdatenbank regelmäßig am an Tatsache, dass verschiedene Konzepte zur Software-Installation unter Linux existieren. Die zwei weit verbreiteten, jedoch zueinander inkompatiblen Systeme RPM und DEB sowie die Möglichkeit, Software aus den Quellen zu übersetzen, tragen viel zu Unübersichtlichkeit bei.

Da wundert es kaum, dass es seit Jahr und Tag Bemühungen gibt, Einsteiger von den Details der einzelnen Formate fernzuhalten und ein übergreifendes Paketformat nebst zugehörigen Werkzeug zu implementieren, das durch die Bank auf den meisten Distributionen funktioniert. Zu den aktuellen und ehemaligen Vertretern der Kategorie gehören Autopackage, MojoSetup oder ZeroInstall.

Alleskönner

Der von Richard Hughes seit 2007 entwickelte Schnittstelle zum Paketmanagement, PackageKit [1], kommt in diesem Zusammenhang ebenfalls eine zentrale Bedeutung zu. Sie stellt ein Interface für unterschiedlichste Paketsysteme bereit (siehe Kasten "Mit den richtigen Rechten").

Mit den richtigen Rechten

Das seit 2007 von Richard Hughes entwickelte PackageKit arbeitet als Abstraktionsschicht zu den unterschiedlichen Paketverwaltungen. Dabei nutzt es PolicyKit zum Überprüfen der Berechtigungen und D-Bus für die Interprozesskommunikation. Ein Daemon startet bei Bedarf zum Abwickeln der Aktionen. Alternativ zu D-Bus kommunizieren Applikationen über eine eigens geschriebene Bibliothek mit dem Framework.

Hughes hat in einer sehr ausführlichen Präsentation alle wichtigen Details rund um die Software und deren Idee zusammengestellt (PDF, [9]). Darin kritisiert er, dass die bisherige Entwicklung von Paketformaten zwar technisch erstklassige Produkte hervorgebracht habe, der Anwender aber oft verloren vor konfusen Dialogen oder kryptischen Fehlermeldungen stünde. Die Idee von PackageKit: Es will in einer weiteren Schicht für mehr Klarheit und Einfachheit sorgen.

Während anfangs nur Fedora (ab F9) und Foresight Linux 1.4.1 die Technik nutzten, wechselte Kubuntu als erste Debian-basierte Distribution ab Version 9.04 auf PackageKit. Heute sind die KDE-Frontends Apper und KPackageKit und das Gnome-Frontend Gnome-Package mit der Schnittstelle kompatibel.

Für die Entwicklung von Listaller ist das Projekt Autopackage von besonderer Bedeutung. Es stammt aus dem Jahr 2002 und hatte die einfache Installation von (Third-Party-)Software zum Ziel, unabhängig von der verwendeten Linux-Distribution. Autopackage funktioniert relativ einfach: Im Prinzip verbirgt sich dahinter ein Shell-Skript, das das zu installierende Programm bereits enthält und das – bis auf die Bash – keine zusätzliche Software braucht.

Idealerweise sollte der gesamte Installationsprozess keine Interaktion mit dem Benutzer erfordern. Abhängigkeiten lösen die Paketverwaltungen in der Regel automatisch auf.

Zweckehe

Allerdings ging es mit dem Projekt nicht wie gewünscht voran. Mike Hearn hat die Software acht Jahre lang entwickelt. Im Jahr 2010 stellte er jedoch die Arbeit daran ein und bündelte seine Kräfte mit dem Projekt Listaller [2]. Letzteres startete Matthias Klumpp 2007 als Experiment, um herauszufinden, wie aufwändig es wäre, ein universelles Interface zu entwickeln, das alle unter Linux relevanten Arten von Software verwaltet.

Durch den Zusammenschluss mit Listaller erschienen den Entwicklern einige Bestandteile von Autopackage obsolet. Auch das Format der Pakete passten sie an die Spezifikation von Listaller an. Trotz einiger bemerkenswerte Fortschritte insbesondere bei der aktuellen Version 0.5.5 hat das neue Projekt bisher allerdings den experimentellen Status nicht verlassen: Es gibt also noch keine "offizielle" Version der Software.

Der Entwickler arbeitet übrigens parallel für OpenSuse am AppStream-Projekt ([3],[4]) mit und gehört zu den Upstream-Entwicklern von PackageKit. Sein Listaller-Projekt hat kein geringeres Ziel, als das Installieren eines Paketes auf verschiedenen Distributionen so einfach und sicher wie möglich zu machen – und das bei bestmöglicher Integration in die Mutterdistribution. Zusätzlich kooperiert Klumpp mit dem Projekt ZeroInstall.

Seit der Version 0.3a arbeitet das Programm Listaller mit PackageKit als Backend zusammen und profitiert somit über dessen Schnittstelle zu PolicyKit in Bezug auf die Rechteverwaltung. Außerdem ermöglicht diese Kooperation, dass Frontends, die auf PackageKit aufsetzen, zusätzlich die mit Listaller installierten Pakete sehen und verwalten.

Das Listaller-eigene Paketformat IPK erlaubt es, auf sehr einfache und flexible Weise Software auf beliebigen Distributionen zu installieren. Matthias Klumpp betont allerdings immer wieder, dass Listaller keinesfalls das bestehende Paketmanagement ersetzen soll, sondern es lediglich ergänzt.

Die Skripte des Listaller-Paketformats IPK weisen eine ähnliche Syntax auf wie die von Debian-Paketen. Die Software komprimiert die Packages automatisch mit LZMA und ermöglicht es außerdem, sie mit GPG zu signieren. Seit der Version 0.4b lagern große Teile der ursprünglichen Funktionen in separaten Bibliotheken, was das Schreiben neuer Frontends in anderen Sprachen erleichtert.

Einen in älteren Versionen von Listaller noch vorhandenen internen Software-Katalog hat der Entwickler inzwischen mit der Begründung gekippt, dass es keinen Sinn mache, den inzwischen sehr guten Software-Stores der Distributionen (etwa Ubuntu Software Center) eine weitgehend ähnliche Technologie mit gleichen Funktionen gegenüber zu stellen. Über einen distributionsübergreifenden Store für Kaufsoftware denkt Klumpp hingegen durchaus nach und will dazu in Zukunft mit dem Pappi-Projekt [5] kooperieren.

AppStream

Anfang 2011 geriet die Arbeit am Listaller-Projekt merklich ins Stocken. Klumpp sah sich sogar in seinem eigenem Blog [6] im Februar 2011 genötigt, die ursprünglichen Ziele des Projektes vorerst für gescheitert zu erklären. Als Grund gab er den selbst auferlegten Perfektionismus an, in Verbindung mit einem latenten Mangel an fähigen Entwicklern.

Paradoxerweise hatte diese Verzögerung auch mit dem ebenfalls unter Beteiligung von Matthias Klumpp voran getriebenen AppStream-Projekt zu tun. Bei AppStream handelt es sich um den Versuch, aufbauend auf PackageKit ein einheitliches Softwaremanagement für die distributionseigenen Pakete zu entwickeln. Es stammt aus der Feder bekannter Entwickler aus unterschiedlichen Distributionscommunities.

Aufgrund der gemeinsamen Anstrengungen war bald klar, das AppStream im Bereich des klassischen Paketmanagements fast alles besser erledigte als Listaller. Letzterer ermöglicht dagegen mit seinen Build-tools und dem IPK-Format eine echtes Setup über Grenzen hinweg.

Versionssprung

Listaller ist jedoch keineswegs tot: Die im Mai des Jahres erschienene Version 0.5.4 brachte bereits zahlreiche Neuerungen. Matthias Klumpp hat nicht nur die gesamte Codebasis quasi neu geschrieben, sondern diese in die drei Teile listaller-core, listaller-devtools und listaller-gui aufgeteilt (siehe Kasten "Listaller intern").

Listaller intern

Matthias Klumpp hat bei der Version 0.5.4 beinahe die komplette Code-Basis überarbeitet, beziehungsweise neu entwickelt. War Listaller anfangs noch in Pascal programmiert, entschied sich Klumpp später für Vala als Programmiersprache, was eine bessere Integration mit den anderen unter Verwendung der Glibc geschriebenen Programmen erlaubt. Zudem ließ sich der Pascal-Code relativ leicht in Vala-Code umschreiben. Derzeit befindet sich der Management-Teil des Programms in der Transformation von Pascal zu Vala, der IPK-Installer beruht weiterhin auf Pascal. Erst nach und nach will der Entwickler die Tools für die Kommandozeile portieren.

Zurzeit erlauben die IPK-Spezifikationen Entwicklern, die Ihre Software mit diesem System verteilen möchten, noch relativ viele Freiheiten. Nach Rücksprache mit den AppStream-Entwicklern will Klumpp aber die Möglichkeiten künftig einschränken, darunter die Installation in systemeigene Verzeichnisse oder das Nachladen von nativen Paketen aus dem Netz. Ferner will er das Tool Runapp modifizieren, um Listaller-Anwendungen in Zukunft in einer Sandbox auszuführen. Das minimiert das Risiko, das System zu beschädigen. Als Sandbox-Technologie kommt Arkose zum Einsatz.

Das Modularisieren vereinfacht nicht nur das Verwalten des Codes, sondern ermöglicht, in Zukunft einzelne Module unabhängig zu veröffentlichen. Tritt ein Fehler im GUI-Modul auf, lässt sich dieser nun schnell beheben, ohne dass ein neues Release das gesamte Paket umfassen müsste. Das Gleiche gilt für die Entwickler-Tools.

Das Kernmodul enthält alles, was Sie zum Betrieb des Programms unbedingt benötigen, darunter wichtige Anwendungen für die Kommandozeile und grundlegende Bibliotheken. Die Devtools enthalten alles, was zum Bauen von IPK-Paketen notwendig ist.

Was das Verwalten der Software angeht, klinkt sich die Applikation in PackageKit ein. Das bedeutet, das Listaller generell alle Programme kennt, die mit dem Framework zusammenarbeiten. Update für diese Programme ziehen Sie alternativ über die PackageKit-Frontends nach. Umgekehrt können auf PackageKit aufbauende Paketmanager wie Apper auch reine Listaller-Anwendungen zu verwalten.

Mit Listaller 0.5.4 ermöglicht es die Software ein Paket für mehrere Prozessorarchitekturen zu erstellen. Nur wenige Wochen nach der Version 0.5.4 schob Matthias Klumpp die zur Zeit aktuelle Version 0.5.5 nach. Mit Version 0.6 plant er dann, die Software als stabil zu kennzeichnen.

Listaller unterstützt allerdings aus den oben angeführten Gründen ausschließlich Anwendungen, jedoch keine Pakete mit komplexen Abhängigkeiten, wie Gnome oder KDE. Ebenfalls tabu sind Systemkomponenten und Systembibliotheken. Für diese gilt es weiter die originalen Werkzeuge der Distribution zu verwenden.

Erster Test

Haben Sie Listaller installiert, ist der Weg frei, um unter KDE mit Apper jede Form von Anwendung zu verwalten – egal ob Sie diese via Autopackage, LOKI, IPK-Setup oder dem Paketmanagement der Distribution installiert haben.

Möchten Sie den unter der GPLv3 lizenzierten Listaller ausprobieren, gelingt das zur Zeit am einfachsten unter Kubuntu, weil auf Lauchpad ein PPA [7] existiert, das Sie einfach in Ihr System integrieren (Abbildung 1). Nutzer anderer Distributionen müssen Listaller aus den Quellen übersetzen.

Abbildung 1

Abbildung 1: Entwickler Matthias Klumpp stellt für Ubuntu ein PPA zum Installieren bereit.

Das Integrieren der PPA-Quelle funktioniert zum Beispiel über das Werkzeug beziehungsweise den Menü-Eintrag Einstellungen | Paketquellen in Synaptic, sofern Sie die GTK-Paketverwaltung unter KDE installieren möchten.

Nach einem Klick auf Neu laden installieren Sie wahlweise über Synaptic, das Kommandozeilentool Apt-get oder mit dem KDE-Frontend Apper eine aktualisierte Version 0.7.5-1 von PackageKit sowie das Paket listaller (für das Listaller-Kernsystem). Ubuntu 12.04 LTS "Precise Pangolin" bringt von Haus aus die Version 0.7.2-4 von PackageKit in den eigenen Paketquellen mit.

Eine spezielles GUI benötigen Sie unter KDE (Kubuntu) nicht, da viele Funktionen von Listaller in dem auf PackageKit basierenden Apper bereitstehen. Sie können allerdings über die genannte PPA-Paketquelle auch das Paket apper-appsetup einrichten, das erweiterte Listaller-Funktionen in Apper aktiviert.

An Gnome-Frontends stehen über die genannte Paketquelle zudem die Werkzeuge listaller-gnome-manager und listaller-gnome-setup zur Verfügung. Möchten Sie Third-Party-Tools mit Listaller selbst einpacken, müssen Sie zudem das Paket listaller-tools installieren (Abbildung 2).

Abbildung 2

Abbildung 2: Entwickler, die Ihre Software im Listaller-Format paketieren wollen, brauchen zudem die listaller-tools.

Versierte Nutzer, die eine aktuelle Apper-Version aus den Quellen installieren möchten, müssen für vollen Listaller-Support den Quellcode mit der Option -DLISTALLER=ON übersetzen.

Zu den erweiterten, in Apper enthaltenen Funktionen gehört etwa die Möglichkeit, Pakete unter /home/users zu installieren, sowie das Update normaler Pakete über den Listaller-eigenen Updater. Darüber hinaus können Entwickler Update-Quellen für ihre Software automatisch aus dem Quellcode des Projektes generieren.

Möchten Sie testen, wie Sie mit Listaller Pakete im IPK-Format installieren, stehen derzeit lediglich einige wenige Demo-Anwendungen auf der Projektseite [8] bereit. Um ein solches Paket einzurichten, öffnen Sie es mit dem PackageKit-Frontend Ihrer Wahl (Apper oder Gnome-PackageKit).

Abbildung 6

Abbildung 6: IPK-Pakete installieren Sie einfach per Klick, beziehungsweise Kontextmenü Öffnen mit | Apper.

Fazit

Listaller beruht auf einem durchdachtem Konzept und bietet den Vorteil der hohen Integration mit existenten Technologien. Daraus resultiert ein hoher Grad an Nutzerfreundlichkeit, denn mit Listaller können Sie einerseits weiterhin mit Ihren gewohnten Frontends (etwa Apper oder Gnome-PackageKit) Anwendungen aus den Paketquellen einrichten, aber auch Anwendungen verwalten oder entfernen, die Sie auf anderem Wege installiert haben.

Die Nützlichkeit und damit letztendlich das Potenzial, neue Softwarepakete künftig in einem systemunabhängigen Format installieren zu können, hängt allerdings letztlich ganz von der Bereitschaft der Entwicklergemeinde ab, Pakete im Listaller-eigenen IPK-Format zu schnüren. 

Tip a friend    Druckansicht beenden Bookmark and Share
Kommentare