Вы серьёзно предлагаете иниту добавить зависимость на конфигурацию 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

Спасибо