Red Hat Bugzilla – Bug 1283601
dnf system-upgrade redownloads everything after errors
Last modified: 2015-11-19 14:59:13 EST
Description of problem:
After erasing packages, to resolve conflicts or problems with repositories that time out, and rerun "sudo dnf system-upgrade download --releasever=23", dnf ignores the packages that are in the cache and redownloads everything. In my case, this means that to correct two minor problems (the repository from which I had installed opera was timing out, and google earth has a permission conflict) which would involve uninstalling these two packages and trying again, I had to download six gigabytes of data.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install a package that is known to produce conflicts. E.g., install google-earth-stable-220.127.116.117-0.x86_64.rpm from google, using rpm --force
2.If you install the above rpm: chmod -w /usr/bin, to restore the permissions in /usr/bin, which the rpm will change.
3.sudo dnf system-upgrade download --releasever=23
4.sudo dnf erase google-earth-stable-18.104.22.1687-0.x86_64
5.sudo dnf system-upgrade download --releasever=23
On step 5, the packages downloaded in step 3 are downloaded again.
Tons of "[SKIPPED]" messages, with no packages downloaded.
If no packages are removed, and a repository times out during the download, then
retrying "sudo dnf system-upgrade download --releasever=23" will produce the expected "[SKIPPED]" messages, so the functionality is there, but not invoked.
These are the messages from the last failed run, showing that dnf claims to have kept the downloaded packages in the cache:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache till the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of filesystem-3.2-35.fc23.x86_64 conflicts with file from package google-earth-stable-22.214.171.1247-0.x86_64
Yeah, we are working on it.
*** This bug has been marked as a duplicate of bug 1276886 ***