> On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek <jmracek(a)redhat.com> wrote: > > Does that mean the issues with dnf [2] we able to be solved all the > time but just weren't investigated? The issue was investigated also with DNF, but the issue was well hidden, because the code uses hard coded set for downloaded elements. For most investigation we used the biggest repository (Fedora) that showed a high memory usage and we tried to mitigate what can we do to improve the situation. The real issue was with update repository that surprisingly uses slightly more RAM then fedora repository. With DNF5 we reinvest it as a completely different issue. DNF5 has a better option for investigation that allow us to discover the real source of the issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore we continued to search in other directions. Basically we were surprised why we got the report with DNF5 because we know that RAM usage was improved with DNF5 and default setting. It means that there where two issues that overlaps with symptoms but has a different reproducers. Solving the first one (too big metadata to process) uncover the second issue with processing updateinfo metadata. The status of the issue - We have to wait until our patch is reviewed and merged in libsolv and we have to wait until libsolv creates the upstream release, because downstream of libsolv in Fedora is not under DNF team control and the main admin doesn't like any downstream patches. Best regards Jaroslav _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
