On Tue, Oct 4, 2016 at 10:37 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Oct 4, 2016 at 11:26 AM, Andrew Lutomirski
> On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
>> On Tue, 4 Oct 2016 09:51:16 -0700
>> Andrew Lutomirski <luto(a)mit.edu> wrote:
>>> By that standard, why do we support dnf at all?
>>> $ sudo dnf upgrade
>>> Error: dnf upgrade is dangerous. Use PackageKit instead and reboot
>>> when asked.
>>> I, for one, *like* not rebooting, and I'm perfectly capable of
>>> rebooting manually if stuff breaks. As far as I know, Fedora
>>> considers plain ol' dnf to be supported.
>> Well, the problem there, what do you mean by 'support'?
>> In this case lots of people use dnf for updates, so IMHO it would be
>> "we will try and keep this working, and fix anything we can, but do
>> understand that there's a low level problem here that something could
>> mess up updates in progress, if you want to be more sure of not hitting
>> problems, use the offline updates in your graphical desktop"
>>> For server use, I'm not convinced that the offline update mechanism is
>>> supported (at the very least, I have no idea how to trigger it), and
>>> servers have the same issue.
>> Much less so. In the server case you have usually ssh, bash and dnf, in
>> the desktop case you have X, possibly wayland, tons of graphics
>> libraries, the terminal application you are using and all it's
>> libraries, and a shell and dnf. There's just a lot more there to
>> possibly crash.
> My point is that a lot of this exposure could be avoided. Sure,
> there's a decent chance that updating packages will crash running
> programs. But, unless one of those programs is dnf, rpm, or systemd,
> that shouldn't be an excuse to blow up the whole upgrade.
I think it's avoided by propagating the point adamw started the thread for.
User: Doctor, it hurts when I do this!
DocAdamW: So then don't do that!
Do users need an INFO message when running 'dnf update' to kill off
the myth that without a warning it's expected to be reliable? Maybe.
I've pondered this a bit, and I think I disagree with you.
A more apt analogy would be:
User: Doctor, it hurts when I walk.
Doctor: So don't walk.
The System Administrator's Guide tells people to use dnf . I agree
that, in the long run, online updates of the system are probably the
wrong solution. But the long run isn't here, and we could do a whole
lot better than we do right now with a straightforward change.
> I've had
> Firefox blow up many times due to concurrent dnf, but this doesn't
> hose my system. Having gnome-terminal or X or Wayland die shouldn't
> be any more dangerous.
I don't understand how you arrive at this conclusion. dnf is sitting
on the top of a house of cards when it's running in Terminal. If
anything below it dies, dnf dies and by extension so is rpm. Could dnf
be put into it's own session or scope (whatever it's called), and
would that prevent it from dying if the whole GUI died?
Yes. dnf would prepare the transaction, solve dependencies, etc, and
then kick off a service to do the actual work. The service would pipe
the progress state and such back to the client.
Even if true,
how does the user know to wait XX minutes before hitting the reset
button? I think it's a rabbit hole, just stop touching the owie.
In my entire experience administering Linux machines, I have *never*
had serious package problems due to a transaction failing for any
reason *other* than loss of the session that the package manager is
running in. So I really do think it's a 90% solution to the problem
that doesn't even require changing anyone's workflow.
So I filed the RFE. I think this should also be a prerequisite for
the KillUserProcesses change.