Ich verstehe es auch nicht. Da wurde die ganze Zeit die Paketverwaltung als großes Plus für Linux angepriesen und plötzlich ist etwas anderes viel besser, dass mit der klassischen Paketverwaltung nicht mehr viel gemein hat. Statisch gepackte Software hat schon ihren Reiz, aber dafür braucht man doch kein Snap.
Das liegt daran das die Distributionen das Konzept nicht konsequent durchgezogen haben. Jedes neue Major Release einer Distribution wirft letztlich alles über den Haufen und fängt neu an.
Es sind in sich geschlossene Systeme, externe Einflüsse sind nicht vorgesehen. Es gibt zwar externe Repositorys, aber die haben ihre eigenen Schattenseiten und ich hatte zumindest unterm Strich damit immer Probleme. Sei es das Pakete nicht gepflegt werden, das Vertrauen nicht da ist, oder es beim Upgrade Probleme gibt.
Kritik wurde stets abgelehnt und man hat versäumt sich den geänderten Umständen anzupassen. Schon recht früh sind Lösungen wie klik/AppImage entstanden die aber auch wenig Beachtung fanden. Es fehlte halt eine Distribution die sich darauf ausrichten wollte.
Canonical fand dann auch an sich mit dem Problem zu befassen. Vielleicht erst mit Fokus auf den mobilen Markt aber schnell wurde klar das es auf dem Desktop auch Hilfreich sein konnte. Recht schnell kam dann auch jemand bei Red Hat darauf und skizzierte was wir bald Flatpak, ehemals xdg-app nennen sollten.
Alle dieser Lösungen haben Nachteile die man mit dem Paketsystemen hätte lösen können, aber auch hier gab es keine Bewegung in den letzten 5 Jahren bei den Distributionen.
Um es kurz zu machen. Snappy, Flatpak und AppImage erlauben es mit alte oder neue Anwendungen unabhängig der Distibution zu verwenden. Zum Beispiel, ich nutze auf den meisten Servern ein Debian. Nun kommt der Ruf nach PHP 7.2 aus unterschiedlichen Gründen (Performance oder weil neue PHP Libs die Version voraussetzen). Debian 9 kommt aber nur mit php 7.0. Debian weigert sich ein aktuelles PHP bereitzustellen. Also was soll ich nun tun? Selber compilieren? Wäre eine Möglichkeit aber ich müsste mir dann die ganze pflege ans Bein binden. Repositorys von Dritten? Das ist wieder so eine Vertrauensfrage, immerhin gebe ich einer fremden Person letztlich root Rechte.
Am liebsten wäre es, wenn ich die neue Version explizit von meiner Distribution bekommen würde. Oder gar vielleicht auch eine alte Version. Zum Beispiel habe ich noch eine alte PHP 5 Anwendung laufen. Diese laufen aber auch nicht auf Debian 9 sondern in einer Isolierten VM die eh nur im Intranet laufen muss.
Das nächste wäre wohl ein offizielles Snap, Flatpak oder AppImage.
Einer der Debian-PHP-Maintainer bietet fertige Pakete für PHP 7.2 (und PHP 5.6) für Debian 9 an. Da er auch für die "normalen" PHP-Pakete zuständig ist, sind diese quasi "trotzdem" perfekt in die Distribution integriert. Was will man mehr?
Das ist Klasse, gibt es auch eine Adresse wo ich die finde (Ich hatte zuletzt letzte Woche oberflächlich mal nach einer Quelle gesucht aber keine gefunden)? Das Löst zumindest eins meiner Probleme.
Die Grundlegende Kritik bleibt aber weiterhin bestehen. Es ist schade das es die PHP 7.2 und 5.6 Pakete nicht offiziell gib oder zumindest als Backport. PHP kannst du auch durch jede Beliebige andere Anwendung ersetzen. Zum Beispiel vor ein paar Jahren hatte das Handshake Projekt sich entschlossen divx/xvid Support zu streichen. In neuen Distributionen hatte man nun das Problem das die bekannte Anwendung nun einen Codec den man nutze nicht mehr anbot. Der User hat auch keine einfache Möglichkeit zu sagen ich nehme dann einfach die Alte Version und installiere sie parallel.
Es geht mir nicht darum, gegen Snap zu sein - ganz im Gegenteil. Es hat schon seine Berechtigung, wenn es um Software geht, die man aus einer anderen Quelle installiert und auch beim nächsten Distributionsupgrade noch laufen soll. Eben wie z.B. VS Code, wenn es nicht offiziell von der Distribution unterstützt wird.
VS Code ist vom Erfinder von Typescript und damit eine der besten freien Möglichkeiten, Typescript zu programmieren. Ich persönlich habe eine Erweiterung für Eclipse gekauft (von Genuitec), eine weitere Möglichkeit wäre Intellij gewesen. Aber VS Code funktioniert gut, wenn man nur Typescript programmieren möchte.
Aber hast du dir mal Docker angesehen? Gerade wenn du noch eine PHP5-Anwendung laufen hast und Debian wegen irgendwelchen Gründen auf eine alte Version festgenagelt ist.
Das gilt übrigens auch für Andre. Gerade zur Entwicklung.
Es geht mir nicht darum, gegen Snap zu sein - ganz im Gegenteil. Es hat schon seine Berechtigung, wenn es um Software geht, die man aus einer anderen Quelle installiert und auch beim nächsten Distributionsupgrade noch laufen soll.
Aber die Berechtigung sollte eigentlich nicht vorhanden sein. Es ist eine Notlösung wegen einer veralteten Distributionspolitik. Es spricht nichts dagegen das eine Distribution auch unterschiedliche Versionen verteilt, je nach dem Bedarf der Anwendung. Das man nur eine Version einer Bibliothek ausliefern will hat sich seit dem erledigt, seit die Bibliotheken auf Abwärtskompatibilität oft keinen Wert legen. Die Pflege von LTS Paketen im Upstream zu erledigen ist schon fast ein Sakrileg.
Aber hast du dir mal Docker angesehen? Gerade wenn du noch eine PHP5-Anwendung laufen hast und Debian wegen irgendwelchen Gründen auf eine alte Version festgenagelt ist.
Darauf würde es wohl hinauslaufen, aber die Lösung mit der VM funktioniert und macht so keinen Aufwand. Sie ist auch nicht extern zu erreichen was einem da Druck heraus nimmt. Und da man auch nicht für eine neue Lösung noch Portierung bezahlen will, oder Zeit einräumt die Anwendung in einen Docker Container zu verschieben nicht bewilligt wird, wird das wohl noch einige Jahre so bleiben.
> Am liebsten wäre es, wenn ich die neue Version explizit von meiner Distribution bekommen würde.
Schau dir mal Fedora an bzw. das bald erhältliche RHEL/CentOS 8: Der Paketmanager unterstützt dort sogenannte Module bzw. Application Streams, was nichts anders bedeutet als das du pro Paket auswählen kannst welchen Versionszweig du benutzen willst. Du könntest deine PHP-Version dann einfach installieren:
dnf module enable php:7.2 dnf upgrade
Wie lange die einzelnen Versionszweige dann unterstützt werden weiß ich nicht - bei Fedora ist die Fragestellung egal, weil das sowieso keine LTS-Distro ist, bei RHEL glaube ich aber nicht dass die z.B jede einzelne PHP-Version 10 Jahre lang unterstützen, das wäre ja zu viel Arbeit. Wahrscheinlich wird es ähnlich wie bei den Software Collections aus RHEL 7 sein, dass jede Version nur ein paar Jahre unterstützt wird und man danach upgraden muss, oder man bleibt eben bei der Standard-Version.
Parallel geht das mit den Modulen nicht, aber mit den Software Collections (in CentOS/RHEL, Fedora hat das nicht). Dann hast du aber keine Standard-Pfade mehr, sondern sowas wie /opt/php_72 oder so.
Wenn du mehrere Versionen parallel betreiben willst, dann sei dir aber sowieso zu Container-basierten Lösungen wie Docker geraten. Das ist heute der allgemein übliche Weg, und bietet darüber hinaus noch weitere Vorteile, wie z.B automatisches Deployment deiner Installation auf ein anderes System.
Du solltest deine Container aber natürlich warten und Sicherheitspatches installieren. Das wird leider oft vergessen, du hast dann im Prinzip mehrere ineinander geschachtelte Betriebssysteme im Einsatz, die alle Updates brauchen. Das Problem besteht bei Snap/Flatpak natürlich genauso.
Debian hat halt keine neuen Versionen freigegeben, weil das niemand testet.
Das Problem ist, dass bestimmte Software auf andere angewiesen ist und andere wiederum eventuell nicht mehrfach installiert werden kann, ohne dass sie sich behindern.
Beispielsweise: Der Webserver ist normalerweise nur für eine PHP-Version benutzen. Natürlich geht es: https://tecadmin.net/install-multiple-php-version-apache-ubuntu/
Aber auch in der anderen Richtung: Funktioniert das moderne PHP mit den alten Bibliotheken. Wie sieht es mit den Zusatzmodulen aus?
Ist deine Lösung also exotisch genug, dann wirst du nichts finden oder nur etwas, was nicht offiziell getestet ist.
Und um dieses Abhängigkeits-Problem zu minimieren, nutzen manche Leute halt Docker. Da baut man sich ein Script, was die Applikation lauffähig verpackt, die Daten kommen in einen eigenen Container oder ins Hostfilesystem und sofern es Updates gibt, wird die Anwendung halt neu gebaut.
Docker ist eine Mini-VM, die von außen nur über die Sever-Ports angesprochen wird (selbstverständlich alles konfigurabel). Die VM selbst ist minimalistisch und auf dem Host muss nur Docker laufen.
Ist auch zur Entwicklung praktisch.
Aber du kannst natürlich auch Pakte von einer vertrauenswürdigen Person nehmen. Nur bei exotischen Lösungen besteht auch immer die Gefahr, dass da dann Sicherheitpatches nicht so häufig und evtl. unvollständig kommen. Wenn dus selbst baust, brauchst du auch ein tiefes Verständnis.
Fazit: Wenns exotisch wird, dann verlässt du ausgetretene Pfade und bist auf die selbst angewiesen. Docker löst das beispielsweise, indem spezialisierte Pakete einzeln gewartet werden.
Die Probleme sind aber nicht neu. Seit über 20 Jahren hat man dieses Problem, aber man war in seiner eigenen Blase und alles war ok.
Das es keine Lösung gibt die von Heute auf Morgen da ist, sollte allen klar sein, aber man kann darauf hin arbeiten.
Ein Anfang wäre wenn die Bibliotheken aufhören würden ständig die API und ABI in Minorversionen umzubauen. Oder der Funktionsumfang im Build Prozess festgelegt wird, das teilt die möglichen Kombinationen an Versionen und mögliche Konfigurationen noch weiter auf. Nicht falsch verstehen, ich mag die Konfigurationsmöglichkeiten. Aber als Systemweite Bibliothek sollte es klar sein was man bekommt ganz gleich welche Distribution.
Und im Fall Debian müsste man nicht mal so viel ändern. Die können weiterhin ihr Ideal umsetzen, aber wenn es eine neue Releaseversion gibt die auf Wunsch auch bereitstellen. Bibliotheken die nicht abwärtskompatible sind kann man ja mit einem neuen .so Namen versehen oder es einen dispatcher erledigen lassen damit die korrekte Version geladen wird. Die alten Anwendungen kann man so auch noch weiter anbieten.
Aktuell laufen wir ja darauf hin das wir viele unterschiedliche Bibliotheksversionen und Konfigurationen der Bibliotheken im System haben werden, die aber eventuell nicht mal gepflegt werden.
Docker ist eine Mini-VM, die von außen nur über die Sever-Ports angesprochen wird (selbstverständlich alles konfigurabel). Die VM selbst ist minimalistisch und auf dem Host muss nur Docker laufen.
Ich kenne Docker, aber mich stört das es keine offiziellen Images gibt und wieder dritte ihre Finger im Spiel haben die teils auch noch selbst an den Anwendungen werkeln.
Ein Problem hast du ja auch schon davon genannt, es ist aber letztlich ein Kompromiss und die Distributionen sollten sich Gedanken machen warum es dazu kam.
dann verrate doch mal exemplarisch bitte ganz kurz wie ich beispielsweise * auf debian8 php7 mit db2 support als statisch kompiliertes packages in aktueller version bekomme. * auf debian8 kdevelop v5 als statisch kompiliertes package in aktuellr version bekommme. * auf debian10 xmms1 als statisch kompiliertes packages zur verfügung bekomme.
bitte jetzt keine ausflüchte wozu man das brauchen solle, oder das ich ein distupgrade fahren solle. es könnte schliesslich sein das ich ganz bewusst noch ein abgeschottetes debian8 weiter einsetzen möchte.
und da du so selbstverständlich davon redest das die jetzige lösung dafür offenbar garnicht notwendig sein und klassische paketverwaltung soviel besser sei - nun denn - bitte ich freuue mich dazu zu lernen.
meiner erfahrung nach arten alle 3 o.g. einsatzzenarien bei klassischer paketverwaltung praktisch zu einem gefrickel aus das man "bestenfalls" nur noch als erfahrener linux-anwender mit fortgeschrittener erfahrung gelöst bekommt.
Von Paketverwaltungen werden übers am So, 7. April 2019 um 09:11 #
Neueste PHP-Versionen baue ich mir immer selber, PHP ist ziemlich einfach selber zu builden, ausserdem ist dann genau das drinn was ich brauche. Ausserdem gibts Containerimages von bitnami,... für neueste Versionen mit dem ganzen üblichen Gerümpel den man sonst noch braucht (DBs, CMS,...).
Snap finde ich in der Hinsicht gar nicht mal so schlecht, es bügelt die Nachteile der klassischen Paket und Grundproblem von Linux aus.
Bsp neuester Opera: Bei dem gehen keine h.264 Videos mehr weil die lib der Distro nicht mehr zu der Version von Opera passt, vorher gings noch. Dolle Wurst dieses libchaos. Ich verstehe nicht warum solche Problemfälle nicht generell statisch reinlinkt oder sowas überhaupt ohne Vorwarunung installierbar ist.
Also ich halte den PM zum Teil für Mist und das schon fast seit einem Jahrzehnt. Snap, Flatpack halte ich aber auch für großen Mist. Zum Glück bieten viele Hersteller mittlerweile ihre Software auch für Linux an, wie auch bei Windows. Das landet bei mir dann im Application-Ordner und wird von dort ausgeführt. Auch wird Software teilweise dorthin kompiliert.
Zunächst dachte ich, mit dieser Idee bin ich ein Exot. Aber in Unternehmen die viel auf Linux setzen, verzichten sie auch auf PM. Ähnlich wie ich, wird die Software irgendwohin geparkt und von dort ausgeführt. Das hat den Vorteil, das die Distributionsversion egal wird. Egal ob LTS oder Rolling-Release. Man besitzt die gewünschte Software und gut ist.
Den PM nutze ich dann nur noch zum update der eigentlichen Distro, die Distributionseigene Software ist mir aber eigentlich egal.
Haha - Snap/Flatpak/Appimage ist selbstverständlich ein Eingeständnis der Tatsache, dass man es nicht (besser) kann. Klar. Es ist ein blutiger Kompromiss, den man genau deshalb geht, weil man meint verstanden zu haben, dass man eine gescheite Lösung halt einfach nicht hinbekommt. Kann der Mensch halt einfach nicht. Es wird zuviel gepfuscht, gewieselt, rauf, wieder runter, jetzt einmal seitlich die Abkürzung genommen; und bei der nächsten Iteration natürlich alles leicht variiert, damit sich auch keine Systematik bilden kann, die den Namen verdient hätte. Er merkt es auch selbst garnicht, und hält das derzeit alles für eine tolle moderne Gangart. Kritische Reflektion: Nööö, das nervt nur beim Netflixen...
Das führt dann zu solchen markabren Aprilscherzen, dass Debian jetzt RPM machen würde... Wäre ja eigentlich das Normalste von der Welt, dass es mal mittelfristig mal _ein_ Format gegeben hätte.
Jetzt hisst man halt die weisse Flagge und packt _alles_ in eine Zip-Datei, und schreibt am Ende "Snap" dran. Derbe doof. Nicht doof genug: Unsere "Lessons Learned" der letzten Jahre schreien ja auch nach Zentralisierung. Warum sollte jeder einfach Pakete anbieten... Cyberwar würde euch alle dahinraffen...
Aber MSI kann noch soviel mehr nicht, da kannst du dir (mutmaßlich) garkein Bild von machen. Der Vergleich ist ungerecht imho. Von MergeModules bis Bootstrapper (siehe Wix ; da sind die Installer dann EXE-Files - ist gerade der letzte Schrei im Windoofland) gibt es da noch soviel Ersatzkonstrukte... Und sie funktionieren _alle_ nicht (oder freundlicher: es sind alles seehr pragmatische Lösungen, die nicht von allzuviel Eleganz geplagt sind)...
Jetzt hisst man halt die weisse Flagge und packt _alles_ in eine Zip-Datei, und schreibt am Ende "Snap" dran.
Ist keine ZIP-Datei, sondern ein schreibgeschütztes Overlay-FS. Und alles ist auch nicht drin, sondern nur die Sachen die nicht in der Runtime vorkommen. Und das ist bei den allermeisten Programm relativ wenig.
Ja, ich habe in der Polemik wieder mal die Details schleifen lassen. Es ist keine Zip-Datei, sondern irgendein Squashfs-Kram (Overlay-FS nur zur Laufzeit für FS-Tricks, RW-Zugriff, usw). Sprich: Eine ZIP-Datei, für die du fast keine Tools findest.
Und es ist auch nicht ganz alles drin. Auf einen Kernsatz, den man nicht immer einpacken muss, konnte man sich vorher noch einigen, und hat ihn Runtime genannt... Immerhin... Also; auf einen Kernsatz für Gnome, einen anderen für KDE, ... *g*
Mal sehen, wie viele Wiesel-Tunnel noch kommen, bis alle Probleme gelöst sind (bspw. das Programm das System-Styling bekommen; ich kenne das zugegebenermaßen nur von Flatpaks, aber es ja ein konzeptbedingtes Problem).
warum muss man eigendlich so einen Exorbitalcrap wie MSI-Container nachbilden ??
:
Auf dem Desktop hat der Rotz einfach NIX verloren!
Ich verstehe es auch nicht. Da wurde die ganze Zeit die Paketverwaltung als großes Plus für Linux angepriesen und plötzlich ist etwas anderes viel besser, dass mit der klassischen Paketverwaltung nicht mehr viel gemein hat. Statisch gepackte Software hat schon ihren Reiz, aber dafür braucht man doch kein Snap.
Das liegt daran das die Distributionen das Konzept nicht konsequent durchgezogen haben. Jedes neue Major Release einer Distribution wirft letztlich alles über den Haufen und fängt neu an.
Es sind in sich geschlossene Systeme, externe Einflüsse sind nicht vorgesehen. Es gibt zwar externe Repositorys, aber die haben ihre eigenen Schattenseiten und ich hatte zumindest unterm Strich damit immer Probleme. Sei es das Pakete nicht gepflegt werden, das Vertrauen nicht da ist, oder es beim Upgrade Probleme gibt.
Kritik wurde stets abgelehnt und man hat versäumt sich den geänderten Umständen anzupassen. Schon recht früh sind Lösungen wie klik/AppImage entstanden die aber auch wenig Beachtung fanden. Es fehlte halt eine Distribution die sich darauf ausrichten wollte.
Canonical fand dann auch an sich mit dem Problem zu befassen. Vielleicht erst mit Fokus auf den mobilen Markt aber schnell wurde klar das es auf dem Desktop auch Hilfreich sein konnte.
Recht schnell kam dann auch jemand bei Red Hat darauf und skizzierte was wir bald Flatpak, ehemals xdg-app nennen sollten.
Alle dieser Lösungen haben Nachteile die man mit dem Paketsystemen hätte lösen können, aber auch hier gab es keine Bewegung in den letzten 5 Jahren bei den Distributionen.
Um es kurz zu machen. Snappy, Flatpak und AppImage erlauben es mit alte oder neue Anwendungen unabhängig der Distibution zu verwenden.
Zum Beispiel, ich nutze auf den meisten Servern ein Debian. Nun kommt der Ruf nach PHP 7.2 aus unterschiedlichen Gründen (Performance oder weil neue PHP Libs die Version voraussetzen). Debian 9 kommt aber nur mit php 7.0. Debian weigert sich ein aktuelles PHP bereitzustellen.
Also was soll ich nun tun? Selber compilieren? Wäre eine Möglichkeit aber ich müsste mir dann die ganze pflege ans Bein binden. Repositorys von Dritten? Das ist wieder so eine Vertrauensfrage, immerhin gebe ich einer fremden Person letztlich root Rechte.
Am liebsten wäre es, wenn ich die neue Version explizit von meiner Distribution bekommen würde. Oder gar vielleicht auch eine alte Version. Zum Beispiel habe ich noch eine alte PHP 5 Anwendung laufen. Diese laufen aber auch nicht auf Debian 9 sondern in einer Isolierten VM die eh nur im Intranet laufen muss.
Das nächste wäre wohl ein offizielles Snap, Flatpak oder AppImage.
Einer der Debian-PHP-Maintainer bietet fertige Pakete für PHP 7.2 (und PHP 5.6) für Debian 9 an. Da er auch für die "normalen" PHP-Pakete zuständig ist, sind diese quasi "trotzdem" perfekt in die Distribution integriert. Was will man mehr?
Das ist Klasse, gibt es auch eine Adresse wo ich die finde (Ich hatte zuletzt letzte Woche oberflächlich mal nach einer Quelle gesucht aber keine gefunden)? Das Löst zumindest eins meiner Probleme.
Die Grundlegende Kritik bleibt aber weiterhin bestehen. Es ist schade das es die PHP 7.2 und 5.6 Pakete nicht offiziell gib oder zumindest als Backport. PHP kannst du auch durch jede Beliebige andere Anwendung ersetzen. Zum Beispiel vor ein paar Jahren hatte das Handshake Projekt sich entschlossen divx/xvid Support zu streichen. In neuen Distributionen hatte man nun das Problem das die bekannte Anwendung nun einen Codec den man nutze nicht mehr anbot. Der User hat auch keine einfache Möglichkeit zu sagen ich nehme dann einfach die Alte Version und installiere sie parallel.
Die Installationsanleitungen finden man eigentlich an jeder Ecke:
-> "PHP 7.2" "Debian 9"
Bringt einen erst mal nicht weiter, denn das Thema vertrauen ist da. Meine Frage war zu den Paketen des Offiziellen Maintainers bei Debian.
Dein Link ist daher eher eine Beleidigung an jeden, denn so einfach ist es nun mal nicht.
Gehen wir mal anders vor. Du sagst der Maintainer hat ein repo. Also erst mal schauen wer das ist.
Ich schaue also mal direkt in das Paket selbst.
Das bringt mich nicht weiter denn da steht nur
Also schaue ich mal ins Debian Wiki https://wiki.debian.org/PHP
Wieder kein Name, aber es gibt einen Link zur Mailing Liste. https://alioth-lists-archive.debian.net/pipermail/pkg-php-maint/
Hilft einem aber auch nicht wirklich weiter.
Aber nun kommst du mit einem lmgtfy Link! Wenn du es nicht ernst meinst, dann lass es einfach.
EDIT: Du willst aber vermutlich auf Ondřej Surý hinaus. https://deb.sury.org/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Apr 2019 um 15:31.Es geht mir nicht darum, gegen Snap zu sein - ganz im Gegenteil. Es hat schon seine Berechtigung, wenn es um Software geht, die man aus einer anderen Quelle installiert und auch beim nächsten Distributionsupgrade noch laufen soll. Eben wie z.B. VS Code, wenn es nicht offiziell von der Distribution unterstützt wird.
VS Code ist vom Erfinder von Typescript und damit eine der besten freien Möglichkeiten, Typescript zu programmieren. Ich persönlich habe eine Erweiterung für Eclipse gekauft (von Genuitec), eine weitere Möglichkeit wäre Intellij gewesen. Aber VS Code funktioniert gut, wenn man nur Typescript programmieren möchte.
Aber hast du dir mal Docker angesehen? Gerade wenn du noch eine PHP5-Anwendung laufen hast und Debian wegen irgendwelchen Gründen auf eine alte Version festgenagelt ist.
Das gilt übrigens auch für Andre. Gerade zur Entwicklung.
Aber die Berechtigung sollte eigentlich nicht vorhanden sein. Es ist eine Notlösung wegen einer veralteten Distributionspolitik. Es spricht nichts dagegen das eine Distribution auch unterschiedliche Versionen verteilt, je nach dem Bedarf der Anwendung. Das man nur eine Version einer Bibliothek ausliefern will hat sich seit dem erledigt, seit die Bibliotheken auf Abwärtskompatibilität oft keinen Wert legen. Die Pflege von LTS Paketen im Upstream zu erledigen ist schon fast ein Sakrileg.
Darauf würde es wohl hinauslaufen, aber die Lösung mit der VM funktioniert und macht so keinen Aufwand. Sie ist auch nicht extern zu erreichen was einem da Druck heraus nimmt. Und da man auch nicht für eine neue Lösung noch Portierung bezahlen will, oder Zeit einräumt die Anwendung in einen Docker Container zu verschieben nicht bewilligt wird, wird das wohl noch einige Jahre so bleiben.
> Am liebsten wäre es, wenn ich die neue Version explizit von meiner Distribution bekommen würde.
Schau dir mal Fedora an bzw. das bald erhältliche RHEL/CentOS 8: Der Paketmanager unterstützt dort sogenannte Module bzw. Application Streams, was nichts anders bedeutet als das du pro Paket auswählen kannst welchen Versionszweig du benutzen willst. Du könntest deine PHP-Version dann einfach installieren:
dnf module enable php:7.2
dnf upgrade
Wie lange die einzelnen Versionszweige dann unterstützt werden weiß ich nicht - bei Fedora ist die Fragestellung egal, weil das sowieso keine LTS-Distro ist, bei RHEL glaube ich aber nicht dass die z.B jede einzelne PHP-Version 10 Jahre lang unterstützen, das wäre ja zu viel Arbeit. Wahrscheinlich wird es ähnlich wie bei den Software Collections aus RHEL 7 sein, dass jede Version nur ein paar Jahre unterstützt wird und man danach upgraden muss, oder man bleibt eben bei der Standard-Version.
Das geht schon in eine interessante Richtung. Ist das was Absolutes oder kann man unterschiedliche Versionen parallel installieren.
Mein Problem bei Fedora war bisher die noch größere Abhängigkeit von externen Paketen als bei Debian.
Parallel geht das mit den Modulen nicht, aber mit den Software Collections (in CentOS/RHEL, Fedora hat das nicht). Dann hast du aber keine Standard-Pfade mehr, sondern sowas wie /opt/php_72 oder so.
Wenn du mehrere Versionen parallel betreiben willst, dann sei dir aber sowieso zu Container-basierten Lösungen wie Docker geraten. Das ist heute der allgemein übliche Weg, und bietet darüber hinaus noch weitere Vorteile, wie z.B automatisches Deployment deiner Installation auf ein anderes System.
Du solltest deine Container aber natürlich warten und Sicherheitspatches installieren. Das wird leider oft vergessen, du hast dann im Prinzip mehrere ineinander geschachtelte Betriebssysteme im Einsatz, die alle Updates brauchen. Das Problem besteht bei Snap/Flatpak natürlich genauso.
Und hier kommen wir wieder in die üblichen Probleme der Eigenlösungen. Man bindet sich da einen gewaltigen Wust ans Bein.
Daher mein Wunsch nach einer offiziellen Lösung und eben wegen dem Problem der Pflege finde ich viele Container oder Snap/Flatpak Pakete so schlecht.
Debian hat halt keine neuen Versionen freigegeben, weil das niemand testet.
Das Problem ist, dass bestimmte Software auf andere angewiesen ist und andere wiederum eventuell nicht mehrfach installiert werden kann, ohne dass sie sich behindern.
Beispielsweise: Der Webserver ist normalerweise nur für eine PHP-Version benutzen. Natürlich geht es:
https://tecadmin.net/install-multiple-php-version-apache-ubuntu/
Aber auch in der anderen Richtung: Funktioniert das moderne PHP mit den alten Bibliotheken. Wie sieht es mit den Zusatzmodulen aus?
Ist deine Lösung also exotisch genug, dann wirst du nichts finden oder nur etwas, was nicht offiziell getestet ist.
Und um dieses Abhängigkeits-Problem zu minimieren, nutzen manche Leute halt Docker. Da baut man sich ein Script, was die Applikation lauffähig verpackt, die Daten kommen in einen eigenen Container oder ins Hostfilesystem und sofern es Updates gibt, wird die Anwendung halt neu gebaut.
Docker ist eine Mini-VM, die von außen nur über die Sever-Ports angesprochen wird (selbstverständlich alles konfigurabel). Die VM selbst ist minimalistisch und auf dem Host muss nur Docker laufen.
Ist auch zur Entwicklung praktisch.
Aber du kannst natürlich auch Pakte von einer vertrauenswürdigen Person nehmen. Nur bei exotischen Lösungen besteht auch immer die Gefahr, dass da dann Sicherheitpatches nicht so häufig und evtl. unvollständig kommen. Wenn dus selbst baust, brauchst du auch ein tiefes Verständnis.
Fazit: Wenns exotisch wird, dann verlässt du ausgetretene Pfade und bist auf die selbst angewiesen. Docker löst das beispielsweise, indem spezialisierte Pakete einzeln gewartet werden.
Die Probleme sind aber nicht neu. Seit über 20 Jahren hat man dieses Problem, aber man war in seiner eigenen Blase und alles war ok.
Das es keine Lösung gibt die von Heute auf Morgen da ist, sollte allen klar sein, aber man kann darauf hin arbeiten.
Ein Anfang wäre wenn die Bibliotheken aufhören würden ständig die API und ABI in Minorversionen umzubauen. Oder der Funktionsumfang im Build Prozess festgelegt wird, das teilt die möglichen Kombinationen an Versionen und mögliche Konfigurationen noch weiter auf. Nicht falsch verstehen, ich mag die Konfigurationsmöglichkeiten. Aber als Systemweite Bibliothek sollte es klar sein was man bekommt ganz gleich welche Distribution.
Und im Fall Debian müsste man nicht mal so viel ändern. Die können weiterhin ihr Ideal umsetzen, aber wenn es eine neue Releaseversion gibt die auf Wunsch auch bereitstellen. Bibliotheken die nicht abwärtskompatible sind kann man ja mit einem neuen .so Namen versehen oder es einen dispatcher erledigen lassen damit die korrekte Version geladen wird. Die alten Anwendungen kann man so auch noch weiter anbieten.
Aktuell laufen wir ja darauf hin das wir viele unterschiedliche Bibliotheksversionen und Konfigurationen der Bibliotheken im System haben werden, die aber eventuell nicht mal gepflegt werden.
Ich bekomme immerhin zur Zeit etwas Hoffnung bei dieser Nachricht von Heute. Debian diskutiert über ein Anwenderarchiv
Ich kenne Docker, aber mich stört das es keine offiziellen Images gibt und wieder dritte ihre Finger im Spiel haben die teils auch noch selbst an den Anwendungen werkeln.
Ein Problem hast du ja auch schon davon genannt, es ist aber letztlich ein Kompromiss und die Distributionen sollten sich Gedanken machen warum es dazu kam.
dann verrate doch mal exemplarisch bitte ganz kurz wie ich beispielsweise
* auf debian8 php7 mit db2 support als statisch kompiliertes packages in aktueller version bekomme.
* auf debian8 kdevelop v5 als statisch kompiliertes package in aktuellr version bekommme.
* auf debian10 xmms1 als statisch kompiliertes packages zur verfügung bekomme.
bitte jetzt keine ausflüchte wozu man das brauchen solle, oder das ich ein distupgrade fahren solle. es könnte schliesslich sein das ich ganz bewusst noch ein abgeschottetes debian8 weiter einsetzen möchte.
und da du so selbstverständlich davon redest das die jetzige lösung dafür offenbar garnicht notwendig sein und klassische paketverwaltung soviel besser sei - nun denn - bitte ich freuue mich dazu zu lernen.
meiner erfahrung nach arten alle 3 o.g. einsatzzenarien bei klassischer paketverwaltung praktisch zu einem gefrickel aus das man "bestenfalls" nur noch als erfahrener linux-anwender mit fortgeschrittener erfahrung gelöst bekommt.
Neueste PHP-Versionen baue ich mir immer selber, PHP ist ziemlich einfach selber zu builden, ausserdem ist dann genau das drinn was ich brauche.
Ausserdem gibts Containerimages von bitnami,... für neueste Versionen mit dem ganzen üblichen Gerümpel den man sonst noch braucht (DBs, CMS,...).
Snap finde ich in der Hinsicht gar nicht mal so schlecht, es bügelt die Nachteile der klassischen Paket und Grundproblem von Linux aus.
Bsp neuester Opera: Bei dem gehen keine h.264 Videos mehr weil die lib der Distro nicht mehr zu der Version von Opera passt, vorher gings noch. Dolle Wurst dieses libchaos. Ich verstehe nicht warum solche Problemfälle nicht generell statisch reinlinkt oder sowas überhaupt ohne Vorwarunung installierbar ist.
Weil du nach 5 iterationen alles statisch gelinkt hättest?
Es ist ja auch ein großes Plus für Linux. Snap & Co ergänzt das nur.
genau darauf wollte ich hinaus
und wenn man sich noch die ünnötige Grösse dieser Snap/Flatpack etc Container ansieht.....
Also ich halte den PM zum Teil für Mist und das schon fast seit einem Jahrzehnt. Snap, Flatpack halte ich aber auch für großen Mist. Zum Glück bieten viele Hersteller mittlerweile ihre Software auch für Linux an, wie auch bei Windows. Das landet bei mir dann im Application-Ordner und wird von dort ausgeführt. Auch wird Software teilweise dorthin kompiliert.
Zunächst dachte ich, mit dieser Idee bin ich ein Exot. Aber in Unternehmen die viel auf Linux setzen, verzichten sie auch auf PM. Ähnlich wie ich, wird die Software irgendwohin geparkt und von dort ausgeführt. Das hat den Vorteil, das die Distributionsversion egal wird. Egal ob LTS oder Rolling-Release. Man besitzt die gewünschte Software und gut ist.
Den PM nutze ich dann nur noch zum update der eigentlichen Distro, die Distributionseigene Software ist mir aber eigentlich egal.
Haha - Snap/Flatpak/Appimage ist selbstverständlich ein Eingeständnis der Tatsache, dass man es nicht (besser) kann. Klar. Es ist ein blutiger Kompromiss, den man genau deshalb geht, weil man meint verstanden zu haben, dass man eine gescheite Lösung halt einfach nicht hinbekommt. Kann der Mensch halt einfach nicht. Es wird zuviel gepfuscht, gewieselt, rauf, wieder runter, jetzt einmal seitlich die Abkürzung genommen; und bei der nächsten Iteration natürlich alles leicht variiert, damit sich auch keine Systematik bilden kann, die den Namen verdient hätte. Er merkt es auch selbst garnicht, und hält das derzeit alles für eine tolle moderne Gangart. Kritische Reflektion: Nööö, das nervt nur beim Netflixen...
Das führt dann zu solchen markabren Aprilscherzen, dass Debian jetzt RPM machen würde... Wäre ja eigentlich das Normalste von der Welt, dass es mal mittelfristig mal _ein_ Format gegeben hätte.
Jetzt hisst man halt die weisse Flagge und packt _alles_ in eine Zip-Datei, und schreibt am Ende "Snap" dran. Derbe doof. Nicht doof genug: Unsere "Lessons Learned" der letzten Jahre schreien ja auch nach Zentralisierung. Warum sollte jeder einfach Pakete anbieten... Cyberwar würde euch alle dahinraffen...
Aber MSI kann noch soviel mehr nicht, da kannst du dir (mutmaßlich) garkein Bild von machen. Der Vergleich ist ungerecht imho. Von MergeModules bis Bootstrapper (siehe Wix ; da sind die Installer dann EXE-Files - ist gerade der letzte Schrei im Windoofland) gibt es da noch soviel Ersatzkonstrukte... Und sie funktionieren _alle_ nicht (oder freundlicher: es sind alles seehr pragmatische Lösungen, die nicht von allzuviel Eleganz geplagt sind)...
Ja, ich habe in der Polemik wieder mal die Details schleifen lassen. Es ist keine Zip-Datei, sondern irgendein Squashfs-Kram (Overlay-FS nur zur Laufzeit für FS-Tricks, RW-Zugriff, usw). Sprich: Eine ZIP-Datei, für die du fast keine Tools findest.
Und es ist auch nicht ganz alles drin. Auf einen Kernsatz, den man nicht immer einpacken muss, konnte man sich vorher noch einigen, und hat ihn Runtime genannt... Immerhin... Also; auf einen Kernsatz für Gnome, einen anderen für KDE, ... *g*
Mal sehen, wie viele Wiesel-Tunnel noch kommen, bis alle Probleme gelöst sind (bspw. das Programm das System-Styling bekommen; ich kenne das zugegebenermaßen nur von Flatpaks, aber es ja ein konzeptbedingtes Problem).
sry: "(bspw. dass Programme nicht das System-Styling bekommen ..."