[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Jeff]

On Sat, Sep 12, 2009 at 11:34:20PM +0200, Marc - A. Dahlhaus wrote:
> 
> Well, so far i got much headwind against the trigger idea...

Just my 2 cents after reading this thread:

1) pacman -Syu = 20 updates that install info pages:

This means running infodir 20 separate times (file-based) or once at the
end of the transaction.

2) pacman -Syu causing update of kernel and modules.

mkinitcpio runs for both packages (file-based) instead of once at the
end of the transaction.

If the hook script had a variable to hold the user preference of
immediate or delayed, then pacman could keep track of those delayed
triggers and run them at the end of the transaction. Of course this
would only make sense for the hooks that can be delayed and pacman would
default to immediate in the absence of such a variable.

At this point, I've forgotten who was in favor of what on some of the
finer details, so I'll just throw my opinions into the fray since it
seems you are calling for such opinions:

I share the concern over code duplication, but I do not agree that it
should be taken out of the hands of the packager except where it can be
reasonably hardcoded into pacman itself. If the user wants control, the
hook script itself can give them that. Either way pacman has to know
what trigger to run and when to run it, so it seems the PKGBUILD is a
natural place to have an array of predefined hook names (like info).
For those hooks that are unique to a given package, the PKGBUILD can
tell pacman to register the hook (i.e. install the hook) prior to any
other file being installed (to allow for preinstall hooks).

Example of some possibilities:

pkgname=example
pkgver=1.0
hooks="("postinstall:gtkcache" "preinstall:uniquescript")
<..>

The really common ones, like info/man cache updates could even be
hardwired into pacman to check for the installation/removal of such to
trigger the corresponding action without having to put them in the
PKGBUILD, though I don't consider a hundred PKGBUILDs all having
postinstall:info in them as code duplication anymore than those same
PKGBUILDs all having make && make install in them. If the cost is low
enough, the same hardcoding could be done for any hook that runs on more
than a few packages installed as part of core or extra. This isn't to
say that pacman hardcodes the action itself, but rather hardcodes the
trigger it is looking up in /etc/hooks, where scripts reside to do the
actual work.

ISTM, to ease the burden, pacman should be able to reverse an operation
upon uninstallation without needing specific instruction. For instance:
postinstall:gtkcache should naturally also mean postremove:gtkcache
without having to explicitly state that in the PKGBUILD (however,
explicitly stating it can be used to override in the corner case of
something having to be pre instead of post or vice versa).

I am also a fan of the hook script itself being the config file. A
global hooks.conf would be a maintenance chore and parsing two files,
one for options and one for the script seems needlessly expensive to
both pacman and the user who is trying to manage his hooks.

As for a hooks package for general hooks, I think that is a good idea so
as to keep pacman OS-independent and avoid the problems that resulted in
the mirror list being separated.

Sorry this email became so long-winded.

-- 
Jeff

My other computer is an abacus.