On Tue, Apr 15, 2008 at 10:01:21PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [080415 21:50]:
> > > Ну а информацию о требуемом наборе действий rpmi должен брать из
> > > какого-нибудь /etc/rpm/autoscripts.d. Например, пакет GConf будет
> > В каком виде можно описать эту информацию?
> В самом тупом.  "МАСКА  СКРИПТ".  Сейчас большинство (если не
> все) макросов %update_*/%clean_* отличаются только разбором
> $RPM_ARG1 (или как он там называется).  Почти все эти скрипты не
> принимают аргументов, работают со всеми файлами в системе (а не
> только с файлами из пакетов) и могут запускаться один раз за
> транзакцию.  Может с этого и начнём?
> 
> > Если хочется обрабатывать нетривиальные случаи, то мы закончим
> > языком программирования.  А подходящего языка программирования
> > нет.
> Для нетривиальных случаев есть %post скрипты в пакете ;-)
> 
> Хотя, хотелось бы автоматизировать случаи типа схем GConf или
> info.

Понимаешь, нужно высокоуровневое семантическое описание того, что
находится в пакете.  Тогда можно обрабатывать нетривиальные случаи,
напр. condrestart сервисов.  А также не хочется играть в "большинство"
пакетов, это не игра в проценты, и надёжность должна быть очень высокой.

"МАСКА СКРИПТ" покрывает только самые тривиальные случаи (без
аргументов, которые просто делают какой-то кеш-генерат).  Кроме того,
остаётся открытым вопрос, чем парсить "МАСКУ СКРИПТ".  На Си это писать
глупо, а на шелле это не хочется писать по другой причине -- выбор
средств для модификаций rpmi гораздо сильнее ограничен, чем выбор
средств для модификации rpmb.  Ну, в rpmb можно засунуть всё что угодно,
и в худшем случае просто какие-то пакеты не пересобирутся, но мы потом
просто rpmb поправим к следующему разу (достаточно, чтобы rpmb мог
пересобрать сам себя, но это обычно проверяется).  А если в rpmi что-то
обламывается, то это уже не проблемы разработчиков, а материализация
духов.

Короче тра-ля-ля, нужно думать, может ли эта идея быть универсально
жизнеспособной, то есть не просто для большей половины пакетов, а для
подавляющего числа пакетов (надёжность начинается с 99%), и что делать
с пакетами, которые в это дело не вписываются.  А именно, надо,
например, продумать схему 1) condrestart сервисов;
и 2) control-dump/control-restore.  Можно это делать автоматически,
ВЫВОДЯ (deduce) всю необходимою информацию из хедера пакета, или нет?

Рассмотрим condrestart сервисов.  Условие может быть таким: если
в пакете есть файл %_initdir/foo, то после установки надо запустить
%_initdir/foo condrestart.  Но не все init-скритпы допускают conrestart.
А некоторые ничего не должны делать при condrestart (напр. network;
сейчас в network вообще нет condrestart).  Это накладывает новые
требования на init-скритпы: они должны выполнять некое DWIM-действие
при вызове condrestart.

Можно конечно проверить что если condrestart нет то и спросу нет,
но это глупо.

$ grep condrestart /etc/init.d/network || echo $?
1
$

Рассмотрим другой вопрос: добавление псевдопользователей и псевдогрупп
в систему.  Если в rpm пакете (в списке %files) есть левые
псевдопользователи и псведогруппы, тогда их можно добавлять
автоматически.  Но иногда их нет, а есть лишь демон (бинарь), который
при запуске рассчитывает, что этот пользователь/группа должны быть в
системе.  Тогда уже на автомате ничего сделать нельзя.

Это возвращает меня к начальному постулату: нужно высокоуровневое,
семантическое, декларативное описание того, что именно находится
в rpm пакете (кроме файлов).  Но это противоречит юникс-вею, что типа
всё тупо и прозрачно, и никаких неявных связей нету.  А они есть, и
их не всегда можно вывести.