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

[Allan McRae]

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