On Fri, Oct 23, 2009 at 12:36:38PM -0500, Shawn Walker wrote: > So it was pointed out to me off-list that there are a few other things > we may want to consider: > > * exposure of the boot env options on platforms where they don't apply > (not a primary concern for our project; primarily experience/cosmetic in > nature since the bootenv module makes this a no-op on other platforms) > > * possible confusion w/ user-images? (and what to do about snapshots...) > > This also occurred to me as well: > > * repeated package operations in the packagemanager GUI or with the cli > after a be creation has occurred; specifically, it seems like we need a > mechanism to warn the user about (but not prevent) subsequent operations > until they've restarted the system (at the least?)
Indeed, it seems to me that BE and IPS aspects of the system should be separated somewhat more cleanly in the UI. Suppose I want to image-update using a new BE, or in place in an existing BE, or to install a new image from scratch in a new BE. I could first create/pick a BE, mount it, then tell IPS to update/install into the image that corresponds to that BE. But that could be a complicated, ugly UI. It should be easy to decide what to do about BEs, and then update/install there, in one single UI. One way to achieve some separation here would be to say that "image-update" is an OS-specific aspect of pkg(1), that its options are entirely OS-specific. This would be totally non-disruptive, indeed, a no-op :) So why do I mention this then? Partly because BE issues are one of the several distinctions between user- and system-images (I'd separate the two completely, UI-wise). And partly because all BE aspects of image-update need to be explicitly separated from the rest of the pkg(1) UI. The same goes for the packagemanager UI. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
