Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 4, 2016 at 5:49 PM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:
> Chris Murphy writes:
>
>> > Seems to me it
>> > would be more worthwhile to build in better error recovery within DNF
>> > than
>> > to always require "offline" - especially
>> > since the incidence of failure (at least anecdotally) just isn't that
>> > high.
>>
>> Sufficiently impractical that it's not possible.
>
>
> Wrong.
>
> I can make any process survive an X shutdown, using an amazing tool called
> "tmux".
>
> Why can't dnf do the same?

I suggested earlier in the thread that it automatically put itself in
its own scope. But I don't know if that solves this problem, and even
if it does it's only one part of a much bigger set of problems that
can cause updates to implode. In this case, sure maybe dnf survives,
but X is gone, the user has no idea what just happened, they have no
idea dnf is still applying their updates in the background, so they
don't know they shouldn't reboot.

When you start making the list of things that have to work exactly
right for system updates in a GUI , you get basically two things:

1. fuck it, we're making the user log out and do the update offline, and;

2. fuck it, we're doing something completely different ala OSTree, ala
Snapper, so the user can do a rollback if things go wrong.

The first is what happens on the other 90% of the world's computers,
including Android system updates. Consider that. The second exists,
right now, and it works and it's a lot better than what the rest of
the world uses.

Strictly speaking Fedora doesn't make you do the first one, but it's
*well* understood for a long time how fragile this is which is why
offline updates was created.


>> It's why openSUSE has spent a ton of resources, and a few bloody
>> noses, getting completely atomic updates working with Btrfs and
>> snapper, with very fine rollback capabilities.
>
>
> You do not need atomic updates to install a signal handler for SIGHUP or
> SIGTERM. And maybe issue a setsid() call, beforehand.
>
> This shouldn't be rocket science.

OK you clearly don't understand the complexity. So go ahead and do
things your way, and when you don't like the result from hitting the
Hurt Me Button, complain and criticize people all you want, wait for
the silence from those who could not give two shits, which means: stop
doing things wrong, start doing them correctly, or fix it all yourself
Mr. Genius. And then go write your own updater.


-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux