[devel] groups of alternatives and branding-*

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Уважаемые коллеги,

Поясню свое предложение, что понимаю под группой альтернатив,
которых нам не хватает и неплохо бы внедрить, и почему это 
не то же самое, что master/slave.
(Спасибо Мише за реплику, я понял, что нужно объяснить
свою мысль подробнее)

viy@:
> > По примеру branding от Сергея Турчина, вынести файловые
> > конфликты в альтернативы, а управление группой альтернатив
> > консольному скрипту (или control(8) приспособить)
> > и модулю альтератор.

mike@:
> ...умеет и сам alternatives (там есть master/slave).

master/slave имеет смысл для конкретного пакета, но не для брендинга 
в целом. Поясню на примере. Допустим, я для зайцев хочу 
создать дистрибутив "Carrot Linux" c дизайном.
И допустим, что я подготовил три пакета с дизайном, для LXDE,
IceWM и KDE4. Вопрос на засыпку: где должен быть мастер?

При том, что у меня три зайца-пользователя.
У зайца А только LXDE, у зайца B -- IceWM, у зайца С -- KDE4. 
Каждому зайцу пакеты с чужим дизайном 100 лет не нужны, тем более
чужие WM/DE. Тем более, что заец С на одной машине с волком Х,
который пользуется LXDE в дизайне "Beast Linux", и, если ему вдруг 
установить LXDE "Carrot Linux", съест зайца С.

Рассуждая логически, придем к тому, что master/slave управление --
должно быть на уровне симлинков одного пакета, 
но должно быть описание метагруппы master/slave симлинков, 
чтобы была бонусная возможность переключать 
сразу всю метагруппу, пакеты из которой равноправны,
любая часть из которых может на законных основаниях
отсутствовать.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine