Ohai,

since some time, dkms started to archive existing modules if you install
a <something>-dkms package that ships an updated version of the module,
for example tp-smapi-dkms shipping hdaps.ko

This leads to the fact that once tp-smapi-dkms is installed, debsums
(and thus piuparts [1]), complains that the linux-image package is missing
a file (which is technically correct, dkms moved it away):

root@system:~# apt install tp-smapi-dkms
…
Installing /lib/modules/6.12.33+deb13-amd64/updates/dkms/thinkpad_ec.ko.xz
Installing /lib/modules/6.12.33+deb13-amd64/updates/dkms/tp_smapi.ko.xz
Found pre-existing /lib/modules/6.12.33+deb13-amd64/kernel/drivers/platform/x86/hdaps.ko.xz, archiving for uninstallation
Installing /lib/modules/6.12.33+deb13-amd64/updates/dkms/hdaps.ko.xz

root@system:~# debsums --silent
debsums: missing file /usr/lib/modules/6.12.33+deb13-amd64/kernel/drivers/platform/x86/hdaps.ko.xz (from linux-image-6.12.33+deb13-amd64 package)

Given dkms (on Debian) installs modules to …/updates/dkms/
(so /lib/modules/6.12.33+deb13-amd64/updates/dkms/hdaps.ko.xz), modprobe
should use that module and not the in-kernel one anyway, and no
archiving should be necessary?

I think this behaviour is coming from [2], but didn't dig deep further
to try it out.

[1] https://piuparts.debian.org/sid/fail/tp-smapi-dkms_0.44-1.2.log
[2] https://github.com/dell/dkms/commit/5889b900916cb6441c6ab94a026a20b7fcc9c71c