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

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

[Антон Мидюков]

Здравствуйте

Версионированные 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 ядер два, то мы можем в часть этого промежутка собирать три ядра.  
- При обновлении с бранча на бранч не будет возникать ситуации, что продукт 10.x был выпущен с ядром un-def, а продукт на p11 11.0 ещё только с std-def. При обновлении пользователь получает ядро, которое не тестировалось с дистрибутивом. По новой схеме будет установлено ядро нижней версии в бранче.
- На первом этапе существования в репозитории можно оставить только самый новый lts и не гнаться за stable, пока не выйдет новый lts
- Переход на более новую версию ядра будет происходить при удалении пакета ядра из репозитория, то есть будет сопровождаться сменой flavour
- Пользователи перестанут задавать вопросы что такое un-def (ассоциация с unstable)
Минусы:
- Для каждого stable ядра в gears будет появляться новый git (мантейнеру ядра не нужно прерывать историю git для веток в gears)
- Мантейнеру ядра при сборке новой версии ядра не нужно будет заботиться о том, что сторонние модули ядра не собираются, да и вообще отправлять их собираться вместе с новым ядром. Ответственность полностью перейдёт на мантейнеров сторонних модулей ядра (для мантейнера ядра - это плюс).

Прошу высказать свои мысли по этому поводу. На первом этапе обсуждения стоит понять необходимость данного изменения.

Изменение потребует доработки update-kernel. Нормой станет исчезновение пакета с ядром, и эту ситуацию нужно будет обрабатывать.
В этой ситуации update-kernel должен уведомить пользователя, что ядра с таким-то flavour в репозитории больше нет, и предложить перейти на flavour с минимальной версией в репозитории.
Также нужно будет пересмотреть remove-old-kernels, чтобы удалял не только для текущего flavour. А то ядра со старыми flavour будут накапливаться.

-- 
С уважением, Антон Мидюков <antohami@basealt.ru>

Re: [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.

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

[Антон Мидюков]

06.07.2023 04:42, 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 ядер. Какие именно проблемы решает предлагаемый
> подход?
> 

Речь именно о замене пары std-def и un-def, которые сопровождает vt. Вопрос не затрагивает тех, кто использует альтернативные ядра.
Переформулирую решаемые проблемы в контексте Сизифа:
- не нужно задерживать сборку нового stable ядра в Сизиф до сборки всех модулей или их удаления, дождавшись прекращения поддержки старого stable. То есть сейчас для сборки нового ядра нужно преодолеть unmets от модулей. По новой схеме собирается новый flavour и никаких unmet'ов нет. Два последних stable могут сосуществовать, пока один из них не прекратит поддерживаться.
- смена версии ядра сопровождается сменой flavour. Причина замены flavour у пользователя - удаление ядра с таким flavour из репозитория. Для пользователя это более заметное событие должно быть.
- мантейнеру таких ядер нужно лишь писать в рассылку, что собрано новое ядро, желающие собирайте с ним модули. И сообщать что через какое-то время неподдерживаемое ядро будет удалено.

>> - При обновлении с бранча на бранч не будет возникать ситуации, что продукт 10.x был выпущен с ядром un-def, а продукт на p11 11.0 ещё только с std-def. При обновлении пользователь получает ядро, которое не тестировалось с дистрибутивом. По новой схеме будет установлено ядро нижней версии в бранче.
> Т.е. это какая-то внутренная проблема выпускающего продукты, раз он
> пропускает продукт с непротестируемым ядром.
> 
>> - На первом этапе существования в репозитории можно оставить только самый новый lts и не гнаться за stable, пока не выйдет новый lts
> Определитесь пожалуйста, что такое stable и что такое lts. LTS это либо

Термины в контексте kernel.org (здесь lts соответствует longterm).

> какие-то обязательства ООО за деньги, либо какие-то специфические
> требования (например мобильные устройства). Специфические ядра требуют
> специфический подход -> проблемы ООО.
> 
>> - Переход на более новую версию ядра будет происходить при удалении пакета ядра из репозитория, то есть будет сопровождаться сменой flavour
>> - Пользователи перестанут задавать вопросы что такое un-def (ассоциация с unstable)
> У меня ассоциация с undefined :)
> 
>> Минусы:
>> - Для каждого stable ядра в gears будет появляться новый git (мантейнеру ядра не нужно прерывать историю git для веток в gears)
>> - Мантейнеру ядра при сборке новой версии ядра не нужно будет заботиться о том, что сторонние модули ядра не собираются, да и вообще отправлять их собираться вместе с новым ядром. Ответственность полностью перейдёт на мантейнеров сторонних модулей ядра (для мантейнера ядра - это плюс).
> Манетейнер ядра уже сейчас не занимается модулями, этим занимается kernel
> team.
> 

Не совсем так. 
При обновлении un-def или std-def мантейнер получает кучу unmet'ов. При сборке нового flavour, мантейнер их получать не будет. Вероятность обеднения нового ядра модулями сильно повышается. И это конечно же минус с моей точки зрения.

-- 
С уважением, Антон Мидюков <antohami@basealt.ru>