Neues Paketformat für Ubuntu Apps

Auf der Ubuntu-Mailingliste machte Colin Watson gestern eine große Ankündigung, welche die Installation von Apps auf Ubuntus neuer Mobilumgebung Ubuntu Touch angeht.

Eigenes Paketformat¶

Auf der Mailingliste beschreibt Colin Watson die Diskussion, die sich in den letzten Monaten ergab. Als Ergebnis will er ein eigenes Paketformat für die Ubuntu Apps anbieten, sodass Drittanbieter es leichter haben, Apps zu erstellen und hochzuladen. Watson betont aber, dass dieses neue Format nicht die aktuell vorhandenen Paketformate (unter Ubuntu wird APT genutzt) berühren wird.

Details¶

Das neue Paketformat soll sehr leichtgewichtig werden, weswegen auch die bei APT so geschätzte Abhängigkeitsstruktur wegfallen wird. Jede Applikation muss ihre Abhängigkeiten also selbst befriedigen. Damit sich die Anwendungen nicht in die Quere kommen, wird jede in einem eigenen Ordner gespeichert (entgegen der bekannten Verwaltungsstruktur auf Linux-Systemen). Ein wichtiger Aspekt ist die Installation von Anwendungen ohne Root-Rechte. Wo genau die Daten im System abgelegt werden, wird nicht erwähnt.

Neben der Anwenderseite soll es aber auch für Entwickler einfacher werden. Der Paketbau einer Ubuntu App soll mittels einiger Python-Skript erfolgen, sodass die Voraussetzungen auf den meisten Linux-Systemen bereits gegeben sind. Damit man bestehende Tools auf das entstehende Binärformat anwenden kann, soll dieses ähnlich zu bereits bestehenden definiert werden.

Colin Watson hat bereits einen Prototypen gebaut, dem aber noch die ein oder andere Kleinigkeit fehlt. Daneben fehlen auch Beispiel und die Integration in das Ubuntu SDK (Software Developer Kit). Nicht Teil seines Prototyps ist die Anbindung an einen App Store oder das Hochladen der fertigen Pakete.

Kritik¶

Da Watson bereits im Voraus erahnen konnte, dass Kritik aus anderen Bereichen der Linux-Community laut wird, wieso er nicht bestehende Paketformate nutzt, geht er auf der Mailingliste auch darauf ein. Er listet seine Erfahrungen mit verschiedenen Formaten wie Androids APK, Listaller 🇬🇧 oder 0install 🇬🇧. Alle Formate haben in seinen Augen kleinere Schwächen, die es für die Ubuntu Apps erst auszumerzen gäbe.

Immerhin betont Watson immer wieder, dass das neue Paketformat und auch die Tools drumherum so rudimentär erstellt sein sollen, dass der Prozess auch für andere Plattformen in der Zukunft sinnvoll eingesetzt werden kann. Ob sich andere Mobil-OS-Hersteller an Canonicals Vorgaben orientieren, wird sich zeigen.

Links¶

Veröffentlicht von Dee | 9. Mai 2013 17:55 | Kategorie: Rund um Ubuntu | # Fehler im Artikel melden

bliet	1 9. Mai 2013 19:43 Alle Formate haben in seinen Augen kleinere Schwächen, die es für die Ubuntu Apps erst auszumerzen gäbe. Nennt er auch die Schwächen? Und warum nicht die Schwächen ausmerzen, anstatt das Rad neu zu erfinden?
skull-y	2 9. Mai 2013 20:25 ..., dass dieses neue Format nicht die aktuell vorhandenen Paketformate (unter Ubuntu wird APT genutzt) berühren wird. Ist das Pektformat nicht *.deb und APT die Paketverwaltung? Dann wären yum, pacman, zypper usw. ja eigenständige Paketformate, was sie ja nicht sind. Was die Schwächen der Paketformate angeht, schliesse ich mich @1: an: Warum nicht die Schwächen ausmerzen, anstatt das Rad neu zu erfinden? Sollte doch einfache, etwas Bekanntes und dessen Schwächen zu verbessern, als etwas komplett Neues zu nehmen? Auch da können (und werden sicherlich auch) andere Schwächen zu finden sein.
jakon Lokalisierungsteam	3 9. Mai 2013 20:29 Das neue Paketformat soll sehr leichtgewichtig werden, weswegen auch die bei APT so geschätzte Abhängigkeitsstruktur wegfallen wird. Jede Applikation muss ihre Abhängigkeiten also selbst befriedigen. Meiner Meinung schließt sich das auch. Soll ab jetzt jede Anwendung ihre zig Librarys selbst mitbringen? Das würde doch dazu führen, dass man ein und dieselben Bibliotheken und Befehle doppelt und dreifach installiert.
kaputtnik	4 9. Mai 2013 20:48 @1: @2: Von wegen „Rad neu erfinden“... manche Leute unterstellen den Ubuntu-Entwicklern ein NIH-Syndrom... @3: Ja, so verstehe ich das auch. Windowsverhältnisse.
danubio	5 9. Mai 2013 20:59 Das neue Paketformat soll sehr leichtgewichtig werden, weswegen auch die bei APT so geschätzte Abhängigkeitsstruktur wegfallen wird. Jede Applikation muss ihre Abhängigkeiten also selbst befriedigen. Das sollte doch mit deb-Paketen auch möglich sein: Alle abhängigen Dateien mit einpacken und keine Abhängigkeiten definieren beim Paketieren.
konstin	6 9. Mai 2013 21:11 @4: Ich sage nur Upstart... Das sollte doch mit deb-Paketen auch möglich sein: Alle abhängigen Dateien mit einpacken und keine Abhängigkeiten definieren beim Paketieren. Der Paketmanager muss dadurch viel wengier können und kann deswegen deutlich schneller sein.
jo-master	7 9. Mai 2013 23:51 das ist totaler blödsinn. die paketmanager sind eine der größten stärken eines linux-systems. dies nun zu verwerfen, bedeutet einen unnötigen rückschritt. für die angepeilten mobilgeräte, sollte es an der nötigen leistung zumindest nicht scheitern.
katze_sonne	8 10. Mai 2013 01:42 Hmm ja... ein sehr kontroverses Thema 😀 Klar erscheint es auf den ersten Blick wenig sinnvoll, wenn bestimmte Libraries doppelt und dreifach mitgeliefert werden... Andererseits habe ich auch schon öfters Probleme mit dem Konzept der APT-Paketverwaltung gehabt... Beispiel: Sowohl KDEnlive als auch OpenShot haben auf das MLT-Framework zurückgegriffen. Allerdings benötigten beide andere Versionen. Also war es leider nicht möglich, beide Probleme gleichzeitig zu benutzen... Von daher erscheint es - zumindest in einigen Fällen - auch sinnvoll, manche Dinge doppelt vorzuhalten (und mal ehrlich: Heute hat selbst ein Smartphone das Vielfache des Speicherplatzes zur Verfügung, den zum Zeitpunkt der Entwicklung dieses Konzeptes ein Desktoprechner hatte - mein erste Windows XP Rechner hatte damals eine 16GB (oder waren es nur 14GB?) Festplatte 😀 - welche Vorteile das sonst noch haben sollte, weiß ich gerade nicht). Das Wichtigste dürfte aber vor allem sein, dass dadurch eines erreicht wird: Einfachkeit. Das hat vor allem auch den Vorteil, potenzielle Entwickler nicht abzuschrecken. @1: Natürlich weiß ich nicht, wo genau die Schwächen liegen, aber ich könnte mir gut vorstellen, dass er dort einige konzeptionelle Schwächen sieht. Und zu einem Projekt zu gehen und es von einen mehr oder weniger stark verändertem Konzept zu überzeugen, dürfte wirklich schwer sein (oder hast du schonmal versucht, mit einem Entwickler Grundsatzentscheidungen zu diskutieren? Das versucht man auch nur einmal 😀 (kommt natürlich auf die Person drauf an, aber viele sind da sehr... "eigen" 😉)). Sehr interessant finde ich auch das Prinzip der Ordnerstruktur, also pro App ein Ordner. Genauso gehört sich das mMn. Das hat mich bei Linux ehrlichgesagt schon länger gestört, dass dort so eine so komplexe Ordnerstruktur gewählt wurde. Zumindest für den Durchschnittsnutzer ist sie nur schwer durchschaubar. Die Trennung von Programmen in Ordnern im Ordner "Programme" unter Windows fand ich da irgendwie schon immer sympathischer (auch wenn es viele Ausnahmen gibt, z.B. die Registry oder die Anwedungsdaten usw.). Ich hoffe mal, dass diese Verstreuung unter Windows hier nicht auch übernommen werden. ☺
Ximion	9 10. Mai 2013 19:02 Naja, alle Punkte die Colin in seinem Beitrag anspricht, sind exakt gleich vom Listaller Project abgedeckt. Und als Listaller Entwickler hat man sich nie bei mir gemeldet, um eventuelle Fragen zu klären. Insofern ist das schon NIH, allerdings scheint man doch offen für Diskussion zu sein. Da allerdings schon fertiger Code bei Ubuntu existiert und die Canonical-Angestellten den wohl auch nutzen wollen, sehe ich keine allzu großen Chancen für andere Projekte.
noisefloor Ehemaliger	10 11. Mai 2013 13:23 @6: Wieso Upstart? Also was meinst du damit?
dbet	11 11. Mai 2013 18:00 @7: Ich hatte ein Nokia N900, welches eine vollständige Paketverwaltung besass. Es war tatsächlich APT, denn das Betriebssystem Maemo basierte auf Debian. Obwohl ich totaler Fan von einer Paketverwaltung und inbesondere derjenigen von Debian bin, konnte ich damit auf dem N900 nicht viel anfangen. Die Handhabung war viel zu kompliziert für ein so kleines Gerät.
Netzmaat_007	12 11. Mai 2013 18:12 Unter welchen Umständen machen diese ganzen Canonical Eigenentwicklungen Sinn? Wenn vom Prizip Freie Software auf Basis freiwilliger oder bezahlter Programierarbeit, auf das Prinzip zentral betriebene Server umgestellt wird? (Das Umwidmungswort lautet SaaS "Software as a Service".) Wenn Serverkomponenten und damit die Protokolle unter proprietäre Kontrolle gebracht werden sollen? Wenn man das OS als "Firmware" Images auf Endgeräte spielen möchte? Wenn man die Installation proprietärer Binärblobs untersützten möchte, für die es darauf ankommt ein feste (ABI) Umgebung in einer bestimmten Version zu haben? (Freie Software wird beim Paketerstellen sonst einfach neu Kompiliert.) Wenn von einem zentralen "App ecosystem" möglichst nur Canonical profitieren soll, bei dem Andere sich später evtl. anschließen dürfen? –- Schon Nokias N900 kam mit .deb, apt-get und einer mobilen apt-Paketverwaltungs "App" zurecht.
PhotonX	13 11. Mai 2013 19:09 Hier ist übrigens eine News mit diesem Artikel als Quelle: http://www.computerbase.de/news/2013-05/ubuntu-apps-sollen-eigenes-paketformat-bekommen/
katze_sonne	14 12. Mai 2013 01:08 @10: Ich glaube er meint, dass Upstart eine Canonical Eigenentwicklung war / ist, anstatt auf systemd zu setzen, was viele andere benutzen. (ich war gerade zu faul zu recherchieren, also ohne Garantie auf Richtigkeit, aber das war das, was in meinem löchrigen Gedächtnis gerade noch hängengeblieben ist 😉)
noisefloor Ehemaliger	15 12. Mai 2013 08:27 @14: Upstart ist älter als systemd und war früher einsatzbereit. Kann also nicht sein ☺
konstin	16 12. Mai 2013 18:34 @14, @15: Ich finde es nicht sinnvoll, dass canonical zu den meisten anderen Distributionen inkompatible Anwendungen entwickelt. Vielfalt ist zwar schön und auch sehr wichtig, in meinen Augen braucht man in bestimmten Bereichen aber auch einheitliche Systeme. Besonders bei systemrelevanten Anwendungen sind einheitliche Standards wichtig, damit man nicht für jede Distribution ein anderes Programm schreiben muss. Es wäre viel sinnvoller wenn canonical einsehen würde, dass es mehr bringt, wenn man an bestehenden Projekten mitarbeitet und diese dann eventuell an die eigenen Bedürfnisse anpasst, anstatt alles selber zu entwickeln. Nur weil Upstart früher fertig war, ist es nicht besser, sondern meiner Ansicht nach eher schlechter. Dass Systemd einige Vorteile gegenüber Upstart hat, wird auch dadurch gezeigt, dass Distributionen wie Fedora und OpenSuse nur kurz Upstart angeboten haben, jetzt aber, wie auch Mandriva, Mageia, Gentoo Red und Hat Enterprise Linux, zu Systemd gewechselt sind.
Kelhim	17 12. Mai 2013 22:41 Man sollte sich unbedingt die hier bereits verlinkte Spec-Seite und die Mailing-Liste durchlesen, dann beantwortet sich manche Kritik hier von selbst.
noisefloor Ehemaliger	18 13. Mai 2013 16:54 @16: Dann muss du diesen Vorwurf aber genau so an systemd machen - da haben die Entwickler auch "was neues" entwickelt anstatt bestehende Projekte (wie Upstart) zu unterstützen. Denn gleichen Vorwurf könntest du auch Linus Torvalds machen, dass er Linux entwickelt hat, anstatt ein bestehendes Projekt wie Minix zu unterstützen. Sprich: wenn du deinen Vorwurf allen Softwareentwicklern machst würden wir alle vielleicht noch ein 70er Jahre Unix benutzen. 😉
MisterFlow	19 2. September 2013 02:54 @18: Wenn man davon absieht, dass upstart ziemlich broken by design ist, gibts da immernoch die CLA Nette Randnotiz zum NIH-Syndrom: Upstart hängt von libnih (von Canonical entwickelt) ab. Das Rad neu erfinden ist vollstens in Ordnung wenn man es gut begründen kann. Daran hapert's aber bei Canonical immer ein wenig. Schade dass sich die Herrschaften von Canonical nicht mit Lennart Poettering zusammensetzen wollen, der hat nämlich was ähnliches in petto (und wie auch bei systemd vs upstart hat er bessere ideen und argumente...): http://0pointer.de/public/gnome-asia-2013-apps.pdf