Как вариант, действительно общеупотребительное вынести в какой-нибудь 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. Но его даже не рассматриваем, это слишком
> > большое изменение для стабильного бранча.
> 
> Это да, точно не стоит. Хотя хочется иногда.