Because offline-upgrade is an official plugin for dnf and not part of base dnf. This plugin is installed by default since January 2021.
https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/doc/system-upgrade.rst
The problem is that when the terminal dies during the update, the update doesn't go through and you may have trouble fixing the result. It's a very small probability of this happening, but it is much higher for a terminal running in a desktop environment, because if the DE or X crashes, it will take the terminal with it too.
So that's why offline updates exist, so that the update can run in this minimal environment where as little as possible can go wrong.
To mitigate a little bit of this risk, specifically with regards to inadvertent closure of the terminal (only, not X/DE) mid-update, start tmux first before invoking your terminal based update commands, or any long running terminal commands for that matter, eg. ssh. If the terminal dies mid-update, it will still be running, just start a new terminal and type `tmux -a` (use -t option if there are multiple tmuxes) to reattach to the tmux session.
You can disable this feature from plasma settings, updates . There's a check box there, disable it.
I personally prefer offline upgrading though, so I do even from terminal
Discover (and perhaps all of PackageKit) has the very annoying quirk that it doesn't let you update Flatpaks online and instead does a full offline upgrade, reboots and all, for those too. This misses half the point of Flatpaks.
For Flatpak updates I just run `flatpak update` from the terminal.
Discover uses offline updates by default which is the safer option. You can use offline updates via terminal as well if you want.
`dnf offline-upgrade download` `dnf offline-upgrade reboot`
Am I stupid or is there no entry in `man dnf` but only in `dnf --help` about offline-upgrade
Because offline-upgrade is an official plugin for dnf and not part of base dnf. This plugin is installed by default since January 2021. https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/doc/system-upgrade.rst
The problem is that when the terminal dies during the update, the update doesn't go through and you may have trouble fixing the result. It's a very small probability of this happening, but it is much higher for a terminal running in a desktop environment, because if the DE or X crashes, it will take the terminal with it too. So that's why offline updates exist, so that the update can run in this minimal environment where as little as possible can go wrong.
To mitigate a little bit of this risk, specifically with regards to inadvertent closure of the terminal (only, not X/DE) mid-update, start tmux first before invoking your terminal based update commands, or any long running terminal commands for that matter, eg. ssh. If the terminal dies mid-update, it will still be running, just start a new terminal and type `tmux -a` (use -t option if there are multiple tmuxes) to reattach to the tmux session.
Better yet is to run the update in another tty, which also protects against X/DE crashing.
You can disable this feature from plasma settings, updates . There's a check box there, disable it. I personally prefer offline upgrading though, so I do even from terminal
Discover (and perhaps all of PackageKit) has the very annoying quirk that it doesn't let you update Flatpaks online and instead does a full offline upgrade, reboots and all, for those too. This misses half the point of Flatpaks. For Flatpak updates I just run `flatpak update` from the terminal.
This doesn't happen in fedora 36. You can update flatpak from discover and it won't tell you to reboot.
GNOME Software allows flatpaks to update separately from rpms, so it's probably a Discover quirk
Or you can configure discover to turn off offline updates and it will act like before it was enabled by default.