On Sat, 2022-12-24 at 19:31 +0100, Sedat Dilek wrote:
[...]
> root# LC_ALL=C ll /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
> -rwxr-xr-x 1 root root 19K Dec 24 08:04
> /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
>
> root# LC_ALL=C dpkg -S /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
> dpkg-query: no path found matching pattern
> /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
>
> ...which packages is shipping sign-file?
>
> OK, looks like you need kbuild-6.1 package, too.
>
> root# cd /var/cache/apt/archives
>
> root# dpkg --contents linux-kbuild-6.1_6.1.1-1~exp2_amd64.deb | grep sign-file
> -rwxr-xr-x root/root 18920 2022-12-24 08:04
> ./usr/lib/linux-kbuild-6.1/scripts/sign-file
>
> Might be good to have this as a Depends for linux-image (unsigned) and
> why is `dpkg -S /path/to/sign-file` not showing the responsible
> package?
[...]
linux-image shouldn't depend on linux-headers etc. as that would pull
in a lot of big packages that are completely unnecessary for users that
don't use OOT modules.
"dpkg -S" is easily confused by symbolic links.
We provide the linux-headers-<flavour> metapackages to make it easy to
get the new kernel headers and rebuild OOT modules. By using
"APT::Get::Upgrade-By-Source-Package=0" you prevented APT from
upgrading linux-headers-amd64 together with linux-image-amd64. Maybe
DKMS should have done a better job of reporting this, but it's really
your mistake.
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
Attachment:
signature.asc
Description: This is a digitally signed message part