Re: [devel-distro] branding

["Владимир Черный" <black@altlinux.org>]

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

При переходе с 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 и т.п.).
>