SUMMARY Every time I start Discover, updates/packages are fetched, no matter how long it's been since the last time. This increases the start time of Discover extremely (I have to wait about 20 seconds on every start before I can install/remove/update packages). Instead, updates should be fetched at system boot, when the user wants to search for updates (pressing on "Search for Updates" or wants to update the system (pressing "install updates") or after a given time (e.g. every hour), which should be configurable. That way, starting Discover is way faster and less bothering. This happens at least on OpenSUSE Tumbleweed, I haven't tested it on other systems. STEPS TO REPRODUCE 1. Start system 2. get message that updates are available 3. start Discover 4. observe Discover fetch updates AGAIN OBSERVED RESULT Discover fetches updates and packages every time it's started EXPECTED RESULT I should be instantly be able to install Updates without having to wait another 20 seconds. SOFTWARE/OS VERSIONS Windows: macOS: Operating System: openSUSE Tumbleweed 20210221 KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-1-default OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz Memory: 23.4 GiB of RAM Graphics Processor: GeForce GTX 1080/PCIe/SSE2 ADDITIONAL INFORMATION
Yeah, this has been a complaint since forever, but it's very noticeable on openSUSE distros because of hong a refresh takes. On Arch or deb-based distros, it's very fast, so people don't really complain about it anymore. Dunno about Fedora.
(In reply to Nate Graham from comment #1) > Yeah, this has been a complaint since forever, but it's very noticeable on > openSUSE distros because of hong a refresh takes. On Arch or deb-based > distros, it's very fast, so people don't really complain about it anymore. > Dunno about Fedora. Yeah OK, it might be faster on other distros, but it still costs time on every system and I don't really see why it's behaving that way at all. But you said that it's a complain since forever, is there a reason why it hasn't been changed? Just because it's not that time consuming and annoying on some distributions anymore? :D
Because it's hard to fix. :)
(In reply to Nate Graham from comment #3) > Because it's hard to fix. :) Oh okay, that explains it. :P
It's not only that it's hard to fix. We used to refresh less often but then sometimes people would get errors that their update wasn't fresh and we'd have to tell them to F5 and try again, which is very confusing. In the end, even if we know that 1h ago the cache was refreshed, we can't tell for sure that all the packages are still current.
(In reply to Aleix Pol from comment #5) > It's not only that it's hard to fix. We used to refresh less often but then > sometimes people would get errors that their update wasn't fresh and we'd > have to tell them to F5 and try again, which is very confusing. > > In the end, even if we know that 1h ago the cache was refreshed, we can't > tell for sure that all the packages are still current. Yeah OK, but wouldn't it be possible to refresh when the user actually tries to install updates then? The same problem occurs at the moment, when you have discover open for a few hours and press "install updates" then. I know, not very probable, but also not completely unthinkable. So, instead of checking for updates when the user opens discover because he may update his system, wouldn't it be more useful to check when the user actually tries to update? And to know that updates are available, it should be checked at system boot and after a given time. And to make it less confusing for the user that when he hits "install updates" but it's checked for updates first, the text of the button could be changed to "search for updates & install", which would be better than the second solution I describe below I think. This solution here would also have nearly the same behavior as it has now, but just checks for updates when it's *really* necessary. A second usable solution would also be to check how old the cache is (like when it's 10 seconds old, it's not very probable that there're new updates), but when it's 5 or 10 minutes old, it might be necessary, so discover shows a dialog, saying that the last check for updates is XX minutes ago and new updates might be available and whether it should check for updates again or not. But that might also be confusing and just unsettle the user (and users who understand the message would probably just hit "yes" anyway all the time and then we have the same behavior as described above, just with extra steps, users who don't understand it would probably hit "no" all the time and then there might be errors with invalid updates, which confuses the user even more, so the solution described above is really better).
Git commit d38e7ad9f2aeb69127b6e62ac50f655077d26e1c by Aleix Pol. Committed on 28/11/2022 at 20:48. Pushed by apol into branch 'master'. flatpak: Do not check for updates immediately Wait for a bit to check for updates, instead just show the locally available data ASAP. Related: bug 439050 M +14 -5 libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp M +2 -1 libdiscover/backends/FlatpakBackend/FlatpakBackend.h https://invent.kde.org/plasma/discover/commit/d38e7ad9f2aeb69127b6e62ac50f655077d26e1c
(In reply to Nate Graham from comment #1) > Dunno about Fedora. It's a problem on Fedora (yum repos have a ton of metadata which gets fetched when checking for updates). The time it takes to fetch that metadata seems to be exacerbated by things like Bug 457408 and Bug 466671, so that refreshing the updates is even slower in Discover than for pkcon or dnf.