> Ну вот всё кроме xz-libs явно могло бы быть факультативным. Есть d-bus
> - пользуемся, нет - работаем только как TCP-сервер (раз уж "из
> других систем по локальной сети").А они разве между хостами передают по TCP, а не через dbus? Не, если это действительно так, то я соглашусь и подпишусь под утверждением, что авторы идиоты. Но поскольку они не выглядят для меня идиотами, я скорее предположу, что они коннектятся к dbus-демону на удалённой машине и весь IPC гонят через dbus.
> Есть ещё и libudev - ловим
> появление/исчезновение устройств (больше ж оно ни за чем не может быть
> нужно?), нет - берём из конфига (в любом случае нужен).
Можно, наверное. Не вижу глубинного смысла: по-моему, это лишь ненужное усложнение кода. Если начать работать с конфигом, то начнутся проблемы типа "конфиг не найден", "синтаксическая ошибка в конфиге", "девайс не найден", "девайс выдернули из гнезда", ... То что в случае hotplug не проблема, а рабочая ситуации, в случае с конфигом превратится в наслоения кода обработки ошибок. И зачем мне эти наслоения кода, если у меня есть libudev?
Впрочем, если это кому-то надо, то он, я полагаю, вполне может отправить pull-реквест -- ну, в качестве альтернативы для libudev, с возможностью отключения при компиляции.
> Есть libcap - пользуемся, нет - работаем как есть. Но, понятно, гномоводы
> не привыкли делать так, всё прибивают на свой юз-кейс...
Прибивать на чужой юзкейс -- это глупость. Софт должен писаться для конкретных целей. Если софт пишется на все случаи жизни, то случается системд. Если в команде разработчиков нет того, кому мешает libcap, значит libcap не мешает. А он не мешает: там где есть ядро linux, можно потерпеть и libcap. Тем более что на libxz и libdbus уже согласились, а они ведь потолще будут в разы.
