[pacman-dev] Hooks for pacman
dpmcgee at gmail.com
Thu Jan 22 22:04:30 EST 2009
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
>>>> run once per transaction (e.g. font cache update). These could be stored
>>>> /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf.
>>>> The .conf file could look something like:
>>>> PerFile = infopage /usr/share/info/
>>>> PerTrans = fontcache /usr/share/fonts/
>>>> That needs improvement, but that covers the information that needs
>>>> - whether the hook is run per file or per transaction, the name of the
>>>> and the directory whose files set off this hook. Maybe the conditions
>>>> set the hook off should be in the actual hook file.
>>>> I guess the actual hook would look look just like:
>>>> 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
>>>> 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
>>>> 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
>>> 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.
> 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:
> Include = /etc/pacman.d/hooks/gnome-hooks
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.
More information about the pacman-dev