Багато програм Linux стверджують, що розташування файлів конфігурації залежить від розподілу. Мені було цікаво, як це роблять різні дистрибутиви. Чи дійсно вони змінюють вихідний код? Чи є параметри побудови, які встановлюють ці місця? Я шукав це, але не можу знайти жодної інформації. Я знаю, що це там, я просто не можу його знайти. Який "Linux шлях" щодо цього?
Відповіді:
Це залежить від розповсюдження та вихідного ("вище") джерела.
У більшості пакетів, що використовують autoconf та автоматичне використання, можна вказати каталог, у якому шукатимуться файли конфігурації за допомогою --sysconfdirпараметра. Інші системи побудови (наприклад, CMake) мають подібні параметри. Якщо вихідний пакет використовує одну з цих систем побудови, то пакувальник може легко вказати потрібні параметри, і не потрібні патчі. Навіть якщо вони цього не роблять (наприклад, через те, що джерело висхідного потоку використовує деяку домашню систему збірки), часто все ще можна вказати певну конфігурацію збірки для переміщення файлів конфігурацій до певного місця, не потребуючи латки вихідного джерела.
Це не так, то часто дистрибутиву доведеться додавати патчі до джерела, щоб змусити його переміщувати файли в тому, що вони вважають «правильним» місцем розташування. У більшості випадків розповсюджувальні пакети потім випишуть патч, який дозволить налаштувати джерело у вищезгаданому сенсі, щоб вони могли надсилати патч вищестоящим обслуговуючим особам, і не потрібно продовжувати його підтримувати / оновлювати. Це стосується розташування файлів конфігурації, але також і для інших речей, таких як bin/ sbinвиконувані файли (інтерпретація того, що є командою системного адміністратора, відрізняється між дистрибутивами), місця, куди слід писати документацію тощо.
Побічна примітка: якщо ви підтримуєте якесь безкоштовне програмне забезпечення, будь ласка, полегшіть розмову з вами упаковщиками. Інакше нам доведеться підтримувати такі патчі без особливо вагомих причин ...
Вони мають патчі, застосовані до дерева вихідного коду, які адаптують розташування.
Існує достатньо "стандартів", щоб кожен дистрибутив міг вибрати свій вибір, виходячи з (особистих) уподобань та / або історичної практики. Рідко є рішення, яке має лише переваги. Іноді це дратує / заплутує, але послідовність у межах одного дистрибутива є найважливішою метою: це призводить до менших проблем і легшого вгадування, де можуть бути програми для програми Y, якщо ви вже знаєте, де подібні речі (файли налаштування / конфігурації, наприклад) для програми X.
Мій пакет python ruamel.yamlдоступний у Debian Sid. Раніше це залежало від того ruamel.base, і користувачі, які встановили через PyPI, можуть все-таки встановити старіші, несумісні версії ruamel.base. Використання setup.py/ PyPI не є реальним управлінням пакетом, тому ви не можете видалити пакет, встановлений раніше через залежності. Я вирішив проблему для користувачів PyPI, створивши новішу версію, ruamel.baseяка усунула проблеми, пов’язані зі старими ruamel.baseпакунками, і стала ruamel.yamlзалежною від нової версії.
Для Sid це не проблема: старіші версії ruamel.baseфайлів не були встановлені (або їх можна було видалити за допомогою управління пакетами). Тому вони застосовують патч , який ви можете знайти на ruamel.yamlсторінці інформації для Сіда , який видаляє залежність ruamel.yamlвід ruamel.base.
Інші дистрибутиви мають подібні налаштування. Наприклад, якщо ви подивитеся на характеристики створення вихідного RPM-файлу (наприклад, для RedHat / CentOS / SuSE), ви побачите, що ви поєднуєте оригінальний оригінальний тарбол пакету з одним або декількома патчами, які будуть застосовані перед налаштуванням / компіляцією .