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
_______________________________________________
pacman-dev mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/pacman-dev
