Firstly, WOO! On 04/07/15 19:59, Andrew Gregory wrote: > = TODO = > * documentation > * run PreTransaction hooks *after* conflict checks > * hook/trigger validation > * masking hooks with an empty file or symlink to /dev/null > * tests > > = Hook Directories = > > ALPM handles keep a list of hook directories to scan. Initially, this list is > populated with a single directory: /usr/share/alpm/hooks/. This directory is > intended for packages to be able to place hooks in a front-end agnostic > manner. > Front-ends may specify any number of additional directories to search, with > later directories overriding earlier ones. Front-ends can disable hooks > altogether by setting an empty list. > > = Parsing Hooks = > > Configured directories are scanned for files matching '*.hook'. Hook files > must be in pacman-style INI format with the following available options: > > [Trigger] (multiple Trigger sections allowed) > Operation = Sync|Remove (Required) > Type = File|Package (Required) > Target = <Path|PkgName> (Required, multiple allowed) > > [Action] (only one Action section allowed) > When = PreTransaction|PostTransaction (Required) > Exec = <Command> (Required) > Depends = <PkgName> (Optional) > AbortOnFail (Optional, PreTransaction only)
Looks good to me. Idea: Do we want to add a field that provides suggest text to display while it is running. I assume pacman will state what hooks it is running and something better than "Running foo.hook..." would be useful. > Unlike pacman.conf multiple values are *not* allowed on a single line. Is there a reason for this? Are they allowed for Target? > Exec is currently limited to the path of the executable to run, arguments are > not allowed. This is intended to be a temporary limitation until I decide the > best way to go about splitting the arguments, which depends in part on whether > we want to try to provide hooks with the packages/files that triggered them. Fair enough - updating caches is the big slowdown during Arch updates. This will cover that. But I'd really like at least the filename to be used. e.g. for info files. Is there a current usage case for package name? > Targets are matched the same as IgnorePkg in pacman.conf, meaning multiple > targets can be specified and targets can be negated with a leading '!'. Great > If multiple Trigger sections are specified the hook will run if any of them > match the transaction. > > = Running Hooks = > > Hooks are not cached after running. Directories are rescanned and hooks > reloaded each time. This is to make sure that any hooks added/removed during > a transaction are appropriately accounted for. So load hooks -> PreTransaction, do stuff, load hooks -> PostTransaction? (aside: do we currently save a list of all files changed? I have a feeling we do during conflict checking) > Hooks are run exactly the same as install scriptlets (chroot, output passed to > the front-end, etc.). > > They do *not* have access to which package/file triggered the hook. > > For the time being, run order is officially undefined. Fine. I'm happy to commit the first two patches now if that would help. I'll take a decent look that the second two later. WOO! Allan
