[pacman-dev] Hooks for pacman

[Dan McGee]

On Thu, Jan 22, 2009 at 6:51 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Thu, Jan 22, 2009 at 6:29 PM, Allan McRae <allan at archlinux.org> wrote:
>> Aaron Griffin wrote:
>>>
>>> On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <allan at archlinux.org> wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>> A new feature I am ever so slightly obsessed about at the moment is the
>>>> possibility of having hooks in pacman for doing common tasks in install
>>>> files.  e.g.  adding info pages to directory, updating font/icon/.desktop
>>>> cache, gconf stuff...
>>>> So, how would this be implemented?   Here is my outline:
>>>>
>>>> Two types of hooks would be needed for both install and remove.  One type
>>>> that is run for every matching file (e.g. info install) and one type that
>>>> is
>>>> run once per transaction (e.g. font cache update).  These could be stored
>>>> in
>>>> /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf.
>>>>  The .conf file could look something like:
>>>>
>>>> [add]
>>>> PerFile = infopage    /usr/share/info/
>>>> PerTrans = fontcache    /usr/share/fonts/
>>>>
>>>> [remove]
>>>> ...
>>>>
>>>> That needs improvement, but that covers the information that needs
>>>> presented
>>>> - whether the hook is run per file or per transaction, the name of the
>>>> hook
>>>> and the directory whose files set off this hook.  Maybe the conditions
>>>> that
>>>> set the hook off should be in the actual hook file.
>>>>
>>>> I guess the actual hook would look look just like:
>>>>
>>>> hook()
>>>> {
>>>> do stuff here...
>>>> }
>>>>
>>>> I figure we must already generate a list of all the files being
>>>> added/removed during conflict checks, so we would "just" need to scan
>>>> that
>>>> list for what hooks need to be run and actually run them.
>>>>
>>>> Anyway, I thought I would post this idea here so I could get more
>>>> feedback
>>>> on the implementation and maybe convince someone to code it...
>>>>
>>>
>>> This is much better than the ideas Dan and I fleshed out last time we
>>> talked about this. One or two nitpicks, though:
>>>
>>> a) [add] and [remove] seem to simple. How about [AddHooks] and
>>> [RemoveHooks]?
>>> b) It'd be nice to use fnmatch patterns (globs) for the file paths.
>>> c) Instead of a function, it makes more sense to just make a script
>>> that takes the files as args, and only run it if it is executable
>>> (assume -x is disable)
>>> Other than that, I really like the PerFile and PerTrans distinction.
>>>
>>
>> All good suggestions.  I went for the function idea so I could reused code
>> for running install scripts.  I have never look at that code so I don't know
>> whether that would be a good or bad idea.
>
> The code simply runs bash and does the following:
>   . /my/install/scriptlet; post_install $version
>
> Note the dot and semicolon are newer. The previous code didn't have it
> - thus the reason why you see the "op=$1" malarky in older scriptlets.
>
>> Thinking about this some more, per transaction hooks really only need ran
>> per transaction...   I.e. there is probably no need for the distinction
>> within [AddHooks] of PerFile and PerTrans.  All the examples I used for run
>> once hook will look the same for both add and remove.   Instead, we could
>> have [AddHooks], [RemoveHooks] and [TransHooks].
>
> That's a good point - the per-transaction hooks are probably able to
> handle added AND removed files. If not, it is a bash script, so i'm
> sure something could be done. Worst case scenario, a very complex hook
> could use all three - write some info to a temp file on add or remove,
> then use the file in the trans hook.
>
>>> When modifying the config parsing, can you ensure 'Include' works
>>> here? That would allow us to ship some stock hooks for info files and
>>> the like, and users would simply include them.
>>>
>>
>> Can you provide an example of what you think the config would look like.   I
>> have a fair guess at what you mean but clarification would be good.
>
> [AddHooks]
> Include = /etc/pacman.d/hooks/gnome-hooks
> ...
>
> # gnome-hooks
> PerFile = mime-database-stuff
> PerFile = scrollkeeper-stuff
> PerFile = update-desktop-db
>
> I guess with the removal of PerFile/PerTransaction, this gets a little
> more weird... perhaps we could allow multiple sections of the same
> name to add to the previous one. That is:
>
> [AddHooks]
> something
>
> Include = /etc/pacman.d/hooks/gnome-hooks
> ...
>
> #gnome-hooks
> [AddHooks]
> above-gnome-stuff
>
> [RemoveHooks]
> more-stuff

Let's get this in a wiki, I think that is a great idea to get it
hashed out and make sure we aren't forgetting about certain scenarios.

Overall this seems like a workable approach.

-Dan