Warum müssen verschiedene Linux-Distributionen Pakete patchen?

Es hat ein paar Versuche gedauert, aber ich glaube, ich verstehe jetzt, was Sie fragen.

Es gibt mehrere mögliche Gründe für eine Verteilung, bestimmte Software vor dem Packen zu patchen. Ich werde versuchen, eine nicht exklusive Liste zu geben; Ich bin sicher, es gibt noch andere mögliche Gründe.

Für die Zwecke dieser Diskussion bezieht sich „Upstream“ auf den ursprünglichen Quellcode von den offiziellen Entwicklern der Software

1. Patches, die Upstream aus welchen Gründen auch immer nicht (oder noch nicht) in ihren Hauptzweig integriert hat. Normalerweise, weil der Paketbetreuer der Distribution für dieses Paket glaubt, dass diese Patches lohnenswert sind, oder weil sie benötigt werden, um die Kontinuität in der Distribution aufrechtzuerhalten (Angenommen, Sie haben einen Webserver und nach einem routinemäßigen Update auf php mehrere Funktionen, auf die Sie sich verlassen haben, funktionieren nicht mehr oder es ist nicht in der Lage, eine Konfigurationsdatei im alten Stil zu lesen)

2. Distributionen neigen dazu, standardisierte Muster für ihre Dateisystemhierarchie in /etc/ zu mögen; Jeder Softwareentwickler kann seine eigenen Vorstellungen davon haben, was angemessene Standards sind. Daher ist eines der ersten Dinge, die ein Verwalter von Distributionspaketen zu tun pflegt, die Build-Skripte zu patchen, um die Konfigurationsdateien in einem Hierarchiemuster zu konfigurieren und zu erwarten, das dem Rest der Distribution entspricht.

3. Um beim Thema Konfiguration fortzufahren, einer der ersten "Patches" ist in der Regel eine Reihe von Standard-Konfigurationsdateien, die sozusagen "out of the box" mit dem Rest der Distribution zusammenarbeiten, sodass der Endbenutzer sofort loslegen kann nach der Installation, anstatt eine funktionierende Konfiguration manuell sortieren zu müssen.

Das geht mir gerade aus dem Kopf. Es mag sehr wohl andere geben, aber ich hoffe, das gibt Ihnen eine Vorstellung.

Aus dem Kopf, zusätzlich zu @Shadurs Antwort:

• Einige Distributionen raten davon ab, eingebettete Bibliotheken oder Dateien zu verwenden, die von einem anderen Paket bereitgestellt werden. Zum Beispiel enthält viel Software eingebettetes JQuery, aber Debian hat ein libjs-jquery-Paket, das es bereitstellt.
• Oft mischen Upstream-Sicherheitspatches und rückwärtsinkompatible Änderungen, z. hängt von neueren Bibliotheken ab. Um umfangreiche Änderungen an der gesamten Distribution zu verhindern, nur um eine, sagen wir, korrektere Zertifikatsprüfung zu erhalten, kann sich der Paketbetreuer dafür entscheiden, nur die Sicherheitspatches auszuwählen.
• Upstream-Software kann Konflikte mit anderer Software verursachen, sie könnten beispielsweise eine Datei mit demselben Pfad, aber unterschiedlichem Inhalt bereitstellen. Um diesen Konflikt zu lösen, ist möglicherweise ein Patch erforderlich, um die Datei woanders zu suchen.
• Upstream begnügt sich oft mit Anweisungen, manuell etwas zu einer anderen Software-Konfigurationsdatei hinzuzufügen, was beim Installieren und Deinstallieren von Paketen fehleranfällig ist, sodass die Distribution es vorziehen könnte, Fragmentdateien in einem *.d-Verzeichnis zu verwenden.
• Einige Teile der Originalautoren könnten mit der Lizenz der Distribution inkompatibel sein, sodass der Paketbetreuer entscheiden könnte, die problematischen Teile zu entfernen.
• Upstream verwendet Pfade mit der Annahme einer bestimmten anderen Software (z. B. Apache), aber der Betreuer möchte, dass sie einen generischen Webserver unterstützt.
• Manchmal kommuniziert der Upstream-Entwickler nicht mehr und die Software versagt, sodass ein Patch erforderlich ist, damit sie weiter funktioniert.

Dafür gibt es mehrere Gründe:

1. Es gibt keine perfekte Software

2. Es gibt keine universelle Paketierungssoftware unter Linux:

   • passend
   • lecker
   • pacman
   • ...

3. Wegen Gabelung

4. Wegen unterschiedlicher Interpretationen der Bibel FHS
5. Wegen Ego