Bug#1040901: Upcoming changes to Debian Linux kernel packages

Moin

On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key

This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.

> ## Image packages contains more version info
> 
> Example: linux-image-6.5.3-cloud-arm64

> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.

I missed that apt does something similar (maintainers cced).  It wants
to see if a particular package matches the current kernel to make the
autoremove prevention work.  That lookup is quite a hard problem.

What should work:  We define a new control field.  It contains both the
kernel name and a version prefix. 

Example:
- Linux 6.6 (would match 6.6-1, 6.6.1-1)
- Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
- Linux 6.6.3+2

The algorithm would be something like this:
- Check $(uname -s) against the first word.  Otherwise completely
  ignore.
- Check if $(uname -r) matches the version prefix in this field.  Mark
  as keep if it matches.
- Aggregate packages by version prefix.
- Sort as version, keep newest two(?).

This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.

Counter proposal: Use see the kernel release as debian version and match
on the upstream version.  But then we need to re-define what we put into
the kernel release field.  In 6.6.1-1-cloud-arm64, the upstream version
is 6.6.1-1-cloud, not 6.6.1 as we would need.  We could of course change
that to: 6.6.1-1~cloud+arm64.  That should always sort correctly in
regard of the package version.

> ## Header and tool packages will not longer contain version

This is obsolete with the counter proposal of a meta package that always
pulls in image and headers of the same version.

Regards,
Bastian