On Mon, Jun 08, 2009 at 10:16:22PM +0200, Darren Reed wrote: > When adding a user or group is implemented in terms of Actuators (and > documented as such - on a separate man page), then I'll believe that > Actuators are a reasonable answer to the problems of updating a file in > /etc and managing the data stores that use them.
Adding users and groups can't be implemented in terms of actuators, not because they manipulate files, but because in order to lay down files, the users and groups that own those files need to exist prior to those files being laid down. So in the case of an install on a non-live image (where the services named by actuators don't get run until the image is booted), you'd have to install the user and group actions, boot the image so the services ran to assemble /etc/passwd and /etc/group, then create a new boot environment based on that new one, update everything else, and reboot a second time. In addition to the two reboots, you'd be completely unable to add a user or group in the same package that wanted to use it. Hardly a useful model. But the same doesn't hold for projects, services, RBAC entries, etc, at least as long as the assembly services run before the services that use the new values in those databases. Unless you're seeing something the rest of us are missing ... The rule of thumb is: if something is required for another action to successfully install, or is required for boot, then it's a candidate for an action. Otherwise, it's up to the application to figure out what to do at runtime, service start-up, etc. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
