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

[Daan De Meyer]

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

Daan

On Mon, 24 Aug 2020 at 22:18, Eli Schwartz <eschwartz at archlinux.org> wrote:
>
> On 8/24/20 4:21 PM, Andrew Gregory wrote:
> > 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?
>
> I kind of agree, because while it's true font conf files can add new
> search paths it's also not unreasonable to just use one unified path, as
> fontconfig already recursively searches there and you can organize fonts
> by subdirectory.
>
> Nevertheless, thanks Allan for mentioning it, because I really wanted to
> know if this could be suitably generic for non-kernel use and this gives
> a much better framework for discussion...
>
> > 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.
>
> I think you're right and Include support would be a better way to go here.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>