Line 116 and 118: Are these adding callbacks so that you get notifications when the user changes the preference settings?
If the user changes the refresh period, to be shorter than the time left to the next check under the previous policy, shouldn't the timeout be changed or another call added to the idle list with a shorter timeout? For example, if I set the refresh period to a day, wait till one minute after the refresh is happened (so the next refresh is set for 24 hours) then change the refresh period to be every hour, I shouldn't have to wait 24 hours before the hourly refresh period takes effect. Regarding your comment about terminating the update manager notifier, does that mean if: a) UMN notices an update and pops up the icon b) I click on the icon to see what updates are available c) I decide I don't want any of those updates at this moment and I cancel UM, or quit it then I no longer get notifications of updates until I ... reboot/relogin/? If so, that seems like broken behavior. I can't tell whether your comment means "we know this is an issue but we're not fixing it in this change set" or "we don't agree this is a problem." Thanks, Brock Padraig O'Briain wrote: > The webrev, http://cr.opensolaris.org/~padraig/ips-5188-v2/ fixes the > following bugs: > > 5174 updatemanagernotifier should be nice(2) > 5188 Tidy up required in updatemanagernotifier > 5198 updatemanagernotifier should re-read config files > > Note that we still terminate updatemanagernotifier after the user has > clicked on the icon. > > Padraig > _______________________________________________ > 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
