From: Mikhail Efremov <sem@altlinux.org> To: devel-distro@lists.altlinux.org Subject: Re: [devel-distro] branding Date: Wed, 4 Aug 2021 13:57:05 +0300 Message-ID: <20210804135705.72d92da1@sem-notebook.localdomain> (raw) In-Reply-To: <CAEdvWkTNBhmQPc2_HoTAyaXPTioTJ_zRwAu3coE-Ccbxydknxw@mail.gmail.com> On Tue, 3 Aug 2021 21:29:47 +0300 Alexey Shabalin wrote: > День добрый. > Есть несколько вопросов для обсуждения по поводу наших 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. > Как они создаются при установке, никакое обновление их больше не обновляет. > Это нарушает ожидаемое поведение во многих скриптах и системах > автоматизированного управления. Я могу привести примеры, если нужно, > кто использует /etc/os-release или /etc/altlinux-release. Ожидается, > что в них используется текущее состояние версии, а не на момент > установки. Я как раз считаю, что там должна быть версия дистрибутива, который человек ставил. Потому что обновление из бранча не означает, что у человека теперь новая версия. Обновление не делает из 9.1 9.2, и уж тем более 10.0. Так же как установка из репозитория пакета, не входящего в дистрибутив, не означает, что в дистрибутиве этот пакет появился. Новая версия - это другой продукт. Состав дистрибутивов меняется от версии к версии, к тому же они могут сильно отличаться первоначальной настройкой системы (те же installer-features могут добавляться, удаляться или изменяться). > Так же мне кажется, это может нарушать и договорные отношения (люди > которые обновились на новый бранч этого не увидят, а люди которым по > договорам нельзя обновляться на новые релизы сделают это без проблем - > вывеска, версия платформы, не изменилась, значит можно) > > Предлагаю откатить это изменение во всех branding для всех дистрибутивов. > > Так же считаю делать что-то в %post с лицензией излишне. > Если лицензия изменилась, надо её доставить. Если есть юридические > проблемы, надо отразить в лицензии, что правообладатель имеет право > менять лицензию в одностороннем порядке. Но это не ко мне, пусть лучше > юристы прокомментируют. Даже в этом случае при изменении лицензии человек должен ее прочитать и согласиться с нею. И у нас не написано в лицензионных договорах, что они могут меняться для уже установленных систем. Впрочем, тут действительно нужны комментарии юриста. > Если в лицензии правообладатель сменился с Альтлинук на Базальт, то > тем более надо менять лицензию - Альтлинукс еще можно найти? > Если кого-то не устраивает изменение лицензии, значит они не должны обновляться. Я считаю, что лицензионное соглашение, которое показывается в альтераторе должно быть именно то, с которым соглашались при установке. > 2) Обновление оформления при обновлении > Так же не происходит обновление bootsplash > %post bootsplash > [ "$1" -eq 1 ] || exit 0 > > Мне кажется, что пользователь должен явно увидеть обновление > оформления своей системы при обновлении на новый бранч. Иначе зачем > вообще обновляются пакеты с оформлением, если изменений в оформлении > не видно. (У меня есть посылка для вашего мальчика, но я вам её не > отдам :)) Изменение оформления тоже спорный вопрос. Если установленный дистрибутив не меняется, то и оформление должно остаться как было. Или что, установка branding от Server превращает Simply в сервер? Это, кстати, и замены os-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?) Я думаю все равно у каждого будет форк, как и с mkimage-profiles. Потому что если мне что-то нужно для дистрибутива, то мне нужно это прям сейчас и быстро. И не факт, что все, что сделают другие RM мне понравится, я могу захотеть это оторвать. > Сейчас нет эталонного репо branding, есть куча форков. С разным > наполнением. Но что хуже, с разным поведением. Например, проблема с > /etc/os-release не проявляется в education. С моей точки зрения наоборот проявляется :). > Тяжело отслеживать полезные изменения в разных репо. Тем более о них > никто не рассказывает и не анонсирует. > Было бы хорошо все брэндинги собирать из единого репо. Задать какую-то > матрицу для сборки, в каких дистрибутивах что должно быть > включено/выключено (профили для kde/xfce/mate и т.п.). Там еще будут разная графика, темы plymouth и т.д. Впрочем, иметь одинаковую общую часть, те же Makefiles, действительно было бы полезно. -- WBR, Mikhail Efremov
next prev parent reply other threads:[~2021-08-04 10:57 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-03 18:29 Alexey Shabalin 2021-08-04 1:00 ` Leonid Krivoshein 2021-08-04 8:26 ` Владимир Черный 2021-08-04 7:42 ` Владимир Черный 2021-08-04 10:14 ` Leonid Krivoshein 2021-08-04 10:23 ` Anton Farygin 2021-08-04 10:35 ` Leonid Krivoshein 2021-08-04 10:41 ` Anton Farygin 2021-08-04 11:08 ` Leonid Krivoshein 2021-08-04 11:09 ` Anton Farygin 2021-08-04 11:14 ` Leonid Krivoshein 2021-08-04 11:30 ` Anton Farygin 2021-08-04 10:29 ` Leonid Krivoshein 2021-08-04 10:46 ` Leonid Krivoshein 2021-08-04 10:49 ` Aleksey Novodvorsky 2021-08-04 11:10 ` Leonid Krivoshein 2021-08-04 11:25 ` Aleksey Novodvorsky 2021-08-04 12:22 ` Leonid Krivoshein 2021-08-04 12:26 ` Aleksey Novodvorsky 2021-08-04 13:02 ` Mikhail Efremov 2021-08-04 13:12 ` Leonid Krivoshein 2021-08-04 14:05 ` Leonid Krivoshein 2021-08-04 14:45 ` Anton Farygin 2021-08-04 15:14 ` Mikhail Efremov 2021-08-04 15:43 ` Leonid Krivoshein 2021-08-05 16:37 ` Alexey Shabalin 2021-08-05 17:41 ` Alexey Shabalin 2021-08-05 18:49 ` Michael Shigorin 2021-08-05 20:02 ` Alexey Shabalin 2021-08-05 20:36 ` Leonid Krivoshein 2021-08-05 21:00 ` Leonid Krivoshein 2021-08-05 21:11 ` Leonid Krivoshein 2021-08-05 22:06 ` Leonid Krivoshein 2021-08-06 4:47 ` Anton Farygin 2021-08-06 5:35 ` Anton Farygin 2021-08-06 5:57 ` Anton Farygin 2021-08-06 6:02 ` Anton Farygin 2021-08-06 6:21 ` Anton Farygin 2021-08-06 4:46 ` Anton Farygin 2021-08-05 20:05 ` Alexey Shabalin 2021-08-05 20:44 ` Leonid Krivoshein 2021-08-16 7:19 ` Anton V. Boyarshinov 2021-08-16 7:23 ` Anton Farygin 2021-08-16 9:22 ` Anton V. Boyarshinov 2021-08-16 9:26 ` Anton Farygin 2021-08-19 10:33 ` Dmitry V. Levin 2021-08-19 10:43 ` Sergey V Turchin 2021-08-19 11:22 ` [devel-distro] os-release Dmitry V. Levin 2021-08-19 11:36 ` Sergey V Turchin 2021-08-19 11:50 ` Dmitry V. Levin 2021-08-19 12:07 ` Sergey V Turchin 2021-08-19 12:24 ` Anton Farygin 2021-08-19 11:19 ` [devel-distro] branding Anton Farygin 2021-08-19 11:29 ` [devel-distro] os-release Dmitry V. Levin 2021-08-19 12:21 ` Anton Farygin 2021-08-21 1:13 ` [devel-distro] branding Leonid Krivoshein 2021-09-01 8:34 ` Dmitry V. Levin 2021-09-01 9:37 ` Anton Farygin 2021-09-01 9:47 ` Dmitry V. Levin 2021-09-01 11:12 ` Anton Farygin 2021-09-01 11:25 ` Dmitry V. Levin 2021-09-01 11:56 ` Anton Farygin 2021-09-01 12:33 ` Leonid Krivoshein 2021-09-01 12:46 ` Leonid Krivoshein 2021-09-01 13:59 ` Dmitry V. Levin 2021-09-01 14:41 ` Anton Farygin 2021-09-01 17:14 ` Leonid Krivoshein 2021-09-01 15:01 ` Sergey V Turchin 2021-09-01 17:08 ` Leonid Krivoshein 2021-09-02 8:26 ` Sergey V Turchin 2021-09-02 16:46 ` Leonid Krivoshein 2021-09-02 17:09 ` Dmitry V. Levin 2021-09-02 17:23 ` Leonid Krivoshein 2021-09-02 18:13 ` Anton Farygin 2021-09-02 18:15 ` Dmitry V. Levin 2021-09-02 18:17 ` Anton Farygin 2021-09-02 18:20 ` Dmitry V. Levin 2021-09-02 18:23 ` Anton Farygin 2021-09-02 18:33 ` Dmitry V. Levin 2021-09-02 18:35 ` Anton Farygin 2021-09-02 20:24 ` Leonid Krivoshein 2021-09-02 20:43 ` Leonid Krivoshein 2021-09-03 5:33 ` Anton Farygin 2021-09-02 21:10 ` Leonid Krivoshein 2021-09-01 9:54 ` Leonid Krivoshein 2021-09-01 10:44 ` Dmitry V. Levin 2021-08-19 11:43 ` [devel-distro] os-release Dmitry V. Levin 2021-08-19 11:58 ` Andrey Cherepanov 2021-08-21 1:20 ` [devel-distro] branding Leonid Krivoshein 2021-08-05 20:37 ` Leonid Krivoshein 2021-08-16 12:38 ` [devel-distro] Сизиф -- не первая версия, а последняя (was: branding) Sergey V Turchin 2021-08-16 7:16 ` [devel-distro] branding Anton V. Boyarshinov 2021-08-04 15:15 ` Anton Farygin 2021-08-04 10:57 ` Mikhail Efremov [this message] 2021-08-04 12:32 ` Anton Farygin 2021-08-04 13:54 ` Leonid Krivoshein 2021-08-04 16:09 ` Dmitry V. Levin 2021-08-16 7:12 ` Anton V. Boyarshinov 2021-08-16 12:19 ` [devel-distro] system-logo (was: branding) Sergey V Turchin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210804135705.72d92da1@sem-notebook.localdomain \ --to=sem@altlinux.org \ --cc=devel-distro@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git