Description of problem:
Please refer to this list discussion:
PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24
As I mentioned in the thread, I have been using DNF since day 1 - and have never had an issue with it. The only time I've had a problem with updates was when I used packagekit a few times and ended up being hit by this: https://bugzilla.redhat.com/show_bug.cgi?id=1259865
If this is indeed an issue to be concerned about, then I would think that the premier tool for Fedora should be able to handle it for all upgrades - especially since the capability is there which allows DNF to do offline upgrades for system-upgrades via the dnf-plugin-system-upgrade.
I realize this may not be a high priority, and that DNF 2 is coming, but hopefully you'll have time to consider and address.
I agree that --offline makes sense. Unfortunately this is definitely low prio.
(In reply to Igor Gnatenko from comment #1)
> I agree that --offline makes sense. Unfortunately this is definitely low
Thanks... and from my experience I would tend to agree that the other things the DNF team is working on will provide more value. You of course have to prioritize based upon risk/benefit. That being the case, I wish the risk of "not doing offline upgrades" be more properly communicated in posts, etc. Making blanket statements which imply there is a greater risk than what actually exists is not really helpful and just needlessly worries people.
I think complete-transaction (RFE bug #1091702) is a much more practical approach than doing everything offline all the time.
(In reply to Kevin Kofler from comment #3)
> I think complete-transaction (RFE bug #1091702) is a much more practical
> approach than doing everything offline all the time.
Kevin, that may well be. I don't know. I just thought that since the DNF team had already done the work for dnf-system-update-plugin this might be a relatively quick stop gap solution for them to implement.
I believe though that all it should be a unified Fedora solution and not piecemeal with every DE doing their own thing.
Additionally, it would be nice down the road for DNF to recognize what requires a reboot by itself and segregate that automatically, while going ahead and processing those items that don't online. In that way you are minimizing the need for reboot and only doing it when required - but small steps.
I strongly disagree that attempting to patch up a crashed operation is better than trying to prevent the operation crashing in the first place, but this isn't really an either/or question, so we don't need to argue it too much.
Implementing this would be a matter of slightly generalizing dnf system-upgrade to allow arbitrary transactions. It would probably be beneficial for the case when upgrading to a new release too, since various common issues might get fixed (e.g. #1324151).
In reference to comment 4, it appears that work already has been done to determine which applications need a system reboot or simply restarted via
the needs-restarting plugin or the tracer plugin: https://goo.gl/ZFS29E
which has a database of application's classification which can be
viewed here: https://goo.gl/Rgwyrt
I would like to implement the feature requested here, but I need additional information about your expectations. I already created a patch for system-upgrade (https://github.com/rpm-software-management/dnf-plugins-extras/pull/97) where it will not install downloaded packages from commandline but it installs packages directly from repos during reboot (offline).
Please how do you want to handle it:
Do you want to prepare, download and save transaction and then perform it during reboot (like system-upgrade)?
Please any additional information will be very useful. The best would be to provide user-cases where I can find out a solution for them.
Well, I mean, the use case is "update the system", it's that simple. The suggestion is simply to make it possible to perform system *updates* offline, in exactly the same manner as system *upgrades*, since in many ways we adopt the position that doing this is safer, and indeed Workstation does updates offline by default.
So: at least so far as I understand it, the request is simply for the ability to do a 'dnf update' transaction offline, so the same set of packages that would be installed by 'dnf update' is downloaded and prepared, then the system is rebooted and the actual update transaction occurs offline, then the system is rebooted back again.
(In reply to Jaroslav Mracek from comment #8)
> Please how do you want to handle it:
> Do you want to prepare, download and save transaction and then perform it
> during reboot (like system-upgrade)?
Yes, that is correct - have it behave in the same manner as system-upgrade.
> Please any additional information will be very useful. The best would be to
> provide user-cases where I can find out a solution for them.
Background information regarding this can be found:
Comment #1 mentions implementation via --offline which to me appears to be a good idea and the ability to permanently set the option via dnf.conf would also be nice.
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Can someone please give an update to this? From the comments above I was under the impression it was being actively worked, but since this has
been languishing now for over 2 years, seems not to be the case?
I am really sorry that implementation of that feature is delayed, but first we need to deliver new Software DB that is one of the pre-requisition of the RFE. Additionally it requires refactor of System-upgrade plugin, therefore it is not easy task. We really want to delivery the perfect solution.