From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 To: Aleksey Novodvorsky , Distributions development References: <0df6518c-2e09-7c27-0145-fe37b55ebd4d@gmail.com> From: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgCDQp9C10YDQvdGL0Lk=?= Message-ID: <90f26f39-afa9-8489-10b0-52e3f9060736@basealt.ru> Date: Wed, 4 Aug 2021 10:42:07 +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: 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 07:41:34 -0000 Archived-At: List-Archive: Да, спасибо, Леня мне прислал. Хотел бы поучаствовать но у меня сегодня в 15 разговор с КД о 9.2 и p10, так что если до 15 уложимся... 04.08.2021 09:41, Aleksey Novodvorsky пишет: > ср, 4 авг. 2021 г., 05:01 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СП >> пользователь обязан всегда обновляться на последнюю версию, даже если >> это будет переход на мажорную версию. Данный коммит и в этом случае >> создаёт путаницу и неудобства. >> >> Обсуждаемый коммит, насколько я теперь понимаю, возник вследствие >> неправомерного наезда. Не стоило прогибаться. > > > Кто на 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@lists.altlinux.org >> https://lists.altlinux.org/mailman/listinfo/devel-distro >> -- С уважением, Владимир Черный Советник Генерального директора. Директор по продуктам. ООО "Базальт СПО" http://www.basealt.ru тел.: +7(495)123-47-99 доб. 513