Hide Forgot
Description of problem: No progress is being printed after Cleanup is done, right before Verification. I've found out that mandb was indexing all man pages (on one CPU core). Is it possible to show more progress messages when doing mandb indexing (or post scripts?)? Maybe to use more verbose from dnf core to show for `PlymouthOutput`. When I was upgrading a one message "[5813/5813] Clean libgcc-5.3.1-6" hung there for 20-30 minutes. To me (or to other users) it looked like the update has hanged. I am not sure if this should be improved in system-upgrade plugin or dnf core. How reproducible: When upgrading system, e.g. from F23->F24 or F24->F25. Steps to Reproduce: 1. dnf system-upgrade --releasever 25 download 2. dnf system-upgrade reboot Actual results: No progress messages after Cleanup transaction, right before Verify. One message hangs there for several minutes. Expected results: Display message(s) between Cleanup and Verify. It could be something like: "Regenrating man index... This may take several minutes." Additional info: You need to have a root password set to check login to system while upgrading. (Other user logins are disabled/locked.)
This is a DNF/RPM problem - DNF doesn't display the output from scriptlets, and scriptlets don't have any other way to report progress.
well, it's RPM working there (I guess filetriggers)...
yeah - %transfile*, %posttrans*, etc. There *are* RPM callbacks for these events but AFAIK they're not documented as public and therefore DNF doesn't handle them. See e.g. bug 1246600.
Eh? Not to excuse for bad/missing documentation, but the script start/stop callback events aren't any less documented than the rest of the callback events, which dnf is merrily using.
Yeah, but (at least the last time I looked) the DNF team doesn't want to add stuff that yum didn't use without it being documented as part of RPM's public API, but nobody on either team has had the time or inclination to do that, so it's not been done. See the DNF side of the discussion here: https://github.com/rpm-software-management/dnf/pull/281#issuecomment-124263743 DNF-2.0 actually dropped support for RPMCALLBACK_SCRIPT_START, since it was still unused by the rest of DNF: https://github.com/rpm-software-management/dnf/commit/25e626d So. This situation could certainly be improved, but it's unfortunately not possible for dnf-plugin-system-upgrade to fix it.
Dnf itself may have special rules about documentation required for something to be considered public but they shouldn't expect every other project to follow the same rules. Whether something is rpm public API doesn't depend on documentation, it depends on what *is* public: If it's in the public headers then it's a public API, and that's all there is to it. On python side the standard underscore-prefixing is used to mark something private, IIRC there isn't a whole lot that is private though. Just FWIW.
*** Bug 1412086 has been marked as a duplicate of this bug. ***
I tried to fulfill your request. Here is pull request: https://github.com/rpm-software-management/dnf/pull/763.
Appreciated. Thank you Jaroslav! Will the messages be visible by default or does the verbose have to be on. If the later, then consider turning on the verbose on `system-upgrade`.
Well so far it will be visible by defaults. But to be exact PR shows starting scriplets for each package but there is no progress bar because it is not supported by rpm. They don't know how long each scriplets will take. But the PR should really help, because usually scriplets are short.
Showing messages when running scriplets is enough for me (almost as showin progress). There are some scriplets that run `mandb`. I am not sure if its run per each package, or dnf has some trigger and runs it itelf. On system upgrade, when (almost) all packages are being upgraded, that mandb takes too long. (see comment #0)
dnf-2.2.0-1.fc26, libdnf-0.8.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-65586fa42b
dnf-2.2.0-1.fc26, libdnf-0.8.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.