Bug 1382063

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
> 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.

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.

Thanks.

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:  
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.

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.

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.

(In reply to Jaroslav Mracek from comment #13)
> 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.

Looks like the new software database was done a few years ago... 
https://bugzilla.redhat.com/show_bug.cgi?id=1563260

Is this still being considered or has it been decided it isn't needed?

Could you install dnf-plugin-system-upgrade (python3-dnf-plugin-system-upgrade package) and try `dnf offline-upgrade`?
It has been implemented already and we forgot to update this bug.

(In reply to Daniel Mach from comment #15)
> Could you install dnf-plugin-system-upgrade
> (python3-dnf-plugin-system-upgrade package) and try `dnf offline-upgrade`?
> It has been implemented already and we forgot to update this bug.

Thanks for the quick reply, this is great news!

I tried it out and have the following comments:

1.  Unless I'm missing something, this appears to be an all-or-nothing
solution.  In other words, all updates are offline.  Comment #4 and #7
mention that some updates are safe to do online, while others are not.  
I realize this is the first iteration, but it would be nice if 
this could be done.

2.  The documentation is a bit confusing:
https://readthedocs.org/projects/dnf-plugins-extras/downloads/pdf/latest/

It explains the system upgrade portion very well, but only infers
how to use this for offline upgrades.  I figured it out, but other
people may not.  

Again, great news this is available.  It goes a long way to resolving
dnf upgrade issues.

Ooh, this is cool. DNF team, would you consider submitting this as a Fedora 33 self-contained change? That will help us remember to publicize it, and also help the docs team know to update various docs.

I am really sorry but we cannot make self contain change for Fedora 33 because the window is already closed. The feature is typical RFE that does not require any approval. Anyway offline-upgrade and offline-distrosync commands are already present in Fedora 32+ (python3-dnf-plugin-system-upgrade-4.0.9).