[devel-distro] branding

Wed Aug 4 09:41:10 MSK 2021

ср, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.altlinux.org/pipermail/devel-distro/attachments/20210804/df58bc11/attachment.html>