Частичная установка пакета

Главная проблема сборки конфигурационных пакетов - это конфликт по конфигурационным файлам. Один из способов избежать конфликта - исключить из установки часть конфигурационных файлов и перенести их в другое место. Такой подход не требует какого-либо изменения политики сборки пакетов со стороны мантейнеров дистрибутива и конфигурационные пакеты можно делать в индивидуальном порядке. В этом случае установка и использование конфигурационного пакета состоит из трех шагов:

1. Конфигурируемые пакеты устанавливаются с исключением (или переносом) конфигурационных файлов;
2. Устанавливается конфигурационный пакет, который размещает свои файлы в тех местах, где должны были быть ранее исключенные конфигурационные файлы пакетов;
3. При выполнении операции обновления, пакетный менеджер обновляет файлы из тех пакетов, из которых они действительно происходят.

У такого подхода есть некоторые не очевидные недостатки, из которых самый главный - пакетный менеджер действительно должен обеспечивать выполнение п.3, что, как мы увидим ниже, под вопросом. Другие недостатки более очевидны:

• Сама процедура установки конфигурационного пакета представляет собой достаточно сложный сценарий, а не просто "Введи команду и используй";
• Триггеры, выполняющиеся при установке пакетов, как правило требуют наличия конфигурационных файлов пакетов, причем, "своих" конфигурационных файлов.

Различные пакетные менеджеры предлагают опции для частичной установки пакетов, рассмотрим два из них.

Принудительный вынос конфигов

Самым удачным решением мог бы стать принудительный вынос конфигурационной части всех программных пакетов. Так, для некоторого пакета somesoft при сборке всегда можно создавать отдельный пакет somesoft-cfg, содержащий всю конфигурационную часть. Если пакеты somesoft и somesoft-cfg будут декларировать зависимости друг на друга, то для обычного пользователя ничего не изменится: как и раньше, он будет устанавливать пакет со стандартными конфигурационными файлами одной командой.

В тоже время, разделение пакета на основную и конфигурационную часть дает хорошую возможность разрабатывать конфигурационные пакеты: такой пакет должен предоставлять возможность somesoft-cfg, что сделает пакет somesoft-cfg виртуальным. Пользователь, устанавливающий пакет somesoft должен будет выбрать конфигурацию, в составе которой будет использоваться пакет.

Можно рассмотреть более сложный случай:

• Пусть существуют пакеты somesoft1, somesoft2 и somesoft3 с соответствующими им конфигурационными пакетами;
• Пусть существуют независимые конфигурации solution1, solution2, реализующие специальные решения на основе пакетов somesoft1, somesoft2 и somesoft3;
• Тогда каждая из конфигураций solution1, solution2 должна предоставлять возможности somesoft1-cfg, somesoft2-cfg и somesoft3-cfg и требовать пакеты somesoft1, somesoft2 и somesoft3.

Таким образом, пользователь, желающий установить готовое решение solution1 или solution2 инициирует их установку, а пользователь, желающий самостоятельно настроить пакеты somesoft1, somesoft2 и somesoft3 инициирует установку пакетов somesoft1-cfg, somesoft2-cfg и somesoft3-cfg.

Такое подход является исчерпывающим решением проблемы, но, к сожалению, воплотить его в жизнь можно только на уровне политики дистрибутива (не столь важно, какого именно), а вероятность её разумного обсуждения, не говоря уж о принятии, исчезающе мала. Тем не менее, как дополнительный аргумент напомню основной тезис статьи Как сделать популярный дистрибутив: хороший дистрибутив, это дистрибутив на основе которого работает несколько коммерческих, конкурирующих групп поддержки пользователей, поставляющих свои решения на основе этого дистрибутива. А для такой группы едва ли не основным инструментом может стать описываемый здесь конфигурационный пакет. Собственно, даже эта статья написана под влиянием обсуждения и по опыту работы в такой группе.

RPM и символические линки

Практически с таким же успехом, конфигурационный пакет можно создать разместив конфигурационные файлы в другое место: например, в директорию /etc/solution1/ для пакета solution1. При этом все соглашения о зависимостях остаются теми же самыми, но потребуется специальный инструмент, выполняющий замену оригинальных конфигурационных файлов конфигурируемых пакетов символическими линками на файлы конфигурационного пакета. При некотором таланте, работу этого инструмента можно сделать обратимой и настроить его автоматический запуск при установке пакета.

Лично я много лет использовал такой способ для различных своих решений (электронной почты, офисного сервера, пакета настройки хостинга и т.п.), и он достаточно хорошо себя зарекомендовал. Такие пакеты обеспечивают тиражируемость решения и возможность централизованного внесения изменений в конфигурацию.были

Домашние извращения в /usr/local

Проблем со стандартными пакетными менеджерами и политикой дистрибутива иной раз настолько много, что более предпочтительным является установка программного обеспечения в /usr/local. Один из случаев, когда приходится принять такое решение, описан для пакетов egg языковой среды python, но он также верен практически для любого развитого языка или программы, обладающей собственной версией менеджера пакетов или дополнений.

Я пользуюсь этим без особых проблем, получая выгоду от гибкости, скорости, независимости от дистрибутива и ориентированности на язык, но рекомендовать это к массовому применению не готов: это решение на ваш собственный риск.

SVN и конфиги в /usr/local

Я никогда не видел это решение в действии и не использовал его сам, а всего лишь рассказываю подход, который услышал от одного очень уважаемого мной (да и вами :) ) специалиста. Идея состоит в том, чтобы держать все конфигурационные файлы в репозитории subversion (или любом другом). Из репозитория конфигурация извлекается, например, в директорию /usr/local, затем запускается вышеупомянутый инструмент, заменяющий оригинальные конфигурационные файлы символическими линками на файлы из репозитория.

Очевидно, такой подход полностью решает проблему централизованного управления конфигурацией и тиражирования решений. Применим ли он в вашем случае - решать вам.