Re: Upcoming changes to Debian Linux kernel packages
On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can
> > also
> > switch back to the still installed older kernel version and it will
> > have
> > the still working module available.
>
> This is what I expect not to work.
>
> Assume I have Linux 6.6 and a third-party gpu driver module installed
> (so there are dkms and the Linux 6.6 headers as well) and everything
> is
> working fine.
> Then I upgrade the system, which brings Linux 6.7 (along linux-image-
> 6.6
> which is kept installed) and a new version of the gpu driver (which
> adds
> support for 6.7). So the old gpu module for 6.6 gets removed and a
> new
> one is built for 6.7 only (since there are only 6.7 headers now).
> Unfortunately 6.7 breaks some exotic in-tree driver (which I
> desperately
> need), so I need to go back to 6.6. Oops, there is no gpu driver
> module
> any more. Recovery now needs manual intervention.
Same concern here. We cannot pose strong assumption on the user's
upgrade path. The said scenario may happen for any dkms package
when the newer kernel version is not supported.
> I'm not sure which class of bugs you are trying to solve with this
> proposed unversioned linux-headers change. IMO the current scheme of
> linux-headers-$version-$abi-$flavor matching
> linux-image-$version-$abi-$flavor works well. But perhaps something
> could be improved on the metapackage side. Ideally a user should
> install
> either meta-linux-image-without-headers-$flavor OR
> meta-linux-image-with-headers-$flavor (and ideally installing dkms
> should "automatically switch" to the with-headers variant, not sure
> how
> this could be done). The current scheme of having to install
> linux-image-$flavor AND linux-headers-$flavor is a bit tricky.
> I'm open to implement improvements on the dkms side.
I could not understand the benefit of it neither. Apart from the dkms
part, the user-customized kernel packages cannot be omitted as well.
For instance, if I build a customized kernel from debian's kernel
source, using `make bindeb-pkg`, I get those:
linux-headers-6.5.3_6.5.3-2_amd64.deb
linux-image-6.5.3_6.5.3-2_amd64.deb
linux-libc-dev_6.5.3-2_amd64.deb
Currently they are well integrated into the system, and IIRC dkms
also works for them. If versioning is gone, how to make it
compatible with user's local kernel package? There must be two
copies of kernel headers in the system in this case because we
cannot remove user's local customized headers on our own.
Then the design still has to support multi version co-existence.
Reply to: