ubuntuusers.de

• Was ist, wenn Software nicht in den Repositorien ist?

• Was ist, wenn man eine neuere Version eines Programmes benötigt, diese aber nicht als Paket verfügbar ist?

• Bei der Veröffentlichung neuer Linux-Software müssen Hersteller für jede Linux-Distribution eine Extrawurst in Sachen Paketformat braten

• Nutzer ohne ausreichende Berechtigung können keine Software installieren

• In vielen Fällen braucht man zur Installation von Software gute Kenntniss des Systems

• Viele Leute wollen sich nicht mit dem Software-Kompilieren beschäftigen, sondern nur ein system, welches "einfach" funktioniert.

Primär Aufgrund dieser Probleme habe ich vor drei Jahren ein neues Projekt gestartet, welches Softwareinstallationen und Deinstallationen unter Linux einfacher machen soll.
Das Projekt "Listaller" (sehr wenig fantasievoll von "Linux" und "Installer" abgeleitet) ist ein Programm, welches Programmierern ermöglicht, ein Paket für alle Linux-Distributionen bereitzustellen und Anwendern das Installieren und Verwalten von Programmen auf dem Rechner erleichtert.
Dies wird vor allem durch ein neues Paketformat erreicht, welches Entwicklern die größtmögliche Freiheit beim Erstellen lässt und welches, wenn es mit dem Setup-Tool geöffnet wird, dem Nutzer einen komfortablen Installationsassistent bietet.
Dieses „Paketformat“, ein LZMA-Komprimierter Tarball mit der Endung .IPK. (Installationspaket) kann je nach Typ verschiedene Aufgaben erfüllen:
Ist das IPK-Paket vom Typ „normal“, enthält die Paketkonfigurationsdatei weitere Informationen über die Abhängigkeiten, die für die aktuelle Distribution/Paketdatenbank benötigt werden. Dabei können auch Internet-Links angegeben werden. Der Listaller löst die Abhängigkeiten dann auf und entpackt anschließend die Anwendung. Für kommende Listaller-Releases ist geplant, dass der Listaller die Abhängigkeiten sogar vollautomatisch aus den Binärdateien des Projektes ermittelt.
Wenn das IPK-Paket vom Typ „container“ ist, wird schlicht und einfach das im Paket enthaltene Autopackage/LOKI-Setup-Paket installiert. Der Listaller hat später die Möglichkeit, Autopackage und LOKI-Setups wieder zu entfernen.
Das IPK-Paket kann auch vom Typ „dlink“ sein. Dieser Typ ist für Entwickler gedacht, die zwar für jede Distribution eigene Pakete erstellt haben und diese auch weiter nutzen verbreiten, jedoch dem Nutzer trotzdem die Wahl des richtigen Paketes erleichtern wollen: In einem DLinkIPK-Paket sind passend zu jeder Distribution die Weblinks zu den entsprechenden passenden Paketen angegeben, die der Listaller bei Bedarf herunterlädt und installiert. Der Nutzer hat davon, dass sich die Anwendung mit einem simplen Klick auf „Deinstallieren“ im Software Manager wieder entfernen lässt und Neue Nutzer sich keine Sorgen darum machen müssen, welches Paket für ihre Distri geeignet ist. Dieses Feature ist vergleichbar mit dem 1-Klick-Install-Dienst der Linux-Distribution openSUSE.
Der Listaller hat auch noch einige weitere Funktionen:
Normale Pakete können vom Listaller-eigenen Updater Gerauch machen. Entwickler können Updatequellen für ihre Software automatisch aus dem Quellcode des Projektes generieren.
Der Listaller enthält auch ein Management-Tool, welches alle auf dem System installierten Anwendungen anzeigt und es ermöglicht, diese auch zu Entfernen. Dabei spielt es keine Rolle, ob die Anwendung mittels Autopackage, LOKI, IPK-Setup oder dem Paketmanagement installiert wurde, da der Listaller mit allen Systemen kompatibel ist.
Basis des Listallers ist die Paketmanager-Abstraktionsschicht [PackageKit]. Der Listaller nutzt selbst PackageKit und erweitert dessen Funktionalität um das Ziel eine einheitliche Softwareverwaltung unter Linux zu erreichen.
Nach der Ersten Veröffentlichung des Listallers, der experimentellen Version 0.1.18a-exp, ist das Projekt schnell gewachsen, Entwickler kamen und gingen, ebenso wie andere aktive Projektmitglieder. Daher suchen wir dringend weitere Entwickler/Designer/Sponsoren, die das Projekt unterstützen möchten. Wer helfen möchte, kann sich bei mir per PN melden oder mal die Seite Get Involved auf der Listaller-Website lesen.
Das Projekt steht unter der GPLv3.
Wer jetzt Lust bekommen hat, sich das Projekt näher anzusehen, der kann sich die Screenshots auf der Projektwebsite ansehen.
Wer den Listaller testen möchte, findet auf unserer Downloadseite vorkompilierte Pakete für viele Distributionen, natürlich auch für Ubuntu (ab 10.04 LTS).
Technisch basiert der Listaller auf dem PackageKit-Projekt, welches von Richard Hughes ins Leben gerufen wurde, um ein einheitliches FrontEnd für alle Paketmanagementsysteme zu bieten und um die Update-Funktion der Distributionen ins nächste Jahrhundert zu befördern. (Zudem bietet PackageKit einigen weiteren Komfort beim Paketmanagement) Der Listaller benutzt ab Version 0.3.5a PackageKit für die Interaktion mit dem Paketmanagement, früher kam eine eigene Lösung zum Einsatz.
Der Listaller ist zum größten Teil in der Sprache Pascal geschrieben.
Frontends für Qt4 und GTK2 sind verfügbar.
Wenn jemand einen Bug im Listaller gefunden hat, kann dieser im Bugtracker auf Launchpad gemeldet werden. (Damit dieser Thread nicht so aufgebläht wird)
Damit das Testen des Listallers nicht zu langweilig wird, haben wird auf der Listaller Website den Service getIPK gestartet. Dieser Dienst stellt fertige IPK Setup Pakete für einige Anwendungen zur Verfügung.
So, damit wäre alles wichtige gesagt. Viel Spaß beim Testen. Ich freue mich auf eure Kritik!

Links:
Listaller Projektwebsite 🇬🇧
Listaller in Launchpad 🇬🇧
PackageKit Website 🇬🇧
Listaller bei Sourceforge 🇬🇧
Listaller 0.4b Ankündigung 🇩🇪
Listaller 0.4b Ankündigung 🇬🇧

Hi Targion

Ich find's gut, dass jemand dieses Problem angeht. Wäre genial, wenn's Installationspakete geben würde, die sich auf jeder Distribution installieren lassen.

Ich werd das Projekt im Auge behalten.

Weiter so!

Ich denke, das es keine gute Idee ist, zwei Package-Manager auf einem System zu benutzen. Deshalb: Wie wäre es, wenn dein Package-Manager mit den lokalen Package-Managern zusammenarbeitet und denen sagt, welche Pakete es installiert hat?

Hi Targion,

Ich bin seit einiger Zeit Entwickler bei Autopackage und wollte mal fragen was denn der Unterschied von deinem System ist? Warum das Rad neu erfinden?

Einfache Installation/Deinstallation von allen auf dem System installierten Anwendungen.

Was genau meinst du damit? Ich kann mit Listaller auch sachen vom paket-manager deinstallieren? Wär es da nicht einfacher Autopackage/LOKI in PackageKit zu integrieren?

Paketformat "IPK", welches... ...eine Funktion wie openSuSEs 1-Klick-Install nahezu Distributionsunabhängig bereitstellt

Also kann dein Programm Reprositories hinzufügen? In der PackageKit Mailingliste wurde sowas schonmal besprochen, zusammen mit den ganzen Nachteilen.

...als Container für Binär-Setups dienen kann

Was meinst du damit?

Aus nur einer Quelldatei ein DEB- und ein RPM-Paket erstellen

Das versteh ich auch nicht ganz. Ist das also sowas wie alien?

Einige Hilfsprogramme für externe Anwendungen z.B. ein grafisches Sudo für KDE und GNOME

Also sowas wie PolicyKit bzw. autosu (Teil von autopackage)?

Jan-Nik schrieb:

Einfache Installation/Deinstallation von allen auf dem System installierten Anwendungen.

Was genau meinst du damit? Ich kann mit Listaller auch sachen vom paket-manager deinstallieren? Wär es da nicht einfacher Autopackage/LOKI in PackageKit zu integrieren?

Exakt das heißt es. Allerdings arbeitet PackageKit auf Paketebene, der Listaller installiert/deinstalliert Anwendungen. Konkret liest der Anwendungsmanager das Verzeichnis "/usr/share/applications" aus, wirft die unerwünschten Einträge (z.B. Systemkomponenten) raus, prüft dann, welches Paket zu der Datei gehört und deinstalliert dieses, wenn es keine reversiven Abhängigkeiten mehr hat.

Paketformat "IPK", welches... ...eine Funktion wie openSuSEs 1-Klick-Install nahezu Distributionsunabhängig bereitstellt

Also kann dein Programm Reprositories hinzufügen? In der PackageKit Mailingliste wurde sowas schonmal besprochen, zusammen mit den ganzen Nachteilen.

Ja, man kann Quellen hinzufügen, allerdings sind diese nicht änderbar, d.H. neue Quellen können nur vor der Kompilierung des Projektes hinzugefügt werden. Das hat den Vorteil, dass es sicher ist und man eine Art "Anwendungskatalog" wie Ubuntu's 'Hinzufügen/Entfernen' nutzen kann. Die 1-Klick-Install Option ist genauso gefährlich/ungefährlich wie wenn man Pakete direkt installiert. In der IPK-Datei ist nur enthalten, wo die Anwendung und deren Abhängigkeiten als DEB/RPM-paket im Internet zu finden sind. Diese werden dann heruntergeladen und installiert. Der Nachteil: Kein Auto-Update, wie wenn man eine Paketquelle hinzufügt.

...als Container für Binär-Setups dienen kann

Was meinst du damit?

Das ist eine Funktion die eigentlich nichts mit dem Listaller direkt zu tun hat. Grob gesagt läuft das so ab: 1. Binärsetup in eine IPK-Datei packen. 2. Eventuell weitere Dateien, die das Binär-Setup benötigt hinzufügen. 3. Der Nutzer öffnet nun das IPK-Paket mit dem Listaller. Enthält die datei ein Autopackage wird Autopackage automatisch installiert. Danach wird die Anwendung mit ROOT-RECHTEN installiert.

Aus nur einer Quelldatei ein DEB- und ein RPM-Paket erstellen

Das versteh ich auch nicht ganz. Ist das also sowas wie alien?

Das Bedeutet, dass du ein IPK-Script (endung: IPS) hast. In diesem stehen dann zusätzliche Informationen wie z.B. Paketname usw. drin. Nun kannst du das Script mit einer Spezialoption bauen, dadurch erhältst du dann anstelle eines IPK-Paketes eine RPM-Datei und ein DEB-Paket, so wie man es z.B. schon von openSuSEs BuildService kennt. Nur läuft (bzw: es soll) das ganze lokal ab.

Einige Hilfsprogramme für externe Anwendungen z.B. ein grafisches Sudo für KDE und GNOME

Also sowas wie PolicyKit bzw. autosu (Teil von autopackage)?

Ja, exakt. Der Kram hat allerdings keine Priorität und ist eigentlich nur als Hilfsmittel für den Listaller gedacht.

~~~~~~~~~~~~~~~~

Ich hoffe ich konnte alle Fragen verständlicher beantworten! 😬 Autopackage ist super, läuft aber manchmal nicht richtig. Und eben wegen der vielen "Räder" die schon erfunden wurden (Autopackage, LOKI, CNR, usw. sowie APT,RPM,Conary, usw.) habe ich mal mit diesem Projekt angefangen, um ALLES unter einer Oberfläche zu vereinen und einfach für Neue Benutzer zu machen, die sich nicht mit der Paketverwaltung rumschlagen wollen oder nicht wissen, wie man z.B. GoogleEarth installieren soll. Außerdem: Verlieren kann man bei OpenSource-Projekten höchstens viel Zeit oder die Nerven. 😉

P.S: @FSM: Genau das tut der Listaller. (Bald mit PackageKit als Backed) Code }}}

Targion schrieb:

Das Bedeutet, dass du ein IPK-Script (endung: IPS) hast. In diesem stehen dann zusätzliche Informationen wie z.B. Paketname usw. drin. Nun kannst du das Script mit einer Spezialoption bauen, dadurch erhältst du dann anstelle eines IPK-Paketes eine RPM-Datei und ein DEB-Paket, so wie man es z.B. schon von openSuSEs BuildService kennt. Nur läuft (bzw: es soll) das ganze lokal ab.

Ist das denn überhaupt lokal möglich? Unter Ubuntu kann ich ja kein Paket für Fedora schnüren.

Ich hoffe ich konnte alle Fragen verständlicher beantworten!

Danke jetzt versteh ich's. Klingt ziemlich gut (aber auch aufwändig 😀)!

Es ist möglich, LSB-konforme RPM-Pakete unter Ubuntu zu bauen, da die LSB ja leider RPM zum Standard gemacht hat. (die Gründe dafür verstehe ich natürlich, allerdings halte ich persönlich DEB für besser) Für openSuSE/Fedora Pakete muss ich mal schauen, wie groß die Unterschiede dort sind und dann diese in den Builder einbauen. Allerdings ist dieses Projekt wirklich extrem umfangreich, und aktuell bin ich der einzige Entwickler, weshalb ich dieses Feature nach dem heutigen Stand wohl erst in Version 1.0 vermute.

@Jan-Nik: Ist es eigentlich in absehbarer Zeit mal vorgesehen eine GUI zur komfortablen Erstellung von Autopackages zu erstellen? Also am besten natürlich eine Oberfläche, in die man nur die Dateien einfügen muss, die man installieren möchte, das Zielverzeichnis angeben, Paketname, Version, etc. Also quasi so eine Oberfläche wie InstallJammer, nur eben für Autopackage. Das wär echt mal eine Innovation ☺ Habe gestern erst wieder versucht ein Autopackage zu erstellen. Habs dann nach einer knappen Stunde mit lauter Fehlermeldungen wieder aufgegeben ☹

Für den Listaller gibt es eine (komfortable?) GUI zum Erstellen von IPK-Paketen. (Screenshots) Wenn du willst kannst du das mal ausprobieren, allerdings ist der komplette Listaller noch pre-alpha, es kann also noch größere Probleme geben. (Es kann nicht nur: Es gibt. Die beste Möglichkeit ist, den Listaller direkt aus den SVN-Quellen zu erstellen) Ubuntu-DEB-pakate gibt es hier: liCreator wird nur zum Erstellen von IPK-paketen benötigt. Autopackage-Pakete kann man damit nicht erstellen, diese kann man nur einbinden. Ich bin, bei meinen Autopackage-Experimenten mal auf ein Programm gestoßen, welches die Pakete grafisch erstellen kann. ich habe nur leider den Namen vergessen, wenn ich das Teil wieder finde melde ich mich!

Targion schrieb:

Für den Listaller gibt es eine (komfortable?) GUI zum Erstellen von IPK-Paketen. (Screenshots) Wenn du willst kannst du das mal ausprobieren, allerdings ist der komplette Listaller noch pre-alpha, es kann also noch größere Probleme geben. (Es kann nicht nur: Es gibt. Die beste Möglichkeit ist, den Listaller direkt aus den SVN-Quellen zu erstellen)

Da bin ich im Moment mal vorsichtig, möchte nichts am System zerschießen. Sobald ihr sagt: "Jetzt ist das Ding bereit" (alpha oder beta) werde ich ihn aber auf jeden Fall testen, also weiter so 😉

Die Screenshots sehen schonmal super aus!

Pre-Alphas sind immer ein Problem. z.B. Hate eine SVN-Version des Listallers RPM-Pakete erstellt, die die Beta-Version von openSuSE 11 komplett lahmgelegt haben. Solche gravierenden Fehler sind in der 0.1.16pa-Version natürlich nicht mehr drin, sonst hätte ich sie nicht freigegeben, aber völlig fehlerlos ist sie auch nicht. Ich habe hier mal ein paar Ubuntu-Brainstorm-Links gefunden, die alle mehr oder weniger eine Lösung wie den Listaller fordern:

http://brainstorm.ubuntu.com/idea/8604/ http://brainstorm.ubuntu.com/idea/9165/ http://brainstorm.ubuntu.com/idea/2045/ http://brainstorm.ubuntu.com/idea/3398/ http://brainstorm.ubuntu.com/idea/9102/ http://brainstorm.ubuntu.com/idea/10051/ http://brainstorm.ubuntu.com/idea/11866/

Das ist der Grund, warum ich das Projekt jetzt auch fortführe, ansonsten hätte ich es schon seingelassen.

Giantics schrieb:

@Jan-Nik: Ist es eigentlich in absehbarer Zeit mal vorgesehen eine GUI zur komfortablen Erstellung von Autopackages zu erstellen? Also am besten natürlich eine Oberfläche, in die man nur die Dateien einfügen muss, die man installieren möchte, das Zielverzeichnis angeben, Paketname, Version, etc. Also quasi so eine Oberfläche wie InstallJammer, nur eben für Autopackage. Das wär echt mal eine Innovation ☺ Habe gestern erst wieder versucht ein Autopackage zu erstellen. Habs dann nach einer knappen Stunde mit lauter Fehlermeldungen wieder aufgegeben ☹

Ja sowas gibt es schon, nennt sich mkapspec. Hab ich aber noch nicht ausprobiert und weiß nicht ob das wirklich komplett ohne Konsole geht. Aber als Entwickler sollte man sich ein bisschen mit der Konsole auskennen 😉

Jan-Nik schrieb:

Ja sowas gibt es schon, nennt sich mkapspec. Hab ich aber noch nicht ausprobiert und weiß nicht ob das wirklich komplett ohne Konsole geht. Aber als Entwickler sollte man sich ein bisschen mit der Konsole auskennen 😉

mkapspec kenn ich, habe ich installiert. Meiner Meinung ist der Vergleich von mkapspec mit einer GUI a la InstallJammer wie der Vergleich zwischen einem Fahrrad und einem Auto 😉 Mir fehlt die komplette Behandlung der zu kopierenden Dateien.

Keine Frage: autopackage ist toll! Ich jedoch denke, das Fehlen einer wirklich vollständigen GUI wird einige Entwickler davon abhalten es zu benutzen.

Hallo, ich bin's wieder! Die Entwicklung der ersten Alpha-Version (0.1.18a) ist nun soweit fortgeschritten, dass fast alle Features implementiert sind. (Es fehlen: KDE integration & Bauen von RPM und DEB-paketen aus einer Datei). Wenn jemand Lust und Zeit dazu hat, fände ich es toll, wenn er/sie mal ein Daily-build testen würde und die Probleme hier oder im Launchpad berichtete. Z.B. wäre folgendes wichtig:

• Funktioniert die Installation / der Start des Programmes problemlos?

• Klappt die Installation von IPK-paketen?

• Wie gefällt euch das UserInterface?

• Werden im "Listaller Manager" Anwendungen gelistet, die nicht deinstalliert werden dürfen? (z.B. der "Konqueror" in KDE)

• Funktioniert die Konvertierung von RPM-Paketen reibungslos?

• Sonstige Verbesserungen.

Der Listaller ist nur locker mit dem Paketmanagementsystem verbunden, wer den Listaller also wieder loswerden will, muss nur

1

sudo apt-get remove listaller-gtk

ausführen.

Die Expressbuilds können von diesem Server heruntergeladen werden. (!Dies ist keine Repository!)

ZUR LAUNCHPAD SEITE (Bugs, Blueprints, Übersetzung, Code, usw.)

thomas@thomas-desktop:~$ listaller
[FORMS.PP] ExceptionOccurred
  Sender=EFOpenError
  Exception=Unable to open file "/etc/lsb-release"
  Stack trace:
  $08097EC8
  $0809EC14
  $08278FC6
  $080896AA
  $08079699
  $0807B211
  $0807CD56
  $08082698
  $0805C724
TApplication.HandleException Unable to open file "/etc/lsb-release"
  Stack trace:
  $08097EC8
  $0809EC14
  $08278FC6
  $080896AA
  $08079699
  $0807B211
  $0807CD56
  $08082698
  $0805C724

Dabei kommt auch ein Fehler-Dialog: "Unable to open /etc/lsb-release". (Debian Lenny)