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. > > That is exactly what we want - let us flag to the user as soon as the UI comes up that a reboot is required and/or the package belongs to an incorporation. Both have considerable impact on the user and they may choose not to update them for that reason. Having the incorporation data allows us to prompt user as soon as they hit install to see if they want to do an Update All (image-update), instead of having to evaluate, find nothing to do and then report back. > | > | 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. > yep - as long as the attributes don't change going forwards we are fine with that and as more become available we can decide how to expose this info to the user. > | > | 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 >
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
