On Mon, Jul 17, 2017 at 6:53 AM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
On Mon, Jul 17, 2017 at 12:45:27PM +0200, Michael Stahl wrote:
> On 16.07.2017 14:10, Kevin Kofler wrote:
> > Debarshi Ray wrote:
> >> How about reliable online updates of running applications as a
> >> benefit?
> > Upgrading RPM applications online just works. I do it all the time. The KDE
> > tools do not even implement offline updates (and IMHO that's a good thing).
> > The worst that can happen is that some recalcitrant applications (by far the
> > minority) need to be restarted after updating (or if you upgraded the whole
> > desktop, then your session may need to be restarted after updating). Until
> > you do that, the current session may be "hosed" to some extent, but
> > restarting will fix it.
> no, the worst case is this:
I had this kind of fun problem upgrading F25 -> F26. I was lazy and didn't
want to reboot so I was just running dnf distro-sync in a gnome-terminal
session. I've upgrade this way since F6 and mostly it just works, but
forgot to nohup it. About 1/3 of the way through installing new packages,
something causes gnome-terminal to die. I had to write a script to read
the dnf planned transaction log and finish installing and erasing remaining
packages, and manually run any %posttrans scripts.
So yeah, even with latest Fedora things can & do go horribly wrong if you
ignore the advice to not run upgrades from a live system.
This happens because DNF doesn't spawn a process in the background to
do this. When you use dnfdragora or a PackageKit frontend, you get
that benefit, because the actual transaction isn't being done by the
user interface process.
In the case of dnfdragora, the dnfdaemon handles it. In the case of
things like GNOME Software, Plasma Discover, etc., the PackageKit
daemon handles it.
A relatively simple enhancement would be to have DNF self-daemonize
when it does transactions through the CLI, so that issues like that
真実はいつも一つ！/ Always, there's only one truth!