[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