Warum ist es so schwierig, aktualisierte Endbenutzersoftware in den offiziellen Repositories zu finden? [geschlossen]

Nein, dies ist kein Dup von /ubuntu/151283/why-dont-the-ubuntu-repositories-have-the-latest-versions-of-software.

Meine Frage bezieht sich hier nur auf Endbenutzersoftware. Ich verstehe das Stabilitätsargument in Bezug auf Low-End-Pakete und andere Dinge vollkommen, aber warum müssen alle paar Tage viele Pakete aktualisiert werden, aber keines davon betrifft meine allgemeinen Anwendungen?

Dies führt uns zu der Absurdität, dass viele Entwickler uns vorschlagen, die offiziellen Repositories einfach nicht zu verwenden, weil sie veraltet sind. Stellen Sie sich auf Ihren Sofas eine mobile Welt vor, in der Sie Ihre APKs / IPAs von überall im Web herunterladen müssten, da der Google Play / App Store nur eine einjährige Version enthält.

Das passiert unter Ubuntu. Die Magie einer einfach zu bedienenden Art der Installation von Software ist völlig durcheinander, weil das Zeug zu alt ist.

Beispiel: Ich habe gerade Ubuntu 16.04 auf meinem Computer und die Calibre-Version ist fast 5 Monate alt - 2.55 ist im Repo, während 2.66 bereits verfügbar ist.

Wenn es den ursprünglichen Entwicklern nicht darum geht, eine PPA zu verwalten, bleiben uns die alten Schulzeiten des Zugriffs auf Download-Sites, des Abrufs von Tarballs oder Debs und der manuellen Installation von Inhalten. Ubuntu war früher cool, aber jetzt ist es in dieser Hinsicht älter als Windows.

Ist der menschliche Faktor hier die einzige Antwort? Ubuntu-Betreuer haben mehr zu tun, als mit allen Software-Releases zwischen Ubuntu-Versionen Schritt zu halten ? Warum ist es für Softwareentwickler nicht einfacher / möglich, ihre eigene Software in den Ubuntu-Repositorys zu aktualisieren?

Warum ist es für Softwareentwickler nicht einfacher / möglich, ihre eigene Software in den Ubuntu-Repositorys zu aktualisieren?

Softwareentwickler aktualisieren ihre Software regelmäßig. Deshalb haben Sie eine neue Calibre-Version gefunden. Sie übertragen ihre Updates jedoch nicht direkt in das Ubuntu-Repository. Die Gründe sind bereits in den Antworten angegeben, die Sie mit Ihrer Frage verknüpft haben.

Sie können nicht immer auch PPAs bereitstellen, da dies eine zusätzliche Belastung für sie darstellen würde. Sie müssten dann Pakete für mehrere Distributionen bereitstellen. Und vergessen Sie nicht, dass es für jede Distribution mehrere Non-EOL-Releases gibt! Wenn sie ein Paket für Ubuntu bereitstellen möchten, müssen sie eines für 16.04, 14.04 und wahrscheinlich 12.04 erstellen. Dann beschweren sich Fedora, Debian und Arch Users! Das ist nicht einfach! Aus diesem Grund werden PPAs normalerweise von Drittanbietern bereitgestellt.

Es gibt jedoch einen anderen alternativen Ansatz, um Endbenutzern, die sich heutzutage entwickeln, die neueste Software bereitzustellen. Es packt jede Komponente einer Anwendung in eine einzige Datei. Sie werden meist in einer isolierten Umgebung wie in einem Container ausgeführt und müssen nicht mit den aktuell im System installierten Bibliotheken kompatibel sein. Beispielsweise können Sie die Anwendung gtk-3.20 in Xenial ausführen, die hauptsächlich aus 3.18-Komponenten besteht.

Aber sie haben auch ihre Probleme! (Siehe Fußnoten)

Einige der Ansätze sind:

• AppImages
• FlatPak von Gnome
• Snap von Ubuntu

Ubuntu-Betreuer haben mehr zu tun, als mit allen Software-Releases zwischen Ubuntu-Versionen Schritt zu halten?

Ubuntu-Betreuer bemühen sich, die Meilensteine ​​für jede Version zu erreichen. Um Ubuntu stabil zu halten, müssen sie sicherstellen, dass jedes Paket wie erwartet funktioniert. So wurde zum Beispiel vor kurzem eine Frage hier gefragt über die neuesten KDEConnect 1.0 in Ubuntu 16.04 zu bekommen. Aber es zeigte sich, dass kdeconnect1.0 Qt 5.6 erfordert. Um ihnen Qt 5.6 zu geben, müssen sie sicherstellen, dass andere Pakete im offiziellen Repository gut damit funktionieren. Das bedeutet, alle KDE-Pakete neu zu erstellen und erneut zu testen, was wirklich eine große Aufgabe ist.

Wenn Sie die neueste, modernste Software benötigen, können Sie versuchen, Rolling-Release-Distributionen oder den anderen Einzelpaket-Ansatz zu verwenden, der weiter oben in der Frage erwähnt wurde.

Einige Probleme mit Single File Packaging:

1. Sie sind normalerweise größer (weil sie alles Notwendige verpacken)

2. Durch die Installation wird Ihr System größer, da in Ihrem System mehrere Kopien derselben Bibliotheken vorhanden sind, die von jedem Paket verwendet werden.

3. Bei diesem Verpackungsformat müssen die Paketbetreuer die Integration mit den Bibliotheken selbst testen. Dies ist eine zusätzliche Belastung für sie. Mit apt, yumAnsatz, werden sie nur mit der Kern-Anwendung gestört. Sie könnten einfach annehmen, dass lib-gtk-xy-1.5 in der Distribution verfügbar ist.

4. Aus den gleichen Gründen werden Paketbetreuer nun wieder mit Fehlerberichten zu Bibliotheken belästigt, die in ihrem Paket enthalten sind. Im traditionellen Ansatz war dies die Aufgabe der Betreuer dieses spezifischen lib-Pakets.