Thanks Greg for the precise explanation. I would suggest to put it in the
Debian Wiki for futur reference.
Le 18-11-2023, à 09:18:56 -0500, Greg Wooledge a écrit :
On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
On Fri 17 Nov 2023 at 14:07:54 (+0000), Tixy wrote:
> At time of writing, that depended on package in stable is called
> 'linux-image-6.1.0-13-amd64' and the version of that package is
> '6.1.55-1'. This is the kernel installed on my machine.
And AIUI that version is the upstream source version, and a Debian
counter for that source. The counter is rarely used, AFAICT, and can
cause consternation when it is, because it means the kernel gets
upgraded 'in place', making it tricky to revert if you wanted to.
(That shouldn't normally be necessary.) And I'm sure you know all
this, or something like it.
Debian kernel images have a complex naming system, to be sure. Let's
look at the package name first: linux-image-6.1.0-13-amd64
The "linux-image-" part is obvious. That's static.
The "6.1.0-" part comes from the upstream release series. All the
kernel images containing "6.1.0-" in this section should come from the
same upstream series (6.1.x), and should have basically the same feature
set, with no major changes.
The "13" is the ABI (Application Binary Interface) identifier. This
gets incremented each time the kernel's internal structures change in
a way that would require kernel modules to be recompiled.
And finally, the "-amd64" part is the architecture.
Next, look at the package version string: 6.1.55-1
The "6.1.55" part is the upstream release number. In this case, this
is the 55th point release in the upstream 6.1.x series.
The "-1" indicates that this is the first Debian package built from
this upstream release, by the Debian kernel image maintainers.
Now, let's say a major bug is found in this kernel, and the maintainers
decide to release a new kernel package built from the same upstream
source, but with a fix. Depending on the changes they make, one of two
things can happen:
1) If the fix doesn't require an ABI change (old modules can be loaded
by the new kernel), then they only have to increment the package
version number. So they'll release package linux-image-6.1.0-13-amd64
version 6.1.55-2. (Or if it were the security team doing it, then
the version number would be something like 6.1.55-1+deb12u1 instead.)
2) If the fix requires an ABI change, then a new package name has to
be created. In this case, they'll release a new package
linux-image-6.1.0-14-amd64 with version 6.1.55-1 (or something
like 6.1.55-0+deb12u1 maybe, although the security team is much
less likely to invoke an ABI change).
In practice, though, new kernel images are most likely to be released
after a whole bunch of upstream point releases have occurred, and
will roll up all of those upstream changes into one gigantic change.
So we would most likely jump from linux-image-6.1.0-13-amd64 version
6.1.55-1 to linux-image-6.1.0-14-amd64 version 6.1.72-1 (or something
along those lines). Because so many changes get amalgamated together,
it's vanishingly rare for the ABI counter *not* to increment.
