Bug 1382063 - RFE - Expand Upgrade function to optionally perform "offline" upgrades
Summary: RFE - Expand Upgrade function to optionally perform "offline" upgrades
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: All
OS: Linux
low
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-05 15:56 UTC by Gerald Cox
Modified: 2019-07-23 10:00 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1091702 None NEW [rfe] complete-transaction support 2019-09-16 22:39:08 UTC

Internal Links: 1091702

Description Gerald Cox 2016-10-05 15:56:55 UTC
Description of problem:
Please refer to this list discussion:

https://goo.gl/BR8NUf

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.

Thanks!

Comment 1 Igor Gnatenko 2016-10-05 15:58:50 UTC
I agree that --offline makes sense. Unfortunately this is definitely low prio.

Comment 2 Gerald Cox 2016-10-05 16:18:19 UTC
(In reply to Igor Gnatenko from comment #1)
> I agree that --offline makes sense. Unfortunately this is definitely low
> prio.

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.

Comment 3 Kevin Kofler 2016-10-05 21:29:30 UTC
I think complete-transaction (RFE bug #1091702) is a much more practical approach than doing everything offline all the time.

Comment 4 Gerald Cox 2016-10-06 02:46:49 UTC
(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.

Comment 5 Adam Williamson 2016-10-06 04:19:55 UTC
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.

Comment 6 Zbigniew Jędrzejewski-Szmek 2016-10-06 17:33:21 UTC
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).

Comment 7 Gerald Cox 2016-10-09 23:22:25 UTC
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

Comment 8 Jaroslav Mracek 2017-06-26 13:19:31 UTC
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.

Thanks.

Comment 9 Adam Williamson 2017-06-27 23:13:05 UTC
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.

Comment 10 Gerald Cox 2017-06-28 00:19:49 UTC
(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:  
https://goo.gl/BR8NUf

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.

Comment 11 Fedora End Of Life 2017-07-25 23:22:04 UTC
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'
of '24'.

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.

Comment 12 Gerald Cox 2019-01-06 14:22:59 UTC
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?

Comment 13 Jaroslav Mracek 2019-01-07 15:09:42 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.