That’s quite a claim. What bug are you referring to?
Software Updater exists primarily because apt updates are deficient for PCs:
- Some updates require restarting the system, and some things may not work until you do.
- Things can break if a machine shuts down during an update.
- A complex app (like Firefox) might stop working properly if updated while it’s running.
- You can’t undo an update (because maintainer scripts can do anything).
- Updates are connection-insensitive — they don’t care whether you’re on a metered or slow connection (or even none at all, spewing errors rather than pausing).
For all these reasons, we need to prompt you explicitly to start updates, and let you opt out of individual updates if you’re doing something important in a particular app. (I assume Gnome Software’s Updates panel exists for similar reasons.)
Some of these reasons don’t apply to snaps:
- Snap updates never require restarting the system.
- Things don’t break if you shut down during a snap update.
- Snap apps don’t break if they’re running during an update (and eventually we’ll prompt you to relaunch if you’ve kept using an old version for ages).
- Still a problem: updates aren’t undoable (in the GUI, only in the CLI).
- Still a problem: updates aren’t connection-sensitive in practice — only in the CLI, only if you know about
rate_limitdespite its absence from the documentation, and (since it would be pointless to rate-limit all the time) only if you remember to start and stop it each time, which you probably won’t.
Snap updates are automatic because that greatly improves security and reliability for the installed base, and these five problems are assumed solved or solvable. So, how do we solve the last two?
Providing connection-sensitivity wouldn’t involve changes in Software Updater, just in Software & Updates Settings. (And possibly in snapd too, if its rate-limiting is oblivious to whether anything else is using the connection.)
Providing undoability probably does involve changes to Software Updater. Years ago, before snaps, I suggested it should have menus that included an “Updates History” item. I never got as far as designing that view, but that would be the obvious place to select which update you wanted to undo.
That’s a decent idea, but I’d much prefer deferring to be automatic than manual. Is there a use case for deferring, that could not be handled by a combination of settings for “defer whenever I’m on a metered connection” and “defer/trickle whenever I’m using my connection for something else”?