+-- 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. | | 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. | | 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. -John _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
