On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <allan@archlinux.org> wrote:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Am Samstag, den 24.01.2009, 00:52 +1000 schrieb Allan McRae:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
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.
The one problem I see with that is that the actual script needs to be run. The post_install scripts etc, just source and run the script in a shell. This becomes more difficult if we have to keep information what files trigger the hooks to be run and when.
The point was that this way you can install new hooks with packages and they would just work without any configuration file fiddling. It would be cleaner for a packager in my opinion.
I understood you point. My point is that each hook need to provide the following information:
1. when to run it (per file or transaction) 2. what files trigger it running 3. a script that can be sourced and run by the shell.
It is _a lot_ easier if 1 and 2 are separate from 3. If you can propose a clean way to have them all together, then we will be happy to consider it.
Hmmm #myhook RUN=PerFile PATTERN=/usr/share/info/* ##### run () { ... } We could do something nasty where pacman parses the file, ignores all lines that it doesn't match to '^RUN' or '^PATTERN', and possibly end parsing early at some token (the ##### above) Still, it's a little nasty. I almost prefer the manual config file editing for a few reasons: It doesn't force the user to use these hooks. *I* should have to turn on the install-info hook myself.