John Plocher wrote: > +-- Brock Pytlik wrote > | Uses tries to install package Foo. > | Packagemanager plans the install and notices that a reboot will be > | required and informs the user of this. > | User clicks ok, and the installation happens > > > Windows and MacOS do this slightly differently - they indicate > whether or not a reboot would be needed as part of the list of > packages, so that the user can (for example) choose to only > install non-reboot packages now and defer reboot-needed ones > for later. > > This argues for exposing the reboot-needed data early in the > user interaction - waiting until the user has constructed a > list of packages to tell them that one or more require a reboot > seems overly harsh. Putting it in the package inventory > might be sufficient. > Please see my follow-up to JMR's email explaining why this isn't possible. > | > | I've imagined three broad approaches > | > > In general, highly structured data seems better than free-form. > I imagine there are a few initial attributes (e.g., reboot needed, > impacts security, co$ts money) that should have strong semantic > associations - when the GUI sees these, it can apply its knowledge > of the semantic expectations behind the attribute to suggest > appropriate actions - and new attributes don't result in failures, > only potentially missed advice. > The reason for the free form option is that we've had trouble keeping changes between the back-end and clients in sync. And generally, if someone else wants to build their own front end, it would be nice if adding a new smf service to restart didn't actually break their code, when we have another available option. The point is that the number of these actuators isn't bounded, at least not to my knowledge. That's why I think the flag+string data is the way to go.
But if we have a way to convey that advice to the user, even if a slightly less snazzy fashion, shouldn't we do that? If someone's installing a package on their webserver which requires their apache server via smf to be restarted, shouldn't we inform them of that, even if we didn't know ahead of time that we'd eventually need such an action? That way they could choose a reasonable way to mitigate the impact of having their webserver offline for a period of time, instead of having it happen without their knowledge. > | > | severity... > +-- > > I'm not sure how the backend can judge severity of these attributes > in any useful manner. Maybe this is all tied up in your workflow > assumptions above - if the user submits a plan to execute, then > having return values and severity makes a bit of sense. On the > other hand, if these attributes are instead part of the initial > listing of packages that *could* be installed, they don't. > Right, I'm assuming the workflow I outlined above. > -John > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
