<div dir="auto"><div><br><br><div data-smartmail="gmail_signature"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 4 авг. 2021 г., 05:01 Leonid Krivoshein <<a href="mailto:klark.devel@gmail.com">klark.devel@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Доброй ночи!<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>
> больше не обновляются файлы /etc/altlinux-release и /etc/os-release.<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>
неправомерного наезда. Не стоило прогибаться.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Кто на sem@ наехал? Поясните, пожалуйста. </div><div dir="auto"><br></div><div dir="auto">Rgrds, Алексей</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>
поставить на 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>
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>
Best regards,<br>
Leonid Krivoshein.<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>