On Sat 18 Nov 2023 at 15:29:51 (+0100), steve wrote: > 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.
I used the term flavour, to encompass the variety within the i386 architecture: {3,4,5,6}86[-pae][-smp] and so on. I don't follow other architectures enough to know whether a similar variety exists elsewhere. > > 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.) We saw that happening in July with linux-image-5.10.0-23-amd64 (bullseye), when there were three versions (sources 5.10.179-{1,2,3}) in use over a period of 12 weeks (6 CVEs). > > 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. > > Thanks Greg for the precise explanation. I would suggest to put it in the > Debian Wiki for futur reference. Cheers, David.