On Tue, Oct 4, 2016 at 10:37 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 4, 2016 at 11:26 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: >>> On Tue, 4 Oct 2016 09:51:16 -0700 >>> Andrew Lutomirski <luto@xxxxxxx> 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 [1]. 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. https://bugzilla.redhat.com/show_bug.cgi?id=1382224 [1] https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/sec-Installing.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
