34809 2018-04-14 12:37:52 +0300 Следует удалить лишние компоненты из systemd-utils 2018-08-17 15:14:06 +0300 1 1 4 Development Sisyphus systemd-utils unstable all Linux CLOSED WONTFIX P3 normal --- 1 asy shaba evg mike shaba qa-sisyphus oldest_to_newest 170406 0 asy 2018-04-14 12:37:52 +0300 Уж коль скоро в системе с 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 перевесить. 170407 1 asy 2018-04-14 12:41:17 +0300 Как вариант, действительно общеупотребительное вынести в какой-нибудь systemd-common. 170432 2 shaba 2018-04-17 01:50:46 +0300 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К не значительный. 170435 3 asy 2018-04-17 12:02:48 +0300 (In reply to comment #2) > Самым надёжный способ гарантировать нужную libsystemd-shared для systemctl это > разместить их в одном пакете. А собрать systemctl статикой не вариант? Тем более, раз всё равно нельзя библиотеку обновить отдельно. И, кстати, а как с остальными приложениями, её использующими? > Другой вариант, новый rpm в p8. Но его даже не рассматриваем, это слишком > большое изменение для стабильного бранча. Это да, точно не стоит. Хотя хочется иногда. 173422 4 shaba 2018-08-17 15:14:06 +0300 (В ответ на комментарий №3) > (In reply to comment #2) > > > Самым надёжный способ гарантировать нужную libsystemd-shared для systemctl это > > разместить их в одном пакете. > > А собрать systemctl статикой не вариант? Тем более, раз всё равно нельзя > библиотеку обновить отдельно. И, кстати, а как с остальными приложениями, её > использующими? Можно, и так будет сделано (systemctl со статической libsystemd). Беда в том, что сейчас уже в системе у пользователей не статический. Поэтому прилетают новые библиотеки, и старый сразу становится не рабочим. А новый еще не установился, а его уже пытаются использовать (udev прилетает раньше и пытается перезапуститься). > > > Другой вариант, новый rpm в p8. Но его даже не рассматриваем, это слишком > > большое изменение для стабильного бранча. > > Это да, точно не стоит. Хотя хочется иногда.