On Tue, Jan 27, 2009 at 7:57 PM, Allan McRae <[email protected]> wrote: > Aaron Griffin wrote: >> >> 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? > > I count install-info stuff as a "per file" hook rather than a per-trans hook > because you need to pass a file name. Per trans hooks would be mainly for > updating font/desktop/icon databases where filenames are not needed. > While I cannot think of any need for a pre-transaction hook, that does not > mean someone won't and I am willing to lean on the side of generality for > this. > > Allan >
How will you handle things like gconfpkg (/usr/share/pacman/proto-gnome.install) ? You need to pass the pkgname. Will there be a "per package" hook? Or will you just use the "per file" hook with the pkgname as argument. Just wanted to bring that out. _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
