[csw-maintainers] package hooks

[Ben Walton]

Excerpts from Dagobert Michelsen's message of Thu Jun 25 09:39:49 -0400 2009:

Hi Dago,

> I guess we should talk about arguments passed, like the package name
> of the package currently modified. Additionally we should have a

Ok, so you think the hooks should be run per-package instead of
per-batch then?  This is heavier, but more granular.

On a more macro level, the package info could be provided to hooks
through a defined 'protocol' whereby the tool would create a set of
files (/var/opt/csw/lib/pkg-hooks/{installs,removes,upgrades}) that
would be available to the hooks.  As long as these files were created
prior to the batch call, the hooks could use this as required.

If all hooks are made per-package instead of per-batch, the protocol
could simply be a single argument passed to the hook.  That's much
easier from an implementation perspective simply because there are no
filesystem objects to look after.

This brings up the issue of hook exit status though.  The patch I
posted will abort the whole (batch) operation if any hook exits
non-zero.  Should per-package hooks have the ability to do the same?
Should the batch hooks have this ability?  My thinking is yes to both,
but I'm interested in alternate views on this.

> package "update hook" (useful for nginx, which allows uninterrupted
> update) and a "package purge hook" which brings the system to a
> pristine state before package installation.

Ok, so I'm taking this as:

If a package is being upgraded (pkgrm followed immediately by pkgadd)
that a preupdate and postupdate hook should be called?

If a package is being removed (without a new version being added) that
there should be a hook called after pkgrm named purge?

This would allow for batch hooks as well as per-package hooks.  In
this case then, should there be a pre/post upgrade batch hook too?
This is something I wasn't sure of...since the underlying tools don't
have any notion of an upgrade, our distinction would be mostly
artificial...not to say useless though.

This is exactly the type of discussion I was hoping for.  It's good to
define the needs up front.

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090625/a3f02285/attachment-0002.asc>