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 -- Without followers, evil cannot spread. -- Spock, "And The Children Shall Lead", stardate 5029.5
