[pacman-dev] [PATCH 0/2][WIP][RFC] hooks
Olivier Brunel
jjk at jjacky.com
Fri Apr 11 05:49:21 EDT 2014
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
>
More information about the pacman-dev
mailing list