On Sun, May 06, 2012 at 12:16:27AM +0300, Igor Vlasenko wrote:
> On Sun, May 06, 2012 at 01:06:40AM +0400, Dmitry V. Levin wrote:
[...]
> > Файлтриггер хорош в типовых ситуациях.  Если в какой-то редкой ситуации
> > файлтриггер будет вреден, то эта вредность будет усугубляться тем, что его
> > нельзя обойти.  Таким образом, если мы идем путем реализации файлтриггера,
> > то мы должны объявить, какие ситуации являются типовыми, и фактически
> > запретить все остальные.  Тоже вариант, конечно, если хорошо все
> > проработать, но я бы не хотел оказаться в ситуации необходимости
> > обходить файлтриггер.
> 
> Понятно. С другой стороны, обходить не так сложно, как кажется.
> Упаковать в проблемный пакет touch /lib/systemd/notrigger/%servicename
> а в filetrigger добавить if ! -e /lib/systemd/notrigger/%servicename.

Проверка на существование файла не совсем подходит для случая удаления
пакета, но в целом идея интересная.

У файлтриггера есть еще одна особенность: выполняться по окончании
транзакции.  Применительно к сервисам это означает выполнение "systemctl
try-restart" не сразу по завершении обновления пакета, а некоторое время
спустя.  В течение этого времени будут работать процессы предыдущей сборки
сервиса на обновленных файлах.  Не все сервисы так умеют.  Еще хуже
обстоит дело с остановкой сервиса при удалении пакета, потому что это
желательно делать, пока существует юнит-файл и те файлы, на которые он
ссылается (например, посредством ExecStop).  Когда все файлы пакета уже
удалены, с корректной остановкой сервиса могут возникнуть непреодолимые
сложности.  Тут бы, пожалуй, лучше подошел бы pretrans filetrigger, но
у нас таких пока не реализовано.

> Проблемных пакетов может оказаться 0-1 на весь Сизиф,
> а зато в 500 пакетах спеки станут чище и добрее :)

Это я к тому все говорю, что мы сейчас еще не знаем, какое в Сизифе
соотношение между числом пакетов, для которых вышеупомянутые
сложности с файлтриггером актуальны, и остальных пакетов с сервисами.


-- 
ldv