[devel] I: rpm macroses for systemd

[Vladimir D. Seleznev]

On Fri, Aug 27, 2021 at 07:00:33PM +0300, Alexey Shabalin wrote:
> пт, 27 авг. 2021 г. в 17:42, Vladimir D. Seleznev <vseleznv на altlinux.org>:
> >
> > On Fri, Aug 27, 2021 at 02:51:56PM +0300, Alexey Shabalin wrote:
> > > пт, 27 авг. 2021 г. в 14:47, Alexey Shabalin <a.shabalin на gmail.com>:
> > > >
> > > > День добрый.
> >
> > Добрый день!
> >
> > > > Есть пара новостей для анонса.
> > > >
> > > > rpm макросы, используемые в апстрим (а также в RH, SUSE),
> > > > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> > > > добавлены в сизиф, но разнесены по двум пакетам: rpm-build и
> > > > rpm-build-systemd(rpm-macros-systemd)
> > > >
> > > > 1) В rpm-build расширен набор макросов с указанием путей для различных
> > > > компонентов systemd.
> > > > http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=commitdiff;h=01d2120325bd565dd69fab5473acdf7f13b3a322
> > > > По просьбе ldv@ макросы имеют более короткие и читаемые имена
> > > > (например вместо %_systemdusergeneratordir используется
> > > > %_user_gen_dir), но совместимость с апстримными макросами сохранена и
> > > > их тоже можно использовать.
> > > >
> > > > 2) rpm-build-systemd виртуальный пакет с зависимостями на
> > > > rpm-macros-systemd, systemd-utils, libsystemd-devel (что бы
> > > > устанавливались pkgconfig(libsystemd) и pkgconfig(systemd))
> > > > Типовое использование:
> > > > BuildRequires(pre): rpm-build-systemd
> > > > или
> > > > BuildRequires(pre): rpm-macros-systemd
> > > > BuildRequires: rpm-build-systemd
> >
> > А когда это нужно?
> 
> Это нужно, когда это нужно :)
> Очевидно, что когда хочется воспользоваться макросами, или когда нужна
> сборочная зависимость на pkgconfig(systemd).
> Или я не понял в чем вопрос.
> 
> >
> > > > 3) В rpm-build-systemd добавлены макросы для использования в разделах
> > > > %post, %preun, %postun
> > > > В /usr/lib/rpm/macros.d/systemd в комментариях можно посмотреть
> > > > варианты использования.
> > > >
> > > > - %post_systemd и %preun_systemd полностью повторяют логику работы
> > > > %post_service и %preun_service. Но в отличие от *_service им за раз
> > > > можно указать несколько unit-файлов, systemd сам разберется в
> > > > очередности перезагрузки сервисов.
> > > > Пример использования:
> > > > -----------------
> > > > %post
> > > > %post_systemd demo.socket demo.service demo1
> > > >
> > > > %preun
> > > > %preun_systemd demo.socket demo.service demo1
> > > > -----------------
> >
> > И что делать тем, у кого в пакетах помимо service-файлов ещё и
> > init-скрипты?
> 
> Ничего не делать, продолжать жить дальше и использовать %post_service
> и %preun_service.
> Новые макросы systemd-only, поэтому они в пакете rpm-macros-systemd.
> У нас сейчас есть довольно много пакетов, которые не предусматривают
> работу под sysvinit.
> Например, ceph, в нем в принципе все заточено для работы под systemd,
> используются юниты вида ceph-osd на 3.service, ceph-mon на server1.service.
> И рестартовать сервисы хотелось бы в конце транзакции.
> Или я опять не понял в чем вопрос.
> 
> Реализовывать отложенный рестарт сервисов под sysvinit нужно каким-то
> другим способом.
> Сейчас как это сделать, каждый пакет придумывает самостоятельно.

Спасибо, стало понятнее.

> >
> > > > [skip]
> > >
> > > Забыл, плюс еще пастримные макросы %tmpfiles_create, %sysusers_create,
> > > %sysusers_create_package, %tmpfiles_create_package, %sysctl_apply,
> > > %binfmt_apply.
> > > Что они делают и примеры тоже можно посмотреть
> > > /usr/lib/rpm/macros.d/systemd, вроде ничего сложного, должно быть
> > > понятно.
> > > Если возникнут вопросы, обращайтесь.
> >
> > У меня возникли вопросы к макросам, обозначенным в последнем абзаце,
> > точнее их необходимости.  Управлять tmpfiles всё-таки надо через
> > tmpfiles.d, а изменять состояния sysctl и binfmt в результате установки,
> > обновления или удаления пакетов мне видится неправильным.
> 
> Не используйте. Я вижу что вы макросы не читали, но осуждаете.

Как раз-таки читал и осуждаю.

> А мне вот нужна необходимость упаковать что-то sysctl.d и применить до
> рестарта сервиса, а не дожидаться когда отработает filetrigger или
> сервер перезагрузится.

Вот как-раз таки такое поведение мне кажется неправильным. Установка,
обновление или удаление пакета с сервисами не должно приводить к
изменению конфигурации sysctl, это зона ответственности системного
администратора. Единственный случай, при котором мне кажется это
допустимо, это сервисы, перезагружающие модуля ядра с последующим
применением (восстановлением, в данном случае) конфигурации
sysctl-параметров, которые данный модуль предоставляет (но это
вырожденный пример). Ну, или ещё вариант, что я ничего не понимаю в
современных Линуксах.

-- 
   WBR,
   Vladimir D. Seleznev