From: Konstantin Lepikhov <lakostis@altlinux.org> To: devel-kernel@lists.altlinux.org Subject: Re: [d-kernel] Ядра с versioned flavour Date: Wed, 5 Jul 2023 23:42:04 +0200 Message-ID: <ZKXjrFxYNdmrs/GQ@lks.home> (raw) In-Reply-To: <574527ed-a4a5-a998-529f-b90d92a0ae6f@basealt.ru> Hi Антон! On 07/06/2023, at 12:06:32 AM you wrote: > Здравствуйте > > Версионированные flavour ядер вместо std-def и un-def. Нужны или не нужны? > Идея бродит уже больше года. Состоит она в том, что ядра буду получать в качестве flavour - мажорную версию ядра. > Т.е. kernel-image-6.1, kernel-image-6.4 и т.д. > Возможно, лучше будет вариант с префиксом std (стандартное для ALT) или stable (стабильное, но путаница с термином, ассоциация stable - это не lts): > kernel-image-std-6.1, kernel-image-std-6.4 и т.д. Где именно бродит эта идея? Может быть она перебродила и не стоит ей увлекаться? :) > > Я плюсы и минусы вижу так: > Плюсы: > - Снимается ограничение в два ядра для репозитория. Сможем позволить себе на относительно короткое время собирать третье ядро. А, если с каким-то ядром будет всё хорошо, оставить в репозитории лишь одно ядро. Это касается бранчей. В Сизифе будет два ядра - последний lts и последний stable. Но так как существует промежуток в месяц, когда stable ядер два, то мы можем в часть этого промежутка собирать три ядра. В сизифе уже сейчас >2 ядер. Какие именно проблемы решает предлагаемый подход? > - При обновлении с бранча на бранч не будет возникать ситуации, что продукт 10.x был выпущен с ядром un-def, а продукт на p11 11.0 ещё только с std-def. При обновлении пользователь получает ядро, которое не тестировалось с дистрибутивом. По новой схеме будет установлено ядро нижней версии в бранче. Т.е. это какая-то внутренная проблема выпускающего продукты, раз он пропускает продукт с непротестируемым ядром. > - На первом этапе существования в репозитории можно оставить только самый новый lts и не гнаться за stable, пока не выйдет новый lts Определитесь пожалуйста, что такое stable и что такое lts. LTS это либо какие-то обязательства ООО за деньги, либо какие-то специфические требования (например мобильные устройства). Специфические ядра требуют специфический подход -> проблемы ООО. > - Переход на более новую версию ядра будет происходить при удалении пакета ядра из репозитория, то есть будет сопровождаться сменой flavour > - Пользователи перестанут задавать вопросы что такое un-def (ассоциация с unstable) У меня ассоциация с undefined :) > Минусы: > - Для каждого stable ядра в gears будет появляться новый git (мантейнеру ядра не нужно прерывать историю git для веток в gears) > - Мантейнеру ядра при сборке новой версии ядра не нужно будет заботиться о том, что сторонние модули ядра не собираются, да и вообще отправлять их собираться вместе с новым ядром. Ответственность полностью перейдёт на мантейнеров сторонних модулей ядра (для мантейнера ядра - это плюс). Манетейнер ядра уже сейчас не занимается модулями, этим занимается kernel team. > > Прошу высказать свои мысли по этому поводу. На первом этапе обсуждения стоит понять необходимость данного изменения. > > Изменение потребует доработки update-kernel. Нормой станет исчезновение пакета с ядром, и эту ситуацию нужно будет обрабатывать. > В этой ситуации update-kernel должен уведомить пользователя, что ядра с таким-то flavour в репозитории больше нет, и предложить перейти на flavour с минимальной версией в репозитории. > Также нужно будет пересмотреть remove-old-kernels, чтобы удалял не только для текущего flavour. А то ядра со старыми flavour будут накапливаться. > .. -- WBR et al.
next prev parent reply other threads:[~2023-07-05 21:42 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-05 17:06 Антон Мидюков 2023-07-05 21:42 ` Konstantin Lepikhov [this message] 2023-07-06 2:29 ` Антон Мидюков
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=ZKXjrFxYNdmrs/GQ@lks.home \ --to=lakostis@altlinux.org \ --cc=devel-kernel@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 kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/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-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git