Debian diskutiert

Logo: Mohd Sohail Lizenz: CC BY 2.0

Auf der Debian-Entwickler-Mailing-Liste wird seit einigen Tagen in dem Thread What can Debian do to provide complex applications to its users? ausgiebig über ein Problem diskutiert, das im Kern die saubere Paketierung von komplexen Anwendungen in Debian betrifft, die meist aus dem Bereich Web-Applikationen stammen. Dabei geht es beispielsweise um Applikationen. die auf die Plattform Node.js und deren Repository NPM setzen. Es ist nicht das erste Mal, dass Debian diese Probleme diskutiert, die im Endeffekt auch die eigene Relevanz in der Zukunft der Linux-Distributionen betreffen.

Debian diskutiert neue Entwicklungsmodelle

Die Welt der Software-Entwicklung verändert sich seit Jahren rapide außerhalb des Debian-Ökosystems. Ein aktueller Trend in der Software-Entwicklung ist die Verwendung von Programmiersprachen, oft interpretierte Hochsprachen, kombiniert mit der intensiven Nutzung von Drittanbieter-Bibliotheken und einem sprachspezifischen Paketmanager für die Installation von Bibliotheken durch Entwickler und den Systemadministrator, der die Software für die Produktion installiert. Dadurch werden Linux-Distributionen zunehmend umgangen.

Nicht kompatibel

Debians Richtlinien kollidieren hier häufig mit der gebotenen Aktualität bei dieser Art von Anwendung. Sicherheit ist dabei ein wichtiges Thema. Es wird in dem Thread unter anderem zu Recht bemängelt, dass Quelltext und Copyright-Informationen der in Web-Applikationen häufig verwendeten unzähligen JavaScript-Bibliotheken von Upstream oft nicht angegeben oder gar unbekannt sind, was in Debian prinzipiell unakzeptabel ist. Darüber hinaus werden JavaScript-Bibliotheken als Abhängigkeiten in solchen Anwendungen häufig aktualisiert, während in Debian noch eine ältere Version der Bibliothek Standard ist und somit die Anwendung bricht.

Viele Upstream-Entwickler solch komplexer Anwendungen ziehen es zunehmend vor, wegen der als restriktiv angesehenen Richtlinien nicht mit Debian zusammenzuarbeiten. Dabei geht es oft um Anwendungen, die neben JavaScript auf PHP, Python, Ruby oder Golang setzen. Die kurzen Supportzeiträume dieser Frameworks und Sprachen passen nicht mit Debians Philosophie zusammen. Ein weiteres Problem ist die Minifizierung, die neben CSS besonders bei JavaScript angewendet wird, um eine beschleunigte Ausführung des Codes zu erreichen. Dies ist aber nicht konform mit Debians Social Contract und ergibt im Ergebnis unwartbaren Quellcode. Deshalb sehen auch Debians FTP-Master und das Technical Comitee minifizierten Code als für Debian unbrauchbar an.

Weiterhin spielt das Thema Vendoring eine Rolle. Vendoring ist die Erstellung einer eigenen Kopie von Bibliotheken, die ein Upstream- Projekt verwendet. Diese Kopien werden traditionell in jedem Projekt platziert und dann im Projekt-Repository gespeichert. Gibt es in einer der Original-Bibliotheken ein Sicherheitsproblem, so wird die »vendored version« oft nicht oder viel zu spät aktualisiert. Auch das entspricht nicht Debians Richtlinien.

Debian-Paket oder externe Anwendung?

Das Dilemma, vor dem die Entwickler und Anwender hier stehen ist nicht leicht zu lösen. Fällt die Wahl auf das Debian-Paket einer Anwendung (sofern eins existiert), so kann meist die gebotene Aktualität, die bei Web-Anwendungen besonders wichtig ist, nicht gewährleistet werden oder die Anwendung bricht bei der Aktualisierung.

Als Alternative kann der Anwender auf die Upstream-Version zurückgreifen, bei der es gleich mehrere Unbekannte gibt. Sie wird meist mit einem eigenen Installer wie Pip im Fall von Python oder NPM für das allgegenwärtige Node.js. Diese Installer schaufeln Code auf die Rechner, der in keiner Weise einer Verifizierung unterliegt, wie das für Debian-Repositories der Fall ist. Andererseits handhaben diese Installer oft Hunderte von Abhängigkeiten, die ein Debian-Maintainer zeitlich gar nicht bewältigen kann.

Container oder Flatpaks

Welche Lösungen gibt es für diese Problematik? Und ist Debian flexibel genug, um mögliche Lösungen umzusetzen? Das sind Fragen, die nicht nur im Thread selbst, sondern auch in den Blogs der beiden Debian-Urgesteine Lars Wirzenius und Joey Hess aufgegriffen werden. Ein diskutierter Lösungsansatz ist die Verwendung von Containern oder Flatpaks innerhalb der Debian-Infrastruktur für solche Anwendungen. Denkbar wäre auch ein Repository für solche Pakete, ähnlich denen für contrib und non-free. Hier müsste klar vermittelt werden, dass für solch ein Repository keine Sicherheitsunterstützung gewährleistet wird.

Vision für die Zukunft?

Eine andere Möglichkeit wäre, Pakete in mehreren Versionen zuzulassen wie das beispielweise für C-Bibliotheken,  GCC, Python und andere schon länger der Fall ist. Der Blick richtet sich zudem auf Distributionen wie NixOS, die nicht der traditionellen Verzeichnisstruktur des Filesystem Hierarchy Standard folgen. NixOS erlaubt mehrere Versionen einer Anwendung gleichzeitig, wobei jede Version der Anwendung ihre Dateien in einem eigenen Verzeichnis ablegt. Alle vorgebrachten Ideen drohen aber an der fehlenden Entwickler- und Betreuerzeit in Debian zu scheitern.

Das vorliegende Problem betrifft aber auch die Relevanz von Debian. So formuliert denn auch ein Entwickler:

I have the […] feeling Arch is taking away our desktop users, Ubuntu is taking away our cloud users, Alpine is taking away our container users and CoreOS/Atomic Host are taking away users interested by container orchestration solutions.Vincent Bernat

Freie Software weiter tragfähig?

Tritt man etwas weiter zurück, so sieht es auf längere Sicht für Linux-Distributionen in ihrer jetzigen Form insgesamt nicht rosig aus. Viele junge Entwickler scheren sich nicht mehr um Werte wie Lizenzen, lesbaren und dokumentierten Quellcode oder nachvollziehbare Copyright-Angaben. Wenn allerdings das Modell der Distributionen nicht mehr tragfähig ist, worauf wollen Entwickler freier Software dann ihre Anwendungen laufen lassen?

Das Problem ist nicht neu, Lennart Poettering hat sich bereits vor Jahren über die Art, wie wir künftig Distributionen bauen Gedanken gemacht. Die Ideen dazu werden bereits seit Längerem erprobt, haben sich aber bisher nicht auf breiter Front durchgesetzt.

Beitrag kommentieren

Alle Kommentare
  • tuxnix

    22.02.2018, 16:55 Uhr

    I have the […] feeling……
    Manjaro ist gegenwärtig der Hit bei den Desktop Usern, aber Debian dürfte hier mit seinem stabilem Grundsystem + Flatpak keineswegs schlechter aufgestellt sein.
    Wollte der Vorsitzende nicht mal die Debian Wiki rund erneuern?
    Hier wäre gegenüber Ubuntu und Mint viel Boden zu gewinnen.

    Was die Cloud betrifft, so ist dies doch eher eine kommerzielle Veranstaltung und dadurch ohnehin nicht ganz auf der Debians Linie.

  • tuxnix

    22.02.2018, 17:06 Uhr

    P.S.: Es gibt ein Gerücht, dass ich hiermit in die Welt setze.
    KDEneon wird in Zukunft auf Debian (sid) aufsetzen!
    Die Zusammenarbeit mit Purism (Pure Os) und das Librem 5 Smartphone, verlangt, dass auch das neueste Plasma und Plasma mobile auf Debian läuft.

    • Ferdinand Thommes

      22.02.2018, 17:54 Uhr

      Das würde absolut Sinn machen. Ubuntu passt da sowieo nicht drunter. Zudem hatte es mich sowieso gewundert, dass Jonathan Riddell sich für Ubuntu als Unterbau entschieden hatte, nadem, wie Shuttleworth mit ihm umgegangen war in Sachen Kubuntu. Ich weiß nicht, ob ich soviel Pragmatismus aufgebracht hätte.

  • Ferdinand Thommes

    22.02.2018, 23:38 Uhr

    Kaum redet man mal schlecht von npm, schon isses kaputt – aber mal richtig kaputt.
    https://www.bleepingcomputer.com/news/linux/botched-npm-update-crashes-linux-systems-forces-users-to-reinstall/

  • chris_blues

    23.02.2018, 18:43 Uhr

    Wow! Da hat ja NPM mal ein schlagkräftiges Argument *für* die „altmodische“ Paketierung gemacht! Ich würde mir auch nicht unbedingt einen weiteren Paketmanager auf die Platte holen…