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

[Olivier Brunel]

On Thu, 31 Dec 2015 14:54:53 -0500
Andrew Gregory <andrew.gregory.8 at gmail.com> wrote:

> 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

Yeah I thought of that, so that was a bad example on my part as for such
caches that is fine indeed. But for things like e.g. rebuilding the
initramfs, where there might not be such a file criteria, it wouldn't
be possible. Or is that just a lone exception (that won't work with
hooks) ?