Description of problem: You can see what happened below. As can be seen, DNF had re-downloaded all the packages, while they are supposed to remain in cache when installation has not succeeded. ------------------------------------------------------------------------------- []# dnf install bitcoin -y Bitcoin for Fedora - x86_64 4.0 kB/s | 27 kB 00:06 Last metadata expiration check performed 0:00:02 ago on Sun Jun 7 02:40:16 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: bitcoin x86_64 0.10.2-1.fc22 bitcoin 3.2 M libdb4 x86_64 4.8.30-16.fc22 fedora 610 k libdb4-cxx x86_64 4.8.30-16.fc22 fedora 639 k openssl-compat-bitcoin x86_64 1:1.0.2a-2.fc22 bitcoin 391 k openssl-compat-bitcoin-libs x86_64 1:1.0.2a-2.fc22 bitcoin 1.2 M Transaction Summary ================================================================================ Install 5 Packages Total download size: 5.9 M Installed size: 16 M Downloading Packages: (1/5): openssl-compat-bitcoin-1.0.2a-2.fc22.x86 11 kB/s | 391 kB 00:35 (2/5): bitcoin-0.10.2-1.fc22.x86_64.rpm 34 kB/s | 3.2 MB 01:34 (3/5): openssl-compat-bitcoin-libs-1.0.2a-2.fc2 16 kB/s | 1.2 MB 01:14 (4/5): libdb4-cxx-4.8.30-16.fc22.x86_64.rpm 5.0 kB/s | 639 kB 02:07 (5/5): libdb4-4.8.30-16.fc22.x86_64.rpm 11 kB/s | 610 kB 00:53 -------------------------------------------------------------------------------- Total 36 kB/s | 5.9 MB 02:49 warning: /var/cache/dnf/x86_64/22/bitcoin/packages/bitcoin-0.10.2-1.fc22.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID a4360c84: NOKEY Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-bitcoin [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-bitcoin] []# rpm -Uvh http://linux.ringingliberty.com/bitcoin/f20/x86_64/bitcoin-release-1-6.noarch.rpm Retrieving http://linux.ringingliberty.com/bitcoin/f20/x86_64/bitcoin-release-1-6.noarch.rpm warning: /var/tmp/rpm-tmp.sUTSQ0: Header V4 RSA/SHA1 Signature, key ID a4360c84: NOKEY Preparing... ################################# [100%] Updating / installing... 1:bitcoin-release-1-6 warning: /etc/yum.repos.d/bitcoin.repo created as /etc/yum.repos.d/bitcoin.repo.rpmnew ################################# [100%] []# dnf install bitcoin -y Last metadata expiration check performed 0:07:58 ago on Sun Jun 7 02:40:16 2015. Dependencies resolved. =============================================================================================================== Package Arch Version Repository Size =============================================================================================================== Installing: bitcoin x86_64 0.10.2-1.fc22 bitcoin 3.2 M libdb4 x86_64 4.8.30-16.fc22 fedora 610 k libdb4-cxx x86_64 4.8.30-16.fc22 fedora 639 k openssl-compat-bitcoin x86_64 1:1.0.2a-2.fc22 bitcoin 391 k openssl-compat-bitcoin-libs x86_64 1:1.0.2a-2.fc22 bitcoin 1.2 M Transaction Summary =============================================================================================================== Install 5 Packages Total download size: 5.9 M Installed size: 16 M Downloading Packages: (1/5): libdb4-cxx-4.8.30-16.fc22.x86_64.rpm 16 kB/s | 639 kB 00:40 (2/5): openssl-compat-bitcoin-1.0.2a-2.fc22.x86_64.rpm 7.3 kB/s | 391 kB 00:53 (3/5): libdb4-4.8.30-16.fc22.x86_64.rpm 18 kB/s | 610 kB 00:34 (4/5): openssl-compat-bitcoin-libs-1.0.2a-2.fc22.x86_64.rpm 9.9 kB/s | 1.2 MB 02:00 (5/5): bitcoin-0.10.2-1.fc22.x86_64.rpm 18 kB/s | 3.2 MB 03:00 --------------------------------------------------------------------------------------------------------------- Total 27 kB/s | 5.9 MB 03:47 warning: /var/cache/dnf/x86_64/22/bitcoin/packages/bitcoin-0.10.2-1.fc22.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID a4360c84: NOKEY Importing GPG key 0xA4360C84: Userid : "Bitcoin RPM Repository <bitcoin>" Fingerprint: 179A 8CC0 90B4 95B2 4620 E172 FC6E 7E4E A436 0C84 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-bitcoin Key imported successfully Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : openssl-compat-bitcoin-libs-1:1.0.2a-2.fc22.x86_64 1/5 Installing : openssl-compat-bitcoin-1:1.0.2a-2.fc22.x86_64 2/5 Installing : libdb4-4.8.30-16.fc22.x86_64 3/5 Installing : libdb4-cxx-4.8.30-16.fc22.x86_64 4/5 Installing : bitcoin-0.10.2-1.fc22.x86_64 5/5 Verifying : bitcoin-0.10.2-1.fc22.x86_64 1/5 Verifying : libdb4-cxx-4.8.30-16.fc22.x86_64 2/5 Verifying : openssl-compat-bitcoin-1:1.0.2a-2.fc22.x86_64 3/5 Verifying : openssl-compat-bitcoin-libs-1:1.0.2a-2.fc22.x86_64 4/5 Verifying : libdb4-4.8.30-16.fc22.x86_64 5/5 Installed: bitcoin.x86_64 0.10.2-1.fc22 libdb4.x86_64 4.8.30-16.fc22 libdb4-cxx.x86_64 4.8.30-16.fc22 openssl-compat-bitcoin.x86_64 1:1.0.2a-2.fc22 openssl-compat-bitcoin-libs.x86_64 1:1.0.2a-2.fc22 Complete! ------------------------------------------------------------------------------- Version-Release number of selected component (if applicable): dnf-1.0.0-1.fc22.noarch
Dnf also re-downloads all packages to be installed (and downloaded previously) after this type of error: Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: installing package firefox-38.0.1-6.fc22.i686 needs 13MB on the / filesystem Error Summary ------------- Disk Requirements: At least 13MB more space needed on the / filesystem. [root@lin ~]#
I've just hit the same bug and it is incredibly annoying. I have a update transaction that is failing due to file conflicts like this: file /usr/bin/git from install of git-2.4.3-2.fc22.x86_64 conflicts with file from package git-core-2.4.3-1.fc22.x86_64 This is terribly difficult to debug as each run of DNF has to download ~300 MiB of packages over and over again. I can't imagine a situation where deleting the packages after transaction failure would be the right thing to do. IMHO it is safe to assume that the user will sooner or later want to finish the transaction successfully, so that the downloaded packages will be useful. If someone is running so tight on disk space that some megabytes of extra packages lying around would be a problem, there's dnf clean for that. Given the ratio of common HDD sizes and connection speeds, it is in any case worse to re-download than to use more diskspace.
The git package update issue is discussed in bug 1231736 and here the reported issue seems to me related to keepcache issue reported in bug 1220074
Yes, this bug is a duplicate of bug 1220074. Can anyone please mark it as such?
Done (In reply to Tomáš Trnka from comment #2) > I can't imagine a situation where deleting the packages after transaction > failure would be the right thing to do. I'm not saying that this is the rationale behind the current behaviour but maybe I can help you to imagine the situation. Actually the current problem with git is a good example. People who know these "file X conflicts between attempted installs" errors know that this is a packaging problem and that there is no reason to try to install git*-2.4.3-1.fc22 packages again because the attempt will always fail. They has to install the earlier version or wait for the next version. Anyway, they will never install git*-2.4.3-1.fc22 in the future and thus there is no reason to preserve these files on the disk. Or the package may have a wrong GPG signature. Or something similar may happen if someone wants to install 2 relative packages but it turns out that one of them is not available any more. Then you don't need to save the second one because you need it only if the first one is available as well. And imagine that the package has few hundreds of megabytes. And don't forget that this behaviour is easier to implement which in turn makes DNF easier to maintain and thus more reliable. Anyway, as you can see, we are working on changing the behaviour. I just wanted to show that the current behaviour has some advantages and personally, if I was the only user of DNF, I'd stay with the current behaviour exactly because of the reasons above. *** This bug has been marked as a duplicate of bug 1220074 ***