Wo soll da ein Problem sein

[schnedan]

libHell? kenne ich auf den Rolling Release distris nicht! Archlinux & Sabyon laufen wie Uhrwerke.
mal gibt es Programme die mit veralteten Libs arbeiten und nicht kompatibel sind, aber das ist selten und wird irgendwann behoben (könnte sicher schneller behoben werden).

Da macht es mehr Sinn C++ einen multilib mechanismus ein zu bauen wie ihn C# hat.
Da kann eine Exe für mehrere Subkomponenten mehrmals die gleiche Lib in unterschiedlichen Versionen laden!

[Theoretiker]

Das Problem sind wohl die Bibliotheken, die nicht sauber ihre Versionen verwalten. Gerade unter Ruby ist das häufig so, dass die mit einem Bugfix-Release die API kaputtmachen. Und dann geht man RVM und Bundler halt hin und kompiliert sich eine bestimmte Ruby-Version und kopiert alle Gems in einer bestimmten Version.

Auch unter Fedora mit RPM habe ich bisher nichts von wirklich schlimmen Problemen mitbekommen. Ich glaube, das hier versucht ein Problem der instabilen APIs in Bibliotheken zu lösen, aber nicht an der richtigen Stelle.

[MingaMinga]

Die Probleme beim RPM sehe ich auch nicht.

Die Zuverlässigkeit wird zukünfitg leiden. Wenn ich heute unter Fedora ein Problem habe, kann ich mit einer Fehlerbeschreibung unter bugzilla.redhat.com hinterlegen. Da können wir über einen definierten Softwarestand und keine Versionschaos reden.

Dann gibt es zu einer Version ein RPM Update mit korrektur-eintragungen und jeder kann nachvollziehen.

Was die bei Fedora jetzt abziehen ist aus QM Sicht Scheisse!
Warum liefere ich in bugzilla immer fleissig Fehlermeldungen ab?

[Theoretiker]

Fedora hat schon die Politik, dass Probleme möglichst Upstream gelöst werden sollen. Das finde ich auch gut, es bringt wenig, wenn die Distribution die Fehler in der Software behebt und Upstream da nichts von erfährt. Schließlich haben dann alle Distributionen was davon und man hat deutlich weniger Arbeit. Außerdem können Fehler dann direkt an Upstream weitergegeben werden und es ist auch deren Software, die dann bei den Nutzern läuft.

Die Hoffnung bei Flatpak ist ja auch, dass dieser »definierte Softwarestand« dann im Flatpak mitgeliefert wird oder zumindest eine feste »Runtime« genutzt wird. Somit ist es in der Theorie dann vielleicht sogar besser als jetzt, wo man durch zusätzliche Paketquellen sein System auch ein einen anderen Zustand bringen kann, als die meisten anderen Nutzer das haben.

Wenn man es so einrichtet, dass man eine Bibliothek in der Version X.?.? und Y.?.? parallel installieren kann, sollte das reichen. Wenn eine Programm exakt X.1.2 und ein anderes X.1.3 braucht, so ist das ein Problem der Bibliothek. Die sollen dann eben Version Y.0.0 rausbringen, wenn sie die API brechen, und die kann dann wieder parallel installiert werden.

Mal schauen, wie es so wird.