Ich habe schon lange über das Thema Distributionen und Paketmanager nachgedacht, vor allem ausgelöst durch cargo für Rust. (Und es gibt keine neuen Gedanken, irgendwer hat alles vorher schon einmal gedacht, man muss es nur finden.) Bei LWN gab es bereits 2017 eine Diskussion »Package managers all the way down« zu dem Thema, die sehr gut die verschiedenen Fragen betrachtet.

• zwei unterschiedliche Standpunkte mit unterschiedlichen Zielen:
  • Distributionen blicken vom Standpunkt des Anwenders auf Software und wollen ein einheitliches System liefern. Integrierende Wirkung
  • Paketmanager blicken vom Standpunkt des Programmierers aus und wollen die Software verteilen.
  • Paketmanager wollen auf verschiedene Systeme (Windows, Linux, Intel, Arm), Distributionen schaffen das System und definieren es.
• Software-Verteiler gibt es schon lange (CTAN, CPAN) und damit haben sich Distributionen schon immer schwer getan; TeXLive-Integration in Debian.
• Paketmanager stecken im Emacs (ELPA, MELPA), Firefox (Add-ons)
• Distributionen haben viel die Probleme gelöst, die durch die Form von C entstanden sind. Cargo bringt viele Werkzeuge mit, sodass der Entwickler auch die Probleme lösen kann; Test für bessere Integration, Metadaten für Abhängigkeiten, strukturierte Softwarebeschreibung mit Lizenz und Bugtracker. Daher hadern so viele Distributionen mit Paketmanagern, weil sich die Zuständigkeiten überschneiden. Das Abhängigkeitsproblem in Bezug auf widersprüchliche Versionen löst Rust zum Beispiel besser als C.
• Die technischen Bedingungen bieten heutzutage die Möglichkeit einer globalen Optimierung (LTO; link time optimization). Der Code ist über die Jahre hin immer vielfältiger (i18n, l10n) und komplexer geworden, aber gleichzeitig kann der Compiler ihn besser analysieren und optimieren. Rust bietet ganz andere Möglichkeiten der Optimierung (z. B. Inlining über Bibliotheksgrenzen hinweg) als C.
• Stabilität/Sicherheit wird jetzt durch Tests, virtuelle Umgebungen, SELinux und andere Techniken gesichert, weshalb ein höherer Entwicklungstakt und eine buntere Mischung möglich ist. Die Frage von Sicherheitsupdates wird zurückgedrängt.
• Große Frage: Sind Shared Libraries noch zeitgemäß? Einerseits die DLL-Hölle von Windows, die aber mit Rust technisch besser gelöst ist, andererseits ist durch den hohen Entwicklungstakt die Software nicht mehr so homogen und für den Endanwender ist es leicht, die Software komplett neu zu bauen.
• Welches Problem lösen Shared Libraries? RAM und Festplattenplatz (Alternative: Deduplizierende Dateisysteme), zentrale Stelle zur Fehlerbehebung
• Es braucht ein Werkzeug, um Bugs (Sicherheitsprobleme) innerhalb von Binaries zu identifizieren: a) in welche Programmen verweisen auf den betroffenen Code, b) ist der betroffene Code überhaupt in Verwendung (wegoptimiert)
• Distributionen bieten Kontrolle des Codes, aber Review kann man heute leichter kollektiv gestalten; Idee: Veröffentlichung einer neuen Version bei Cargo und Bewerter geben ihre Meinung dazu ab. So wie man heute seiner Distribution vertraut, könnte man mehreren Bewertern vertrauen und diese kontrollieren den Code – Web of Trust.
• Als zweite Spezialform gibt es das App-Store-Konzept, bei dem kein Quellcode, sondern Binaries verteilt werden.
• Funktion von Distribution:
  • Kontrolle/Review: könnte per Web anders gelöst werden
  • Integration: wurde zum Entwickler verschoben, bessere Werkzeuge (cargo, Tests) und bessere Strukturierung, Bugtracker beim Entwickler (github ggü. tgz per ftp)
• Die große Zeit der Linux-Distributionen ist vorbei. Es wird in Zukunft noch einen Kern (Kernel + Grundsoftware) geben und darüber hinaus wird alles über Software-Verteiler laufen. Die viele Integrations- und Anpassungsarbeit, die Distributionen leisten, wird zum Entwickler verschoben. Für vieles wird es noch eine Standardisierung der Schnittstellen geben, sodass Werkzeuge entwickelt werden können (API zum Bugmelden).
• Idee: cargo-reportbug schaut in den Metadaten des Pakets nach, welcher Bugtracker angegeben ist und erhebt anhand einer Vorlage (.github/ISSUE_TEMPLATE) die notwendigen Daten und macht einen Eintrag im Bugtracker. Somit könnte jeder Entwickler seinen eigenen Bugtracker betreiben und gleichzeitig können alle Nutzer die Bugtracker aus einer einheitlichen Software heraus bedienen.
• Packaging Kubernetes (mit massenhaft Abhängigkeiten) for Debian