Description of problem: I've tested dnf on my Rawhide installation when 'yum upgrade --skip-broken' was unable to resolve dependencies and it has ignored many package from upgrade transaction (Bug863044). While the transaction has been nicely resolved and 3/4 of package has been properly marked for upgrade, the download part it self has been pretty slow compared with 'yum' performance here. My DSL provider has pretty decent connection speed and individual package download rate was above 1MB/s - however between the download of each package there was quite noticeable delay in range of 2-3 seconds (which sums up, when >100 packages is upgraded) Version-Release number of selected component (if applicable): dnf-0.3.8-2.git85524ae.fc20.noarch How reproducible: Steps to Reproduce: 1. dnf upgrade 2. 3. Actual results: Expected results: Additional info:
I saw this too, some digging needs to take place to decide whether this is a librepo issue or whether we do something strange ourselves. Low prio at this point.
The observed delay before download start is due to how the progress bar is implemented: it is waiting for librepo to tell us the total package size, which for some involved reasons can not do so right away, even though the download has already started. As zpavlas pointed out we should be able to deduce this information from the available metadata instead. Assigning to zpavlas who already did patching in this area. Notwithstanding the console output the total download time is probably going to be larger than in the current Yum versions due to the missing support of parallel package downloads (bug 909744).
(In reply to Ales Kozumplik from comment #2) > The observed delay before download start is due to how the progress bar is > implemented: it is waiting for librepo to tell us the total package size, Actually, this is only a part of the problem. As I found out today, most time is lost because DNF creates an extra librepo handle for each package download and these need to sync the mirrorlist first to know the real repo URL ("baseurl"). And that takes most of the extra time.
Fixed the mirrorlist syncing (commit fecb703, will be in dnf-0.3.11), on a fast network this speeds up download of each package by approx. 1.5s. I consider this resolved then, and opened bug 988377 to deal with the progress bar dealy.
dnf-0.3.11-1.git7d717c7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dnf-0.3.11-1.git7d717c7.fc19
Package dnf-0.3.11-1.git7d717c7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.3.11-1.git7d717c7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14693/dnf-0.3.11-1.git7d717c7.fc19 then log in and leave karma (feedback).
dnf-0.3.11-1.git7d717c7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.