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

[Daan De Meyer]

One idea is that we don't need to necessarily do this with includes.
We could simply add an option (e.g. EnableDropinDirectories) that
enables the drop-in directories for a particular hook. It doesn't
account for renaming the hook but in my opinion, I don't think that
will be a massive issue in practice.

Daan

On Sat, 5 Sep 2020 at 02:31, Andrew Gregory <andrew.gregory.8 at gmail.com> wrote:
>
> On 09/04/20 at 12:22pm, Allan McRae wrote:
> ...
> > 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.
>
> Requiring the hook to opt-in to this behavior is the point.  Once you
> make a hook extensible, making any changes to that hook become much
> more difficult because those changes could render any extensions
> useless, and the hook author doesn't have any way to know if anything
> else is depending on the current implementation.  Requiring the hook
> to opt-in gives the author a way to indicate that the hook is suitable
> for extension and won't change in a way that breaks those extensions
> in the future.  Essentially we're allowing a hook to choose to provide
> a public interface instead of automatically doing it for all hooks.
> And, of course, the fact that we already have code to deal with
> Includes is a nice plus.