<div dir="auto"><div><br><div data-smartmail="gmail_signature"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 6 авг. 2021 г., 13:16 Владимир Черный <<a href="mailto:black@altlinux.org">black@altlinux.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Я полностью согласен с позицией Леонида и Алексея.<br>
Кроме технических проблем, это крайне мешает бизнесу.<br>
<br>
При переходе с 8 на 9 нам неоднократно задавали вопросы типа, а можно <br>
перейти с Альт РС 8 на Альт РС 9? ЛП компании это запрещает, предлагаем <br>
апгрейд за 0.5 РРЦ, "А если я обновлю, как указано на wiki, как понять, <br>
что мы перешли?"..</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Этот механизм есть, мы говорили об этом. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Rgrds, Алексей</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">. остается взывать к совести и к тому, что документы в <br>
бухгалтерии на конкретный релиз, не более.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ответ от юристов еще не получен.<br>
<br>
04.08.2021 04:00, Leonid Krivoshein пишет:<br>
> Доброй ночи!<br>
> <br>
> <br>
> 03.08.2021 21:29, Alexey Shabalin пишет:<br>
>> День добрый.<br>
>> Есть несколько вопросов для обсуждения по поводу наших branding.<br>
>><br>
>> 1) /etc/altlinux-release и /etc/os-release<br>
>> После коммита, который разошелся по всем брэндингам<br>
>> <a href="http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89" rel="noreferrer noreferrer" target="_blank">http://git.altlinux.org/people/sem/packages/branding.git?p=branding.git;a=commitdiff;h=50b0c08ab5be61e9bf83e756ef7f456d706b8b89</a> <br>
>><br>
>> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.<br>
>> Как они создаются при установке, никакое обновление их больше не <br>
>> обновляет.<br>
>> Это нарушает ожидаемое поведение во многих скриптах и системах<br>
>> автоматизированного управления.<br>
> <br>
> Главным образом это нарушает единственный на сегодняшний день <br>
> устоявшийся междистрибутивный стандарт <br>
> (<a href="http://0pointer.de/blog/projects/os-release" rel="noreferrer noreferrer" target="_blank">http://0pointer.de/blog/projects/os-release</a>). Плохой ли, хороший ли, но <br>
> де-факто единственный. LSB не в счёт. А нарушать стандарты плохо.<br>
> <br>
> Да, это создаёт проблемы не только для утилит автоматизации, но и нашей <br>
> техподдержке. Сбился со счёта по обращениям внешним и внутренним в СТП <br>
> только из-за проблем с /etc/os-release.<br>
> <br>
> Это порождает существенные проблемы несовместимости, потому что все <br>
> ориентируются на окружение по os-release, а пытаясь обмануть всех, мы <br>
> обманываем только себя в данном случае, ещё и пользователям создаём <br>
> неудобства.<br>
> <br>
> <br>
>> Я могу привести примеры, если нужно,<br>
>> кто использует /etc/os-release или /etc/altlinux-release. Ожидается,<br>
>> что в них используется текущее состояние версии, а не на момент<br>
>> установки.<br>
>> Так же мне кажется, это может нарушать и договорные отношения (люди<br>
>> которые обновились на новый бранч этого не увидят, а люди которым по<br>
>> договорам нельзя обновляться на новые релизы сделают это без проблем -<br>
>> вывеска, версия платформы, не изменилась, значит можно)<br>
> <br>
> Наверное нет практического руководства для фискальных органов по <br>
> сличению соответствия содержимого диска с содержимым договора в <br>
> отношении ALT Linux. Но даже, если такое существует, не думаю, что при <br>
> полностью изменённой пакетной базе содержимое /etc/*-release хоть что-то <br>
> будет значить, равно как и надписи в grub-меню, которые пользователь <br>
> может поменять, картинки брэндинга, которые пользователь может заменить, <br>
> итд. Все эти os-release, как мне кажется, очень далеки от договорных <br>
> отношений, но тут лучше получить комментарии от юриста.<br>
> <br>
> По нынешней лицензионной политике у организаций есть право обновляться в <br>
> пределах мажорной версии. Т.е. обсуждаемый коммит вреден тем, что он в <br>
> данном случае препятствует правомерной смене брендинга при переходе с <br>
> 9.0 на 9.1, так же завязанному на os-release. По формуляру Альт 8СП <br>
> пользователь обязан всегда обновляться на последнюю версию, даже если <br>
> это будет переход на мажорную версию. Данный коммит и в этом случае <br>
> создаёт путаницу и неудобства.<br>
> <br>
> Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие <br>
> неправомерного наезда. Не стоило прогибаться. Если у людей (организаций) <br>
> не было права обновляться, значит не надо было обновляться. Можно <br>
> поставить на HOLD, можно не переключать бранчи.<br>
> <br>
> Поддержка данного коммита (а по сути некорректного поведения по <br>
> умолчанию, когда все думают, что эта система в первоначальном виде, хотя <br>
> это уже далеко не так) создаёт возможность для госзаказчиков никогда не <br>
> платить за обновление и переход на новые мажорные версии. А зачем <br>
> платить, если по os-release это всё та же купленная система?<br>
> <br>
> <br>
>> Предлагаю откатить это изменение во всех branding для всех дистрибутивов.<br>
> +1<br>
> <br>
> Полагаю, профита от него нет, одни недостатки. Если кому-то такое <br>
> поведение нужно, давайте сделаем его включаемым, но не по умолчанию.<br>
> <br>
> <br>
>> Так же считаю делать что-то в %post с лицензией излишне.<br>
>> Если лицензия изменилась, надо её доставить. Если есть юридические<br>
>> проблемы, надо отразить в лицензии, что правообладатель имеет право<br>
>> менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше<br>
>> юристы прокомментируют.<br>
>> Если в лицензии правообладатель сменился с Альтлинук на Базальт, то<br>
>> тем более надо менять лицензию - Альтлинукс еще можно найти?<br>
>> Если кого-то не устраивает изменение лицензии, значит они не должны <br>
>> обновляться.<br>
> <br>
> Коммерческая лицензия на дистрибутив как составное произведение не <br>
> должна меняться в течении жизненного цикла продукта, если только в ней <br>
> нет оговорки, что у правообладателя есть право менять её в одностороннем <br>
> порядке. Потому что это действительно затрагивает тех, кто купил продукт <br>
> на определённых условиях. Если оговорки в договоре нет, должна быть <br>
> policy, что лицензия на дистрибутив не меняется до выхода следующей <br>
> мажорной версии.<br>
> <br>
> <br>
>> 2) Обновление оформления при обновлении<br>
>> Так же не происходит обновление bootsplash<br>
>> %post bootsplash<br>
>> [ "$1" -eq 1 ] || exit 0<br>
>><br>
>> Мне кажется, что пользователь должен явно увидеть обновление<br>
>> оформления своей системы при обновлении на новый бранч. Иначе зачем<br>
>> вообще обновляются пакеты с оформлением, если изменений в оформлении<br>
>> не видно. (У меня есть посылка для вашего мальчика, но я вам её не<br>
>> отдам :))<br>
> <br>
> Хотя бы сделать такое поведение при обновлении включаемым не по <br>
> умолчанию. И лучше завязать не на os-release, а какой-нибудь внутренний <br>
> /etc/release.d/ , где хранить информацию о том, что было установлено <br>
> изначально, и нужно ли обновлять /etc/*-release файлы при обновлении.<br>
> <br>
> <br>
>> Даже не обязательно изменение оформления, а исправление ошибки в<br>
>> пакете не приведет ни к каким результатам.<br>
>><br>
>> 3) Веса альтернатив в branding<br>
>> В пакетах брэндинга находятся 3 штуки альтернатив<br>
>> - /usr/share/design-current<br>
>> - /usr/share/design/current<br>
>> - /etc/alterator/design-browser-qt<br>
>><br>
>> Из-за того, что альтернативы делаются в Makefile, веса этих<br>
>> альтернатив задаются статически. И получаются одинаковые для всех<br>
>> брэндингов разных дистрибутивов. А как мы знаем, дубликаты Provides<br>
>> теперь запрещены.<br>
>> Поэтому надо договориться, у каких дистрибутивов какие веса будут.<br>
>> branding-education уже занял 50 и 000012000000.<br>
>> Я вчера занял для branding-server-v - 60 и 000012000060<br>
>> Либо давайте сейчас все переиграем и сразу возьмем выделенные веса.<br>
>> И лучше эти веса задавать в rpm spec, пусть они передаются в Makefile<br>
>> как переменные. Или вообще деть эти альтернативы в rpm spec и убрать<br>
>> из Makefile.<br>
>><br>
>> 4) Разработка всех branding в едином репо (subst spec?)<br>
>> Сейчас нет эталонного репо branding, есть куча форков. С разным<br>
>> наполнением. Но что хуже, с разным поведением. Например, проблема с<br>
>> /etc/os-release не проявляется в education.<br>
>> Тяжело отслеживать полезные изменения в разных репо. Тем более о них<br>
>> никто не рассказывает и не анонсирует.<br>
>> Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то<br>
>> матрицу для сборки, в каких дистрибутивах что должно быть<br>
>> включено/выключено (профили для kde/xfce/mate и т.п.).<br>
> <br>
_______________________________________________<br>
devel-distro mailing list<br>
<a href="mailto:devel-distro@lists.altlinux.org" target="_blank" rel="noreferrer">devel-distro@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/devel-distro" rel="noreferrer noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel-distro</a><br>
</blockquote></div></div></div>