tl;dr
1) Мы говорим не о последовательности загрузки, мы говорим о systemd-delta.
2) Дефолтная конфигурация может быть получена в результате выполнения мейнтейнерского скрипта, к тому же её может не быть вовсе.> Только это не о boot sequence.
Так мы и говорим не о ней. Мы говорим о systemd-delta, которая вроде как должна сравнивать конфигурационные файлы.
С обеспечением boot sequence у systemd -- тоже тема весьма кислая, и мне есть много чего сказать по этому поводу. Но давайте сейчас не будем удаляться от предмета нашего разговора, а именно, systemd-delta.
> В boot sequence с sysv init
> в дебиане отродясь бардак. Да и у других не лучше. Если
> я поменял какой-то стартовый скрипт - новая версия пакета может это
> перетереть при обновлении. А может не перетереть. Последнее что я хочу
> как админ - ковыряться в spec файле и прочих исходниках пакета,
> чтобы узнать как там это на самом деле сделано.
Ну, начну с оффтопика: в debian нету spec-файлов, это rpm-специфичная вещь.
В deb для этого используется специальный файл debian/conffiles, в котором помечаются все конфигурационные файлы. Но в отличие от rpm-ов в Debian для сборки пакетов используется роскошный набор скриптов debhelper, один из которых (dh_installdeb) автоматически помечает все файлы пакета, находящиеся в /etc как конфигурационные, и потому затереть их так просто не выйдет.
Но даже если вам действительно так необходимо подменить какой-либо файл из пакета, и чтобы апдейт этого не убил, всегда есть dpkg-divert. Подменяйте на здоровье. А также по возможности сообщите мейнтейнеру, чтобы он был в курсе, что у пользователя в силу некоторых обстоятельств может возникнуть такая потребность.
> Пакетов много, уделять каждому по столько внимания слишком жирно.
Да и раньше, в общем-то, не приходилось. Может быть Вы расскажете о каком-нибудь случае из Вашей практики?
> С конфигами тоже до некоторой степени бардак. Чтобы дефолтный конфиг мог лежать
> в "майнтайнерской" дире, а админ мог перекрыть его допустим записью в
> /etc/чеготам - требует явной поддержки в программе.
Я что-то не понял: а если использовать systemd, явной поддержки этого "перекрытия" конфигов в самой программе не требуется, что ли?
>> А вот что ещё интересно. При настройке того же postfix в зависимости
>> от назначения сервера предлагаются разные дефолтные мейнтейнерские конфиги.
>> Относительно какой конфигурации дифф смотреть будем?
> Systemd занимается стартовой последовательностью, а не конфигами вообще. Ее или меняли
> относительно того что предложили майнтайнеры, или нет. Вот относительно этого и
> будем смотреть.
У вас какое-то непонимание вопроса. Я вот выше на примере postfix-а вам и объясняю, что предложенная мейнтейнером конфигурация может быть файликом, который генерируется скриптом post-install. И этот скрипт, вообще говоря, может спросить у пользователя много дополнительных параметров, в зависимости от которых будут получены разные "дефолтные мейнтейнерские" конфигурации.
Вот и вопрос: как в этом случае дифф брать? Такое предусмотрено?
> Но для
> конфигов в популярных дистрах штатно пока нет таких инструментариев. Можно поднять
> SCM и все сделать самому. Можно даже написать свою ОС. Но
> это требует времени и не способствует решению изначальной задачи.
И в чём же заключается изначальная задача?
Вообще, существование этого инструмента -- это в некотором роде попытка внедрить в systemd ещё и SCM. Ну, как бы, спасибо, конечно. Но этой SCM ещё надо учиться, и работать она будет только в системах на базе systemd. Почему бы админу не выучить какую-нибудь SCM более общего назначения? Тот же ansible, например?
