[devel-distro] branding

[devel-distro] branding

[Alexey Shabalin]

День добрый.
Есть несколько вопросов для обсуждения по поводу наших branding.

1) /etc/altlinux-release и /etc/os-release
После коммита, который разошелся по всем брэндингам
http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
Как они создаются при установке, никакое обновление их больше не обновляет.
Это нарушает ожидаемое поведение во многих скриптах и системах
автоматизированного управления. Я могу привести примеры, если нужно,
кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
что в них используется текущее состояние версии, а не на момент
установки.
Так же мне кажется, это может нарушать и договорные отношения (люди
которые обновились на новый бранч этого не увидят, а люди которым по
договорам нельзя обновляться на новые релизы сделают это без проблем -
вывеска, версия платформы, не изменилась, значит можно)

Предлагаю откатить это изменение во всех branding для всех дистрибутивов.

Так же считаю делать что-то в %post с лицензией излишне.
Если лицензия изменилась, надо её доставить. Если есть юридические
проблемы, надо отразить в лицензии, что правообладатель имеет право
менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
юристы прокомментируют.
Если в лицензии правообладатель сменился с Альтлинук на Базальт, то
тем более надо менять лицензию - Альтлинукс еще можно найти?
Если кого-то не устраивает изменение лицензии, значит они не должны обновляться.

2) Обновление оформления при обновлении
Так же не происходит обновление bootsplash
%post bootsplash
[ "$1" -eq 1 ] || exit 0

Мне кажется, что пользователь должен явно увидеть обновление
оформления своей системы при обновлении на новый бранч. Иначе зачем
вообще обновляются пакеты с оформлением, если изменений в оформлении
не видно. (У меня есть посылка для вашего мальчика, но я вам её не
отдам :))
Даже не обязательно изменение оформления, а исправление ошибки в
пакете не приведет ни к каким результатам.

3) Веса альтернатив в branding
В пакетах брэндинга находятся 3 штуки альтернатив
- /usr/share/design-current
- /usr/share/design/current
- /etc/alterator/design-browser-qt

Из-за того, что альтернативы делаются в Makefile, веса этих
альтернатив задаются статически. И получаются одинаковые для всех
брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
теперь запрещены.
Поэтому надо договориться, у каких дистрибутивов какие веса будут.
branding-education уже занял 50 и 000012000000.
Я вчера занял для branding-server-v - 60 и 000012000060
Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
из Makefile.

4) Разработка всех branding в едином репо (subst spec?)
Сейчас нет эталонного репо branding, есть куча форков. С разным
наполнением. Но что хуже, с разным поведением. Например, проблема с
/etc/os-release не проявляется в education.
Тяжело отслеживать полезные изменения в разных репо. Тем более о них
никто не рассказывает и не анонсирует.
Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
матрицу для сборки, в каких дистрибутивах что должно быть
включено/выключено (профили для kde/xfce/mate и т.п.).


-- 
Alexey Shabalin

Re: [devel-distro] branding

[Leonid Krivoshein]

Доброй ночи!


03.08.2021 21:29, Alexey Shabalin пишет:
> День добрый.
> Есть несколько вопросов для обсуждения по поводу наших branding.
>
> 1) /etc/altlinux-release и /etc/os-release
> После коммита, который разошелся по всем брэндингам
> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
> Как они создаются при установке, никакое обновление их больше не обновляет.
> Это нарушает ожидаемое поведение во многих скриптах и системах
> автоматизированного управления.

Главным образом это нарушает единственный на сегодняшний день 
устоявшийся междистрибутивный стандарт 
(http://0pointer.de/blog/projects/os-release). Плохой ли, хороший ли, но 
де-факто единственный. LSB не в счёт. А нарушать стандарты плохо.

Да, это создаёт проблемы не только для утилит автоматизации, но и нашей 
техподдержке. Сбился со счёта по обращениям внешним и внутренним в СТП 
только из-за проблем с /etc/os-release.

Это порождает существенные проблемы несовместимости, потому что все 
ориентируются на окружение по os-release, а пытаясь обмануть всех, мы 
обманываем только себя в данном случае, ещё и пользователям создаём 
неудобства.


> Я могу привести примеры, если нужно,
> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
> что в них используется текущее состояние версии, а не на момент
> установки.
> Так же мне кажется, это может нарушать и договорные отношения (люди
> которые обновились на новый бранч этого не увидят, а люди которым по
> договорам нельзя обновляться на новые релизы сделают это без проблем -
> вывеска, версия платформы, не изменилась, значит можно)

Наверное нет практического руководства для фискальных органов по 
сличению соответствия содержимого диска с содержимым договора в 
отношении ALT Linux. Но даже, если такое существует, не думаю, что при 
полностью изменённой пакетной базе содержимое /etc/*-release хоть что-то 
будет значить, равно как и надписи в grub-меню, которые пользователь 
может поменять, картинки брэндинга, которые пользователь может заменить, 
итд. Все эти os-release, как мне кажется, очень далеки от договорных 
отношений, но тут лучше получить комментарии от юриста.

По нынешней лицензионной политике у организаций есть право обновляться в 
пределах мажорной версии. Т.е. обсуждаемый коммит вреден тем, что он в 
данном случае препятствует правомерной смене брендинга при переходе с 
9.0 на 9.1, так же завязанному на os-release. По формуляру Альт 8СП 
пользователь обязан всегда обновляться на последнюю версию, даже если 
это будет переход на мажорную версию. Данный коммит и в этом случае 
создаёт путаницу и неудобства.

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

Поддержка данного коммита (а по сути некорректного поведения по 
умолчанию, когда все думают, что эта система в первоначальном виде, хотя 
это уже далеко не так) создаёт возможность для госзаказчиков никогда не 
платить за обновление и переход на новые мажорные версии. А зачем 
платить, если по os-release это всё та же купленная система?


> Предлагаю откатить это изменение во всех branding для всех дистрибутивов.
+1

Полагаю, профита от него нет, одни недостатки. Если кому-то такое 
поведение нужно, давайте сделаем его включаемым, но не по умолчанию.


> Так же считаю делать что-то в %post с лицензией излишне.
> Если лицензия изменилась, надо её доставить. Если есть юридические
> проблемы, надо отразить в лицензии, что правообладатель имеет право
> менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
> юристы прокомментируют.
> Если в лицензии правообладатель сменился с Альтлинук на Базальт, то
> тем более надо менять лицензию - Альтлинукс еще можно найти?
> Если кого-то не устраивает изменение лицензии, значит они не должны обновляться.

Коммерческая лицензия на дистрибутив как составное произведение не 
должна меняться в течении жизненного цикла продукта, если только в ней 
нет оговорки, что у правообладателя есть право менять её в одностороннем 
порядке. Потому что это действительно затрагивает тех, кто купил продукт 
на определённых условиях. Если оговорки в договоре нет, должна быть 
policy, что лицензия на дистрибутив не меняется до выхода следующей 
мажорной версии.


> 2) Обновление оформления при обновлении
> Так же не происходит обновление bootsplash
> %post bootsplash
> [ "$1" -eq 1 ] || exit 0
>
> Мне кажется, что пользователь должен явно увидеть обновление
> оформления своей системы при обновлении на новый бранч. Иначе зачем
> вообще обновляются пакеты с оформлением, если изменений в оформлении
> не видно. (У меня есть посылка для вашего мальчика, но я вам её не
> отдам :))

Хотя бы сделать такое поведение при обновлении включаемым не по 
умолчанию. И лучше завязать не на os-release, а какой-нибудь внутренний 
/etc/release.d/ , где хранить информацию о том, что было установлено 
изначально, и нужно ли обновлять /etc/*-release файлы при обновлении.


> Даже не обязательно изменение оформления, а исправление ошибки в
> пакете не приведет ни к каким результатам.
>
> 3) Веса альтернатив в branding
> В пакетах брэндинга находятся 3 штуки альтернатив
> - /usr/share/design-current
> - /usr/share/design/current
> - /etc/alterator/design-browser-qt
>
> Из-за того, что альтернативы делаются в Makefile, веса этих
> альтернатив задаются статически. И получаются одинаковые для всех
> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
> теперь запрещены.
> Поэтому надо договориться, у каких дистрибутивов какие веса будут.
> branding-education уже занял 50 и 000012000000.
> Я вчера занял для branding-server-v - 60 и 000012000060
> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
> из Makefile.
>
> 4) Разработка всех branding в едином репо (subst spec?)
> Сейчас нет эталонного репо branding, есть куча форков. С разным
> наполнением. Но что хуже, с разным поведением. Например, проблема с
> /etc/os-release не проявляется в education.
> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
> никто не рассказывает и не анонсирует.
> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
> матрицу для сборки, в каких дистрибутивах что должно быть
> включено/выключено (профили для kde/xfce/mate и т.п.).

-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Владимир Черный]

Я полностью согласен с позицией Леонида и Алексея.
Кроме технических проблем, это крайне мешает бизнесу.

При переходе с 8 на 9 нам неоднократно задавали вопросы типа, а можно 
перейти с Альт РС 8 на Альт РС 9? ЛП компании это запрещает, предлагаем 
апгрейд за 0.5 РРЦ, "А если я обновлю, как указано на wiki, как понять, 
что мы перешли?"... остается взывать к совести и к тому, что документы в 
бухгалтерии на конкретный релиз, не более.

Ответ от юристов еще не получен.

04.08.2021 04:00, Leonid Krivoshein пишет:
> Доброй ночи!
> 
> 
> 03.08.2021 21:29, Alexey Shabalin пишет:
>> День добрый.
>> Есть несколько вопросов для обсуждения по поводу наших branding.
>>
>> 1) /etc/altlinux-release и /etc/os-release
>> После коммита, который разошелся по всем брэндингам
>> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89 
>>
>> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
>> Как они создаются при установке, никакое обновление их больше не 
>> обновляет.
>> Это нарушает ожидаемое поведение во многих скриптах и системах
>> автоматизированного управления.
> 
> Главным образом это нарушает единственный на сегодняшний день 
> устоявшийся междистрибутивный стандарт 
> (http://0pointer.de/blog/projects/os-release). Плохой ли, хороший ли, но 
> де-факто единственный. LSB не в счёт. А нарушать стандарты плохо.
> 
> Да, это создаёт проблемы не только для утилит автоматизации, но и нашей 
> техподдержке. Сбился со счёта по обращениям внешним и внутренним в СТП 
> только из-за проблем с /etc/os-release.
> 
> Это порождает существенные проблемы несовместимости, потому что все 
> ориентируются на окружение по os-release, а пытаясь обмануть всех, мы 
> обманываем только себя в данном случае, ещё и пользователям создаём 
> неудобства.
> 
> 
>> Я могу привести примеры, если нужно,
>> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
>> что в них используется текущее состояние версии, а не на момент
>> установки.
>> Так же мне кажется, это может нарушать и договорные отношения (люди
>> которые обновились на новый бранч этого не увидят, а люди которым по
>> договорам нельзя обновляться на новые релизы сделают это без проблем -
>> вывеска, версия платформы, не изменилась, значит можно)
> 
> Наверное нет практического руководства для фискальных органов по 
> сличению соответствия содержимого диска с содержимым договора в 
> отношении ALT Linux. Но даже, если такое существует, не думаю, что при 
> полностью изменённой пакетной базе содержимое /etc/*-release хоть что-то 
> будет значить, равно как и надписи в grub-меню, которые пользователь 
> может поменять, картинки брэндинга, которые пользователь может заменить, 
> итд. Все эти os-release, как мне кажется, очень далеки от договорных 
> отношений, но тут лучше получить комментарии от юриста.
> 
> По нынешней лицензионной политике у организаций есть право обновляться в 
> пределах мажорной версии. Т.е. обсуждаемый коммит вреден тем, что он в 
> данном случае препятствует правомерной смене брендинга при переходе с 
> 9.0 на 9.1, так же завязанному на os-release. По формуляру Альт 8СП 
> пользователь обязан всегда обновляться на последнюю версию, даже если 
> это будет переход на мажорную версию. Данный коммит и в этом случае 
> создаёт путаницу и неудобства.
> 
> Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие 
> неправомерного наезда. Не стоило прогибаться. Если у людей (организаций) 
> не было права обновляться, значит не надо было обновляться. Можно 
> поставить на HOLD, можно не переключать бранчи.
> 
> Поддержка данного коммита (а по сути некорректного поведения по 
> умолчанию, когда все думают, что эта система в первоначальном виде, хотя 
> это уже далеко не так) создаёт возможность для госзаказчиков никогда не 
> платить за обновление и переход на новые мажорные версии. А зачем 
> платить, если по os-release это всё та же купленная система?
> 
> 
>> Предлагаю откатить это изменение во всех branding для всех дистрибутивов.
> +1
> 
> Полагаю, профита от него нет, одни недостатки. Если кому-то такое 
> поведение нужно, давайте сделаем его включаемым, но не по умолчанию.
> 
> 
>> Так же считаю делать что-то в %post с лицензией излишне.
>> Если лицензия изменилась, надо её доставить. Если есть юридические
>> проблемы, надо отразить в лицензии, что правообладатель имеет право
>> менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
>> юристы прокомментируют.
>> Если в лицензии правообладатель сменился с Альтлинук на Базальт, то
>> тем более надо менять лицензию - Альтлинукс еще можно найти?
>> Если кого-то не устраивает изменение лицензии, значит они не должны 
>> обновляться.
> 
> Коммерческая лицензия на дистрибутив как составное произведение не 
> должна меняться в течении жизненного цикла продукта, если только в ней 
> нет оговорки, что у правообладателя есть право менять её в одностороннем 
> порядке. Потому что это действительно затрагивает тех, кто купил продукт 
> на определённых условиях. Если оговорки в договоре нет, должна быть 
> policy, что лицензия на дистрибутив не меняется до выхода следующей 
> мажорной версии.
> 
> 
>> 2) Обновление оформления при обновлении
>> Так же не происходит обновление bootsplash
>> %post bootsplash
>> [ "$1" -eq 1 ] || exit 0
>>
>> Мне кажется, что пользователь должен явно увидеть обновление
>> оформления своей системы при обновлении на новый бранч. Иначе зачем
>> вообще обновляются пакеты с оформлением, если изменений в оформлении
>> не видно. (У меня есть посылка для вашего мальчика, но я вам её не
>> отдам :))
> 
> Хотя бы сделать такое поведение при обновлении включаемым не по 
> умолчанию. И лучше завязать не на os-release, а какой-нибудь внутренний 
> /etc/release.d/ , где хранить информацию о том, что было установлено 
> изначально, и нужно ли обновлять /etc/*-release файлы при обновлении.
> 
> 
>> Даже не обязательно изменение оформления, а исправление ошибки в
>> пакете не приведет ни к каким результатам.
>>
>> 3) Веса альтернатив в branding
>> В пакетах брэндинга находятся 3 штуки альтернатив
>> - /usr/share/design-current
>> - /usr/share/design/current
>> - /etc/alterator/design-browser-qt
>>
>> Из-за того, что альтернативы делаются в Makefile, веса этих
>> альтернатив задаются статически. И получаются одинаковые для всех
>> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
>> теперь запрещены.
>> Поэтому надо договориться, у каких дистрибутивов какие веса будут.
>> branding-education уже занял 50 и 000012000000.
>> Я вчера занял для branding-server-v - 60 и 000012000060
>> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
>> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
>> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
>> из Makefile.
>>
>> 4) Разработка всех branding в едином репо (subst spec?)
>> Сейчас нет эталонного репо branding, есть куча форков. С разным
>> наполнением. Но что хуже, с разным поведением. Например, проблема с
>> /etc/os-release не проявляется в education.
>> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
>> никто не рассказывает и не анонсирует.
>> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
>> матрицу для сборки, в каких дистрибутивах что должно быть
>> включено/выключено (профили для kde/xfce/mate и т.п.).
> 

Re: [devel-distro] branding

[Владимир Черный]

Да, спасибо, Леня мне прислал. Хотел бы поучаствовать но у меня сегодня 
в 15 разговор с КД о 9.2 и p10, так что если до 15 уложимся...

04.08.2021 09:41, Aleksey Novodvorsky пишет:
> ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein <klark.devel@gmail.com>:
> 
>> Доброй ночи!
>>
>>
>> 03.08.2021 21:29, Alexey Shabalin пишет:
>>> День добрый.
>>> Есть несколько вопросов для обсуждения по поводу наших branding.
>>>
>>> 1) /etc/altlinux-release и /etc/os-release
>>> После коммита, который разошелся по всем брэндингам
>>>
>> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
>>> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
>>> Как они создаются при установке, никакое обновление их больше не
>> обновляет.
>>> Это нарушает ожидаемое поведение во многих скриптах и системах
>>> автоматизированного управления.
>>
>> Главным образом это нарушает единственный на сегодняшний день
>> устоявшийся междистрибутивный стандарт
>> (http://0pointer.de/blog/projects/os-release). Плохой ли, хороший ли, но
>> де-факто единственный. LSB не в счёт. А нарушать стандарты плохо.
>>
>> Да, это создаёт проблемы не только для утилит автоматизации, но и нашей
>> техподдержке. Сбился со счёта по обращениям внешним и внутренним в СТП
>> только из-за проблем с /etc/os-release.
>>
>> Это порождает существенные проблемы несовместимости, потому что все
>> ориентируются на окружение по os-release, а пытаясь обмануть всех, мы
>> обманываем только себя в данном случае, ещё и пользователям создаём
>> неудобства.
>>
>>
>>> Я могу привести примеры, если нужно,
>>> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
>>> что в них используется текущее состояние версии, а не на момент
>>> установки.
>>> Так же мне кажется, это может нарушать и договорные отношения (люди
>>> которые обновились на новый бранч этого не увидят, а люди которым по
>>> договорам нельзя обновляться на новые релизы сделают это без проблем -
>>> вывеска, версия платформы, не изменилась, значит можно)
>>
>> Наверное нет практического руководства для фискальных органов по
>> сличению соответствия содержимого диска с содержимым договора в
>> отношении ALT Linux. Но даже, если такое существует, не думаю, что при
>> полностью изменённой пакетной базе содержимое /etc/*-release хоть что-то
>> будет значить, равно как и надписи в grub-меню, которые пользователь
>> может поменять, картинки брэндинга, которые пользователь может заменить,
>> итд. Все эти os-release, как мне кажется, очень далеки от договорных
>> отношений, но тут лучше получить комментарии от юриста.
>>
>> По нынешней лицензионной политике у организаций есть право обновляться в
>> пределах мажорной версии. Т.е. обсуждаемый коммит вреден тем, что он в
>> данном случае препятствует правомерной смене брендинга при переходе с
>> 9.0 на 9.1, так же завязанному на os-release. По формуляру Альт 8СП
>> пользователь обязан всегда обновляться на последнюю версию, даже если
>> это будет переход на мажорную версию. Данный коммит и в этом случае
>> создаёт путаницу и неудобства.
>>
>> Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие
>> неправомерного наезда. Не стоило прогибаться.
> 
> 
> Кто на sem@ наехал? Поясните, пожалуйста.
> 
> Rgrds, Алексей
> 
> 
> Если у людей (организаций)
>> не было права обновляться, значит не надо было обновляться. Можно
>> поставить на HOLD, можно не переключать бранчи.
>>
>> Поддержка данного коммита (а по сути некорректного поведения по
>> умолчанию, когда все думают, что эта система в первоначальном виде, хотя
>> это уже далеко не так) создаёт возможность для госзаказчиков никогда не
>> платить за обновление и переход на новые мажорные версии. А зачем
>> платить, если по os-release это всё та же купленная система?
>>
>>
>>> Предлагаю откатить это изменение во всех branding для всех дистрибутивов.
>> +1
>>
>> Полагаю, профита от него нет, одни недостатки. Если кому-то такое
>> поведение нужно, давайте сделаем его включаемым, но не по умолчанию.
>>
>>
>>> Так же считаю делать что-то в %post с лицензией излишне.
>>> Если лицензия изменилась, надо её доставить. Если есть юридические
>>> проблемы, надо отразить в лицензии, что правообладатель имеет право
>>> менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
>>> юристы прокомментируют.
>>> Если в лицензии правообладатель сменился с Альтлинук на Базальт, то
>>> тем более надо менять лицензию - Альтлинукс еще можно найти?
>>> Если кого-то не устраивает изменение лицензии, значит они не должны
>> обновляться.
>>
>> Коммерческая лицензия на дистрибутив как составное произведение не
>> должна меняться в течении жизненного цикла продукта, если только в ней
>> нет оговорки, что у правообладателя есть право менять её в одностороннем
>> порядке. Потому что это действительно затрагивает тех, кто купил продукт
>> на определённых условиях. Если оговорки в договоре нет, должна быть
>> policy, что лицензия на дистрибутив не меняется до выхода следующей
>> мажорной версии.
>>
>>
>>> 2) Обновление оформления при обновлении
>>> Так же не происходит обновление bootsplash
>>> %post bootsplash
>>> [ "$1" -eq 1 ] || exit 0
>>>
>>> Мне кажется, что пользователь должен явно увидеть обновление
>>> оформления своей системы при обновлении на новый бранч. Иначе зачем
>>> вообще обновляются пакеты с оформлением, если изменений в оформлении
>>> не видно. (У меня есть посылка для вашего мальчика, но я вам её не
>>> отдам :))
>>
>> Хотя бы сделать такое поведение при обновлении включаемым не по
>> умолчанию. И лучше завязать не на os-release, а какой-нибудь внутренний
>> /etc/release.d/ , где хранить информацию о том, что было установлено
>> изначально, и нужно ли обновлять /etc/*-release файлы при обновлении.
>>
>>
>>> Даже не обязательно изменение оформления, а исправление ошибки в
>>> пакете не приведет ни к каким результатам.
>>>
>>> 3) Веса альтернатив в branding
>>> В пакетах брэндинга находятся 3 штуки альтернатив
>>> - /usr/share/design-current
>>> - /usr/share/design/current
>>> - /etc/alterator/design-browser-qt
>>>
>>> Из-за того, что альтернативы делаются в Makefile, веса этих
>>> альтернатив задаются статически. И получаются одинаковые для всех
>>> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
>>> теперь запрещены.
>>> Поэтому надо договориться, у каких дистрибутивов какие веса будут.
>>> branding-education уже занял 50 и 000012000000.
>>> Я вчера занял для branding-server-v - 60 и 000012000060
>>> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
>>> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
>>> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
>>> из Makefile.
>>>
>>> 4) Разработка всех branding в едином репо (subst spec?)
>>> Сейчас нет эталонного репо branding, есть куча форков. С разным
>>> наполнением. Но что хуже, с разным поведением. Например, проблема с
>>> /etc/os-release не проявляется в education.
>>> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
>>> никто не рассказывает и не анонсирует.
>>> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
>>> матрицу для сборки, в каких дистрибутивах что должно быть
>>> включено/выключено (профили для kde/xfce/mate и т.п.).
>>
>> --
>> Best regards,
>> Leonid Krivoshein.
>>
>> _______________________________________________
>> devel-distro mailing list
>> devel-distro@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel-distro
>>

-- 
С уважением,
Владимир Черный
Советник Генерального директора. Директор по продуктам.
ООО "Базальт СПО"
http://www.basealt.ru
тел.: +7(495)123-47-99 доб. 513

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 9:41, Aleksey Novodvorsky пишет:
>
> ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>
>     Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие
>     неправомерного наезда. Не стоило прогибаться.
>
>
> Кто на sem@ наехал? Поясните, пожалуйста.
>

Вы что-то неправильно поняли, про sem@ я ничего не говорил. И пояснение 
ниже, сразу за тем же текстом:


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

Как стало понятно из вчерашнего разговора, коммит возник вследствие 
наезда со стороны людей, которым приехало "что-то не то". Ещё раз: не 
надо обновляться, тогда не приедет, если именно у вас такого права нет.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>     Если у людей (организаций)
>>     не было права обновляться, значит не надо было обновляться. Можно
>>     поставить на HOLD, можно не переключать бранчи.
>>
>
> Как стало понятно из вчерашнего разговора, коммит возник вследствие 
> наезда со стороны людей, которым приехало "что-то не то". Ещё раз: не 
> надо обновляться, тогда не приедет, если именно у вас такого права нет. 

Это как это - не обновляться ?

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:23, Anton Farygin пишет:
> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>     Если у людей (организаций)
>>>     не было права обновляться, значит не надо было обновляться. Можно
>>>     поставить на HOLD, можно не переключать бранчи.
>>>
>>
>> Как стало понятно из вчерашнего разговора, коммит возник вследствие 
>> наезда со стороны людей, которым приехало "что-то не то". Ещё раз: не 
>> надо обновляться, тогда не приедет, если именно у вас такого права нет. 
>
> Это как это - не обновляться ?
>

Наш лицензионный договор даёт организациям право обновления с 9.0 на 
9.1, с 9.1 на 9.2, но не на 10.x. На частников это не распространяется. 
Если нет права обновляться на p10, значит не надо на него переходить, 
нужно сначала это право приобрести.



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 13:35, Leonid Krivoshein wrote:
>
>
> 04.08.2021 13:23, Anton Farygin пишет:
>> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>>     Если у людей (организаций)
>>>>     не было права обновляться, значит не надо было обновляться. Можно
>>>>     поставить на HOLD, можно не переключать бранчи.
>>>>
>>>
>>> Как стало понятно из вчерашнего разговора, коммит возник вследствие 
>>> наезда со стороны людей, которым приехало "что-то не то". Ещё раз: 
>>> не надо обновляться, тогда не приедет, если именно у вас такого 
>>> права нет. 
>>
>> Это как это - не обновляться ?
>>
>
> Наш лицензионный договор даёт организациям право обновления с 9.0 на 
> 9.1, с 9.1 на 9.2, но не на 10.x. На частников это не 
> распространяется. Если нет права обновляться на p10, значит не надо на 
> него переходить, нужно сначала это право приобрести.
>
>
>
И каким образом вот это изменение влияет на то, что не надо обновляться ?

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:41, Anton Farygin пишет:
> On 04.08.2021 13:35, Leonid Krivoshein wrote:
>>
>>
>> 04.08.2021 13:23, Anton Farygin пишет:
>>> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>>>     Если у людей (организаций)
>>>>>     не было права обновляться, значит не надо было обновляться. Можно
>>>>>     поставить на HOLD, можно не переключать бранчи.
>>>>>
>>>>
>>>> Как стало понятно из вчерашнего разговора, коммит возник вследствие 
>>>> наезда со стороны людей, которым приехало "что-то не то". Ещё раз: 
>>>> не надо обновляться, тогда не приедет, если именно у вас такого 
>>>> права нет. 
>>>
>>> Это как это - не обновляться ?
>>>
>>
>> Наш лицензионный договор даёт организациям право обновления с 9.0 на 
>> 9.1, с 9.1 на 9.2, но не на 10.x. На частников это не 
>> распространяется. Если нет права обновляться на p10, значит не надо 
>> на него переходить, нужно сначала это право приобрести.
>>
>>
>>
> И каким образом вот это изменение влияет на то, что не надо обновляться ?

Оно наоборот, снимает ограничение на обновления для организаций. Можно 
ставить 10.1, 11.2 итд. И не кому ничего не платить. Релиз останется 
исходно купленный -- 9.1.



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 14:08, Leonid Krivoshein wrote:
>
>
> 04.08.2021 13:41, Anton Farygin пишет:
>> On 04.08.2021 13:35, Leonid Krivoshein wrote:
>>>
>>>
>>> 04.08.2021 13:23, Anton Farygin пишет:
>>>> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>>>>     Если у людей (организаций)
>>>>>>     не было права обновляться, значит не надо было обновляться. 
>>>>>> Можно
>>>>>>     поставить на HOLD, можно не переключать бранчи.
>>>>>>
>>>>>
>>>>> Как стало понятно из вчерашнего разговора, коммит возник 
>>>>> вследствие наезда со стороны людей, которым приехало "что-то не 
>>>>> то". Ещё раз: не надо обновляться, тогда не приедет, если именно у 
>>>>> вас такого права нет. 
>>>>
>>>> Это как это - не обновляться ?
>>>>
>>>
>>> Наш лицензионный договор даёт организациям право обновления с 9.0 на 
>>> 9.1, с 9.1 на 9.2, но не на 10.x. На частников это не 
>>> распространяется. Если нет права обновляться на p10, значит не надо 
>>> на него переходить, нужно сначала это право приобрести.
>>>
>>>
>>>
>> И каким образом вот это изменение влияет на то, что не надо 
>> обновляться ?
>
> Оно наоборот, снимает ограничение на обновления для организаций. Можно 
> ставить 10.1, 11.2 итд. И не кому ничего не платить. Релиз останется 
> исходно купленный -- 9.1.
>
>
>
Так он меняется, как это он остаётся ?

Пакетная база переезжает, совместимость теряется.

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 14:09, Anton Farygin пишет:
> On 04.08.2021 14:08, Leonid Krivoshein wrote:
>>
>>
>> 04.08.2021 13:41, Anton Farygin пишет:
>>> On 04.08.2021 13:35, Leonid Krivoshein wrote:
>>>>
>>>>
>>>> 04.08.2021 13:23, Anton Farygin пишет:
>>>>> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>>>>>     Если у людей (организаций)
>>>>>>>     не было права обновляться, значит не надо было обновляться. 
>>>>>>> Можно
>>>>>>>     поставить на HOLD, можно не переключать бранчи.
>>>>>>>
>>>>>>
>>>>>> Как стало понятно из вчерашнего разговора, коммит возник 
>>>>>> вследствие наезда со стороны людей, которым приехало "что-то не 
>>>>>> то". Ещё раз: не надо обновляться, тогда не приедет, если именно 
>>>>>> у вас такого права нет. 
>>>>>
>>>>> Это как это - не обновляться ?
>>>>>
>>>>
>>>> Наш лицензионный договор даёт организациям право обновления с 9.0 
>>>> на 9.1, с 9.1 на 9.2, но не на 10.x. На частников это не 
>>>> распространяется. Если нет права обновляться на p10, значит не надо 
>>>> на него переходить, нужно сначала это право приобрести.
>>>>
>>>>
>>>>
>>> И каким образом вот это изменение влияет на то, что не надо 
>>> обновляться ?
>>
>> Оно наоборот, снимает ограничение на обновления для организаций. 
>> Можно ставить 10.1, 11.2 итд. И не кому ничего не платить. Релиз 
>> останется исходно купленный -- 9.1.
>>
>>
>>
> Так он меняется, как это он остаётся ?
>
> Пакетная база переезжает, совместимость теряется.

Меняется пакет, но не файлы /etc/*-release, о чём тут собственно и речь. 
Поэтому и оформление при обновлении не меняется по умолчанию.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 14:14, Leonid Krivoshein wrote:
>
>
> 04.08.2021 14:09, Anton Farygin пишет:
>> On 04.08.2021 14:08, Leonid Krivoshein wrote:
>>>
>>>
>>> 04.08.2021 13:41, Anton Farygin пишет:
>>>> On 04.08.2021 13:35, Leonid Krivoshein wrote:
>>>>>
>>>>>
>>>>> 04.08.2021 13:23, Anton Farygin пишет:
>>>>>> On 04.08.2021 13:14, Leonid Krivoshein wrote:
>>>>>>>>     Если у людей (организаций)
>>>>>>>>     не было права обновляться, значит не надо было обновляться. 
>>>>>>>> Можно
>>>>>>>>     поставить на HOLD, можно не переключать бранчи.
>>>>>>>>
>>>>>>>
>>>>>>> Как стало понятно из вчерашнего разговора, коммит возник 
>>>>>>> вследствие наезда со стороны людей, которым приехало "что-то не 
>>>>>>> то". Ещё раз: не надо обновляться, тогда не приедет, если именно 
>>>>>>> у вас такого права нет. 
>>>>>>
>>>>>> Это как это - не обновляться ?
>>>>>>
>>>>>
>>>>> Наш лицензионный договор даёт организациям право обновления с 9.0 
>>>>> на 9.1, с 9.1 на 9.2, но не на 10.x. На частников это не 
>>>>> распространяется. Если нет права обновляться на p10, значит не 
>>>>> надо на него переходить, нужно сначала это право приобрести.
>>>>>
>>>>>
>>>>>
>>>> И каким образом вот это изменение влияет на то, что не надо 
>>>> обновляться ?
>>>
>>> Оно наоборот, снимает ограничение на обновления для организаций. 
>>> Можно ставить 10.1, 11.2 итд. И не кому ничего не платить. Релиз 
>>> останется исходно купленный -- 9.1.
>>>
>>>
>>>
>> Так он меняется, как это он остаётся ?
>>
>> Пакетная база переезжает, совместимость теряется.
>
> Меняется пакет, но не файлы /etc/*-release, о чём тут собственно и 
> речь. Поэтому и оформление при обновлении не меняется по умолчанию.
>
>
Так это ошибка - ведь много кто проверяет операционку по /etc/*-release, 
надеясь на основании этих данных получить информацию о текущей системе.

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:18, Aleksey Novodvorsky пишет:
>
> ср, 4 авг. 2021 г., 14:14 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>
>     04.08.2021 9:41, Aleksey Novodvorsky пишет:
>     >
>     > ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein
>     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>
>     > <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>>:
>     >
>     >
>     >
>     >     Обсуждаемый коммит, насколько я теперь понимаю, возник
>     вследствие
>     >     неправомерного наезда. Не стоило прогибаться.
>     >
>     >
>     > Кто на sem@ наехал? Поясните, пожалуйста.
>     >
>
>     Вы что-то неправильно поняли, про sem@ я ничего не говорил
>
>
> Про какой коммит Вы говорили?

http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89


> Чей он?

Вот это совершенно не имеет значения. Миша сделал очевидно то, что его 
попросили.


>
>     . И пояснение
>     ниже, сразу за тем же текстом:
>
>
>     >
>     >     Если у людей (организаций)
>     >     не было права обновляться, значит не надо было обновляться.
>     Можно
>     >     поставить на HOLD, можно не переключать бранчи.
>     >
>
>     Как стало понятно из вчерашнего разговора, коммит возник вследствие
>     наезда со стороны людей, которым приехало "что-то не то". 
>
>
> Что это за люди?

Все детали вчера так и не были раскрыты. Может, Володя или Михаил поделятся.

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

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


>
> Rgrds, Алексей
>
>
>     Ещё раз: не
>     надо обновляться, тогда не приедет, если именно у вас такого права
>     нет.
>
>
>     -- 
>     Best regards,
>     Leonid Krivoshein.
>
>     _______________________________________________
>     devel-distro mailing list
>     devel-distro@lists.altlinux.org
>     <mailto:devel-distro@lists.altlinux.org>
>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:36, Aleksey Novodvorsky пишет:
>
> ср, 4 авг. 2021 г., 14:30 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>
>     04.08.2021 13:18, Aleksey Novodvorsky пишет:
>     >
>     > ср, 4 авг. 2021 г., 14:14 Leonid Krivoshein
>     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>
>     > <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>>:
>     >
>     >
>     >
>     >     04.08.2021 9:41, Aleksey Novodvorsky пишет:
>     >     >
>     >     > ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein
>     >     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>
>     <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>
>     >     > <mailto:klark.devel@gmail.com
>     <mailto:klark.devel@gmail.com> <mailto:klark.devel@gmail.com
>     <mailto:klark.devel@gmail.com>>>>:
>     >     >
>     >     >
>     >     >
>     >     >     Обсуждаемый коммит, насколько я теперь понимаю, возник
>     >     вследствие
>     >     >     неправомерного наезда. Не стоило прогибаться.
>     >     >
>     >     >
>     >     > Кто на sem@ наехал? Поясните, пожалуйста.
>     >     >
>     >
>     >     Вы что-то неправильно поняли, про sem@ я ничего не говорил
>     >
>     >
>     > Про какой коммит Вы говорили?
>
>     http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
>
>
>     > Чей он?
>
>     Вот это совершенно не имеет значения. Миша сделал очевидно то, что
>     его
>     попросили.
>
> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
>

Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши, 
он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно, 
Вы пропустили часть обсуждения, из него было понятно. Если бы меня 
интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой 
коммит. :-)


> Rgrds, Алексей
>
>
>
>
>
>     >
>     >     . И пояснение
>     >     ниже, сразу за тем же текстом:
>     >
>     >
>     >     >
>     >     >     Если у людей (организаций)
>     >     >     не было права обновляться, значит не надо было
>     обновляться.
>     >     Можно
>     >     >     поставить на HOLD, можно не переключать бранчи.
>     >     >
>     >
>     >     Как стало понятно из вчерашнего разговора, коммит возник
>     вследствие
>     >     наезда со стороны людей, которым приехало "что-то не то".
>     >
>     >
>     > Что это за люди?
>
>     Все детали вчера так и не были раскрыты. Может, Володя или Михаил
>     поделятся.
>
>     Но я поясню на пальцах, чтобы было понятно, почему наезд
>     неправомерный.
>     Допустим Вы снимаете помещение, и тут вдруг собственник изменился.
>     Вам
>     прислали перезаключить договор аренды с новым собственником, а Вы
>     говорите: а на каком основании меняется договор, я не хочу заключать
>     договор с новым собственником. Правильно было такому ответить: не
>     хочешь
>     новый договор -- освобождай помещение, тут новый хозяин.
>
>     Вместо того, чтобы объяснить, что не надо обновляться либо надо
>     принять
>     договор с новым собственником, решили сделать какую-то кривизну.
>
>
>     >
>     > Rgrds, Алексей
>     >
>     >
>     >     Ещё раз: не
>     >     надо обновляться, тогда не приедет, если именно у вас такого
>     права
>     >     нет.
>     >
>     >
>     >     --
>     >     Best regards,
>     >     Leonid Krivoshein.
>     >
>     >     _______________________________________________
>     >     devel-distro mailing list
>     > devel-distro@lists.altlinux.org
>     <mailto:devel-distro@lists.altlinux.org>
>     >     <mailto:devel-distro@lists.altlinux.org
>     <mailto:devel-distro@lists.altlinux.org>>
>     > https://lists.altlinux.org/mailman/listinfo/devel-distro
>     >
>     >
>     > _______________________________________________
>     > devel-distro mailing list
>     > devel-distro@lists.altlinux.org
>     <mailto:devel-distro@lists.altlinux.org>
>     > https://lists.altlinux.org/mailman/listinfo/devel-distro
>
>     -- 
>     Best regards,
>     Leonid Krivoshein.
>
>     _______________________________________________
>     devel-distro mailing list
>     devel-distro@lists.altlinux.org
>     <mailto:devel-distro@lists.altlinux.org>
>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Aleksey Novodvorsky]

ср, 4 авг. 2021 г. в 14:46, Leonid Krivoshein <klark.devel@gmail.com>:
>
>
> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
> >
> > ср, 4 авг. 2021 г., 14:30 Leonid Krivoshein <klark.devel@gmail.com
> > <mailto:klark.devel@gmail.com>>:
> >
> >
> >
> >     04.08.2021 13:18, Aleksey Novodvorsky пишет:
> >     >
> >     > ср, 4 авг. 2021 г., 14:14 Leonid Krivoshein
> >     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>
> >     > <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>>:
> >     >
> >     >
> >     >
> >     >     04.08.2021 9:41, Aleksey Novodvorsky пишет:
> >     >     >
> >     >     > ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein
> >     >     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>
> >     <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>
> >     >     > <mailto:klark.devel@gmail.com
> >     <mailto:klark.devel@gmail.com> <mailto:klark.devel@gmail.com
> >     <mailto:klark.devel@gmail.com>>>>:
> >     >     >
> >     >     >
> >     >     >
> >     >     >     Обсуждаемый коммит, насколько я теперь понимаю, возник
> >     >     вследствие
> >     >     >     неправомерного наезда. Не стоило прогибаться.
> >     >     >
> >     >     >
> >     >     > Кто на sem@ наехал? Поясните, пожалуйста.
> >     >     >
> >     >
> >     >     Вы что-то неправильно поняли, про sem@ я ничего не говорил
> >     >
> >     >
> >     > Про какой коммит Вы говорили?
> >
> >     http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
> >
> >
> >     > Чей он?
> >
> >     Вот это совершенно не имеет значения. Миша сделал очевидно то, что
> >     его
> >     попросили.
> >
> > Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
> >
>
> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
> коммит. :-)

Это написали сюда Вы и я прошу Вас и тут ответить.
За слова ведь надо отвечать, тем более сказанные публично.
Rgrds, Алексей

>
>
> > Rgrds, Алексей
> >
> >
> >
> >
> >
> >     >
> >     >     . И пояснение
> >     >     ниже, сразу за тем же текстом:
> >     >
> >     >
> >     >     >
> >     >     >     Если у людей (организаций)
> >     >     >     не было права обновляться, значит не надо было
> >     обновляться.
> >     >     Можно
> >     >     >     поставить на HOLD, можно не переключать бранчи.
> >     >     >
> >     >
> >     >     Как стало понятно из вчерашнего разговора, коммит возник
> >     вследствие
> >     >     наезда со стороны людей, которым приехало "что-то не то".
> >     >
> >     >
> >     > Что это за люди?
> >
> >     Все детали вчера так и не были раскрыты. Может, Володя или Михаил
> >     поделятся.
> >
> >     Но я поясню на пальцах, чтобы было понятно, почему наезд
> >     неправомерный.
> >     Допустим Вы снимаете помещение, и тут вдруг собственник изменился.
> >     Вам
> >     прислали перезаключить договор аренды с новым собственником, а Вы
> >     говорите: а на каком основании меняется договор, я не хочу заключать
> >     договор с новым собственником. Правильно было такому ответить: не
> >     хочешь
> >     новый договор -- освобождай помещение, тут новый хозяин.
> >
> >     Вместо того, чтобы объяснить, что не надо обновляться либо надо
> >     принять
> >     договор с новым собственником, решили сделать какую-то кривизну.
> >
> >
> >     >
> >     > Rgrds, Алексей
> >     >
> >     >
> >     >     Ещё раз: не
> >     >     надо обновляться, тогда не приедет, если именно у вас такого
> >     права
> >     >     нет.
> >     >
> >     >
> >     >     --
> >     >     Best regards,
> >     >     Leonid Krivoshein.
> >     >
> >     >     _______________________________________________
> >     >     devel-distro mailing list
> >     > devel-distro@lists.altlinux.org
> >     <mailto:devel-distro@lists.altlinux.org>
> >     >     <mailto:devel-distro@lists.altlinux.org
> >     <mailto:devel-distro@lists.altlinux.org>>
> >     > https://lists.altlinux.org/mailman/listinfo/devel-distro
> >     >
> >     >
> >     > _______________________________________________
> >     > devel-distro mailing list
> >     > devel-distro@lists.altlinux.org
> >     <mailto:devel-distro@lists.altlinux.org>
> >     > https://lists.altlinux.org/mailman/listinfo/devel-distro
> >
> >     --
> >     Best regards,
> >     Leonid Krivoshein.
> >
> >     _______________________________________________
> >     devel-distro mailing list
> >     devel-distro@lists.altlinux.org
> >     <mailto:devel-distro@lists.altlinux.org>
> >     https://lists.altlinux.org/mailman/listinfo/devel-distro
> >
> >
> > _______________________________________________
> > devel-distro mailing list
> > devel-distro@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel-distro
>
> --
> Best regards,
> Leonid Krivoshein.
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:49, Aleksey Novodvorsky пишет:
> ср, 4 авг. 2021 г. в 14:46, Leonid Krivoshein <klark.devel@gmail.com>:
>> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
>>> [...]
>>>
>>>
>>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
>>>
>> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
>> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
>> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
>> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
>> коммит. :-)
> Это написали сюда Вы и я прошу Вас и тут ответить.
> За слова ведь надо отвечать, тем более сказанные публично.

Ну, раз так настаиваете, я выясню, и напишу результат тут публично.



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Aleksey Novodvorsky]

ср, 4 авг. 2021 г. в 15:10, Leonid Krivoshein <klark.devel@gmail.com>:
>
>
> 04.08.2021 13:49, Aleksey Novodvorsky пишет:
> > ср, 4 авг. 2021 г. в 14:46, Leonid Krivoshein <klark.devel@gmail.com>:
> >> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
> >>> [...]
> >>>
> >>>
> >>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
> >>>
> >> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
> >> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
> >> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
> >> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
> >> коммит. :-)
> > Это написали сюда Вы и я прошу Вас и тут ответить.
> > За слова ведь надо отвечать, тем более сказанные публично.
>
> Ну, раз так настаиваете, я выясню, и напишу результат тут публично.

Я всегда настаиваю на подтверждении слов, тем более содержащих обвинения.
Когда Вы выясните и напишете?

Rgrds, Алексей

>
>
>
> --
> Best regards,
> Leonid Krivoshein.
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 14:25, Aleksey Novodvorsky пишет:
> ср, 4 авг. 2021 г. в 15:10, Leonid Krivoshein <klark.devel@gmail.com>:
>>
>> 04.08.2021 13:49, Aleksey Novodvorsky пишет:
>>> ср, 4 авг. 2021 г. в 14:46, Leonid Krivoshein <klark.devel@gmail.com>:
>>>> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
>>>>> [...]
>>>>>
>>>>>
>>>>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
>>>>>
>>>> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
>>>> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
>>>> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
>>>> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
>>>> коммит. :-)
>>> Это написали сюда Вы и я прошу Вас и тут ответить.
>>> За слова ведь надо отвечать, тем более сказанные публично.
>> Ну, раз так настаиваете, я выясню, и напишу результат тут публично.
> Я всегда настаиваю на подтверждении слов, тем более содержащих обвинения.

Я никого ни в чём не обвинял и не собирался заниматься "разбором 
полётов". Мы тут обсуждаем пользу или вред от конкретного коммита. Я 
лишь высказал мнение, что прогибаться на неправомерные наезды не стоит. 
Вчера на совещании Михаил сам озвучил, вследствие чего возник данный 
коммит. Детали мне не так важны.


> Когда Вы выясните и напишете?

Постараюсь не затягивать, учитывая занятость. В ближайшие дни.


>
> Rgrds, Алексей
>
>>
>>
>> --
>> Best regards,
>> Leonid Krivoshein.
>>
>> _______________________________________________
>> devel-distro mailing list
>> devel-distro@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel-distro
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Aleksey Novodvorsky]

ср, 4 авг. 2021 г. в 16:22, Leonid Krivoshein <klark.devel@gmail.com>:
>
>
>
> 04.08.2021 14:25, Aleksey Novodvorsky пишет:
> > ср, 4 авг. 2021 г. в 15:10, Leonid Krivoshein <klark.devel@gmail.com>:
> >>
> >> 04.08.2021 13:49, Aleksey Novodvorsky пишет:
> >>> ср, 4 авг. 2021 г. в 14:46, Leonid Krivoshein <klark.devel@gmail.com>:
> >>>> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
> >>>>> [...]
> >>>>>
> >>>>>
> >>>>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
> >>>>>
> >>>> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
> >>>> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
> >>>> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
> >>>> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
> >>>> коммит. :-)
> >>> Это написали сюда Вы и я прошу Вас и тут ответить.
> >>> За слова ведь надо отвечать, тем более сказанные публично.
> >> Ну, раз так настаиваете, я выясню, и напишу результат тут публично.
> > Я всегда настаиваю на подтверждении слов, тем более содержащих обвинения.
>
> Я никого ни в чём не обвинял и не собирался заниматься "разбором
> полётов". Мы тут обсуждаем пользу или вред от конкретного коммита. Я
> лишь высказал мнение, что прогибаться на неправомерные наезды не стоит.
> Вчера на совещании Михаил сам озвучил, вследствие чего возник данный
> коммит. Детали мне не так важны.

Почитайте сегодняшнее письмо Михаила. Михаил никогда не сделает то, с
чем не согласен.
Потому Ваши слова -- обвинение.

>
>
> > Когда Вы выясните и напишете?
>
> Постараюсь не затягивать, учитывая занятость. В ближайшие дни.

Нет, так не годится. Называйте срок.

Rgrds, Алексей


>
>
> >
> > Rgrds, Алексей
> >
> >>
> >>
> >> --
> >> Best regards,
> >> Leonid Krivoshein.
> >>
> >> _______________________________________________
> >> devel-distro mailing list
> >> devel-distro@lists.altlinux.org
> >> https://lists.altlinux.org/mailman/listinfo/devel-distro
> > _______________________________________________
> > devel-distro mailing list
> > devel-distro@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel-distro
>
> --
> Best regards,
> Leonid Krivoshein.
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

Re: [devel-distro] branding

[Mikhail Efremov]

On Wed, 4 Aug 2021 13:46:05 +0300 Leonid Krivoshein wrote:
> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
> >
> > ср, 4 авг. 2021 г., 14:30 Leonid Krivoshein <klark.devel@gmail.com 
> > <mailto:klark.devel@gmail.com>>:
> >
> >
> >
> >     04.08.2021 13:18, Aleksey Novodvorsky пишет:  
> >     >
> >     > ср, 4 авг. 2021 г., 14:14 Leonid Krivoshein  
> >     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>  
> >     > <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>>:
> >     >
> >     >
> >     >
> >     >     04.08.2021 9:41, Aleksey Novodvorsky пишет:
> >     >     >
> >     >     > ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein
> >     >     <klark.devel@gmail.com <mailto:klark.devel@gmail.com>  
> >     <mailto:klark.devel@gmail.com <mailto:klark.devel@gmail.com>>  
> >     >     > <mailto:klark.devel@gmail.com  
> >     <mailto:klark.devel@gmail.com> <mailto:klark.devel@gmail.com
> >     <mailto:klark.devel@gmail.com>>>>:  
> >     >     >
> >     >     >
> >     >     >
> >     >     >     Обсуждаемый коммит, насколько я теперь понимаю, возник
> >     >     вследствие
> >     >     >     неправомерного наезда. Не стоило прогибаться.
> >     >     >
> >     >     >
> >     >     > Кто на sem@ наехал? Поясните, пожалуйста.
> >     >     >
> >     >
> >     >     Вы что-то неправильно поняли, про sem@ я ничего не говорил
> >     >
> >     >
> >     > Про какой коммит Вы говорили?  
> >
> >     http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
> >
> >  
> >     > Чей он?  
> >
> >     Вот это совершенно не имеет значения. Миша сделал очевидно то, что
> >     его
> >     попросили.
> >
> > Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
> >  
> 
> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши, 
> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно, 
> Вы пропустили часть обсуждения, из него было понятно. Если бы меня 
> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой 
> коммит. :-)

Меня никто не просил и не заставлял. Я сделал так, как считал
правильным. Просто катализатором послужило та история с изменением
лицензии. Я помню, людей тогда успокаивали, что смена лицензии
обратной силы не имеет и распространяется только на новые продукты.
При этом /etc/os-release и текст лицензии менялся с обновлением,
некоторые люди выказывали опасения на этот счет. Я нашел способ решить
проблему на будущее, да и мне самому так кажется правильно.

-- 
WBR, Mikhail Efremov

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 16:02, Mikhail Efremov пишет:
> On Wed, 4 Aug 2021 13:46:05 +0300 Leonid Krivoshein wrote:
>> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
>>> [...]
>>>
>>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и ответьте.
>>>   
>> Мне детали неизвестны, но я думаю, что данная инициатива шла не от Миши,
>> он предлагал вчера напомнить про ситуацию с возникшей бучей. Возможно,
>> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
>> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
>> коммит. :-)
> Меня никто не просил и не заставлял. Я сделал так, как считал
> правильным. Просто катализатором послужило та история с изменением
> лицензии. Я помню, людей тогда успокаивали, что смена лицензии
> обратной силы не имеет и распространяется только на новые продукты.
> При этом /etc/os-release и текст лицензии менялся с обновлением,
> некоторые люди выказывали опасения на этот счет. Я нашел способ решить
> проблему на будущее, да и мне самому так кажется правильно.

Михаил, спасибо! Вот и разобрались. Как я пониманию, хотя это не столь 
важно, речь о ситуации с заменой лицензии, которая обсуждалась в 
коммьюнити за несколько месяцев до коммита.

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


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 16:22, Aleksey Novodvorsky пишет:
>
>
>
> ср, 4 авг. 2021 г., 17:13 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>     04.08.2021 16:02, Mikhail Efremov пишет:
>     > On Wed, 4 Aug 2021 13:46:05 +0300 Leonid Krivoshein wrote:
>     >> 04.08.2021 13:36, Aleksey Novodvorsky пишет:
>     >>> [...]
>     >>>
>     >>> Кто попросил? Меня интересует ровно это. Вы это сказали, Вы и
>     ответьте.
>     >>>
>     >> Мне детали неизвестны, но я думаю, что данная инициатива шла не
>     от Миши,
>     >> он предлагал вчера напомнить про ситуацию с возникшей бучей.
>     Возможно,
>     >> Вы пропустили часть обсуждения, из него было понятно. Если бы меня
>     >> интересовал тот же вопрос, я бы выяснил, кто сподвиг Мишу на такой
>     >> коммит. :-)
>     > Меня никто не просил и не заставлял. Я сделал так, как считал
>     > правильным. Просто катализатором послужило та история с изменением
>     > лицензии. Я помню, людей тогда успокаивали, что смена лицензии
>     > обратной силы не имеет и распространяется только на новые продукты.
>     > При этом /etc/os-release и текст лицензии менялся с обновлением,
>     > некоторые люди выказывали опасения на этот счет. Я нашел способ
>     решить
>     > проблему на будущее, да и мне самому так кажется правильно.
>
>     Михаил, спасибо! Вот и разобрались. Как я пониманию, хотя это не
>     столь
>     важно, речь о ситуации с заменой лицензии, которая обсуждалась в
>     коммьюнити за несколько месяцев до коммита.
>
>     Алексей, пожалуйста, читайте внимательно, что я написал в исходном
>     письме. Никого ни в чём не обвинял. Ваши встречные вопросы уводят
>     обсуждение в сторону от главного. А главное это то, нужны ли данные
>     изменения в репозитории.
>
>
> Для обсуждения нужно обосновывать свои суждения.
> Вы написали, что коммит возник вследствие неправомерного наезда.
> Прошу обосновать Ваше суждение.

Михаил выше обосновал. Вчера было сказано, что возник коммит вследствие 
поднятой бучи. Сегодня было добавлено, что да, "катализатором послужило 
та история с изменением лицензии...". На днях Вы сами на канале 
обосновывали такое поведение os-release чьими-то коммерческими 
интересами. Из этого я сделал вывод, на который Вы отреагировали. 
Процитирую его тут ещё раз:

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

Почему Вы считаете, что я сделал неверный вывод? И какой вывод можно 
сделать из данного потока информации? Кого я тут обвинил в этой фразе? 
Предлагаю всё же вернуться к тому, что имеет значение, а не уводить в 
сторону. Факт: до коммита поведение было другим. Другой подтверждённый 
факт: коммит возник вследствие поднятой бучи. Я сделал из этого вывод, 
что "прогнулись", совершили ошибку, а не стоило. Такие атаки нужно 
отбивать. И я это обосновал. Предлагаю на этом разбор полётов завершить.



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 17:30, Aleksey Novodvorsky wrote:
>
>
>     """Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие
>     неправомерного наезда.
>
>
> Ещё раз.
> Кто наехал? Где? Почему неправомерно?
>
> Почитайте Михаила.

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

Re: [devel-distro] branding

[Mikhail Efremov]

On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
> По сути же, мне не нравится любое изменение , не согласованное со всеми
> релиз-менеджерами.

Когда я о нем писал почти никто не отреагировал:
https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html

-- 
WBR, Mikhail Efremov

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 18:30, Aleksey Novodvorsky пишет:
>
> ср, 4 авг. 2021 г., 19:14 Mikhail Efremov <sem@altlinux.org 
> <mailto:sem@altlinux.org>>:
>
>     On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>     > По сути же, мне не нравится любое изменение , не согласованное
>     со всеми
>     > релиз-менеджерами.
>
>     Когда я о нем писал почти никто не отреагировал:
>     https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>
>
> Спасибо!
>
> А кто же "неправомерно наехал?" :
>

Если это вопрос ко мне, то вот ответ. В первых строках написано:


Когда была катавасия со сменой лицензионного договора на дитрибутивы,
aen@ объяснял, помнится, что действует тот договор, с которым
пользователь соглашался при установке, обновление/удаление/установка
пакетов на это не влияют.


Дата задолго до моего прихода в Базальт СПО. Итак, кто же наехал? Что за 
катавасия? Что за буча? :-) Вы же в этой цитате давали по ней пояснения. 
А я скажу, почему этот наезд был неправомерный. :-)

И ещё: тут Вы всё правильно говорите про действие договора. Но из этого 
совершенно не следует, что файл договора должен оставаться старый.

Интересно, кто-то ещё увидел в моих словах хамство? Я никого ни в чём не 
обвинял, на личности не переходил. Всем желаю только добра.))


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Alexey Shabalin]

ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem@altlinux.org>:
>
> On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
> > По сути же, мне не нравится любое изменение , не согласованное со всеми
> > релиз-менеджерами.
>
> Когда я о нем писал почти никто не отреагировал:
> https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html

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

Давай попробуем не рассматривать юридические аспекты, остановимся
только на технических.
При эксплуатации и  обслуживании системы, через пару-тройку лет, а еще
и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно все равно,
откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо важнее, текущее
состояние версии - 8, 9 или 10. И для этого есть стандартное место -
/etc/os-release или /etc/altlinux-release.
Заглянуть в эти файлы проще, чем делать rpm -q --qf "%{VERSION}"
branding-alt-workstation-release, а еще перед этим надо узнать имя
пакета, workstation или какое-другое.
А дальше еще нужно переписать кучу софта, который смотрит в /etc/os-release.
Вы готовы пропатчить все возможное? Начиная с python3-module-distro,
platform.freedesktop_os_release() в будущем python-3.10? Кучу
остального прикладного софта?
Этот прикладной софт не знает, что было придумано в Альт в 2017 году.
Во всех дистрибутивах принято в /etc/os-release хранить текущую версию
(ок, называйте как угодно, пусть будет версия пакета branding, а не
версия дистрибутива - меня устроит любое определение). У альт и так
много специфических отличий, но зачем тут создавать ненужное отличие
на ровном месте?


-- 
Alexey Shabalin

Re: [devel-distro] branding

[Alexey Shabalin]

чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
> чт, 5 авг. 2021 г., 19:38 Alexey Shabalin <a.shabalin@gmail.com>:
>>
>> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem@altlinux.org>:
>> >
>> > On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>> > > По сути же, мне не нравится любое изменение , не согласованное со всеми
>> > > релиз-менеджерами.
>> >
>> > Когда я о нем писал почти никто не отреагировал:
>> > https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>>
>> Для релиз менеджера, который тестирует разные beta и rc, причем
>> исключительно новыми установками, это изменение возможно полезное.
>> Но на системах, которые никакого отношения не имеют к beta, установка
>> только из релиза и в дальнейшем многолетняя эксплуатация с
>> обновлениями, это изменение вредное.
>>
>> Давай попробуем не рассматривать юридические аспекты, остановимся
>> только на технических.
>> При эксплуатации и  обслуживании системы, через пару-тройку лет, а еще
>> и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно все равно,
>> откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо важнее, текущее
>> состояние версии - 8, 9 или 10. И для этого есть стандартное место -
>> /etc/os-release или /etc/altlinux-release.
>> Заглянуть в эти файлы проще, чем делать rpm -q --qf "%{VERSION}"
>> branding-alt-workstation-release, а еще перед этим надо узнать имя
>> пакета, workstation или какое-другое.
>> А дальше еще нужно переписать кучу софта, который смотрит в /etc/os-release.
>> Вы готовы пропатчить все возможное? Начиная с python3-module-distro,
>> platform.freedesktop_os_release() в будущем python-3.10? Кучу
>> остального прикладного софта?
>> Этот прикладной софт не знает, что было придумано в Альт в 2017 году.
>> Во всех дистрибутивах принято в /etc/os-release хранить текущую версию
>> (ок, называйте как угодно, пусть будет версия пакета branding, а не
>> версия дистрибутива - меня устроит любое определение). У альт и так
>> много специфических отличий, но зачем тут создавать ненужное отличие
>> на ровном месте?
>
>
> На ровном месте точно не нужно.
> Давайте обратимся к "мелочам".
> Что должно быть в os-release у обновившихся с p9 до p10 до выхода 10.0?

Лучше, чтобы уже было написано "10.0". Вас это все равно ни к чему не
обязывает - релиза еще не было и iso образов еще нет.
И тогда:
- саппорт увидит что именно использует клиент;
- системы автоматизации и скрипты можно подготавливать и адаптировать
для дистрибутивов на p10;
- видно кто неправомерно обновился.

Пусть пакет имеет версию 9.9 или 9.98, как любит sem@, но внутри в
/etc/os-release уже будет 10.0.
Обратная логика, предлагаемая sem@.

-- 
Alexey Shabalin

Re: [devel-distro] branding

[Michael Shigorin]

On Thu, Aug 05, 2021 at 08:41:16PM +0300, Alexey Shabalin wrote:
> Лучше, чтобы уже было написано "10.0". Вас это все равно ни к
> чему не обязывает - релиза еще не было и iso образов еще нет.
> И тогда:
[...]
> - видно кто неправомерно обновился.

Ой, а это как?

По-моему, если я купил поддержку на 9.x и обновился до p10
-- ну остался без поддержки (или поставил опять 9.x),
как я мог неправомерно-то обновиться?

(если мог -- не учи плохому, просто сообщи, что мог :)

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

Re: [devel-distro] branding

[Alexey Shabalin]

чт, 5 авг. 2021 г. в 21:49, Michael Shigorin <mike@altlinux.org>:
>
> On Thu, Aug 05, 2021 at 08:41:16PM +0300, Alexey Shabalin wrote:
> > Лучше, чтобы уже было написано "10.0". Вас это все равно ни к
> > чему не обязывает - релиза еще не было и iso образов еще нет.
> > И тогда:
> [...]
> > - видно кто неправомерно обновился.
>
> Ой, а это как?
>
> По-моему, если я купил поддержку на 9.x и обновился до p10
> -- ну остался без поддержки (или поставил опять 9.x),
> как я мог неправомерно-то обновиться?

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


>
> (если мог -- не учи плохому, просто сообщи, что мог :)
>



--
Alexey Shabalin

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 20:57, Aleksey Novodvorsky пишет:
>
> чт, 5 авг. 2021 г., 20:41 Alexey Shabalin <a.shabalin@gmail.com 
> <mailto:a.shabalin@gmail.com>>:
>
>     чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky <aen@basealt.ru
>     <mailto:aen@basealt.ru>>:
>     >
>     >
>     >
>     > чт, 5 авг. 2021 г., 19:38 Alexey Shabalin <a.shabalin@gmail.com
>     <mailto:a.shabalin@gmail.com>>:
>     >>
>     >> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem@altlinux.org
>     <mailto:sem@altlinux.org>>:
>     >> >
>     >> > On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>     >> > > По сути же, мне не нравится любое изменение , не
>     согласованное со всеми
>     >> > > релиз-менеджерами.
>     >> >
>     >> > Когда я о нем писал почти никто не отреагировал:
>     >> >
>     https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>     >>
>     >> Для релиз менеджера, который тестирует разные beta и rc, причем
>     >> исключительно новыми установками, это изменение возможно полезное.
>     >> Но на системах, которые никакого отношения не имеют к beta,
>     установка
>     >> только из релиза и в дальнейшем многолетняя эксплуатация с
>     >> обновлениями, это изменение вредное.
>     >>
>     >> Давай попробуем не рассматривать юридические аспекты, остановимся
>     >> только на технических.
>     >> При эксплуатации и  обслуживании системы, через пару-тройку
>     лет, а еще
>     >> и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно все
>     равно,
>     >> откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо важнее,
>     текущее
>     >> состояние версии - 8, 9 или 10. И для этого есть стандартное
>     место -
>     >> /etc/os-release или /etc/altlinux-release.
>     >> Заглянуть в эти файлы проще, чем делать rpm -q --qf "%{VERSION}"
>     >> branding-alt-workstation-release, а еще перед этим надо узнать имя
>     >> пакета, workstation или какое-другое.
>     >> А дальше еще нужно переписать кучу софта, который смотрит в
>     /etc/os-release.
>     >> Вы готовы пропатчить все возможное? Начиная с
>     python3-module-distro,
>     >> platform.freedesktop_os_release() в будущем python-3.10? Кучу
>     >> остального прикладного софта?
>     >> Этот прикладной софт не знает, что было придумано в Альт в 2017
>     году.
>     >> Во всех дистрибутивах принято в /etc/os-release хранить текущую
>     версию
>     >> (ок, называйте как угодно, пусть будет версия пакета branding, а не
>     >> версия дистрибутива - меня устроит любое определение). У альт и так
>     >> много специфических отличий, но зачем тут создавать ненужное
>     отличие
>     >> на ровном месте?
>     >
>     >
>     > На ровном месте точно не нужно.
>     > Давайте обратимся к "мелочам".
>     > Что должно быть в os-release у обновившихся с p9 до p10 до
>     выхода 10.0?
>
>     Лучше, чтобы уже было написано "10.0". Вас это все равно ни к чему не
>     обязывает - релиза еще не было и iso образов еще нет.
>

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

Сейчас же ситуация худшая из возможных, когда кто в лес, кто по дрова. 
Как нам теперь партнёрам объяснять "...а если используете Альт Сервер 
виртуализации 9.2 и выше, то поведение как по стандарту..." (маленький 
фрагмент из большой шпаргалки по altlinux-release.


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

Как раз это не пример, так как нет продукта -- нет анонса. И бранч -- 
это не продукт с версией, в смысле не дистрибутив. А у нас, как верно 
заметил вчера Дима, обновление коммерческого продукта только из 
свободного бранча. Так что на мой взгляд переход на p10 ещё не меняет 
установленный дистрибутив до 10.0, пока не появится соответствующего 
брэндинга. И кстати, это спорное состояние для тестирования, подготовки 
к переходу, но не для продакшена.


>
>     И тогда:
>     - саппорт увидит что именно использует клиент;
>     - системы автоматизации и скрипты можно подготавливать и адаптировать
>     для дистрибутивов на p10;
>     - видно кто непавомерно обновился.
>
>
> Мне, честно говоря, не нравятся разговоры о неправомерном  обновлении 
> из свободного репозитория. Буду говорить с коммерческим блоком
>


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 23:44, Aleksey Novodvorsky пишет:
> чт, 5 авг. 2021 г., 23:36 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>     [...]
>     Сейчас же ситуация худшая из возможных, когда кто в лес, кто по
>     дрова.
>     Как нам теперь партнёрам объяснять "...а если используете Альт Сервер
>     виртуализации 9.2 и выше, то поведение как по стандарту..."
>     (маленький
>     фрагмент из большой шпаргалки по altlinux-release.
>
>
> Если Вы с таким встречались, то давайте сюда пруф. Если  это Ваши 
> предположения, то я их читать не буду.
>

Ничто не мешает выпускающему маинтейнеру выпустить образ со своим 
заданием, откатывающим данный коммит. См., например, #282009, 282010. 
Так Алексей же с этого и начал тему, и Антон Фарыгин ранее в обсуждении 
предлагал "общее решение уровнем выше".


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 23:44, Aleksey Novodvorsky пишет:
> чт, 5 авг. 2021 г., 23:36 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>     [...]
>
>     Сейчас же ситуация худшая из возможных, когда кто в лес, кто по
>     дрова.
>     Как нам теперь партнёрам объяснять "...а если используете Альт Сервер
>     виртуализации 9.2 и выше, то поведение как по стандарту..."
>     (маленький
>     фрагмент из большой шпаргалки по altlinux-release.
>
>
> Если Вы с таким встречались, то давайте сюда пруф. Если  это Ваши 
> предположения, то я их читать не буду.
>

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

И кстати, согласен с Антоном, потому что брэндинг с лицензией на 
дистрибутив вроде как коммерческий пакет Базальт СПО, один из немногих, 
тут нельзя так "кто в лес, кто по дрова". Хотя не берусь утверждать, 
что-то от Смирнова об этом слышал.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 23:44, Aleksey Novodvorsky пишет:
> [...]
>
>
>     >
>     > У нас именно в 10.0 будут новшества в apt, работа идёт, мы
>     говорили об
>     > этом. А бранч будет доступен для обновления раньше.
>     > То есть это как раз пример того, когда номер релиза, пусть
>     условный,
>     > не дает нужной информации.
>
>     Как раз это не пример, так как нет продукта -- нет анонса. И бранч --
>     это не продукт с версией, в смысле не дистрибутив. А у нас, как верно
>     заметил вчера Дима, обновление коммерческого продукта только из
>     свободного бранча. Так что на мой взгляд переход на p10 ещё не меняет
>     установленный дистрибутив до 10.0, пока не появится соответствующего
>     брэндинга. И кстати, это спорное состояние для тестирования,
>     подготовки
>     к переходу, но не для продакшена.
>
>
> Я полагал, что мы говорим о функциональности. Ради неё люди 
> обновляются. Могу понять предложение вынести в os-release 
> идентификатор, который отражает текущее состояние функциональности 
> системы. Но Вас сейчас не понял.
>

Вышеупомянутое обновление на бранч скорее 
экспериментально-ознакомительное, на свой страх и риск, если продуктов 
ещё не вышло. Если начинать нумерацию продуктов с 10.1, в которых что-то 
обещали, то переход на 10.0 довольно чётко показывает состояние с 
отсутствием заявленной функциональности, но актуальной пакетной базой.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 06.08.2021 01:06, Leonid Krivoshein wrote:
>
> 05.08.2021 23:44, Aleksey Novodvorsky пишет:
>> [...]
>>
>>
>>     >
>>     > У нас именно в 10.0 будут новшества в apt, работа идёт, мы
>>     говорили об
>>     > этом. А бранч будет доступен для обновления раньше.
>>     > То есть это как раз пример того, когда номер релиза, пусть
>>     условный,
>>     > не дает нужной информации.
>>
>>     Как раз это не пример, так как нет продукта -- нет анонса. И 
>> бранч --
>>     это не продукт с версией, в смысле не дистрибутив. А у нас, как 
>> верно
>>     заметил вчера Дима, обновление коммерческого продукта только из
>>     свободного бранча. Так что на мой взгляд переход на p10 ещё не 
>> меняет
>>     установленный дистрибутив до 10.0, пока не появится соответствующего
>>     брэндинга. И кстати, это спорное состояние для тестирования,
>>     подготовки
>>     к переходу, но не для продакшена.
>>
>>
>> Я полагал, что мы говорим о функциональности. Ради неё люди 
>> обновляются. Могу понять предложение вынести в os-release 
>> идентификатор, который отражает текущее состояние функциональности 
>> системы. Но Вас сейчас не понял.
>>
>
> Вышеупомянутое обновление на бранч скорее 
> экспериментально-ознакомительное, на свой страх и риск, если продуктов 
> ещё не вышло. Если начинать нумерацию продуктов с 10.1, в которых 
> что-то обещали, то переход на 10.0 довольно чётко показывает состояние 
> с отсутствием заявленной функциональности, но актуальной пакетной базой.
>
>
Выпускать бранч без привязки к продуктам вообще так себе идея.

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

Re: [devel-distro] branding

[Anton Farygin]

On 06.08.2021 08:29, Aleksey Novodvorsky wrote:
>
>     Ну или, говорить о том, что мы его выпустили и на него можно
>     переходить
>     - переходить можно будет только тогда, когда выйдут релизы основных
>     дистрибутивов. А до этого времени это альфа-версия стабильного
>     репозитория.
>
>
> Возможно, но это требует другого уровня организации работы и 
> планирования. И, соответственно, ресурсов. Давайте обсудим такой 
> вариант к p11. Это важно.
> И это не тема данного списка  рассылки, мне кажется.

Да конечно, но это никак не связано с выпуском p11.

Т.е. - мы прямо сейчас а анонсе можем назвать p10 версией для 
разработчика, а не для production use. При этом снимать этот статус 
сразу после выпуска релизов дистрибутивов.

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

Re: [devel-distro] branding

[Anton Farygin]

On 06.08.2021 08:45, Aleksey Novodvorsky wrote:
>
>
>
>
> пт, 6 авг. 2021 г., 08:35 Anton Farygin <rider@basealt.ru 
> <mailto:rider@basealt.ru>>:
>
>     On 06.08.2021 08:29, Aleksey Novodvorsky wrote:
>     >
>     >     Ну или, говорить о том, что мы его выпустили и на него можно
>     >     переходить
>     >     - переходить можно будет только тогда, когда выйдут релизы
>     основных
>     >     дистрибутивов. А до этого времени это альфа-версия стабильного
>     >     репозитория.
>     >
>     >
>     > Возможно, но это требует другого уровня организации работы и
>     > планирования. И, соответственно, ресурсов. Давайте обсудим такой
>     > вариант к p11. Это важно.
>     > И это не тема данного списка  рассылки, мне кажется.
>
>     Да конечно, но это никак не связано с выпуском p11.
>
>     Т.е. - мы прямо сейчас а анонсе можем назвать p10 версией для
>     разработчика, а не для production use. При этом снимать этот статус
>     сразу после выпуска релизов дистрибутивов.
>
>     С одной стороны нам нужен форк бранча для выпуска образов, а с другой
>     стороны - мы его не можем рекомендовать к использованию, пока он не
>     будет в должной степени проверен на всех поставляемых конфигурациях.
>
>
> С этим не согласен. Такие вещи надо обсуждать заранее.
> Мы напишем, конечно, что продукты выйдут в октябре и что бранч 
> источник из разработки, но "десакрализация" бранча всех запутает в 
> публичном поле.
>
Скорее распутает - текущая ситуация с выпуском так называемого 
стабильного бранча до выпуска настоящих дистрибутивов на нём путает всех 
однозначно.

Re: [devel-distro] branding

[Anton Farygin]

On 06.08.2021 08:59, Aleksey Novodvorsky wrote:
>
>
>
>
> пт, 6 авг. 2021 г., 08:57 Anton Farygin <rider@basealt.ru 
> <mailto:rider@basealt.ru>>:
>
>     On 06.08.2021 08:45, Aleksey Novodvorsky wrote:
>     >
>     >
>     >
>     >
>     > пт, 6 авг. 2021 г., 08:35 Anton Farygin <rider@basealt.ru
>     <mailto:rider@basealt.ru>
>     > <mailto:rider@basealt.ru <mailto:rider@basealt.ru>>>:
>     >
>     >     On 06.08.2021 08:29, Aleksey Novodvorsky wrote:
>     >     >
>     >     >     Ну или, говорить о том, что мы его выпустили и на него
>     можно
>     >     >     переходить
>     >     >     - переходить можно будет только тогда, когда выйдут релизы
>     >     основных
>     >     >     дистрибутивов. А до этого времени это альфа-версия
>     стабильного
>     >     >     репозитория.
>     >     >
>     >     >
>     >     > Возможно, но это требует другого уровня организации работы и
>     >     > планирования. И, соответственно, ресурсов. Давайте обсудим
>     такой
>     >     > вариант к p11. Это важно.
>     >     > И это не тема данного списка  рассылки, мне кажется.
>     >
>     >     Да конечно, но это никак не связано с выпуском p11.
>     >
>     >     Т.е. - мы прямо сейчас а анонсе можем назвать p10 версией для
>     >     разработчика, а не для production use. При этом снимать этот
>     статус
>     >     сразу после выпуска релизов дистрибутивов.
>     >
>     >     С одной стороны нам нужен форк бранча для выпуска образов, а
>     с другой
>     >     стороны - мы его не можем рекомендовать к использованию,
>     пока он не
>     >     будет в должной степени проверен на всех поставляемых
>     конфигурациях.
>     >
>     >
>     > С этим не согласен. Такие вещи надо обсуждать заранее.
>     > Мы напишем, конечно, что продукты выйдут в октябре и что бранч
>     > источник из разработки, но "десакрализация" бранча всех запутает в
>     > публичном поле.
>     >
>     Скорее распутает - текущая ситуация с выпуском так называемого
>     стабильного бранча до выпуска настоящих дистрибутивов на нём
>     путает всех
>     однозначно.
>
>
> Это обычная, штатная на сегодня  ситуация, мы ничего не меняем.
>
Так эта ситуация раз в три года всех и путает. Она абсолютно внештатная 
и непонятная.

В прошлый раз я замучался всем объяснять то, что не надо спешить с 
обновлением до p9, пока мы не оттестируем его в дистрибутивах.

Re: [devel-distro] branding

[Anton Farygin]

On 06.08.2021 09:04, Aleksey Novodvorsky wrote:
>
>
>
>
> пт, 6 авг. 2021 г., 09:02 Anton Farygin <rider@basealt.ru 
> <mailto:rider@basealt.ru>>:
>
>     On 06.08.2021 08:59, Aleksey Novodvorsky wrote:
>     >
>     >
>     >
>     >
>     > пт, 6 авг. 2021 г., 08:57 Anton Farygin <rider@basealt.ru
>     <mailto:rider@basealt.ru>
>     > <mailto:rider@basealt.ru <mailto:rider@basealt.ru>>>:
>     >
>     >     On 06.08.2021 08:45, Aleksey Novodvorsky wrote:
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > пт, 6 авг. 2021 г., 08:35 Anton Farygin <rider@basealt.ru
>     <mailto:rider@basealt.ru>
>     >     <mailto:rider@basealt.ru <mailto:rider@basealt.ru>>
>     >     > <mailto:rider@basealt.ru <mailto:rider@basealt.ru>
>     <mailto:rider@basealt.ru <mailto:rider@basealt.ru>>>>:
>     >     >
>     >     >     On 06.08.2021 08:29, Aleksey Novodvorsky wrote:
>     >     >     >
>     >     >     >     Ну или, говорить о том, что мы его выпустили и
>     на него
>     >     можно
>     >     >     >     переходить
>     >     >     >     - переходить можно будет только тогда, когда
>     выйдут релизы
>     >     >     основных
>     >     >     >     дистрибутивов. А до этого времени это альфа-версия
>     >     стабильного
>     >     >     >     репозитория.
>     >     >     >
>     >     >     >
>     >     >     > Возможно, но это требует другого уровня организации
>     работы и
>     >     >     > планирования. И, соответственно, ресурсов. Давайте
>     обсудим
>     >     такой
>     >     >     > вариант к p11. Это важно.
>     >     >     > И это не тема данного списка рассылки, мне кажется.
>     >     >
>     >     >     Да конечно, но это никак не связано с выпуском p11.
>     >     >
>     >     >     Т.е. - мы прямо сейчас а анонсе можем назвать p10
>     версией для
>     >     >     разработчика, а не для production use. При этом
>     снимать этот
>     >     статус
>     >     >     сразу после выпуска релизов дистрибутивов.
>     >     >
>     >     >     С одной стороны нам нужен форк бранча для выпуска
>     образов, а
>     >     с другой
>     >     >     стороны - мы его не можем рекомендовать к использованию,
>     >     пока он не
>     >     >     будет в должной степени проверен на всех поставляемых
>     >     конфигурациях.
>     >     >
>     >     >
>     >     > С этим не согласен. Такие вещи надо обсуждать заранее.
>     >     > Мы напишем, конечно, что продукты выйдут в октябре и что бранч
>     >     > источник из разработки, но "десакрализация" бранча всех
>     запутает в
>     >     > публичном поле.
>     >     >
>     >     Скорее распутает - текущая ситуация с выпуском так называемого
>     >     стабильного бранча до выпуска настоящих дистрибутивов на нём
>     >     путает всех
>     >     однозначно.
>     >
>     >
>     > Это обычная, штатная на сегодня  ситуация, мы ничего не меняем.
>     >
>     Так эта ситуация раз в три года всех и путает. Она абсолютно
>     внештатная
>     и непонятная.
>
>     В прошлый раз я замучался всем объяснять то, что не надо спешить с
>     обновлением до p9, пока мы не оттестируем его в дистрибутивах.
>
>
> Давай напишем, что поддержка обновлений коммерческих продуктов 
> начнется с выходом их версий 10.
>
Да, выглядит разумно.

Спасибо.

Re: [devel-distro] branding

[Anton Farygin]

On 05.08.2021 23:44, Aleksey Novodvorsky wrote:
>
>     Как раз это не пример, так как нет продукта -- нет анонса. И бранч --
>     это не продукт с версией, в смысле не дистрибутив. А у нас, как верно
>     заметил вчера Дима, обновление коммерческого продукта только из
>     свободного бранча. Так что на мой взгляд переход на p10 ещё не меняет
>     установленный дистрибутив до 10.0, пока не появится соответствующего
>     брэндинга. И кстати, это спорное состояние для тестирования,
>     подготовки
>     к переходу, но не для продакшена.
>
>
> Я полагал, что мы говорим о функциональности. Ради неё люди 
> обновляются. Могу понять предложение вынести в os-release 
> идентификатор, который отражает текущее состояние функциональности 
> системы. Но Вас сейчас не понял.

А можно поподробнее про функциональность ?

Чем таким, кроме тулчейна и яхыков программирования новый бранч 
интереснее старого ?

Re: [devel-distro] branding

[Alexey Shabalin]

чт, 5 авг. 2021 г. в 21:12, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
> чт, 5 авг. 2021 г., 20:57 Aleksey Novodvorsky <aen@basealt.ru>:
>>
>>
>>
>> чт, 5 авг. 2021 г., 20:41 Alexey Shabalin <a.shabalin@gmail.com>:
>>>
>>> чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky <aen@basealt.ru>:
>>> >
>>> >
>>> >
>>> > чт, 5 авг. 2021 г., 19:38 Alexey Shabalin <a.shabalin@gmail.com>:
>>> >>
>>> >> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov <sem@altlinux.org>:
>>> >> >
>>> >> > On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>>> >> > > По сути же, мне не нравится любое изменение , не согласованное со всеми
>>> >> > > релиз-менеджерами.
>>> >> >
>>> >> > Когда я о нем писал почти никто не отреагировал:
>>> >> > https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>>> >>
>>> >> Для релиз менеджера, который тестирует разные beta и rc, причем
>>> >> исключительно новыми установками, это изменение возможно полезное.
>>> >> Но на системах, которые никакого отношения не имеют к beta, установка
>>> >> только из релиза и в дальнейшем многолетняя эксплуатация с
>>> >> обновлениями, это изменение вредное.
>>> >>
>>> >> Давай попробуем не рассматривать юридические аспекты, остановимся
>>> >> только на технических.
>>> >> При эксплуатации и  обслуживании системы, через пару-тройку лет, а еще
>>> >> и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно все равно,
>>> >> откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо важнее, текущее
>>> >> состояние версии - 8, 9 или 10. И для этого есть стандартное место -
>>> >> /etc/os-release или /etc/altlinux-release.
>>> >> Заглянуть в эти файлы проще, чем делать rpm -q --qf "%{VERSION}"
>>> >> branding-alt-workstation-release, а еще перед этим надо узнать имя
>>> >> пакета, workstation или какое-другое.
>>> >> А дальше еще нужно переписать кучу софта, который смотрит в /etc/os-release.
>>> >> Вы готовы пропатчить все возможное? Начиная с python3-module-distro,
>>> >> platform.freedesktop_os_release() в будущем python-3.10? Кучу
>>> >> остального прикладного софта?
>>> >> Этот прикладной софт не знает, что было придумано в Альт в 2017 году.
>>> >> Во всех дистрибутивах принято в /etc/os-release хранить текущую версию
>>> >> (ок, называйте как угодно, пусть будет версия пакета branding, а не
>>> >> версия дистрибутива - меня устроит любое определение). У альт и так
>>> >> много специфических отличий, но зачем тут создавать ненужное отличие
>>> >> на ровном месте?
>>> >
>>> >
>>> > На ровном месте точно не нужно.
>>> > Давайте обратимся к "мелочам".
>>> > Что должно быть в os-release у обновившихся с p9 до p10 до выхода 10.0?
>>>
>>> Лучше, чтобы уже было написано "10.0". Вас это все равно ни к чему не
>>> обязывает - релиза еще не было и iso образов еще нет.
>>
>>
>> У нас именно в 10.0 будут новшества в apt, работа идёт, мы говорили об этом. А бранч будет доступен для обновления раньше.
>> То есть это как раз пример того, когда номер релиза, пусть условный, не дает нужной информации.
>
>
> Возможно, стоит считать начальный бранч релизом 0 ,   а продукты выпускать начиная с 1.
> То есть версия -- это состояние бранча. На котором могут выпускаются продукты.

Не стоит переусложнять. Ничто не мешает выпустить продукты с "10.0".

-- 
Alexey Shabalin

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 23:05, Alexey Shabalin пишет:
> чт, 5 авг. 2021 г. в 21:12, Aleksey Novodvorsky <aen@basealt.ru>:
>> [...]
>> Возможно, стоит считать начальный бранч релизом 0 ,   а продукты выпускать начиная с 1.
>> То есть версия -- это состояние бранча. На котором могут выпускаются продукты.
> Не стоит переусложнять. Ничто не мешает выпустить продукты с "10.0".

А в чём ты видишь тут сложности? И да, это не противоречит одно другому, 
если продуктами 10.0.x считать предварительные, тестовые сборки. 
По-моему, красивая идея, которая как будет максимально отражать 
состояние всего и подчёркивать неприменимость для продакшена.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton V. Boyarshinov]

В Thu, 5 Aug 2021 23:44:32 +0300
Leonid Krivoshein <klark.devel@gmail.com> пишет:

> >> То есть версия -- это состояние бранча. На котором могут выпускаются продукты.  
> > Не стоит переусложнять. Ничто не мешает выпустить продукты с "10.0".  
> 
> А в чём ты видишь тут сложности? И да, это не противоречит одно другому, 
> если продуктами 10.0.x считать предварительные, тестовые сборки.

У каждого продукта своё версионирование и не вполне понятно -- как
можно связать это версионирование с "версией бранча". Версия бранча это
вообще имя_бранча+дата.

Re: [devel-distro] branding

[Anton Farygin]

On 16.08.2021 10:19, Anton V. Boyarshinov wrote:
> В Thu, 5 Aug 2021 23:44:32 +0300
> Leonid Krivoshein <klark.devel@gmail.com> пишет:
>
>>>> То есть версия -- это состояние бранча. На котором могут выпускаются продукты.
>>> Не стоит переусложнять. Ничто не мешает выпустить продукты с "10.0".
>> А в чём ты видишь тут сложности? И да, это не противоречит одно другому,
>> если продуктами 10.0.x считать предварительные, тестовые сборки.
> У каждого продукта своё версионирование и не вполне понятно -- как
> можно связать это версионирование с "версией бранча". Версия бранча это
> вообще имя_бранча+дата.

У /etc/os-release есть куча полей, куда можно записывать и дату бранча в 
том числе.

Плюс в стандарте есть возможность создавать свои расширения.

Re: [devel-distro] branding

[Anton V. Boyarshinov]

 
> > У каждого продукта своё версионирование и не вполне понятно -- как
> > можно связать это версионирование с "версией бранча". Версия бранча это
> > вообще имя_бранча+дата.  
> 
> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в 
> том числе.
> 
> Плюс в стандарте есть возможность создавать свои расширения.

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

Re: [devel-distro] branding

[Anton Farygin]

On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
>   
>>> У каждого продукта своё версионирование и не вполне понятно -- как
>>> можно связать это версионирование с "версией бранча". Версия бранча это
>>> вообще имя_бранча+дата.
>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
>> том числе.
>>
>> Плюс в стандарте есть возможность создавать свои расширения.
> Значит надо продумать как единообразным образом использовать эти кучу
> полей и, возможно, расширения.

Я для обсуждеия этого повесил баг:

https://bugzilla.altlinux.org/40703

предлагаю с обсуждением переместиться туда.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
> >   
> >>> У каждого продукта своё версионирование и не вполне понятно -- как
> >>> можно связать это версионирование с "версией бранча". Версия бранча это
> >>> вообще имя_бранча+дата.
> >> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
> >> том числе.
> >>
> >> Плюс в стандарте есть возможность создавать свои расширения.
> > Значит надо продумать как единообразным образом использовать эти кучу
> > полей и, возможно, расширения.
> 
> Я для обсуждеия этого повесил баг:
> 
> https://bugzilla.altlinux.org/40703
> 
> предлагаю с обсуждением переместиться туда.

Обсуждать в баге неудобно.
Я предлагаю следующую простую схему.

Файл /etc/altlinux-release обновляется, как обычные файлы.
Файл /etc/os-release обновляется по правилам, описанным ниже.

Все провайдеры os-release пакуют его в /usr/lib/os-release
(согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
/usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
Они же пакуют %ghost /etc/os-release нулевого размера.
Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
и мержит изменения в /etc/os-release следующим образом:

Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
имена которых начинаются с префикса ALT_installed_, копируются в
/etc/os-release, при этом, если в /etc/os-release уже были параметры с
такими именами, то:

- старые параметры, имена и значения которых совпадают с новыми,
  удаляются;
- остальные старые параметры, имена которых совпадают с новыми,
  переименовываются путём добавления префикса ALT_installed_ и добавляются
  в /etc/os-release, если параметров с такими именами там ещё не было, в
  противном случае удаляются.


-- 
ldv

Re: [devel-distro] branding

[Sergey V Turchin]

On Thursday, 19 August 2021 13:33:46 MSK Dmitry V wrote:

[...]
> Я предлагаю следующую простую схему.
> 
> Файл /etc/altlinux-release обновляется, как обычные файлы.
> Файл /etc/os-release обновляется по правилам, описанным ниже.
> 
> Все провайдеры os-release пакуют его в /usr/lib/os-release
> (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
Это существенно, т.к. означает, что /usr/lib/os-release может быть 
альтернативой.

> Они же пакуют %ghost /etc/os-release нулевого размера.
Этого им как раз не нужно делать вообще.

> Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> и мержит изменения в /etc/os-release следующим образом:
Этот пакет и содержит /etc/os-release.

[...]

-- 
Regards, Sergey.

Re: [devel-distro] os-release

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 01:43:49PM +0300, Sergey V Turchin wrote:
> On Thursday, 19 August 2021 13:33:46 MSK Dmitry V wrote:
> 
> [...]
> > Я предлагаю следующую простую схему.
> > 
> > Файл /etc/altlinux-release обновляется, как обычные файлы.
> > Файл /etc/os-release обновляется по правилам, описанным ниже.
> > 
> > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> > /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
> Это существенно, т.к. означает, что /usr/lib/os-release может быть 
> альтернативой.

Это несущественно в том смысле, что эта деталь реализации находится за
пределами рассмотрения.

> > Они же пакуют %ghost /etc/os-release нулевого размера.
> Этого им как раз не нужно делать вообще.

Файл /etc/os-release должен кому-то принадлежать, поэтому паковать его надо.
Но заменять содержимое /etc/os-release напрямую нельзя, поэтому %ghost.

> > Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> > и мержит изменения в /etc/os-release следующим образом:
> Этот пакет и содержит /etc/os-release.

Ни один пакет не должен содержать /etc/os-release, потому что
/etc/os-release должен быть результатом объединения прежнего содержимого
/etc/os-release и нового содержимого /usr/lib/os-release.

Прочитай, пожалуйста, то письмо, на которое отвечаешь, я там описал
предлагаемые правила формирования /etc/os-release после каждого обновления
/usr/lib/os-release.


-- 
ldv

Re: [devel-distro] os-release

[Sergey V Turchin]

On Thursday, 19 August 2021 14:22:24 MSK Dmitry V wrote:
> On Thu, Aug 19, 2021 at 01:43:49PM +0300, Sergey V Turchin wrote:
> > On Thursday, 19 August 2021 13:33:46 MSK Dmitry V wrote:
> > 
> > [...]
> > 
> > > Я предлагаю следующую простую схему.
> > > 
> > > Файл /etc/altlinux-release обновляется, как обычные файлы.
> > > Файл /etc/os-release обновляется по правилам, описанным ниже.
> > > 
> > > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > > (согласно
> > > https://www.freedesktop.org/software/systemd/man/os-release.html),
> > > /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.> 
> > Это существенно, т.к. означает, что /usr/lib/os-release может быть
> > альтернативой.
> Это несущественно в том смысле, что эта деталь реализации находится за
> пределами рассмотрения.
Это существенно, т.к. способно похерить всё хорошее один раз и накорню.

[...]
> Файл /etc/os-release должен кому-то принадлежать, поэтому паковать его надо.
[...]
> Ни один пакет не должен содержать /etc/os-release
Чего-чего?

[...]

Я, вообще, говорю о схеме, при которой пакеты c release-файлами перестанут 
конфликтовать.

Т.е. `rpm -qf /etc/os-release /usr/lib/os-release` должен показывать только 
тот единственный в репозитории пакет, в котором лежит файлтриггер, обновляющий 
содержимое /etc/os-release.


-- 
Regards, Sergey.

Re: [devel-distro] os-release

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 02:36:13PM +0300, Sergey V Turchin wrote:
> On Thursday, 19 August 2021 14:22:24 MSK Dmitry V wrote:
> > On Thu, Aug 19, 2021 at 01:43:49PM +0300, Sergey V Turchin wrote:
> > > On Thursday, 19 August 2021 13:33:46 MSK Dmitry V wrote:
> > > 
> > > [...]
> > > 
> > > > Я предлагаю следующую простую схему.
> > > > 
> > > > Файл /etc/altlinux-release обновляется, как обычные файлы.
> > > > Файл /etc/os-release обновляется по правилам, описанным ниже.
> > > > 
> > > > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > > > (согласно
> > > > https://www.freedesktop.org/software/systemd/man/os-release.html),
> > > > /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.> 
> > > Это существенно, т.к. означает, что /usr/lib/os-release может быть
> > > альтернативой.
> > Это несущественно в том смысле, что эта деталь реализации находится за
> > пределами рассмотрения.
> Это существенно, т.к. способно похерить всё хорошее один раз и накорню.

Я надеюсь, что вы справитесь.

> [...]
> > Файл /etc/os-release должен кому-то принадлежать, поэтому паковать его надо.
> [...]
> > Ни один пакет не должен содержать /etc/os-release
> Чего-чего?

Кроме того, предлагаю дополнить sisyphus_check следующими проверками:
- каждому пакету либо принадлежит каждый из трёх файлов (/etc/altlinux-release
  /etc/os-release /usr/lib/os-release, либо не принадлежит ни один из них.
- файл /etc/os-release должен быть нулевого размера.

> Т.е. `rpm -qf /etc/os-release /usr/lib/os-release` должен показывать только 
> тот единственный в репозитории пакет, в котором лежит файлтриггер, обновляющий 
> содержимое /etc/os-release.

Файлтриггер для обновления /etc/os-release НЕ должен принадлежать пакету,
которому принадлежит os-release.  Этот файлтриггер вообще можно запаковать
в пакет rpm.


-- 
ldv

Re: [devel-distro] os-release

[Sergey V Turchin]

On Thursday, 19 August 2021 14:50:06 MSK Dmitry V wrote:
> On Thu, Aug 19, 2021 at 02:36:13PM +0300, Sergey V Turchin wrote:
> > On Thursday, 19 August 2021 14:22:24 MSK Dmitry V wrote:
> > > On Thu, Aug 19, 2021 at 01:43:49PM +0300, Sergey V Turchin wrote:
> > > > On Thursday, 19 August 2021 13:33:46 MSK Dmitry V wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > Я предлагаю следующую простую схему.
> > > > > 
> > > > > Файл /etc/altlinux-release обновляется, как обычные файлы.
> > > > > Файл /etc/os-release обновляется по правилам, описанным ниже.
> > > > > 
> > > > > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > > > > (согласно
> > > > > https://www.freedesktop.org/software/systemd/man/os-release.html),
> > > > > /usr/lib/os-release может быть ссылкой куда-то ещё, это
> > > > > несущественно.>
> > > > 
> > > > Это существенно, т.к. означает, что /usr/lib/os-release может быть
> > > > альтернативой.
> > > 
> > > Это несущественно в том смысле, что эта деталь реализации находится за
> > > пределами рассмотрения.
> > 
> > Это существенно, т.к. способно похерить всё хорошее один раз и накорню.
> 
> Я надеюсь, что вы справитесь.
После https://bugzilla.altlinux.org/39830 мне сложно такую фразу не 
воспринимать, как подколку.

[...]
> Кроме того, предлагаю дополнить sisyphus_check следующими проверками:
> - каждому пакету либо принадлежит каждый из трёх файлов
> (/etc/altlinux-release /etc/os-release /usr/lib/os-release, либо не
> принадлежит ни один из них. - файл /etc/os-release должен быть нулевого
> размера.
Да, только вместо "каждому" пусть будет конкретное имя одного пакета.

> > Т.е. `rpm -qf /etc/os-release /usr/lib/os-release` должен показывать
> > только
> > тот единственный в репозитории пакет, в котором лежит файлтриггер,
> > обновляющий содержимое /etc/os-release.
> Файлтриггер для обновления /etc/os-release НЕ должен принадлежать пакету,
> которому принадлежит os-release.  Этот файлтриггер вообще можно запаковать
> в пакет rpm.
Без проблем, пусть так.
Он же может формировать /etc/altlinux-release на основе os-release.

-- 
Regards, Sergey.

Re: [devel-distro] os-release

[Anton Farygin]

On 19.08.2021 14:50, Dmitry V. Levin wrote:
> On Thu, Aug 19, 2021 at 02:36:13PM +0300, Sergey V Turchin wrote:
>> On Thursday, 19 August 2021 14:22:24 MSK Dmitry V wrote:
>>
>> Т.е. `rpm -qf /etc/os-release /usr/lib/os-release` должен показывать только
>> тот единственный в репозитории пакет, в котором лежит файлтриггер, обновляющий
>> содержимое /etc/os-release.
> Файлтриггер для обновления /etc/os-release НЕ должен принадлежать пакету,
> которому принадлежит os-release.  Этот файлтриггер вообще можно запаковать
> в пакет rpm.
>
>
Вот это прекрасная идея!

Я ещё думал над тем, что бы при каждом успешном dist-upgrade в 
/etc/os-release куда-то записывать дату и имя бранча, на который был 
сделан успешный dist-upgrade.

Но для этого у apt'а нет никакой поддержки, и мне видится что нужен 
какой-то ежедневно-обновляемый altlinux-release-branch, содержащий в 
себе дату публикации репозитория в каком-нибуть BUILD_ID= и, эта дата, 
должна мержится в /etc/os-release в том же файлтриггере.

Re: [devel-distro] branding

[Anton Farygin]

On 19.08.2021 13:33, Dmitry V. Levin wrote:
> On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
>> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
>>>    
>>>>> У каждого продукта своё версионирование и не вполне понятно -- как
>>>>> можно связать это версионирование с "версией бранча". Версия бранча это
>>>>> вообще имя_бранча+дата.
>>>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
>>>> том числе.
>>>>
>>>> Плюс в стандарте есть возможность создавать свои расширения.
>>> Значит надо продумать как единообразным образом использовать эти кучу
>>> полей и, возможно, расширения.
>> Я для обсуждеия этого повесил баг:
>>
>> https://bugzilla.altlinux.org/40703
>>
>> предлагаю с обсуждением переместиться туда.
> Обсуждать в баге неудобно.
Вообще, конечно, bugzilla именно для этого и предназначена. Ну да ладно. 
Давайте здесь.
> Я предлагаю следующую простую схему.
>
> Файл /etc/altlinux-release обновляется, как обычные файлы.

Т.е. - просто лежит в пакете, который приезжает с каждой новой версией 
пакета, содержащего этот файл?

Например, в моём случае это branding-xalt-kworkstation-release

> Файл /etc/os-release обновляется по правилам, описанным ниже.
>
> Все провайдеры os-release пакуют его в /usr/lib/os-release
> (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
> Они же пакуют %ghost /etc/os-release нулевого размера.
Ну или действительно как предложил зерг - запаковать в файлтриггер.
> Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> и мержит изменения в /etc/os-release следующим образом:
>
> Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
> имена которых начинаются с префикса ALT_installed_, копируются в
> /etc/os-release, при этом, если в /etc/os-release уже были параметры с
> такими именами, то:
>
> - старые параметры, имена и значения которых совпадают с новыми,
>    удаляются;
Т.е., говоря проще - заменяются новыми значениями из /usr/lib/os-release
> - остальные старые параметры, имена которых совпадают с новыми,
>    переименовываются путём добавления префикса ALT_installed_ и добавляются
>    в /etc/os-release, если параметров с такими именами там ещё не было, в
>    противном случае удаляются.

Вот это вообще непонятно, что имеется в виду.


можно пример, на:
$ cat /etc/os-release
NAME="ALT"
VERSION="9.2 "
ID=altlinux
VERSION_ID=9.2
PRETTY_NAME="ALT Workstation K 9.2  (Centaurea Pineticola)"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:kworkstation:9.2"
HOME_URL="https://www.basealt.ru/"
BUG_REPORT_URL="https://bugs.altlinux.org/"
DOCUMENTATION_URL="https://docs.altlinux.org/"
SUPPORT_URL="https://support.basealt.ru/"

Что из этого должно переименоваться в ALT_installed ?

>
>

Re: [devel-distro] os-release

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 02:19:11PM +0300, Anton Farygin wrote:
> On 19.08.2021 13:33, Dmitry V. Levin wrote:
> > On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
> >> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
> >>>    
> >>>>> У каждого продукта своё версионирование и не вполне понятно -- как
> >>>>> можно связать это версионирование с "версией бранча". Версия бранча это
> >>>>> вообще имя_бранча+дата.
> >>>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
> >>>> том числе.
> >>>>
> >>>> Плюс в стандарте есть возможность создавать свои расширения.
> >>> Значит надо продумать как единообразным образом использовать эти кучу
> >>> полей и, возможно, расширения.
> >> Я для обсуждеия этого повесил баг:
> >>
> >> https://bugzilla.altlinux.org/40703
> >>
> >> предлагаю с обсуждением переместиться туда.
> > Обсуждать в баге неудобно.
> Вообще, конечно, bugzilla именно для этого и предназначена. Ну да ладно. 
> Давайте здесь.
> > Я предлагаю следующую простую схему.
> >
> > Файл /etc/altlinux-release обновляется, как обычные файлы.
> 
> Т.е. - просто лежит в пакете, который приезжает с каждой новой версией 
> пакета, содержащего этот файл?

Да, тут сложно что-то другое придумать, формат этого файла слишком
негибкий.  Были предложения копировать /etc/altlinux-release куда-то,
но при наличии os-release это выглядит избыточным.

> Например, в моём случае это branding-xalt-kworkstation-release
> 
> > Файл /etc/os-release обновляется по правилам, описанным ниже.
> >
> > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> > /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
> > Они же пакуют %ghost /etc/os-release нулевого размера.
> Ну или действительно как предложил зерг - запаковать в файлтриггер.
> > Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> > и мержит изменения в /etc/os-release следующим образом:
> >
> > Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
> > имена которых начинаются с префикса ALT_installed_, копируются в
> > /etc/os-release, при этом, если в /etc/os-release уже были параметры с
> > такими именами, то:
> >
> > - старые параметры, имена и значения которых совпадают с новыми,
> >    удаляются;
> Т.е., говоря проще - заменяются новыми значениями из /usr/lib/os-release
> > - остальные старые параметры, имена которых совпадают с новыми,
> >    переименовываются путём добавления префикса ALT_installed_ и добавляются
> >    в /etc/os-release, если параметров с такими именами там ещё не было, в
> >    противном случае удаляются.
> 
> Вот это вообще непонятно, что имеется в виду.

Имеется в виду, что когда из /usr/lib/os-release приезжают параметры с
теми же именами, что и в /etc/os-release, но с другими значениями, то
такие параметры в /etc/os-release переименовываются.

> можно пример, на:
> $ cat /etc/os-release
> NAME="ALT"
> VERSION="9.2 "
> ID=altlinux
> VERSION_ID=9.2
> PRETTY_NAME="ALT Workstation K 9.2  (Centaurea Pineticola)"
> ANSI_COLOR="1;33"
> CPE_NAME="cpe:/o:alt:kworkstation:9.2"
> HOME_URL="https://www.basealt.ru/"
> BUG_REPORT_URL="https://bugs.altlinux.org/"
> DOCUMENTATION_URL="https://docs.altlinux.org/"
> SUPPORT_URL="https://support.basealt.ru/"
> 
> Что из этого должно переименоваться в ALT_installed ?

А что в /usr/lib/os-release?


-- 
ldv

Re: [devel-distro] os-release

[Anton Farygin]

On 19.08.2021 14:29, Dmitry V. Levin wrote:
> On Thu, Aug 19, 2021 at 02:19:11PM +0300, Anton Farygin wrote:
>> On 19.08.2021 13:33, Dmitry V. Levin wrote:
>>> On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
>>>> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
>>>>>     
>>>>>>> У каждого продукта своё версионирование и не вполне понятно -- как
>>>>>>> можно связать это версионирование с "версией бранча". Версия бранча это
>>>>>>> вообще имя_бранча+дата.
>>>>>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
>>>>>> том числе.
>>>>>>
>>>>>> Плюс в стандарте есть возможность создавать свои расширения.
>>>>> Значит надо продумать как единообразным образом использовать эти кучу
>>>>> полей и, возможно, расширения.
>>>> Я для обсуждеия этого повесил баг:
>>>>
>>>> https://bugzilla.altlinux.org/40703
>>>>
>>>> предлагаю с обсуждением переместиться туда.
>>> Обсуждать в баге неудобно.
>> Вообще, конечно, bugzilla именно для этого и предназначена. Ну да ладно.
>> Давайте здесь.
>>> Я предлагаю следующую простую схему.
>>>
>>> Файл /etc/altlinux-release обновляется, как обычные файлы.
>> Т.е. - просто лежит в пакете, который приезжает с каждой новой версией
>> пакета, содержащего этот файл?
> Да, тут сложно что-то другое придумать, формат этого файла слишком
> негибкий.  Были предложения копировать /etc/altlinux-release куда-то,
> но при наличии os-release это выглядит избыточным.

Этот файл вообще избыточен и нужен для совместимости с совсем старыми 
системами.

Ещё, мне кажется, надо избавляться от вот этого мнимого соответствия 
RedHat и Fedora:

/etc/fedora-release
/etc/os-release
/etc/redhat-release
/etc/system-release

>
>> Например, в моём случае это branding-xalt-kworkstation-release
>>
>>> Файл /etc/os-release обновляется по правилам, описанным ниже.
>>>
>>> Все провайдеры os-release пакуют его в /usr/lib/os-release
>>> (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
>>> /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
>>> Они же пакуют %ghost /etc/os-release нулевого размера.
>> Ну или действительно как предложил зерг - запаковать в файлтриггер.
>>> Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
>>> и мержит изменения в /etc/os-release следующим образом:
>>>
>>> Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
>>> имена которых начинаются с префикса ALT_installed_, копируются в
>>> /etc/os-release, при этом, если в /etc/os-release уже были параметры с
>>> такими именами, то:
>>>
>>> - старые параметры, имена и значения которых совпадают с новыми,
>>>     удаляются;
>> Т.е., говоря проще - заменяются новыми значениями из /usr/lib/os-release
>>> - остальные старые параметры, имена которых совпадают с новыми,
>>>     переименовываются путём добавления префикса ALT_installed_ и добавляются
>>>     в /etc/os-release, если параметров с такими именами там ещё не было, в
>>>     противном случае удаляются.
>> Вот это вообще непонятно, что имеется в виду.
> Имеется в виду, что когда из /usr/lib/os-release приезжают параметры с
> теми же именами, что и в /etc/os-release, но с другими значениями, то
> такие параметры в /etc/os-release переименовываются.
А если переименовываемые параметры уже были ?
>
>> можно пример, на:
>> $ cat /etc/os-release
>> NAME="ALT"
>> VERSION="9.2 "
>> ID=altlinux
>> VERSION_ID=9.2
>> PRETTY_NAME="ALT Workstation K 9.2  (Centaurea Pineticola)"
>> ANSI_COLOR="1;33"
>> CPE_NAME="cpe:/o:alt:kworkstation:9.2"
>> HOME_URL="https://www.basealt.ru/"
>> BUG_REPORT_URL="https://bugs.altlinux.org/"
>> DOCUMENTATION_URL="https://docs.altlinux.org/"
>> SUPPORT_URL="https://support.basealt.ru/"
>>
>> Что из этого должно переименоваться в ALT_installed ?
> А что в /usr/lib/os-release?
>
Сейчас одинаковое. Это плохой пример. вот хороший (тут Sisyphus):
$ cat /etc/os-release
NAME="ALT Server"
VERSION="8.2 (april)"
ID=altlinux
VERSION_ID=8.2
PRETTY_NAME="ALT 8.2 Server (april)"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt linux:school server:8.2"
HOME_URL="http://altlinux.ru/"

BUG_REPORT_URL="https://bugs.altlinux.org/"


$ cat /usr/share/branding-data-current/release/os-release (по новой 
схеме это будет /usr/lib/os-release)
NAME="ALT Server"
VERSION="9.2"
ID=altlinux
VERSION_ID=9.2
PRETTY_NAME="ALT Server 9.2 (FalcoRusticolus)"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:server:9.2"
HOME_URL="https://basealt.ru/"
BUG_REPORT_URL="https://bugs.altlinux.org/"

Re: [devel-distro] os-release

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 02:39:21PM +0300, Andrey Cherepanov wrote:
> 19.08.2021 13:33, Dmitry V. Levin пишет:
> > On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
> >> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
> >>>    
> >>>>> У каждого продукта своё версионирование и не вполне понятно -- как
> >>>>> можно связать это версионирование с "версией бранча". Версия бранча это
> >>>>> вообще имя_бранча+дата.
> >>>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
> >>>> том числе.
> >>>>
> >>>> Плюс в стандарте есть возможность создавать свои расширения.
> >>> Значит надо продумать как единообразным образом использовать эти кучу
> >>> полей и, возможно, расширения.
> >> Я для обсуждеия этого повесил баг:
> >>
> >> https://bugzilla.altlinux.org/40703
> >>
> >> предлагаю с обсуждением переместиться туда.
> > Обсуждать в баге неудобно.
> > Я предлагаю следующую простую схему.
> >
> > Файл /etc/altlinux-release обновляется, как обычные файлы.
> > Файл /etc/os-release обновляется по правилам, описанным ниже.
> >
> > Все провайдеры os-release пакуют его в /usr/lib/os-release
> > (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> > /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
> > Они же пакуют %ghost /etc/os-release нулевого размера.
> > Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> > и мержит изменения в /etc/os-release следующим образом:
> >
> > Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
> > имена которых начинаются с префикса ALT_installed_, копируются в
> > /etc/os-release, при этом, если в /etc/os-release уже были параметры с
> > такими именами, то:
> >
> > - старые параметры, имена и значения которых совпадают с новыми,
> >    удаляются;
> > - остальные старые параметры, имена которых совпадают с новыми,
> >    переименовываются путём добавления префикса ALT_installed_ и добавляются
> >    в /etc/os-release, если параметров с такими именами там ещё не было, в
> >    противном случае удаляются.
> >
> а) избыточно сложный парсинг и слияние к тому же большого файла (по 
> сравнению просто с копией /etc/altlinux-release)

Это очень простой merger.  В чём избыточная сложность?
Какому пакету будет принадлежать копия /etc/altlinux-release?

> б) забыл про необновление лицензий.

Это было вообще не про os-release.

Ты предложил написать следующий текст:
"При обновлении пакетов branding-*-notes не должны перезаписываться файлы
/usr/share/alt-notes/license.*.html. Они должны соответствовать начальной                                                   
установке системы.
Это позволит сохранить именно ту версию лицензии, с которой соглашался
пользователь при установке системы."


-- 
ldv

Re: [devel-distro] os-release

[Andrey Cherepanov]

19.08.2021 14:43, Dmitry V. Levin пишет:
> On Thu, Aug 19, 2021 at 02:39:21PM +0300, Andrey Cherepanov wrote:
>> 19.08.2021 13:33, Dmitry V. Levin пишет:
>>> On Mon, Aug 16, 2021 at 12:26:55PM +0300, Anton Farygin wrote:
>>>> On 16.08.2021 12:22, Anton V. Boyarshinov wrote:
>>>>>     
>>>>>>> У каждого продукта своё версионирование и не вполне понятно -- как
>>>>>>> можно связать это версионирование с "версией бранча". Версия бранча это
>>>>>>> вообще имя_бранча+дата.
>>>>>> У /etc/os-release есть куча полей, куда можно записывать и дату бранча в
>>>>>> том числе.
>>>>>>
>>>>>> Плюс в стандарте есть возможность создавать свои расширения.
>>>>> Значит надо продумать как единообразным образом использовать эти кучу
>>>>> полей и, возможно, расширения.
>>>> Я для обсуждеия этого повесил баг:
>>>>
>>>> https://bugzilla.altlinux.org/40703
>>>>
>>>> предлагаю с обсуждением переместиться туда.
>>> Обсуждать в баге неудобно.
>>> Я предлагаю следующую простую схему.
>>>
>>> Файл /etc/altlinux-release обновляется, как обычные файлы.
>>> Файл /etc/os-release обновляется по правилам, описанным ниже.
>>>
>>> Все провайдеры os-release пакуют его в /usr/lib/os-release
>>> (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
>>> /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
>>> Они же пакуют %ghost /etc/os-release нулевого размера.
>>> Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
>>> и мержит изменения в /etc/os-release следующим образом:
>>>
>>> Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
>>> имена которых начинаются с префикса ALT_installed_, копируются в
>>> /etc/os-release, при этом, если в /etc/os-release уже были параметры с
>>> такими именами, то:
>>>
>>> - старые параметры, имена и значения которых совпадают с новыми,
>>>     удаляются;
>>> - остальные старые параметры, имена которых совпадают с новыми,
>>>     переименовываются путём добавления префикса ALT_installed_ и добавляются
>>>     в /etc/os-release, если параметров с такими именами там ещё не было, в
>>>     противном случае удаляются.
>>>
>> а) избыточно сложный парсинг и слияние к тому же большого файла (по
>> сравнению просто с копией /etc/altlinux-release)
> Это очень простой merger.  В чём избыточная сложность?

Зачем хранить всю информацию, если требуется только наименование 
операционной системы и её версии.

А так вместо одной строки нужно дублировать 5 (!).

> Какому пакету будет принадлежать копия /etc/altlinux-release?
>
Ни к какому.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel-distro] branding

[Leonid Krivoshein]

19.08.2021 14:39, Andrey Cherepanov пишет:
> а) избыточно сложный парсинг и слияние к тому же большого файла (по 
> сравнению просто с копией /etc/altlinux-release)

У меня тут другое сомнение. А как быть с downgrade или большими 
неудачными транзакциями установки? Главное, конечно, понять смысл этих 
перемен. Что именно будет идентифицировать генерат /etc/os-release? 
Другой вопрос: а что если некто ставит на HOLD пакет branding-*-release?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

Привет!


19.08.2021 13:33, Dmitry V. Levin пишет:
> [...]
> Я предлагаю следующую простую схему.

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


> Файл /etc/altlinux-release обновляется, как обычные файлы.

Сейчас он опакечивается, как файл конфигурации. Начиная с p8, уж точно. 
Если его изменит админ, он больше не будет обновляться. Это же касается 
и /etc/os-release, хотя в стандарте говорится следующее:

os-release contains data that is defined by the operating system vendor 
and should generally not be changed by the administrator.

Отсюда уточнение: будем давать админам право менять 
/etc/altlinux-release или сделаем обычным файлом? В принципе, стандарт 
не исключает любого из вариантов и можно оставить, как сейчас.


> Файл /etc/os-release обновляется по правилам, описанным ниже.
>
> Все провайдеры os-release пакуют его в /usr/lib/os-release
> (согласно https://www.freedesktop.org/software/systemd/man/os-release.html),
> /usr/lib/os-release может быть ссылкой куда-то ещё, это несущественно.
> Они же пакуют %ghost /etc/os-release нулевого размера.
> Файлриггер следит за обновлением пакетов, содержащих /usr/lib/os-release,
> и мержит изменения в /etc/os-release следующим образом:
>
> Все параметры, описанные в /usr/lib/os-release, за исключением параметров,
> имена которых начинаются с префикса ALT_installed_, копируются в
> /etc/os-release, при этом, если в /etc/os-release уже были параметры с
> такими именами, то:
>
> - старые параметры, имена и значения которых совпадают с новыми,
>    удаляются;
> - остальные старые параметры, имена которых совпадают с новыми,
>    переименовываются путём добавления префикса ALT_installed_ и добавляются
>    в /etc/os-release, если параметров с такими именами там ещё не было, в
>    противном случае удаляются.

Да, стандарт допускает введение собственных параметров. Но зачем эти 
параметры нам? Нужно ли нам хранить всё, что ранее было записано в 
/etc/os-release? В стандарте есть хорошее поле, которое как раз не 
должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что 
стоит пересохранять через файлтриггер.

Что касается бранча, то текущий показывает apt-repo, а на каком 
строилось первоначальное решение, однозначно определяется по BUILD_ID.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
[...]
> Да, стандарт допускает введение собственных параметров. Но зачем эти 
> параметры нам? Нужно ли нам хранить всё, что ранее было записано в 
> /etc/os-release? В стандарте есть хорошее поле, которое как раз не 
> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что 
> стоит пересохранять через файлтриггер.

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


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 01.09.2021 11:34, Dmitry V. Levin wrote:
> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
> [...]
>> Да, стандарт допускает введение собственных параметров. Но зачем эти
>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
>> стоит пересохранять через файлтриггер.
> Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
> указан далеко не везде.
>
Это можно добавить с обновлением пакета.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
> On 01.09.2021 11:34, Dmitry V. Levin wrote:
> > On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
> > [...]
> >> Да, стандарт допускает введение собственных параметров. Но зачем эти
> >> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
> >> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
> >> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
> >> стоит пересохранять через файлтриггер.
> > Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
> > случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
> > указан далеко не везде.
> >
> Это можно добавить с обновлением пакета.

Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID добавить,
если пакет уже установлен без информации о BUILD_ID?


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 01.09.2021 12:47, Dmitry V. Levin wrote:
> On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
>> On 01.09.2021 11:34, Dmitry V. Levin wrote:
>>> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
>>> [...]
>>>> Да, стандарт допускает введение собственных параметров. Но зачем эти
>>>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>>>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>>>> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
>>>> стоит пересохранять через файлтриггер.
>>> Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
>>> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
>>> указан далеко не везде.
>>>
>> Это можно добавить с обновлением пакета.
> Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID добавить,
> если пакет уже установлен без информации о BUILD_ID?
>
>
Т.к. у нас сейчас os-release не меняется с обновлением, то наполнение 
BUILD_ID можно взять при первом же обновлении пакета с переездом на 
новую схему.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Wed, Sep 01, 2021 at 02:12:33PM +0300, Anton Farygin wrote:
> On 01.09.2021 12:47, Dmitry V. Levin wrote:
> > On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
> >> On 01.09.2021 11:34, Dmitry V. Levin wrote:
> >>> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
> >>> [...]
> >>>> Да, стандарт допускает введение собственных параметров. Но зачем эти
> >>>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
> >>>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
> >>>> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
> >>>> стоит пересохранять через файлтриггер.
> >>> Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
> >>> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
> >>> указан далеко не везде.
> >>>
> >> Это можно добавить с обновлением пакета.
> > Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID добавить,
> > если пакет уже установлен без информации о BUILD_ID?
> >
> Т.к. у нас сейчас os-release не меняется с обновлением, то наполнение 
> BUILD_ID можно взять при первом же обновлении пакета с переездом на 
> новую схему.

Тогда, если в старом пакете BUILD_ID нет, то в качестве BUILD_ID будет
взято значение из нового пакета, а это не совсем то, к чему мы стремились.
Леонид предложил в таком случае брать значение VERSION_ID из старого
пакета в качестве BUILD_ID.


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 01.09.2021 14:25, Dmitry V. Levin wrote:
> On Wed, Sep 01, 2021 at 02:12:33PM +0300, Anton Farygin wrote:
>> On 01.09.2021 12:47, Dmitry V. Levin wrote:
>>> On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
>>>> On 01.09.2021 11:34, Dmitry V. Levin wrote:
>>>>> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
>>>>> [...]
>>>>>> Да, стандарт допускает введение собственных параметров. Но зачем эти
>>>>>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>>>>>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>>>>>> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
>>>>>> стоит пересохранять через файлтриггер.
>>>>> Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
>>>>> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
>>>>> указан далеко не везде.
>>>>>
>>>> Это можно добавить с обновлением пакета.
>>> Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID добавить,
>>> если пакет уже установлен без информации о BUILD_ID?
>>>
>> Т.к. у нас сейчас os-release не меняется с обновлением, то наполнение
>> BUILD_ID можно взять при первом же обновлении пакета с переездом на
>> новую схему.
> Тогда, если в старом пакете BUILD_ID нет, то в качестве BUILD_ID будет
> взято значение из нового пакета, а это не совсем то, к чему мы стремились.
> Леонид предложил в таком случае брать значение VERSION_ID из старого
> пакета в качестве BUILD_ID.
>
Так конечно не из нового пакета - данные для BUILD_ID брать однократно 
из старого.

Re: [devel-distro] branding

[Leonid Krivoshein]

01.09.2021 14:56, Anton Farygin пишет:
> On 01.09.2021 14:25, Dmitry V. Levin wrote:
>> On Wed, Sep 01, 2021 at 02:12:33PM +0300, Anton Farygin wrote:
>>> On 01.09.2021 12:47, Dmitry V. Levin wrote:
>>>> On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
>>>>> On 01.09.2021 11:34, Dmitry V. Levin wrote:
>>>>>> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
>>>>>> [...]
>>>>>>> Да, стандарт допускает введение собственных параметров. Но зачем 
>>>>>>> эти
>>>>>>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>>>>>>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>>>>>>> должно меняться при обновлении -- BUILD_ID, это больше похоже на 
>>>>>>> то, что
>>>>>>> стоит пересохранять через файлтриггер.
>>>>>> Мы можем хранить не всё, а только то, что нужно, но как тогда 
>>>>>> быть в тех
>>>>>> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID 
>>>>>> сейчас
>>>>>> указан далеко не везде.
>>>>>>
>>>>> Это можно добавить с обновлением пакета.
>>>> Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID 
>>>> добавить,
>>>> если пакет уже установлен без информации о BUILD_ID?
>>>>
>>> Т.к. у нас сейчас os-release не меняется с обновлением, то наполнение
>>> BUILD_ID можно взять при первом же обновлении пакета с переездом на
>>> новую схему.
>> Тогда, если в старом пакете BUILD_ID нет, то в качестве BUILD_ID будет
>> взято значение из нового пакета, а это не совсем то, к чему мы 
>> стремились.
>> Леонид предложил в таком случае брать значение VERSION_ID из старого
>> пакета в качестве BUILD_ID.
>>
> Так конечно не из нового пакета - данные для BUILD_ID брать однократно 
> из старого.

Наоборот, из старого всегда брать BUILD_ID, если он там есть.
А если его нет, тогда однократно брать его значение из VERSION_ID.
Но не из самого /etc/os-release, а того, что лежит в /usr/share



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

01.09.2021 15:33, Leonid Krivoshein пишет:
> Наоборот, из старого всегда брать BUILD_ID, если он там есть.
> А если его нет, тогда однократно брать его значение из VERSION_ID.
> Но не из самого /etc/os-release, а того, что лежит в /usr/share

Тогда получается, что BUILD_ID может находиться в одном из трёх состояний:

1. Как сейчас (пусто) -- старая система, на новый rpm ещё не перешли.
2. Значение, которое задано при выпуске устанавливаемого дистрибутива. 
Оно не меняется с обновлением пакета. Это то, к чему мы стремились. 
Теперь по BUILD_ID можно узнать, что ставилось изначально, а не что сейчас.
3. Значение, которое было получено при переходе на новую схему. Не было 
BUILD_ID, оно получено из VERSION_ID. А что в VERSION_ID? Тут два варианта:
3.1. Если VERSION_ID берётся из /usr/share, в нём то, что на момент 
перехода на новую схему.
3.2. Если брать VERSION_ID из /etc/os-release, в нём может быть то, что 
устанавливалось изначально, а может уже и не быть, если пользователь 
руками поменял брэндинг.

Тогда лучше всё-таки брать однократно VERSION_ID из /etc/os-release, 
потому что больше шансов захватить версию, стоявшую изначально.



-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Wed, Sep 01, 2021 at 03:46:43PM +0300, Leonid Krivoshein wrote:
> 
> 01.09.2021 15:33, Leonid Krivoshein пишет:
> > Наоборот, из старого всегда брать BUILD_ID, если он там есть.
> > А если его нет, тогда однократно брать его значение из VERSION_ID.
> > Но не из самого /etc/os-release, а того, что лежит в /usr/share
> 
> Тогда получается, что BUILD_ID может находиться в одном из трёх состояний:
> 
> 1. Как сейчас (пусто) -- старая система, на новый rpm ещё не перешли.
> 2. Значение, которое задано при выпуске устанавливаемого дистрибутива. 
> Оно не меняется с обновлением пакета. Это то, к чему мы стремились. 
> Теперь по BUILD_ID можно узнать, что ставилось изначально, а не что сейчас.
> 3. Значение, которое было получено при переходе на новую схему. Не было 
> BUILD_ID, оно получено из VERSION_ID. А что в VERSION_ID? Тут два варианта:
> 3.1. Если VERSION_ID берётся из /usr/share, в нём то, что на момент 
> перехода на новую схему.
> 3.2. Если брать VERSION_ID из /etc/os-release, в нём может быть то, что 
> устанавливалось изначально, а может уже и не быть, если пользователь 
> руками поменял брэндинг.
> 
> Тогда лучше всё-таки брать однократно VERSION_ID из /etc/os-release, 
> потому что больше шансов захватить версию, стоявшую изначально.

Конечно.


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 01.09.2021 15:33, Leonid Krivoshein wrote:
>
>
> 01.09.2021 14:56, Anton Farygin пишет:
>> On 01.09.2021 14:25, Dmitry V. Levin wrote:
>>> On Wed, Sep 01, 2021 at 02:12:33PM +0300, Anton Farygin wrote:
>>>> On 01.09.2021 12:47, Dmitry V. Levin wrote:
>>>>> On Wed, Sep 01, 2021 at 12:37:29PM +0300, Anton Farygin wrote:
>>>>>> On 01.09.2021 11:34, Dmitry V. Levin wrote:
>>>>>>> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
>>>>>>> [...]
>>>>>>>> Да, стандарт допускает введение собственных параметров. Но 
>>>>>>>> зачем эти
>>>>>>>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>>>>>>>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>>>>>>>> должно меняться при обновлении -- BUILD_ID, это больше похоже 
>>>>>>>> на то, что
>>>>>>>> стоит пересохранять через файлтриггер.
>>>>>>> Мы можем хранить не всё, а только то, что нужно, но как тогда 
>>>>>>> быть в тех
>>>>>>> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID 
>>>>>>> сейчас
>>>>>>> указан далеко не везде.
>>>>>>>
>>>>>> Это можно добавить с обновлением пакета.
>>>>> Можно, конечно, но есть одна небольшая сложность: какой BUILD_ID 
>>>>> добавить,
>>>>> если пакет уже установлен без информации о BUILD_ID?
>>>>>
>>>> Т.к. у нас сейчас os-release не меняется с обновлением, то наполнение
>>>> BUILD_ID можно взять при первом же обновлении пакета с переездом на
>>>> новую схему.
>>> Тогда, если в старом пакете BUILD_ID нет, то в качестве BUILD_ID будет
>>> взято значение из нового пакета, а это не совсем то, к чему мы 
>>> стремились.
>>> Леонид предложил в таком случае брать значение VERSION_ID из старого
>>> пакета в качестве BUILD_ID.
>>>
>> Так конечно не из нового пакета - данные для BUILD_ID брать 
>> однократно из старого.
>
> Наоборот, из старого всегда брать BUILD_ID, если он там есть.
> А если его нет, тогда однократно брать его значение из VERSION_ID.
> Но не из самого /etc/os-release, а того, что лежит в /usr/share

зачем из /usr/share ? прямо из /etc/os-release.

С BUILD_ID всё понятно, непонятно когда и как обновлять остальные поля.

Re: [devel-distro] branding

[Leonid Krivoshein]

01.09.2021 17:41, Anton Farygin пишет:
> On 01.09.2021 15:33, Leonid Krivoshein wrote:
>> [...]
>> Наоборот, из старого всегда брать BUILD_ID, если он там есть.
>> А если его нет, тогда однократно брать его значение из VERSION_ID.
>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>
> зачем из /usr/share ? прямо из /etc/os-release.
>

Да, так лучше.


> С BUILD_ID всё понятно, непонятно когда и как обновлять остальные поля.
>

А какие поля нужно ещё СОХРАНЯТЬ? Обновлять нужно все остальные поля.

Например, имеет ли смысл сохранять какой-то VERSION_CODENAME того, что 
было установлено? Ведь по VERSION_ID или BUILD_ID остальное определяется 
однозначно. У нас же меняется только версия. Да и кто будет даже этот 
BUIL_ID анализировать? Но парсить его в любом случае проще и тогда такая 
схема получается проще, чем сохранять и парсить все поля с префиксом alt_*.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Sergey V Turchin]

01.09.2021 15:33, Leonid Krivoshein пишет:

[...]
> Но не из самого /etc/os-release, а того, что лежит в /usr/share
Не /usr/share, а из /usr/lib/os-release.
https://www.freedesktop.org/software/systemd/man/os-release.html

Re: [devel-distro] branding

[Leonid Krivoshein]

01.09.2021 18:01, Sergey V Turchin пишет:
> 01.09.2021 15:33, Leonid Krivoshein пишет:
>
> [...]
>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
> Не /usr/share, а из /usr/lib/os-release.
> https://www.freedesktop.org/software/systemd/man/os-release.html

Не, это о другом. Я имел ввиду наше внутреннее:
/usr/share/branding-data-current/release/os-release


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Sergey V Turchin]

01.09.2021 20:08, Leonid Krivoshein пишет:
> 
> 01.09.2021 18:01, Sergey V Turchin пишет:
>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>
>> [...]
>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>> Не /usr/share, а из /usr/lib/os-release.
>> https://www.freedesktop.org/software/systemd/man/os-release.html
> 
> Не, это о другом. Я имел ввиду наше внутреннее:
> /usr/share/branding-data-current/release/os-release
Так, разговор и о том, чтоб без велосипедов.

Re: [devel-distro] branding

[Leonid Krivoshein]

02.09.2021 11:26, Sergey V Turchin пишет:
> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>
>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>
>>> [...]
>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>> Не /usr/share, а из /usr/lib/os-release.
>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>
>> Не, это о другом. Я имел ввиду наше внутреннее:
>> /usr/share/branding-data-current/release/os-release
> Так, разговор и о том, чтоб без велосипедов.
>

Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если 
его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность, 
второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто 
хочет сориентироваться в текущем окружении, типа ansible.

То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный 
неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release 
сейчас копируется информация в пост-установочном скрипте, сам 
/etc/os-release сейчас является файлом конфигурации, и он не меняется с 
обновлением пакета брэндинга.

Предлагается в rpm сделать файл-триггер, который будет генерировать 
содержимое /etc/os-release, полностью соответствующее стандарту. В новом 
варианте здесь будут данные, соответствующие текущей ситуации, а не той, 
что была. Но обсуждается вариант сохранения информации, соответствующие 
исходному состоянию системы. Рассмотрены два варианта:

- Сохранять все поля, добавляя к ним альтовый префикс, что допускается 
стандартом.
- Сохранять только поле BUILD_ID, а в его отсутствии брать значение из 
VERSION_ID (в /etc/os-release).

Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release, 
остальные поля перезаписывать из 
/usr/share/branding-data-current/release/os-release. При даунгрейде 
пакета брэндинга схема будет в точности такой же.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
> 
> 
> 02.09.2021 11:26, Sergey V Turchin пишет:
> > 01.09.2021 20:08, Leonid Krivoshein пишет:
> >>
> >> 01.09.2021 18:01, Sergey V Turchin пишет:
> >>> 01.09.2021 15:33, Leonid Krivoshein пишет:
> >>>
> >>> [...]
> >>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
> >>> Не /usr/share, а из /usr/lib/os-release.
> >>> https://www.freedesktop.org/software/systemd/man/os-release.html
> >>
> >> Не, это о другом. Я имел ввиду наше внутреннее:
> >> /usr/share/branding-data-current/release/os-release
> > Так, разговор и о том, чтоб без велосипедов.
> >
> 
> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если 
> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность, 
> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто 
> хочет сориентироваться в текущем окружении, типа ansible.
> 
> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный 
> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release 
> сейчас копируется информация в пост-установочном скрипте, сам 
> /etc/os-release сейчас является файлом конфигурации, и он не меняется с 
> обновлением пакета брэндинга.
> 
> Предлагается в rpm сделать файл-триггер, который будет генерировать 
> содержимое /etc/os-release, полностью соответствующее стандарту. В новом 
> варианте здесь будут данные, соответствующие текущей ситуации, а не той, 
> что была. Но обсуждается вариант сохранения информации, соответствующие 
> исходному состоянию системы. Рассмотрены два варианта:
> 
> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается 
> стандартом.
> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из 
> VERSION_ID (в /etc/os-release).
> 
> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release, 
> остальные поля перезаписывать из 
> /usr/share/branding-data-current/release/os-release. При даунгрейде 
> пакета брэндинга схема будет в точности такой же.

Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
смотреть не напрямую в
/usr/share/branding-data-current/release/os-release, а в
/usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
на тот же /usr/share/branding-data-current/release/os-release.


-- 
ldv

Re: [devel-distro] branding

[Leonid Krivoshein]

02.09.2021 20:09, Dmitry V. Levin пишет:
> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
>>
>> 02.09.2021 11:26, Sergey V Turchin пишет:
>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>>>
>>>>> [...]
>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>>>> Не /usr/share, а из /usr/lib/os-release.
>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>>> Не, это о другом. Я имел ввиду наше внутреннее:
>>>> /usr/share/branding-data-current/release/os-release
>>> Так, разговор и о том, чтоб без велосипедов.
>>>
>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>> хочет сориентироваться в текущем окружении, типа ansible.
>>
>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>> сейчас копируется информация в пост-установочном скрипте, сам
>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>> обновлением пакета брэндинга.
>>
>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>> что была. Но обсуждается вариант сохранения информации, соответствующие
>> исходному состоянию системы. Рассмотрены два варианта:
>>
>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>> стандартом.
>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>> VERSION_ID (в /etc/os-release).
>>
>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>> остальные поля перезаписывать из
>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>> пакета брэндинга схема будет в точности такой же.
> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
> смотреть не напрямую в
> /usr/share/branding-data-current/release/os-release, а в
> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
> на тот же /usr/share/branding-data-current/release/os-release.

Интересная деталь, поскольку один раз мне удалось получить ситуацию 
остаться без /etc/os-release до apt-get dist-upgrade. В этот момент 
устанавливаемые пакеты, если используют информацию о версии ОС, должны 
смотреть в /usr/lib/os-release. В общем случае не будет большой разницы 
между одной сущностью и другой. Ну, разве что в полях, которые должны 
сохраняться, т.е. об исходной системе. Если уже удалён /etc/os-release, 
то вообще нет разницы.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 02.09.2021 20:09, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
>>
>> 02.09.2021 11:26, Sergey V Turchin пишет:
>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>>>
>>>>> [...]
>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>>>> Не /usr/share, а из /usr/lib/os-release.
>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>>> Не, это о другом. Я имел ввиду наше внутреннее:
>>>> /usr/share/branding-data-current/release/os-release
>>> Так, разговор и о том, чтоб без велосипедов.
>>>
>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>> хочет сориентироваться в текущем окружении, типа ansible.
>>
>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>> сейчас копируется информация в пост-установочном скрипте, сам
>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>> обновлением пакета брэндинга.
>>
>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>> что была. Но обсуждается вариант сохранения информации, соответствующие
>> исходному состоянию системы. Рассмотрены два варианта:
>>
>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>> стандартом.
>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>> VERSION_ID (в /etc/os-release).
>>
>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>> остальные поля перезаписывать из
>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>> пакета брэндинга схема будет в точности такой же.
> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
> смотреть не напрямую в
> /usr/share/branding-data-current/release/os-release, а в
> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
> на тот же /usr/share/branding-data-current/release/os-release.
>
>
Во время работы файлтриггера в этом месте данные будут уже обновлены.

А вот в /etc/os-release они всё ещё остануться старые.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
> On 02.09.2021 20:09, Dmitry V. Levin wrote:
> > On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
> >>
> >> 02.09.2021 11:26, Sergey V Turchin пишет:
> >>> 01.09.2021 20:08, Leonid Krivoshein пишет:
> >>>> 01.09.2021 18:01, Sergey V Turchin пишет:
> >>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
> >>>>>
> >>>>> [...]
> >>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
> >>>>> Не /usr/share, а из /usr/lib/os-release.
> >>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
> >>>> Не, это о другом. Я имел ввиду наше внутреннее:
> >>>> /usr/share/branding-data-current/release/os-release
> >>> Так, разговор и о том, чтоб без велосипедов.
> >>>
> >> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
> >> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
> >> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
> >> хочет сориентироваться в текущем окружении, типа ansible.
> >>
> >> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
> >> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
> >> сейчас копируется информация в пост-установочном скрипте, сам
> >> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
> >> обновлением пакета брэндинга.
> >>
> >> Предлагается в rpm сделать файл-триггер, который будет генерировать
> >> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
> >> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
> >> что была. Но обсуждается вариант сохранения информации, соответствующие
> >> исходному состоянию системы. Рассмотрены два варианта:
> >>
> >> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
> >> стандартом.
> >> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
> >> VERSION_ID (в /etc/os-release).
> >>
> >> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
> >> остальные поля перезаписывать из
> >> /usr/share/branding-data-current/release/os-release. При даунгрейде
> >> пакета брэндинга схема будет в точности такой же.
> > Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
> > смотреть не напрямую в
> > /usr/share/branding-data-current/release/os-release, а в
> > /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
> > на тот же /usr/share/branding-data-current/release/os-release.
> >
> Во время работы файлтриггера в этом месте данные будут уже обновлены.
> 
> А вот в /etc/os-release они всё ещё остануться старые.

Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
когда отработает файлтриггер, обновляющий /etc/os-release?


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 02.09.2021 21:15, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
>> On 02.09.2021 20:09, Dmitry V. Levin wrote:
>>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
>>>> 02.09.2021 11:26, Sergey V Turchin пишет:
>>>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>>>>>
>>>>>>> [...]
>>>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>>>>>> Не /usr/share, а из /usr/lib/os-release.
>>>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>>>>> Не, это о другом. Я имел ввиду наше внутреннее:
>>>>>> /usr/share/branding-data-current/release/os-release
>>>>> Так, разговор и о том, чтоб без велосипедов.
>>>>>
>>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>>>> хочет сориентироваться в текущем окружении, типа ansible.
>>>>
>>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>>>> сейчас копируется информация в пост-установочном скрипте, сам
>>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>>>> обновлением пакета брэндинга.
>>>>
>>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>>>> что была. Но обсуждается вариант сохранения информации, соответствующие
>>>> исходному состоянию системы. Рассмотрены два варианта:
>>>>
>>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>>>> стандартом.
>>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>>>> VERSION_ID (в /etc/os-release).
>>>>
>>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>>>> остальные поля перезаписывать из
>>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>>>> пакета брэндинга схема будет в точности такой же.
>>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
>>> смотреть не напрямую в
>>> /usr/share/branding-data-current/release/os-release, а в
>>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
>>> на тот же /usr/share/branding-data-current/release/os-release.
>>>
>> Во время работы файлтриггера в этом месте данные будут уже обновлены.
>>
>> А вот в /etc/os-release они всё ещё остануться старые.
> Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
> когда отработает файлтриггер, обновляющий /etc/os-release?

нет,  /usr/lib/os-release обновляется из пакета. во время работы 
файлтриггера пакет будет установлен уже новый, в котором эти данные 
могут быть изменены.

Надо брать данные для os-release из старого пакета, до обновления.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Thu, Sep 02, 2021 at 09:17:11PM +0300, Anton Farygin wrote:
> On 02.09.2021 21:15, Dmitry V. Levin wrote:
> > On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
> >> On 02.09.2021 20:09, Dmitry V. Levin wrote:
> >>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
> >>>> 02.09.2021 11:26, Sergey V Turchin пишет:
> >>>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
> >>>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
> >>>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
> >>>>>>>
> >>>>>>> [...]
> >>>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
> >>>>>>> Не /usr/share, а из /usr/lib/os-release.
> >>>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
> >>>>>> Не, это о другом. Я имел ввиду наше внутреннее:
> >>>>>> /usr/share/branding-data-current/release/os-release
> >>>>> Так, разговор и о том, чтоб без велосипедов.
> >>>>>
> >>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
> >>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
> >>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
> >>>> хочет сориентироваться в текущем окружении, типа ansible.
> >>>>
> >>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
> >>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
> >>>> сейчас копируется информация в пост-установочном скрипте, сам
> >>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
> >>>> обновлением пакета брэндинга.
> >>>>
> >>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
> >>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
> >>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
> >>>> что была. Но обсуждается вариант сохранения информации, соответствующие
> >>>> исходному состоянию системы. Рассмотрены два варианта:
> >>>>
> >>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
> >>>> стандартом.
> >>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
> >>>> VERSION_ID (в /etc/os-release).
> >>>>
> >>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
> >>>> остальные поля перезаписывать из
> >>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
> >>>> пакета брэндинга схема будет в точности такой же.
> >>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
> >>> смотреть не напрямую в
> >>> /usr/share/branding-data-current/release/os-release, а в
> >>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
> >>> на тот же /usr/share/branding-data-current/release/os-release.
> >>>
> >> Во время работы файлтриггера в этом месте данные будут уже обновлены.
> >>
> >> А вот в /etc/os-release они всё ещё остануться старые.
> > Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
> > когда отработает файлтриггер, обновляющий /etc/os-release?
> 
> нет,  /usr/lib/os-release обновляется из пакета. во время работы 
> файлтриггера пакет будет установлен уже новый, в котором эти данные 
> могут быть изменены.
> 
> Надо брать данные для os-release из старого пакета, до обновления.

Разве в /etc/os-release уже не находятся старые данные, которые как раз
и надо обновить из /usr/lib/os-release после обновления последнего?


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 02.09.2021 21:20, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 09:17:11PM +0300, Anton Farygin wrote:
>> On 02.09.2021 21:15, Dmitry V. Levin wrote:
>>> On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
>>>> On 02.09.2021 20:09, Dmitry V. Levin wrote:
>>>>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
>>>>>> 02.09.2021 11:26, Sergey V Turchin пишет:
>>>>>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>>>>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>>>>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>>>>>>>> Не /usr/share, а из /usr/lib/os-release.
>>>>>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>>>>>>> Не, это о другом. Я имел ввиду наше внутреннее:
>>>>>>>> /usr/share/branding-data-current/release/os-release
>>>>>>> Так, разговор и о том, чтоб без велосипедов.
>>>>>>>
>>>>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>>>>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>>>>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>>>>>> хочет сориентироваться в текущем окружении, типа ansible.
>>>>>>
>>>>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>>>>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>>>>>> сейчас копируется информация в пост-установочном скрипте, сам
>>>>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>>>>>> обновлением пакета брэндинга.
>>>>>>
>>>>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>>>>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>>>>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>>>>>> что была. Но обсуждается вариант сохранения информации, соответствующие
>>>>>> исходному состоянию системы. Рассмотрены два варианта:
>>>>>>
>>>>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>>>>>> стандартом.
>>>>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>>>>>> VERSION_ID (в /etc/os-release).
>>>>>>
>>>>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>>>>>> остальные поля перезаписывать из
>>>>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>>>>>> пакета брэндинга схема будет в точности такой же.
>>>>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
>>>>> смотреть не напрямую в
>>>>> /usr/share/branding-data-current/release/os-release, а в
>>>>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
>>>>> на тот же /usr/share/branding-data-current/release/os-release.
>>>>>
>>>> Во время работы файлтриггера в этом месте данные будут уже обновлены.
>>>>
>>>> А вот в /etc/os-release они всё ещё остануться старые.
>>> Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
>>> когда отработает файлтриггер, обновляющий /etc/os-release?
>> нет,  /usr/lib/os-release обновляется из пакета. во время работы
>> файлтриггера пакет будет установлен уже новый, в котором эти данные
>> могут быть изменены.
>>
>> Надо брать данные для os-release из старого пакета, до обновления.
> Разве в /etc/os-release уже не находятся старые данные, которые как раз
> и надо обновить из /usr/lib/os-release после обновления последнего?

Мы говорим о разных файлтриггерах. Если нам нужно первый раз получить 
BUILD_ID, то в /usr/lib/os-release он будет уже новый, а в 
/etc/os-release - старый (который нам как раз и нужен)

Если мы говорим про обновление остальных данных, то да, файлтриггер 
должен конечно должен брать их уже из /usr/lib/os-release

Re: [devel-distro] branding

[Dmitry V. Levin]

On Thu, Sep 02, 2021 at 09:23:26PM +0300, Anton Farygin wrote:
> On 02.09.2021 21:20, Dmitry V. Levin wrote:
> > On Thu, Sep 02, 2021 at 09:17:11PM +0300, Anton Farygin wrote:
> >> On 02.09.2021 21:15, Dmitry V. Levin wrote:
> >>> On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
> >>>> On 02.09.2021 20:09, Dmitry V. Levin wrote:
> >>>>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
[...]
> >>>>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
> >>>>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
> >>>>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
> >>>>>> хочет сориентироваться в текущем окружении, типа ansible.
> >>>>>>
> >>>>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
> >>>>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
> >>>>>> сейчас копируется информация в пост-установочном скрипте, сам
> >>>>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
> >>>>>> обновлением пакета брэндинга.
> >>>>>>
> >>>>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
> >>>>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
> >>>>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
> >>>>>> что была. Но обсуждается вариант сохранения информации, соответствующие
> >>>>>> исходному состоянию системы. Рассмотрены два варианта:
> >>>>>>
> >>>>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
> >>>>>> стандартом.
> >>>>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
> >>>>>> VERSION_ID (в /etc/os-release).
> >>>>>>
> >>>>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
> >>>>>> остальные поля перезаписывать из
> >>>>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
> >>>>>> пакета брэндинга схема будет в точности такой же.
> >>>>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
> >>>>> смотреть не напрямую в
> >>>>> /usr/share/branding-data-current/release/os-release, а в
> >>>>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
> >>>>> на тот же /usr/share/branding-data-current/release/os-release.
> >>>>>
> >>>> Во время работы файлтриггера в этом месте данные будут уже обновлены.
> >>>>
> >>>> А вот в /etc/os-release они всё ещё остануться старые.
> >>> Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
> >>> когда отработает файлтриггер, обновляющий /etc/os-release?
> >> нет,  /usr/lib/os-release обновляется из пакета. во время работы
> >> файлтриггера пакет будет установлен уже новый, в котором эти данные
> >> могут быть изменены.
> >>
> >> Надо брать данные для os-release из старого пакета, до обновления.
> > Разве в /etc/os-release уже не находятся старые данные, которые как раз
> > и надо обновить из /usr/lib/os-release после обновления последнего?
> 
> Мы говорим о разных файлтриггерах. Если нам нужно первый раз получить 
> BUILD_ID, то в /usr/lib/os-release он будет уже новый, а в 
> /etc/os-release - старый (который нам как раз и нужен)
> 
> Если мы говорим про обновление остальных данных, то да, файлтриггер 
> должен конечно должен брать их уже из /usr/lib/os-release

Мне кажется, что это один и тот же файлтриггер, который оставляет BUILD_ID
в /etc/os-release старым (а если там нет BUILD_ID, то клонирует VERSION_ID
в BUILD_ID), а всё остальное копирует из /usr/lib/os-release.

Остаётся вопрос, что делать с теми полями, которые есть в /etc/os-release,
но нет в /usr/lib/os-release - оставлять или удалять?


-- 
ldv

Re: [devel-distro] branding

[Anton Farygin]

On 02.09.2021 21:33, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 09:23:26PM +0300, Anton Farygin wrote:
>> On 02.09.2021 21:20, Dmitry V. Levin wrote:
>>> On Thu, Sep 02, 2021 at 09:17:11PM +0300, Anton Farygin wrote:
>>>> On 02.09.2021 21:15, Dmitry V. Levin wrote:
>>>>> On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
>>>>>> On 02.09.2021 20:09, Dmitry V. Levin wrote:
>>>>>>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
> [...]
>>>>>>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>>>>>>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>>>>>>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>>>>>>>> хочет сориентироваться в текущем окружении, типа ansible.
>>>>>>>>
>>>>>>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>>>>>>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>>>>>>>> сейчас копируется информация в пост-установочном скрипте, сам
>>>>>>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>>>>>>>> обновлением пакета брэндинга.
>>>>>>>>
>>>>>>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>>>>>>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>>>>>>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>>>>>>>> что была. Но обсуждается вариант сохранения информации, соответствующие
>>>>>>>> исходному состоянию системы. Рассмотрены два варианта:
>>>>>>>>
>>>>>>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>>>>>>>> стандартом.
>>>>>>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>>>>>>>> VERSION_ID (в /etc/os-release).
>>>>>>>>
>>>>>>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>>>>>>>> остальные поля перезаписывать из
>>>>>>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>>>>>>>> пакета брэндинга схема будет в точности такой же.
>>>>>>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
>>>>>>> смотреть не напрямую в
>>>>>>> /usr/share/branding-data-current/release/os-release, а в
>>>>>>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
>>>>>>> на тот же /usr/share/branding-data-current/release/os-release.
>>>>>>>
>>>>>> Во время работы файлтриггера в этом месте данные будут уже обновлены.
>>>>>>
>>>>>> А вот в /etc/os-release они всё ещё остануться старые.
>>>>> Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
>>>>> когда отработает файлтриггер, обновляющий /etc/os-release?
>>>> нет,  /usr/lib/os-release обновляется из пакета. во время работы
>>>> файлтриггера пакет будет установлен уже новый, в котором эти данные
>>>> могут быть изменены.
>>>>
>>>> Надо брать данные для os-release из старого пакета, до обновления.
>>> Разве в /etc/os-release уже не находятся старые данные, которые как раз
>>> и надо обновить из /usr/lib/os-release после обновления последнего?
>> Мы говорим о разных файлтриггерах. Если нам нужно первый раз получить
>> BUILD_ID, то в /usr/lib/os-release он будет уже новый, а в
>> /etc/os-release - старый (который нам как раз и нужен)
>>
>> Если мы говорим про обновление остальных данных, то да, файлтриггер
>> должен конечно должен брать их уже из /usr/lib/os-release
> Мне кажется, что это один и тот же файлтриггер, который оставляет BUILD_ID
> в /etc/os-release старым (а если там нет BUILD_ID, то клонирует VERSION_ID
> в BUILD_ID), а всё остальное копирует из /usr/lib/os-release.
>
> Остаётся вопрос, что делать с теми полями, которые есть в /etc/os-release,
> но нет в /usr/lib/os-release - оставлять или удалять?
>


Я предлагаю оставлять, тем самым дав возможность тем, кто выпускает 
дистрибутивы дополнить /etc/os-release какими-то нужными им данными, не 
предполагающими обновления.

Re: [devel-distro] branding

[Leonid Krivoshein]

02.09.2021 21:35, Anton Farygin пишет:
> On 02.09.2021 21:33, Dmitry V. Levin wrote:
>> [...]
>> Остаётся вопрос, что делать с теми полями, которые есть в 
>> /etc/os-release,
>> но нет в /usr/lib/os-release - оставлять или удалять?
>>
>
> Я предлагаю оставлять, тем самым дав возможность тем, кто выпускает 
> дистрибутивы дополнить /etc/os-release какими-то нужными им данными, 
> не предполагающими обновления.
>

Для данных, предназначенных для сохранения, типа BUILD_ID в 
файл-триггере программируется особое поведение. А в случае "всех 
остальных полей" его уже нельзя реализовать так же чётко. Потому как а 
что будет в тех случаях, когда в следующих версиях os-release эти данные 
будут приезжать с новыми значениями? Получается неустойчивое состояние 
таких полей -- в одном случае они будут сохраняться, ну а если их новые 
версии появились -- перезаписываться. Как на такое можно полагаться? 
Опять же, если оставлять и игнорировать новые значения, то никогда не 
исправишь ошибку в этих данных. Мне кажется, лучше удалять. Потому что 
маинтейнер новой версии пакета как бы сам понимает, что и зачем он 
удалил/изменил или добавил, всё это должно попасть в новый 
/etc/os-release + BUILD_ID от исходной системы.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

02.09.2021 21:35, Anton Farygin пишет:
>> Остаётся вопрос, что делать с теми полями, которые есть в 
>> /etc/os-release,
>> но нет в /usr/lib/os-release - оставлять или удалять?
>>
>
> Я предлагаю оставлять, тем самым дав возможность тем, кто выпускает 
> дистрибутивы дополнить /etc/os-release какими-то нужными им данными, 
> не предполагающими обновления. 

Можно использовать префикс alt_* для всех остальных полей, которые всё 
же должны сохраняться от исходной системы.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Anton Farygin]

On 02.09.2021 23:43, Leonid Krivoshein wrote:
>
> 02.09.2021 21:35, Anton Farygin пишет:
>>> Остаётся вопрос, что делать с теми полями, которые есть в 
>>> /etc/os-release,
>>> но нет в /usr/lib/os-release - оставлять или удалять?
>>>
>>
>> Я предлагаю оставлять, тем самым дав возможность тем, кто выпускает 
>> дистрибутивы дополнить /etc/os-release какими-то нужными им данными, 
>> не предполагающими обновления. 
>
> Можно использовать префикс alt_* для всех остальных полей, которые всё 
> же должны сохраняться от исходной системы.
>
>
Конечно, именно его и использовать.

Re: [devel-distro] branding

[Leonid Krivoshein]

Ещё немного подумав...


02.09.2021 21:33, Dmitry V. Levin пишет:
> [...]
> Остаётся вопрос, что делать с теми полями, которые есть в /etc/os-release,
> но нет в /usr/lib/os-release - оставлять или удалять?

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

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

Можно ещё захардкодить в файл-триггер все поля, которые должны 
сохраняться, в том числе, с префиксами.

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


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Leonid Krivoshein]

01.09.2021 11:34, Dmitry V. Levin пишет:
> On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
> [...]
>> Да, стандарт допускает введение собственных параметров. Но зачем эти
>> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
>> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
>> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
>> стоит пересохранять через файлтриггер.
> Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
> случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
> указан далеко не везде.

Для BUILD_ID можно использовать VERSION_ID в случае, если BUILD_ID нет, 
как сейчас.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Wed, Sep 01, 2021 at 12:54:59PM +0300, Leonid Krivoshein wrote:
> 
> 01.09.2021 11:34, Dmitry V. Levin пишет:
> > On Sat, Aug 21, 2021 at 04:13:34AM +0300, Leonid Krivoshein wrote:
> > [...]
> >> Да, стандарт допускает введение собственных параметров. Но зачем эти
> >> параметры нам? Нужно ли нам хранить всё, что ранее было записано в
> >> /etc/os-release? В стандарте есть хорошее поле, которое как раз не
> >> должно меняться при обновлении -- BUILD_ID, это больше похоже на то, что
> >> стоит пересохранять через файлтриггер.
> > Мы можем хранить не всё, а только то, что нужно, но как тогда быть в тех
> > случаях, когда того, что нужно, нет?  Например, тот же BUILD_ID сейчас
> > указан далеко не везде.
> 
> Для BUILD_ID можно использовать VERSION_ID в случае, если BUILD_ID нет, 
> как сейчас.

Допустим.  Какое в таком случае получается правило обновления /etc/os-release?


-- 
ldv

Re: [devel-distro] branding

[Leonid Krivoshein]

05.08.2021 21:11, Aleksey Novodvorsky пишет:
>
>
> чт, 5 авг. 2021 г., 20:57 Aleksey Novodvorsky <aen@basealt.ru 
> <mailto:aen@basealt.ru>>:
>
>
>
>     чт, 5 авг. 2021 г., 20:41 Alexey Shabalin <a.shabalin@gmail.com
>     <mailto:a.shabalin@gmail.com>>:
>
>         чт, 5 авг. 2021 г. в 19:49, Aleksey Novodvorsky
>         <aen@basealt.ru <mailto:aen@basealt.ru>>:
>         >
>         >
>         >
>         > чт, 5 авг. 2021 г., 19:38 Alexey Shabalin
>         <a.shabalin@gmail.com <mailto:a.shabalin@gmail.com>>:
>         >>
>         >> ср, 4 авг. 2021 г. в 18:14, Mikhail Efremov
>         <sem@altlinux.org <mailto:sem@altlinux.org>>:
>         >> >
>         >> > On Wed, 4 Aug 2021 18:51:56 +0400 Aleksey Novodvorsky wrote:
>         >> > > По сути же, мне не нравится любое изменение , не
>         согласованное со всеми
>         >> > > релиз-менеджерами.
>         >> >
>         >> > Когда я о нем писал почти никто не отреагировал:
>         >> >
>         https://lists.altlinux.org/pipermail/devel-distro/2017-March/001471.html
>         >>
>         >> Для релиз менеджера, который тестирует разные beta и rc, причем
>         >> исключительно новыми установками, это изменение возможно
>         полезное.
>         >> Но на системах, которые никакого отношения не имеют к beta,
>         установка
>         >> только из релиза и в дальнейшем многолетняя эксплуатация с
>         >> обновлениями, это изменение вредное.
>         >>
>         >> Давай попробуем не рассматривать юридические аспекты,
>         остановимся
>         >> только на технических.
>         >> При эксплуатации и  обслуживании системы, через пару-тройку
>         лет, а еще
>         >> и при апгрейде с p8 на p9, в дальнейшем на p10, абсолютно
>         все равно,
>         >> откуда уставился дистрибутив, с 8.0 или 8.1. Гораздо
>         важнее, текущее
>         >> состояние версии - 8, 9 или 10. И для этого есть
>         стандартное место -
>         >> /etc/os-release или /etc/altlinux-release.
>         >> Заглянуть в эти файлы проще, чем делать rpm -q --qf
>         "%{VERSION}"
>         >> branding-alt-workstation-release, а еще перед этим надо
>         узнать имя
>         >> пакета, workstation или какое-другое.
>         >> А дальше еще нужно переписать кучу софта, который смотрит в
>         /etc/os-release.
>         >> Вы готовы пропатчить все возможное? Начиная с
>         python3-module-distro,
>         >> platform.freedesktop_os_release() в будущем python-3.10? Кучу
>         >> остального прикладного софта?
>         >> Этот прикладной софт не знает, что было придумано в Альт в
>         2017 году.
>         >> Во всех дистрибутивах принято в /etc/os-release хранить
>         текущую версию
>         >> (ок, называйте как угодно, пусть будет версия пакета
>         branding, а не
>         >> версия дистрибутива - меня устроит любое определение). У
>         альт и так
>         >> много специфических отличий, но зачем тут создавать
>         ненужное отличие
>         >> на ровном месте?
>         >
>         >
>         > На ровном месте точно не нужно.
>         > Давайте обратимся к "мелочам".
>         > Что должно быть в os-release у обновившихся с p9 до p10 до
>         выхода 10.0?
>
>         Лучше, чтобы уже было написано "10.0". Вас это все равно ни к
>         чему не
>         обязывает - релиза еще не было и iso образов еще нет.
>
>
>     У нас именно в 10.0 будут новшества в apt, работа идёт, мы
>     говорили об этом. А бранч будет доступен для обновления раньше.
>     То есть это как раз пример того, когда номер релиза, пусть
>     условный, не дает нужной информации.
>
>
> Возможно, стоит считать начальный бранч релизом 0 ,   а продукты 
> выпускать начиная с 1.
> То есть версия -- это состояние бранча. На котором могут выпускаются 
> продукты.
>

Мне эта идея нравится.


> Rgrds, Алексей
>
>
>         И тогда:
>         - саппорт увидит что именно использует клиент;
>         - системы автоматизации и скрипты можно подготавливать и
>         адаптировать
>         для дистрибутивов на p10;
>         - видно кто непавомерно обновился.
>
>
>     Мне, честно говоря, не нравятся разговоры о неправомерном 
>     обновлении из свободного репозитория. Буду говорить с коммерческим
>     блоком
>
>     Rgrds, Алексей.
>
>
>         Пусть пакет имеет версию 9.9 или 9.98, как любит sem@, но внутри в
>         /etc/os-release уже будет 10.0.
>         Обратная логика, предлагаемая sem@.
>
>         -- 
>         Alexey Shabalin
>
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
Best regards,
Leonid Krivoshein.

[devel-distro] Сизиф -- не первая версия, а последняя (was: branding)

[Sergey V Turchin]

On Thursday, 5 August 2021 21:11:59 MSK Aleksey Novodvorsky wrote:

[...]
> Возможно, стоит считать начальный бранч релизом 0 ,   а продукты выпускать
> начиная с 1.
> То есть версия -- это состояние бранча. На котором могут выпускаются
> продукты.
Плохо, т.к. будет "непорядок", т.к. "не порядок". Сизиф должен повышать версию 
при появлении нового бранча. Например, сейчас p11. Или иметь отдельное 
именование версий, но любая из них должна быть больше любой версии любого 
бранча.

[...]

-- 
Regards, Sergey.

Re: [devel-distro] branding

[Anton V. Boyarshinov]

В Thu, 5 Aug 2021 20:41:16 +0300
Alexey Shabalin <a.shabalin@gmail.com> пишет:

> Лучше, чтобы уже было написано "10.0". Вас это все равно ни к чему не
> обязывает - релиза еще не было и iso образов еще нет.
> И тогда:
> - саппорт увидит что именно использует клиент;
> - системы автоматизации и скрипты можно подготавливать и адаптировать
> для дистрибутивов на p10;

По этим пунктам я согласен с Алексеем.

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 17:51, Aleksey Novodvorsky wrote:
>
>
>
>
> ср, 4 авг. 2021 г., 18:45 Anton Farygin <rider@basealt.ru 
> <mailto:rider@basealt.ru>>:
>
>     On 04.08.2021 17:30, Aleksey Novodvorsky wrote:
>     >
>     >
>     >     """Обсуждаемый коммит, насколько я теперь понимаю, возник
>     вследствие
>     >     неправомерного наезда.
>     >
>     >
>     > Ещё раз.
>     > Кто наехал? Где? Почему неправомерно?
>     >
>     > Почитайте Михаила.
>
>     Можно сколько угодно спорить о том, кто на кого и зачем наехал, но от
>     этого поведение данного изменения не станет правильным.
>
>
> Обсуждение не должно идти в такой форме. Я ровно об этом.
> По сути же, мне не нравится любое изменение , не согласованное со 
> всеми релиз-менеджерами.
>
Ну если я правильно понял, каждый релиз-менеджер вволю в своём брандинге 
принимать самостоятельное решение по данному изменению.

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

Re: [devel-distro] branding

[Mikhail Efremov]

On Tue, 3 Aug 2021 21:29:47 +0300 Alexey Shabalin wrote:
> День добрый.
> Есть несколько вопросов для обсуждения по поводу наших branding.
> 
> 1) /etc/altlinux-release и /etc/os-release
> После коммита, который разошелся по всем брэндингам
> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
> Как они создаются при установке, никакое обновление их больше не обновляет.
> Это нарушает ожидаемое поведение во многих скриптах и системах
> автоматизированного управления. Я могу привести примеры, если нужно,
> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
> что в них используется текущее состояние версии, а не на момент
> установки.

Я как раз считаю, что там должна быть версия дистрибутива, который
человек ставил. Потому что обновление из бранча не означает, что у
человека теперь новая версия. Обновление не делает из 9.1 9.2, и уж тем
более 10.0. Так же как установка из репозитория пакета, не входящего в
дистрибутив, не означает, что в дистрибутиве этот пакет появился.
Новая версия - это другой продукт.
Состав дистрибутивов меняется от версии к версии, к тому же они могут
сильно отличаться первоначальной настройкой системы (те же
installer-features могут добавляться, удаляться или изменяться).

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

Даже в этом случае при изменении лицензии человек должен ее прочитать и
согласиться с нею. И у нас не написано в лицензионных договорах, что они
могут меняться для уже установленных систем.
Впрочем, тут действительно нужны комментарии юриста.

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

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

> 2) Обновление оформления при обновлении
> Так же не происходит обновление bootsplash
> %post bootsplash
> [ "$1" -eq 1 ] || exit 0
> 
> Мне кажется, что пользователь должен явно увидеть обновление
> оформления своей системы при обновлении на новый бранч. Иначе зачем
> вообще обновляются пакеты с оформлением, если изменений в оформлении
> не видно. (У меня есть посылка для вашего мальчика, но я вам её не
> отдам :))

Изменение оформления тоже спорный вопрос. Если установленный
дистрибутив не меняется, то и оформление должно остаться как было.
Или что, установка branding от Server превращает Simply в сервер?
Это, кстати, и замены os-release касается.

> Даже не обязательно изменение оформления, а исправление ошибки в
> пакете не приведет ни к каким результатам.

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

> 3) Веса альтернатив в branding
> В пакетах брэндинга находятся 3 штуки альтернатив
> - /usr/share/design-current
> - /usr/share/design/current
> - /etc/alterator/design-browser-qt
> 
> Из-за того, что альтернативы делаются в Makefile, веса этих
> альтернатив задаются статически. И получаются одинаковые для всех
> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
> теперь запрещены.
> Поэтому надо договориться, у каких дистрибутивов какие веса будут.
> branding-education уже занял 50 и 000012000000.
> Я вчера занял для branding-server-v - 60 и 000012000060
> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
> из Makefile.

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

> 4) Разработка всех branding в едином репо (subst spec?)

Я думаю все равно у каждого будет форк, как и с mkimage-profiles.
Потому что если мне что-то нужно для дистрибутива, то мне нужно это
прям сейчас и быстро. И не факт, что все, что сделают другие RM мне
понравится, я могу захотеть это оторвать.

> Сейчас нет эталонного репо branding, есть куча форков. С разным
> наполнением. Но что хуже, с разным поведением. Например, проблема с
> /etc/os-release не проявляется в education.

С моей точки зрения наоборот проявляется :).

> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
> никто не рассказывает и не анонсирует.
> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
> матрицу для сборки, в каких дистрибутивах что должно быть
> включено/выключено (профили для kde/xfce/mate и т.п.).

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

-- 
WBR, Mikhail Efremov

Re: [devel-distro] branding

[Anton Farygin]

On 04.08.2021 13:57, Mikhail Efremov wrote:
> On Tue, 3 Aug 2021 21:29:47 +0300 Alexey Shabalin wrote:
>> День добрый.
>> Есть несколько вопросов для обсуждения по поводу наших branding.
>>
>> 1) /etc/altlinux-release и /etc/os-release
>> После коммита, который разошелся по всем брэндингам
>> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
>> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
>> Как они создаются при установке, никакое обновление их больше не обновляет.
>> Это нарушает ожидаемое поведение во многих скриптах и системах
>> автоматизированного управления. Я могу привести примеры, если нужно,
>> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
>> что в них используется текущее состояние версии, а не на момент
>> установки.
> Я как раз считаю, что там должна быть версия дистрибутива, который
> человек ставил. Потому что обновление из бранча не означает, что у
> человека теперь новая версия. Обновление не делает из 9.1 9.2, и уж тем
> более 10.0. Так же как установка из репозитория пакета, не входящего в
> дистрибутив, не означает, что в дистрибутиве этот пакет появился.
> Новая версия - это другой продукт.
> Состав дистрибутивов меняется от версии к версии, к тому же они могут
> сильно отличаться первоначальной настройкой системы (те же
> installer-features могут добавляться, удаляться или изменяться).
>
Но в первую очередь дистрибутив - это пакетная база, а не то, как её 
поставили (хотя, конечно же, это связано).

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

Re: [devel-distro] branding

[Leonid Krivoshein]

04.08.2021 13:57, Mikhail Efremov пишет:
> On Tue, 3 Aug 2021 21:29:47 +0300 Alexey Shabalin wrote:
>> День добрый.
>> Есть несколько вопросов для обсуждения по поводу наших branding.
>>
>> 1) /etc/altlinux-release и /etc/os-release
>> После коммита, который разошелся по всем брэндингам
>> http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
>> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
>> Как они создаются при установке, никакое обновление их больше не обновляет.
>> Это нарушает ожидаемое поведение во многих скриптах и системах
>> автоматизированного управления. Я могу привести примеры, если нужно,
>> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
>> что в них используется текущее состояние версии, а не на момент
>> установки.
> Я как раз считаю, что там должна быть версия дистрибутива, который
> человек ставил. Потому что обновление из бранча не означает, что у
> человека теперь новая версия.

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


> Обновление не делает из 9.1 9.2,

У нас почему-то не делает. У всех остальных вендоров делает. На самом 
деле мы все знаем, что и наше обновление делает из 9.1 -> 9.2, но данным 
коммитом мы показываем остальным, что никаких изменений не было.


> и уж тем
> более 10.0.

К слову напомнить о разнице между upgrade и dist-upgrade в debian, у 
которой можно прописать current в apt repo, но для нас всё делается 
через dist-upgrade, а переключение на бранч требует отдельного 
телодвижения. Во всех дистрибутивах и при мажорном, и при минорном 
обновлении файлы релиза и брэндинг меняются. Во всех, кроме Альта.

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


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

Всё же для большинства пользователей и инструментов система определяется 
составом и версией пакетной базы. При обновлении всей пакетной базы с p9 
на p10 скорее получится продукт на p10, какие бы там раньше 
installer-фичи не отрабатывали. У root'а вся информация об изначально 
установленной системе есть в /root/.install-logs, а если кому-то кроме 
рута надо, можно держать отдельно в /etc/release.d/ и что-то в этом 
роде. Правда я не очень пониманию, для чего такая информация может быть 
полезна.

Любой продукт можно считать производным от..., если он был обновлён из 
репозитория или если туда был поставлен хотя бы один пакет или удалён. 
Лицензия (не важно, куплена она или предоставлена даром) может давать на 
это право. Если кому-то важно получить систему, максимально близкую к 
купленной, просто не надо её обновлять. Все эти действия не связаны с 
/etc/os-release, он о том, что у пользователя на данный момент времени. 
Законно это получено или нет -- не наше дело.


>> Так же мне кажется, это может нарушать и договорные отношения (люди
>> которые обновились на новый бранч этого не увидят, а люди которым по
>> договорам нельзя обновляться на новые релизы сделают это без проблем -
>> вывеска, версия платформы, не изменилась, значит можно)
>>
>> Предлагаю откатить это изменение во всех branding для всех дистрибутивов.
>>
>> Так же считаю делать что-то в %post с лицензией излишне.
>> Если лицензия изменилась, надо её доставить. Если есть юридические
>> проблемы, надо отразить в лицензии, что правообладатель имеет право
>> менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
>> юристы прокомментируют.
> Даже в этом случае при изменении лицензии человек должен ее прочитать и
> согласиться с нею. И у нас не написано в лицензионных договорах, что они
> могут меняться для уже установленных систем.
> Впрочем, тут действительно нужны комментарии юриста.
>
>> Если в лицензии правообладатель сменился с Альтлинук на Базальт, то
>> тем более надо менять лицензию - Альтлинукс еще можно найти?
>> Если кого-то не устраивает изменение лицензии, значит они не должны обновляться.
> Я считаю, что лицензионное соглашение, которое показывается в
> альтераторе должно быть именно то, с которым соглашались при установке.
>
>> 2) Обновление оформления при обновлении
>> Так же не происходит обновление bootsplash
>> %post bootsplash
>> [ "$1" -eq 1 ] || exit 0
>>
>> Мне кажется, что пользователь должен явно увидеть обновление
>> оформления своей системы при обновлении на новый бранч. Иначе зачем
>> вообще обновляются пакеты с оформлением, если изменений в оформлении
>> не видно. (У меня есть посылка для вашего мальчика, но я вам её не
>> отдам :))
> Изменение оформления тоже спорный вопрос. Если установленный
> дистрибутив не меняется, то и оформление должно остаться как было.
> Или что, установка branding от Server превращает Simply в сервер?
> Это, кстати, и замены os-release касается.
>

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


>> Даже не обязательно изменение оформления, а исправление ошибки в
>> пакете не приведет ни к каким результатам.
> Вот исправление ошибок это аргумент. Но обычно они достаточно
> незначительны. В случае серьезных - можно что-то придумать.
>
>> 3) Веса альтернатив в branding
>> В пакетах брэндинга находятся 3 штуки альтернатив
>> - /usr/share/design-current
>> - /usr/share/design/current
>> - /etc/alterator/design-browser-qt
>>
>> Из-за того, что альтернативы делаются в Makefile, веса этих
>> альтернатив задаются статически. И получаются одинаковые для всех
>> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides
>> теперь запрещены.
>> Поэтому надо договориться, у каких дистрибутивов какие веса будут.
>> branding-education уже занял 50 и 000012000000.
>> Я вчера занял для branding-server-v - 60 и 000012000060
>> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.
>> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile
>> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать
>> из Makefile.
> Вопрос весов мне не кажется сильно значительным, можно просто взять
> любой свободный. Но лучше да, договориться.
>
>> 4) Разработка всех branding в едином репо (subst spec?)
> Я думаю все равно у каждого будет форк, как и с mkimage-profiles.
> Потому что если мне что-то нужно для дистрибутива, то мне нужно это
> прям сейчас и быстро. И не факт, что все, что сделают другие RM мне
> понравится, я могу захотеть это оторвать.
>
>> Сейчас нет эталонного репо branding, есть куча форков. С разным
>> наполнением. Но что хуже, с разным поведением. Например, проблема с
>> /etc/os-release не проявляется в education.
> С моей точки зрения наоборот проявляется :).
>
>> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
>> никто не рассказывает и не анонсирует.
>> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
>> матрицу для сборки, в каких дистрибутивах что должно быть
>> включено/выключено (профили для kde/xfce/mate и т.п.).
> Там еще будут разная графика, темы plymouth и т.д.
> Впрочем, иметь одинаковую общую часть, те же Makefiles, действительно
> было бы полезно.
>

-- 
Best regards,
Leonid Krivoshein.

Re: [devel-distro] branding

[Dmitry V. Levin]

On Wed, Aug 04, 2021 at 01:57:05PM +0300, Mikhail Efremov wrote:
> On Tue, 3 Aug 2021 21:29:47 +0300 Alexey Shabalin wrote:
> > День добрый.
> > Есть несколько вопросов для обсуждения по поводу наших branding.
> > 
> > 1) /etc/altlinux-release и /etc/os-release
> > После коммита, который разошелся по всем брэндингам
> > http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89
> > больше не обновляются файлы /etc/altlinux-release и /etc/os-release.
> > Как они создаются при установке, никакое обновление их больше не обновляет.
> > Это нарушает ожидаемое поведение во многих скриптах и системах
> > автоматизированного управления. Я могу привести примеры, если нужно,
> > кто использует /etc/os-release или /etc/altlinux-release. Ожидается,
> > что в них используется текущее состояние версии, а не на момент
> > установки.
> 
> Я как раз считаю, что там должна быть версия дистрибутива, который
> человек ставил. Потому что обновление из бранча не означает, что у
> человека теперь новая версия. Обновление не делает из 9.1 9.2, и уж тем
> более 10.0. Так же как установка из репозитория пакета, не входящего в
> дистрибутив, не означает, что в дистрибутиве этот пакет появился.
> Новая версия - это другой продукт.
> Состав дистрибутивов меняется от версии к версии, к тому же они могут
> сильно отличаться первоначальной настройкой системы (те же
> installer-features могут добавляться, удаляться или изменяться).

Что такое версия операционной системы - это очень интересный вопрос.
Можно сказать, что версия ОС - это версия распространяемого образа ОС,
но как быть с версией ОС во время её эксплуатации?  Мало того, что при
установке ОС приобретает индивидуальность, так она ещё может обновляться и
меняться до полной неузнаваемости.  Довольно странно называть версией ОС
нечто, что было на момент установки, если с тех пор не сохранилось ни
одного пакета.  С одной стороны, полагаться на версию ОС опрометчиво,
потому что это слишком скользкое понятие, с другой стороны, можно
определить версию ОС таким образом, чтобы убрать неоднозначность,
например, установить, что версия ОС - это версия брэндинга.

> > Так же мне кажется, это может нарушать и договорные отношения (люди
> > которые обновились на новый бранч этого не увидят, а люди которым по
> > договорам нельзя обновляться на новые релизы сделают это без проблем -
> > вывеска, версия платформы, не изменилась, значит можно)
> > 
> > Предлагаю откатить это изменение во всех branding для всех дистрибутивов.
> > 
> > Так же считаю делать что-то в %post с лицензией излишне.
> > Если лицензия изменилась, надо её доставить. Если есть юридические
> > проблемы, надо отразить в лицензии, что правообладатель имеет право
> > менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше
> > юристы прокомментируют.
> 
> Даже в этом случае при изменении лицензии человек должен ее прочитать и
> согласиться с нею. И у нас не написано в лицензионных договорах, что они
> могут меняться для уже установленных систем.
> Впрочем, тут действительно нужны комментарии юриста.

С лицензией на ОС как на производное произведение немного другая история.

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

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

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


-- 
ldv

Re: [devel-distro] branding

[Anton V. Boyarshinov]

> 3) Веса альтернатив в branding
> В пакетах брэндинга находятся 3 штуки альтернатив
> - /usr/share/design-current
> - /usr/share/design/current
> - /etc/alterator/design-browser-qt

Само по себе это не проблема, распределение весов автоматически
проконтролируется контролем дублирующихся провайдов, но без альтернатив
(мне) действительно было бы удобнее.

> 
> 4) Разработка всех branding в едином репо (subst spec?)
Не вижу, каким образом тут можно прикрутить specsubst...

Проблема в том, что в брендингах всегда различаются некоторые текстовые
строки (легко решается specsubst), изображения (решается specsust если
хранить их в разных каталогах). Но, вообще говоря, там могут быть
другие значимые изменения.

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

> Сейчас нет эталонного репо branding, есть куча форков. С разным
> наполнением. Но что хуже, с разным поведением. Например, проблема с
> /etc/os-release не проявляется в education.
> Тяжело отслеживать полезные изменения в разных репо. Тем более о них
> никто не рассказывает и не анонсирует.
> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то
> матрицу для сборки, в каких дистрибутивах что должно быть
> включено/выключено (профили для kde/xfce/mate и т.п.).
> 
> 

[devel-distro] system-logo (was: branding)

[Sergey V Turchin]

On Tuesday, 3 August 2021 21:29:47 MSK Alexey Shabalin wrote:
> День добрый.
> Есть несколько вопросов для обсуждения по поводу наших branding.
У меня есть один. Зачем сломали часть branding-*-bootsplash, добавив туда 
варварским(совершенно испортив всю концепцию branding) способом провайд /usr/
share/pixmaps/system-logo.png и когда исправят?

Просто, если вдруг меня коснется, я в своём branding-*-bootsplash сделаю
Provides: /usr/share/pixmaps/system-logo.png
Obsoletes: /usr/share/pixmaps/system-logo.png

Я предупредил, если что.

[...]

-- 
Regards, Sergey.