[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.