Forgot to change the category to Package: Core.

It's completely broken to call pacman itself from an install hook, even for a local DB query.

@Dave - can you elaborate a bit? I see other lines in linux.install that do just this. For example in the post_upgrade function.

pacman might not even work in the middle of an upgrade. We statically compile vercmp against libalpm explicitly to avoid this sort of thing. The sort of cautionary messages that pacman is used to generate is crap for other reasons (why no syslinux, or burg, or <insert other bootloader>).

The name of the dkms package might change, or there could be some other provider (dkms-git?). You're about to call a binary called dkms, so check for a binary available called dkms.

if type -p dkms >/dev/null; then
dkms -k autoinstall $KERNEL_VERSION
fi

That said, I don't think this crap has any place in an install scriptlet.

@Dave - thanks for the clarification. If not in an install scriptlet, where do you feel it would be appropriate?

Updated patch per Dave's suggestion.

I don't like adding stuff to .install file. Thomas your opinion on this?
We don't check on mounted boot nor do we run lilo out of there.

@Dave: Thanks for the suggestions. I can see calling pacman within a .install to be problematic, but my patch was based on the fact that the existing .install calls pacman.

@John: thanks for the feature request and for updating the patch. I felt a further change to ignore errors from dkms would make this more robust. Just to ensure the kernel install never fails due to this. I've attached an updated patch.

Bump. Can you kindly include this? I have tested this and it works fine for me (including a scenario where dkms build failed, but the kernel install wasn't affected).
In my opinion, this patch puts dkms to its proper use.

I will not add this. The install file should be as clean as possible.

Thomas said pacman should implement this and not the kernel.install file.
Closing as won't implement please open a new task against pacman.