[devel-distro] branding

Fri Aug 6 13:29:51 MSK 2021

пт, 6 авг. 2021 г., 13:16 Владимир Черный <black at altlinux.org>:

> Я полностью согласен с позицией Леонида и Алексея.
> Кроме технических проблем, это крайне мешает бизнесу.
>
> При переходе с 8 на 9 нам неоднократно задавали вопросы типа, а можно
> перейти с Альт РС 8 на Альт РС 9? ЛП компании это запрещает, предлагаем
> апгрейд за 0.5 РРЦ, "А если я обновлю, как указано на wiki, как понять,
> что мы перешли?"..

Этот механизм есть, мы говорили об этом.

Rgrds, Алексей

. остается взывать к совести и к тому, что документы в
> бухгалтерии на конкретный релиз, не более.
>

> Ответ от юристов еще не получен.
>
> 04.08.2021 04:00, Leonid Krivoshein пишет:
> > Доброй ночи!
> >
> >
> > 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СП
> > пользователь обязан всегда обновляться на последнюю версию, даже если
> > это будет переход на мажорную версию. Данный коммит и в этом случае
> > создаёт путаницу и неудобства.
> >
> > Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие
> > неправомерного наезда. Не стоило прогибаться. Если у людей (организаций)
> > не было права обновляться, значит не надо было обновляться. Можно
> > поставить на 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 и т.п.).
> >
> _______________________________________________
> 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/20210806/b0f5c34a/attachment.html>