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.
