Is offline-upgrade option removed in dnf5?

neotux · June 25, 2023, 11:52am

sudo dnf offline-upgrade download
Unknown argument "offline-upgrade" for command "dnf5". Add "--help" for more information about the arguments.

I have used this option mostly when I haven’t been updating my Fedora box for some time and there are many packages to update.

Isn’t offline-upgrade supported with dnf5anymore?

vekruse · June 25, 2023, 12:06pm

dnf5 is still in rapid development, so it might not have been implemented yet.

neotux · June 25, 2023, 12:15pm

Thanks for the reply @vekruse!

I do really like this option and find it useful. So there might be a chance that it will be implemented later on? Let’s hope so!

jn64 · June 25, 2023, 12:19pm

Refer to pinned issues in the dnf5 repo tracking progress of the various commands.

neotux · June 25, 2023, 12:25pm

Thank you so much for posting the link! That’s really helpful! I will keep an eye on its progress.

Edit: I see that there is already a discussion going on:

github.com/rpm-software-management/dnf5

System upgrade and offline transactions (upgrade, distrosync, ...)

opened 09:50AM - 30 Jan 23 UTC

j-mracek

Priority: MEDIUM

In DNF there is a possibility to perform offline upgrade for limited transaction…s and command. I suggest to extend the functionality to allow for any transaction operation offline upgrade and provide the functionality in API of LIBDNF5. Components requiring that kind of functionality - DNF - system-upgrade - offline-upgrade - offline-distrosync - PackageKit - LEAPP - Convert2rhel - Imagebuilder The workflow should be split to multiple steps: - [ ] Creation transaction, download packages and storing of transaction - Store all required data to perform identical transaction after reboot - DNF4 implementation is good but not perfect - not storing package or group reasons - Store group planned operation - Store module planned operation - [ ] reboot or running in container Primary implement rebooting mechanism like DNF4 system-upgrade uses. LEAPP uses an alternative way of running stored transaction. It is superior to DNF approach for system upgrade, because it uses rpm from target system, but there are also some weak sides. - [ ] loading of stored transaction and performing We need to ensure that the transaction will be identical to approved in step 4 from multiple sides - RPM content, groups, modules, history DB and System-state We can: - store more information about transaction (reason, package checksum, ...) - add check step that replayed transaction is identical - removed packages are not checked much in DNF4. - alternatively we don't need to rerun libsolv transaction - transaction itself is verified by RPM - ensure that RPMs are still identical what we stored (checksums + length) - optionally - system was not changed - rpm content - using RPM cookies - requires a new way how to update history DB, system state, and filling RPM transaction