On Mon, Jun 08, 2009 at 03:50:06PM -0700, Bart Smaalders wrote: > The more the packaging system knows about Solaris internals, the more > difficult it is to make upgrade work across a wide variety of releases.
Good point. <tongue-in-cheek> Perhaps then there shouldn't even be newuser/group actions (init(1M) could self-assemble any updates of /etc/passwd, shadow and group, after all, by kicking off the relevant update program from /etc/inittab). </tongue-in-cheek> I suspect we'll end up with utilities for updating various files, not unlike CAS, just easier to use, and with pkgs invoking those from self-assembly SMF services. Such utilities would reduce code duplication. That seems like a good result, actually. My main concern is the explosion of random self-assembly SMF FMRIs. For aesthetic reasons I'd like us to have a prefix for use for naming SMF FMRIs used only for self-assembly. But I think too that we're likely to end up needing to know when all self-assmebly is complete. Consider the validated execution, which, IIUC, wants to be able to run with read-only /. On update one would have to run with read-write / at update/boot time in order to allow for self-assembly. The system will have to know when self-assembly has completed so as to reboot with read-only / (or perhaps remount / ro -- does ZFS allow that?). This argues, I think, for either a self-assembly/update milestone or service that depends on all self-assembly services. I bet there will be other reasons to do that. For example, one might want GDM not to start until post-image-update boot time self-assembly complete. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
