For first cut of the updtatemanager we will just have to go with the list of available updates and not provide the reboot info. We also need the repo to be suitably tagged so we can pull out metapackages/ product patches which we cannot do at present (we just list out the packages that are installed and have an update available). Again something I'd like to see supported by the API in the future, list all installed packages with updates, list only installed metapackages with updates. The GUI could then allow the user to choose what to list
For 2009.04 I'd like to see us have the evaluate run by the UMNotifier (gnome-applet) and have it cache the results for the UM GUI to consume when its launched. In this way we should be able to reliably flag a package as requiring a reboot. This reboot info is available on Mac OS X updates. JR Brock Pytlik wrote: > John Plocher wrote: > >> Brock Pytlik wrote >> >> >>> What are you going to tell the user that won't be horribly confusing? >>> >>> >> Warning: Installing package foo (which you selected for install) >> requires that you reboot the system afterwards. >> >> Details: New: Foo => [EMAIL PROTECTED] or [EMAIL PROTECTED] >> Existing: baz => [EMAIL PROTECTED] (optional) >> New: [EMAIL PROTECTED] requires a reboot. >> >> What should I do? >> You can install Foo (and reboot because of [EMAIL PROTECTED]), >> you can continue without installing Foo (and thus not >> rebooting) or you can cancel the install. >> >> >> > Ok, perhaps that's something we'll aim for down the road. Of course, I > could come up with arbitrarily complex scenarios, but those might not be > reflected in the real world. In any case, that information won't be > available until after evaluation. Stephan just mentioned in the hallway > that we might want to consider a "possible reboot needed" flag for a > package which would be true if any action inside the package could > produce a reboot (or we could provide a count of the actions, or a > percentage of the actions, or a percentage of the file actions, or > (after these have been around a few versions) a historically generated > probability that this version, when jumping from N-versions back, will > require a reboot). If this is very important to the UI, pick a > reasonable, implementable measure and we can have the API provide it. I > have no inherent objection to the API indicating why a particular set of > changes will require a reboot. I think it's a very questionable UI > decision to present that data be default. If it's not presented by > default, and it presents a substantial engineering effort on our behalf > to be able to generate that data, I think that it could go into the bin > of "things to do later." > > Also, to be clear, I think your details section is reasonably achievable > for arbitrary dependency structures. I think providing a specific > warning will be more complex: suppose if you install foo and bar, a > reboot is needed, but if you install only foo, or only bar, no reboot is > needed. Further, suppose that if you install foo, bar, and baz, no > reboot is needed (and yes, I think I can construct a situation where > this can actually happen). Now, what does the warning look like? The > "what should I do" section I think is beyond the scope of this project, > because of the difficulty of generating reasonable natural language > based on complex data, because of the translation issues that I think > would come up, and because the text could be tremendously long. > >> -John >> >> PS. I would hope we are doing everything we can to stomp out >> all the "reboot needed" situations we can find, in the same way >> (and for the same reasons) we stomp out kernel panics. Users >> and admins DO NOT want to have to reboot their systems any more >> than they absolutely have to; "never need to reboot" would be >> a very powerful feature for us to aim for. >> >> > I'll let others address this. I'll merely say that by doing this, we're > at least potentially reducing the number of reboots since instead of an > entire package producing a reboot, only a specific action will. This > means that, we cannot have more reboots indicated than if we tagged at > package level, and have the possibility for substantially less. > > Brock > >> >> _______________________________________________ >> 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
