Bug 1488639
| Summary: | dnf package install very slow, scriptlet related? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ben Greear <greearb> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | dmach, greearb, jmracek, john.sincock, jss, mblaha, mluscon, packaging-team-maint, rpm-software-management, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-20 11:08:28 UTC | 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: | |||
|
Description
Ben Greear
2017-09-05 22:54:59 UTC
please run dnf with --rpmverbosity=debug and paste output... and tell which exact scriptlet takes long to run. I notice that the --rpmverbosity=debug does not add any timestamps, so it would not be obvious from the logs what is taking a long time. I tried a simple test of removing and re-adding freeradius, and that was not too slow this time, so probably I will have to reproduce using a more complex command (which is going to generate a large amount of logs). Is there any way to get timestamps in the output so you we can see exactly what is taking a long time? This doesn't seem to be something DNF can fix. The fix has to be made in individual scriptlets. This is a bug. I've just updated a bunch of packages on RHEL 8, and the amount of time spent running stupid little scriptlets was obscene. There is no excuse for it. It is no good saying the fix needs to be made in individual scriptlets, when suddenly, in EL8, it seems almost every rpm runs a scriptlet, and they're all dog slow. It's just pathetic. oh my god the cleanup stage is also running scriptlets and some of them are slow too, this is just unbelievable. Nearly 4 years on, and no improvement. Package installations via DNF are still insanely slow. Absolutely pitiful. With all due respect to your frustration, I believe you are barking up the wrong tree here. DNF cannot do much to improve the situation. Packages rely on the execution of scriptlets during both installation and removal phase, and not executing them would certainly cause more harm. Instead, you can try to identify the specific scriptlets that are causing slowdowns and report the issues to their respective packages. Feel free to let me know if you have any further questions or if there's anything else I can assist you with! With all due respect, as a sysadmin who has been regularly patching EL5,6,7,8,9 servers, for many years now, i can tell you for a fact that installing packages via dnf in EL8 is appallingly slow compared to yum on EL7. I am not interested in excuses or blame-shifting from dnf to the individual packages. The problem is not the individual packages, the problem, is that installing packages is always slower on el8. Although, sure, maybe it's not dnf. The dependency resolution is not the thing that is slow, so, the issue is indeed more likely to be the rpm command itself, not dnf as such. Whatever. Whether it is dnf, or rpm, or some stupid librpm interface, I don't care. The simple fact is that when installing a bunch of packages - el7/yum/rpm manages to install packages much, much faster than el8/dnf/rpm. And people were complaining about the problem in this ticket 6 years ago, in 2017, and there has been no improvement, just people pretending there is no problem. And that is pathetic. |