[pacman-dev] Hooks for pacman

Fri Jan 23 03:43:32 EST 2009

Am Donnerstag, den 22.01.2009, 21:04 -0600 schrieb 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

Hello,

what about an approach that keeps all settings of a specific hook inside
the hook script itself? This would just work after deployment of a hook
script in /etc/pacman.d/hooks.d without any configuration file hassle.
The Hooks would be self contained in files that pacman could source
before doing anything. And if someone wants to know what a hook do and
when it will be used there is only one place to look.

Marc