Re: [devel-distro] branding

[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СП 
пользователь обязан всегда обновляться на последнюю версию, даже если 
это будет переход на мажорную версию. Данный коммит и в этом случае 
создаёт путаницу и неудобства.

Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие 
неправомерного наезда. Не стоило прогибаться. Если у людей (организаций) 
не было права обновляться, значит не надо было обновляться. Можно 
поставить на 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.