[pacman-dev] [PATCH 0/4] hooks

[Andrew Gregory]

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