[pacman-dev] [PATCH] [RFC] alpm: Add a new hook type: PackageDir

[Andrew Gregory]

On 12/31/15 at 08:38pm, Olivier Brunel wrote:
> Same as Package only instead of defining matching packages in the .hook file, it
> is done on the filesystem.
> 
> Signed-off-by: Olivier Brunel <jjk at jjacky.com>
> ---
> Hey there,
> 
> So I may be totally wrong, but I thought one of the cool things that could be
> done with hooks was that instead of having e.g. 3 packages refreshing a cache in
> their post_upgrade scriptlets, it'll be done via one post-transaction hook, so
> that it only runs once.
> 
> And unless I'm missing something, this doesn't seem possible currently. At
> least not in a "good" way, since all matching packages must be included inside
> the .hook file itself.
> 
> So am I wrong and was this never planned? Or is actually possible? Or is it
> meant to be added later?
> 
> In case, here's a patch (though no documentation) that adds a new type of hooks:
> PackageDir
> 
> Those are just like Package (and in fact turned into Package once
> validated/filled), only no targets should be featured inside the hook
> file itself, instead alpm will check for a directory by the hook name plus ".d"
> inside all the hookdirs (in order), so e.g. for hook "foobar" folders
> "foobar.d" will be looked for.
> 
> Inside those dirs, a regular file means a target to add, said target being the
> name of the file. So files must be named after the packages to add/trigger the
> hook. A symlink however will mean to remove said package from the targets; The
> idea being that a user could create a symlink (to /dev/null) in e.g.
> /etc/pacman.d/hooks/foobar.d by the name of a package, to "undo"/mask a file by
> the same name in /usr/lib/alpm/hooks/foobar.d, file that could be part of any
> (other) package.
> 
> That way, the font package provides the hook font-cache and any package that
> needs to trigger it simply adds an empty file to
> /usr/lib/alpm/hooks/font-cache.d by the name of the package.
> Also works for mkinitcpio providing a hook to rebuild the initramfs, which can
> then be triggered by any of e.g. mkinitcpio, linux, systemd, etc
> 
> Thoughts?
> -j

Why is this preferable to just using a File target:

 [Trigger]
 Type = File
 Operation = Install
 Operation = Upgrade
 Operation = Remove
 Target = usr/share/fonts/*
 
 [Action]
 When = PostTransaction
 Exec = /bin/fc-cache --system-only --force

apg