Remove ability to symlink kernel modules

[wesbarnett]

Given the complications the option to symlink old kernel modules brings brings, I think I may just remove this capability altogether (see #21 and #19). In reality, these symlinks can be created by their own hook. For example:

[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Package
Target = linux

[Action]
Description = Symlinking old kernel modules...
When = PostTransaction
Exec = /usr/bin/bash -c "ln -sv /.snapshots/$(snapper -c root list | awk '/pre/ { print $3 }' | tail -n 1)/snapshot/usr/lib/modules/$(uname -r) /usr/lib/modules/"

Then the user would need to periodically cleanup the symlinks in /usr/lib/modules. This could be done via another hook, added to this hook, a systemd unit, or a systemd timer.

The command to delete all symlinks in /usr/lib/modules would be:

find /usr/lib/modules -maxdepth 1 -type l -delete

The command to delete only broken symlinks would be:

find /usr/lib/modules -xtype l -delete

[ckotte]

If you don't want to have an additional dependency to systemd, then a PostTransaction hook that is executed first at all times, to avoid the issue with DKMS modules re-build (#21), would be good.

However, it's annoying that I have broken symlinks from the old kernel in /usr/lib/modules that eventually point to nowhere since the snapshot was deleted by number cleanup. Therefore, I would prefer a systemd service that's executed on every reboot to clean any symlink to a snapshot in /usr/lib/modules.

[wesbarnett]

pacman will find the file conflicts and abort a transaction before the pre hooks are even executed, so that is not a solution to file conflicts unfortunately. That's why I'm thinking this package shouldn't even be touching /usr/lib/modules and users can create their own pacman hooks and systemd services based on the example above.

[AtosNicoS]

It would be nice if you can put the hook inside the readme or in the repository, so other can use them real quick :) I think this is a useful idea!

[wesbarnett]

Yes, I will do that. That way users can have more fine-grained control on their exact system.