Makefile: fix extension of kernel-install plugin

[Nowa-Ammerlaan]

According to the kernel-install manual plugins need to have the .install extension, otherwise they are ignored:

kernel-install will run the executable files ("plugins") located in the directory
/usr/lib/kernel/install.d/ and the local administration directory /etc/kernel/install.d/. All files
are collectively sorted and executed in lexical order, regardless of the directory in which they
live. However, files with identical filenames replace each other. Files in /etc/kernel/install.d/
take precedence over files with the same name in /usr/lib/kernel/install.d/. This can be used to
override a system-supplied executables with a local file if needed; a symbolic link in
/etc/kernel/install.d/ with the same name as an executable in /usr/lib/kernel/install.d/, pointing
to /dev/null, disables the executable entirely. Executables must have the extension ".install";
other extensions are ignored.

[evelikov]

Thanks for the PR. How did you notice the issue?

While I agree we should follow the documentation, I'm weary about regressions. Can you check and provide some references that this won't cause (m)any issues and/or that distros are already renaming the file.

For example: Arch does not install the files, as it can be seen from the package contents

[Nowa-Ammerlaan]

Thanks for the PR. How did you notice the issue?

Installing a new kernel did not automatically trigger the rebuilding of dkms modules. Of course after rebooting the systemd service still takes care of this, so not a huge problem.

• Fedora (and by extension anything based on it) at least are already working around this, they have a 40-dkms.install in /usr/lib/kernel/install.d. You can download the rpm from here to see what they are installing: https://koji.fedoraproject.org/koji/buildinfo?buildID=2195311

• Debian/Ubuntu do not appear to rename the file, but they might have some other mechanism in place to trigger dkms when the kernel package gets updated.

For example: Arch does not install the files, as it can be seen from the package contents

• Yes, Arch seems to be relying on the pacman hooks to achieve the same functionality (kernel gets installed, dkms gets triggered). Note that making the change in this PR won't break anything because I'm pretty sure Arch does not use the kernel-install command to install the kernel in the first place.

• Gentoo (which I maintain a dkms package for) does not rename the file (yet). The impact of the issue is low so I decided to not adjust the ebuild with a temporary workaround and instead just fix it upstream and wait for the next release.

In fact, AFAIK it is pretty uncommon to use the kernel-install command (which should then call this plugin) except on source based distributions like Gentoo or when installing a kernel manually (kernel-install gets called when running the kernel's make install). So the impact of the issue here is low, nonetheless it is very easy to do it properly and make this work as it was intended.

Worst case scenario you end up running dkms twice, the second time won't do anything since dkms will find that the modules are already installed and skip.

KCONF = $(DESTDIR)/etc/kernel

By the way, technically this should really be KCONF = $(DESTDIR)/usr/lib/kernel. /usr is where packages and default configurations are installed. /etc is for configuration and scripts managed by the system administrator. Note that making this change will also not break anything since both directories are checked by kernel-install, it is important however to prefix the plugin file with some two digit number to control the order in which the plugins are executed. Currently the dkms plugin is executed last because /etc/kernel is run after /usr/lib/kernel, so to retain this behaviour a suitable number could be 95. Not that it really matters because dkms is all about modules and not the kernel itself so it will work fine in any order.

andrew-gentoo-laptop andrew # ls /usr/lib/kernel/install.d
00-00machineid-directory.install  50-depmod.install  50-dracut.install  51-dracut-rescue.install  90-loaderentry.install  90-uki-copy.install

[evelikov]

Looking at Fedora it has an extra install snippet although the commit message is bit short.

    install -p -m 644 -D kernel_install.d_dkms \            
                %{buildroot}%{_prefix}/lib/kernel/install.d/40-%{name}.install

@scaronni you seem to be the author, do you recall what inspired that change? Do you think it's safe for us to step even further and use 40-dkms.install as per your Fedora patch?

@anbe42 can you have a quick check this won't break any Debian tooling? At a glance I could not spot any.

[scaronni]

Looking at Fedora it has an extra install snippet although the commit message is bit short.

    install -p -m 644 -D kernel_install.d_dkms \            
                %{buildroot}%{_prefix}/lib/kernel/install.d/40-%{name}.install

@scaronni you seem to be the author, do you recall what inspired that change? Do you think it's safe for us to step even further and use 40-dkms.install as per your Fedora patch?

Sorry can't really remember, it's 3 years and 4 months since that was applied. If I'm not mistaken somone pointed out in a bug that was needed to be installed to make it work.

I inherited an abandoned DKMS package in Fedora/EPEL and as well an almost abandoned repository in Github around the same time, too much has passed since.

[anbe42]

I don't think this file (although we ship /etc/kernel/install.d/dkms) is used at all in Debian. The linux-image-* maintainer scripts use run-parts (from package debianutils) to run scripts from /etc/kernel/{pre,post}{inst,rm}.d/ and there is no corresponding location in /usr.

[Nowa-Ammerlaan]

Alright I changed the commit to install the plugin as is done in Fedora (/usr/lib/kernel/install.d/40-dkms.install). 40 will cause the dkms plugin to run before dracut (which is 50), probably this is a good idea in case we want to include dkms modules into the dracut initrd.

[anbe42]

It's very unusual to have $(DESTDIR) embedded in the $(FOODIR) variables.
Usually an install targets looks more like this:

FOODIR = /usr/foo/bar
install:
        install -d $(DESTDIR)$(FOODIR)
        install some.file $(DESTDIR)$(FOODIR)

and can be customized via make install FOODIR=/usr/local/foobar or make install DESTDIR=/tmp/installroot (or both)

[evelikov]

It's very unusual to have $(DESTDIR) embedded in the $(FOODIR) variables.

Indeed, which is why I unintentionally misled Andrew for a moment.

Thank you for the MR and patience Andrew 🙇

[Nowa-Ammerlaan]

🥳 It was a slightly mutually confusing ride, but we got there in the end. Thanks for merging!