On 07/05/15 at 12:00am, Allan McRae wrote:
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.
As of now, hooks are treated similarly to scriptlets; no output is shown unless the hook itself generates it. I was considering adding some sort of message, but hadn't decided on it yet. If we add one, I agree allowing hooks to specify a name/description 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?
For simplicity and because the values can technically contain whitespace. Target does not allow multiple values on a single line.
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?
I have no idea. Since hooks are run outside the transaction it should be safe for them to use the package name to query the database, but I don't know of a use case where they would want to. My tentative plan for providing hooks with the triggering files in the future is to allow hooks to specify that file lists should be provided to them on stdin. Having them explicitly request the file list would make it easy for us to avoid a significant amount of unnecessary overhead if they don't need it. Providing it to them on stdin would avoid the problem of potentially exceeding the maximum command line length and prevent the need for complicated substitutions in the Exec command. If that plan is agreeable to everybody, it can be implemented later without disrupting any of the existing implementation so I would like to go ahead and get an initial hook implementation merged before worrying about file lists.
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)
Correct. During file conflict checking we determine which files in a package are *new* but I think that's about it and we don't save them anywhere. Part of the problem with trying to track changes during the transaction to avoid rescanning is that multiple hook directories are allowed. We would have to scan all packages for files in all of those directories and keep track of where previously loaded hooks came from to maintain proper order.
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