| Summary: | Allow clicking on Update All while a refresh is still in progress, triggering whatever updates are found to occur without another click once the refresh is complete | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Roke Julian Lockhart Beedell <4wy78uwh> |
| Component: | Updates | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | aleixpol, john.kizer, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://discuss.kde.org/t/i-should-be-able-to-instruct-discover-to-begin-downloading-updates-before-theyve-been-instantiated/33345#:~:text=I%20should%20be%20able%20to%20instruct%20Discover%20to%20begin%20downloading%20updates%20before%20they%E2%80%99ve%20been%20instantiated | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | A Screenshot Of The "Fetching updates..." Page | ||
|
Description
Roke Julian Lockhart Beedell
2025-04-26 15:05:49 UTC
So basically, you want the ability blindly update without knowing what you're updating to? (In reply to Nate Graham from comment #1) Yeah. The equivalent of a `-y` option. I realise that there's potential danger associated with it, and that others might not know of that, so I wouldn't mind if it deactivated itself when the transaction involves removal. However, I think there needs to be some kind of solution, because as it is, with a slow internet connection, I have to wait at my PC for a *while* for Discover to load its updates. For comparison (albeit not 1:1), the Microsoft Store (at least, on Windows > 10) and Google Play Store (on AOSP > 5) both already do this, which is, I presume, why I find it so jarring that Discover doesn't. Sounds like you should just use automatic updates, then? What's wrong with that option? (In reply to Nate Graham from comment #3) Whether I want to verify an update's content before applying it basically differs per day, depending upon whether I have the time, or if not, have reason to believe that an update is problematic beforehand. On that last point, on Atomic OSes (think Fedora Kinoite, with RPM-OSTree and Flatpak), the standard concern of dependency conflict causing removal is significantly diminished. Because I tend to update my OS when I step away from the PC and don't leave it running at night, those times when I need to leave *right then* are exactly the time when I want it to update during. However, I can't get it to update during that period of time without either preparing Discover beforehand (which I forget to do), or waiting, cutting into the time I'm meant to be doing whatever else. In this case, going to the KCM and enabling automatic updates should be mostly equivalent to this, except that I have no introspection into what conditions that actives under, so I have no idea whether it'll actually update whilst I'm gone. In practice, it hasn't. Thanks. I don't think this makes sense to implement as requested; it's basically a workaround for checking for updates being too slow. That's a legitimate gripe; let's focus on that instead. As a general matter, we should fix our bugs, rather than making few features or UI changes that support working around them. (In reply to Nate Graham from comment #5) There's always going to be a slow network, though, and on immutable OSes, one can go their whole installation without a package conflict. There's even the automatic update mode in the Update KCM. If security is the problem, I can't say I see the rationale, especially if other OS vendors *seem* to agree. 🤷 I just feel for those who haven't the skill to whip out the CLI for this. |