Hi Eric,

I think I can help answering this one. It's a good question.

On 8/5/23 10:43, Eric Valette wrote:

Hi Debian kernel maintainers,

I have a question regarding the way kernel versions are selected for the stable tree. [...]
[...]

So I have reverted to 6.1.x release for many machines and put the
package on hold.

apt-cache policy linux-image-amd64
linux-image-amd64:
Installé : 6.1.38-2
Candidat : 6.4.4-2
Table de version :
6.4.4-2 500
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
*** 6.1.38-2 500
500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
100 /var/lib/dpkg/status

Two days ago, I was a bit surprised to see that only 6.1.38-2 was pushed
to correct zenbleed while at least 6.1.41 was available for a week or so
and we are now at 6.1.43.

So my questions are:

- Why did you not pick up the last LTS version?

The 6.1.38-2 package version is a security update. It has two extra
included patches compared to the previous 6.1.38-1.

https://tracker.debian.org/news/1449038/accepted-linux-6138-2-source-into-stable-security/

When preparing a security update, first an attempt is made to provide a
new package containing the needed fixes, and at the same time having the
least possible amount of other changes included. In this case, it seems
this was possible, by just picking two new upstream changes, still on
top of the source version 6.1.38.

- On what occasion do you pick up a new LTS kernel for the
stable branch? Is there any formal rule?

For regular Debian stable point releases, which tend to happen about
every two months, there usually will be a package update that follows
the stable upstream branch. At that point, the upstream source will be
updated to whatever is current upstream (LTS) stable version, and the separately added security patches can be dropped again.

The security updates happen 'in between' the normal point releases, and
by trying to keep them as small as possible, we also might for example accommodate users who treat installing a security update differently
than a stable point release.

Extra...1!

After a security update is published, it also automatically gets queued
for stable-proposed-updates (for the next official point release). At https://tracker.debian.org/pkg/linux this is visible at 2023-07-31,
where it happens a day later:

https://tracker.debian.org/news/1449227/accepted-linux-6138-2-source-into-proposed-updates/

So, even if for some reason there would not be a separate update for the
point release, the earlier security update will then be the version that
gets included.

Extra...2!

In some exceptional situations, it might be desirable to already provide
a new package with a new upstream (LTS/stable) kernel version, for
reasons that do not warrant doing a security update. For example, there
might be some non-trivial regression bugs that hit a bunch of users with specific use cases / hardware. If downgrading to the previous package
version as workaround is also not an option because of some serious
other problem, the kernel team might decide to do some extra work
already to help those users get out of the uncomfortable situation right
now. (These should be exceptional ;])

In that case, the kernel team can already do similar work as would
otherwise be done later (closer to the Debian stable point release
date), and for example already upload a package with new upstream source version. In that case, it also gets uploaded to stable-proposed-update,
and users who really want or need it, can install it from there.

It's officially signed (the package repository) and at least the users
do not need to build it themselves etc.

No criticism just curious : I can always pick up the Debian kernel, the Debian config, slightly modify it for the kernel signature and sign the produced kernel and modules. Just that given the handful of modules I do
not need, this is time consuming and I find myself out of normal Debian
path.

Thanks, have fun!
Hans

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)