ACHTUNG! Das ist keine Übersetzung der Releaseankündigung des Listallers! Die Ankündigung findet sich auf dieser Seite. (englisch)
Endlich kann ich mal ein Release des Listallers ankündigen! Es hat über 9 Monate gedauert, dieses Release fertig zu stellen, was vor allem am enormen Schwund an Entwicklern liegt. (viele hatten zu viel an der Uni zu tun, um sich noch weiter um den Listaller zu kümmern)
Der Listaller, für die, die das Projekt noch nicht kennen, ist ein distributionsübergreifendes Tool, um Software auf Linux-Systemen zu verwalten. Das Projekt basiert auf Richard Hughes’ PackageKit und ist quasi eine Erweiterung von dessen Funktionen. Der Listaller stellt ein Metapaketformat zu Verfügung, welches einen sehr einfachen und flexiblen Weg bereitstellt, Software mit nur einem Paket auf vielen Linux-Distributionen zu installieren. Zudem kann man existierende installierte Anwendungen mit dem Listaller verwalten.
Der Listaller 0.4b verfügt über folgende neue Funktionen:
- Generelles Code-Aufräumen: Viele Teile des Listallers sind neu geschrieben worde.
- IPK1.0 Format: Das Paketformat verwendet jetzt eine ähnliche Syntax wie die, die bei Debian-Paketen zum Einsatz kommt. Die neue Formatierung ersetzt das alte XML-basierte Format, wodurch IPK-Scripte besser lesbar werden sollen.
- Vollständige PackageKit-Integration: Die alte Paketinstallationslösung wurde vollständig durch PackageKit ersetzt, welches jetzt fix integriert ist. (und nicht nur als Plugin zu Verfügung steht) In vorigen Versionen hat der Listaller noch direkt Verbindungen zu APT/Yum/Zypper etc. durch eine eigene Abstraktionsschicht hergestellt. Stattdessen wird jetzt PackageKit verwendet.
- Neue libInstaller: Eine Bibliothek, welche alle Listaller Funktionen enthält. Damit sind neue Sprachbindungen (für Python/C++) möglich.
- Katalog entfernt: Die Distributoren haben während der Entwicklungszeit von Listaller 0.4b sehr gute Software-Stores entwickelt. Zudem werden wir mit dem PAPPI-Projekt zusammenarbeiten, welches die nun fehlende Funktion vielleicht ersetzt. Bis jetzt hat keiner der Tester den Software-Katalog vermisst 😛
- Überarbeitete grafische Oberflächen und Qt4-Versionen der GUIs
- IPK-Pakete sind jetzt LZMA-komprimiert (macht sie über 20% kleiner, je nach Inhalt)
- PolicyKit Unterstützung für alle Module des Projektes
Und das sind nur die wichtigsten Punkte. Im Grunde wurde bei der Entwicklung kein Stein auf dem Anderen gelassen.
Mit diesem Listaller-Release können jetzt erstmals sehr einfach IPK-Pakete erstellt werden. Leider kann ich aber eine vollständige Stabilität des IPK-Formates nicht garantieren, obwohl das eines der Ziele des 0.4b Releases war. Dies ist aber wir vieles Andere auch dem Entwicklermangel zum Opfer gefallen. Der Listaller Manager kann in der aktuellen Version mit folgenden 3rd-Party Installationssystemen umgehen: LOKI, Mojo, Autopackage, Natives, IPK. Unterstützung für ZeroInstall ist geplant. Dies bedeutet, dass man mit dem Listaller Anwendungen wie GoogleEarth so leicht entfernen kann wie im Paketmanager, auch wenn sie nicht als Paket installiert wurden.
Wegen der geringen Zahl der Entwickler konnten wir auch einige der Tests auf verschiedenen Distributionen nicht durchführen. Daher hoffen wir darauf, dass die Nutzer den Listaller ausgiebig auf verschiedenen Distributionen testen. (Bis jetzt funktionieren Ubuntu 10.04, Debian Sid und Fedora 13)
Ein der tollsten Neuigkeiten des Projektes ist unsere Kooperation oder unser Zusammenschluss mit dem PAPPI-Project. PAPPI – eine Kurzform für “Personal Applikation Installer” – ist ein Projekt, welches einen distributionsunabhängigen Software-Store für Linux verfügbar machen möchte. Das Projekt ist aus der Ubuntuusers-Community bekannt. Zur Zeit erstellen wir eine Roadmap für die Listaller <> PAPPI Kooperation. So könnte z.B. PAPPI als SoftwareStore in den Listaller integriert werden, währen PAPPI Listallers IPK-Format verwendet. (IPK verfügt über einige Features, die bei PAPPI schon auf der Roadmap stehen, z.B. Signaturen)
Apropos Roadmap: Jetzt wo der Listaller 0.4b fertig ist, werden natürlich erstmal alle Fehler darin behoben, das ist die Hauptaufgabe der nächsten Wochen. Aber auch für Listaller 0.5 existieren natürlich schon Pläne. So könnte der Installer dann Multi-Architektur-IPKs unterstützen, welche binäre Dateien für mehrere Architekturen enthalten, z.B. für AMD64 und i386. Die richtigen Dateien werden dann während der Installation ausgewählt. Das könnte für Firmen, welche Linuxspiele vertreiben sehr nützlich sein. (Wenn man an Ryan Gordon‘s FatELF Projekt denkt, scheint ein Bedarf da zu sein.) Auch verschiedenene Geschwindigkeitsverbesserungen sind geplant. Zudem soll es eine C++-Implementation des Listaller Manager geben, welche sich schön in den KDE-Desktop integriert.
Wer jetzt den Listaller einmal ausprobieren möchste, findet vorkompilierte Pakete für neuere Distributionen (mit PackageKit >= 0.5.6) auf unsererer Downloadseite. Alternativ kann der Listaller natürlich auch direkt aus den Quellen kompiliert werden. Um eine IPK-Installation auszuprobieren, empfehle ich das Spiel “Osmos” bzw. dessen Demoversion. Das IPK-Paket zu Osmos kann von unserem getIPK heruntergeladen werden.
Wer dem Projekt in irgendeiner Form helfen will (Entwickler/Sponsor/Designer) kann mich gerne direkt kontaktieren. Bugmeldungen zum aktuellen Release sind ebenfalls (anders als die Bugs selber) sehr gerne gesehen. Dafür steht der Bugtracker auf Launchpad bereit.
Viel Spaß!
Klingt ziemlich interessant. Ist ja generell ein Problem von Linux, dass es so viele Paketmanager gibt, und dann noch zusätzlich die binären Installer, meist bei proprietärer Software, die an der Paketverwaltung vorbei installieren. Da ist der Listaller sicher ganz praktisch, dann müssen sich die Distributionen nicht selber auf ein eigenes Paketformat einigen, was erfahrungsgemäß wegen der unterschiedlichen Philosophien nicht ganz einfach ist.
Wie ist beim Listaller denn das Problem mit den Abhängigkeiten gelöst? ES gibt ja bereits Tools, wie alien, mit denen man RPM-Pakete auf Debian-Systemen installieren kann und umgekehrt, aber da gehen die Abhängigkeiten verloren, da die entsprechenden Pakete unter den verschiedenen Distributionen ja unterschiedliche Namen haben.
Entweder gibt der Entwickler für jede Distribution die richtigen Pakete im IPK-Paket an, oder aber es werden nur die Namen der nötigen Bibliotheken gespeichert. Der Listaller sucht und installiert während der Installation dann die passenden Pakete. (dieser Vorgang kann länger dauern, wird aber in Zukunft schneller gehen)
Dass sich alle Distributionen auf ein Format einigen, wird vermutlich niemals geschehen…
Das mit der automatischen Suche klingt gut, sofern es funktioniert..
Klar funktioniert es 🙂
Obwohl Bug #598115 das Vergnügen für Fedora-User noch etwas trübt.
Warum macht es Sinn, ein weiteres Packetformat zu etablieren bzw. sollte dieses distributionsübergreifender als die bisherigen sein? Schließlich lässt sich jetzt schon RPM auf Debian installieren (und umgekehrt), auch ist niemand gezwungen, shared libraries zu verwenden..
Kein Flame, ich habe es bloß noch nicht verstanden.
RPM lässt sich nicht auf Debian installieren. Tools wie “alien” extrahieren nur die Dateien und package die in eine DEB-Struktur. Wenn man glück hat, lässt sich das Paket dann installieren.
Wegen der komplett unterschiedlichen Philosophien und wegen des ganz anderen, jeweils eigenen Workflows der Distributionen wird es IMO niemals ein Format geben, auf das sich alle einigen.
Das IPK-Format stellt da einen Kompromiss da, da es überhaupt nicht entwickelt worden ist, um DEB/RPM zu ersetzen. Es ist vielmehr eine Ergänzung zum bestehenden System.
(Zum letzten Teil: Shared libraries verwenden muss man nicht… Aber es ist viel praktischer und Sicherheitstechnisch besser, das zu tun.)
Nicht? -> http://packages.debian.org/lenny/rpm
..zugegeben, ich habe es noch nicht probiert.. (hol’ ich aber gleich nach) aber warum sollte es in den Repos sein, wenn es nicht funktioniert? Dasselbe gilt für yum, der auch drin ist.. -> http://packages.debian.org/lenny/yum
RPM ist drin, damit Programme wie z.B. File-Roller RPM-Archive lesen können. AFAIK ist das RPM-Tool sogar explizit deaktiviert und kann ohne aktivierung gar nicht zum Installieren genutzt werden.
Was yum in Debian soll, weiß ich ehrlich gesagt nicht… Funktionieren kann es jedenfalls nicht im eigentlichen Sinne, vermutlich wird es benutzt, um yum-Paketquellen auf Debianservern zu verwalten.
Naja.. hab’s mal mit der der aktuellen Opera-Version probiert – wurde noch zur Eingabe von –force-debian genötigt (keine Ahnung, was es bewirkt) und musste Abhängigkeiten ignorieren – danach hatte ich eine voll funktionsfähige Opera-Version zur Verfügung, dessen Entfernung ebenso problemlos verlief.
Wobei die Abhängigkeitsprüfung deines Tools aufgrund des Namens (das Problem der falschen Version wird leider bleiben) natürlich einen Vorteil darstellt. Auch ist mir nicht klar, wie weit die traditionellen Systeme in die Systemstruktur eingreifen, dass eine mischung problemlos ist – daher möchte ich mich als Laie auch nicht mehr zu weit aus dem Fenster lehnen.
Naja, bin gespannt, wann die ersten kommerziellen Produkte dein System/Programm nutzen.. 🙂
Korrektur: mit dem “umgekehrt” bin ich mir nicht mehr so sicher. Aber selbst dann hielte ich es für schlauer, Zusammenarbeit / “Konvertierprogramme” zu stärken, v.a. weil es schon viel mehr Software als rpm / deb gibt..