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

[Olivier Brunel]

On Fri, 1 Jan 2016 09:51:55 +1000
Allan McRae <allan at archlinux.org> wrote:

> On 01/01/16 06:08, Olivier Brunel wrote:
> > 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) ?  
> 
> Can you give a concrete example of something that can not be done
> with a File hook but could be done with this approach?
> 
> e.g. for the initramfs example, what would change on the filesystem to
> cause the need for a rebuild that can not be captured by the File
> hook?
> 
> A

Well, basically it seemed to me that Package hooks were really only
useful for user-made hooks, not hooks from packages. And, I thought
there could be cases where a hook is provided by a package, but would
work as a Package hook, only then it's not really making sense, and
that's where this PackageDir type would be handy.

For example with the initramfs, which is what I had in mind, one could
think it'd make sense to rebuild the initramfs when systemd is updated.
But why? How do you do your File hook? Only udev-related? Or also other
files for those who actually have systemd inside their initramfs?
I thought for such cases, going by package name was the way to
go/easier. Not to mention it allows the user to add/remove packages
from the triggering list.

Another example, maybe one uses the encrypt hook (encrypted rootfs) and
would like to rebuild the initramfs when crypsetup is updated. So this
isn't from a package, but a user, but with a PackageDir it's easy to
do: touch /etc/pacman.d/hooks/mkinitcpio.d/cryptsetup

-j