Wiele programów Linuksa twierdzi, że lokalizacja pliku (-ów) konfiguracyjnego zależy od dystrybucji. Zastanawiałem się, jak to robią różne dystrybucje. Czy faktycznie modyfikują kod źródłowy? Czy istnieją parametry kompilacji, które ustawiają te lokalizacje? Szukałem tego, ale nie mogę znaleźć żadnych informacji. Wiem, że tam jest, ale po prostu nie mogę go znaleźć. Jaki jest w tym zakresie „sposób Linuxa”?
Odpowiedzi:
Zależy to od dystrybucji i pierwotnego („upstream”) źródła.
W przypadku większości pakietów używających funkcji automatycznego uwierzytelniania i automatycznego konfigurowania można określić katalog, w którym będą wyszukiwane pliki konfiguracyjne, za pomocą parametru --sysconfdir parametru. Inne systemy kompilacji (np. CMake) mają podobne opcje. Jeśli pakiet źródłowy korzysta z jednego z tych systemów kompilacji, program pakujący może łatwo określić właściwe parametry i nie są wymagane żadne łaty. Nawet jeśli tego nie robią (np. Ponieważ źródło źródłowe używa jakiegoś domowego systemu kompilacji), często nadal można określić konfigurację kompilacji, aby przenieść pliki konfiguracyjne do określonej lokalizacji bez konieczności łatania źródła źródłowego.
Tak nie jest, wtedy często dystrybucja rzeczywiście będzie musiała dodać łatki do źródła, aby przenieść pliki w miejscu, które uznają za „właściwą” lokalizację. W większości przypadków osoby zajmujące się dystrybucją napiszą następnie łatę, która pozwoli na skonfigurowanie źródła w powyższym sensie, tak aby mogły wysłać łatkę do opiekunów poprzedzających i nie będą musieli jej utrzymywać / aktualizować. Dotyczy to lokalizacji plików konfiguracyjnych, ale także innych rzeczy, takich jak bin/sbin executables (interpretacja polecenia administratora systemu różni się w zależności od dystrybucji), lokalizacja zapisu dokumentacji itd.
Dygresja: jeśli zachować trochę wolnego oprogramowania, prosimy ułatwiają pakujących porozmawiać. W przeciwnym razie musimy zachować takie łatki bez szczególnie dobrego powodu ...
Mają łatki zastosowane do drzewa kodu źródłowego, które dostosowują lokalizacje.
Dostępnych jest tyle „standardów”, że każda dystrybucja może wybrać według własnych preferencji i / lub praktyk historycznych. Jest to rozwiązanie, które rzadko tylko ma zalety. Czasami jest to denerwujące / mylące, ale spójność w ramach jednej dystrybucji jest najważniejszym celem: prowadzi do mniej bałaganu i łatwiejszego zgadywania, gdzie mogą być rzeczy dla programu Y, jeśli już wiesz, gdzie podobne rzeczy (np. Pliki konfiguracji / konfiguracji) są dla programu X.
Mój pakiet python ruamel.yamljest dostępny w Debianie Sid. Kiedyś była zależna ruamel.base, a użytkownicy, którzy zainstalowali za pośrednictwem PyPI, mogą nadal mieć starsze, niekompatybilne wersje ruamel.base. Użycie setup.py/ PyPI nie jest prawdziwym zarządzaniem pakietami, więc nie można usunąć pakietu wcześniej zainstalowanego przez zależności. Rozwiązałem problem dla użytkowników PyPI, czyniąc nowszą wersję, ruamel.basektóra usunęła problemy związane ze starszymi ruamel.basepakietami i ruamel.yamluzależniła się od tej nowszej wersji.
W przypadku Sid nie stanowi to problemu: starsze wersje ruamel.basenie zostały zainstalowane (lub można je usunąć za pomocą zarządzania pakietami). Dlatego też stosować plastra , który można znaleźć na ruamel.yamlstronie informacyjnej dla Sid , który usuwa zależność ruamel.yamlna ruamel.base.
Inne dystrybucje mają podobne konfiguracje. Np. Jeśli spojrzysz na specyfikacje tworzenia źródłowego pliku RPM (np. Dla RedHat / CentOS / SuSE), zobaczysz, że łączysz oryginalne oryginalne archiwum pakietu z jedną lub kilkoma łatkami, które zostaną zastosowane przed konfiguracją / kompilacją .