So looking at general usefulness, I think it mostly comes down to two things: - Selectively disable triggers for existing packages. This would require packages to switch to drop-in based triggers which the user can then override or an additional patch would be needed to allow a negative glob in another trigger to override a normal glob in a previous trigger. So if a package has a glob /* trigger and a drop-in trigger has a glob !/usr/* trigger, those would combine to search everything except /usr. I'm not sure if we want to allow triggers to influence each other though. I'm guessing this is not possible today and it might require some changes to get this work if triggers are currently architected to be independent of each other (which might very well be a good thing to keep things simple). - Add triggers for additional directories/files to packages This is useful for NeedsTargets based triggers since you can pass additional targets to the hook and if the hook can deal with those extra targets, dropping in new directories/files for the hook to work on becomes really easy. It can also be useful for hooks without NeedsTargets if aside from the added trigger, you also configure the extra directory to work on in a configuration directory for the package somewhere. So for the font cache example, you could add the extra directory somewhere to a configuration file of the program that builds font caches and add a trigger drop-in for that extra directory to the pacman hook as well and things should just work. If the font cache builder program works with NeedsTargets, you only need to add the trigger and it should just work. One thing to be aware of with this approach is that we might not want to encourage adding extra directories like this to search for files. At least in systemd and Arch Linux, the preference is to use store files in a fixed set of directories instead of adding new directories all over the place. If the idea is to store files in existing directories, making it easy to use alternative directories might not be something we want to do. Then again, this is rather specific to my experience with systemd/Arch. pacman might be used in other scenarios where doing this is perfectly valid and encouraged. Daan On Mon, 24 Aug 2020 at 02:22, Allan McRae <allan@archlinux.org> wrote:
Lets take a step back here...
I don't really care about the kernel use case, but more whether this could be more generally used. Here are other examples I came up with.
Font caches: A package could drop a config file in /etc/font/conf.d/ to add another directory that is to be used when building font caches. They would also want to add a .trigger file for the hook.
OK... I just came up with one other example! But I did not look too hard at what hooks on my system actually do.
Back to the question of whether we support this. A quick skim of the patch shows me it is quite long, but relatively simple. (it seems to be doing more than just adding .trigger support - also adding drop in directories - and this seems two patches to me...)
So, I am leaning in the direction of this being a useful addition.
Further discussion of the usefulness should not focus around the kernel approach, but rather the general idea of the feature.
Allan