Adjust installation for Red Hat based distributions

[scaronni]

Fix for cleaning up the kernel modules when a kernel is uninstalled

The trigger for the removal of DKMS modules in Red Hat based distributions happens when the kernel-core package is removed. That package contains no modules, so also the modules.dep is already gone at the moment of the trigger.

This makes the check for unbuild fail because the main DKMS script is not able to get the compression method used for the modules from the modules.dep file. So get the compression method by looking at modules in the kernel folder, which can either be distribution provided modules or the remaining DKMS modules when the distribution modules have disappeared already.

Reduce installation scripts and redirects

Red Hat based systems using kernel-install from systemd, do not use the prerm.d and postinst.d folders.

So instead of lots of redirects and links, use a different /usr/lib/kernel/install.d/40-dkms.install file on Red Hat based systems that is much simpler and self contained and drop all these files and folders:

/etc/kernel/postinst.d/
/etc/kernel/postinst.d/dkms
/etc/kernel/prerm.d/
/etc/kernel/prerm.d/dkms
/usr/lib/dkms/
/usr/lib/dkms/common.postinst
/usr/lib/dkms/dkms_autoinstaller

Other small stuff

Remove the executable bit from include files in the repositories, reduce the scope of the rm commands during make clean.

[scaronni]

Thanks!

[iamandrii]

Hello, what was the reason to delete file /usr/lib/dkms/common.postinst?

We used this file in our postinstall phase in order to notify dkms about kernel module that we supply.

Now it is removed, and I do not understand correctly the reason behind this in the scope of the PR. Looks like it was a mistake?

[scaronni]

Hello, the file has not been deleted, just not installed anymore with the install-redhat target as I know it's pretty entangled in some Debian packages. The same functionality can be achieved with:

%post
dkms add -m %{dkms_name} -v %{version} -q --rpm_safe_upgrade || :
# Rebuild and make available for the currently running kernel:
dkms build -m %{dkms_name} -v %{version} -q || :
dkms install -m %{dkms_name} -v %{version} -q --force || :

%preun
# Remove all versions from DKMS registry:
dkms remove -m %{dkms_name} -v %{version} -q --all --rpm_safe_upgrade || :

I can also add it back, that's not an iusse, but I think it's pretty redundant.

I've looked at the issues linked there and I have the impression the SPEC files are a bit too complicated in that regard. Is there any reason why you can't use the above snippet? Thanks.

[scaronni]

@iamandrii maybe I was not clear enough, but I think you can replace your entire %post and %preun/%postun sections for the DKMS module with the snippet I pasted.

[iamandrii]

Hello, @scaronni.

Thank you for the snippet provided, for now I've just included workaround to work with the change (I am a bit worried about impact on older versions of DKMS, I have to investigate that first).

In general, I was concerned about the change at all, because as far as I understand, common.postinst was so-called "safe API" for all of the systems and all of the DKMS configurations. Now this was changed, and I guess a lot of .spec files might be broken as a result of the lack of the file.

IMHO, in case of such a changes it would be better to provide something like a placeholder file that only does the three commands you mentioned, as it would prevent unwanted breaks.

[scaronni]

Thank you for the snippet provided, for now I've just included workaround to work with the change (I am a bit worried about impact on older versions of DKMS, I have to investigate that first).

That script just calls dkms commands, so you can just call the commands instead,

IMHO, in case of such a changes it would be better to provide something like a placeholder file that only does the three commands you mentioned, as it would prevent unwanted breaks.

It has been readded.