From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Wed, 5 Jul 2023 23:42:04 +0200 From: Konstantin Lepikhov To: devel-kernel@lists.altlinux.org Message-ID: Mail-Followup-To: devel-kernel@lists.altlinux.org References: <574527ed-a4a5-a998-529f-b90d92a0ae6f@basealt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <574527ed-a4a5-a998-529f-b90d92a0ae6f@basealt.ru> X-Operation-System: ALT Regular Sisyphus 6.1.0-lks-wks-alt6.34 User-Agent: Mutt/2.1.1.0.3.g6c0f75cca (2021-07-12) Subject: Re: [d-kernel] =?utf-8?b?0K/QtNGA0LAg0YEgdmVyc2lvbmVkIGZsYXZvdXI=?= X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2023 21:42:14 -0000 Archived-At: List-Archive: List-Post: 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.