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

[Allan McRae]

On 31/8/20 6:23 am, Andrew Gregory wrote:
> On 08/24/20 at 10:34pm, Daan De Meyer wrote:
>>> What about adding Include support to hooks?  Then hooks that need this
>>> type of functionality could explicitly include trigger files from
>>> a particular directory, insulating the process from simple hook
>>> renaming and hopefully making it more obvious when changes to the hook
>>> will require changes to any package that modifies it.
>>
>> Just to make sure I understand correctly, does Include support imply
>> that hooks opt in to reading triggers from a specific directory and
>> that we can rename the hook itself without changing the drop-in
>> directory for that hook to avoid breakage? If so, that sounds totally
>> reasonable and even preferable since it also avoids packages adding
>> triggers to hooks that can't deal with extra targets when NeedsTargets
>> is used. I can adapt the patch to use this approach.
>>
>> Do we pass a full path to Include or just a directory name? The
>> advantage of just a directory name is that it could be created in any
>> of the hook directories (hook installed in /usr/share/libalpm/hooks
>> and the added triggers in /etc/pacman.d/hooks/<directory> for
>> example). It doesn't necessarily have to be just a directory name, we
>> could interpret it as a relative path and you could still put it in
>> each of the hook directories but that might just be adding too much
>> complexity.
> 
> Include should take a glob, just like pacman.conf.
> 

I'm trying to figure out how includes would address this problem.

We have a hook that runs when its triggers are met.  We want to have a
package add additional triggers, by dropping in a file into our config,
but do not want to duplicate the function of the hook, or to directly
edit the hook.  An Include would provide a place where we can drop more
config files with (e.g.) more triggers, but that requires the original
hook to be set up such that it is extendable.  Just adding additional
triggers does not require the original hook to do anything.


Now, just writing as I think here, so don't take this as a good idea...
Unless a hooks name defined their include directory?   I.e.
fontconfig.hook would include fontconfig.d/* automatically.


Long story short, I'm not sold on how Includes would work!

Allan