Danek Duvall wrote:
If you want to have a service that gets run when a file is changed by the
packaging system, then the action that delivers that file must be tagged
with that actuator. The service itself can be delivered in any package,
though clearly you'd want to introduce a dependency on the package
delivering the service into the package delivering the file tagged with the
actuator.
To follow your example, ABC can deliver the service, but mozilla-nss which
delivers this cert database must be modified to tag the database file with
the actuator to kick the service that you deliver in ABC.
Would restart_fmri actuator be used for this? I'd just like to make sure...
That said, it's not clear to me that this is the right architecture. Are
there other potential consumers of this cert database that will want
notification when it's been changed? If so, then each consumer will need
to make changes to mozilla-nss, and that file will end up being tagged with
one actuator for each consumer. That's not a very scalable process.
I don't know if there will be other potential consumers need this
notification.
If I can have a set of CA certs for consumers to use and get the SSL
support,
the consumers of this cert database will not have the need to get
notification
presumably.
What seems like a better solution is for each consumer of the database
which wants to be notified when there are updates to it to use file event
notifications to monitor it. Then, on startup and on each notification, it
can go re-read the database to do whatever it needs to do with the new
information.
Agree. This would allow me to leave NSS package alone.
I'll look into this approach.
The mozilla-nss package is being delivered through the "shared"
consolidation which also delivers nspr and jss. The old package name is
SUNWtls.
Thanks,
Hai-May
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss