[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