Если и делать filetrigger, то, видимо, в пакете service.

Для дистрибутива системы с systemd существующих костылей уже не достаточно, т.к. сервис из пакета с диска дистрибутива, установленного уже после установки дистрибутива будет _только_ в состоянии "отключено".

(В ответ на комментарий №2)
> Для дистрибутива системы с systemd существующих костылей уже не достаточно,
> т.к. сервис из пакета с диска дистрибутива, установленного уже после установки
> дистрибутива будет _только_ в состоянии "отключено".

И что же в этом плохого?

(В ответ на комментарий №3)
> И что же в этом плохого?
В том, что сервис не будет включен по умолчанию, нисмотря ни на что.
При sysvinit он это хтя бы регулируется мантейнером пакета, а с systemd это ну может регулироваться вообще никем, кроме конечного пользователя.

Я предлагаю решение, которое позволит это регулировать Release Manager-у. 
Вроде, этот несуществующий аргумент фигурировал в рассылке.

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

Например, если пользователь в установщике снимет галку "Поддержка печати", то потом свежеустановленный cups ему никто не включит.

(In reply to comment #2)
> Для дистрибутива системы с systemd существующих костылей уже не достаточно,
> т.к. сервис из пакета с диска дистрибутива, установленного уже после установки
> дистрибутива будет _только_ в состоянии "отключено".

%post_service свежеустановленного пакета выполнит systemctl preset, который, в свою очередь, может либо сделать сервис enabled, либо оставить его disabled.

(В ответ на комментарий №6)
> %post_service свежеустановленного пакета выполнит systemctl preset
Для любого сервиса, поведение которого собрался регулировать ReleaseManager дистрибутива? В последнем слове предыдущего предложения 1-я буква "т" -- лишняя, если это не так ;-)

А так же chkconfig делает только
/bin/systemctl -q enable %s.service
, а у cups, например, кроме .service есть еще и .socket и .path .

(В ответ на комментарий №8)
> А так же chkconfig делает только
> /bin/systemctl -q enable %s.service
> , а у cups, например, кроме .service есть еще и .socket и .path .

не вводите в заблуждение.
в cups.service есть секция [Install], где:
Also=cups.socket cups.path
Т.е для systemctl enable cups.service, так же будут включены и cups.socket cups.path

(В ответ на комментарий №9)
> Also=cups.socket cups.path
Ок. Это хорошо.

А еще нужно, чтоб filetrigger и запускал сервис в зависимости от 
$DURING_INSTALL (для сервера это можно отключить).

Например (это прямо сейчас все могут воспроизвести), у пользователя установлен
KDE4, но не установлена samba.
Пользователь тыкается в свойства каталога, закладку раздачи.
Ему там говорят "samba не установлена, давай поставлю".
Он соглашается, samba устанавливается.
Он включает раздачу и нажимает ok.
Результат: никакой раздачи не происходит, даже если все утилиты настройки
отработали правильно, потому, что samba не запущена.

(В ответ на комментарий №9)
> не вводите в заблуждение.
Не цепляйтесь к словам. Я лишь привожу пример.
Или подобное "Also" обязано быть в каждом .service при наличии .socket или .path?

(В ответ на комментарий №12)
> (В ответ на комментарий №9)
> > не вводите в заблуждение.
> Не цепляйтесь к словам. Я лишь привожу пример.
да ладно, это я так, к слову.

> Или подобное "Also" обязано быть в каждом .service при наличии .socket или
> .path?

если нет симлинков в /lib/systemd/system/*.wants/ , то обязательно.