ALT Linux kernel packages development
 help / color / mirror / Atom feed
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.


  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