joerg@britannica.bec.de wrote:
> As a solution I propose to introduce "trigger". A package can register 
> trigger programs with the framework. They get executed whenever a
> package using this trigger is installed, removed or updated. Multiple
> packages can provide the same trigger (Ghostscript and Xorg are both
> interested in TTF fonts).
> 
> A package can tag the PLIST to invoce the trigger for a specific file,
> e.g. like:
> 	@trigger TTF
> 	lib/X11/fonts/X11/geni102.ttf
> 	@trigger TTF
> 	lib/X11/fonts/X11/genr102.ttf
> would result in the TTF trigger being called with both files as
> arguments. In addition, it should be possible to call trigger with pure
> meta data (useful for sysutils/user*). A package can also require a
> trigger to be provided at least once. This allows (in combination with
> the alternative framework) to handle the first problem.

I suggest an alternative form:

     lib/X11/fonts/X11/geni102.ttf
     @post-install register-truetype-font %f
     @pre-deinstall unregister-truetype-font %f
     lib/X11/fonts/X11/geni102.ttf
     @post-install register-truetype-font %f
     @pre-deinstall unregister-truetype-font %f

This way it is clear which arguments the trigger gets (they will be 
parsed like in the shell, and %f expands to the properly quoted filename 
that occured last). You can also define triggers that don't take any 
arguments with this scheme.

Every package can install its own triggers, for example in 
libexec/pkg_triggers/. There could also be a trigger called "exec" that 
executes its arguments via the exec() functions.

pkg_add should get a --paranoid or --interactive mode, which will ask 
the pkgsrc user before running each trigger. To reduce the burden, some 
triggers may be defined as trusted by the pkgsrc user in a special 
configuration file.

So far for my ideas, which would make pkgsrc much more suitable for 
paranoid system administrators. :)

Roland