*** Bug 574 has been marked as a duplicate of this bug. ***

The most straightforward approach appears to be something like an action that
monitors subsequently installed actions w/ a filter; anything passing the filer
would cause the refresh to occur.

A example might be:

refresh fmri=svc://application/man/whatis when=[install,update,remove]
filter="man=true"

Subsequent to the installation of this action, any actions
installed/removed/updated w/ "man=true" would cause a record to be appended to
var/pkg/refresh/application/man/whatis containing the name of the transition
and the action that passed the filter.  If this pkg command was running on a
live image, 

svcadm refresh svc://application/man/whatis

would be invoked on the (presumably) transient whatis service, which would read
the log file to perform any desired actions.  Locking is still tbd.  If the
image isn't live, the transient service should take care of the necessary
processing on next boot.  The pkg command would collapse multiple refresh
requests into a single event; even if hundreds of packages containing man pages
were installed, the whatis db would be rebuilt just once.

Each refresh action would be written to a known location in the /var/pkg
hierarchy during installation; any pkg commands modifying an image would load
the installed refresh actions so that any action changes could be filtered.

It may be useful to make the creation of the log file of modified actions
optional; some types of svc updates (such as bootadm update-archive)
rebuild the world each time so a log file isn't needed.  A mechanism is
still needed to let the svc know that work needs to be done in the non-live
case; the existence of an empty log file (to be deleted by the svc on
successful completion) might suffice here.

see also http://defect.opensolaris.org/bz/show_bug.cgi?id=542 regarding Desktop
Gnome menus not updated after an IPS install of packages that declare user
menus.

Might be a fix to be done at the Gnome level, but not sure it can be done by
May 2008.  
I think IPS install/remove should have a way to notify the desktop of some
changes instead of having the desktop to constantly check for changes on the
filesystem.

Please keep in mind that there is an effort to use IPS as a
cross-platform packaging system. So we need a solution to this
general problem (triggering post-installation logic) for other 
platforms as well.

Note that on other platforms we are pretty much limited to 
installing into User images, often by a non-root user. In this
case a simple, generic solution that can be used across all
(non-Solaris?) platforms is desirable. For example, maybe the fmri 
could point to an executable that is run directly by pkg, after all 
installation/update is complete, right before exit (maybe first
thing for removal). It would be defined that pkg() is only acting
as a trigger for this logic, and failure of one of these executables
would never impact the install/update/removal of a package.

*** Bug 1758 has been marked as a duplicate of this bug. ***

Spoke to Bart, he's targeting build 96.

we would appreciate, if you could also document as to what upstream developers
like myself should do to ensure that apache or mysql services are enabled at
the end of installing IPS packages

(In reply to comment #8)
> we would appreciate, if you could also document as to what upstream developers
> like myself should do to ensure that apache or mysql services are enabled at
> the end of installing IPS packages

Please file that request as a separate defect.  Thanks.

Resetting target milestone to 97

Resetting to 99

Resetting target milestone.

Fixed in 584:22bc748edce6