John Rice wrote: > Well - its clear that the only way for us to get the information we need > to display to them about size of the upgrade is to use UMNotifier after > its done its scheduled refresh to do an evaluate and cache the results > for the fmris that can be upgraded. Then the UM GUI can consume this > cached data and present it to the user on startup with minimal delay. > > How will information such as reboot required, this package is part of an > incorporation etc... be exposed after evaluation? Will we just get this > from the info object if we request it after evaluate? > > No, please see my original email where I laid out a plan for providing this information to the GUI.
If it's needed, we can probably provide which package(s) make a reboot required. The problem is that the package we name may not be one of the ones the user chose to install. So, from a UI perspective, if the user chooses to install foo, and we say a reboot will be required because [EMAIL PROTECTED] must be installed is better than simply saying "a reboot will be required", then we can probably meet that need. What we cannot currently do is tell which user-provided package caused a reboot to be needed. Bart gave this example when I spoke to him a few minutes ago: The user wants to install foo. Foo has a dependency on [EMAIL PROTECTED], which is not currently installed on the system. The user also has baz installed on their system, which has an optional dependency on [EMAIL PROTECTED] Installing [EMAIL PROTECTED] will require a reboot (installing [EMAIL PROTECTED] may or may not require a reboot). What are you going to tell the user that won't be horribly confusing? Brock > JR > > Bart Smaalders wrote: > >> [EMAIL PROTECTED] wrote: >> >> >>> It seems like there are better ways of determining this information, >>> instead of looking through all of the manifests, and examining the size >>> attributes. >>> >>> The pkg client doesn't know how large an install will be until it has >>> evaluated an imageplan. Once the evaluation has completed, we actually >>> have the number of packages and bytes available. It seems like it would >>> make more sense to plug at the end of imageplan.evaluate, than it would >>> to do really slow and painful things. You could always prompt the user >>> to abort between the evaluate and the download phases. >>> >>> >> This is the only place you can know whether a reboot is needed, or if >> critical services need to be restarted, etc. The path taken for upgrade >> depends on the starting point, largely _UNLIKE_ today's system (modulo >> minimization). >> >> - Bart >> >> Bart Smaalders Solaris Kernel Performance >> [EMAIL PROTECTED] http://blogs.sun.com/barts >> "You will contribute more with mercurial than with thunderbird." >> _______________________________________________ >> 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 > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
