Bug 2124994

Summary:	[dnf5] Provide overall transaction progress
Product:	[Fedora] Fedora	Reporter:	Milan Crha <mcrha>
Component:	dnf5	Assignee:	rpm-software-management
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	42	CC:	daniel.mach, jkolarik, jmracek, jrohel, mblaha, nsella, pkratoch, ppisar, rpm-software-management
Target Milestone:	---	Keywords:	Triaged
Target Release:	---	Flags:	tpopela: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2125232

Description Milan Crha 2022-09-07 16:40:30 UTC

Is it possible to provide overall transaction progress, not only per-package progress?

Consider I'm installing a game, which has a small base package and then a giant data package, which even I do not know about (in the gnome-software), because the package is auto-added into the transaction as a dependency. Calculating progress based on the package the app knows (the base/game package) would be very inaccurate.

The signals from [1] suggest:

a) I get only per-package progress;
b) the 'Action' does not contain download phase.

The dnf command line tool does show overall progress, even when it's split for download and then install. I'd like to be able to show the overall progress to the user in the app, thus it knows the download is slow or any such thing.

[1] https://libdnf.readthedocs.io/en/dnf-5-devel/dnf_daemon/dnf5daemon_dbus_api.8.html#org.rpm.dnf.v0.rpm.Rpm.transaction_action_start

Comment 1 Milan Crha 2022-09-07 16:43:24 UTC

Also, installation (or such) can take a long time. The D-Bus call has the default timeout around 30 seconds. Maybe the expected slow operations should be handled in an async way, aka fire the install request, get back the transaction ID, then wait for a signal notifying about the giver transaction finished. Just an idea, not a mandatory thing.

Comment 2 Milan Crha 2022-09-08 12:06:25 UTC

As I just mentioned in bug #2125232, you send more signals than the .xml D-Bus interface files define, but none of those is an overall progress (unless I overlooked it).

Comment 3 Ben Cotton 2023-02-07 15:09:33 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 4 Aoife Moloney 2024-05-07 15:48:35 UTC

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
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
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Aoife Moloney 2025-02-26 12:52:36 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Comment 6 Jan Kolarik 2025-03-26 09:52:27 UTC

There is now information in dnf5daemon indicating the "everything is done" state after the upstream bug fix: https://github.com/rpm-software-management/dnf5/issues/1189. Is this functionality sufficient, or is anything else needed?

Comment 7 Milan Crha 2025-03-27 07:09:45 UTC

This is not much about "everything is done", this is more about overall progress, like the update usually consists of several stages:

   1. download repo information
   2. check packages to be updated
   3. download the packages
   4. verify transaction
   5. run the transaction
      6. install packages
      7. run post-install scripts
   8. clean up after installation

There are signals for most (if not all) of the 1..8 stages, but giving 1/8th for each of them is not accurate, because they do not take the same portion (the 1. can mean 10 seconds, while the 3. can mean hundreds of packages to be downloaded, then the rest done for the same 100 packages).

The thing is unlike dnf, the gnome-software has only one operation progress bar, the "updating packages", with no label, thus going up and then suddenly down in the progress when moving to the next phase would be very confusing to the user.

I'm afraid you cannot do this anyway. You do not know the size of the operation before finishing the 2., right?