Listaller - Linux Software Manager (beta)

[Targion]

So... Hier mal ein kurzer Statusbericht des Projektes:
Wir haben 4 weitere Helfer für Paketebau usw. bekommen, gleichzeitig ist der zweite Programmierer im Moment zu beschäftigt um am Listaller zu arbeiten. Die neue Version besteht zu fast 100% aus meinem Code. Gleichzeitig wurde eine Art Logo-Wettbewerb gestartet, um ein neues, moderneres Listaller-Logo zu bekommen. Die Website soll ebenfalls verbessert werden.
An neuen Funktionen wurde/wird folgendes implementiert:
* PackageKit 0.5.4 Unterstützung
* Neue Listaller API, libinstaller wird nun von allen Modulen verwendet
* Listaller DBus daemon
* Integration von PolicyKit
* Implementation von IPK1.0 (zu 80% fertig)
* Diverse Stabilitätspatches
* Wechsel zu Lazarus 0.9.28 & FPC 2.4.0
* Verbesserter yum support
* Testinstallationen nun einfacher möglich
* Einge Patches für die Qt4-GUI
* Portierung der DB zu SQLite
So. Die Neuerungen sind extrem umfangreich und zeigen sehr gut, wie mächtig FPC unter Linux wirklich ist. Große Teile des Listallers wurden komplett neu geschrieben.
So, und jetzt meine Frage... Hätte von euch noch jemand Lust und Zeit, den universal-Installer für Linux zu unterstützen? Es gibt eine Menge "easy-Jobs" zu tun, um den Angepeilten Releasetermin für Listaller 0.4 Anfang Februar einzuhalten.
Der Listaller ist - unbestritten - die flexibelste Installationslösung unter Linux derzeit. Das Projekt kann mit jeder Art von Setup unter Linux umgehen und macht die Installation neuer Programme problemlos auf vielen Distributionen möglich. In der Testphase (ab Januar) wäre es daher sinnvoll, das Projekt auf mehreren Linux-Distros als nur Ubuntu/Fedora zu testen.
Wir stehen in engem Austausch mit dem PackageKit-Projekt, welches sogar einige API-Änderungen vorgenommen hat, um nicht-C-Sprachen besser zu unterstützen. PackageKit & Listaller ist die ultimative Lösung für alle 3rd-Party Installationsprobleme in Linuxsystemen.
So, jetzt aber genug der Sülzerei... Unabhängig davon, ob wer helfen möchte: Gibt es irgendwelche Feature-Wünsche? Mitte Dezember ist Feature-Stopp, wer also ein "must-have"-Feature noch hat...

[pluto]

Klingt alles recht Viel versprechend.

[Targion]

Soo... Das Projekt ist nicht tot oderso, es geht munter weiter. Allerdings entwickle nun hauptsächlich ich an dem Projekt, da die anderen Projektmitglieder zu sehr mit anderen Dingen beschäftigt sind.
Das einzige, was dem Listaller noch fehlt, um 0.4 genannt zu werden, ist eine Überarbeitung der Specs für IPK-Updates, das ist im Moment noch suboptimal. (Ein Update kann z.B. keine Dateien entfernen, sondern nur bestehendes aktualisieren)
Zudem folgt dann noch eine ausführliche Testreihe auf verschiedenen Linuxdistributionen, und einige Probleme müssen auch noch ausgetrieben werden. (z.B. Crasht der DBus-Daemon hin und wieder...)
Da das Testen sehr aufwändig ist (man muss schließlich jede Linux-Distri in einer VM installieren) wollte ich mal fragen, ob hier im Forum jemand daran interessiert wäre, das Projekt auf seiner Distribution auszuprobieren oder ob jemand vielleicht sigar ein paar IPK-Pakete bauen möchte. Auf meinem Rechner läuft Alles immer relativ perfekt, daher wären solche Daten extrem wichtig. Auch würde mich interessieren, wie "nicht-eingeweihte" mit dem IPS-Syntax zurecht kommen.

Den Listaller-Quellcode kann man übrigens mittels Git beziehen:

Code: Alles auswählen

git clone git://gitorious.org/listaller/listaller.git

Fertige Pakete gibt es für Ubuntu/Debian auf Launchpad oder für RPM-basierte Distributionen mittels dem openSUSE Buod Service. Die binären Pakete sind aber nicht immer besonders aktuell.
Der Listaller benötigt mindestens PackageKit 0.5.6 und GLib 2.14 sowie SQLite3 und PolicyKit.
Gebaut wird das Projekt mittels

Code: Alles auswählen

cd /pfad/zum/sourcecode
./configure --enable-qt --enable-creator #oder --enable-gtk
make
make install #als root

Aktuelle Bugs sind im Bugtracker oder auf meiner TODO-Liste zu finden

[Socke]

Hallo Targion,
ich habe mir gerade dein Webseite angesehen. Bisher konnte ich nur keinen Grund erkennen, was Listaller besser machen sollte als aktuelle Paketmangementsysteme bzw. wie es deren Fehler korrigieren soll.
Bei der Webseite ist mir aufgefallen: wo ist die IPK-Datei für Listaller?

Code: Alles auswählen

cd /pfad/zum/sourcecode
./configure --enable-qt --enable-creator #oder --enable-gtk
make
make install #als root

Bisher habe ich für mein Debian eher nach einer Lösung gesucht, das make install zu umgehen und statt dessen alles über dpkg/apt zu installieren. Dann könnten eventuelle Abhängigkeiten aufgelöst werden und alle könnte auch wieder sauber deinstalliert werden. Bei meinen Versuchen mit den debhelper-tools ein Paket für einen gthumb-Backport (bzw. eine benötigte Version der libunique) zu erzeugen bin ich an die Grenzen meines Verständnisses der Dokumentation geraten. Wenn Listaller das kann (und ich Listaller als Paket installieren kann) hätte ich allerdings einen Grund gefunden.

[Targion]

Listaller kann hauptsächlich drei Dinge besser als APT:

• Ein einziges Paket für alle Distributionen, auf denen Listaller läuft. Man muss kein DEB/RPM-Paket für jede Distribution erstellen
• Sehr einfache Erstellung von IPK-Paketen (ich würde es etwas mit der Schwierigkeit von InnoSetup vergleichen)
• Vereinheitlichung von fast allen Konzepten des Softwaremanagements für Linux unter einer Oberfläche: Der Listaller kann Software entfernen, egal wie sie auf das System gelangte (unterstützt werden Autopackage,LOKI/MOJO, Native etc.) und unterstützt Nutzer bei der Installation von z.B. RPM-Paketen auf einer Debian-Basierten Distribution.

Zudem vereinheitlicht der Listaller Konzepte von bisherigen Softwaremanagern wie Autopackage, LOKI, NIXInstall und KLIK in einem Paketformat und stellt eine Funktion ähnlich openSUSEs 1-Klick-Install für weitere Distributionen bereit. Dabei ist der Listaller relativ sicher.
Der Listaller ist nur dafür erstellt, Anwendungen zu installieren. Abhängigkeiten, wie z.B. Bibliotheken, _müssen_ von der jeweiligen Distribution bereitgestellt werden, oder das Programm muss statisch gelinkt sein.

Eine IPK-Datei für den Listaller gibt es nicht, da man IPKs ohne Listaller nicht installieren kann Dafür musst du das projekt entweder manuell aus dem Code erstellen oder aber ein fertiges Build (als RPM oder DEB) benutzen.
Das make install wird vom Listaller Programm "libuild" direkt in eine Verzeichnisstruktur im IPK-Paket umgeleitet. Existiert ein IPK-Paket für eine Anwendung, dann kannst du dir das selbst kompilieren sparen.

Bei meinen Versuchen mit den debhelper-tools ein Paket für einen gthumb-Backport (bzw. eine benötigte Version der libunique) zu erzeugen bin ich an die Grenzen meines Verständnisses der Dokumentation geraten. Wenn Listaller das kann (und ich Listaller als Paket installieren kann) hätte ich allerdings einen Grund gefunden.

Was ist das denn genau? Systembibliotheken würde ich ungern in ein IPK-Paket packen, die gehören in ein DEB/RPM/TGZ-Paket, welches vom Distributionseigenen Paketmanager verwaltet wird. Wenn das aber eine Anwendung oder ein Plugin ist, würde ich es gerne mal testweise als IPK-Paket bereitstellen.
(Solche Testfälle suche ich auch, je mehr Pakete ich baue, um so ausführlicher wird das Projekt getestet)
Wer den Listaller testet: Die Installation im Superuser-Modus ist momentan noch mit Vorsicht zu genießen. Zwar können keine Daten verloren gehen, aber die Installation crasht gerne mal auf halben Weg.
Ich werde bald mal ein paar IPK-Pakete online stellen. (Die aktuellen auf der Listaller-Seite taugen nicht wirklich was)

[Socke]

Ich wollte eigentlich ein Plugin für das neue gThumb schreiben. D.h. ich bräuchte gThumb 2.11 (development, http://live.gnome.org/gthumb); Das hängt aber von der libunique (http://live.gnome.org/LibUnique) ab.
gThumb ist ein Bildverwalter und libunique eine Bibliothek um das mehrmalige Starten einer Anwendung zu verhindern.

Eine IPK-Datei für den Listaller gibt es nicht, da man IPKs ohne Listaller nicht installieren kann Dafür musst du das projekt entweder manuell aus dem Code erstellen oder aber ein fertiges Build (als RPM oder DEB) benutzen.

Ich dachte, mit Listaller könnte man auch updaten?

Wenn der Listaller den Paketmanager nicht ersetzen soll, soll er ihn dann umgehen? Mein persönlicher Paketmanager soll doch bitte wissen, welche Software alles installiert ist (ausgenommen development-Versionen). Selbstkompiliertes soll da auch mit rein (Übersichtlichkeit/einfachere Deinstallation/Upgrade). Zumal ich nur ungern verschiedene Software benutze, die meine Software verwaltet.

Wie viel Handarbeit muss man denn anlegen, damit man aus einem Programmquelltext ein IPK-Paket entsteht und die Binaries dann auch dort ankommen, wo sie vom System gefunden werden?

Wie löst du das Problem, dass verschiedene Distributionen verschiedene Pfade als Standard definieren (bspw. /usr/bin statt /usr/local/bin)?

[pluto]

Wenn der Listaller den Paketmanager nicht ersetzen soll, soll er ihn dann umgehen? Mein persönlicher Paketmanager soll doch bitte wissen, welche Software alles installiert ist (

Das Programm muss ja Irgendwie Installiert werden. Einige Programme verwenden die bin Dateien... vielleicht wäre das hier auch eine Idee...

[Targion]

Ich wollte eigentlich ein Plugin für das neue gThumb schreiben. D.h. ich bräuchte gThumb 2.11 (development, http://live.gnome.org/gthumb); Das hängt aber von der libunique (http://live.gnome.org/LibUnique) ab.
gThumb ist ein Bildverwalter und libunique eine Bibliothek um das mehrmalige Starten einer Anwendung zu verhindern.

Dann müsste ich für ein IPK-Paket GThumb statisch linken. Systembibliotheken darf der Listaller nicht ersetzen, schreibt man ein Script, was sowas macht bekommt man eine kritische Warnung beim Paketbau. Systembibliotheken werden generell vom Distributionseigenen Paketmanager verwaltet, alles Andere wäre auch Sicherheitstechnisch gefährlich.

Ich dachte, mit Listaller könnte man auch updaten?

Ja, IPK-Anwendungen können per Updater instand gehalten werden.

Wenn der Listaller den Paketmanager nicht ersetzen soll, soll er ihn dann umgehen? Mein persönlicher Paketmanager soll doch bitte wissen, welche Software alles installiert ist (ausgenommen development-Versionen). Selbstkompiliertes soll da auch mit rein (Übersichtlichkeit/einfachere Deinstallation/Upgrade). Zumal ich nur ungern verschiedene Software benutze, die meine Software verwaltet.

Der Listaller-Manager verwaltet alle Software auf dem System, die eine GUI hat, dazu gehört auch selbskompiliertes. (Nur das man eigene bui,ds nicht mit dem Manager löschen kann, da der Listaller nicht weiß, was alles zu dem Programm gehört) Der Listaller kommuniziert mit dem Paketmanager, um z.B. Systembibliotheken zu installieren, aber er ersetzt kein Paket des Paketmanagers.
Es wäre möglich, ein PlugIn für PackageKit zu schreiben, damit PackageKit auch Listaller-Anwendungen verwalten kann. Das mache ich, wenn der Listaller eine größere Verbreitung erreichen sollte. Dann könnte man direkt aus der Paketverwaltung die gesamte Systemsoftware, Listaller oder nicht, verwalten.
(Kurz mal so, falls das nicht eindeutig ist: Der Listaller installiert erstens IPK-Pakete, welche ein eigenes Format für Setups darstellen. Gleichzeitig ist der Listaller aber auch ein universeller Software-Verwalter, der mit Autopackage und LOKI-Scripten (das Zeug, in dem z.B. Google Earth verpackt ist) umgehen kann und in der Lage ist, diese per GUI zu entfernen.)

Wie viel Handarbeit muss man denn anlegen, damit man aus einem Programmquelltext ein IPK-Paket entsteht und die Binaries dann auch dort ankommen, wo sie vom System gefunden werden?

Kommt ganz auf die Anwendung an. Für mein Supertux-Testpaket brauche ich 28 Zeilen IPK-Script und 32-Zeilen Bashscript, um Supertux vernünftig zu bauen. Dieser wert ist je nach IPK-Typ unterschiedlich. (packt man einfach eine LOKI-Binary in ein IPK-Paket reiche 8 Zeilen oder weniger)
Insgesamt würde ich sagen, IPK-Pakete bauen ist um ein vielfaches einfacher als Debian-Pakete erstellen. (IPK-Pakete bauen ist aber im Moment noch stressiger, da der builder noch nicht so viele Testläufe hatte und daher manchmal buggy ist)

Wie löst du das Problem, dass verschiedene Distributionen verschiedene Pfade als Standard definieren (bspw. /usr/bin statt /usr/local/bin)?

Um nicht mit dem Paketmanager ins Gehege zu kommen wird Software meistens nach $INST installiert. $INST ist eine Pfadvariable, die das Listaller-Setuptool auflöst. Macht man eine normale Installation ins HOME-Verzeichnis, so zeigt sie nach $HOME/.appfiles/, installiert man das Paket als Superuser, zeigt sie nach /opt/appfiles, um nicht mit dem Paketmanager ins Gehege zu kommen. /opt ist nach der LSB der Standardpfad für optionale Software. Auch für andere Pfade gibt es solche Variabeln. Man kann allerdings auch Anwendungen z.B. statisch nach /usr/share installieren. Dann kann man allerdings keine Testinstallationen und keine Installationen nach $HOME mit dem Paket machen.
Die Pfade für Bibliotheken sind zwar auf vielen Distributionen anders, aber jede Distribution setzt natürlich auch die entsprechende Systemvariable korrekt, sodass ene Anwendung so eine Bibliothek problemlos finden kann.
Der Listaller sollte keine Bibliotheken installieren. Muss man das noch tun (warum auch immer...) kann man $LIB benutzen, welche den korrekten Pfad enthält.

Ich habe im Anhang mal mein Songbird-IPS-Script angehängt. Dieses Script paketiert eine fertig kompilierte Version, hat daher mehr Zeilen als das Supertux-Script. (Die Dateiendung muss in .ips geändert werden.)
Bevor wer fragt: Ja, man kann auch ganze Ordner einfügen und ja, der Listaller kann nach dem Build die Sektion unter "Files" auch automatisch erstellen Das ist - wie gesagt - nur ein Testscript. (Wenn ihr wollt kann ich auch das Supertux-Script anhängen... Aber da werde ich bald mal ein paar Pakete bauen)

[Socke]

Wenn ich das ganz kurz zusammen fassen darf:

Listaller ist ein neuer Paketmanager, der für Bibliotheken auf einen vorhandenen distributionsspezifischen Paketmanager zurückgreift.
Die Dateien werden nicht in die distributionsspezifischen Standardverzeichnisse sondern in die empfohlenen Verzeichnisse für optionale Software installiert.

Richtig?

Code: Alles auswählen

AppCMD: $INST/songbird/songbird

heißt das, dass das binary gar nicht in $PATH liegt?

[Targion]

Wenn ich das ganz kurz zusammen fassen darf:

Listaller ist ein neuer Paketmanager, der für Bibliotheken auf einen vorhandenen distributionsspezifischen Paketmanager zurückgreift.
Die Dateien werden nicht in die distributionsspezifischen Standardverzeichnisse sondern in die empfohlenen Verzeichnisse für optionale Software installiert.

Richtig?

Richtig. Zudem ist der Listaller eine Art "Meta-Paketmanager", der andere Paketmanagementsysteme parallel integrieren kann.

Code: Alles auswählen

AppCMD: $INST/songbird/songbird

heißt das, dass das binary gar nicht in $PATH liegt?

Jo. Das AppCMD-Element legt fest, welches Kommando nach der Installation ausgeführt werden soll, um die neue Anwendung zu starten. Würde ein link in z.B. /usr/bin erstellt, dann könnte der Nutzer die Anwendung nicht mehr in sein Home-Verzeichnis installieren. (Der Listaller erlaubt das aber, nur kann die Software dann halt nur für alle Nutzer installiert werden) In einer neuen IPS-version kann ich vielleicht festlegen, dass der Listaller von Fall zu Fall selbst entscheidet, den Link zu erstellen.
Ich habe übrigens mal das Songbird-IPK-Paket aktualisiert. Jetzt sollte es keinen Fehler mehr geben. (Vorher wurde angezeigt, dass das IPK-Paket für die Rechnerarchitektur nicht geeignet ist)

[Socke]

Jo. Das AppCMD-Element legt fest, welches Kommando nach der Installation ausgeführt werden soll, um die neue Anwendung zu starten. Würde ein link in z.B. /usr/bin erstellt, dann könnte der Nutzer die Anwendung nicht mehr in sein Home-Verzeichnis installieren. (Der Listaller erlaubt das aber, nur kann die Software dann halt nur für alle Nutzer installiert werden) In einer neuen IPS-version kann ich vielleicht festlegen, dass der Listaller von Fall zu Fall selbst entscheidet, den Link zu erstellen.

Wie wärs damit:

1. Wenn in das Benutzerverzeichnis installiert wird
   1. Benutzer die Möglichkeit geben einen benutzerspezifischen $PATH-Pfad anzugeben (z.b. $HOME/.bin)
   2. Link dort erstellen
2. Wenn in ein anderes Verzeichnis (/opt) installiert wird
   1. Root-Rechte beantragen
   2. als Root installieren
   3. Link in /usr/bin anlegen (bzw. anderem $PATH-Eelement

[Targion]

Könnte ich so machen. Es wird aber in der Regel sowieso eine .desktop-Datei ins verzeichnis $HOME/.applications installiert. Zu diesem verzeichnis existiert ein lokalisierter Symlink in $HOME, das heußt der Nutzer bekommt alle Anwendungen aus seinem Home-Verzeichnis sowieso angezeigt, wenn er in den Ordner ~/Anwendungen navigiert. Die Idee ist aber gut, ich überlege mir dazu mal was, sobald die anderen Teile stabil laufen.

[Socke]

$PATH wäre nur schön fürs scripting. Viele Programme mit GUI können ein paar Aufgaben auch über ohne GUI durchführen.

[Targion]

Es gibt Neuigkeiten!
Nächste Woche werde ich version 0.4b des Installers freigeben. Der enthält z.B. erstmalig mit der libinstaller die Möglichkeit, eigene Frontends für den Installer zu schreiben, mit IPK1.0 ein komplett neues LZMA-Komprimiertes Paketformat und eine durchgängige Anbindung an PackageKit.
Leider konnte ich nicht alle Tests abschließen, weshalb es auch version 0.4-beta wird. Aber da Listaller 0.4 nun seit über 9 Monaten aussteht wird es Zeit für ein Release.
Mit Stolz möchte ich auch die zukünftige Kooperation mit dem PAPPI-Projekt verkünden. Wir arbeiten gereade eine Roadmap aus.
Nun meine Bitte an euch: Bevor es nächste Woche losgeht, könntet ihr (da ihr alle mit Lazarus umgehen könnt ) mal die aktuelle Version testen? Fertige Pakete für Fedora 13 gibt's im OpenSUSE Build Service, auf Launchpad gibt's Debian Pakete für Sidux und Ubuntu Lucid.
Am schönsten ist es natürlich, den Listaller aus den Quellen zu bauen... Die kann man sich über Git holen:

Code: Alles auswählen

git clone git://gitorious.org/listaller/listaller.git

Dann zunächst

Code: Alles auswählen

./configure --enable-gtk --enable-creator

und dann

Code: Alles auswählen

make;sudo make install

. (Mit dem Parameter "--enable-qt" kann man auch alle Oberflächen für Qt4 bauen, wenn libqt4pas installiert ist)
Ihr braucht die SQLite und PackageKit-GLib Header zum bauen. Viel Spaß ^^ Sollte es Probleme geben, behebe ich die umgehend, damit es ein einigermaßen sauberes Release nächste Woche gibt. (Am besten Bugs melden)

[Targion]

Sooo! Jetzt endlich, nach über 9 Monaten, ist der Listaller 0.4b bereit für die Öfentlichkeit. *sektkorken knall*
Wer sich über das neue Release Informieren will, kann sich die Releaseankündigung durchlesen:
in Englisch
in Deutsch (gekürzte Fassung)