> That's not what I'm implying. The need for actuators in user images > simply implies the need to have package installation trigger some > code execution -- that's the same need (or at least one of the > needs) the SMF based implementation satisfies.
Actuators provide a way to manpiulate SMF services, but they don't exist for the purpose of executing random bits of code. >> One of the design specifications listed for UserImageActuators states: >> >> o Any failure of a UserImageAcutator hook must not cause an >> imageplan evaluation to fail >> >> Unforuntately, this is unenforceable if arbitrary code is executing. > > But isn't this true with the SMF implementation as well? My package > can install an SMF service and restart it and now that arbitrary > code (the SMF service) could misbehave. You've missed the point. In the second case, the code gets executed in the context of the SMF, with the services privileges, after the install has completed. You're proposing that we execute code at install time with the privileges of the installer. SMF places misbehaving services in the maintenance state after they have failed repeatedly. Code executed in the context of the installer could make arbitrary modifications to the image, and has no framework to ensure proper behavior. Bart has also observed that your proposal confines us to manipulating running images. We want to be able to make modifications to images that aren't running. > When folks hollered that they needed "package scripts" one > of the responses was: no you don't, you can do that with actuators. It sounds like you have misunderstood. What was said was that you should use actions to perform common install operations. If actions don't meet your needs, consider extending the actions. In rare cases, a you may need to create a service do perform some kind of one-time configuration that occurs after install. In that case, you should create a SMF service and use actuators to manipulate the service. The reasons for using a service instead of executing arbitrary code are as previously described. We don't want to run these things in the context of the installer, we want to ensure deterministic behavior, and we don't want everybody writing broken one-off scripts for common tasks that should be handled by actions. > The current SMF Actuator implementation provides the ability for > a package installation (or removal or update) to trigger code to be > executed. The actuators don't exist to execute code, you've reversed cause and effect. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
