[devel] startup and standalone versions of systemd utilities.

[devel] startup and standalone versions of systemd utilities.

[Alexey Shabalin]

День добрый.
startup перешел на использование standalone утилит от systemd (tmpfiles и др)
Какие я вижу возникшие проблемы:
1) на системах с systemd приезжают также и standalone версии, которые
не нужны. Зачем два экземпляра утилит?
Вариант решения - либо втянуть нужные файлы (конфиги типа
/etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо выделить
их в общий пакет, типа startup-common.
Как вариант, совсем отказаться от легаси конфигов типа
/etc/sysconfig/clock, либо перенести их в sysv-специфичный пакет.

2) на системах с sysv должны ставиться standalone утилиты, а не
systemd-utils, но при этом нет rpm filetrigger, аналогичных
systemd-utils. Соответственно при установке пакетов на системах с sysv
они не отрабатывают, что может привести к некорректной
работе/установке пакетов.
Вариант решения - повторить эти rpm filetrigger. Можно их добавить в
пакеты со standalone утилитами, но пока не решен вопрос с их
установкой на системы с systemd это будет вызывать проблему двойного
срабатывания.

В fedora в rpmbuild есть прикольный параметр:
RemovePathPostfixes: .standalone
Что позволяет упаковать в пакет файлы, обрезав суффикс.
Это позволит не переписывать скрипты на использование standalone утилит.
Добавление этой фичи в наш rpmbuild помогло бы в решении вышеуказанных проблем.

Прошу высказаться, как будем решать вышеуказанные проблемы.

-- 
Alexey Shabalin

Re: [devel] RemovePathPostfixes

[Dmitry V. Levin]

On Thu, Feb 04, 2021 at 06:23:33PM +0300, Alexey Shabalin wrote:
[...]
> В fedora в rpmbuild есть прикольный параметр:
> RemovePathPostfixes: .standalone
> Что позволяет упаковать в пакет файлы, обрезав суффикс.
> Это позволит не переписывать скрипты на использование standalone утилит.
> Добавление этой фичи в наш rpmbuild помогло бы в решении вышеуказанных проблем.

Эта "фича" нужна для того, чтобы легко плодить конфликтующих
альтернативных провайдеров, что, на мой взгляд, для репозитория вредно.


-- 
ldv

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-04 18:45:53 +0300, Dmitry V. Levin wrote:

 >> В fedora в rpmbuild есть прикольный параметр:
 >> RemovePathPostfixes: .standalone
 >> Что позволяет упаковать в пакет файлы, обрезав суффикс.
 > Эта "фича" нужна для того, чтобы легко плодить конфликтующих
 > альтернативных провайдеров, что, на мой взгляд, для репозитория
 > вредно.

Это именно то, чего от репы ждут админы (которым до этого вообще
есть дело, разумеется). А то, что один и тот же файл можно найти
в разных пакетах - всего лишь повод явно написать Requires, если
принципиальным является использование именно этого варианта. Или
(что еще более правильно) явно указать нужный пакет при установке.

А еще файловый конфликт намного лучше полного угробища, именуемого
alternatives и зачем-то бережно сохраняемого в наших системах.


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

Re: [devel] RemovePathPostfixes

[Dmitry V. Levin]

On Thu, Feb 04, 2021 at 07:21:09PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-04 18:45:53 +0300, Dmitry V. Levin wrote:
> 
>  >> В fedora в rpmbuild есть прикольный параметр:
>  >> RemovePathPostfixes: .standalone
>  >> Что позволяет упаковать в пакет файлы, обрезав суффикс.
>  > Эта "фича" нужна для того, чтобы легко плодить конфликтующих
>  > альтернативных провайдеров, что, на мой взгляд, для репозитория
>  > вредно.
> 
> Это именно то, чего от репы ждут админы

Обоснуй.


-- 
ldv

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-04 20:13:24 +0300, Dmitry V. Levin wrote:

 >>> Эта "фича" нужна для того, чтобы легко плодить конфликтующих
 >>> альтернативных провайдеров, что, на мой взгляд, для
 >>> репозитория вредно.
 >> Это именно то, чего от репы ждут админы
 > Обоснуй.

Никто не любит, когда за них принимают решения, не спросив, что
именно им нужно. Классический пример - /usr/sbin/sendmail: это
имя файла уже много лет прибито гвоздями в куче [говно]кода, и
избавиться от него практически невозможно, хотя само шлимыло уже
давно сдохло. Предоставить этот файл могут (у нас) пакеты exim,
msmtp и postfix, причем что именно ставить - решает админ. Более
того, если настраивать сервер по уму, лучше будет поставить два
пакета - exim или postfix в качестве демона SMTP (который будет
слушать *:25) и msmtp (который будет запускаться из-под обычных
бесправных пользователей как /usr/sbin/sendmail и отправлять
сообщения через смартхост на ::1).

Так вот: простейший способ обеспечить необходимую гибкость при
установке - сделать этот самый /usr/sbin/sendmail симлинком и
вынести в %package %name-sendmail во всех трех пакетах. А кроме
того, что простейший - еще и самый понятный админу, который со
всей этой колбасней работает: "вот тут ставим postfix, который
будет смартхостом, рядом ставим msmtp и msmtp-sendmail, чтобы
отправлять почту через этот смартхост; а теперь делаем еще 30
серверов уже без postfix, а только с msmtp и msmtp-sendmail -
они будут все слать через первый сервер".

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


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

Re: [devel] RemovePathPostfixes

[Vladimir D. Seleznev]

On Thu, Feb 04, 2021 at 10:45:50PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-04 20:13:24 +0300, Dmitry V. Levin wrote:
> 
>  >>> Эта "фича" нужна для того, чтобы легко плодить конфликтующих
>  >>> альтернативных провайдеров, что, на мой взгляд, для
>  >>> репозитория вредно.
>  >> Это именно то, чего от репы ждут админы
>  > Обоснуй.
> 
> Никто не любит, когда за них принимают решения, не спросив, что
> именно им нужно. Классический пример - /usr/sbin/sendmail: это
> имя файла уже много лет прибито гвоздями в куче [говно]кода, и
> избавиться от него практически невозможно, хотя само шлимыло уже
> давно сдохло. Предоставить этот файл могут (у нас) пакеты exim,
> msmtp и postfix, причем что именно ставить - решает админ. Более
> того, если настраивать сервер по уму, лучше будет поставить два
> пакета - exim или postfix в качестве демона SMTP (который будет
> слушать *:25) и msmtp (который будет запускаться из-под обычных
> бесправных пользователей как /usr/sbin/sendmail и отправлять
> сообщения через смартхост на ::1).
> 
> Так вот: простейший способ обеспечить необходимую гибкость при
> установке - сделать этот самый /usr/sbin/sendmail симлинком и
> вынести в %package %name-sendmail во всех трех пакетах. А кроме
> того, что простейший - еще и самый понятный админу, который со
> всей этой колбасней работает: "вот тут ставим postfix, который
> будет смартхостом, рядом ставим msmtp и msmtp-sendmail, чтобы
> отправлять почту через этот смартхост; а теперь делаем еще 30
> серверов уже без postfix, а только с msmtp и msmtp-sendmail -
> они будут все слать через первый сервер".

Мне кажется, ты только что изобрёл alternatives.

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

А этот абзац противоречит предыдущему.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-04 23:12:32 +0300, Vladimir D. Seleznev wrote:

 > Мне кажется, ты только что изобрёл alternatives.

Нет - это способ избавиться от alternatives.

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

Никоим образом. Просто вместо разруливания конфликтов (как это было
задумано в alternatives, а про реализацию я говорить лучше не буду)
применяется другой подход - конфликты есть, но они заведомо никому
не мешают, и поэтому разруливать их не надо.


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

Re: [devel] RemovePathPostfixes

[Paul Wolneykien]

В Fri, 5 Feb 2021 00:01:13 +0300
"Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:

> On 2021-02-04 23:12:32 +0300, Vladimir D. Seleznev wrote:
> 
>  > Мне кажется, ты только что изобрёл alternatives.  
> 
> Нет - это способ избавиться от alternatives.

  Мне тоже так показалось. Ведь alternatives --- это способ установить
в систему несколько альтернативных (!) пакетов _одновременно_.
А с конфликтами всё наоборот. Не знаю только, можно ли все имеющиеся
alternatives заменить конфликтующими подпакетами и к чему это
приведёт...


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

Re: [devel] RemovePathPostfixes

[Alexey Shabalin]

пт, 5 февр. 2021 г. в 02:46, Paul Wolneykien <manowar@altlinux.org>:
>
> В Fri, 5 Feb 2021 00:01:13 +0300
> "Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:
>
> > On 2021-02-04 23:12:32 +0300, Vladimir D. Seleznev wrote:
> >
> >  > Мне кажется, ты только что изобрёл alternatives.
> >
> > Нет - это способ избавиться от alternatives.
>
>   Мне тоже так показалось. Ведь alternatives --- это способ установить
> в систему несколько альтернативных (!) пакетов _одновременно_.
> А с конфликтами всё наоборот. Не знаю только, можно ли все имеющиеся
> alternatives заменить конфликтующими подпакетами и к чему это
> приведёт...
>
>
> >  >> Поэтому конфликты между альтернативными провайдерами - вполне
> >  >> нормальное и, главное, ожидаемое явление. В отличие от того же
> >  >> угробища, именуемого alternatives и возводящего в абсолют самую
> >  >> глупую ошибку разработчика - принимать решения за пользователя.
> >  > А этот абзац противоречит предыдущему.
> >
> > Никоим образом. Просто вместо разруливания конфликтов (как это было
> > задумано в alternatives, а про реализацию я говорить лучше не буду)
> > применяется другой подход - конфликты есть, но они заведомо никому
> > не мешают, и поэтому разруливать их не надо.

Вы ушли в сторону от обсуждаемой темы RemovePathPostfixes.
Хорошо альтернативы или нет, совсем другой вопрос.
В пакетах postfix-sendmail, exim-sendmail, foo-sendmail можно сделать
хоть конфликт, хоть альтернативы.
Это _разные_  src.rpm пакеты.
А RemovePathPostfixes позволяет по одному пути упаковать разные файлы
в разные бинарные rpm из одного src.rpm пакета.
Да конфликтующие, но разные и из одного src.rpm.
Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
(разве что найдется герой и напишет её на shell).
Поэтому тут альтернативы лишние, а конфликт в самый раз.

Еще забыл упомянуть в первом письме, что вызов systemd-tmpfiles(и
других утилит) может быть в %post у пакета. В случае с sysv такой
пакет уже не установится, точнее будет вытягивать systemd. А задача
была обратная - предоставить systemd standalone утилиты для sysv.
Теряется унификация для наших пакетов и скриптов.
Поэтому мне кажется стоит откатить изменения в startup.
Если ничего не выйдет с RemovePathPostfixes, то все равно придется
standalone утилиты собирать "родными" именами (без суфикса
.standalone). Хоть из отдельного src.rpm пакета. Да конфликтующие с
основными утилитами.
Просто RemovePathPostfixes облегчил бы жизнь.

-- 
Alexey Shabalin

Re: [devel] RemovePathPostfixes

[Dmitry V. Levin]

On Fri, Feb 05, 2021 at 04:31:50AM +0300, Alexey Shabalin wrote:
[...]
> А RemovePathPostfixes позволяет по одному пути упаковать разные файлы
> в разные бинарные rpm из одного src.rpm пакета.
> Да конфликтующие, но разные и из одного src.rpm.
> Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
> (разве что найдется герой и напишет её на shell).
> Поэтому тут альтернативы лишние, а конфликт в самый раз.

Допустим, в репозитории есть несколько конфликтующих провайдеров
/sbin/systemd-tmpfiles, и допустим, что в некотором пакете есть
зависимость на /sbin/systemd-tmpfiles, возможно, даже автоматически
вычисленная.

Какого из провайдеров должен установить apt-get, если ни одного из
провайдеров не установлено?  Того, который указан в
/etc/apt/pkgpriorities?  Значит, для каждого дистрибутива будет свой
/etc/apt/pkgpriorities, очень удобно.  А какого провайдера указать в
/etc/apt/pkgpriorities, используемом для сборки пакетов в репозиторий?
А почему именно его?

Альтернативные провайдеры в Сизифе есть, но это PITA.

RemovePathPostfixes просто позволит причинять эту боль быстрее,
чем мы будем успевать её купировать.

Я не против RemovePathPostfixes, если каждый альтернативный провайдер
будет проходить обязательную процедуру согласования, на которой
релиз-инженеры всех дистрибутивов и операторы всех сборочниц будут давать
отмашку, когда у них будет всё готово к появлению нового альтернативного
провайдера.

На самом деле, такая процедура нам давно была нужна и без всяких
RemovePathPostfixes.  Тогда, например, не возникло бы проблемы с
неожиданным появлением неподходящего провайдера network-config-subsystem.


-- 
ldv

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 05:51:51 +0300, Dmitry V. Levin wrote:

 > Допустим, в репозитории есть несколько конфликтующих провайдеров
 > /sbin/systemd-tmpfiles, и допустим, что в некотором пакете есть
 > зависимость на /sbin/systemd-tmpfiles, возможно, даже автоматически
 > вычисленная.

Даже скорее всего автоматически. Потому что вручную можно указать и
конкретный пакет, и (если совсем пофигу) имя из Provides:

 > Какого из провайдеров должен установить apt-get, если ни одного
 > из провайдеров не установлено?

Указанного явно. Либо с минимумом зависимостей.

 > Того, который указан в /etc/apt/pkgpriorities? Значит, для каждого
 > дистрибутива будет свой /etc/apt/pkgpriorities, очень удобно.

Вполне нормальное решение.

 > А какого провайдера указать в /etc/apt/pkgpriorities, используемом
 > для сборки пакетов в репозиторий? А почему именно его?

Точно так же - либо указанного явно, либо с минимумом зависимостей.
Или у тебя есть более интересные, но при этом тоже работоспособные
варианты?

 > Альтернативные провайдеры в Сизифе есть, но это PITA.

У кого и насколько сильно?

 > RemovePathPostfixes просто позволит причинять эту боль быстрее,
 > чем мы будем успевать её купировать.

Если продолжать медицинские аналогии, то нужно не боль купировать, а
причину устранять. То есть, например, сломанную ногу не диклофенаком
обкалывать, а репозицию сделать и гипс наложить. Оно, конечно, еще
какое-то время будет болеть (и это нужно учитывать), но процедура от
этого менее правильной не становится.

 > Я не против RemovePathPostfixes, если каждый альтернативный
 > провайдер будет проходить обязательную процедуру согласования,
 > на которой релиз-инженеры всех дистрибутивов и операторы всех
 > сборочниц будут давать отмашку, когда у них будет всё готово
 > к появлению нового альтернативного провайдера.

Сочиняй, публикуй в листе...

 > На самом деле, такая процедура нам давно была нужна и без
 > всяких RemovePathPostfixes. Тогда, например, не возникло бы
 > проблемы с неожиданным появлением неподходящего провайдера
 > network-config-subsystem.

Кому и куда неподходящего?


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

Re: [devel] RemovePathPostfixes

[Alexey Shabalin]

пт, 5 февр. 2021 г. в 05:51, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Feb 05, 2021 at 04:31:50AM +0300, Alexey Shabalin wrote:
> [...]
> > А RemovePathPostfixes позволяет по одному пути упаковать разные файлы
> > в разные бинарные rpm из одного src.rpm пакета.
> > Да конфликтующие, но разные и из одного src.rpm.
> > Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
> > (разве что найдется герой и напишет её на shell).
> > Поэтому тут альтернативы лишние, а конфликт в самый раз.
>
> Допустим, в репозитории есть несколько конфликтующих провайдеров
> /sbin/systemd-tmpfiles, и допустим, что в некотором пакете есть
> зависимость на /sbin/systemd-tmpfiles, возможно, даже автоматически
> вычисленная.
>
> Какого из провайдеров должен установить apt-get, если ни одного из
> провайдеров не установлено?

Если мы говорим об обыкновенной системе, то этот провайдер обычно уже
существует в системе,
для systemd это пакет systemd-utils, для sysv должен быть systemd-*-standalone.

> Того, который указан в
> /etc/apt/pkgpriorities?  Значит, для каждого дистрибутива будет свой
> /etc/apt/pkgpriorities, очень удобно.  А какого провайдера указать в
> /etc/apt/pkgpriorities, используемом для сборки пакетов в репозиторий?
> А почему именно его?

Мне кажется apt в состоянии вычислить предпочтительный пакет без
дополнительных указаний.
А какая разница для сборочницы какой провайдер приедет? они оба должны
работать одинаково.

> Альтернативные провайдеры в Сизифе есть, но это PITA.
>
> RemovePathPostfixes просто позволит причинять эту боль быстрее,
> чем мы будем успевать её купировать.
>
> Я не против RemovePathPostfixes, если каждый альтернативный провайдер
> будет проходить обязательную процедуру согласования, на которой
> релиз-инженеры всех дистрибутивов и операторы всех сборочниц будут давать
> отмашку, когда у них будет всё готово к появлению нового альтернативного
> провайдера.
>
> На самом деле, такая процедура нам давно была нужна и без всяких
> RemovePathPostfixes.  Тогда, например, не возникло бы проблемы с
> неожиданным появлением неподходящего провайдера network-config-subsystem.


-- 
Alexey Shabalin

Re: [devel] RemovePathPostfixes

[Aleksei Nikiforov]

05.02.2021 04:31, Alexey Shabalin пишет:
> Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
> (разве что найдется герой и напишет её на shell).

Давно существует:

https://packages.gentoo.org/packages/sys-apps/opentmpfiles
https://github.com/openrc/opentmpfiles

С уважением,
Алексей Никифоров

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 10:33:17 +0300, Aleksei Nikiforov wrote:

 >> Я не думаю, что появится еще какая-нибудь реализация
 >> systemd-tmpfiles (разве что найдется герой и напишет её на shell).
 > Давно существует:
 > https://packages.gentoo.org/packages/sys-apps/opentmpfiles
 > https://github.com/openrc/opentmpfiles

Вот, собственно, и решение...


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

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 13:00:39 MSK Alexey V wrote:
> On 2021-02-05 10:33:17 +0300, Aleksei Nikiforov wrote:
>  >> Я не думаю, что появится еще какая-нибудь реализация
>  >> systemd-tmpfiles (разве что найдется герой и напишет её на shell).
>  > 
>  > Давно существует:
>  > https://packages.gentoo.org/packages/sys-apps/opentmpfiles
>  > https://github.com/openrc/opentmpfiles
> 
> Вот, собственно, и решение...
А вот там как раз зависимости. ;-D

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 15:14:50 MSK Sergey V wrote:
> On Friday, 5 February 2021 13:00:39 MSK Alexey V wrote:
> > On 2021-02-05 10:33:17 +0300, Aleksei Nikiforov wrote:
> >  >> Я не думаю, что появится еще какая-нибудь реализация
> >  >> systemd-tmpfiles (разве что найдется герой и напишет её на shell).
> >  > 
> >  > Давно существует:
> >  > https://packages.gentoo.org/packages/sys-apps/opentmpfiles
> >  > https://github.com/openrc/opentmpfiles
> > 
> > Вот, собственно, и решение...
> 
> А вот там как раз зависимости. ;-D
Хотя, ошибся. Там нужен тольно  tmpfiles.sh .

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Paul Wolneykien]

5 февраля 2021 г. 4:31:50 GMT+03:00, Alexey Shabalin <a.shabalin@gmail.com> пишет:

>Вы ушли в сторону от обсуждаемой темы RemovePathPostfixes.
>Хорошо альтернативы или нет, совсем другой вопрос.
>В пакетах postfix-sendmail, exim-sendmail, foo-sendmail можно сделать
>хоть конфликт, хоть альтернативы.
>Это _разные_  src.rpm пакеты.
>А RemovePathPostfixes позволяет по одному пути упаковать разные файлы
>в разные бинарные rpm из одного src.rpm пакета.
>Да конфликтующие, но разные и из одного src.rpm.
>Я не думаю, что появится еще какая-нибудь реализация systemd-tmpfiles
>(разве что найдется герой и напишет её на shell).
>Поэтому тут альтернативы лишние, а конфликт в самый раз.

А почему, кстати? /etc/alternatives как раз позволяют сделать файлы с разными именами доступными по одному и тому же пути — хоть из разных srpm, хоть из одного.

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 04:31:50 MSK Alexey Shabalin wrote:

[..]
> Поэтому тут альтернативы лишние, а конфликт в самый раз.
Прошу избегать любых конфликтов пакетов вообще везде и всегда, если это 
возможно. Наш apt и так зачастую "нишмагла" в различных нетривиальных 
ситуациях, поэтому просьба не усугублять. Особенно в системообразующих 
пакетах.

[...]

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 12:15:19 +0300, Sergey V Turchin wrote:

 >> Поэтому тут альтернативы лишние, а конфликт в самый раз.
 > Прошу избегать любых конфликтов пакетов вообще везде и
 > всегда, если это возможно. Наш apt и так зачастую "нишмагла"
 > в различных нетривиальных ситуациях, поэтому просьба не
 > усугублять. Особенно в системообразующих пакетах.

Вообще-то большинство случаев "нишмагла" в исполнении apt -
это не Provides или Conflicts, а избыточные зависимости.


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

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 13:13:05 MSK Alexey V wrote:
> On 2021-02-05 12:15:19 +0300, Sergey V Turchin wrote:
>  >> Поэтому тут альтернативы лишние, а конфликт в самый раз.
>  > 
>  > Прошу избегать любых конфликтов пакетов вообще везде и
>  > всегда, если это возможно. Наш apt и так зачастую "нишмагла"
>  > в различных нетривиальных ситуациях, поэтому просьба не
>  > усугублять. Особенно в системообразующих пакетах.
> 
> Вообще-то большинство случаев "нишмагла" в исполнении apt -
> это не Provides или Conflicts, а избыточные зависимости.
Ну, зависимости. В чём проблема их всех поставить?

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 04:31:50 +0300, Alexey Shabalin wrote:

 > Вы ушли в сторону от обсуждаемой темы RemovePathPostfixes

Я ответил на сообщение ldv про то, что множественные Provides -
это плохо для репы. Ну а дальше дискуссия продолжилась... :-)

 > RemovePathPostfixes позволяет по одному пути упаковать разные
 > файлы в разные бинарные rpm из одного src.rpm пакета.

Да, и это очень хорошо. Если пользоваться этой возможностью с умом,
можно даже библиотеки так собирать - с заведомо одинаковым ABI, но,
например, с разными зависимостями от других библиотек. Единственная
сложность, которая здесь может возникнуть - при сборке придется явно
указывать, какую библиотеку использовать (имя пакета; так-то понятно,
что нужно выбирать сборку с минимальными зависимостями).

 > Да конфликтующие, но разные и из одного src.rpm. Я не думаю, что
 > появится еще какая-нибудь реализация systemd-tmpfiles (разве что
 > найдется герой и напишет её на shell).

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

 > Поэтому тут альтернативы лишние, а конфликт в самый раз.

Да alternatives везде лишние... но всем как обычно.

 > Еще забыл упомянуть в первом письме, что вызов systemd-tmpfiles
 > (и других утилит) может быть в %post у пакета. В случае с sysv
 > такой пакет уже не установится, точнее будет вытягивать systemd.

Возможно, есть смысл не тащить в системы с sysV ошметки systemd, а
либо реализовать нужный функционал независимо, либо вообще обойтись
без него.

 > А задача была обратная - предоставить systemd standalone утилиты
 > для sysv. Теряется унификация для наших пакетов и скриптов.

А так ли она нужна? Может, проще будет разграничить их по принципу
"юниты налево, скрипты направо"?

 > Поэтому мне кажется стоит откатить изменения в startup. Если
 > ничего не выйдет с RemovePathPostfixes, то все равно придется
 > standalone утилиты собирать "родными" именами (без суфикса
 > .standalone). Хоть из отдельного src.rpm пакета.

Или как-то их объезжать. Вплоть до того, что сделать два разных
пакета с Provides: startup

 > Да конфликтующие с основными утилитами.

Да и хрен бы с ними...

 > Просто RemovePathPostfixes облегчил бы жизнь.

Угу. Только использовать его нужно с умом. И очень аккуратно.


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

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 02:45:41 +0300, Paul Wolneykien wrote:

 >>> Мне кажется, ты только что изобрёл alternatives.
 >> Нет - это способ избавиться от alternatives.
 > Мне тоже так показалось. Ведь alternatives --- это способ
 > установить в систему несколько альтернативных (!) пакетов
 > _одновременно_.

Кому и для чего это может быть нужно? Только не 20 лет назад (во
времена "персональных компутеров коллективного пользования"), а
именно сейчас.

 > А с конфликтами всё наоборот. Не знаю только, можно ли все
 > имеющиеся alternatives заменить конфликтующими подпакетами

Можно.

 > и к чему это приведёт...

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


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

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 12:19:09 MSK Alexey V wrote:

[...]
>  > А с конфликтами всё наоборот. Не знаю только, можно ли все
>  > имеющиеся alternatives заменить конфликтующими подпакетами
> Можно.
Можно, но ни в коем случае не нужно портить репозиторий.

[...]

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 00:01:13 MSK Alexey V wrote:

[...]
> - конфликты есть, но они заведомо никому не мешают
Единственное и прямое назначение конфликтов -- мешать. :-D

[...]

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 11:05:50 MSK Sergey V wrote:
> On Friday, 5 February 2021 00:01:13 MSK Alexey V wrote:
> 
> [...]
> 
> > - конфликты есть, но они заведомо никому не мешают
> 
> Единственное и прямое назначение конфликтов -- мешать. :-D
А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
 
> [...]


-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 11:11:44 +0300, Sergey V Turchin wrote:

 >>> конфликты есть, но они заведомо никому не мешают
 >> Единственное и прямое назначение конфликтов -- мешать. :-D
 > А alternatives, соответственно, -- чтобы никто никому НЕ мешал.

Попробуй взглянуть на это с кочки зрения админа.


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

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Friday, 5 February 2021 13:17:09 MSK Alexey V wrote:
> On 2021-02-05 11:11:44 +0300, Sergey V Turchin wrote:
>  >>> конфликты есть, но они заведомо никому не мешают
>  >> 
>  >> Единственное и прямое назначение конфликтов -- мешать. :-D
>  > 
>  > А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
> 
> Попробуй взглянуть на это с кочки зрения админа.
Правильно! Не стоит админу давать советы разработчикам по разработке и 
мантейнерам пакетов по упаковке. ;-)

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 14:11:12 +0300, Sergey V Turchin wrote:
 >>>>> конфликты есть, но они заведомо никому не мешают
 >>>> Единственное и прямое назначение конфликтов -- мешать. :-D
 >>> А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
 >> Попробуй взглянуть на это с кочки зрения админа.
 > Правильно! Не стоит админу давать советы разработчикам по
 > разработке и мантейнерам пакетов по упаковке. ;-)

То есть, ты предлагаешь полностью игнорировать vox populi и
делать так, как подсказывает пролетарское чутье? Увы, это еще
никого до добра не доводило.


З.Ы. (Замечу Ышо): смайлик вижу, ага... но вопрос-то серьезный.

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

Re: [devel] RemovePathPostfixes

[Sergey V Turchin]

On Monday, 8 February 2021 05:49:34 MSK Alexey V wrote:
> On 2021-02-05 14:11:12 +0300, Sergey V Turchin wrote:
>  >>>>> конфликты есть, но они заведомо никому не мешают
>  >>>> 
>  >>>> Единственное и прямое назначение конфликтов -- мешать. :-D
>  >>> 
>  >>> А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
>  >> 
>  >> Попробуй взглянуть на это с кочки зрения админа.
>  > 
>  > Правильно! Не стоит админу давать советы разработчикам по
>  > разработке и мантейнерам пакетов по упаковке. ;-)
> 
> То есть, ты предлагаешь полностью игнорировать vox populi
Нет, не полностью.

> и делать так, как подсказывает
> пролетарское
Профессиональное.

> чутье?
Опыт и знания.

> Увы, это еще никого до добра не доводило.
Голословно. С таким же успехом верно обратное.

> З.Ы. (Замечу Ышо): смайлик вижу, ага... но вопрос-то серьезный.
Да, но определить, как его решить -- не пользовательская задача.

-- 
Regards, Sergey.

Re: [devel] RemovePathPostfixes

[Vladimir D. Seleznev]

On Fri, Feb 05, 2021 at 01:17:09PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-05 11:11:44 +0300, Sergey V Turchin wrote:
> 
>  >>> конфликты есть, но они заведомо никому не мешают
>  >> Единственное и прямое назначение конфликтов -- мешать. :-D
>  > А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
> 
> Попробуй взглянуть на это с кочки зрения админа.

И с точки зрения админа alternatives — удобный механизм. Более того, ты
по сути его сам переизобрёл несколькими сообщениями раньше.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-05 15:10:13 +0300, Vladimir D. Seleznev wrote:

 >>>>> конфликты есть, но они заведомо никому не мешают
 >>>> Единственное и прямое назначение конфликтов -- мешать. :-D
 >>> А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
 >> Попробуй взглянуть на это с кочки зрения админа.
 > И с точки зрения админа alternatives — удобный механизм.
 > Более того, ты по сути его сам переизобрёл несколькими
 > сообщениями раньше.

Ты не видишь принципиальной разницы? Подсказываю: что выдаст
`rpm -qf /usr/sbin/sendmail` при одновременно установленных
msmtp и postfix? Сравни ответы для двух методов :-)


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

Re: [devel] RemovePathPostfixes

[Vladimir D. Seleznev]

On Mon, Feb 08, 2021 at 05:52:46AM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-05 15:10:13 +0300, Vladimir D. Seleznev wrote:
> 
>  >>>>> конфликты есть, но они заведомо никому не мешают
>  >>>> Единственное и прямое назначение конфликтов -- мешать. :-D
>  >>> А alternatives, соответственно, -- чтобы никто никому НЕ мешал.
>  >> Попробуй взглянуть на это с кочки зрения админа.
>  > И с точки зрения админа alternatives — удобный механизм.
>  > Более того, ты по сути его сам переизобрёл несколькими
>  > сообщениями раньше.
> 
> Ты не видишь принципиальной разницы? Подсказываю: что выдаст
> `rpm -qf /usr/sbin/sendmail` при одновременно установленных
> msmtp и postfix? Сравни ответы для двух методов :-)

/usr/sbin/sendmail не обёрнут alternatives.

$ rpm -qf /usr/bin/vim
vim-X11-8.2.0011-alt2.noarch
vim-console-8.2.0011-alt2.x86_64
$ readlink /usr/bin/vim
/etc/alternatives/links/|usr|bin|vim
readlink -f /usr/bin/vim
/usr/bin/vim-console

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RemovePathPostfixes

[Alexey V. Vissarionov]

On 2021-02-08 06:32:53 +0300, Vladimir D. Seleznev wrote:

 >>> Более того, ты по сути его сам переизобрёл несколькими
 >>> сообщениями раньше.
 >> Ты не видишь принципиальной разницы? Подсказываю: что выдаст
 >> `rpm -qf /usr/sbin/sendmail` при одновременно установленных
 >> msmtp и postfix? Сравни ответы для двух методов :-)
 > /usr/sbin/sendmail не обёрнут alternatives.

И то хорошо. Можно посмотреть любой другой пакет.

 > $ rpm -qf /usr/bin/vim
 > vim-X11-8.2.0011-alt2.noarch
 > vim-console-8.2.0011-alt2.x86_64

Бардак.

 > $ readlink /usr/bin/vim
 > /etc/alternatives/links/|usr|bin|vim
 > readlink -f /usr/bin/vim
 > /usr/bin/vim-console

И как следствие - лишние действия только для того, чтобы выяснить,
какой vim у нас сегодня в моде...

Дурь.


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

Re: [devel] RemovePathPostfixes

[Vladimir D. Seleznev]

On Mon, Feb 08, 2021 at 06:38:35AM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-08 06:32:53 +0300, Vladimir D. Seleznev wrote:
> 
>  >>> Более того, ты по сути его сам переизобрёл несколькими
>  >>> сообщениями раньше.
>  >> Ты не видишь принципиальной разницы? Подсказываю: что выдаст
>  >> `rpm -qf /usr/sbin/sendmail` при одновременно установленных
>  >> msmtp и postfix? Сравни ответы для двух методов :-)
>  > /usr/sbin/sendmail не обёрнут alternatives.
> 
> И то хорошо. Можно посмотреть любой другой пакет.
> 
>  > $ rpm -qf /usr/bin/vim
>  > vim-X11-8.2.0011-alt2.noarch
>  > vim-console-8.2.0011-alt2.x86_64
> 
> Бардак.

Не вижу.

>  > $ readlink /usr/bin/vim
>  > /etc/alternatives/links/|usr|bin|vim
>  > readlink -f /usr/bin/vim
>  > /usr/bin/vim-console
> 
> И как следствие - лишние действия только для того, чтобы выяснить,
> какой vim у нас сегодня в моде...

Какой vim используется на установленной системе. /* fixed */ И будет
использоваться после обновления именно этот, а не любой другой из
возможных.

Выше пример с readlink был для наглядности, а так:

alternatives-list /usr/bin/vim
/usr/bin/vim points to /usr/bin/vim-console

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RemovePathPostfixes

[Sergey Y. Afonin]

On Thursday 04 February 2021, Alexey V. Vissarionov wrote:

> если настраивать сервер по уму, лучше будет поставить два
> пакета - exim или postfix в качестве демона SMTP (который будет
> слушать *:25) и msmtp (который будет запускаться из-под обычных
> бесправных пользователей как /usr/sbin/sendmail и отправлять
> сообщения через смартхост на ::1).

Что только люди не придумают, чтобы поставить одно "сдохшее шлимыло",
которое давно (десятка полтора лет) так и работает. Единственное что,
бинарник один используется. Но это так, лирика.

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

Re: [devel] RemovePathPostfixes

[Sergey Y. Afonin]

On Friday 05 February 2021, Sergey Y. Afonin wrote:

> чтобы поставить

В смысле чтобы не.

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

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Thu, Feb 04, 2021 at 06:23:33PM +0300, Alexey Shabalin wrote:
> День добрый.
> startup перешел на использование standalone утилит от systemd (tmpfiles и др)
> Какие я вижу возникшие проблемы:
> 1) на системах с systemd приезжают также и standalone версии, которые
> не нужны. Зачем два экземпляра утилит?
> Вариант решения - либо втянуть нужные файлы (конфиги типа
> /etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо выделить
> их в общий пакет, типа startup-common.

А можешь показать список того, что хочет systemd из startup ?

-- 
Rgrds, legion

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Shabalin]

чт, 4 февр. 2021 г. в 19:34, Alexey Gladkov <legion@altlinux.ru>:
>
> On Thu, Feb 04, 2021 at 06:23:33PM +0300, Alexey Shabalin wrote:
> > День добрый.
> > startup перешел на использование standalone утилит от systemd (tmpfiles и др)
> > Какие я вижу возникшие проблемы:
> > 1) на системах с systemd приезжают также и standalone версии, которые
> > не нужны. Зачем два экземпляра утилит?
> > Вариант решения - либо втянуть нужные файлы (конфиги типа
> > /etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо выделить
> > их в общий пакет, типа startup-common.
>
> А можешь показать список того, что хочет systemd из startup ?

Быстрым взглядом:
/etc/firsttime.d (под вопросом, вообще я делал
altlinux-first_time.service для обработки этой директории)
/etc/modules
/etc/rc.d/scripts/gen_kernel_headers (тут вообще вопрос, точно этот
скрипт должен быть в startup?)
/etc/sysconfig/clock (пора отказаться от этих legacy конфигов, но
инсталлер и sysv скрипты так никто и не переписал)
/etc/sysconfig/i18n  (пора отказаться от этих legacy конфигов, но
инсталлер и sysv скрипты так никто и не переписал)
/etc/sysconfig/mouse (под вопросом, кому это вообще нужно? если gpm,
то пусть он и носит этот конфиг)
/etc/sysctl.conf
/var/lib/rsbac (не пора его вообще убрать?)
/var/log/wtmp
/var/run/utmp

Большинство из вышеуказанного я могу перенести в systemd и поставить
конфликт на startup. Только сизиф такое не переживет :) у нас даже в
ядрах зависимость на пакет startup.


-- 
Alexey Shabalin

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Fri, Feb 05, 2021 at 04:52:47AM +0300, Alexey Shabalin wrote:
> > А можешь показать список того, что хочет systemd из startup ?
> 
> Быстрым взглядом:
> /etc/firsttime.d (под вопросом, вообще я делал
> altlinux-first_time.service для обработки этой директории)
> /etc/modules
> /etc/rc.d/scripts/gen_kernel_headers (тут вообще вопрос, точно этот
> скрипт должен быть в startup?)


> /etc/sysconfig/clock (пора отказаться от этих legacy конфигов, но
> инсталлер и sysv скрипты так никто и не переписал)
> /etc/sysconfig/i18n  (пора отказаться от этих legacy конфигов, но
> инсталлер и sysv скрипты так никто и не переписал)

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

Кроме того, эти "legacy" конфиги используются и заполняются скриптами (в
том числе не упакованными) долгое время. Выкинуть их можно только если
будет написаны скрипты для автоматической конвертации в новые.

> /etc/sysconfig/mouse (под вопросом, кому это вообще нужно? если gpm,
> то пусть он и носит этот конфиг)
> /etc/sysctl.conf
> /var/lib/rsbac (не пора его вообще убрать?)
> /var/log/wtmp
> /var/run/utmp
> 
> Большинство из вышеуказанного я могу перенести в systemd и поставить
> конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> ядрах зависимость на пакет startup.

udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
пока они оба используют udevd.

-- 
Rgrds, legion

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey V. Vissarionov]

On 2021-02-05 11:55:40 +0100, Alexey Gladkov wrote:

 > udevd требует systemd-utils. Разделение миров systemd и sysv
 > невозможно пока они оба используют udevd.

Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
например, его просто никогда не было.

% zgrep DEVTMPFS /proc/config.gz
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y


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

Re: [devel] startup and standalone versions of systemd utilities.

[Vladislav Zavjalov]

On Mon, Feb 08, 2021 at 06:11:16AM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-05 11:55:40 +0100, Alexey Gladkov wrote:
> 
>  > udevd требует systemd-utils. Разделение миров systemd и sysv
>  > невозможно пока они оба используют udevd.
>
> Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
> например, его просто никогда не было.
> 
> % zgrep DEVTMPFS /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y

А что при этом есть взамен udev rules? Я уже как-то привык:
втыкаешь пять каких-нибудь странных китайских приборчиков, смотришь,
чем они отличаются (id, или на худой конец devpath по тем портам, куда
они воткнуты) и расписываешь, какой модуль загрузить, какой скрипт
запустить (если вдруг надо), какой группе дать доступ, и каждому -
свой уникальный симлинк обязательно.

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey V. Vissarionov]

On 2021-02-08 12:34:03 +0300, Vladislav Zavjalov wrote:

 >>> udevd требует systemd-utils. Разделение миров systemd и sysv
 >>> невозможно пока они оба используют udevd.
 >> Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
 >> например, его просто никогда не было.
 >> % zgrep DEVTMPFS /proc/config.gz
 >> CONFIG_DEVTMPFS=y
 >> CONFIG_DEVTMPFS_MOUNT=y
 > А что при этом есть взамен udev rules?

Ничего. Они просто не нужны.

 > Я уже как-то привык: втыкаешь пять каких-нибудь странных
 > китайских приборчиков, смотришь, чем они отличаются (id,

Там обычно что-нибудь из shared, а устройство опознается по
серийнику.

 > или на худой конец devpath по тем портам, куда они воткнуты)

Воткнуты они могут быть куда угодно.

 > и расписываешь, какой модуль загрузить,

Все нужные модули загружаются при старте системы, после чего
происходит sysctl kernel.modules_disabled=1

А модули для накопителей и сетевых устройств вообще полагается
внутрь ядра вкомпилячивать. И я уже устал объяснять, почему.

 > какой скрипт запустить (если вдруг надо), какой группе дать
 > доступ, и каждому - свой уникальный симлинк обязательно.

А зачем? Устройство либо опознается ядром и работает через
него, либо работа с ним происходит из userspace как с HID.
Никакие симлинки при этом не нужны (хватает VID:PID:Serial),
а держать лишнего дырявого демона с рутовыми правами только
для управления доступом лично мне претит.


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

Re: [devel] startup and standalone versions of systemd utilities.

[Vladislav Zavjalov]

On Mon, Feb 08, 2021 at 01:03:05PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-08 12:34:03 +0300, Vladislav Zavjalov wrote:
>  > какой скрипт запустить (если вдруг надо), какой группе дать
>  > доступ, и каждому - свой уникальный симлинк обязательно.
> 
> А зачем? Устройство либо опознается ядром и работает через
> него, либо работа с ним происходит из userspace как с HID.
> Никакие симлинки при этом не нужны (хватает VID:PID:Serial),
> а держать лишнего дырявого демона с рутовыми правами только
> для управления доступом лично мне претит.

Ну вот пример, программируемые источники тока/напряжения Tenma/Korad.
Это дешевые и хорошие китайские источники (уж получше некоторых
Agilent/Keysight за 2000$/штука), к которым приделывают тупейший
usb-интерфейс. В одной стойке у меня 8шт таких, в другой - 4.
Там нет никаких ID/Serial, но мне важно знать, какое устройство
в какой /dev/usbACM* встало. Я их различаю по devpath и ставлю
симлинки (был бы Serial - различал бы по нему и тоже ставил симлинки).
И дальше уже вполне уверен, что подаю ток в нужное место.
Возможность написать в конфиге /dev/power_supply3 - это довольно ценно.

Поскольку я эти системы делаю для себя (плюс, может быть 1-2 студента),
и с некоторой долей экспериментирования (сегодня надо попробовать одно,
если не сработает, то завтра про это забыть и делать совсем другое),
то у меня могут быть немного смещенные идеи про соотношение
надежности/простоты настройки/гибкости.
В итоге от udev у меня есть ощущение, что это - полезный сервис,
который можно использовать.

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Mon, Feb 08, 2021 at 06:11:16AM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-05 11:55:40 +0100, Alexey Gladkov wrote:
> 
>  > udevd требует systemd-utils. Разделение миров systemd и sysv
>  > невозможно пока они оба используют udevd.
> 
> Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
> например, его просто никогда не было.
> 
> % zgrep DEVTMPFS /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y

Не путайте тёплое с мягким. udev уже давно не создаёт файлы устройств. Для
этого как раз используется devtmpfs. udev нужен для обработки факта
появления устройства и ещё некоторых эвентов ядра.

-- 
Rgrds, legion

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey V. Vissarionov]

On 2021-02-08 11:46:18 +0100, Alexey Gladkov wrote:

 >>> udevd требует systemd-utils. Разделение миров systemd и sysv
 >>> невозможно пока они оба используют udevd.
 >> Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
 >> например, его просто никогда не было.
 >> % zgrep DEVTMPFS /proc/config.gz
 >> CONFIG_DEVTMPFS=y
 >> CONFIG_DEVTMPFS_MOUNT=y
 > Не путайте тёплое с мягким. udev уже давно не создаёт файлы
 > устройств.

Да ну? А как же надпись "populating /dev" при загрузке? Врет?

 > Для этого как раз используется devtmpfs. udev нужен для обработки
 > факта появления устройства и ещё некоторых эвентов ядра.

Если точнее, _был_ нужен во времена /sbin/hotplug - сейчас все
это можно получить от ядра через netlink socket откуда угодно,
поэтому CONFIG_UEVENT_HELPER в ядре можно даже не включать.

Кстати, что любопытно:

config UEVENT_HELPER
 bool "Support for uevent helper"
 help
 The uevent helper program is forked by the kernel for
 every uevent.
 Before the switch to the netlink-based uevent source, this
 was used to hook hotplug scripts into kernel device events.
 It usually pointed to a shell script at /sbin/hotplug.

этот самый /sbin/hotplug изначально планировался как шелловский
скрипт, а не кусок udev :-)


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

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Tue, Feb 09, 2021 at 04:03:15PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-08 11:46:18 +0100, Alexey Gladkov wrote:
> 
>  >>> udevd требует systemd-utils. Разделение миров systemd и sysv
>  >>> невозможно пока они оба используют udevd.
>  >> Ну в общем-то выкинуть udev - совершенно не проблема... у меня,
>  >> например, его просто никогда не было.
>  >> % zgrep DEVTMPFS /proc/config.gz
>  >> CONFIG_DEVTMPFS=y
>  >> CONFIG_DEVTMPFS_MOUNT=y
>  > Не путайте тёплое с мягким. udev уже давно не создаёт файлы
>  > устройств.
> 
> Да ну? А как же надпись "populating /dev" при загрузке?

Уф. Ну вы хоть бы постарались почитать прежде чем писать. udev c 2012 не
умеет создавать устройства и не умеет работать без devtmpfs. До этого он
прекрасно умел работать с простым tmpfs.

https://github.com/systemd/systemd/commit/220893b3cbdbf8932f95c44811b169a8f0d33939

> Врет?

Раньше (когда он создавал файлы устройств) он досоздавал устройства на
tmpfs. Советую почитать, что делает /etc/rc.d/init.d/udevd, когда пишет
"Populating /dev" и что происходит после этих команд.

>  > Для этого как раз используется devtmpfs. udev нужен для обработки
>  > факта появления устройства и ещё некоторых эвентов ядра.
> 
> Если точнее, _был_ нужен во времена /sbin/hotplug - сейчас все
> это можно получить от ядра через netlink socket откуда угодно,
> поэтому CONFIG_UEVENT_HELPER в ядре можно даже не включать.
> 
> Кстати, что любопытно:
> 
> config UEVENT_HELPER
>  bool "Support for uevent helper"
>  help
>  The uevent helper program is forked by the kernel for
>  every uevent.
>  Before the switch to the netlink-based uevent source, this
>  was used to hook hotplug scripts into kernel device events.
>  It usually pointed to a shell script at /sbin/hotplug.
> 
> этот самый /sbin/hotplug изначально планировался как шелловский
> скрипт, а не кусок udev :-)

Брррр ... При чём тут /sbin/hotplug ? Этот хэлпер не имеет никакого
отношения к udevd и udevd также не требует этот параметр ядра. udevd
использует как раз netlink для получения эвентов ядра.

По сути udevd и есть тот удобный механизм, который позволяет реагировать
на эвенты ядра, приходящие через netlink.

Да и во времена, как вы сказали, во времена /sbin/hotplug udevd был не
нужен, потому что его в те времена ещё не было. hotplug намного более
старый механизм.

-- 
Rgrds, legion

[devel] Разделение миров systemd и sysv

[Alexey Shabalin]

пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> >
> > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > ядрах зависимость на пакет startup.
>
> udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> пока они оба используют udevd.

Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
ли она сейчас.

Давайте наметим план по разделению миров systemd и sysv.
Постараемся сделать из самодостаточными, что бы не было лишних
зависимостей ни в одном из миров.

1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
Если бы я раньше знал чем это грозит, я бы не стал делать такие подпакеты.
Давайте обеспечим отсутствие standalone подпакетов под systemd.

2) предлагаю под systemd перейти на dracut вместо make-initrd.
В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
На самом деле тут больше вопросов к нашему
/sbin/installkernel(bootloader-utils). И да, он к dracut не
адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
/(etc|usr/lib)/kernel/install.d или плавно перейти на использование
/sbin/kernel-install(в systemd)
Так же нужно будет исправить зависимости в kernel-image. Там до сих
пор указаны module-init-tools и mkinitrd.

3) что еще мешает пользователям sysv?

-- 
Alexey Shabalin

Re: [devel] Разделение миров systemd и sysv

[Alexey Gladkov]

On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > >
> > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > ядрах зависимость на пакет startup.
> >
> > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > пока они оба используют udevd.
> 
> Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> ли она сейчас.
> 
> Давайте наметим план по разделению миров systemd и sysv.
> Постараемся сделать из самодостаточными, что бы не было лишних
> зависимостей ни в одном из миров.
> 
> 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
> Если бы я раньше знал чем это грозит, я бы не стал делать такие подпакеты.
> Давайте обеспечим отсутствие standalone подпакетов под systemd.
> 
> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> На самом деле тут больше вопросов к нашему
> /sbin/installkernel(bootloader-utils). И да, он к dracut не
> адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> /sbin/kernel-install(в systemd)
> Так же нужно будет исправить зависимости в kernel-image. Там до сих
> пор указаны module-init-tools и mkinitrd.
> 
> 3) что еще мешает пользователям sysv?

Ты же понимаешь, что если если мантейнеры, использующие sysv, начнут
выпиливать поддержку systemd из своих пакетов, чтобы "убрать всё лишнее,
что мешает им своим существованием", то в "мире systemd" будет жить не
очень удобно.

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

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

-- 
Rgrds, legion

Re: [devel] Разделение миров systemd и sysv

[Andrey Savchenko]

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

On Wed, 17 Mar 2021 23:43:15 +0100 Alexey Gladkov wrote:
> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> > пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > > >
> > > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > > ядрах зависимость на пакет startup.
> > >
> > > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > > пока они оба используют udevd.
> > 
> > Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> > ли она сейчас.
> > 
> > Давайте наметим план по разделению миров systemd и sysv.
> > Постараемся сделать из самодостаточными, что бы не было лишних
> > зависимостей ни в одном из миров.
> > 
> > 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
> > Если бы я раньше знал чем это грозит, я бы не стал делать такие подпакеты.
> > Давайте обеспечим отсутствие standalone подпакетов под systemd.
> > 
> > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> > В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> > На самом деле тут больше вопросов к нашему
> > /sbin/installkernel(bootloader-utils). И да, он к dracut не
> > адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> > /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> > /sbin/kernel-install(в systemd)
> > Так же нужно будет исправить зависимости в kernel-image. Там до сих
> > пор указаны module-init-tools и mkinitrd.
> > 
> > 3) что еще мешает пользователям sysv?
> 
> Ты же понимаешь, что если если мантейнеры, использующие sysv, начнут
> выпиливать поддержку systemd из своих пакетов, чтобы "убрать всё лишнее,
> что мешает им своим существованием", то в "мире systemd" будет жить не
> очень удобно.
> 
> То что ты предлагаешь это по сути предложение выбора одной системы
> инициализации и форка для остальных.
> 
> Я не отвечаю за развитие репозитория и поэтому не могу ответить на твой
> вопрос. Если ответственные за стратегию развития репозитория посчитают,
> что без sysv будет лучше, то так тому и быть. Я не буду мешать и просто
> отойду в сторону.

Я считаю, что поддержка альтернатив systemd — важная
функциональность Alt, которая необходима пользователям, в т.ч.
новым, и её нельзя выбрасывать в угоду некоторым новомодным
тенденциям.


Best regards,
Andrew Savchenko

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

Re: [devel] Разделение миров systemd и sysv

[Alexey Shabalin]

пт, 19 мар. 2021 г. в 11:45, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Wed, 17 Mar 2021 23:43:15 +0100 Alexey Gladkov wrote:
> > On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> > > пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > > > >
> > > > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > > > ядрах зависимость на пакет startup.
> > > >
> > > > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > > > пока они оба используют udevd.
> > >
> > > Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> > > ли она сейчас.
> > >
> > > Давайте наметим план по разделению миров systemd и sysv.
> > > Постараемся сделать из самодостаточными, что бы не было лишних
> > > зависимостей ни в одном из миров.
> > >
> > > 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
> > > Если бы я раньше знал чем это грозит, я бы не стал делать такие подпакеты.
> > > Давайте обеспечим отсутствие standalone подпакетов под systemd.
> > >
> > > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> > > В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> > > На самом деле тут больше вопросов к нашему
> > > /sbin/installkernel(bootloader-utils). И да, он к dracut не
> > > адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> > > /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> > > /sbin/kernel-install(в systemd)
> > > Так же нужно будет исправить зависимости в kernel-image. Там до сих
> > > пор указаны module-init-tools и mkinitrd.
> > >
> > > 3) что еще мешает пользователям sysv?
> >
> > Ты же понимаешь, что если если мантейнеры, использующие sysv, начнут
> > выпиливать поддержку systemd из своих пакетов, чтобы "убрать всё лишнее,
> > что мешает им своим существованием", то в "мире systemd" будет жить не
> > очень удобно.
> >
> > То что ты предлагаешь это по сути предложение выбора одной системы
> > инициализации и форка для остальных.
> >
> > Я не отвечаю за развитие репозитория и поэтому не могу ответить на твой
> > вопрос. Если ответственные за стратегию развития репозитория посчитают,
> > что без sysv будет лучше, то так тому и быть. Я не буду мешать и просто
> > отойду в сторону.
>
> Я считаю, что поддержка альтернатив systemd — важная
> функциональность Alt, которая необходима пользователям, в т.ч.
> новым, и её нельзя выбрасывать в угоду некоторым новомодным
> тенденциям.
>

Я тоже считаю поддержку систем с systemd не менее важной, чем c sysv.
Но мантейнеры sysv фанатично противодействуют.
В рамках альта как раз получается добиться некоторого симбиоза
(systemd может использовать старые конфиги от sysv, sysv может
использовать утилиты от systemd - tmpfiles и др.)
Но любое предложение что-то изменить в мире sysv наталкивается на
огромное противодействие. Типа "раньше работало" и не трож.


-- 
Alexey Shabalin

Re: [devel] Разделение миров systemd и sysv

[Alexey Shabalin]

чт, 18 мар. 2021 г. в 01:43, Alexey Gladkov <legion@altlinux.ru>:
>
> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> > пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > > >
> > > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > > ядрах зависимость на пакет startup.
> > >
> > > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > > пока они оба используют udevd.
> >
> > Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> > ли она сейчас.
> >
> > Давайте наметим план по разделению миров systemd и sysv.
> > Постараемся сделать из самодостаточными, что бы не было лишних
> > зависимостей ни в одном из миров.
> >
> > 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
> > Если бы я раньше знал чем это грозит, я бы не стал делать такие подпакеты.
> > Давайте обеспечим отсутствие standalone подпакетов под systemd.
> >
> > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> > В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> > На самом деле тут больше вопросов к нашему
> > /sbin/installkernel(bootloader-utils). И да, он к dracut не
> > адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> > /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> > /sbin/kernel-install(в systemd)
> > Так же нужно будет исправить зависимости в kernel-image. Там до сих
> > пор указаны module-init-tools и mkinitrd.
> >
> > 3) что еще мешает пользователям sysv?
>
> Ты же понимаешь, что если если мантейнеры, использующие sysv, начнут
> выпиливать поддержку systemd из своих пакетов, чтобы "убрать всё лишнее,
> что мешает им своим существованием", то в "мире systemd" будет жить не
> очень удобно.

На самом деле, это сейчас и происходит.
Мантейнеры использующие sysv принципиально не хотят упаковать systemd
unit файлы в пакет.
Например баг от 2014 года.
https://bugzilla.altlinux.org/show_bug.cgi?id=30155

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

Как раз я этого не предлагаю.
Предлагаю просто аккуратно развести два мира.
Что бы не мешать друг-другу.
Я уже понял, что пакет startup можно считать sysv-only и в systemd
избавится от него.

>
> Я не отвечаю за развитие репозитория и поэтому не могу ответить на твой
> вопрос. Если ответственные за стратегию развития репозитория посчитают,
> что без sysv будет лучше, то так тому и быть. Я не буду мешать и просто
> отойду в сторону.

-- 
Alexey Shabalin

Re: [devel] Разделение миров systemd и sysv

[Alexey Gladkov]

On Thu, Mar 25, 2021 at 07:52:42PM +0300, Alexey Shabalin wrote:
> На самом деле, это сейчас и происходит.
> Мантейнеры использующие sysv принципиально не хотят упаковать systemd
> unit файлы в пакет.
> Например баг от 2014 года.
> https://bugzilla.altlinux.org/show_bug.cgi?id=30155

Это было не преднамеренно. Я проглядел этот баг и он потерялся.

Alexey Gladkov 2015-10-02: Приложите юнит, который нужно положить в пакет.
Alexey Shabalin 2019-01-02: Создано вложение 7930.

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

Я сам не могу создавать такие юниты поскольку не разбираюсь как их
создавать и тем более не могу проверить их. Поэтому "пример unit файла для
consolesaver" мне ни чем не помогает.

Добавил его todo.

-- 
Rgrds, legion

Re: [devel] Разделение миров systemd и sysv

[Dmitry V. Levin]

On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
[...]
> 2) предлагаю под systemd перейти на dracut вместо make-initrd.

А зачем?

Дело в том, что make-initrd был сделан в ALT и для ALT, мы умеем его
готовить.  Что даст замена make-initrd на dracut, помимо утраты
компетенции в этой области?


-- 
ldv

Re: [devel] Разделение миров systemd и sysv

[Alexey Shabalin]

чт, 18 мар. 2021 г. в 01:43, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> [...]
> > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>
> А зачем?
>
> Дело в том, что make-initrd был сделан в ALT и для ALT, мы умеем его
> готовить.  Что даст замена make-initrd на dracut, помимо утраты
> компетенции в этой области?

А куда денется компетенция в этой области? Она просто так не испарится.
Из плюсов в dracut (в сравнении с make-initrd):
- Используется во многих дистрибутивах: fedora, RHEL, openSUSE, Void.
- Не используется по-умолчанию, но может использоваться и присутствует
в репо у Gentoo, Debian, OpenMandriva, Magea, Arch
См. - https://en.wikipedia.org/wiki/Dracut_(software)
- разобраться в работе dracut не сложнее, чем в make-initrd
- понятная документация. (по документации make-initrd не всегда
получается ожидаемый результат. например чтобы получить shell в
initrd, прочитать документацию по make-initrd недостаточно, пришлось
еще залезть в код и смотреть как он работает.)
- многие апстримы сразу поддерживают dracut (plymouth, ignition). Для
make-initrd нужно реализовывать этот функционал самостоятельно.
- dracut может также использоваться на системах с sysv, но я не
предлагаю вам этого делать :)
- внутри initrd используется systemd, такой же как и в системе, как
следствие более понятная и единообразная загрузка системы. Более
плавная что ли :) не знаю какое определение подобрать :)
- больше различных модулей. например systemd-networkd. Ожидать его
поддержки в make-initrd просто не реально.

Минусы make-initrd
- используется только в одном дистрибутиве
- проект одного человека
- Компетенции поддерживать предыдущие стабильные версии без основного
разработчика у нас также нет. А его по понятным причинам не интересуют
стабильные бранчи. Поэтому в p9 пришлось переходить на make-initrd2.
- как в любом открытом проекте, необходимую фичу придется
разрабатывать самостоятельно. тут нет никакой разницы с dracut.

PS: to legion@ я ценю и уважаю проделанную тобой работу. Ни в коем
случае не хочу как-то принизить твои заслуги.

-- 
Alexey Shabalin

Re: [devel] Разделение миров systemd и sysv

[Leonid Krivoshein]

25.03.2021 20:28, Alexey Shabalin пишет:
> чт, 18 мар. 2021 г. в 01:43, Dmitry V. Levin <ldv@altlinux.org>:
>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
>> [...]
>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>> А зачем?
>>
>> Дело в том, что make-initrd был сделан в ALT и для ALT, мы умеем его
>> готовить.  Что даст замена make-initrd на dracut, помимо утраты
>> компетенции в этой области?
> А куда денется компетенция в этой области? Она просто так не испарится.
> Из плюсов в dracut (в сравнении с make-initrd):
> - Используется во многих дистрибутивах: fedora, RHEL, openSUSE, Void.
> - Не используется по-умолчанию, но может использоваться и присутствует
> в репо у Gentoo, Debian, OpenMandriva, Magea, Arch
> См. - https://en.wikipedia.org/wiki/Dracut_(software)
> - разобраться в работе dracut не сложнее, чем в make-initrd
> - понятная документация. (по документации make-initrd не всегда
> получается ожидаемый результат. например чтобы получить shell в
> initrd, прочитать документацию по make-initrd недостаточно, пришлось
> еще залезть в код и смотреть как он работает.)
> - многие апстримы сразу поддерживают dracut (plymouth, ignition). Для
> make-initrd нужно реализовывать этот функционал самостоятельно.
> - dracut может также использоваться на системах с sysv, но я не
> предлагаю вам этого делать :)
> - внутри initrd используется systemd, такой же как и в системе, как
> следствие более понятная и единообразная загрузка системы. Более
> плавная что ли :) не знаю какое определение подобрать :)
> - больше различных модулей. например systemd-networkd. Ожидать его
> поддержки в make-initrd просто не реально.
>
> Минусы make-initrd
> - используется только в одном дистрибутиве
> - проект одного человека
> - Компетенции поддерживать предыдущие стабильные версии без основного
> разработчика у нас также нет. А его по понятным причинам не интересуют
> стабильные бранчи. Поэтому в p9 пришлось переходить на make-initrd2.
> - как в любом открытом проекте, необходимую фичу придется
> разрабатывать самостоятельно. тут нет никакой разницы с dracut.
>
> PS: to legion@ я ценю и уважаю проделанную тобой работу. Ни в коем
> случае не хочу как-то принизить твои заслуги.

Во многом согласен и добавлю:

- На текущий момент более 300 разработчиков, более года назад смотрел -- 
их было 60.
   Многие из них так же пилят systemd, который event-driven на Си, а не 
скриптах.
- Значительно более широкая поддержка всего, с чего можно загрузиться.
   К примеру, не хватившей у нас на днях DASD на Power9:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/95dasd
- Более простая и ясная для меня реализация этой поддержки -- shell, а 
не make.

Тем не менее, очень мало случаев, где именно systemd может понадобиться 
в rescue/live/install в stage0. И потому выбор средства создания 
initrams должен быть за выпускающим меинтейнером, а подтягивание в 
make-initrd нужных фич даже из того же dracut -- не делом одного 
разработчика. От возможности выбора (в репозитории) и честной 
конкуренции уж точно хуже не будет.


Отдельно отмечу: мы начали на практике осваивать фичу pipeline и она 
реально впечатляет. Очень хочется избавиться от propagator хотя бы к 
p10. Это даст возможность грузиться с шифрованных томов LUKS1, LUKS2, 
токенов, это обеспечит запрашиваемый иногда аналог liveroot из Ubuntu, 
избавит нас от старого хлама. legion@ проделал большую работу для этого.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Разделение миров systemd и sysv

[Michael Shigorin]

On Thu, Mar 25, 2021 at 09:33:07PM +0300, Leonid Krivoshein wrote:
> - Более простая и ясная для меня реализация этой поддержки --
> shell, а не make.

Замечу, что прочитанный от корки до корки GNU Make Manual:
http://www.gnu.org/software/make/manual/make.html
-- для меня оказалось неплохим вложением времени;
читается довольно легко, десять лет спустя продолжаю
порой кому-нибудь чего-нибудь по make(1) подсказывать.

> [...] legion@ проделал большую работу для этого.

Причём на него, в отличие от апстрима dracut,
мне лично полагаться спокойно.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Разделение миров systemd и sysv

[Konstantin Lepikhov]

Hi Alexey!

On 03/25/2021, at 08:28:18 PM you wrote:

> чт, 18 мар. 2021 г. в 01:43, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> > [...]
> > > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> >
> > А зачем?
> >
> > Дело в том, что make-initrd был сделан в ALT и для ALT, мы умеем его
> > готовить.  Что даст замена make-initrd на dracut, помимо утраты
> > компетенции в этой области?
> 
> А куда денется компетенция в этой области? Она просто так не испарится.
> Из плюсов в dracut (в сравнении с make-initrd):
> - Используется во многих дистрибутивах: fedora, RHEL, openSUSE, Void.
Используется и поддерживается это разные вещи. Не надо забывать, что
dracut это продукт исключительно RH под нужды RH и в этом он ничем не
лучше, чем make-initrd.

> - Не используется по-умолчанию, но может использоваться и присутствует
> в репо у Gentoo, Debian, OpenMandriva, Magea, Arch
> См. - https://en.wikipedia.org/wiki/Dracut_(software)
> - разобраться в работе dracut не сложнее, чем в make-initrd
Это ваше утверждение, ничем не подкрепленное.

> - понятная документация. (по документации make-initrd не всегда
> получается ожидаемый результат. например чтобы получить shell в
> initrd, прочитать документацию по make-initrd недостаточно, пришлось
> еще залезть в код и смотреть как он работает.)
Это ваше утверждение, ничем не подкрепленное. Документация по dracut
распылена по куче мест и дистрибутивов, некоторые опции могут
отсутствовать (привет, RHEL). В make-initrd русскоязычный разрабочик и вы
не можете с ним пообщаться и помочь улучшить документацию? Oh way, опять
эти русские чем-то недовольны.


> - многие апстримы сразу поддерживают dracut (plymouth, ignition). Для
> make-initrd нужно реализовывать этот функционал самостоятельно.
Апстримы где? Это еще одни продукты определенных дистрибутивов.

> - dracut может также использоваться на системах с sysv, но я не
> предлагаю вам этого делать :)
И не надо. Лучше не знать, как он там работает.

> - внутри initrd используется systemd, такой же как и в системе, как
> следствие более понятная и единообразная загрузка системы. Более
> плавная что ли :) не знаю какое определение подобрать :)
Бла-бла-бла.

> - больше различных модулей. например systemd-networkd. Ожидать его
> поддержки в make-initrd просто не реально.
Зачем? Ваш networkd даже с lxc не работает как надо. См.
https://github.com/systemd/systemd/issues/15101

> 
> Минусы make-initrd
> - используется только в одном дистрибутиве
> - проект одного человека
> - Компетенции поддерживать предыдущие стабильные версии без основного
> разработчика у нас также нет. А его по понятным причинам не интересуют
> стабильные бранчи. Поэтому в p9 пришлось переходить на make-initrd2.
> - как в любом открытом проекте, необходимую фичу придется
> разрабатывать самостоятельно. тут нет никакой разницы с dracut.
> 
> PS: to legion@ я ценю и уважаю проделанную тобой работу. Ни в коем
> случае не хочу как-то принизить твои заслуги.
Алексей, если вам так противен альт и приятна федора, зачем это здесь
писать?

-- 
WBR et al.

Re: [devel] Разделение миров systemd и sysv

[Michael Shigorin]

On Thu, Mar 25, 2021 at 08:55:18PM +0300, Aleksey Novodvorsky wrote:
> Лично я предпочитаю свои собственные ошибки вынужденным чужим.
> Тем более в наше сумбурное время.
> Но это общее соображение, пусть для меня и важное.

+1!

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

[devel] dracut (Re: Разделение миров systemd и sysv)

[Alexey Sheplyakov]

Добрый вечер!

On 18.03.2021 02:43, Dmitry V. Levin wrote:
> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> [...]
>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> 
> А зачем?

Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
происходила без участия человека (и/или доступности ключей на съемных носителях).

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Anton Farygin]

On 25.03.2021 22:36, Alexey Sheplyakov wrote:
> Добрый вечер!
>
> On 18.03.2021 02:43, Dmitry V. Levin wrote:
>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
>> [...]
>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>> А зачем?
> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
> Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
> происходила без участия человека (и/или доступности ключей на съемных носителях).
>
Так это надо сделать, фича классная, но пока была никому не нужна.

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Andrey Savchenko]

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

On Fri, 26 Mar 2021 12:19:50 +0300 Anton Farygin wrote:
> On 25.03.2021 22:36, Alexey Sheplyakov wrote:
> > Добрый вечер!
> >
> > On 18.03.2021 02:43, Dmitry V. Levin wrote:
> >> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> >> [...]
> >>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> >> А зачем?
> > Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
> > Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
> > происходила без участия человека (и/или доступности ключей на съемных носителях).
> >
> Так это надо сделать, фича классная, но пока была никому не нужна.

Сотрудники NSA одобряют. Больше завязок на TPM!
Усилим национальную безопасность США!

Best regards,
Andrew Savchenko

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

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Anton Farygin]

On 26.03.2021 12:52, Andrey Savchenko wrote:
> On Fri, 26 Mar 2021 12:19:50 +0300 Anton Farygin wrote:
>> On 25.03.2021 22:36, Alexey Sheplyakov wrote:
>>> Добрый вечер!
>>>
>>> On 18.03.2021 02:43, Dmitry V. Levin wrote:
>>>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
>>>> [...]
>>>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>>>> А зачем?
>>> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
>>> Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
>>> происходила без участия человека (и/или доступности ключей на съемных носителях).
>>>
>> Так это надо сделать, фича классная, но пока была никому не нужна.
> Сотрудники NSA одобряют. Больше завязок на TPM!
> Усилим национальную безопасность США!

Никто не запрещает добавить в tpm россиские реализации.

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Andrey Savchenko]

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

On Fri, 26 Mar 2021 14:04:38 +0300 Anton Farygin wrote:
> On 26.03.2021 12:52, Andrey Savchenko wrote:
> > On Fri, 26 Mar 2021 12:19:50 +0300 Anton Farygin wrote:
> >> On 25.03.2021 22:36, Alexey Sheplyakov wrote:
> >>> Добрый вечер!
> >>>
> >>> On 18.03.2021 02:43, Dmitry V. Levin wrote:
> >>>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> >>>> [...]
> >>>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> >>>> А зачем?
> >>> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
> >>> Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
> >>> происходила без участия человека (и/или доступности ключей на съемных носителях).
> >>>
> >> Так это надо сделать, фича классная, но пока была никому не нужна.
> > Сотрудники NSA одобряют. Больше завязок на TPM!
> > Усилим национальную безопасность США!
> 
> Никто не запрещает добавить в tpm россиские реализации.

С каких это пор прошивка TPM стала открытой?
Если добавите — хорошо, но я в это не верю, пока обратное не
доказано экспериментально.

Best regards,
Andrew Savchenko

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

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Anton Farygin]

On 26.03.2021 15:42, Andrey Savchenko wrote:
> On Fri, 26 Mar 2021 14:04:38 +0300 Anton Farygin wrote:
>> On 26.03.2021 12:52, Andrey Savchenko wrote:
>>> On Fri, 26 Mar 2021 12:19:50 +0300 Anton Farygin wrote:
>>>> On 25.03.2021 22:36, Alexey Sheplyakov wrote:
>>>>> Добрый вечер!
>>>>>
>>>>> On 18.03.2021 02:43, Dmitry V. Levin wrote:
>>>>>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
>>>>>> [...]
>>>>>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>>>>>> А зачем?
>>>>> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
>>>>> Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
>>>>> происходила без участия человека (и/или доступности ключей на съемных носителях).
>>>>>
>>>> Так это надо сделать, фича классная, но пока была никому не нужна.
>>> Сотрудники NSA одобряют. Больше завязок на TPM!
>>> Усилим национальную безопасность США!
>> Никто не запрещает добавить в tpm россиские реализации.
> С каких это пор прошивка TPM стала открытой?
> Если добавите — хорошо, но я в это не верю, пока обратное не
> доказано экспериментально.

Со стороны linux'а всё открытое, т.е. - интерфейсы все известны.

Я точно не буду это добавлять - это задача для железячных контор. И, 
если я не ошибаюсь, кто-то в России что-то подобное для x86 делал.

"  Модуль Kraftway TPM на базе изделия компании «Актив» «Рутокен ЭЦП». 
Специализированное защищённое энергонезависимое хранилище в форм-факторе 
USB объёмом 8 ГБ, доступное только из KSS на уровне UEFI, с функцией 
датчика случайных чисел и СКЗИ с функцией генерации ключевой информации 
и хранения сертификатов;"

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Leonid Krivoshein]

26.03.2021 12:19, Anton Farygin пишет:
> On 25.03.2021 22:36, Alexey Sheplyakov wrote:
>> Добрый вечер!
>>
>> On 18.03.2021 02:43, Dmitry V. Levin wrote:
>>> On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
>>> [...]
>>>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>>> А зачем?
>> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, 
>> например.
>> Чтобы можно было зашифровать весь диск с rootfs, и при этом 
>> (пере)загрузка ОС
>> происходила без участия человека (и/или доступности ключей на съемных 
>> носителях).
>>
> Так это надо сделать, фича классная, но пока была никому не нужна.
>

Коллеги из Актива почти сами, но немного с нашей помощью реализовали 
загрузку с шифрованного корня на токене, используя новую фичу pipeline 
из make-initrd: 
https://github.com/lo1ol/make-initrd-flash-unlock/tree/master/flash-unlock 
, но с тем же успехом можно использовать LUKS1, LUKS2 (который понимает 
токены) и pipeline из make-initrd для загрузки с шифрованного корня.

Кстати, Антон, а ты не знаешь ничего про патчи grub для загрузки с 
LUKS2? LUKS1 он и сейчас умеет.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Nikolai Kostrigin]

26.03.2021 14:27, Leonid Krivoshein пишет:
> 

> 
> Кстати, Антон, а ты не знаешь ничего про патчи grub для загрузки с
> LUKS2? LUKS1 он и сейчас умеет.
> 
> 
grub-2.06-rc1 готовится отправиться в Сизиф.
Там есть упоминания о поддержке LUKS2, но на практике не проверялось.

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Konstantin Lepikhov]

Hi Alexey!

On 03/25/2021, at 11:36:20 PM you wrote:

> Добрый вечер!
> 
> On 18.03.2021 02:43, Dmitry V. Levin wrote:
> > On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> > [...]
> >> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> > 
> > А зачем?
> 
> Монтирование зашифрованной rootfs с использованием ключей из TPM 2.0, например.
> Чтобы можно было зашифровать весь диск с rootfs, и при этом (пере)загрузка ОС
> происходила без участия человека (и/или доступности ключей на съемных носителях).
Все уже придумано и проверено давным-давно. См.

https://www.slideshare.net/IgnatKorchagin/managing-server-secrets-at-scale-with-saltstack-and-a-vaultless-password-manager

и насчет TPM
https://blog.cloudflare.com/anchoring-trust-a-hardware-secure-boot-story/

-- 
WBR et al.

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Alexey V. Vissarionov]

On 2021-03-25 23:36:20 +0400, Alexey Sheplyakov wrote:

 >>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
 >> А зачем?
 > Монтирование зашифрованной rootfs с использованием ключей из
 > TPM 2.0, например.

Не напомнишь ли почтенной публике, для кого TPM является T?

 > Чтобы можно было зашифровать весь диск с rootfs, и при этом
 > (пере)загрузка ОС происходила без участия человека (и/или
 > доступности ключей на съемных носителях).

Это делается немного по-другому. И уже почти 15 лет.


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

Re: [devel] dracut (Re: Разделение миров systemd и sysv)

[Denis Medvedev]

On Wed, 31 Mar 2021 13:00:18 +0300
"Alexey V. Vissarionov" <gremlin@altlinux.org> wrote:

> On 2021-03-25 23:36:20 +0400, Alexey Sheplyakov wrote:
> 
>  >>> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
>  >> А зачем?
>  > Монтирование зашифрованной rootfs с использованием ключей из
>  > TPM 2.0, например.
> 
> Не напомнишь ли почтенной публике, для кого TPM является T?
Для контролирующих реализацию сего хардверного интерфейса и доверяющих
им, а что?
В "наших" архитектурах может быть построена своя реализация TPM (даже с
ГОСТ, почему нет?) но с тем же интерфейсом.

> 
>  > Чтобы можно было зашифровать весь диск с rootfs, и при этом
>  > (пере)загрузка ОС происходила без участия человека (и/или
>  > доступности ключей на съемных носителях).
> 
> Это делается немного по-другому. И уже почти 15 лет.
> 
> 

Re: [devel] Разделение миров systemd и sysv

[Andrey Savchenko]

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

On Wed, 17 Mar 2021 23:00:08 +0300 Alexey Shabalin wrote:
> пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > >
> > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > ядрах зависимость на пакет startup.
> >
> > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > пока они оба используют udevd.
> 
> Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> ли она сейчас.
> 
> Давайте наметим план по разделению миров systemd и sysv.
> Постараемся сделать из самодостаточными, что бы не было лишних
> зависимостей ни в одном из миров.

Это технически невозможно без создания отдельного репозитория для
systemd, поскольку нет возможности динамической замины
systemd-logind на elogind и приложения можно слинковать только с
чем-то одним.
 
> 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)

У нас сообщество, так что личные хотелки следует поумерить. Мне,
например, мешает libsystemd.so своим наличием. И это не просто
место на диске — она загружается в память разными приложениями, что
я считаю совершенно неприемлемым и отношу к серьёзной уязвимости,
ограничивающей применимость дистрибутива:

# lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
colord
cups-browsed
cupsd
dbus-daemon
rpcbind
syslog-ng
tor
unbound

Ну и зачем этим процессам libsystemd? Особенно на системе без
systemd.

Однако, в рамках единого бинарного репозитория невозможно очистить
все пакеты от этой избыточной зависимости, поэтому придётся
сосуществовать вместе. Точно так же и тебе придётся тянуть
standalone подпакеты.

> 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> На самом деле тут больше вопросов к нашему
> /sbin/installkernel(bootloader-utils). И да, он к dracut не
> адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> /sbin/kernel-install(в systemd)
> Так же нужно будет исправить зависимости в kernel-image. Там до сих
> пор указаны module-init-tools и mkinitrd.

Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
очевидны — потеря контроля над развитием ключевого компонента.
 
Best regards,
Andrew Savchenko

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

Re: [devel] Разделение миров systemd и sysv

[Sergey Afonin]

On Friday 19 March 2021, Andrey Savchenko wrote:

> # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
>
> syslog-ng
> 
> Ну и зачем этим процессам libsystemd? Особенно на системе без
> systemd.

Действительно интересно. Я что-то даже и не смотрел, и полагал,
что оно только для syslog-ng-journal нужно. А так как udev у меня
везде, то и внимания не обратил, кто ещё этот libsystemd хочет.
Попробую понять.

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

Re: [devel] Разделение миров systemd и sysv

[Sergey Y. Afonin]

On Friday 19 March 2021, Sergey Afonin wrote:

> > # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
> >
> > syslog-ng
> > 
> > Ну и зачем этим процессам libsystemd? Особенно на системе без
> > systemd.
> 
> Действительно интересно. Я что-то даже и не смотрел, и полагал,
> что оно только для syslog-ng-journal нужно. А так как udev у меня
> везде, то и внимания не обратил, кто ещё этот libsystemd хочет.
> Попробую понять.
 
В общем есть syslog-ng/modules/afsocket/systemd-syslog-source.c
Там есть

#if SYSLOG_NG_ENABLE_SYSTEMD

#include <systemd/sd-daemon.h>

static gboolean
systemd_syslog_sd_acquire_socket(AFSocketSourceDriver *s,
                                 gint *acquired_fd)
{
<тут всякий код>
}

#else
static gboolean
systemd_syslog_sd_acquire_socket(AFSocketSourceDriver *s,
                                 gint *acquired_fd)
{
  return TRUE;
}

#endif

Можно ли и правильно ли переписать systemd_syslog_sd_acquire_socket() без
systemd/sd-daemon.h пока не знаю.

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

Re: [devel] Разделение миров systemd и sysv

[Alexey Shabalin]

пт, 19 мар. 2021 г. в 11:42, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Wed, 17 Mar 2021 23:00:08 +0300 Alexey Shabalin wrote:
> > пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > > >
> > > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > > ядрах зависимость на пакет startup.
> > >
> > > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > > пока они оба используют udevd.
> >
> > Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> > ли она сейчас.
> >
> > Давайте наметим план по разделению миров systemd и sysv.
> > Постараемся сделать из самодостаточными, что бы не было лишних
> > зависимостей ни в одном из миров.
>
> Это технически невозможно без создания отдельного репозитория для
> systemd, поскольку нет возможности динамической замины
> systemd-logind на elogind и приложения можно слинковать только с
> чем-то одним.

Я никак не упоминал logind. Все что я упоминал, технически возможно реализовать.

>
> > 1) сейчас мне под systemd мешают standalone пакеты (своим присутствием :)
>
> У нас сообщество, так что личные хотелки следует поумерить.

Почему? я не являюсь члеом сообщества?
Именно желания конкретных людей из сообщества что-то и двигают вперед.
Если нет хотелок, то никто и не возьмется делать задачу в открытом сообществе.
Если личные хотелки не противоречат желаниям сообщества, то в чем проблема.
Как хотелка избавится от tmpfiles.standalone на системе с systemd
отражается на тебе, пользователе sysv?
В конкретном этом случае, тебе все равно.

> Мне,
> например, мешает libsystemd.so своим наличием. И это не просто
> место на диске — она загружается в память разными приложениями, что
> я считаю совершенно неприемлемым и отношу к серьёзной уязвимости,
> ограничивающей применимость дистрибутива:

Вот когда мне что-то мешает, я пытаюсь поднять вопрос, дискуссию,
выработать техническое решение.

>
> # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
> colord
> cups-browsed
> cupsd
> dbus-daemon
> rpcbind
> syslog-ng
> tor
> unbound
>
> Ну и зачем этим процессам libsystemd? Особенно на системе без
> systemd.
>
> Однако, в рамках единого бинарного репозитория невозможно очистить
> все пакеты от этой избыточной зависимости, поэтому придётся
> сосуществовать вместе. Точно так же и тебе придётся тянуть
> standalone подпакеты.

Нет, standalone упакованы в отдельные пакеты. Это совсем другой случай

>
> > 2) предлагаю под systemd перейти на dracut вместо make-initrd.
> > В сизифе dracut уже есть, у меня работает несколько месяцев, все устраивает.
> > На самом деле тут больше вопросов к нашему
> > /sbin/installkernel(bootloader-utils). И да, он к dracut не
> > адаптирован. По-хорошему его нужно распилить на отдельные скрипты в
> > /(etc|usr/lib)/kernel/install.d или плавно перейти на использование
> > /sbin/kernel-install(в systemd)
> > Так же нужно будет исправить зависимости в kernel-image. Там до сих
> > пор указаны module-init-tools и mkinitrd.
>
> Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
> очевидны — потеря контроля над развитием ключевого компонента.

-- 
Alexey Shabalin

[devel] libsystemd (Re: Разделение миров systemd и sysv)

[Alexey Sheplyakov]

Добрый день!

On 19.03.2021 12:42, Andrey Savchenko wrote:

> # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
> colord
> cups-browsed
> cupsd
> dbus-daemon
> rpcbind
> syslog-ng
> tor
> unbound
> 
> Ну и зачем этим процессам libsystemd?

В основном для sd_notify

https://www.freedesktop.org/software/systemd/man/sd_notify.html

Пример: веб-приложению нужна БД. Причем наличие процесса mysqld необходимо,
но не достаточно. Нужно, чтобы в момент запуска приложения mysqld уже слушал
на своем сокете. init не может (и не должен) догадаться, в какой именно
момент mysqld сможет принимать запросы. А вот mysqld вполне может уведомить
init "я готов". И получив такое уведомление, init может смело запускать
сервисы, зависящие от mysqld. sd_notify как раз и позволяет сервису оповестить
init (причем не только о успешном старте).

> Однако, в рамках единого бинарного репозитория невозможно очистить
> все пакеты от этой избыточной зависимости,

Потому что она необходимая. Если Вам нравится в уме вычислять,
в каком порядке нужно (пере)запускать сервисы (или делать еще
какую-нибудь нудную работу, которую можно и нужно поручить
компьютеру) - пожалуйста, сколько угодно. Только не надо всех
насильно загонять в каменный век.


> Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
> очевидны — потеря контроля над развитием ключевого компонента.

<sarcasm>
Ну остальные-то ключевые компоненты мы контролируем:
Linux (ядро), glibc, GCC, Mesa, GTK, Qt и далее со всеми остановками.
</sarcasm>

Re: [devel] libsystemd (Re: Разделение миров systemd и sysv)

[Andrey Savchenko]

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

On Fri, 26 Mar 2021 13:45:49 +0400 Alexey Sheplyakov wrote:
> Добрый день!
> 
> On 19.03.2021 12:42, Andrey Savchenko wrote:
> 
> > # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
> > colord
> > cups-browsed
> > cupsd
> > dbus-daemon
> > rpcbind
> > syslog-ng
> > tor
> > unbound
> > 
> > Ну и зачем этим процессам libsystemd?
> 
> В основном для sd_notify
> 
> https://www.freedesktop.org/software/systemd/man/sd_notify.html
> 
> Пример: веб-приложению нужна БД. Причем наличие процесса mysqld необходимо,
> но не достаточно. Нужно, чтобы в момент запуска приложения mysqld уже слушал
> на своем сокете. init не может (и не должен) догадаться, в какой именно
> момент mysqld сможет принимать запросы. А вот mysqld вполне может уведомить
> init "я готов". И получив такое уведомление, init может смело запускать
> сервисы, зависящие от mysqld. sd_notify как раз и позволяет сервису оповестить
> init (причем не только о успешном старте).
> 
> > Однако, в рамках единого бинарного репозитория невозможно очистить
> > все пакеты от этой избыточной зависимости,
> 
> Потому что она необходимая. Если Вам нравится в уме вычислять,
> в каком порядке нужно (пере)запускать сервисы (или делать еще
> какую-нибудь нудную работу, которую можно и нужно поручить
> компьютеру) - пожалуйста, сколько угодно. Только не надо всех
> насильно загонять в каменный век.

Каким образом sd-notify используется в Альте на системах с init?
По-моему, это мёртвый груз.

> > Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
> > очевидны — потеря контроля над развитием ключевого компонента.
> 
> <sarcasm>
> Ну остальные-то ключевые компоненты мы контролируем:
> Linux (ядро), glibc, GCC, Mesa, GTK, Qt и далее со всеми остановками.
> </sarcasm>

Вообще-то, на glibc мы очень даже влияем. Сюрприз?

Best regards,
Andrew Savchenko

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

Re: [devel] libsystemd (Re: Разделение миров systemd и =?utf-8?b?IHN5c3Y=?=)

[Sergey Afonin]

On Friday 26 March 2021, Alexey Sheplyakov wrote:

> Пример: веб-приложению нужна БД. Причем наличие процесса mysqld
> необходимо, но не достаточно. Нужно, чтобы в момент запуска 
> приложения mysqld уже слушал на своем сокете.

Зачем? Почему веб-приложение не может подождать и повторить? 
А если бд просто перезапустили в какой-то момент? Другой 
механизм в приложении реализовывать?

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

Re: [devel] libsystemd (Re: Разделение миров systemd и sysv)

[Arseny Maslennikov]

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

On Fri, Mar 26, 2021 at 01:45:49PM +0400, Alexey Sheplyakov wrote:
> Добрый день!
> 
> On 19.03.2021 12:42, Andrey Savchenko wrote:
> 
> > # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
> > colord
> > cups-browsed
> > cupsd
> > dbus-daemon
> > rpcbind
> > syslog-ng
> > tor
> > unbound
> > 
> > Ну и зачем этим процессам libsystemd?
> 
> В основном для sd_notify
> 
> https://www.freedesktop.org/software/systemd/man/sd_notify.html

...Там внутри сокет по номеру fd (или пути, не помню), указанному в
конкретной переменной окружения, в который пишут сообщеньки с текстовыми
строчками вроде READY=1, снабжённые peercred — и никакой магии.
https://github.com/systemd/systemd/blob/fe96c0f86d15e844d74d539c6cff7f971078cf84/src/libsystemd/sd-daemon/sd-daemon.c#L440
В самом протоколе ничего не намекает на systemd, можно спокойно
реализовывать в аналогах.

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

> 
> Пример: веб-приложению нужна БД. Причем наличие процесса mysqld необходимо,
> но не достаточно. Нужно, чтобы в момент запуска приложения mysqld уже слушал
> на своем сокете. init не может (и не должен) догадаться, в какой именно
> момент mysqld сможет принимать запросы. А вот mysqld вполне может уведомить
> init "я готов". И получив такое уведомление, init может смело запускать
> сервисы, зависящие от mysqld. sd_notify как раз и позволяет сервису оповестить
> init (причем не только о успешном старте).
> 
> > Однако, в рамках единого бинарного репозитория невозможно очистить
> > все пакеты от этой избыточной зависимости,
> 
> Потому что она необходимая. Если Вам нравится в уме вычислять,
> в каком порядке нужно (пере)запускать сервисы (или делать еще
> какую-нибудь нудную работу, которую можно и нужно поручить
> компьютеру) - пожалуйста, сколько угодно. Только не надо всех
> насильно загонять в каменный век.
> 
> 
> > Здесь Дима уже ответил: выгоды такого перехода не ясны, недостатки
> > очевидны — потеря контроля над развитием ключевого компонента.
> 
> <sarcasm>
> Ну остальные-то ключевые компоненты мы контролируем:
> Linux (ядро), glibc, GCC, Mesa, GTK, Qt и далее со всеми остановками.
> </sarcasm>

Контроль — это не только явная власть, но и возможность договориться с
апстримом в случае возникновения проблем. Первые трое достаточно
договороспособны (а ldv@ и вовсе вхож в glibc), а два последних не
вызывают дистрибутивных проблем (т. е. при условии, что они
упаковываются и мейнтейнятся, приложения с ними просто работают
одинаково во всех дистрибутивах, которые не лезут значительно в их
кишки; например, в ubuntu когда-то подхакивали gtk)
Про mesa ничего не знаю.

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

Re: [devel] libsystemd (Re: Разделение миров systemd и sysv)

[Alexey V. Vissarionov]

On 2021-03-26 13:45:49 +0400, Alexey Sheplyakov wrote:

 >> # lsof +c0 -n 2>/dev/null | grep libsystemd | mawk '{print $1}' | sort -u
 >> colord
 >> cups-browsed
 >> cupsd
 >> dbus-daemon
 >> rpcbind
 >> syslog-ng
 >> tor
 >> unbound
 >> Ну и зачем этим процессам libsystemd?
 > В основном для sd_notify

Без него можно обойтись? Можно. Значит, вырезать этот рак нещадно.

 > Пример: веб-приложению нужна БД. Причем наличие процесса mysqld
 > необходимо, но не достаточно. Нужно, чтобы в момент запуска
 > приложения mysqld уже слушал на своем сокете.

Классическая ошибка человека, который никогда не администрировал
критичные сервисы (у которых ущерб от простоя измеряется сотнями
килорублей в минуту)...

 > init не может (и не должен) догадаться, в какой именно момент
 > mysqld сможет принимать запросы. А вот mysqld вполне может
 > уведомить init "я готов".

А теперь придумай способ сделать то же самое в ситуации, когда БД
и уеб-сервис работают на разных компутерах. Придумал? Теперь думай,
как сделать это решение универсальным - для всех видов БД (ладно,
ограничимся Mongo + MySQL + PostgreSQL). Не получается? Да, я знаю,
что эта задача общего решения не имеет. Более того, это знают даже
быдлокодеры, которые клепают уеб-сервисы. А разработчики ОС, как
выясняется, об этом даже никогда не задумывались.

 > И получив такое уведомление, init может смело запускать
 > сервисы, зависящие от mysqld. sd_notify как раз и позволяет
 > сервису оповестить init (причем не только о успешном старте).

В том числе на другом сервере? Если да - как? Если нет - нахрена
оно такое нужно?

 >> Однако, в рамках единого бинарного репозитория невозможно
 >> очистить все пакеты от этой избыточной зависимости,
 > Потому что она необходимая.

Она именно избыточная.

 > Если Вам нравится в уме вычислять, в каком порядке нужно
 > (пере)запускать сервисы (или делать еще какую-нибудь нудную
 > работу, которую можно и нужно поручить компьютеру) -
 > пожалуйста, сколько угодно. Только не надо всех насильно
 > загонять в каменный век.

А что надо? Сломать всем ноги и раздать современные костыли?
Что-то много таких благодетелей развелось...

Кто как, а лично я за попытку сломать мне ноги просто оторву
голову. Особенно с учетом того, что авторы подобных идей, как
правило, ей все равно не пользуются.


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

Re: [devel] Разделение миров systemd и sysv

[Arseny Maslennikov]

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

On Wed, Mar 17, 2021 at 11:00:08PM +0300, Alexey Shabalin wrote:
> пт, 5 февр. 2021 г. в 13:55, Alexey Gladkov <legion@altlinux.ru>:
> > >
> > > Большинство из вышеуказанного я могу перенести в systemd и поставить
> > > конфликт на startup. Только сизиф такое не переживет :) у нас даже в
> > > ядрах зависимость на пакет startup.
> >
> > udevd требует systemd-utils. Разделение миров systemd и sysv невозможно
> > пока они оба используют udevd.
> 
> Эта зависимость выставлена вручную. Надо еще раз посмотреть, актуальна
> ли она сейчас.
> 
> Давайте наметим план по разделению миров systemd и sysv.
> Постараемся сделать из самодостаточными, что бы не было лишних
> зависимостей ни в одном из миров.

Не сводится ли этот план целиком к ликвидации паразитных зависимостей на
startup? (мол, остальные шаги каждый мейнтейнер может предпринять сам
без необходимости координировать сообщество)?

Что же касается этой самой ликвидации: задача "отпилить от пакета
startup всё, что не связано с sysv-инит-последовательностью" проще, чем
задача "перетащить всё в этой вселенной с одних конфигов на другие".
Я бы предложил браться за первую формулировку, а про вторую думать потом.


Если мы всё же решаем сразу вторую, то тогда вопрос к любителям
/etc/sysconfig/*: есть ли у нас документация на всякое /etc/sysconfig/*,
упакованное в пакет startup, по которой человеку независимому можно
понять, зачем оно кому-то нужно? Т. е. вот, допустим, я _ничего_ не знаю
об этих файлах и настраиваю те же clock, i18n (как я понимаю эти
понятия) другими способами и не жалуюсь на результат. Я при таких
вводных никак не могу способствовать предложенному переводу "старых"
конфигов в "новые", и заставить не связанные с /etc/rc.d пакеты не
зависеть от startup тоже не могу.

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

Re: [devel] /etc/sysconfig/{clock,i18n}

[Dmitry V. Levin]

On Mon, Mar 29, 2021 at 09:03:20PM +0300, Arseny Maslennikov wrote:
> [...] вот, допустим, я _ничего_ не знаю
> об этих файлах и настраиваю те же clock, i18n (как я понимаю эти
> понятия) другими способами и не жалуюсь на результат. Я при таких
> вводных никак не могу способствовать предложенному переводу "старых"
> конфигов в "новые", и заставить не связанные с /etc/rc.d пакеты не
> зависеть от startup тоже не могу.

clock:
/etc/sysconfig/clock в пакете самодокументирован, пример использования
в скрипте, который поддерживает /etc/sysconfig/clock и /etc/timezone:
/usr/sbin/tzupdate.

i18n:
/etc/profile.d/lang.sh считает, что /etc/sysconfig/i18n и /etc/locale.conf
- это одно и то же, использует первый, который найдёт.


-- 
ldv

Re: [devel] /etc/sysconfig/{clock,i18n}

[Arseny Maslennikov]

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

On Mon, Mar 29, 2021 at 10:24:37PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 29, 2021 at 09:03:20PM +0300, Arseny Maslennikov wrote:
> > [...] вот, допустим, я _ничего_ не знаю
> > об этих файлах и настраиваю те же clock, i18n (как я понимаю эти
> > понятия) другими способами и не жалуюсь на результат. Я при таких
> > вводных никак не могу способствовать предложенному переводу "старых"
> > конфигов в "новые", и заставить не связанные с /etc/rc.d пакеты не
> > зависеть от startup тоже не могу.
> 
> clock:
> /etc/sysconfig/clock в пакете самодокументирован,

Задокументирован он, к сожалению, лениво — в стиле "Бетономешалка мешает
бетон". :( Впрочем, если бы он был хорошо самодокументирован, документация
бы составляла более 4/5 его длины.
Воздержусь от подробного разбора, чтобы не засорять рассылку — благо
стало и так понятно, что делать.


> пример использования
> в скрипте, который поддерживает /etc/sysconfig/clock и /etc/timezone:
> /usr/sbin/tzupdate.

Гм.
Пусть тут на всякий случай будет altlinux-classic-clock.service, исполняющий
/etc/rc.d/init.d/clock, который стоит положить в пакет к нему, если это
не будет startup.

Вот канва этого юнита:
---8<--------
[Unit]
Description=/etc/rc.d/init.d/clock
Documentation=

[Service]
Type=oneshot
ExecStart=/etc/rc.d/init.d/clock start
ExecStop=/etc/rc.d/init.d/clock stop
--->8--------

Видимо, в /etc/sysconfig/clock сошлись два назначения: одно —
настраивать /etc/rc.d/init.d/clock, другое — настраивать $ZONE.

Правильно ли я понял, что /etc/localtime мог бы быть и симлинком на
/usr/share/zoneinfo/$ZONE, но для разных сервисов, которые чрутятся средствами
ALT и исполнимого файла update_chrooted, не реализовано воссоздание этих
путей в чруте — и это единственная помеха к превращению /etc/localtime в
симлинк по умолчанию?
* Если да, то надо ZONE делать необязательным (по умолчанию результат
  readlink, а если не симлинк, то UTC), а остальное в этом файле
  настраивает поведение /etc/rc.d/init.d/clock. Тогда файл можно и в
  пакете startup оставить — или в том, в котором /etc/rc.d/init.d/clock.

Ну, и остался вопрос, кто ещё потребляет /etc/sysconfig/clock, кроме
нижеперечисленного (взятого с моей системы):
# grep -r /etc/sysconfig/clock /usr /etc
/usr/sbin/tzupdate:env_file=/etc/sysconfig/clock
/etc/rc.d/init.d/clock:if SourceIfNotEmpty /etc/sysconfig/clock; then
и только ли ZONE= они от него хотят.

> 
> i18n:
> /etc/profile.d/lang.sh считает, что /etc/sysconfig/i18n и /etc/locale.conf
> - это одно и то же, использует первый, который найдёт.
> 

Правильно ли я понимаю, что формат данных в этих файлах одинаковый, и это
— shell-style связывание параметров вида /(LANG|LC_[A-Z_]*)/ с локалями?
* Если да, то один из этих файлов можно сделать симлинком на другой.

Правда, /lib/systemd/systemd-localed, когда пишет в этот файл (если его
заставить при помощи `localectl set-locale VAR=value'), не сохраняет
комментарии в строках.

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

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey V. Vissarionov]

On 2021-02-05 04:52:47 +0300, Alexey Shabalin wrote:

 >>> 1) на системах с systemd приезжают также и standalone версии,
 >>> которые не нужны. Зачем два экземпляра утилит?
 >>> Вариант решения - либо втянуть нужные файлы (конфиги типа
 >>> /etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо
 >>> выделить их в общий пакет, типа startup-common.

В таких случаях - только отдельный пакет.

 >> А можешь показать список того, что хочет systemd из startup ?
 > Быстрым взглядом: /etc/firsttime.d (под вопросом, вообще я делал
 > altlinux-first_time.service для обработки этой директории)
 > /etc/modules

Отдельный пакет для каталога.

 > /etc/rc.d/scripts/gen_kernel_headers (тут вообще вопрос, точно
 > этот скрипт должен быть в startup?)

Этого скрипта вообще быть не должно. Как и ядерных заголовков на
промышленных системах.

 > /etc/sysconfig/clock (пора отказаться от этих legacy конфигов,
 > но инсталлер и sysv скрипты так никто и не переписал)
 > /etc/sysconfig/i18n (пора отказаться от этих legacy конфигов,
 > но инсталлер и sysv скрипты так никто и не переписал)

И не нужно. Продолжаем тащить.

 > /etc/sysconfig/mouse (под вопросом, кому это вообще нужно?
 > если gpm, то пусть он и носит этот конфиг)

Выкинуть нахрен вместе с gpm. Для копипастинга в консоли уже давно
существует screen.

 > /etc/sysctl.conf

Лучше бы с самого начала в procps, но теперь только в отдельный пакет.

 > /var/lib/rsbac (не пора его вообще убрать?)

Давно пора.

 > /var/log/wtmp /var/run/utmp

Отдельный пакет с %ghost для них.

 > Большинство из вышеуказанного я могу перенести в systemd и
 > поставить конфликт на startup. Только сизиф такое не переживет :)

Когда тебе в голову опять придет такая мысль - лучше застрелись
самостоятельно... :-)

А если серьезно, то поддержка sysVinit - одно из наших важнейших
конкурентных преимуществ.

 > у нас даже в ядрах зависимость на пакет startup.

Да у нас вообще много веселых зависимостей...


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

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Shabalin]

чт, 4 февр. 2021 г. в 18:23, Alexey Shabalin <a.shabalin@gmail.com>:
>
> День добрый.
> startup перешел на использование standalone утилит от systemd (tmpfiles и др)
> Какие я вижу возникшие проблемы:
> 1) на системах с systemd приезжают также и standalone версии, которые
> не нужны. Зачем два экземпляра утилит?
> Вариант решения - либо втянуть нужные файлы (конфиги типа
> /etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо выделить
> их в общий пакет, типа startup-common.
> Как вариант, совсем отказаться от легаси конфигов типа
> /etc/sysconfig/clock, либо перенести их в sysv-специфичный пакет.
>
> 2) на системах с sysv должны ставиться standalone утилиты, а не
> systemd-utils, но при этом нет rpm filetrigger, аналогичных
> systemd-utils. Соответственно при установке пакетов на системах с sysv
> они не отрабатывают, что может привести к некорректной
> работе/установке пакетов.
> Вариант решения - повторить эти rpm filetrigger. Можно их добавить в
> пакеты со standalone утилитами, но пока не решен вопрос с их
> установкой на системы с systemd это будет вызывать проблему двойного
> срабатывания.

3) утилиты без суффикса .standalone могут быть в %post у пакетов. (и
соответственно зависимости на них)
Значит на sysv системах от systemd избавится опять не получится

> В fedora в rpmbuild есть прикольный параметр:
> RemovePathPostfixes: .standalone
> Что позволяет упаковать в пакет файлы, обрезав суффикс.
> Это позволит не переписывать скрипты на использование standalone утилит.
> Добавление этой фичи в наш rpmbuild помогло бы в решении вышеуказанных проблем.
>
> Прошу высказаться, как будем решать вышеуказанные проблемы.
>
> --
> Alexey Shabalin



-- 
Alexey Shabalin

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Fri, Feb 05, 2021 at 04:37:18AM +0300, Alexey Shabalin wrote:
> чт, 4 февр. 2021 г. в 18:23, Alexey Shabalin <a.shabalin@gmail.com>:
> >
> > День добрый.
> > startup перешел на использование standalone утилит от systemd (tmpfiles и др)
> > Какие я вижу возникшие проблемы:
> > 1) на системах с systemd приезжают также и standalone версии, которые
> > не нужны. Зачем два экземпляра утилит?
> > Вариант решения - либо втянуть нужные файлы (конфиги типа
> > /etc/sysconfig/clock, /etc/sysctl.conf) в пакет systemd, либо выделить
> > их в общий пакет, типа startup-common.
> > Как вариант, совсем отказаться от легаси конфигов типа
> > /etc/sysconfig/clock, либо перенести их в sysv-специфичный пакет.
> >
> > 2) на системах с sysv должны ставиться standalone утилиты, а не
> > systemd-utils, но при этом нет rpm filetrigger, аналогичных
> > systemd-utils. Соответственно при установке пакетов на системах с sysv
> > они не отрабатывают, что может привести к некорректной
> > работе/установке пакетов.
> > Вариант решения - повторить эти rpm filetrigger. Можно их добавить в
> > пакеты со standalone утилитами, но пока не решен вопрос с их
> > установкой на системы с systemd это будет вызывать проблему двойного
> > срабатывания.
> 
> 3) утилиты без суффикса .standalone могут быть в %post у пакетов. (и
> соответственно зависимости на них)
> Значит на sysv системах от systemd избавится опять не получится

Пока да. В том числе и вот по этому:

# apt-cache whatdepends systemd-utils |grep -A1 udev-
  udev-1:247.2-alt1:sisyphus+263562.100.1.1@1608151944
    Depends: systemd-utils = 1:247.2-alt1:sisyphus+263562.100.1.1
--
  eudev-3.2.9-alt2:sisyphus+262657.100.1.1@1606568600
    Depends: </sbin/systemd-tmpfiles>

-- 
Rgrds, legion

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Fri, Feb 05, 2021 at 11:24:24AM +0100, Alexey Gladkov wrote:
> > 3) утилиты без суффикса .standalone могут быть в %post у пакетов. (и
> > соответственно зависимости на них)
> > Значит на sysv системах от systemd избавится опять не получится
> 
> Пока да. В том числе и вот по этому:
> 
>   eudev-3.2.9-alt2:sisyphus+262657.100.1.1@1606568600
>     Depends: </sbin/systemd-tmpfiles>

Этот больше не хочет systemd-utils.

-- 
Rgrds, legion

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Shabalin]

пн, 8 февр. 2021 г. в 13:47, Alexey Gladkov <legion@altlinux.ru>:
>
> On Fri, Feb 05, 2021 at 11:24:24AM +0100, Alexey Gladkov wrote:
> > > 3) утилиты без суффикса .standalone могут быть в %post у пакетов. (и
> > > соответственно зависимости на них)
> > > Значит на sysv системах от systemd избавится опять не получится
> >
> > Пока да. В том числе и вот по этому:
> >
> >   eudev-3.2.9-alt2:sisyphus+262657.100.1.1@1606568600
> >     Depends: </sbin/systemd-tmpfiles>
>
> Этот больше не хочет systemd-utils.

Мне кажется, это все полурешения. Предлагаешь вычислить все места, где
используют systemd-tmpfiles и делать обвязку для выбора стандартных
или standalone?
Я уже упоминал где могут использоваться %pre и %post, filetrigger. Их
все не исправишь.
Мне кажется это не вариант. Лучше для standalone предоставить хоть
симлинки на стандартные имена. Хоть alternatives прикрутить, если
боитесь файловых конфликтов.

-- 
Alexey Shabalin

Re: [devel] startup and standalone versions of systemd utilities.

[Alexey Gladkov]

On Tue, Feb 09, 2021 at 01:42:56PM +0300, Alexey Shabalin wrote:
> пн, 8 февр. 2021 г. в 13:47, Alexey Gladkov <legion@altlinux.ru>:
> >
> > On Fri, Feb 05, 2021 at 11:24:24AM +0100, Alexey Gladkov wrote:
> > > > 3) утилиты без суффикса .standalone могут быть в %post у пакетов. (и
> > > > соответственно зависимости на них)
> > > > Значит на sysv системах от systemd избавится опять не получится
> > >
> > > Пока да. В том числе и вот по этому:
> > >
> > >   eudev-3.2.9-alt2:sisyphus+262657.100.1.1@1606568600
> > >     Depends: </sbin/systemd-tmpfiles>
> >
> > Этот больше не хочет systemd-utils.
> 
> Мне кажется, это все полурешения. Предлагаешь вычислить все места, где
> используют systemd-tmpfiles и делать обвязку для выбора стандартных
> или standalone?

Я лишь убрал явную неправильную зависимость. Этот пакет имеет право
требовать standalone в явном виде.

> Я уже упоминал где могут использоваться %pre и %post, filetrigger. Их
> все не исправишь.
> Мне кажется это не вариант. Лучше для standalone предоставить хоть
> симлинки на стандартные имена. Хоть alternatives прикрутить, если
> боитесь файловых конфликтов.

alternatives могут тут помочь. Правда выглядит тут как абьюз, потому что
их переключение пользователем не имеет смысла. Хотя согласен, что это
решит проблему с разными именами.

-- 
Rgrds, legion