Viele Linux-Programme geben an, dass der Speicherort der Konfigurationsdatei(en) von der Distribution abhängig ist. Ich habe mich gefragt, wie die verschiedenen Distributionen das machen. Ändern sie tatsächlich den Quellcode? Gibt es Build-Parameter, die diese Speicherorte festlegen? Ich habe danach gesucht, kann aber keine Informationen finden. Ich weiß, dass es sie gibt, aber ich kann sie einfach nicht finden. Was ist in dieser Hinsicht der „Linux-Weg“?
Antwort1
Dies hängt von der Verteilung und der ursprünglichen („Upstream-“)Quelle ab.
Bei den meisten Paketen, die autoconf und automake verwenden, ist es möglich, mit dem --sysconfdirParameter das Verzeichnis anzugeben, in dem nach den Konfigurationsdateien gesucht wird. 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 dennoch möglich, eine Build-Konfiguration anzugeben, um die Konfigurationsdateien an einen bestimmten Ort zu verschieben, ohne die Upstream-Quelle patchen zu müssen.
Wenn das nicht der Fall ist, muss die Distribution oft tatsächlich Patches zur Quelle hinzufügen, damit die Dateien an den ihrer Ansicht nach „richtigen“ Ort verschoben werden. In den meisten Fällen schreiben die Paketierer der Distribution dann einen Patch, mit dem die Quelle im oben genannten Sinne konfiguriert werden kann, 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 die bin/ sbin-ausführbaren Dateien (die Interpretation eines Systemadministratorbefehls ist bei den Distributionen unterschiedlich), Speicherorte, an denen Dokumentation geschrieben wird usw.
Randbemerkung: Wenn Sie kostenlose Software pflegen,BitteMachen Sie es Paketierern leicht, mit Ihnen zu kommunizieren. Andernfalls müssen wir solche Patches ohne besonders guten Grund pflegen ...
Antwort2
Sie haben Patches auf den Quellcodebaum angewendet, die die Standorte anpassen.
Es gibt genügend „Standards“, sodass jede Distribution ihre eigene Auswahl basierend auf (persönlichen) Vorlieben und/oder historischen Praktiken treffen kann. Es gibt selten eine Lösung, dienurhat Vorteile. Das ist manchmal ärgerlich/verwirrend, aber Konsistenz innerhalb einer Distribution ist das wichtigste Ziel: Es führt zu weniger Unordnung und es ist einfacher zu erraten, wo Dinge für Programm Y sein könnten, wenn Sie bereits wissen, wo ähnliche Dinge (Setup-/Konfigurationsdateien z. B.) für Programm X sind.
Beispiel für die Patchanwendung
Mein Python-Paket ruamel.yamlist in Debian Sid verfügbar. Es war früher abhängig von ruamel.base, und Benutzer, die es über PyPI installiert haben, haben möglicherweise noch ältere, inkompatible Versionen von ruamel.baseinstalliert. Die Verwendung von setup.py/PyPI ist keine echte Paketverwaltung, daher können Sie nichtlöschenein Paket, das zuvor über Abhängigkeiten installiert wurde. Ich habe das Problem für PyPI-Benutzer gelöst, indem ich eine neuere Version erstellt habe, ruamel.basedie die mit älteren Paketen verbundenen Probleme beseitigt ruamel.baseund ruamel.yamlvon dieser neueren Version abhängig gemacht hat.
Für Sid ist das kein Problem: ältere Versionen von ruamel.basewurden nicht installiert (oder konnten über die Paketverwaltung entfernt werden). Daher wenden sie einePatch, die Sie auf derruamel.yamlInformationsseite für SidDadurch wird die Abhängigkeit von ruamel.yamlentfernt ruamel.base.
Andere Distributionen haben ähnliche Setups. Wenn Sie sich beispielsweise die Spezifikationen zum Erstellen einer Quell-RPM-Datei ansehen (z. B. für RedHat/CentOS/SuSE), werden Sie feststellen, dass Sie das ursprüngliche Tarball eines Pakets mit einem oder mehreren Patches kombinieren, die vor der Konfiguration/Kompilierung angewendet werden.