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

[Andrew Gregory]

On 08/24/20 at 11:22am, Allan McRae 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.

I'm still a bit skeptical.  I can't say I'm particularly familiar with
fonts and their configuration, but is there really a valid use case
for that kind of per-package configuration that we need to support?

More abstractly, I'm not fond of how much this ties packages together.
One of the ideas of hooks was for the package that does the work to
handle all of the necessary details so the triggering packages
wouldn't have to worry about it.  With this approach, they not only
have to know to adjust the hook, they also have to know the name of
the hook and how the hook works.  Changes to the hook then require an
adjustment and rebuild of any package modifying it.  This is not an
entirely new problem, user overrides are also dependant on hook
naming, but this does exacerbate it in a way that I think will be easy
for packagers to miss and cause breakage.

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.