Eric Bélanger wrote:
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.
The file that would set off the gconfpkg hook would be like
/usr/share/gconf/schemas/pkgname.schemas. So the script will be passed
the filename and can extract the pkgname from that reasonably easily.
Allan
_______________________________________________
pacman-dev mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/pacman-dev
