[devel-distro] branding

Wed Aug 4 10:42:07 MSK 2021

Да, спасибо, Леня мне прислал. Хотел бы поучаствовать но у меня сегодня 
в 15 разговор с КД о 9.2 и p10, так что если до 15 уложимся...

04.08.2021 09:41, Aleksey Novodvorsky пишет:
> ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein <klark.devel at 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СП
>> пользователь обязан всегда обновляться на последнюю версию, даже если
>> это будет переход на мажорную версию. Данный коммит и в этом случае
>> создаёт путаницу и неудобства.
>>
>> Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие
>> неправомерного наезда. Не стоило прогибаться.
> 
> 
> Кто на sem@ наехал? Поясните, пожалуйста.
> 
> Rgrds, Алексей
> 
> 
> Если у людей (организаций)
>> не было права обновляться, значит не надо было обновляться. Можно
>> поставить на 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.
>>
>> _______________________________________________
>> devel-distro mailing list
>> devel-distro at lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel-distro
>>

-- 
С уважением,
Владимир Черный
Советник Генерального директора. Директор по продуктам.
ООО "Базальт СПО"
http://www.basealt.ru
тел.: +7(495)123-47-99 доб. 513