Vielleicht sollte man sich mal auf ein einheitliches Distroformat und einheitliche Grundstruktur distroübergreifend (freedesktop) beschränken dann bräuchte man nicht ein neues Monsterpaketformat, das es auch schon wieder in mehreren Eigenentwicklungen gibt.
Problem erkannt aber Umsetzung auf ein weiteres ausgelagert, das nen Rattenschwanz weiterer Probleme mitbringt.
Das ist einfach nur bescheuert was hier "entwickelt" wird.
So funktioniert das nicht. Nicht jede app bringt alle ihre abhängigkeiten mit, sondern es gibt eine kette von runtimes. Z.b. eine gtk runtime, eine java runtime etc. Und das office flatpak setzt dann einfach die entsprechenden runtimes voraus. Im office flatpak wären nur sachen enthalten die relativ speziell mit office zusammenhängen. Natürlich gibt es die runtimes auch in verschiedenen versionen, aber halt für alle distributionen gleich.
Wenn office sagt ich brauche die gtk-runtime-1.2 und die office-runtime-1.3 dann sind die runtimes gleich egal ob unter debian oder fedora. Doppelt hast du die nur auf der platte wenn z.b. libreoffice und calligra unterschiedliche versionen der office-runtime benutzen würden(das wären so sachen wie cups, libjpeg und pdf export support schätze ich). Es ist wirklich ein ganz erheblicher fortschritt, im endeffekt geht es darum das der entwickler eines programms nicht nur vorgeben kann welche lib versionen sein programm nutzt, sondern er kann davon ausgehen das die ganze dependency chain seines programms beim user identisch ist zu der auf seinem entwicklungssystem. Das erleichtert die fehlersuche enorm(reproduzierbarkeit), was wiederum die zuverlässigkeit erhöht.
Das könnte ganz erheblich den arbeitsaufwand reduzieren den distros wie debian oder fedora haben. Die haben eh schon probleme für alle pakete maintainer zu finden, wenn da grosse softwarepakete wie firefox und libreoffice direkt vom "hersteller" kommen ...
Dem müsste dann auch vorgebeugt werden, indem LibreOffice eben nicht auf das neueste Gtk setzt wenn das gar nicht wirklich einen Mehrwert bringt. Nur so können wir verhindern, dass dann 20 Gtk Versionen auf der Platte sind.
In Acht geben müssen wir uns dann vor diesen faulen Skript Kiddies, die übernacht mal eben ein Programm geschrieben haben und alle Flags auf die neuesten Runtimes setzen, weil es eben cool ist. Da müsste es strenge Regeln geben. Z.B. auch eine komplette IDE, die so was leichter macht. Da klickt man dann "ich brauche Funktion X" und die IDE weiß, dass das eben schon in allen Gtk Versionen enthalten ist und zwingt dann den Dev, die älteste mögliche Version zu nutzen, die noch Sicherheitsupdates erfährt. Und primär sollten natürlich die Distro-eigenen Libs benutzt werden.
Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter. Mit anderen worten es gibt da eine runtime die enthält xy, und wenn dann der herausgeber der Runtime meint er hätte einen interessanten mehrwert in seinen entwicklungen dann bringt er eine neue runtime raus. Der drittverwerter, z.b. libreoffice, schaut sich das dann an und entscheidet ob er die neue runtime nutzen will oder nicht. Wenn er sie nutzen will wird sie gründlich getestet und dann als neue dependency als neuer unterbau eingespielt. Der flatpak manager prüft dann im anschluss ob die alte runtime noch von jemand anderem genutzt wird oder nicht und löscht sie entweder oder hält sie auf vorrat.
Das ist wie gesagt auch nicht für jedes kleine miniprogramm gedacht. Wird sicherlich auch "triviale" software geben die einfach sagt "ich will eine gtk runtime > 1.2" und die keine extrawurst braucht weil der entwickler halt drauf achtet wie künfitige runtimes mit seinem programm funktionieren. Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
>Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter.
Hmm... glaub nicht, dass das z.B. bei Debian oder Slackware so funktionieren wird. Da wird so weit wie möglich auf die Distro internen Libs zurücggegriffen werden (weiß nicht wie möglich das bei Flatpak zur Zeit ist).
> Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Daher meine Angst, denn ich glaube, dass manchmal Projekte zu früh einen Bump auf neue lib Versionen machen, ohne wirklich die Features zu brauchen. Und dann kannst du z.B. ein einfaches GUI Programm nicht mal eben so bei Debian kompilieren, usw.
>Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
Da habe ich auch die Angst, dass ich dann irgendwann, falls Linux mal erfolgreicher bin, ein Programm nutzen muss (das hippste Chatprogramm, das alle nutzen oder ein Frontend irgendeiner Behörde...), dass jemand mal eben so programmiert hat und einfach alle neuesten Sachen beim Building gesetzt hat. Und dann gibt es schon die 400MB Szenarien für poplige Frontends.
wenn jedes Paket die ganzen Abhängigkeitne mitbringt?
Office braucht:
tausende Libs + Java + Python +....
Vielleicht sollte man sich mal auf ein einheitliches Distroformat und einheitliche Grundstruktur distroübergreifend (freedesktop) beschränken dann bräuchte man nicht ein neues Monsterpaketformat, das es auch schon wieder in mehreren Eigenentwicklungen gibt.
Problem erkannt aber Umsetzung auf ein weiteres ausgelagert, das nen Rattenschwanz weiterer Probleme mitbringt.
Das ist einfach nur bescheuert was hier "entwickelt" wird.
So funktioniert das nicht. Nicht jede app bringt alle ihre abhängigkeiten mit, sondern es gibt eine kette von runtimes. Z.b. eine gtk runtime, eine java runtime etc. Und das office flatpak setzt dann einfach die entsprechenden runtimes voraus. Im office flatpak wären nur sachen enthalten die relativ speziell mit office zusammenhängen. Natürlich gibt es die runtimes auch in verschiedenen versionen, aber halt für alle distributionen gleich.
Wenn office sagt ich brauche die gtk-runtime-1.2 und die office-runtime-1.3 dann sind die runtimes gleich egal ob unter debian oder fedora. Doppelt hast du die nur auf der platte wenn z.b. libreoffice und calligra unterschiedliche versionen der office-runtime benutzen würden(das wären so sachen wie cups, libjpeg und pdf export support schätze ich). Es ist wirklich ein ganz erheblicher fortschritt, im endeffekt geht es darum das der entwickler eines programms nicht nur vorgeben kann welche lib versionen sein programm nutzt, sondern er kann davon ausgehen das die ganze dependency chain seines programms beim user identisch ist zu der auf seinem entwicklungssystem. Das erleichtert die fehlersuche enorm(reproduzierbarkeit), was wiederum die zuverlässigkeit erhöht.
Das könnte ganz erheblich den arbeitsaufwand reduzieren den distros wie debian oder fedora haben. Die haben eh schon probleme für alle pakete maintainer zu finden, wenn da grosse softwarepakete wie firefox und libreoffice direkt vom "hersteller" kommen ...
Dem müsste dann auch vorgebeugt werden, indem LibreOffice eben nicht auf das neueste Gtk setzt wenn das gar nicht wirklich einen Mehrwert bringt. Nur so können wir verhindern, dass dann 20 Gtk Versionen auf der Platte sind.
In Acht geben müssen wir uns dann vor diesen faulen Skript Kiddies, die übernacht mal eben ein Programm geschrieben haben und alle Flags auf die neuesten Runtimes setzen, weil es eben cool ist. Da müsste es strenge Regeln geben. Z.B. auch eine komplette IDE, die so was leichter macht. Da klickt man dann "ich brauche Funktion X" und die IDE weiß, dass das eben schon in allen Gtk Versionen enthalten ist und zwingt dann den Dev, die älteste mögliche Version zu nutzen, die noch Sicherheitsupdates erfährt. Und primär sollten natürlich die Distro-eigenen Libs benutzt werden.
Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter. Mit anderen worten es gibt da eine runtime die enthält xy, und wenn dann der herausgeber der Runtime meint er hätte einen interessanten mehrwert in seinen entwicklungen dann bringt er eine neue runtime raus. Der drittverwerter, z.b. libreoffice, schaut sich das dann an und entscheidet ob er die neue runtime nutzen will oder nicht. Wenn er sie nutzen will wird sie gründlich getestet und dann als neue dependency als neuer unterbau eingespielt. Der flatpak manager prüft dann im anschluss ob die alte runtime noch von jemand anderem genutzt wird oder nicht und löscht sie entweder oder hält sie auf vorrat.
Das ist wie gesagt auch nicht für jedes kleine miniprogramm gedacht. Wird sicherlich auch "triviale" software geben die einfach sagt "ich will eine gtk runtime > 1.2" und die keine extrawurst braucht weil der entwickler halt drauf achtet wie künfitige runtimes mit seinem programm funktionieren. Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
>Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter.
Hmm... glaub nicht, dass das z.B. bei Debian oder Slackware so funktionieren wird. Da wird so weit wie möglich auf die Distro internen Libs zurücggegriffen werden (weiß nicht wie möglich das bei Flatpak zur Zeit ist).
> Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Daher meine Angst, denn ich glaube, dass manchmal Projekte zu früh einen Bump auf neue lib Versionen machen, ohne wirklich die Features zu brauchen. Und dann kannst du z.B. ein einfaches GUI Programm nicht mal eben so bei Debian kompilieren, usw.
>Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
Da habe ich auch die Angst, dass ich dann irgendwann, falls Linux mal erfolgreicher bin, ein Programm nutzen muss (das hippste Chatprogramm, das alle nutzen oder ein Frontend irgendeiner Behörde...), dass jemand mal eben so programmiert hat und einfach alle neuesten Sachen beim Building gesetzt hat. Und dann gibt es schon die 400MB Szenarien für poplige Frontends.