
Во многих программах Linux указано, что расположение файла(ов) конфигурации зависит от дистрибутива. Мне было интересно, как это делают разные дистрибутивы. Изменяют ли они на самом деле исходный код? Есть ли параметры сборки, которые задают эти расположения? Я искал об этом, но не смог найти никакой информации. Я знаю, что это где-то есть, просто не могу найти. Что такое «способ Linux» в этом отношении?
решение1
Это зависит от дистрибуции и исходного («вышестоящего») источника.
Для большинства пакетов, использующих autoconf и automake, можно указать каталог, в котором будут искаться файлы конфигурации, используя параметр --sysconfdir
. Другие системы сборки (например, CMake) имеют похожие параметры. Если исходный пакет использует одну из этих систем сборки, то упаковщик может легко указать правильные параметры, и никаких исправлений не требуется. Даже если они этого не делают (например, потому что исходный код использует какую-то собственную систему сборки), часто все равно можно указать некоторую конфигурацию сборки, чтобы переместить файлы конфигурации в определенное место без необходимости исправления исходного кода.
Если это не так, то часто дистрибутив действительно должен будет добавлять патчи к источнику, чтобы заставить его перемещать файлы в то, что они считают «правильным» местом. В большинстве случаев упаковщики дистрибутивов затем напишут патч, который позволит настроить источник в вышеуказанном смысле, чтобы они могли отправить патч вышестоящим сопровождающим и не должны были продолжать поддерживать/обновлять его. Это касается местоположений файлов конфигурации, но также и других вещей, таких как bin
/ sbin
исполняемые файлы (интерпретация того, что является командой системного администратора, различается в разных дистрибутивах), место, где писать документацию, и так далее.
Примечание: если вы поддерживаете какое-то свободное программное обеспечение,пожалуйстасделайте так, чтобы упаковщикам было легко общаться с вами. В противном случае нам придется поддерживать такие патчи без особой на то причины...
решение2
Они вносят исправления в исходный код дерева, которые адаптируют местоположения.
Существует достаточно "стандартов", доступных для каждого дистрибутивного решения, которые могут быть выбраны на основе (личных) предпочтений и/или исторической практики. Редко существует решение, котороетолькоимеет свои преимущества. Иногда это раздражает/сбивает с толку, но согласованность в рамках одного дистрибутива — самая важная цель: это приводит к меньшему беспорядку и более легкому угадыванию того, где могут находиться вещи для программы Y, если вы уже знаете, где находятся похожие вещи (например, файлы настройки/конфигурации) для программы X.
Пример применения патча
Мой пакет python ruamel.yaml
доступен в Debian Sid. Раньше он зависел от ruamel.base
, и пользователи, установившие его через PyPI, могли иметь старые, несовместимые версии ruamel.base
. Использование setup.py
/PyPI не является реальным управлением пакетами, поэтому вы не можетеудалитьпакет, ранее установленный через зависимости. Я решил проблему для пользователей PyPI, создав более новую версию, ruamel.base
которая устранила проблемы, связанные со старыми ruamel.base
пакетами, и сделала ruamel.yaml
зависимой от этой новой версии.
Для Сида это не проблема: старые версии ruamel.base
не были установлены (или могли быть удалены через управление пакетами). Поэтому они применяютпластырь, который вы можете найти наruamel.yaml
информационная страница для Сидачто устраняет зависимость ruamel.yaml
от ruamel.base
.
Другие дистрибутивы имеют похожие настройки. Например, если вы посмотрите на спецификации создания исходного файла RPM (например, для RedHat/CentOS/SuSE), вы увидите, что вы объединяете исходный tarball пакета с одним или несколькими патчами, которые будут применены перед настройкой/компиляцией.