Traurig, dass so etwas nicht seitens der Distributionen automatisch nach upstream wandert.
Wer sagt denn, das dies nicht passiert ist? Es muss natürlich auch Upstream jemand da sein, der Patches dann in den Hauptzweig aufnimmt und regelmäßig neue Releases herausgibt. Vielleicht ist es ja genau daran gescheitert?
bzip2 wäre damit schon mal aus der Distribution draußen, wenn das seit über einer Dekade keine Updates mehr bekam.
Und das wäre ja auch korrekt, denn wie du selbst oben beklagst: Es ist im Grunde genommen nicht Aufgabe der Distributionen, eigene Patches für Pakete zu entwickeln und zu pflegen (außer in Spezialfällen wie z.B. selbst gepflegter LTS Kernel mit Backports). Da hat am Ende jeder weniger davon, als wenn es einen ordentlichen Upstream Support gibt.
Klar muss man im Einzelfall schauen, ob ein Paket möglicherweise eine so große Bedeutung hat, das man es bereitstellen muss, um keine Probleme bei den Usern zu verursachen. Aber wenn in einem Paket über Jahre Upstream nicht mal Sicherheitslücken gefixt werden, sollte man es im Zweifel rauswerfen, das sehe ich auch so. Rauswerfen kann auch heißen "durch eine funktionsgleiche oder -ähnliche Alternative ersetzen". Oder halt einen Fork veranlassen.
Was nicht sinnvoll ist: Upstream rührt sich jahrelang nicht, aber drei Dutzend Paketbetreuer bei drei Dutzend Distributionen patchen sich drei Dutzende eigene Versionen ihres Pakets zurecht, nur damit es irgendwie läuft. Das wäre dann echt pure Ineffizienz, dann lieber ein Fork.
Rauswerfen macht nur Sinn, wenn das Paket ohnehin nicht mehr sinnvoll genutzt werden kann, wenn das Paket gleichwertig ersetzt werden kann oder es gravierende Sicherheitslücken aufweist welche nicht mit vertretbarem Aufwand behoben werden können.
Die Pflege verwaister Pakete innerhalb der Distributionen macht durchaus Sinn und ist am Ende auch nichts anderes als eine andere Art von Fork. Zudem ist es keineswegs so, dass die einzelnen Distributionen dabei nicht voneinander abschauen.
Traurig, dass so etwas nicht seitens der Distributionen automatisch nach upstream wandert.
Wer sagt denn, das dies nicht passiert ist? Es muss natürlich auch Upstream jemand da sein, der Patches dann in den Hauptzweig aufnimmt und regelmäßig neue Releases herausgibt. Vielleicht ist es ja genau daran gescheitert?
Ganz eindeutig ist es nicht formuliert, aber einem Eintrag des im Artikel verlinkten Blogs des Entwicklers kann man entnehmen:
[...] Bzip2 has not had a release since 2010. In the meantime, Linux distros have accumulated a number of bug/security fixes for it. Seemingly every distributor of bzip2 patches its build system. [...] There is no source control repository, nor bug tracker. [...]
Ich verstehe das so, als ob bzip2 Upstream nicht gepflegt worden wäre und die Distributoren den Weg des geringsten Widerstands gegangen wären. Daher denke ich, dass die Distributoren hier nicht primär die Verantwortung jener Missstände tragen.
Von Verfluchtnochmal-05995bd7b am Fr, 28. Juni 2019 um 15:19 #
Im Grunde ist es GENAU die Aufgabe von Distributionen dafür zu sorgen dass Dependencies im Zuge von Updates weiter durch den Compiler laufen und wenn es leicht geht auch korrekte Binaries raus kommen
Es wäre wünnschenswert downstram sowenig Patches wie möglich zu haben, aber die Definiton einer Distribution ist es eben dafür zu sorgen dass alles aufeinander abgestimmt ist und so weit möglich auch out-of-the-box funktioniert und Sicherheitsupdates bekommt
Es muss natürlich auch Upstream jemand da sein, der Patches dann in den Hauptzweig aufnimmt und regelmäßig neue Releases herausgibt. Vielleicht ist es ja genau daran gescheitert?Und das wäre ja auch korrekt, denn wie du selbst oben beklagst: Es ist im Grunde genommen nicht Aufgabe der Distributionen, eigene Patches für Pakete zu entwickeln und zu pflegen (außer in Spezialfällen wie z.B. selbst gepflegter LTS Kernel mit Backports). Da hat am Ende jeder weniger davon, als wenn es einen ordentlichen Upstream Support gibt.
Das ist total dumm pakete rauszuschmeissen die kein update bekommen haben, das muss doch von fall zu fall geschaut werden.
Klar muss man im Einzelfall schauen, ob ein Paket möglicherweise eine so große Bedeutung hat, das man es bereitstellen muss, um keine Probleme bei den Usern zu verursachen.
Aber wenn in einem Paket über Jahre Upstream nicht mal Sicherheitslücken gefixt werden, sollte man es im Zweifel rauswerfen, das sehe ich auch so. Rauswerfen kann auch heißen "durch eine funktionsgleiche oder -ähnliche Alternative ersetzen".
Oder halt einen Fork veranlassen.
Was nicht sinnvoll ist: Upstream rührt sich jahrelang nicht, aber drei Dutzend Paketbetreuer bei drei Dutzend Distributionen patchen sich drei Dutzende eigene Versionen ihres Pakets zurecht, nur damit es irgendwie läuft. Das wäre dann echt pure Ineffizienz, dann lieber ein Fork.
Rauswerfen macht nur Sinn, wenn das Paket ohnehin nicht mehr sinnvoll genutzt werden kann, wenn das Paket gleichwertig ersetzt werden kann oder es gravierende Sicherheitslücken aufweist welche nicht mit vertretbarem Aufwand behoben werden können.
Die Pflege verwaister Pakete innerhalb der Distributionen macht durchaus Sinn und ist am Ende auch nichts anderes als eine andere Art von Fork. Zudem ist es keineswegs so, dass die einzelnen Distributionen dabei nicht voneinander abschauen.
Im Grunde ist es GENAU die Aufgabe von Distributionen dafür zu sorgen dass Dependencies im Zuge von Updates weiter durch den Compiler laufen und wenn es leicht geht auch korrekte Binaries raus kommen
Es wäre wünnschenswert downstram sowenig Patches wie möglich zu haben, aber die Definiton einer Distribution ist es eben dafür zu sorgen dass alles aufeinander abgestimmt ist und so weit möglich auch out-of-the-box funktioniert und Sicherheitsupdates bekommt