From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel-distro@lists.altlinux.org References: <0df6518c-2e09-7c27-0145-fe37b55ebd4d@gmail.com> From: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgCDQp9C10YDQvdGL0Lk=?= Message-ID: <9db31596-2f5d-f8d9-e5e4-6573b1b89600@altlinux.org> Date: Wed, 4 Aug 2021 11:26:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <0df6518c-2e09-7c27-0145-fe37b55ebd4d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-RU-lebedev Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 06 Aug 2021 13:16:37 +0300 Subject: Re: [devel-distro] branding X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 08:26:03 -0000 Archived-At: List-Archive: Я полностью согласен с позицией Леонида и Алексея. Кроме технических проблем, это крайне мешает бизнесу. При переходе с 8 на 9 нам неоднократно задавали вопросы типа, а можно перейти с Альт РС 8 на Альт РС 9? ЛП компании это запрещает, предлагаем апгрейд за 0.5 РРЦ, "А если я обновлю, как указано на wiki, как понять, что мы перешли?"... остается взывать к совести и к тому, что документы в бухгалтерии на конкретный релиз, не более. Ответ от юристов еще не получен. 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 и т.п.). >