[pacman-dev] [PATCH 0/2][WIP][RFC] hooks

[Andrew Gregory]

On 04/11/14 at 11:49am, Olivier Brunel wrote:
> 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

Right now there is a clear separation between what alpm and pacman are
responsible for reading.  pacman handles all of the configuration and
alpm handles the actual package (which includes any install scripts).
Despite their similarity to install scripts, every discussion of hooks
so far has anticipated them being user-configurable, making them
configuration files more in front-end territory.  Having alpm be
responsible for reading them would alter the relationship between alpm
and the front-end.  I don't think that's the correct solution and
won't be implementing it without a clear consensus first.

The fact that this would introduce additional work for front-ends is
unfortunate, but doesn't necessarily mean that the back-end is the
correct place for this.  Any alpm front-end already likely parses
pacman.conf which is much more difficult than parsing the hook files.
Even our own scripts in contrib/ don't parse it the same way pacman
does.

Having the front-end parse and configure the hooks for alpm upfront
doesn't really work because we would need to update the hooks in alpm
as the hook files were added/removed/updated which would involve the
same amount of work as the current implementation.

I do hope to move *some* of this into alpm, particularly the actual
execution of the individual hooks and possibly the selection of which
hooks to run at a given time.  The parsing and triggering I currently
intend to keep in the front-end.

apg