В соответствии с написанным в Bug 41444 наверное стоит добавить в зависимости apt-conf-ignore-systemd ?
Вы серьёзно предлагаете иниту добавить зависимость на конфигурацию apt ? $ rpmquery -pR noarch/RPMS/apt-conf-ignore-systemd-0.1-alt2.1.noarch.rpm sysvinit rpmlib(PayloadIsLzma) Для начала вы получите циклическую зависимость. Вы скорее всего хотите сделать метапакет, который вытянет всё что нужно для sysv-специфичной установки. Сам же пакет sysvinit не должен зависеть от apt и его конфигурации.
Я думаю, предложение было в том, чтобы просто запаковать файл /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет sysvinit без каких-либо зависимостей.
(Ответ для Dmitry V. Levin на комментарий #2) > Я думаю, предложение было в том, чтобы просто запаковать файл > /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет > sysvinit без каких-либо зависимостей. В описании речь именно про добавление зависимости на apt-conf-ignore-systemd. Технически нет никаких проблем запаковать этот файл в sysvinit. Но меня смущает, что после этого sysvinit будет невозможно иметь вместе с systemd на одной машине. Причём на уровне конфигурации apt. У самого sysvinit даже нет конфликта на systemd. С одной стороны да и хрен с ним и пусть нельзя держать два инита одновременно, но с другой стороны это будет сделано искусственно т.к. технически ничего не иметь их рядом. Хотим ли мы объявить войну другому иниту ? И ещё вопрос, что будет при обновлении у людей у которых уже стоят sysvinit и systemd ?
(Ответ для Alexey Gladkov на комментарий #3) > (Ответ для Dmitry V. Levin на комментарий #2) > > Я думаю, предложение было в том, чтобы просто запаковать файл > > /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет > > sysvinit без каких-либо зависимостей. > > В описании речь именно про добавление зависимости на apt-conf-ignore-systemd. > > Технически нет никаких проблем запаковать этот файл в sysvinit. Но меня > смущает, что после этого sysvinit будет невозможно иметь вместе с systemd на > одной машине. Причём на уровне конфигурации apt. У самого sysvinit даже нет > конфликта на systemd. > > С одной стороны да и хрен с ним и пусть нельзя держать два инита > одновременно, но с другой стороны это будет сделано искусственно т.к. > технически ничего не иметь их рядом. > > Хотим ли мы объявить войну другому иниту ? > > И ещё вопрос, что будет при обновлении у людей у которых уже стоят sysvinit > и systemd ? Я думаю, что зависимость излишня. Новые сборки с sysvinit я собираю с apt-conf-ignore-systemd. Этого вполне достаточно.
(In reply to Alexey Gladkov from comment #1) > Вы серьёзно предлагаете иниту добавить зависимость на конфигурацию apt ? > > $ rpmquery -pR noarch/RPMS/apt-conf-ignore-systemd-0.1-alt2.1.noarch.rpm > sysvinit > rpmlib(PayloadIsLzma) > > Для начала вы получите циклическую зависимость. Честно говоря, я не проверил зависимости apt-conf-ignore-systemd. Да, циклической зависимости быть не должно, и в apt-conf-ignore-systemd надо тогда убрать Requires: sysvinit. > Вы скорее всего хотите сделать метапакет, который вытянет всё что нужно для > sysv-специфичной установки. Нет, я хочу, чтобы не произошёл такой вот казус: # apt-get dist-upgrade Reading Package Lists... Done Building Dependency Tree... Done Calculating Upgrade... Done The following packages will be upgraded libsystemd libudev1 systemd-sysctl-common systemd-tmpfiles-common systemd-utils-filetriggers systemd-utils-standalone udev The following packages will be REPLACED: systemd-utils (by systemd) The following NEW packages will be installed: acl agetty libnss-myhostname libnss-systemd pam_systemd systemd systemd-boot-efi Вот ни разу не нужно, чтобы в системе с sysvinit вдруг оказался systemd, да ещё с pam_systemd > Сам же пакет sysvinit не должен зависеть от apt и его конфигурации. От apt он конечно зависеть не должен, но вот от некоего пакета, который не зависит от apt, почему бы и нет? (In reply to Dmitry V. Levin from comment #2) > Я думаю, предложение было в том, чтобы просто запаковать файл > /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет > sysvinit без каких-либо зависимостей. Это, в целом, тоже неплохой вариант, если есть возможность обновить sysvinit в p10 и p9. В общем что-то точно сделать надо, а как - вопрос творческий.
(In reply to Sergey Y. Afonin from comment #5) > Вот ни разу не нужно, чтобы в системе с sysvinit вдруг оказался systemd, да > ещё с pam_systemd Если что, при этом сразу отпадает доступ по ssh.
(Ответ для Антон Мидюков на комментарий #4) > Я думаю, что зависимость излишня. Новые сборки с sysvinit я собираю с > apt-conf-ignore-systemd. Этого вполне достаточно. Это будет работать только для новых установок (коммент #c5). (Ответ для Sergey Y. Afonin на комментарий #5) > Нет, я хочу, чтобы не произошёл такой вот казус: > > # apt-get dist-upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > Calculating Upgrade... Done > The following packages will be upgraded > libsystemd libudev1 systemd-sysctl-common systemd-tmpfiles-common > systemd-utils-filetriggers > systemd-utils-standalone udev > The following packages will be REPLACED: > systemd-utils (by systemd) > The following NEW packages will be installed: > acl agetty libnss-myhostname libnss-systemd pam_systemd systemd > systemd-boot-efi > > Вот ни разу не нужно, чтобы в системе с sysvinit вдруг оказался systemd, да > ещё с pam_systemd Вам удалось понять почему к вам приезжают эти пакеты ?
(Ответ для Alexey Gladkov на комментарий #7) > Вам удалось понять почему к вам приезжают эти пакеты ? Пакет systemd теперь провайдит systemd-utils, а systemd-utils-standalone в системе не установлен. Если systemd-utils-standalone установлен, то не приезжает.
(Ответ для Антон Мидюков на комментарий #8) > Пакет systemd теперь провайдит systemd-utils, а systemd-utils-standalone в > системе не установлен. Если systemd-utils-standalone установлен, то не > приезжает. Может просто добавить в sysvinit добавить конфликт на systemd ? Тогда уже установленный sysvinit не даст поставится systemd и наоборот там где systemd нельзя будет случайно поставить sysvinit.
(In reply to Alexey Gladkov from comment #7) > > Вот ни разу не нужно, чтобы в системе с sysvinit вдруг оказался systemd, да > > ещё с pam_systemd > > Вам удалось понять почему к вам приезжают эти пакеты ? Так в исходном сообщении ссылка на баг, из-за которого произошли изменения в упаковке systemd. Исправление того бага вызвало это последствие.
(Ответ для Alexey Gladkov на комментарий #9) > (Ответ для Антон Мидюков на комментарий #8) > > Пакет systemd теперь провайдит systemd-utils, а systemd-utils-standalone в > > системе не установлен. Если systemd-utils-standalone установлен, то не > > приезжает. > > Может просто добавить в sysvinit добавить конфликт на systemd ? > > Тогда уже установленный sysvinit не даст поставится systemd и наоборот там > где systemd нельзя будет случайно поставить sysvinit. Да. Но нужно проверить, что обновление пройдёт правильно. А то вдруг apt предпочтёт вынести sysvinit.
(Ответ для Антон Мидюков на комментарий #11) > Да. Но нужно проверить, что обновление пройдёт правильно. А то вдруг apt > предпочтёт вынести sysvinit. Можете проверить ? Мне подготовить задание ?
(In reply to Dmitry V. Levin from comment #2) > Я думаю, предложение было в том, чтобы просто запаковать файл > /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет > sysvinit без каких-либо зависимостей. Вообще это может быть лучший выход действительно. Кому понадобится systemd при установленном sysvinit просто сделает этот файл пустым. Ну или там закомментирует. И %config(noreplace) соответственно.
(In reply to Антон Мидюков from comment #11) > А то вдруг apt предпочтёт вынести sysvinit. Маловероятно, поскольку sysvinit перечислен в категории Required в файле /etc/apt/pkgpriorities. А если предпочтёт, то обязательно задаст свой сакраментальный вопрос, на который надо будет ответить "Yes, do as I say!".
(In reply to Sergey Y. Afonin from comment #13) > (In reply to Dmitry V. Levin from comment #2) > > > Я думаю, предложение было в том, чтобы просто запаковать файл > > /etc/apt/apt.conf.d/sysvinit-ignore-systemd.conf непосредственно в пакет > > sysvinit без каких-либо зависимостей. > > Вообще это может быть лучший выход действительно. Кому понадобится systemd > при установленном sysvinit просто сделает этот файл пустым. Ну или там > закомментирует. И %config(noreplace) соответственно. Я думаю, после того, что сделали в systemd, одновременная установка больше не сулит ничего хорошего, и лучше честно поставить конфликт в обе стороны.
Ок. Тогда давай определимся. Мы ставим конфликт или кладём конфиг из apt-conf-ignore-systemd или всё вместе ? Мне кажется конфликта будет достаточно.
(Ответ для Alexey Gladkov на комментарий #16) > Ок. Тогда давай определимся. Мы ставим конфликт или кладём конфиг из > apt-conf-ignore-systemd или всё вместе ? > > Мне кажется конфликта будет достаточно. Я тоже считаю, что конфликта достаточно. Задание готов проверить на разных сценариях.
(In reply to Alexey Gladkov from comment #16) > Мне кажется конфликта будет достаточно. Необходимо и достаточно. :)
Ок. В 2.88-alt7 добавлю. А потом нужно обновить пакет. Уже 3.00 вышла. https://git.savannah.nongnu.org/cgit/sysvinit.git/refs/tags
* Thu Dec 16 2021 Alexey Gladkov <legion@altlinux> 2.88-alt7 - Add conflict to systemd to make it impossible to install systemd on a system with sysvinit (ALT#41579). Очередная тестовая пересборка показала, что перестали собираться следующие пакеты: fcitx-libpinyin fcitx-sunpinyin fcitx-table-extra fcitx-table-other fcoe-utils freeipa-healthcheck gem-librarian-puppet kde5-konqueror kf5-kdelibs4support libraft libvirt mozldap perl-Archive-Tar-Wrapper perl-File-Finder perl-POSIX-1003 perl-Test-File plasma5-bluedevil plasma5-browser-integration plasma5-desktop plasma5-disks plasma5-workspace pve-manager pve-storage-linstor rex slapi-nis swtpm
Это изменение вскрыло, то что у нас миры всё-таки не полностью разделены. В итоге в сборочной системе оказываются оба инита. Investigating 389-ds-base Package 389-ds-base has broken dep on /bin/systemctl Considering systemd 2 as a solution to 389-ds-base 2 Holding Back 389-ds-base rather than change /bin/systemctl Investigating libnss-systemd Package libnss-systemd has broken dep on systemd Considering systemd 2 as a solution to libnss-systemd -1 Holding Back libnss-systemd rather than change systemd Investigating startup Package startup has broken dep on /sbin/systemd-modules-load Considering systemd-utils-standalone 0 as a solution to startup -1 Holding Back startup rather than change /sbin/systemd-modules-load Investigating systemd-boot-efi Package systemd-boot-efi has broken dep on systemd Considering systemd 2 as a solution to systemd-boot-efi -1 Holding Back systemd-boot-efi rather than change systemd Investigating systemd-sysctl-common Package systemd-sysctl-common has broken dep on /etc/sysctl.conf Considering startup -1 as a solution to systemd-sysctl-common -1 Holding Back systemd-sysctl-common rather than change /etc/sysctl.conf Investigating 389-ds-base-devel Package 389-ds-base-devel has broken dep on 389-ds-base Considering 389-ds-base 2 as a solution to 389-ds-base-devel 9999 Re-Instated startup Re-Instated libnss-systemd Re-Instated systemd-boot-efi Re-Instated systemd-sysctl-common Re-Instated systemd Re-Instated 389-ds-base Investigating sysvinit Package sysvinit has broken dep on systemd Considering systemd 2 as a solution to sysvinit -1 Holding Back sysvinit rather than change systemd Investigating startup Package startup has broken dep on /sbin/halt Considering systemd-sysvinit 0 as a solution to startup -1 Holding Back startup rather than change /sbin/halt Investigating systemd-sysctl-common Package systemd-sysctl-common has broken dep on /etc/sysctl.conf Considering startup -1 as a solution to systemd-sysctl-common -1 Holding Back systemd-sysctl-common rather than change /etc/sysctl.conf Investigating systemd Package systemd has broken dep on /etc/modules Considering startup -1 as a solution to systemd 2 Holding Back systemd rather than change /etc/modules Investigating 389-ds-base Package 389-ds-base has broken dep on /bin/systemctl Considering systemd 2 as a solution to 389-ds-base 2 Holding Back 389-ds-base rather than change /bin/systemctl Investigating libnss-systemd Package libnss-systemd has broken dep on systemd Considering systemd 2 as a solution to libnss-systemd -1 Holding Back libnss-systemd rather than change systemd Investigating systemd-boot-efi Package systemd-boot-efi has broken dep on systemd Considering systemd 2 as a solution to systemd-boot-efi -1 Holding Back systemd-boot-efi rather than change systemd Investigating 389-ds-base-devel Package 389-ds-base-devel has broken dep on 389-ds-base Considering 389-ds-base 2 as a solution to 389-ds-base-devel 9999 Done
$ rpmquery -pR 389-ds-base-1.4.3.28-alt1.x86_64.rpm |grep -c /bin/systemctl 1
Я думаю, что конфликт должен быть формально именно с pam_systemd, а не с systemd, потому что установка именно пакета pam_systemd, а не systemd, мгновенно превращает систему в тыкву. Сейчас, не смотря на конфликт с systemd, можно установить pam_systemd без systemd в систему на sysvinit.
(Ответ для Dmitry V. Levin на комментарий #23) > Я думаю, что конфликт должен быть формально именно с pam_systemd, а не с > systemd, Ну это уже совсем странно. Это превращает sysvinit в помойку. Неправильно пихать в конфликты sysvinit всё что ломает системы с sysvinit. > потому что установка именно пакета pam_systemd, а не systemd, мгновенно > превращает систему в тыкву. Установка pam_systemd превращает в тыкву систему с sysvinit, а не сам sysvinit. Давай добавим конфликт на pam_systemd в более подходящее место.
(Ответ для Dmitry V. Levin на комментарий #23) > Я думаю, что конфликт должен быть формально именно с pam_systemd, а не с > systemd, > потому что установка именно пакета pam_systemd, а не systemd, мгновенно > превращает систему в тыкву. > > Сейчас, не смотря на конфликт с systemd, можно установить pam_systemd без > systemd в систему на sysvinit. Может сделать pam_systemd частью пакета systemd?
(Ответ для Dmitry V. Levin на комментарий #23) > Сейчас, не смотря на конфликт с systemd, можно установить pam_systemd без > systemd в систему на sysvinit. Я считаю, что ошибка как раз вот в этом. Если pam_systemd превращает в тыкву систему без systemd, то у pam_systemd должна быть на systemd зависимость.
(Ответ для Антон Мидюков на комментарий #25) > Может сделать pam_systemd частью пакета systemd? Или так, или зависимость на systemd, или runtime проверка внутри модуля на возможность присоединится к logind.
В общем, конфликт на systemd в sysvinit появился. Странно почему сборочница не закрыла баг по changelog.
(In reply to Alexey Gladkov from comment #27) > (Ответ для Антон Мидюков на комментарий #25) > > Может сделать pam_systemd частью пакета systemd? > > Или так, или зависимость на systemd, или runtime проверка внутри модуля на > возможность присоединится к logind. Повесил отдельный баг на pam_systemd: https://bugzilla.altlinux.org/41592
Спасибо
