[pacman-dev] [PATCH v4] libalpm: Add support for trigger dropins

Daan De Meyer daan.j.demeyer at gmail.com
Mon Aug 24 11:11:09 UTC 2020


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 at 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


More information about the pacman-dev mailing list