Es hängt von der Distribution und der ursprünglichen ('upstream') Quelle ab.
Bei den meisten Paketen, die Autoconf und Automake verwenden, ist es möglich, das Verzeichnis anzugeben, in dem nach den Konfigurationsdateien gesucht wird, indem der --sysconfdir verwendet wird Parameter. Andere Build-Systeme (z. B. CMake) haben ähnliche Optionen. Wenn das Quellpaket eines dieser Build-Systeme verwendet, kann der Paketierer problemlos die richtigen Parameter angeben, und es sind keine Patches erforderlich. Selbst wenn dies nicht der Fall ist (z. B. weil die Upstream-Quelle ein selbst entwickeltes Build-System verwendet), ist es oft immer noch möglich, eine Build-Konfiguration anzugeben, um die Konfigurationsdateien an einen bestimmten Ort zu verschieben, ohne die Upstream-Quelle patchen zu müssen.
Wenn dies nicht der Fall ist, muss die Distribution oft tatsächlich Patches zur Quelle hinzufügen, damit sie Dateien an den Ort verschiebt, den sie für den "richtigen" Ort halten. In den meisten Fällen schreiben Distributionspaketierer dann einen Patch, der es ermöglicht, die Quelle im obigen Sinne zu konfigurieren, sodass sie den Patch an die Upstream-Betreuer senden können und ihn nicht ständig warten/aktualisieren müssen. Dies gilt für Speicherorte von Konfigurationsdateien, aber auch für andere Dinge wie bin /sbin ausführbare Dateien (die Interpretation dessen, was ein Befehl eines Systemadministrators ist, unterscheidet sich zwischen den Distributionen), Ort, an dem die Dokumentation geschrieben werden soll, und so weiter.
Nebenbemerkung:Wenn Sie freie Software pflegen, bitte machen es Verpackern leicht, mit Ihnen zu sprechen. Sonst müssen wir solche Patches ohne besonders triftigen Grund pflegen...
Sie haben Patches auf den Quellcodebaum angewendet, die die Speicherorte anpassen.
Es sind genügend "Standards" verfügbar, die jede Distribution basierend auf (persönlichen) Vorlieben und/oder historischen Praktiken auswählen kann. Es gibt selten eine Lösung, die nur hat Vorteile. Das ist manchmal ärgerlich/verwirrend, aber Konsistenz innerhalb einer Distribution ist das wichtigste Ziel:Es führt zu weniger Unordnung und einfacherem Erraten, wo Dinge für Programm Y sein könnten, wenn Sie bereits wissen, wo ähnliche Dinge (z. B. Setup-/Konfigurationsdateien) für Programm sind X.
Beispiel für Patch-Anwendung
Mein Python-Paket ruamel.yaml ist in Debian Sid verfügbar. Früher war es abhängig von ruamel.base , und Benutzer, die über PyPI installiert haben, haben möglicherweise immer noch ältere, inkompatible Versionen von ruamel.base Eingerichtet. Mit setup.py /PyPI ist keine echte Paketverwaltung, Sie können also nicht löschen ein zuvor über Abhängigkeiten installiertes Paket. Ich habe das Problem für PyPI-Benutzer gelöst, indem ich eine neuere Version von ruamel.base erstellt habe Dadurch wurden die mit älteren ruamel.base verbundenen Probleme behoben Pakete und machte ruamel.yaml abhängig von dieser neueren Version.
Für Sid ist das kein Problem:ältere Versionen von ruamel.base wurden nicht installiert (oder konnten über die Paketverwaltung entfernt werden). Daher wenden sie einen Patch an, den Sie auf der ruamel.yaml finden Informationsseite für Sid, die die Abhängigkeit von ruamel.yaml entfernt auf ruamel.base .
Andere Distributionen haben ähnliche Einstellungen. Z.B. Wenn Sie sich die Spezifikationen zum Erstellen einer Quell-RPM-Datei (z. B. für RedHat/CentOS/SuSE) ansehen, werden Sie sehen, dass Sie den ursprünglichen Original-Tarball eines Pakets mit einem oder mehreren Patches kombinieren, die vor dem Konfigurieren/Kompilieren angewendet werden.