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

On Fri, 1 Jan 2016 09:51:55 +1000 Allan McRae wrote:

On 01/01/16 06:08, Olivier Brunel wrote:

...

On Thu, 31 Dec 2015 14:54:53 -0500 Andrew Gregory 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 --- 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