On Fri, Jan 23, 2009 at 11:56 AM, Aaron Griffin <[email protected]> wrote: > On Fri, Jan 23, 2009 at 9:38 AM, Allan McRae <[email protected]> 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.
One thing that just came to mind (emailing it before I forget): We need to differentiate between additions and removals for the "per trans" hooks somehow. Take, for instance, info files. On add: install-info /path/to/file On remove: install-info --delete /path/to/file The per-trans hook needs to do BOTH steps in the case of an upgrade (a remove then an add). Right? Or do info files work fine in this case? _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
