PackageKit 0.4.9-1 gnome-packagekit 2.27.3-1 I have observed that selecting "Show Updates" from the tray icon usually leads to a screen which takes a while to actually show the list of updates which are available (sometimes this seems to load quite instantly though). I would expect that if I have been notified about updates, the program which is notifying me and which even displays the number of updates would know WHAT updates are available, yet this does not seem to be the case? I can understand if the descriptions are loaded later, but it seems like the package name at least and probably the title should be immediately knowable to the end user. Initially, it was my suspicion that the package names load in the background after the updates available notification is displayed, so I have tested this theory by not selecting "Show Updates" until hours later, but usually it is the same result -- I have to wait to see the list of updates I have been told to install. More interestingly, I have recently discovered that the list of packages seems to need to be loaded again even if I have previously selected "Show Updates" but have not installed the updates. In other words: 1) I see notification about updates; 2) I click "Show Updates"; 3) I wait for the list of updates to load; 4) I Click "Quit" or the Close Window button; 5) Time passes; 6) I click "Show Updates"; 7) I wait for the _same_ list of updates to load again.
(In reply to comment #0) > I have observed that selecting "Show Updates" from the tray icon usually leads > to a screen which takes a while to actually show the list of updates which are > available (sometimes this seems to load quite instantly though). I would expect > that if I have been notified about updates, the program which is notifying me > and which even displays the number of updates would know WHAT updates are > available, yet this does not seem to be the case? I can understand if the > descriptions are loaded later, but it seems like the package name at least and > probably the title should be immediately knowable to the end user. Right. If packagekitd is returning results from an internal cache, then it's almost instant. If it's asking yum, then it takes a lot longer. You can play with this using "pkcon get-updates". > Initially, it was my suspicion that the package names load in the background > after the updates available notification is displayed, so I have tested this > theory by not selecting "Show Updates" until hours later, but usually it is the > same result -- I have to wait to see the list of updates I have been told to > install. If you remove or install other packages in the meantime, then the cache is cleared. > More interestingly, I have recently discovered that the list of packages seems > to need to be loaded again even if I have previously selected "Show Updates" > but have not installed the updates. In other words: 1) I see notification about > updates; 2) I click "Show Updates"; 3) I wait for the list of updates to load; > 4) I Click "Quit" or the Close Window button; 5) Time passes; 6) I click "Show > Updates"; 7) I wait for the _same_ list of updates to load again. The update list doesn't have to be reloaded, but the update details and package details do. The latter two are not cached by the daemon. The problem is made worse because packagekitd quits after some time of inactivity, thus also loosing the cache. You can play with how long the daemon stays around (trading speed with memory use) by playing with /etc/PackageKit/PackageKit.conf, specifically the ShutdownTimeout and BackendShutdownTimeout. The file is documented, so should be pretty easy to understand.
(In reply to comment #1) > > Right. If packagekitd is returning results from an internal cache, then it's > almost instant. If it's asking yum, then it takes a lot longer. > > The update list doesn't have to be reloaded, but the update details and package > details do. The latter two are not cached by the daemon. The problem is made > worse because packagekitd quits after some time of inactivity, thus also > loosing the cache. I'm not sure I entirely understand -- "The update list doesn't have to be reloaded, but the update details and package details do" -- what is the "update list," and does it not include at least the package name (e.g. "thunderbird-3.0-2.6.b3.fc11 (i586)")? If it does include the package name, I suggest that at least that information should be instantaneously viewable to the end user. Optimally, the title (e.g "Mozilla Thunderbird mail/newgroup client") would also be instantaneously viewable, and, to a lesser extent, the Size (e.g. "31.9 MB"), since those 3 details are the ones shown in the "Show Updates" list I am referring to. If not even the package name (e.g. "thunderbird-3.0-2.6.b3.fc11 (i586)") could be shown instantaneously, I think this is a major shortcoming for the user experience. Regardless of which information is cached permanently or temporarily in the current implementation, I guess my suggestion is that the information shown in the "Show Updates" list should be cached even when packagekitd would quit ... Whether the cache is in memory, such as by transferring some details from packagekitd to the program associated with the tray icon (i.e. the one that stays around with the options to "Show Updates" or "Update System Now") or even making an exception to keep packagekitd running when updates are available, or whether the cache is written to disk (flat file or database), I think is pretty irrelevant from the user's perspective, probably even in relation to memory usage(?), but I believe would be a relatively major improvement to the user experience. Of course, I could misunderstand the constraints and implications involved.... Regards, Nate
We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.