Уж коль скоро в системе с sysvinit нельзя удалить systemd-utils, не следует упаковывать в пакет совсем ненужные компоненты: # rpm -qf /bin/journalctl systemd-utils-237-alt2.M80P.2 # rpm -qf /bin/systemctl systemd-utils-237-alt2.M80P.2 Если это безобразие только в p8, можно на p8 перевесить.
Как вариант, действительно общеупотребительное вынести в какой-нибудь systemd-common.
systemd-utils и есть обще употребительное. Добавление systemctl в этот пакет чисто техническое, и выстраданное. По другому уже не получается. Тяжело усидеть на двух стульях. Решаемая проблема в следующем. Все описанное ниже решалось для p8, и в sisyphus сделано для однообразия. Старый rpm в p8 работает не так как в sisyphus. При обновлении новый rpm сначала устанавливает все пакеты и потом удаляет старые. Старый обрабатывает по одному - ставит новый и тут же удаляет старый. Отсюда получается проблема с библиотекой libsystemd-shared. Точнее с программами, которые её используют. Выглядит это следующим образом. При dist-upgrade: - обновляется libsystemd-shared и тут же удаляется старая. - обновляются systemd-utils (systemd-tmpfiles, systemd-sysctl - они нужны и в SysV) - обновляется udev. В случае SysV все хорошо, udev рестартуется с помощью service (init-скрипта). А вот в случае systemd рестартуется с помощью systemctl. Но в этот момент systemctl уже не рабочий, т.к. libsystemd-shared уже обновилась, а systemctl (который в пакете systemd) еще нет. Получается ошибка обновления и в системе остаются два пакета udev. - обновляется systemd, в котором systemctl. Но уже поздно. Т.е. надо добиться нужного порядка обновления, сначала systemd, а потом udev. Но добавить зависимость в udev на systemd нельзя, потому что пользователям SysV прилетит systemd. Указанный Conflicts в udev на systemd < %EVR никак не помогает, apt ведёт себя по-своему. Самым надёжный способ гарантировать нужную libsystemd-shared для systemctl это разместить их в одном пакете. Но libsystemd-shared нужна и самому "первому" пакету systemd-utils. Поэтому и было принято решение перенести и libsystemd-shared, и systemctl в один пакет systemd-utils. Есть еще один вариант, это объединить udev и systemd. Он бы меня вполне устроил, если бы нашёлся смелый мантейнер сопровождать специальный отдельный udev для SysV систем. Типа eudev в gentoo. Другой вариант, новый rpm в p8. Но его даже не рассматриваем, это слишком большое изменение для стабильного бранча. Journalctl перенес до кучи. Он точно не помешает, т.к. позволяет читать лог-файлы, скопированные с другого компьютера. А размер 63К не значительный.
(In reply to comment #2) > Самым надёжный способ гарантировать нужную libsystemd-shared для systemctl это > разместить их в одном пакете. А собрать systemctl статикой не вариант? Тем более, раз всё равно нельзя библиотеку обновить отдельно. И, кстати, а как с остальными приложениями, её использующими? > Другой вариант, новый rpm в p8. Но его даже не рассматриваем, это слишком > большое изменение для стабильного бранча. Это да, точно не стоит. Хотя хочется иногда.
(В ответ на комментарий №3) > (In reply to comment #2) > > > Самым надёжный способ гарантировать нужную libsystemd-shared для systemctl это > > разместить их в одном пакете. > > А собрать systemctl статикой не вариант? Тем более, раз всё равно нельзя > библиотеку обновить отдельно. И, кстати, а как с остальными приложениями, её > использующими? Можно, и так будет сделано (systemctl со статической libsystemd). Беда в том, что сейчас уже в системе у пользователей не статический. Поэтому прилетают новые библиотеки, и старый сразу становится не рабочим. А новый еще не установился, а его уже пытаются использовать (udev прилетает раньше и пытается перезапуститься). > > > Другой вариант, новый rpm в p8. Но его даже не рассматриваем, это слишком > > большое изменение для стабильного бранча. > > Это да, точно не стоит. Хотя хочется иногда.