On 04/11/14 01:59, Andrew Gregory wrote:
This is a lazy conversion of a work-in-progress hook implementation from my pacutils library [1] (hence all the pu_* prefixes). I have left out several previously outlined features that I do not see as essential to an initial implementation and can be easily added later if they are actually needed: * mid-transaction hooks (PreInstall, PostRemove, etc..) * passing triggering packages/files to the hook * system vs user hook directories with overriding (use backup=() instead) * specifying hook order
Some included features not previously discussed that I know of: * pre-transaction hooks can cancel the transaction * multiple triggers per-hook
Major TODO's: * documentation * error handling * use _alpm_run_chroot or similar to run the hook instead of system()
I have chosen to implement hooks entirely in the front-end as the only alternatives I came up with were having alpm do the file parsing itself or having pacman repeatedly reset the list of hooks as packages are added/removed.
Although I welcome the addition of hooks, I don't think it's a good idea to make it a frontend/pacman-only implementation. Just like today one wouldn't consider a package operation (e.g. install) to be complete without dependencies handling or the scriptlets run, tomorrow it won't be considered complete without hooks having been processed. So it should definitely be an ALPM thing. In fact, one of the reason for hooks has been said to replace "common" install files with hooks, so it is thought of as part of the whole operation process, and therefore would mean any frontend not reimplementing hooks exactly like pacman does would be broken! This doesn't sound good/right to me. Frontends could do the parsing themselves, but then only set things up in ALPM, much like they set repos or which packages/groups to ignore. But then, it's ALPM who makes use of it, and maybe ignores a package or asks user about it, not the frontend. Additionally, since there was talk that if a package installs hook files, they should be taken into account within the transaction (for remaining package operations), it seems it might be better to have ALPM actually do the parsing, since it could then also load any new hook files added as part of a package operation. Frontends would then only set which folders are to be used/looked in for hook files. (And there'd be an event INVALID_HOOK or something, for when ALPM fails to parse a hook file, and will therefore ignore it.) What is the problem with ALPM doing the parsing, that you didn't want to do it? Cheers, -j
Because this is a rather minimal implementation, my primary concern at this point is making sure that no essential features are missing and that I don't commit us to anything that would make implementing the remaining features more difficult later.
Some example hooks:
# basic hook [Trigger] Operation = Install Object = File Target = usr/bin/foo # note no / prefix
[Action] When = PostTransaction Exec = /usr/bin/echo "I'm in a hook"
# don't uninstall linux* packages [Trigger] Operation = Remove Object = Package Target = linux*
[Action] When = PreTransaction Exec = /usr/bin/false
Previous discussion: https://mailman.archlinux.org/pipermail/pacman-dev/2013-July/017508.html
Wiki: https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
[1] https://github.com/andrewgregory/pacutils
Andrew Gregory (2): add TRANS_COMMIT_{START,END} events add basic hook support
lib/libalpm/alpm.h | 5 +- lib/libalpm/sync.c | 6 ++ lib/libalpm/trans.c | 7 +++ src/pacman/Makefile.am | 1 + src/pacman/callback.c | 42 +++++++++++++ src/pacman/hook.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++ src/pacman/hook.h | 52 +++++++++++++++++ 7 files changed, 268 insertions(+), 1 deletion(-) create mode 100644 src/pacman/hook.c create mode 100644 src/pacman/hook.h