Реализация альтернатив

Ниже изложен один из возможных подходов к реализации системы альтернатив

Файлы альтернатив реализуются с помощью символических ссылок следующим образом: Общее имя , по которому пользователи вызывают программу /path/common-name указывает на служебную ссылку /etc/alternatives/internal-name, которая в свою очередь указывает на определённого кандидата /path/candidate. Такое размещение позволяет перенастраивать альтернативы даже если каталог с бинарными файлами /usr) находится в режиме “только чтение”. Кроме того, для программе работающей с альтернативами это, пожалуй, самый удобный способ удалять символические ссылки на уже несуществуюшие альтернативы (например в результате удаления пакета из системы).

Есть два возможных подхода организации базы данных кандидатов. Первый подход [1]: пакет при установке добавляет сведения в базу с помощью специальной утилиты, а при удалении - удаляет за собой данные из базы . В этом случае надо хорошо продумывать формат хранения из базы, а также корректное добавление/удаление данных. Существует большая опасность порушить базу, а вместе с ней и все альтернативы. Второй [2] - не создавать отдельного хранилища, каждый пакет носит с собой конфигурационный файл. При добавлении/удалении пакета данные “автоматически” добавляются/удаляются. Корректность процедуры гарантирует rpm. Во втором подходе пакету после установки достаточно только дать запрос на обновление. Система альтернатив проанализирует все альтернативы и произведёт все изменения, которые необходимы.

Второй подход лучше в плане хранения данных, облегчает восстановление в сбойных ситуациях, но тоже не без проблем. Скрипты обновления статуса альтернатив логично размещать в %post и %postun. Если просто проводить обновление, например, вызывая макрос %update_alternatives, то возможна ситуация, что в небольшой промежуток времени символические ссылки будут в подвешенном состоянии. Такое случается, например, когда удаляется пакет с большим весом - возникает промежуток времени между удалением файлов и запуском скрипта %postun (и соответственно восстановлением ситуации).

Истина как всегда где-то посередине. В нашей реализации используется смешанный подход: При установке пакета происходит активизация кандидата (%register_alternative), а перед началом удаления - деактивизация (%unregister_alternative). Поэтому несмостря на то что файлы ёщё присутствуют в системе система альтернатив считает, что их уже нет и переключает альтернативу на новые файлы. Активизация/деактивизация реализована через создание/удалении символической ссылки на файл-описание кандидата (/etc/alternatives/packages.d/some-name) в рабочий каталог (/etc/alternatives/auto/).

Конфигурационный файл альтернатив находится по адресу /etc/alternatives/alternatives.xml. Формат конфигурационого файла общий для всех программ, использующих класс Config из libing. Настраиваемые параметры:

alternatives::directories::packages

Каталог куда кладут свои файлы описания кандидатов пакеты, по-умолчанию это /etc/alternatives/packages.d/

alternatives::directories::packages

Каталог, где размещаются символические ссылки на активных кандидатов, по-умолчанию это /etc/alternatives/auto/

alternatives::directories::links

Каталог, где размещаются служебные ссылки, по-умолчанию - /etc/alternatives

Файл-описание также имеет стандартный формат со следующими параметрами. Внутри файла может присутствовать несколько групп candidate. Каждая группа есть описание одного кандидата альтернативы. Внутри группы candidate могут дополнительно присутствовать несколько групп slave - описание соответствующего предоставляемого кандидата подчиненной альтернативы

candidate::link

общее имя файла, разделяемое между несколькими альтернативами

candidate::real

реальное имя файла кандидата

candidate::weight

вес кандидата, может отсутствовать у альтернатив находящихся в ручном режиме

candidate::current

текущий кандидат альтернативы, присутствует только если альтернатива находится в ручном режиме

candidate::slave::link

общее, разделяемое имя подчиненной альтернативы

candidate::slave::real

реальное имя файла кандидата подчиненной альтернативы



[1] используется в реализации Debian

[2] по такой схеме работает menu