Okay, its been pointed out to me its been replaced by a hook. It seems like the hook did not trigger for linux-grsec, however.

What does "did not trigger for linux-grsec" mean?

Looks like the trigger works, in the sense that doing this does trigger dkms.

# bash -x /usr/lib/dkms/alpm-hook install
+ (( EUID ))
+ (( 1 < 1 ))
+ source_tree=/usr/src
+ dkms_tree=/var/lib/dkms
+ install_tree=/usr/lib/modules
+ source /etc/dkms/framework.conf
+ shopt -s nullglob
+ read -r path
usr/lib/modules/4.4.2.201602182048-1-grsec/
+ [[ /usr/lib/modules/4.4.2.201602182048-1-grsec/ =~ ^/usr/src/([^/]+)-([^/]+)/dkms\.conf$ ]]
+ [[ /usr/lib/modules/4.4.2.201602182048-1-grsec/ =~ ^/usr/lib/modules/([^/]+)/ ]]
+ pushd /var/lib/dkms
+ for mod in '*/*/source'
+ dkms install -m broadcom-wl/6.30.223.248 -k 4.4.2.201602182048-1-grsec

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area...
make KERNELRELEASE=4.4.2.201602182048-1-grsec -C /usr/lib/modules/4.4.2.201602182048-1-grsec/build M=/var/lib/dkms/broadcom-wl/6.30.223.248/build...
...


However, with pacman -S linux-grsec (either reinstall or uninstall/install), I see this in the debug output:

debug: parsing hook file /usr/share/libalpm/hooks/70-dkms-remove.hook
debug: parsing hook file /usr/share/libalpm/hooks/70-dkms-install.hook
debug: unregistering database 'local'

Which makes me suspicious that the hook isn't triggering

Do you have the headers installed for it? That's going to be what triggers it.

Okay, so not a bug:

- The package is obviously wired up against the headers package. I misread the trigger. Reinstalling linux-grsec-headers did retrigger the dkms build.
- I guess this might have arose from the order in which I upgraded packages.

I missed the message inside the install hook, sorry for the noise.