>>> I find the idea of offline update rather odd: not only it's inconvenient
>>> since the machine is unusable during this time, but on top of it, in
>>> case of trouble, it can make it harder to fix the problem because you
>>> may not be able to boot into a conveniently-usable system.
>> That was my feeling, too. Only very involved scenarios came to mind,
>> like "you have connectivity now, but are running on battery, and later
>> you'll have AC power but no connectivity" or something.
That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already. No need to reboot into a special mode to perform
the install.
> Offline update has disadvantages, but it makes sure that every programs are
> restarted, thus avoiding strange issues or crashes due to conflicts in
> libraries versions ([1] is a KDE article that very briefly explaining
> this). In an another article I could not find anymore, someone from KDE
> explains that they receive many bug reports where issues comes from system
> update without reboot (I would also be interested to know what is "many"
> here).
Rebooting after the updates is different from the offline update you describe.
> Indeed, in a perfect setup, system should make a snapshot before updates are
> applied (see 6. in systemd.offline-updates manpage, note that I have not
> heard it is done yet by any distribution by default), and revert the changes
> if the update fails.
[ Agreed. Ideally the updates should be performed in a "clone" of the current
system, and only after it's done and sanity-checked should we switch to
the new system. We've known how to do that for many years (thanks to
IBM's main frames, for example). ]
> Anyway, being able to fix a system that has been broken by *online*
> updates is only relevant if the user has technical skills to do so.
But that is no different than for offline updates, is it?
> Windows, targeting both technical and non technical users, does exactly
> this. I did not use an Apple system for years, but I think it was quite
> similar for system updates. Please don't byte me ;-)
Indeed. But they have different trade-offs. They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box. Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".
Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.
Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.
Stefan "sorry for having hijacked your thread"
