Von auch als entwickler am Fr, 18. August 2017 um 13:14 #
Dem verlinkten Artikel kann ich nur zustimmen. Für mich ist der OpenSUSE Buildservice momentan die Lösung für die Unterstützung vieler Distributionen.
Evtl. könnte ich mir als Entwickler, der hauptsächlich auf Qt setzt vorstellen, dass die Qt Bibliotheken schon von der Distribution vorinstalliert wären. Das würde allerdings voraussetzen, dass "meine-anwendung" mit einer Qt Version gebaut wurde, die kleiner als die installierte Qt Version ist. Und es setzt voraus, dass die betreffenden Qt Versionen binär (aufwärts) kompatibel sind.
Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre. Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.
„Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre. Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.“
Genau das fängt man sich mit Flatpak, Snappy und Co. Dazu kommt noch der Aufwand, die verwendeten Bibliotheken selbst aktuell zu halten. Vorausgesetzt man will das... Flatpak, Snappy und Co haben nur einen Vorteil, wenn der Entwickler Bibliotheken verwendet, die so selten genutzt werden, dass die Distribution sie nicht von sich aus enthält. Man könnte diese Biblitheken, dann auch als separates Paket anbieten, riskiert damit aber Kollisionen mit den Paketen anderer Anbieter. Hier wäre ein alternativer Ansatz, die Information über solche Bibliotheken über die Distributoren mit anderen Entwicklern zu teilen. Also das, was open source ausmacht: Kooperation. Dazu muss aber die zugrunde liegende Denkweise in die Köpfe so mancher Entwickler dringen...
... oder man schmeißt diese einzelne, selten verwendete Bibliothek einfach direkt mit ins Anwendungspaket. Das Problem lässt sich auch ohne Flatpak, Snappy & Co. lösen - womit man alles nur unglaublich viel schlimmer macht.
Wenn diese Bibliothek ausserhalb des Suchpfades für Bibliotheken, also zum Beispiel unter /opt/... landet und damit für andere Anwendungen „unsichtbar“ bleibt, ist das natürlich auch eine Lösung.
Die gleichen Probleme haben klassische Pakete auch: Spotify: libcef.so (121,6 MB, ist ja im Prinzip Chrome, gilt für jede Electron basierte Anwendung) AfterShot 3: Qt5 (insgesamt über 140 MB an Bibliotheken, einige sind jedoch bestimmt auch AfterShot 3 spezifisch)
Sobald etwas nicht in der Distribution vorausgesetzt werden kann, muss es vom Software-Entwickler ausgeliefert werden. Und in RHEL/CentOS (aber auch Fedora), als RPM basierte Distributionen, fehlt so einiges.
Drittanbieter Repositories sind auch keine Lösung, weil RPMFusion nicht mit Russian Fedora oder UnitedRPMS zusammenarbeiten wird. Ob die Pakete überhaupt ausreichend aktualisiert werden, ist noch eine ganz andere Frage (bei Ubuntu Universe, zum Beispiel, sieht es ja eher schlecht aus). Abgesehen davon hat man damit das gleiche Problem:
die Anwender damit zwingt darauf zu vertrauen, das Dritte – von denen man im Grunde nicht weiß, wie vertrauenswürdig sie sind – ihre Hausaufgaben machen!
Wobei: Wenn der Entwickler nicht vertrauenswürdig ist, warum sollte man dessen Software nutzen?
http://www.fedora-blog.de/flatpak-und-snap-sind-nicht-die-loesung-
des-problems-sondern-machen-es-noch-schlimmer
Für Entwickler vielleicht möglich, ich als Anwender möchte aber nicht auf rpm- oder deb-basierende Verwaltung verzichten.
Jan
Dem verlinkten Artikel kann ich nur zustimmen.
Für mich ist der OpenSUSE Buildservice momentan die Lösung für die Unterstützung vieler Distributionen.
Evtl. könnte ich mir als Entwickler, der hauptsächlich auf Qt setzt vorstellen, dass die Qt Bibliotheken schon von der Distribution vorinstalliert wären.
Das würde allerdings voraussetzen, dass "meine-anwendung" mit einer Qt Version gebaut wurde, die kleiner als die installierte Qt Version ist.
Und es setzt voraus, dass die betreffenden Qt Versionen binär (aufwärts) kompatibel sind.
Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre.
Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.
„Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre.
Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.“
Genau das fängt man sich mit Flatpak, Snappy und Co. Dazu kommt noch der Aufwand, die verwendeten Bibliotheken selbst aktuell zu halten. Vorausgesetzt man will das...
Flatpak, Snappy und Co haben nur einen Vorteil, wenn der Entwickler Bibliotheken verwendet, die so selten genutzt werden, dass die Distribution sie nicht von sich aus enthält. Man könnte diese Biblitheken, dann auch als separates Paket anbieten, riskiert damit aber Kollisionen mit den Paketen anderer Anbieter. Hier wäre ein alternativer Ansatz, die Information über solche Bibliotheken über die Distributoren mit anderen Entwicklern zu teilen. Also das, was open source ausmacht: Kooperation. Dazu muss aber die zugrunde liegende Denkweise in die Köpfe so mancher Entwickler dringen...
who knows
... oder man schmeißt diese einzelne, selten verwendete Bibliothek einfach direkt mit ins Anwendungspaket. Das Problem lässt sich auch ohne Flatpak, Snappy & Co. lösen - womit man alles nur unglaublich viel schlimmer macht.
Wenn diese Bibliothek ausserhalb des Suchpfades für Bibliotheken, also zum Beispiel unter /opt/... landet und damit für andere Anwendungen „unsichtbar“ bleibt, ist das natürlich auch eine Lösung.
who knows
Die gleichen Probleme haben klassische Pakete auch:
Spotify: libcef.so (121,6 MB, ist ja im Prinzip Chrome, gilt für jede Electron basierte Anwendung)
AfterShot 3: Qt5 (insgesamt über 140 MB an Bibliotheken, einige sind jedoch bestimmt auch AfterShot 3 spezifisch)
Sobald etwas nicht in der Distribution vorausgesetzt werden kann, muss es vom Software-Entwickler ausgeliefert werden. Und in RHEL/CentOS (aber auch Fedora), als RPM basierte Distributionen, fehlt so einiges.
Drittanbieter Repositories sind auch keine Lösung, weil RPMFusion nicht mit Russian Fedora oder UnitedRPMS zusammenarbeiten wird.
Wobei: Wenn der Entwickler nicht vertrauenswürdig ist, warum sollte man dessen Software nutzen?Ob die Pakete überhaupt ausreichend aktualisiert werden, ist noch eine ganz andere Frage (bei Ubuntu Universe, zum Beispiel, sieht es ja eher schlecht aus). Abgesehen davon hat man damit das gleiche Problem: