[d-kernel] Ядра с versioned flavour

[Konstantin Lepikhov]

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.