Am Donnerstag, den 22.01.2009, 21:04 -0600 schrieb Dan McGee: > On Thu, Jan 22, 2009 at 6:51 PM, Aaron Griffin <[email protected]> > wrote: > > On Thu, Jan 22, 2009 at 6:29 PM, Allan McRae <[email protected]> wrote: > >> Aaron Griffin wrote: > >>> > >>> On Thu, Jan 22, 2009 at 9:15 AM, Allan McRae <[email protected]> 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 _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
