[devel] I: sysvinit vs systemd

[devel] I: sysvinit vs systemd

[Alexey Gladkov]

Привет!

В виду нарастающей несовместимости между системами с sysvinit и systemd.
В sysvinit была добавлена явный конфликт на systemd. Технически они не
конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
это приводит к серьёзным проблемам.

Правда, после этого изменения перестали собираться несколько пакетов:

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

не все пакеты непосредственно виноваты. Например, mozldap не собирается
из-за:

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

То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
по сути является синонимом systemd, что делает эти пакеты systemd-only.

-- 
Rgrds, legion

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 17, 2021 at 01:07:16PM +0100, Alexey Gladkov wrote:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.

Ввиду того, что установка pam_systemd в систему без systemd мгновенно
делает систему нерабочей, и в systemd никак это не исправили.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 17, 2021 at 01:07:16PM +0100, Alexey Gladkov wrote:
[...]
> не все пакеты непосредственно виноваты. Например, mozldap не собирается
> из-за:
> 
> 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
> 
> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> по сути является синонимом systemd, что делает эти пакеты systemd-only.

Но многие сами виноваты, например:

$ rpmquery -Rp Sisyphus/files/SRPMS/perl-Test-File-1.448-alt1.src.rpm |grep libnss-mymachines
libnss-mymachines  


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> это приводит к серьёзным проблемам.
> 
> Правда, после этого изменения перестали собираться несколько пакетов:
А я думаю, как такое могло пройти сборочницу! :-)

[...]
> kde5-konqueror
kde* в процессе task#292102. Я оторвал зависимость, т.к. особо не нужна пока.

[...]

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Alexey Gladkov]

On Fri, Dec 17, 2021 at 03:38:46PM +0300, Sergey V Turchin wrote:
> On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> > Привет!
> > 
> > В виду нарастающей несовместимости между системами с sysvinit и systemd.
> > В sysvinit была добавлена явный конфликт на systemd. Технически они не
> > конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> > это приводит к серьёзным проблемам.
> > 
> > Правда, после этого изменения перестали собираться несколько пакетов:
> А я думаю, как такое могло пройти сборочницу! :-)

Изменение, которое было сделано не делает unmets. Если бы после добавления
пакета у нас происходила полная пересборка всего сизифа, то это изменение
не прошло бы сборочницу.

> [...]
> > kde5-konqueror
> kde* в процессе task#292102. Я оторвал зависимость, т.к. особо не нужна пока.
> 
> [...]
> 
> -- 
> Regards, Sergey.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Rgrds, legion

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Friday, 17 December 2021 15:43:52 MSK Alexey Gladkov wrote:
> On Fri, Dec 17, 2021 at 03:38:46PM +0300, Sergey V Turchin wrote:
> > On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> > > Привет!
> > > 
> > > В виду нарастающей несовместимости между системами с sysvinit и systemd.
> > > В sysvinit была добавлена явный конфликт на systemd. Технически они не
> > > конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> > > это приводит к серьёзным проблемам.
> > 
> > > Правда, после этого изменения перестали собираться несколько пакетов:
> > А я думаю, как такое могло пройти сборочницу! :-)
> 
> Изменение, которое было сделано не делает unmets. Если бы после добавления
> пакета у нас происходила полная пересборка всего сизифа, то это изменение
> не прошло бы сборочницу.
Поэтому я и не врубилися сразу. Provide есть, а сборочница говорит -- хрен 
тебе, нету. :-)
Интересно, пролезет ли в p10 такое.

> 
> > [...]
> > 
> > > kde5-konqueror
> > 
> > kde* в процессе task#292102. Я оторвал зависимость, т.к. особо не нужна
> > пока.
> > 
> > [...]


-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Anton Farygin]

On 17.12.2021 15:56, Sergey V Turchin wrote:
> On Friday, 17 December 2021 15:43:52 MSK Alexey Gladkov wrote:
>> On Fri, Dec 17, 2021 at 03:38:46PM +0300, Sergey V Turchin wrote:
>>> On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
>>>> Привет!
>>>>
>>>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
>>>> В sysvinit была добавлена явный конфликт на systemd. Технически они не
>>>> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
>>>> это приводит к серьёзным проблемам.
>>>> Правда, после этого изменения перестали собираться несколько пакетов:
>>> А я думаю, как такое могло пройти сборочницу! :-)
>> Изменение, которое было сделано не делает unmets. Если бы после добавления
>> пакета у нас происходила полная пересборка всего сизифа, то это изменение
>> не прошло бы сборочницу.
> Поэтому я и не врубилися сразу. Provide есть, а сборочница говорит -- хрен
> тебе, нету. :-)
> Интересно, пролезет ли в p10 такое.
Когда все пакеты починят, то причин не пролезть не останется.

[devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:

[...]
> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> по сути является синонимом systemd, что делает эти пакеты systemd-only.
/bin/systemctl --user
, например, по другому никак не сделать. Соотв. макросов нет.

-- 
Regards, Sergey.

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Dmitry V. Levin]

On Fri, Dec 17, 2021 at 04:07:20PM +0300, Sergey V Turchin wrote:
> On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> 
> [...]
> > То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> > по сути является синонимом systemd, что делает эти пакеты systemd-only.
> /bin/systemctl --user

А /bin зачем?  Полагаете, /bin нет в $PATH?

> , например, по другому никак не сделать. Соотв. макросов нет.

Если отсутствие systemctl --user фатально, значит,
это systemd-only пакет, и всё правильно, только зачем ему тогда sysvinit?

В противном случае надо проверять, есть ли systemctl.
Например, как в пакете service:

SYSTEMCTL=systemctl
...
systemd_status=
systemd_is_active()
{
	if [ -z "$systemd_status" ]; then
		sd_booted && "$SYSTEMCTL" --version >/dev/null 2>&1
		systemd_status=$?
	fi
	return $systemd_status
}

Не обязательно так сложно, это просто пример.


-- 
ldv

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Friday, 17 December 2021 16:22:53 MSK Dmitry V wrote:
> On Fri, Dec 17, 2021 at 04:07:20PM +0300, Sergey V Turchin wrote:
> > On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> > 
> > [...]
> > 
> > > То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> > > по сути является синонимом systemd, что делает эти пакеты systemd-only.
> > 
> > /bin/systemctl --user
> 
> А /bin зачем?  Полагаете, /bin нет в $PATH?
Так точно есть.


> > , например, по другому никак не сделать. Соотв. макросов нет.
> Если отсутствие systemctl --user фатально, значит,
> это systemd-only пакет,
Нет, пока не фатально, поэтому и оторвал. Надо как-то по другому сделать, 
когда понадобится.

> и всё правильно, только зачем ему тогда sysvinit?
Сборочница так решила.
На тестовой системе у меня его нет и всё собирается и работает.

> В противном случае надо проверять, есть ли systemctl.
> Например, как в пакете service:
> 
> SYSTEMCTL=systemctl
> ...
> systemd_status=
> systemd_is_active()
> {
> 	if [ -z "$systemd_status" ]; then
> 		sd_booted && "$SYSTEMCTL" --version >/dev/null 2>&1
> 		systemd_status=$?
> 	fi
> 	return $systemd_status
> }
> 
> Не обязательно так сложно, это просто пример.
Спасибо! Я к тому, что готового сейчас нет. Не реализовано пока никем.

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Friday, 17 December 2021 15:57:27 MSK Anton Farygin wrote:

[...]
> > Поэтому я и не врубилися сразу. Provide есть, а сборочница говорит -- хрен
> > тебе, нету. :-)
> > Интересно, пролезет ли в p10 такое.
> Когда все пакеты починят, то причин не пролезть не останется.
Но он же наверняка до этого попытается.

-- 
Regards, Sergey.

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Dmitry V. Levin]

On Fri, Dec 17, 2021 at 04:35:54PM +0300, Sergey V Turchin wrote:
[...]
> > В противном случае надо проверять, есть ли systemctl.
> > Например, как в пакете service:
> > 
> > SYSTEMCTL=systemctl
> > ...
> > systemd_status=
> > systemd_is_active()
> > {
> > 	if [ -z "$systemd_status" ]; then
> > 		sd_booted && "$SYSTEMCTL" --version >/dev/null 2>&1
> > 		systemd_status=$?
> > 	fi
> > 	return $systemd_status
> > }
> > 
> > Не обязательно так сложно, это просто пример.
> Спасибо! Я к тому, что готового сейчас нет. Не реализовано пока никем.

Я пока не вижу универсального варианта.  Большей части пользователей
systemctl на самом деле нужен какой-то макрос, реализуемый пакетом
service, но кому-то действительно нужен именно systemctl с зависимостью
на systemd.  Непонятно, пригодится ли, например, какой-нибудь враппер
try_systemctl, который запустит systemctl, если он есть, и вернёт 0,
если systemctl нет?


-- 
ldv

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Alexey V. Vissarionov]

On 2021-12-17 21:52:35 +0300, Dmitry V. Levin wrote:

 >>> В противном случае надо проверять, есть ли systemctl.
 >>> Например, как в пакете service
 >> Спасибо! Я к тому, что готового сейчас нет. Не реализовано
 >> пока никем.
 > Я пока не вижу универсального варианта. Большей части
 > пользователей systemctl на самом деле нужен какой-то макрос,
 > реализуемый пакетом service, но кому-то действительно нужен
 > именно systemctl с зависимостью на systemd.

А кому и зачем? Причем не вообще, а именно в пакете, который
по идее должен ставиться одинаково независимо от используемой
системы инициализации.

 > Непонятно, пригодится ли, например, какой-нибудь враппер
 > try_systemctl, который запустит systemctl, если он есть,
 > и вернёт 0, если systemctl нет?

Никакого смысла.

Более правильным мне видится вариант, когда возможные отличия
в работе ПО с разными системами инициализации проявляются не
при установке, а уже при запуске. Максимум, что можно сделать
в %post - рассказать системе инициализации о появлении нового
демона, да и то не всегда. В единичных случаях (мне известен
единственный пример: service sshd keygen) может понадобиться
что-то еще, но это совсем экзотика, и перед ее использованием
надо очень хорошо подумать.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Friday, 17 December 2021 21:52:35 MSK Dmitry V wrote:

[...]
> Я пока не вижу универсального варианта.  Большей части пользователей
> systemctl на самом деле нужен какой-то макрос, реализуемый пакетом
> service, но кому-то действительно нужен именно systemctl с зависимостью
> на systemd.  Непонятно, пригодится ли, например, какой-нибудь враппер
> try_systemctl, который запустит systemctl, если он есть, и вернёт 0,
> если systemctl нет?
Скорее всего всё-таки `systemctl --user` мне не нужно и получится делать через 
файлтриггеры и systemd/user-preset, типа как сейчас системные сервисы.

Единственное, в другом месте нужно включать запуск пользовательской сессии по 
старой схеме или через systemd. Это может быть специфичный для DE/сессии 
костыль. Один на каждую.

-- 
Regards, Sergey.

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Friday, 17 December 2021 23:14:58 MSK Alexey V wrote:

[...]
> в пакете, который
> по идее должен ставиться одинаково независимо от используемой
> системы инициализации.
Так дойдёшь до беспроблемной перезагрузки между sysvinit и systemd ;-)

> Более правильным мне видится вариант, когда возможные отличия
> в работе ПО с разными системами инициализации проявляются не
> при установке, а уже при запуске.
Мне тоже. См. выше.

[...]


-- 
Regards, Sergey.

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Saturday, 18 December 2021 03:15:16 MSK Sergey V wrote:

> [...]
> > в пакете, который
> > по идее должен ставиться одинаково независимо от используемой
> > системы инициализации.
> Так дойдёшь до беспроблемной перезагрузки между sysvinit и systemd ;-)
Кстати, делов-то! Переписать service и /etc/rc.d/rc для работы с только 
systemd-шными юнитами и дело в шляпе. ;-)

> > Более правильным мне видится вариант, когда возможные отличия
> > в работе ПО с разными системами инициализации проявляются не
> > при установке, а уже при запуске.
> Мне тоже. См. выше.
> [...]


-- 
Regards, Sergey.

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Alexey V. Vissarionov]

On 2021-12-18 16:22:26 +0300, Sergey V Turchin wrote:

 >>> в пакете, который по идее должен ставиться одинаково
 >>> независимо от используемой системы инициализации.
 >> Так дойдёшь до беспроблемной перезагрузки между sysvinit
 >> и systemd ;-)

А зачем? Проще вообще не использовать systemd.

 > Кстати, делов-то! Переписать service и /etc/rc.d/rc для
 > работы с только systemd-шными юнитами и дело в шляпе. ;-)

Опять же, зачем? Даже если по какой-то причине приходится
использовать systemd, он уже никуда не денется от поддержки
init-скриптов, которая там давно есть.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm-macro systemctl --user (was: sysvinit vs systemd)

[Sergey V Turchin]

On Saturday, 18 December 2021 21:07:00 MSK Alexey V wrote:
> On 2021-12-18 16:22:26 +0300, Sergey V Turchin wrote:
>  >>> в пакете, который по идее должен ставиться одинаково
>  >>> независимо от используемой системы инициализации.
>  >> 
>  >> Так дойдёшь до беспроблемной перезагрузки между sysvinit
>  >> и systemd ;-)
> А зачем? Проще вообще не использовать systemd.
Проще вообще ничего не использовать, а болтать языком.

>  > Кстати, делов-то! Переписать service и /etc/rc.d/rc для
>  > работы с только systemd-шными юнитами и дело в шляпе. ;-)
> Опять же, зачем? Даже если по какой-то причине приходится
> использовать systemd, он уже никуда не денется от поддержки
> init-скриптов, которая там давно есть.
Не давно есть, а давно пора выбрасывать вместе со всеми init-скриптами.

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Stanislav Levin]

[-- Attachment #1.1: Type: text/plain, Size: 2071 bytes --]



17.12.2021 15:07, Alexey Gladkov пишет:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> это приводит к серьёзным проблемам.
> 
> Правда, после этого изменения перестали собираться несколько пакетов:
> 
> 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
> 
> не все пакеты непосредственно виноваты. Например, mozldap не собирается
> из-за:
> 
> 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
> 
> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> по сути является синонимом systemd, что делает эти пакеты systemd-only.
> 

Добрый день.
На примере 389-ds-base, у которого в preun скриплете используется
незамаскированный /bin/systemctl. Считаю это легитимной конфигурацией,
когда какой-либо сервис работает *только* с systemd. Но по факту в
сегодняшнем сизифе все клиенты *systemd-only* пакетов будут страдать от
неопределенности в установке (порядок, веса, тд), например:

https://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/1220/error/slapi-nis-0.56.7-alt2

К слову `hsh-install systemd-sysvinit 389-ds-base` в отличие от
`hsh-install 389-ds-base` уже отрабатывает на голом hasher.

Ожидаю, что будет предложено убрать strictness на /bin/systemctl, но это
не отменяет того факта, что установка *systemd-only* пакетов в полной
мере не поддерживается.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [devel] I: sysvinit vs systemd

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

Добрый день!

On Mon, 20 Dec 2021 11:29:01 +0300 Stanislav Levin wrote:
> 17.12.2021 15:07, Alexey Gladkov пишет:
> > не все пакеты непосредственно виноваты. Например, mozldap не собирается
> > из-за:
> > 
> > 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
> > 
> > То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> > по сути является синонимом systemd, что делает эти пакеты systemd-only.
> > 
> 
> Добрый день.
> На примере 389-ds-base, у которого в preun скриплете используется
> незамаскированный /bin/systemctl. Считаю это легитимной конфигурацией,
> когда какой-либо сервис работает *только* с systemd.

С какой это стати 389-ds-base только с systemd может работать?
Там в Makefile.am спокойно задаётся:
WITH_SYSTEMD = 0

так что это вопрос сборки и упаковки.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: sysvinit vs systemd

[Stanislav Levin]

[-- Attachment #1.1: Type: text/plain, Size: 1348 bytes --]



20.12.2021 11:39, Andrey Savchenko пишет:
> Добрый день!
> 
> On Mon, 20 Dec 2021 11:29:01 +0300 Stanislav Levin wrote:
>> 17.12.2021 15:07, Alexey Gladkov пишет:
>>> не все пакеты непосредственно виноваты. Например, mozldap не собирается
>>> из-за:
>>>
>>> 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
>>>
>>> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
>>> по сути является синонимом systemd, что делает эти пакеты systemd-only.
>>>
>>
>> Добрый день.
>> На примере 389-ds-base, у которого в preun скриплете используется
>> незамаскированный /bin/systemctl. Считаю это легитимной конфигурацией,
>> когда какой-либо сервис работает *только* с systemd.
> 
> С какой это стати 389-ds-base только с systemd может работать?
> Там в Makefile.am спокойно задаётся:
> WITH_SYSTEMD = 0
> 
> так что это вопрос сборки и упаковки.
> 
> Best regards,
> Andrew Savchenko
> 

Пожалуйста, соблюдайте деловой стиль переписки.

Это офтопик. Сущность вопроса в другом.

Но я все же отвечу на этот выпад - то, что там указано, совершенно не
означает, что это именно так. Апстрим уже давно не поддерживает не
systemd, но хранит у себя в репозитории init скрипты.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [devel] I: sysvinit vs systemd

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

On Mon, 20 Dec 2021 11:48:31 +0300 Stanislav Levin wrote:
> 
> 
> 20.12.2021 11:39, Andrey Savchenko пишет:
> > Добрый день!
> > 
> > On Mon, 20 Dec 2021 11:29:01 +0300 Stanislav Levin wrote:
> >> 17.12.2021 15:07, Alexey Gladkov пишет:
> >>> не все пакеты непосредственно виноваты. Например, mozldap не собирается
> >>> из-за:
> >>>
> >>> 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
> >>>
> >>> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> >>> по сути является синонимом systemd, что делает эти пакеты systemd-only.
> >>>
> >>
> >> Добрый день.
> >> На примере 389-ds-base, у которого в preun скриплете используется
> >> незамаскированный /bin/systemctl. Считаю это легитимной конфигурацией,
> >> когда какой-либо сервис работает *только* с systemd.
> > 
> > С какой это стати 389-ds-base только с systemd может работать?
> > Там в Makefile.am спокойно задаётся:
> > WITH_SYSTEMD = 0
> > 
> > так что это вопрос сборки и упаковки.
> > 
> > Best regards,
> > Andrew Savchenko
> > 
> 
> Пожалуйста, соблюдайте деловой стиль переписки.
>
> Это офтопик. Сущность вопроса в другом.

Сущность вопроса в жёсткой завязке пакетов на systemd, чего не
должно быть, кроме компонент самого systemd.
 
> Но я все же отвечу на этот выпад - то, что там указано, совершенно не
> означает, что это именно так. Апстрим уже давно не поддерживает не
> systemd, но хранит у себя в репозитории init скрипты.
 
Это не выпад, а указание на некорректную фактологию с Вашей стороны.
В ряде дистрибутивов эта функциональность вполне себе
поддерживается.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] всё как в апстрме

[Dmitry V. Levin]

On Mon, Dec 20, 2021 at 11:48:31AM +0300, Stanislav Levin wrote:
[...]
> Но я все же отвечу на этот выпад - то, что там указано, совершенно не
> означает, что это именно так. Апстрим уже давно не поддерживает не
> systemd, но хранит у себя в репозитории init скрипты.

Не понимаю, откуда такая мода повелась делать всё как в апстриме.
Если вы и есть апстрим, тогда понятно.  Но если нет, то нет.
Апстрим - это конкретные люди, у которых определённые интересы,
и они далеко не всегда совпадают с вашими.

Если бы мы стремились делать всё так, как сделано в апстриме,
то ALT даже не появился бы на свет.


-- 
ldv

Re: [devel] всё как в апстрме

[Anton Farygin]

On 20.12.2021 18:25, Dmitry V. Levin wrote:
> On Mon, Dec 20, 2021 at 11:48:31AM +0300, Stanislav Levin wrote:
> [...]
>> Но я все же отвечу на этот выпад - то, что там указано, совершенно не
>> означает, что это именно так. Апстрим уже давно не поддерживает не
>> systemd, но хранит у себя в репозитории init скрипты.
> Не понимаю, откуда такая мода повелась делать всё как в апстриме.
> Если вы и есть апстрим, тогда понятно.  Но если нет, то нет.
> Апстрим - это конкретные люди, у которых определённые интересы,
> и они далеко не всегда совпадают с вашими.
>
> Если бы мы стремились делать всё так, как сделано в апстриме,
> то ALT даже не появился бы на свет.
>
>
В данном случае отсутствие support'а в апстриме означает то, что эта 
конфигурация никем не тестируется.

А тратить заметные ресурсы на совместимость с sysvinit, на котором у 
компании, в которой работает Стас, нету никаких продуктов - не имеет 
никакого объяснимого смысла.

Я в таком случае с удовольствием принимаю патчи, но ничего не гарантирую.

Re: [devel] всё как в апстрме

[Dmitry V. Levin]

On Mon, Dec 20, 2021 at 07:16:21PM +0300, Anton Farygin wrote:
[...]
> Я в таком случае с удовольствием принимаю патчи, но ничего не гарантирую.

Здесь у нас никто ничего не гарантирует, поскольку this software is
distributed in the hope that it will be useful, but without any warranty;
without even the implied warranty of merchantability or fitness for
a particular purpose.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Paul Wolneykien]

В Fri, 17 Dec 2021 13:07:16 +0100
Alexey Gladkov <legion@altlinux.ru> пишет:

> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и
> systemd. В sysvinit была добавлена явный конфликт на systemd.
> Технически они не конфликтуют, но без него в системы с sysvinit
> иногда попадает systemd и это приводит к серьёзным проблемам.
> 
> Правда, после этого изменения перестали собираться несколько пакетов:

  У меня теперь install-check не проходит. Это как-то связано с новым
конфликтом?


> 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
> 
> не все пакеты непосредственно виноваты. Например, mozldap не
> собирается из-за:
> 
> 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
> 
> То есть некоторые пакеты из зависимостей хотят /bin/systemctl, который
> по сути является синонимом systemd, что делает эти пакеты
> systemd-only.
> 

Re: [devel] I: sysvinit vs systemd

[Paul Wolneykien]

В Tue, 21 Dec 2021 15:45:19 +0300
Paul Wolneykien <manowar@altlinux.org> пишет:

> В Fri, 17 Dec 2021 13:07:16 +0100
> Alexey Gladkov <legion@altlinux.ru> пишет:
> 
> > Привет!
> > 
> > В виду нарастающей несовместимости между системами с sysvinit и
> > systemd. В sysvinit была добавлена явный конфликт на systemd.
> > Технически они не конфликтуют, но без него в системы с sysvinit
> > иногда попадает systemd и это приводит к серьёзным проблемам.
> > 
> > Правда, после этого изменения перестали собираться несколько
> > пакетов:  
> 
>   У меня теперь install-check не проходит. Это как-то связано с новым
> конфликтом?

  Извиняюсь, ссылку не вставил:

    https://git.altlinux.org/tasks/292393/logs/events.1.1.log


> > 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
> > 
> > не все пакеты непосредственно виноваты. Например, mozldap не
> > собирается из-за:
> > 
> > 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
> > 
> > То есть некоторые пакеты из зависимостей хотят /bin/systemctl,
> > который по сути является синонимом systemd, что делает эти пакеты
> > systemd-only.
> >   
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: sysvinit vs systemd

[Anton Farygin]

On 21.12.2021 15:46, Paul Wolneykien wrote:
> В Tue, 21 Dec 2021 15:45:19 +0300
> Paul Wolneykien<manowar@altlinux.org>  пишет:
>
>> В Fri, 17 Dec 2021 13:07:16 +0100
>> Alexey Gladkov<legion@altlinux.ru>  пишет:
>>
>>> Привет!
>>>
>>> В виду нарастающей несовместимости между системами с sysvinit и
>>> systemd. В sysvinit была добавлена явный конфликт на systemd.
>>> Технически они не конфликтуют, но без него в системы с sysvinit
>>> иногда попадает systemd и это приводит к серьёзным проблемам.
>>>
>>> Правда, после этого изменения перестали собираться несколько
>>> пакетов:
>>    У меня теперь install-check не проходит. Это как-то связано с новым
>> конфликтом?
>    Извиняюсь, ссылку не вставил:
>
>      https://git.altlinux.org/tasks/292393/logs/events.1.1.log
>
>
У меня тоже не проходил, я сейчас в apache замаскировал вызов /bin/systemctl

В результате этого конфликта теперь нельзя делать зависимостей на systemd.

Re: [devel] I: sysvinit vs systemd

[Alexey Shabalin]

пт, 17 дек. 2021 г. в 15:09, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Dec 17, 2021 at 01:07:16PM +0100, Alexey Gladkov wrote:
> > Привет!
> >
> > В виду нарастающей несовместимости между системами с sysvinit и systemd.
>
> Ввиду того, что установка pam_systemd в систему без systemd мгновенно
> делает систему нерабочей, и в systemd никак это не исправили.

Не подтверждаю.
У меня не получилось воспроизвести эту проблему.
Взял alt-p10-server-sysv-20211212-x86_64.iso, доустановил в него pam_systemd.
Все работает, login без проблем. ssh тоже.
Обновил до sisyphus - тоже не вызвало никаких проблем с логином.
Как можно воспроизвести проблему?



-- 
Alexey Shabalin

Re: [devel] I: sysvinit vs systemd

[Антон Мидюков]

22.12.2021 00:25, Alexey Shabalin пишет:
> пт, 17 дек. 2021 г. в 15:09, Dmitry V. Levin <ldv@altlinux.org>:
>>
>> On Fri, Dec 17, 2021 at 01:07:16PM +0100, Alexey Gladkov wrote:
>>> Привет!
>>>
>>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
>>
>> Ввиду того, что установка pam_systemd в систему без systemd мгновенно
>> делает систему нерабочей, и в systemd никак это не исправили.
> 
> Не подтверждаю.
> У меня не получилось воспроизвести эту проблему.
> Взял alt-p10-server-sysv-20211212-x86_64.iso, доустановил в него pam_systemd.
> Все работает, login без проблем. ssh тоже.
> Обновил до sisyphus - тоже не вызвало никаких проблем с логином.
> Как можно воспроизвести проблему?
> 

Без проблем обычным пользователем?

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: sysvinit vs systemd

[Sergey Y. Afonin]

On Tuesday 21 December 2021, Alexey Shabalin wrote:

> Да, без проблем обычным пользователем.
 
У меня товарищ нарвался в OpenVZ-контейнере. Хорошо, что контйнер, и хорошо,
что у меня доступ в хостсистему. Удаление  pam_systemd помогло, но там не
только pam_systemd удалился следом, может и не только в нём дело. Потом тему
в sisyphus@lists увидел "Проблема с обновлением на системах с sysvinit", и
себе сразу везде понаставил apt-conf-ignore-systemd. Над воспроизведением не
думал пока.

-- 
С уважением, Сергей Афонин

Re: [devel] I: sysvinit vs systemd

[Антон Мидюков]

17.12.2021 19:07, Alexey Gladkov пишет:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> это приводит к серьёзным проблемам.

Проблема скорее в том, что в hasher попадает sysvinit. А попадает он туда
через треугольник systemd-utils-standalone - startup - systemd-sysctl-common.
Эти пакеты вытягивают друг друга и sysvinit.
startup тянется другими пакетами из-за конфигов, которые в нём.
Можете попробовать установить в только что инициализированный hasher.
А вот как они вытягивают sysvinit, я что-то не пойму. Наверное, это startup.

# rpm -q --requires startup
chkconfig
gawk
grep
sed >= 1:4.1.1
findutils >= 0:4.0.33
mount >= 0:2.10q-ipl1mdk
procps >= 0:2.0.7-ipl5mdk
psmisc >= 0:19-ipl2mdk
util-linux >= 0:2.10q-ipl1mdk
service >= 0.5.32
filesystem >= 0:2.1.7-alt1
hwclock >= 1:2.14-alt1
sysvinit-utils
/sbin/fsck
/sbin/systemd-modules-load
/sbin/systemd-sysctl
/sbin/systemd-tmpfiles
/bin/sh
/bin/sh
/etc/rc.d/init.d
/etc/rc.d/init.d(ExecIfExecutable)
/etc/rc.d/init.d(SourceIfNotEmpty)
/etc/rc.d/init.d(UnmountFilesystems)
/etc/rc.d/init.d(echo_failure)
/etc/rc.d/init.d(echo_passed)
/etc/rc.d/init.d(echo_success)
/etc/rc.d/init.d(is_no)
/etc/rc.d/init.d(is_yes)
/etc/rc.d/init.d(msg_usage)
/etc/rc.d/init.d/functions
/sbin/halt
/sbin/initlog
/sbin/reboot
/sbin/shutdown
/sbin/telinit
coreutils
grep
msulogin
sed
service
shadow-utils
termutils
coreutils
/sbin/chkconfig


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: sysvinit vs systemd

[Leonid Krivoshein]

21.12.2021 22:32, Антон Мидюков пишет:
> 17.12.2021 19:07, Alexey Gladkov пишет:
>> Привет!
>>
>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
>> В sysvinit была добавлена явный конфликт на systemd. Технически они не
>> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
>> это приводит к серьёзным проблемам.
> Проблема скорее в том, что в hasher попадает sysvinit. А попадает он туда
> через треугольник systemd-utils-standalone - startup - systemd-sysctl-common.
> Эти пакеты вытягивают друг друга и sysvinit.
> startup тянется другими пакетами из-за конфигов, которые в нём.
> Можете попробовать установить в только что инициализированный hasher.
> А вот как они вытягивают sysvinit, я что-то не пойму. Наверное, это startup.

От startup раньше зависел interactive-basesystem, теперь нет. Но раз его 
убрали из зависимостей, кому-то это могло что-то поломать, так что с 
марта 2021 startup могли добавить куда-то ещё.

А можешь показать cat /etc/apt/pkgpriorities ? Этот файл ведь не 
установщик может создавать, его могли бы определять конфликтующие иниты, 
каждый по-своему. Потому что многие инитные зависимости виртуальные, и 
при обновлении начинается качание весов. Можно оставить его в 
apt-conf-branch для всех решений, а для пользователей sysvinit 
переместить в инитный пакет.


> # rpm -q --requires startup
> chkconfig
> gawk
> grep
> sed >= 1:4.1.1
> findutils >= 0:4.0.33
> mount >= 0:2.10q-ipl1mdk
> procps >= 0:2.0.7-ipl5mdk
> psmisc >= 0:19-ipl2mdk
> util-linux >= 0:2.10q-ipl1mdk
> service >= 0.5.32
> filesystem >= 0:2.1.7-alt1
> hwclock >= 1:2.14-alt1
> sysvinit-utils
> /sbin/fsck
> /sbin/systemd-modules-load
> /sbin/systemd-sysctl
> /sbin/systemd-tmpfiles
> /bin/sh
> /bin/sh
> /etc/rc.d/init.d
> /etc/rc.d/init.d(ExecIfExecutable)
> /etc/rc.d/init.d(SourceIfNotEmpty)
> /etc/rc.d/init.d(UnmountFilesystems)
> /etc/rc.d/init.d(echo_failure)
> /etc/rc.d/init.d(echo_passed)
> /etc/rc.d/init.d(echo_success)
> /etc/rc.d/init.d(is_no)
> /etc/rc.d/init.d(is_yes)
> /etc/rc.d/init.d(msg_usage)
> /etc/rc.d/init.d/functions
> /sbin/halt
> /sbin/initlog
> /sbin/reboot
> /sbin/shutdown
> /sbin/telinit
> coreutils
> grep
> msulogin
> sed
> service
> shadow-utils
> termutils
> coreutils
> /sbin/chkconfig

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] I: sysvinit vs systemd

[Leonid Krivoshein]

21.12.2021 23:06, Leonid Krivoshein пишет:
> А можешь показать cat /etc/apt/pkgpriorities ?

А может ли сие как-то влиять на возникшую ситуацию:
https://git.altlinux.org/gears/a/apt-conf-branch.git?p=apt-conf-branch.git;a=commitdiff;h=3a13a9969d7cf7246e38923221d24c98470e774f


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] I: sysvinit vs systemd

[Антон Мидюков]

22.12.2021 00:31, Alexey Shabalin пишет:
> вт, 21 дек. 2021 г., 20:28 Антон Мидюков <midyukov-anton@ya.ru>:
> 
>> 22.12.2021 00:25, Alexey Shabalin пишет:
>>> пт, 17 дек. 2021 г. в 15:09, Dmitry V. Levin <ldv@altlinux.org>:
>>>>
>>>> On Fri, Dec 17, 2021 at 01:07:16PM +0100, Alexey Gladkov wrote:
>>>>> Привет!
>>>>>
>>>>> В виду нарастающей несовместимости между системами с sysvinit и
>> systemd.
>>>>
>>>> Ввиду того, что установка pam_systemd в систему без systemd мгновенно
>>>> делает систему нерабочей, и в systemd никак это не исправили.
>>>
>>> Не подтверждаю.
>>> У меня не получилось воспроизвести эту проблему.
>>> Взял alt-p10-server-sysv-20211212-x86_64.iso, доустановил в него
>> pam_systemd.
>>> Все работает, login без проблем. ssh тоже.
>>> Обновил до sisyphus - тоже не вызвало никаких проблем с логином.
>>> Как можно воспроизвести проблему?
>>>
>>
>> Без проблем обычным пользователем?
>>
> 
> Да, без проблем обычным пользователем.
> 

Перепроверил. Действительно так. Проблема возникает при установке systemd.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: sysvinit vs systemd

[Антон Мидюков]

22.12.2021 03:06, Leonid Krivoshein пишет:
> 
> 21.12.2021 22:32, Антон Мидюков пишет:
>> 17.12.2021 19:07, Alexey Gladkov пишет:
>>> Привет!
>>>
>>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
>>> В sysvinit была добавлена явный конфликт на systemd. Технически они не
>>> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
>>> это приводит к серьёзным проблемам.
>> Проблема скорее в том, что в hasher попадает sysvinit. А попадает он туда
>> через треугольник systemd-utils-standalone - startup - systemd-sysctl-common.
>> Эти пакеты вытягивают друг друга и sysvinit.
>> startup тянется другими пакетами из-за конфигов, которые в нём.
>> Можете попробовать установить в только что инициализированный hasher.
>> А вот как они вытягивают sysvinit, я что-то не пойму. Наверное, это startup.
> 
> От startup раньше зависел interactive-basesystem, теперь нет. Но раз его убрали из зависимостей, кому-то это могло что-то поломать, так что с марта 2021 startup могли добавить куда-то ещё.
> 
> А можешь показать cat /etc/apt/pkgpriorities ? Этот файл ведь не установщик может создавать, его могли бы определять конфликтующие иниты, каждый по-своему. Потому что многие инитные зависимости виртуальные, и при обновлении начинается качание весов. Можно оставить его в apt-conf-branch для всех решений, а для пользователей sysvinit переместить в инитный пакет.
> 

Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо sysvinit, либо systemd-sysvinit.
Исправив startup, починим сборку пакетов.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Wednesday, 22 December 2021 07:33:12 MSK Антон Мидюков wrote:

[...]
> Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо
> sysvinit, либо systemd-sysvinit. Исправив startup, починим сборку пакетов.
И даже #292430 ?

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Антон Мидюков]

22.12.2021 17:14, Sergey V Turchin пишет:
> On Wednesday, 22 December 2021 07:33:12 MSK Антон Мидюков wrote:
> 
> [...]
>> Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо
>> sysvinit, либо systemd-sysvinit. Исправив startup, починим сборку пакетов.
> И даже #292430 ?
> 

Да. Увидев это задание и начал расследование. Оказалось, что также в пустой hasher нельзя
установить alterator-setup, alterator-datetime и, видимо, многие другие пакеты.

Для alterator-datetime apt строит такой граф:

MI2a: mark alterator-datetime
MI2a:  target alterator
MI2a:   mark alterator
MI2a:    target alterator-l10n
MI2a:     mark alterator-l10n
MI2a:    target alterator-sh-functions
MI2a:     mark alterator-sh-functions
MI2a:    target alterator-lookout
MI2a:     mark alterator-lookout
MI2a:    target libguile-vhttpd
MI2a:     mark libguile-vhttpd
MI2a:      target libguile-2.2.so.1()(64bit)
MI2a:       mark guile22
MI2a:        target libgc.so.1()(64bit)
MI2a:         mark libgc
MI2a:        target libltdl.so.7()(64bit)
MI2a:         mark libltdl7
MI2a:      target libvhttpd
MI2a:       mark libvhttpd
MI2a:        target libssl.so.1.1()(64bit)
MI2a:         mark libssl1.1
MI2a:          target libcrypto1.1
MI2a:           mark libcrypto1.1
MI2a:            target ca-certificates
MI2a:             mark ca-certificates
MI2a:              target ca-trust
MI2a:               mark ca-trust
MI2a:                target p11-kit-trust
MI2a:                 mark p11-kit-trust
MI2a:                  target /etc/alternatives/packages.d
MI2a:                   mark alternatives
MI2a:                    target rpm-macros-alternatives
MI2a:                     mark rpm-macros-alternatives
MI2a:                  target libtasn1.so.6()(64bit)
MI2a:                   mark libtasn1
MI2a:                  target libp11-kit
MI2a:                   mark libp11-kit
MI2a:    target /usr/bin/guile
MI2a:     mark guile
MI2a:    target rpm-macros-alterator
MI2a:     mark rpm-macros-alterator
MI2a:  target alterator-service-functions
MI2a:   mark alterator-service-functions
MI2a:  target ntp-server AMB
MI2a:  target /etc/rc.d/init.d/clock
MI2a:   mark startup
MI2a:    target mount
MI2a:     mark mount
MI2a:    target hwclock
MI2a:     mark hwclock
MI2a:    target /sbin/systemd-modules-load AMB
MI2a:    target /sbin/systemd-sysctl AMB
MI2a:    target /sbin/systemd-tmpfiles AMB
MI2a:    target /sbin/halt AMB
MI2a:    target /sbin/reboot AMB
MI2a:    target /sbin/shutdown AMB
MI2a:    target /sbin/telinit AMB
MI2a:    target msulogin
MI2a:     mark msulogin
MI2a:  target curl
MI2a:   mark curl
MI2a:    target libcurl
MI2a:     mark libcurl
MI2a:      target libbrotlidec.so.1()(64bit)
MI2a:       mark libbrotlidec
MI2a:        target libbrotlicommon
MI2a:         mark libbrotlicommon
MI2a:      target libgssapi_krb5.so.2()(64bit)
MI2a:       mark libkrb5
MI2a:        target libcom_err.so.2()(64bit)
MI2a:         mark libcom_err
MI2a:        target libkeyutils.so.1()(64bit)
MI2a:         mark libkeyutils
MI2a:        target liblmdb.so.0()(64bit)
MI2a:         mark liblmdb
MI2a:        target libverto.so.1()(64bit)
MI2a:         mark libverto
MI2a:      target libidn2.so.0()(64bit)
MI2a:       mark libidn2
MI2a:      target liblber-2.4.so.2()(64bit)
MI2a:       mark libldap
MI2a:        target libsasl2.so.3()(64bit)
MI2a:         mark libsasl2-3
MI2a:        target openldap-common
MI2a:         mark openldap-common
MI2a:      target libnghttp2.so.14()(64bit)
MI2a:       mark libnghttp2
MI2a:      target libpsl.so.5()(64bit)
MI2a:       mark libpsl
MI2a:        target publicsuffix-list-dafsa
MI2a:         mark publicsuffix-list-dafsa
MI2a:  target iproute2
MI2a:   mark iproute2
MI2a:    target iputils
MI2a:     mark iputils
MI2a:      target /var/resolv
MI2a:       mark chrooted-resolv
MI2a:        target /etc/chroot.d
MI2a:         mark chrooted
MI2a:    target libatm.so.1()(64bit)
MI2a:     mark libatm
MI2a:    target libmnl.so.0()(64bit)
MI2a:     mark libmnl
MI2a:    target libxtables.so.12()(64bit)
MI2a:     mark libiptables
MI2a:    target libnetlink
MI2a:     mark libnetlink
MI2a:  target kmod
MI2a:   mark kmod
MI2a:    target libkmod
MI2a:     mark libkmod
MI2b: mark alterator-datetime
MI2b:  target ntp-server AMB
MI2b: mark startup
MI2b:  target /sbin/systemd-modules-load AMB
MI2b:  target /sbin/systemd-sysctl AMB
MI2b:  target /sbin/systemd-tmpfiles AMB
MI2b:  target /sbin/halt AMB
MI2b:  target /sbin/reboot AMB
MI2b:  target /sbin/shutdown AMB
MI2b:  target /sbin/telinit AMB
MI2c: mark alterator-datetime
MI2c:  target ntp-server
MI2c:   mark systemd-timesyncd
MI2c:    target systemd-networkd
MI2c:     mark systemd-networkd
MI2c:      target libgnutls.so.30()(64bit)
MI2c:       mark libgnutls30
MI2c:        target libhogweed.so.6()(64bit)
MI2c:         mark libhogweed6
MI2c:          target libnettle8
MI2c:           mark libnettle8
MI2c:      target systemd
MI2c:       mark systemd
MI2c:        target agetty
MI2c:         mark agetty
MI2c:          target login
MI2c:           mark login
MI2c:        target acl
MI2c:         mark acl
MI2c:        target libcryptsetup.so.12()(64bit)
MI2c:         mark libcryptsetup
MI2c:          target libargon2.so.1()(64bit)
MI2c:           mark libargon2
MI2c:          target libdevmapper.so.1.02()(64bit)
MI2c:           mark libdevmapper
MI2c:          target libjson-c.so.5()(64bit)
MI2c:           mark libjson-c5
MI2c:        target libfdisk.so.1()(64bit)
MI2c:         mark libfdisk
MI2c:        target liblz4.so.1()(64bit)
MI2c:         mark liblz4
MI2c:        target libnss-systemd
MI2c:         mark libnss-systemd
MI2c:        target libnss-myhostname
MI2c:         mark libnss-myhostname
MI2c:        target pam_systemd
MI2c:         mark pam_systemd
MI2c:          target dbus
MI2c:           mark dbus
MI2c:            target libexpat.so.1()(64bit)
MI2c:             mark libexpat
MI2c:            target libsystemd.so.0()(64bit)
MI2c:             mark libsystemd
MI2c:            target dbus-tools
MI2c:             mark dbus-tools
MI2c:              target libdbus
MI2c:               mark libdbus
MI2c:        target systemd-boot-efi
MI2c:         mark systemd-boot-efi
MI2c:        target systemd-utils-filetriggers
MI2c:         mark systemd-utils-filetriggers
MI2c:        target systemd-tmpfiles-common
MI2c:         mark systemd-tmpfiles-common
MI2c:        target systemd-sysctl-common
MI2c:         mark systemd-sysctl-common
MI2c:        target udev
MI2c:         mark udev
MI2c:          target dmsetup
MI2c:           mark dmsetup
MI2c:            target lsblk
MI2c:             mark lsblk
MI2c:          target losetup
MI2c:           mark losetup
MI2c: mark startup
MI2c:  target /sbin/halt
MI2c:   mark sysvinit
MI2c:    delete systemd

apt принимает решение удалить systemd, но сделать этого не может, так как нужен timesyncd.
apt разрешить ситуацию не может.

Кстати, тут ещё один выход вырисовывается. Если объединить пакеты systemd-sysvinit и systemd, то
sysvinit не выберется и проблемы не будет.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Wednesday, 22 December 2021 13:37:10 MSK Антон Мидюков wrote:
> 22.12.2021 17:14, Sergey V Turchin пишет:
> > On Wednesday, 22 December 2021 07:33:12 MSK Антон Мидюков wrote:
> > 
> > [...]
> > 
> >> Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо
> >> sysvinit, либо systemd-sysvinit. Исправив startup, починим сборку
> >> пакетов.
> > 
> > И даже #292430 ?
> 
> Да.
Похоже не то. Я ради интереса сделал тестовое #292461 .

[...]

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Alexey Gladkov]

On Wed, Dec 22, 2021 at 11:33:12AM +0700, Антон Мидюков wrote:
> 22.12.2021 03:06, Leonid Krivoshein пишет:
> > 
> > 21.12.2021 22:32, Антон Мидюков пишет:
> >> 17.12.2021 19:07, Alexey Gladkov пишет:
> >>> Привет!
> >>>
> >>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> >>> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> >>> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> >>> это приводит к серьёзным проблемам.
> >> Проблема скорее в том, что в hasher попадает sysvinit. А попадает он туда
> >> через треугольник systemd-utils-standalone - startup - systemd-sysctl-common.
> >> Эти пакеты вытягивают друг друга и sysvinit.
> >> startup тянется другими пакетами из-за конфигов, которые в нём.
> >> Можете попробовать установить в только что инициализированный hasher.
> >> А вот как они вытягивают sysvinit, я что-то не пойму. Наверное, это startup.
> > 
> > От startup раньше зависел interactive-basesystem, теперь нет. Но раз его убрали из зависимостей, кому-то это могло что-то поломать, так что с марта 2021 startup могли добавить куда-то ещё.
> > 
> > А можешь показать cat /etc/apt/pkgpriorities ? Этот файл ведь не установщик может создавать, его могли бы определять конфликтующие иниты, каждый по-своему. Потому что многие инитные зависимости виртуальные, и при обновлении начинается качание весов. Можно оставить его в apt-conf-branch для всех решений, а для пользователей sysvinit переместить в инитный пакет.
> > 
> 
> Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо sysvinit, либо systemd-sysvinit.
> Исправив startup, починим сборку пакетов.

Насколько я понимаю startup не нужен на системах с systemd. Об этом уже
писал shaba@. Пакет startup нужен только на системах с sysvinit.

Конфликт в sysvinit выявил скрытую проблему:

https://git.altlinux.org/tasks/292438/logs/events.1.1.log

сейчас у нас systemd сам вытягивает startup

Building Dependency Tree...
 MI2a: mark libnss-mymachines
 MI2a:  target systemd-container
 MI2a:   mark systemd-container
 MI2a:    target systemd
 MI2a:     mark systemd
 MI2a:      target /etc/modules
 MI2a:       mark startup
            ^^^^^^^^^^^^^^
 MI2a:      target libnss-systemd
 MI2a:       mark libnss-systemd
 MI2a:      target systemd-boot-efi
 MI2a:       mark systemd-boot-efi
 MI2a:      target systemd-sysctl-common
 MI2a:       mark systemd-sysctl-common

$ rpmquery -pR files/x86_64/RPMS/systemd-249.7-alt5.x86_64.rpm | grep /etc/modules
/etc/modules

$ apt-cache showpkg /etc/modules
Package: /etc/modules
Versions: 

Reverse Depends: 
  systemd,/etc/modules
Dependencies: 
Provides: 
Reverse Provides: 
startup 0.9.9.13-alt1:sisyphus+284270.100.1.1@1630416269

В свою очередь startup хочет утилиты halt, initlog, reboot, shutdown,
telinit. Их предоставляет либо sysvinit, либо systemd-sysvinit.

$ rpm -e --test systemd-sysvinit
error: Failed dependencies:
 /sbin/halt is needed by (installed) startup-0.9.9.13-alt1.noarch
 /sbin/reboot is needed by (installed) startup-0.9.9.13-alt1.noarch
 /sbin/shutdown is needed by (installed) startup-0.9.9.13-alt1.noarch
 /sbin/telinit is needed by (installed) startup-0.9.9.13-alt1.noarch

С одной стороны если systemd втащит внутрь systemd-sysvinit, то это
спрячет проблему и sysvinit перестанет появляться в окружении с systemd.
Но это плохое решение.

Другим решением будет доделать перенос легаси конфигов в отдельные пакеты.

Дима предложил порядок действий:

+ В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
зависимости.

+ Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
зависимость.

+ В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
на файл и добавляется ссылка /etc/sysctl.conf.

+ В новом systemd-modules-common добавляется файл
/etc/modules-load.d/modules.conf и ссылка /etc/modules на него.

+ В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
новые места.

После этого startup перестанет появляться на системах с systemd и
вытягивать ненужные зависимости.

-- 
Rgrds, legion

Re: [devel] I: sysvinit vs systemd

[Alexey V. Vissarionov]

On 2021-12-22 17:37:10 +0700, Антон Мидюков wrote:

 >>> Да уже разобрался. startup через зависимость /sbin/halt
 >>> вытягивает либо sysvinit, либо systemd-sysvinit. Исправив
 >>> startup, починим сборку пакетов.
 >> И даже #292430 ?
 > Да. Увидев это задание и начал расследование. Оказалось, что
 > также в пустой hasher нельзя установить alterator-setup,
 > alterator-datetime и, видимо, многие другие пакеты.
 > Для alterator-datetime apt строит такой граф:
 > [...]
 > MI2c: mark alterator-datetime
 > MI2c: target ntp-server
 > MI2c:  mark systemd-timesyncd

Ага, полезли метастазы... В принципе, лечится явным указанием
openntpd.

 > apt принимает решение удалить systemd, но сделать этого не
 > может, так как нужен timesyncd. apt разрешить ситуацию не
 > может.

Значит, ему надо подсказать.

 > Кстати, тут ещё один выход вырисовывается. Если объединить
 > пакеты systemd-sysvinit и systemd, то sysvinit не выберется
 > и проблемы не будет.

По-моему лучше собрать пустой пакет с нужными зависимостями.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Wednesday, 22 December 2021 15:30:09 MSK Alexey V wrote:

[...]
> Значит, ему надо подсказать.
_уже_ подсказали. ;-)

[...]

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> это приводит к серьёзным проблемам.
> 
> Правда, после этого изменения перестали собираться несколько пакетов:
А systemd соберётся?
install-check пройдёт?

[...]

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Sergey V Turchin]

On Friday, 17 December 2021 15:07:16 MSK Alexey Gladkov wrote:
> Привет!
> 
> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> это приводит к серьёзным проблемам.
> 
> Правда, после этого изменения перестали собираться несколько пакетов:
Список не полный. snapd нет, например.

[...]

-- 
Regards, Sergey.

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Wed, Dec 22, 2021 at 12:01:06PM +0100, Alexey Gladkov wrote:
> On Wed, Dec 22, 2021 at 11:33:12AM +0700, Антон Мидюков wrote:
> > 22.12.2021 03:06, Leonid Krivoshein пишет:
> > > 21.12.2021 22:32, Антон Мидюков пишет:
> > >> 17.12.2021 19:07, Alexey Gladkov пишет:
> > >>> Привет!
> > >>>
> > >>> В виду нарастающей несовместимости между системами с sysvinit и systemd.
> > >>> В sysvinit была добавлена явный конфликт на systemd. Технически они не
> > >>> конфликтуют, но без него в системы с sysvinit иногда попадает systemd и
> > >>> это приводит к серьёзным проблемам.
> > >> Проблема скорее в том, что в hasher попадает sysvinit. А попадает он туда
> > >> через треугольник systemd-utils-standalone - startup - systemd-sysctl-common.
> > >> Эти пакеты вытягивают друг друга и sysvinit.
> > >> startup тянется другими пакетами из-за конфигов, которые в нём.
> > >> Можете попробовать установить в только что инициализированный hasher.
> > >> А вот как они вытягивают sysvinit, я что-то не пойму. Наверное, это startup.
> > > 
> > > От startup раньше зависел interactive-basesystem, теперь нет. Но раз его убрали из зависимостей, кому-то это могло что-то поломать, так что с марта 2021 startup могли добавить куда-то ещё.
> > > 
> > > А можешь показать cat /etc/apt/pkgpriorities ? Этот файл ведь не установщик может создавать, его могли бы определять конфликтующие иниты, каждый по-своему. Потому что многие инитные зависимости виртуальные, и при обновлении начинается качание весов. Можно оставить его в apt-conf-branch для всех решений, а для пользователей sysvinit переместить в инитный пакет.
> > > 
> > 
> > Да уже разобрался. startup через зависимость /sbin/halt вытягивает либо sysvinit, либо systemd-sysvinit.
> > Исправив startup, починим сборку пакетов.
> 
> Насколько я понимаю startup не нужен на системах с systemd. Об этом уже
> писал shaba@. Пакет startup нужен только на системах с sysvinit.
> 
> Конфликт в sysvinit выявил скрытую проблему:
> 
> https://git.altlinux.org/tasks/292438/logs/events.1.1.log
> 
> сейчас у нас systemd сам вытягивает startup
> 
> Building Dependency Tree...
>  MI2a: mark libnss-mymachines
>  MI2a:  target systemd-container
>  MI2a:   mark systemd-container
>  MI2a:    target systemd
>  MI2a:     mark systemd
>  MI2a:      target /etc/modules
>  MI2a:       mark startup
>             ^^^^^^^^^^^^^^
>  MI2a:      target libnss-systemd
>  MI2a:       mark libnss-systemd
>  MI2a:      target systemd-boot-efi
>  MI2a:       mark systemd-boot-efi
>  MI2a:      target systemd-sysctl-common
>  MI2a:       mark systemd-sysctl-common
> 
> $ rpmquery -pR files/x86_64/RPMS/systemd-249.7-alt5.x86_64.rpm | grep /etc/modules
> /etc/modules
> 
> $ apt-cache showpkg /etc/modules
> Package: /etc/modules
> Versions: 
> 
> Reverse Depends: 
>   systemd,/etc/modules
> Dependencies: 
> Provides: 
> Reverse Provides: 
> startup 0.9.9.13-alt1:sisyphus+284270.100.1.1@1630416269
> 
> В свою очередь startup хочет утилиты halt, initlog, reboot, shutdown,
> telinit. Их предоставляет либо sysvinit, либо systemd-sysvinit.
> 
> $ rpm -e --test systemd-sysvinit
> error: Failed dependencies:
>  /sbin/halt is needed by (installed) startup-0.9.9.13-alt1.noarch
>  /sbin/reboot is needed by (installed) startup-0.9.9.13-alt1.noarch
>  /sbin/shutdown is needed by (installed) startup-0.9.9.13-alt1.noarch
>  /sbin/telinit is needed by (installed) startup-0.9.9.13-alt1.noarch
> 
> С одной стороны если systemd втащит внутрь systemd-sysvinit, то это
> спрячет проблему и sysvinit перестанет появляться в окружении с systemd.
> Но это плохое решение.
> 
> Другим решением будет доделать перенос легаси конфигов в отдельные пакеты.
> 
> Дима предложил порядок действий:
> 
> + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> зависимости.
> 
> + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> зависимость.
> 
> + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> на файл и добавляется ссылка /etc/sysctl.conf.
> 
> + В новом systemd-modules-common добавляется файл
> /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> 
> + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> новые места.
> 
> После этого startup перестанет появляться на системах с systemd и
> вытягивать ненужные зависимости.

Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
исправит.  Если он по той или иной причине не сможет, я буду искать того,
кто сможет.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Alexey Shabalin]

чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > Дима предложил порядок действий:
> >
> > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > зависимости.
> >
> > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > зависимость.
> >
> > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > на файл и добавляется ссылка /etc/sysctl.conf.
> >
> > + В новом systemd-modules-common добавляется файл
> > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> >
> > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > новые места.
> >
> > После этого startup перестанет появляться на системах с systemd и
> > вытягивать ненужные зависимости.
>
> Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> исправит.  Если он по той или иной причине не сможет, я буду искать того,
> кто сможет.

Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
изменений. Он первый в списке. От изменений в нем зависит все
остальное.
Задание можно расшарить, я в него добавлю исправления связанные с systemd.
Мне хватило истории со standalone утилитами, я помню своё задание, где
убрал зависимость на startup в systemd, и как это задание откатили.
Повторно по тем же граблям мне ходить не интересно.

-- 
Alexey Shabalin

Re: [devel] I: sysvinit vs systemd

[Anton Farygin]

On 22.12.2021 14:01, Alexey Gladkov wrote:
> Дима предложил порядок действий:
>
> + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> зависимости.
>
> + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> зависимость.
>
> + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> на файл и добавляется ссылка /etc/sysctl.conf.
>
> + В новом systemd-modules-common добавляется файл
> /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
>
> + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> новые места.
>
> После этого startup перестанет появляться на системах с systemd и
> вытягивать ненужные зависимости.

А наш rpm переживёт эти процедуры со ссылками ?

https://bugzilla.altlinux.org/34619

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Thu, Dec 23, 2021 at 06:59:30PM +0300, Anton Farygin wrote:
> On 22.12.2021 14:01, Alexey Gladkov wrote:
> > Дима предложил порядок действий:
> >
> > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > зависимости.
> >
> > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > зависимость.
> >
> > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > на файл и добавляется ссылка /etc/sysctl.conf.
> >
> > + В новом systemd-modules-common добавляется файл
> > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> >
> > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > новые места.
> >
> > После этого startup перестанет появляться на системах с systemd и
> > вытягивать ненужные зависимости.
> 
> А наш rpm переживёт эти процедуры со ссылками ?

Замены ссылок на файлы и обратно rpm обычно переваривает нормально.
Единственная нетривиальность - сохранить содержание перемещаемых файлов,
если они были изменены локально, но и это несложно.  Но надо будет
протестировать, что содержание действительно не теряется.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Alexey Gladkov]

On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > кто сможет.
> 
> Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> изменений. Он первый в списке.

А ты оказывается обидчивый! Интересно, почему ты жаждешь именно реакции
первого мантейнера, а не второго или любого другого у кого есть
квалификация.

> От изменений в нем зависит все остальное.

В нём ? В первом мантейнере из списка ? Что в нём такого особенного ?

> Задание можно расшарить, я в него добавлю исправления связанные с systemd.
> Мне хватило истории со standalone утилитами, я помню своё задание, где
> убрал зависимость на startup в systemd, и как это задание откатили.
> Повторно по тем же граблям мне ходить не интересно.

Я не против исправить эту старую багу, которая мешает systemd, но смогу
это сделать только в следующем году.

-- 
Rgrds, legion

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > Дима предложил порядок действий:
> > >
> > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > зависимости.
> > >
> > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > зависимость.
> > >
> > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > на файл и добавляется ссылка /etc/sysctl.conf.
> > >
> > > + В новом systemd-modules-common добавляется файл
> > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > >
> > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > новые места.
> > >
> > > После этого startup перестанет появляться на системах с systemd и
> > > вытягивать ненужные зависимости.
> >
> > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > кто сможет.
> 
> Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> изменений. Он первый в списке. От изменений в нем зависит все
> остальное.

$ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
rpmlib(PayloadIsLzma)  
$ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
54

На всякий случай при таком раскладе лучше собирать пакет startup
последним подзаданием в сборочном задании.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > Дима предложил порядок действий:
> > > >
> > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > зависимости.
> > > >
> > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > зависимость.
> > > >
> > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > >
> > > > + В новом systemd-modules-common добавляется файл
> > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > >
> > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > новые места.
> > > >
> > > > После этого startup перестанет появляться на системах с systemd и
> > > > вытягивать ненужные зависимости.
> > >
> > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > кто сможет.
> > 
> > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > изменений. Он первый в списке. От изменений в нем зависит все
> > остальное.
> 
> $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> rpmlib(PayloadIsLzma)  
> $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> 54
> 
> На всякий случай при таком раскладе лучше собирать пакет startup
> последним подзаданием в сборочном задании.

https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
- я проверил, что этот пакет собирается.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 03:00:29AM +0300, Dmitry V. Levin wrote:
> On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > Дима предложил порядок действий:
> > > > >
> > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > зависимости.
> > > > >
> > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > зависимость.
> > > > >
> > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > >
> > > > > + В новом systemd-modules-common добавляется файл
> > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > >
> > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > новые места.
> > > > >
> > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > вытягивать ненужные зависимости.
> > > >
> > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > кто сможет.
> > > 
> > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > изменений. Он первый в списке. От изменений в нем зависит все
> > > остальное.
> > 
> > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > rpmlib(PayloadIsLzma)  
> > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > 54
> > 
> > На всякий случай при таком раскладе лучше собирать пакет startup
> > последним подзаданием в сборочном задании.
> 
> https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> - я проверил, что этот пакет собирается.

PoC, untested:

%pre -n systemd-modules-common
src=/etc/modules
dst=/etc/modules-load.d/modules.conf
tmp=$dst.rpmmove
rm -f $tmp
if [ -L $dst -a -s $src -a ! -L $src ]; then
	mkdir -p ${tmp%/*}
	mv $src $tmp
fi

%post -n systemd-modules-common
src=/etc/modules-load.d/modules.conf.rpmmove
dst=/etc/modules-load.d/modules.conf
tmp=$dst.rpmsave
if [ -s $src ]; then
	mv $dst $tmp
	mv $src $dst
	if cmp -s $dst $tmp; then
		rm -f $tmp
	fi
fi
	

-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Alexey Shabalin]

пт, 24 дек. 2021 г. в 03:00, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > Дима предложил порядок действий:
> > > > >
> > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > зависимости.
> > > > >
> > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > зависимость.
> > > > >
> > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > >
> > > > > + В новом systemd-modules-common добавляется файл
> > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > >
> > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > новые места.
> > > > >
> > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > вытягивать ненужные зависимости.
> > > >
> > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > кто сможет.
> > >
> > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > изменений. Он первый в списке. От изменений в нем зависит все
> > > остальное.
> >
> > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > rpmlib(PayloadIsLzma)
> > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > 54
> >
> > На всякий случай при таком раскладе лучше собирать пакет startup
> > последним подзаданием в сборочном задании.
>
> https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> - я проверил, что этот пакет собирается.

Симлинки в файлы конечно можно не переименовывать, нужно просто
избавиться от ненужных зависимостей.
Но согласен, лучше это сделать сейчас.

Что я не пойму, так почему эти симлинки  (/etc/modules,
/etc/sysctl.conf) и файлы должны быть в пакете systemd.
Почему вы так упорно перекладываете проблему на пакет systemd?
В systemd и так хватает %pre,%post скриптов. Зачем его еще больше перегружать.
Я бы предпочел в systemd сделать аналогичные изменения
startup-0.9.9.14, а все преобразования с симлинками и файлами в,
например, пакетах startup-modules-common, startup-sysctl-common.

-- 
Alexey Shabalin

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 06:07:39PM +0300, Alexey Shabalin wrote:
> пт, 24 дек. 2021 г. в 03:00, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > > Дима предложил порядок действий:
> > > > > >
> > > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > > зависимости.
> > > > > >
> > > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > > зависимость.
> > > > > >
> > > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > > >
> > > > > > + В новом systemd-modules-common добавляется файл
> > > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > > >
> > > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > > новые места.
> > > > > >
> > > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > > вытягивать ненужные зависимости.
> > > > >
> > > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > > кто сможет.
> > > >
> > > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > > изменений. Он первый в списке. От изменений в нем зависит все
> > > > остальное.
> > >
> > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > > rpmlib(PayloadIsLzma)
> > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > > 54
> > >
> > > На всякий случай при таком раскладе лучше собирать пакет startup
> > > последним подзаданием в сборочном задании.
> >
> > https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> > - я проверил, что этот пакет собирается.
> 
> Симлинки в файлы конечно можно не переименовывать, нужно просто
> избавиться от ненужных зависимостей.
> Но согласен, лучше это сделать сейчас.
> 
> Что я не пойму, так почему эти симлинки  (/etc/modules,
> /etc/sysctl.conf) и файлы должны быть в пакете systemd.
> Почему вы так упорно перекладываете проблему на пакет systemd?
> В systemd и так хватает %pre,%post скриптов. Зачем его еще больше перегружать.
> Я бы предпочел в systemd сделать аналогичные изменения
> startup-0.9.9.14, а все преобразования с симлинками и файлами в,
> например, пакетах startup-modules-common, startup-sysctl-common.

Потому что пакет systemd-sysctl-common уже есть, и перемещать его
содержимое куда-то ещё - это дополнительная морока.  Эти файлы, и в том
числе этот пакет совершенно не обязаны быть частью systemd, но ты уже
сделал его частью systemd, отрывать было бы сложнее, наверное.

Или я тебя неправильно понял.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Alexey Shabalin]

пт, 24 дек. 2021 г. в 18:32, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Dec 24, 2021 at 06:07:39PM +0300, Alexey Shabalin wrote:
> > пт, 24 дек. 2021 г. в 03:00, Dmitry V. Levin <ldv@altlinux.org>:
> > >
> > > On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > > > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > > > Дима предложил порядок действий:
> > > > > > >
> > > > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > > > зависимости.
> > > > > > >
> > > > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > > > зависимость.
> > > > > > >
> > > > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > > > >
> > > > > > > + В новом systemd-modules-common добавляется файл
> > > > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > > > >
> > > > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > > > новые места.
> > > > > > >
> > > > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > > > вытягивать ненужные зависимости.
> > > > > >
> > > > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > > > кто сможет.
> > > > >
> > > > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > > > изменений. Он первый в списке. От изменений в нем зависит все
> > > > > остальное.
> > > >
> > > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > > > rpmlib(PayloadIsLzma)
> > > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > > > 54
> > > >
> > > > На всякий случай при таком раскладе лучше собирать пакет startup
> > > > последним подзаданием в сборочном задании.
> > >
> > > https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> > > - я проверил, что этот пакет собирается.
> >
> > Симлинки в файлы конечно можно не переименовывать, нужно просто
> > избавиться от ненужных зависимостей.
> > Но согласен, лучше это сделать сейчас.
> >
> > Что я не пойму, так почему эти симлинки  (/etc/modules,
> > /etc/sysctl.conf) и файлы должны быть в пакете systemd.
> > Почему вы так упорно перекладываете проблему на пакет systemd?
> > В systemd и так хватает %pre,%post скриптов. Зачем его еще больше перегружать.
> > Я бы предпочел в systemd сделать аналогичные изменения
> > startup-0.9.9.14, а все преобразования с симлинками и файлами в,
> > например, пакетах startup-modules-common, startup-sysctl-common.
>
> Потому что пакет systemd-sysctl-common уже есть, и перемещать его
> содержимое куда-то ещё - это дополнительная морока.  Эти файлы, и в том
> числе этот пакет совершенно не обязаны быть частью systemd, но ты уже
> сделал его частью systemd, отрывать было бы сложнее, наверное.
>
> Или я тебя неправильно понял.

Думаю правильно понял.
В systemd-sysctl-common в основном конфиги, которые действительно
присутствуют в проекте systemd.
Наши дополнения, это только 49-coredump-disable.conf,
50-mmap-min-addr.conf (архитектурно зависимый), и был симлинк
/etc/sysctl.d/99-sysctl.conf который и порождал зависимость на
startup. Вот все эти переименования симлинка и файла 99-sysctl.conf
можно вынести в пакет startup-sysctl-common, плюс наши дополнения.

А systemd-modules-common раньше вообще не было, поэтому тоже можно
сразу сделать startup-modules-common.


-- 
Alexey Shabalin

Re: [devel] I: sysvinit vs systemd

[Alexey Shabalin]

пт, 24 дек. 2021 г. в 03:30, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Dec 24, 2021 at 03:00:29AM +0300, Dmitry V. Levin wrote:
> > On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > > Дима предложил порядок действий:
> > > > > >
> > > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > > зависимости.
> > > > > >
> > > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > > зависимость.
> > > > > >
> > > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > > >
> > > > > > + В новом systemd-modules-common добавляется файл
> > > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > > >
> > > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > > новые места.
> > > > > >
> > > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > > вытягивать ненужные зависимости.
> > > > >
> > > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > > кто сможет.
> > > >
> > > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > > изменений. Он первый в списке. От изменений в нем зависит все
> > > > остальное.
> > >
> > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > > rpmlib(PayloadIsLzma)
> > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > > 54
> > >
> > > На всякий случай при таком раскладе лучше собирать пакет startup
> > > последним подзаданием в сборочном задании.
> >
> > https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> > - я проверил, что этот пакет собирается.

https://git.altlinux.org/people/shaba/packages/systemd.git
Проверил сборку и обновление.

>
> PoC, untested:

Спасибо.

>
> %pre -n systemd-modules-common
> src=/etc/modules
> dst=/etc/modules-load.d/modules.conf
> tmp=$dst.rpmmove
> rm -f $tmp
> if [ -L $dst -a -s $src -a ! -L $src ]; then

Убрал проверку -L $dst. Потому что может не быть такого симлинка
(напрмер на системах sysv).
На самом деле не важно, есть ли там сейчас симлинк, все равно в итоге
там должен оказаться файл с содержимым /etc/modules.

>         mkdir -p ${tmp%/*}

Убрал mkdir, т.к. все эти каталоги принадлежат пакету filesystem и
обязаны присутствовать в системе.

>         mv $src $tmp

Оказалось что нельзя делать mv. При отсутствии $src выдает ошибку rpm
про cpio archive.
Заменил на cp. Rpm сам успешно преобразует $src файл в симлинк и
дополнительную помощь не приветствует.

> fi
>
> %post -n systemd-modules-common
> src=/etc/modules-load.d/modules.conf.rpmmove
> dst=/etc/modules-load.d/modules.conf
> tmp=$dst.rpmsave
> if [ -s $src ]; then
>         mv $dst $tmp
>         mv $src $dst
>         if cmp -s $dst $tmp; then
>                 rm -f $tmp
>         fi

Если мы тут создаем rpmsave вручную, то я еще добавил удаление
/etc/modules.rpmsave автоматически создаваемое rpm.

> fi
>


-- 
Alexey Shabalin

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 08:28:34PM +0300, Alexey Shabalin wrote:
> пт, 24 дек. 2021 г. в 18:32, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Fri, Dec 24, 2021 at 06:07:39PM +0300, Alexey Shabalin wrote:
> > > пт, 24 дек. 2021 г. в 03:00, Dmitry V. Levin <ldv@altlinux.org>:
> > > >
> > > > On Fri, Dec 24, 2021 at 02:36:45AM +0300, Dmitry V. Levin wrote:
> > > > > On Thu, Dec 23, 2021 at 06:53:56PM +0300, Alexey Shabalin wrote:
> > > > > > чт, 23 дек. 2021 г. в 17:20, Dmitry V. Levin <ldv@altlinux.org>:
> > > > > > > > Дима предложил порядок действий:
> > > > > > > >
> > > > > > > > + В startup ссылки /etc/modules и /etc/sysctl.conf заменяются на
> > > > > > > > зависимости.
> > > > > > > >
> > > > > > > > + Из systemd ссылка /etc/modules-load.d/modules.conf заменяется на
> > > > > > > > зависимость.
> > > > > > > >
> > > > > > > > + В systemd-sysctl-common ссылка /etc/sysctl.d/99-sysctl.conf заменяется
> > > > > > > > на файл и добавляется ссылка /etc/sysctl.conf.
> > > > > > > >
> > > > > > > > + В новом systemd-modules-common добавляется файл
> > > > > > > > /etc/modules-load.d/modules.conf и ссылка /etc/modules на него.
> > > > > > > >
> > > > > > > > + В обоих -common добавляются %pre, которые перемещают заменяемые файлы на
> > > > > > > > новые места.
> > > > > > > >
> > > > > > > > После этого startup перестанет появляться на системах с systemd и
> > > > > > > > вытягивать ненужные зависимости.
> > > > > > >
> > > > > > > Чтобы не было разночтений, я ожидаю, что мантейнер пакета systemd всё это
> > > > > > > исправит.  Если он по той или иной причине не сможет, я буду искать того,
> > > > > > > кто сможет.
> > > > > >
> > > > > > Тоже внесу ясность. Я жду от мантейнеров пакета startup предложенных
> > > > > > изменений. Он первый в списке. От изменений в нем зависит все
> > > > > > остальное.
> > > > >
> > > > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/startup-0.9.9.13-alt1.src.rpm
> > > > > rpmlib(PayloadIsLzma)
> > > > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/systemd-249.7-alt5.src.rpm |wc -l
> > > > > 54
> > > > >
> > > > > На всякий случай при таком раскладе лучше собирать пакет startup
> > > > > последним подзаданием в сборочном задании.
> > > >
> > > > https://git.altlinux.org/people/ldv/packages/?p=startup.git;a=tag;h=0.9.9.14-alt1
> > > > - я проверил, что этот пакет собирается.
> > >
> > > Симлинки в файлы конечно можно не переименовывать, нужно просто
> > > избавиться от ненужных зависимостей.
> > > Но согласен, лучше это сделать сейчас.
> > >
> > > Что я не пойму, так почему эти симлинки  (/etc/modules,
> > > /etc/sysctl.conf) и файлы должны быть в пакете systemd.
> > > Почему вы так упорно перекладываете проблему на пакет systemd?
> > > В systemd и так хватает %pre,%post скриптов. Зачем его еще больше перегружать.
> > > Я бы предпочел в systemd сделать аналогичные изменения
> > > startup-0.9.9.14, а все преобразования с симлинками и файлами в,
> > > например, пакетах startup-modules-common, startup-sysctl-common.
> >
> > Потому что пакет systemd-sysctl-common уже есть, и перемещать его
> > содержимое куда-то ещё - это дополнительная морока.  Эти файлы, и в том
> > числе этот пакет совершенно не обязаны быть частью systemd, но ты уже
> > сделал его частью systemd, отрывать было бы сложнее, наверное.
> >
> > Или я тебя неправильно понял.
> 
> Думаю правильно понял.
> В systemd-sysctl-common в основном конфиги, которые действительно
> присутствуют в проекте systemd.
> Наши дополнения, это только 49-coredump-disable.conf,
> 50-mmap-min-addr.conf (архитектурно зависимый), и был симлинк
> /etc/sysctl.d/99-sysctl.conf который и порождал зависимость на
> startup. Вот все эти переименования симлинка и файла 99-sysctl.conf
> можно вынести в пакет startup-sysctl-common, плюс наши дополнения.
> 
> А systemd-modules-common раньше вообще не было, поэтому тоже можно
> сразу сделать startup-modules-common.

Можно, только надо будет аккуратно расставить версионированные конфликты,
чтобы никто не пытался поставить новый startup-sysctl-common на старый
systemd-sysctl-common и новый startup-modules-common на старый systemd.

Ну и префикс startup-, на мой взгляд, не очень уместен для пакета,
в котором лежат только конфиги.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 08:50:18PM +0300, Alexey Shabalin wrote:
[...]
> > %pre -n systemd-modules-common
> > src=/etc/modules
> > dst=/etc/modules-load.d/modules.conf
> > tmp=$dst.rpmmove
> > rm -f $tmp
> > if [ -L $dst -a -s $src -a ! -L $src ]; then
> 
> Убрал проверку -L $dst. Потому что может не быть такого симлинка
> (напрмер на системах sysv).
> На самом деле не важно, есть ли там сейчас симлинк, все равно в итоге
> там должен оказаться файл с содержимым /etc/modules.
> 
> >         mkdir -p ${tmp%/*}
> 
> Убрал mkdir, т.к. все эти каталоги принадлежат пакету filesystem и
> обязаны присутствовать в системе.
> 
> >         mv $src $tmp
> 
> Оказалось что нельзя делать mv. При отсутствии $src выдает ошибку rpm
> про cpio archive.
> Заменил на cp. Rpm сам успешно преобразует $src файл в симлинк и
> дополнительную помощь не приветствует.

Если mv нельзя, то надо, видимо, делать cp -a.


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Dmitry V. Levin]

On Fri, Dec 24, 2021 at 09:04:11PM +0300, Dmitry V. Levin wrote:
> On Fri, Dec 24, 2021 at 08:50:18PM +0300, Alexey Shabalin wrote:
> [...]
> > > %pre -n systemd-modules-common
> > > src=/etc/modules
> > > dst=/etc/modules-load.d/modules.conf
> > > tmp=$dst.rpmmove
> > > rm -f $tmp
> > > if [ -L $dst -a -s $src -a ! -L $src ]; then
> > 
> > Убрал проверку -L $dst. Потому что может не быть такого симлинка
> > (напрмер на системах sysv).
> > На самом деле не важно, есть ли там сейчас симлинк, все равно в итоге
> > там должен оказаться файл с содержимым /etc/modules.
> > 
> > >         mkdir -p ${tmp%/*}
> > 
> > Убрал mkdir, т.к. все эти каталоги принадлежат пакету filesystem и
> > обязаны присутствовать в системе.
> > 
> > >         mv $src $tmp
> > 
> > Оказалось что нельзя делать mv. При отсутствии $src выдает ошибку rpm
> > про cpio archive.
> > Заменил на cp. Rpm сам успешно преобразует $src файл в симлинк и
> > дополнительную помощь не приветствует.
> 
> Если mv нельзя, то надо, видимо, делать cp -a.

При обновлении с не изменёнными /etc/sysctl.conf и /etc/modules получается:

'/etc/sysctl.conf' -> '/etc/sysctl.d/99-sysctl.conf.rpmmove'
systemd-sysctl-common-1:249.7-alt7.x86_64
renamed '/etc/sysctl.d/99-sysctl.conf' -> '/etc/sysctl.d/99-sysctl.conf.rpmsave'
renamed '/etc/sysctl.d/99-sysctl.conf.rpmmove' -> '/etc/sysctl.d/99-sysctl.conf'

'/etc/modules' -> '/etc/modules-load.d/modules.conf.rpmmove'
systemd-modules-common-1:249.7-alt7.noarch
renamed '/etc/modules-load.d/modules.conf' -> '/etc/modules-load.d/modules.conf.rpmsave'
renamed '/etc/modules-load.d/modules.conf.rpmmove' -> '/etc/modules-load.d/modules.conf'


При обновлении с изменёнными /etc/sysctl.conf и /etc/modules получается:

'/etc/sysctl.conf' -> '/etc/sysctl.d/99-sysctl.conf.rpmmove'
systemd-sysctl-common-1:249.7-alt7.x86_64
warning: /etc/sysctl.conf saved as /etc/sysctl.conf.rpmsave
renamed '/etc/sysctl.d/99-sysctl.conf' -> '/etc/sysctl.d/99-sysctl.conf.rpmsave'
renamed '/etc/sysctl.d/99-sysctl.conf.rpmmove' -> '/etc/sysctl.d/99-sysctl.conf'

'/etc/modules' -> '/etc/modules-load.d/modules.conf.rpmmove'
systemd-modules-common-1:249.7-alt7.noarch
warning: /etc/modules saved as /etc/modules.rpmsave
renamed '/etc/modules-load.d/modules.conf' -> '/etc/modules-load.d/modules.conf.rpmsave'
renamed '/etc/modules-load.d/modules.conf.rpmmove' -> '/etc/modules-load.d/modules.conf'


Я думаю, мы можем сделать лучше, если будем проверять .rpmsave,
которые создаёт rpm, например:

%pre modules-common
src=/etc/modules
dst=/etc/modules-load.d/modules.conf.rpmmove
rm -f $dst
if [ -s $src -a ! -L $src ]; then
	cp -a $src $dst
fi

%post modules-common
src=/etc/modules.rpmsave
dst=/etc/modules-load.d/modules.conf
tmp=$dst.rpmmove
new=$dst.rpmnew
if [ -f $tmp ]; then
	if cmp -s $src $tmp; then
		mv -v -f $dst $new
		mv -v $src $dst
	fi
	rm -f $tmp
fi


-- 
ldv

Re: [devel] I: sysvinit vs systemd

[Alexey V. Vissarionov]

On 2021-12-24 20:55:19 +0300, Dmitry V. Levin wrote:

 > Ну и префикс startup-, на мой взгляд, не очень уместен для
 > пакета, в котором лежат только конфиги.

Нарезать помельче и распихать по пакетам с осмысленными именами.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net