[devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:
> On Sat, May 21, 2011 at 04:42:31PM +0400, Alexey Shabalin wrote:
>> Чёрт, с этим исправлением возникает другая проблема.
>> В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
>> Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
>> (добавляется d в конце имени).
>
> Вопрос, эти названия из upstream существуют в виде init-скриптов, или в
> каком-то ином виде?  Например, если апстрим реализует некий демон
> SERVICEd, то init-скрипт у нас с высокой вероятностью будет называться
> SERVICEd а не SERVICE.  Просьба прояснить картину.

В виде init-скриптов для RedHat.  Да и другие дистрибутивы стараются
держать имена сервисов аналогичными с RedHat.
Ну и systemd делался изначально для федоры с оглядкой на имена
сервисов в федоре.
В .service файлах зависимости указываются по именам сервисов, а сервис
может быть как .service файл для systemd, так и init-скрит.

>> Для работы с systemd на такие имена сделаны симлинки
>> # ls -l /lib/systemd/system/udevd.service
>> lrwxrwxrwx 1 root root 12 Май 21 17:39
>> /lib/systemd/system/udevd.service -> udev.service
>> [root на shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
>> lrwxrwxrwx 1 root root 17 Май 21 17:39
>> /lib/systemd/system/bluetoothd.service -> bluetooth.service
>>
>> Это работает  для start|stop (systemctl start|stop foo.service или
>> service foo start|stop ),
>> но не работает для enable|disable ( systemctk enable|disable
>> foo.service или chkconfig foo enable|disable)
>> Ругается что это symlink и хочет правильное имя.
>>
>> Как это объезжать?
>> - привести имена init-скриптов к апстримному виду
>
> В этом случае сломаются обновление пакетов и привычки у людей.
Для обновления можно использовать тригеры.
И возможно этот путь самый реалистичный.

>> - привести имена .service файлов к ALTLinux виду
>
> В этом случае может ухудшиться переносимость .service-файлов.
Да, придётся всё отслеживать. Можно в пакет добавлять
Provides/Requires типа systemd(foo).

> Если идти путем переименования, то придется рассматривать каждый случай
> в отдельности.
>
>> - научить systemd делать enable|disable для симлинков (а симлинк может
>> быть и на /dev/null - для systemd это нормальный способ выключить или
>> замаскировать сервис).
>
> Если симлинк ведет на /dev/null, то как ему можно сделать enable|disable?
не важно, можно ли сделать enable|disable на симлинк /dev/null, важно
что при start|stop ничего происходить не будет.
А сейчас enable|disable с любыми симлинками запрещены. Поэтому,
например, невохможно коректно обновить udev. post скрипт обламывется и
в системе остаётся два udev.

-- 
Alexey Shabalin