On Wed, Mar 04, 2009 at 06:17:28PM -0800, Joseph Di Pol wrote: > When time allows we'll start considering options for a simple > cross-platform service framework for user images -- I see that > Nicolas has posted some thoughts on this. I don't think the > goal would be to have something as sophisticated as SMF.
Indeed, I'd even say that something as sophisticated as SMF would be inappropriate here. Note that user images are different from system images in a number of very important ways. Also, I'm not sure that I understand exactly how user images are supposed to be used; I imagine they are intended to live in user home directories, but if that's wrong then all of what follows may be equally wrong. a) So far as user images can be said to "run" they can be running concurrently on the same host (multiple seats/virtual terminals) and on different hosts (home directories on NFS). Speaking of user images as "running" seems wrong, but allow me to do so for now. System images can only be running in one place at a time (ignore diskless boot -- that's not really supported now except as an implementation detail of jumpstart). b) User images can run, either concurrently or at different times, on systems running different OS versions. Clearly the same is not true of system images. c) When a pkg is installed into a user image the user image may or may not be running, either in the context where the pkg(1) command was executed and/or elsewhere on a different system, or not at all. Whereas system images are either running or not. (a) argues for locking around any equivalent of "SMF actions" for user images. (b) argues for run-time dependency checks by software installed into user images, but it likely won't happen (a check of OS rel is one thing, a full check of pkg deps is probably not acceptable). So being lax with dependencies may be a hard requirement for software installing into user images. (b) may also argue for having multiple user images, but I bet that complicates everything w.r.t. things like start bar / icon / other desktop feature management :( The fact that a user image may be running on different hosts also means that there's no reliable way to discover additions/removals at runtime other than by polling. Polling sucks (particularly from a power management point of view). I'm not offering a solution. User images seem to have complex issues. In any case, what I did offer earlier seems like a place to start. Namely: a tool to run deferred actions associated with packages installed into user images. This tool would be run a logon time, and... at some other unspecified time -- I don't know what that would be (perhaps as a last step in pkg(1) IFF pkg(1) ran in the context of a logged in user running the affected user image. Packages installed into user images would use file actions to drop registrations into a location in the user image where said tool would expect them. That's roughly how the tool I posted for re-using SVR4 package scripting via IPS SMF actions works, so you might want to look at that. Whether that's sufficient, I don't know. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
