Red Hat Bugzilla – Bug 492985
RFE use links instead of copies to yum cache when fetching from local repo
Last modified: 2014-01-21 18:08:47 EST
Description of problem: When using a local repository copies of the files already on the hard disk are made in yum's cache area. This significantly increases the amount of space used on / when doing upgrades. This can be a problem for large upgrades. Version-Release number of selected component (if applicable): yum-3.2.22-1.fc11.noarch How reproducible: 100% Steps to Reproduce: 1. Use rsync to make a local repo 2. Update the repo config file to use appropriate file: url 3. yum update Actual results: rpms are copied to cache Expected results: rpms are sym linked to from cache or appropriate direct paths into the local repo are used. Additional info:
The attempted fix in yum-3.2.22-2.fc11 made things worse. Even -d 9 didn't seem to show why, but I get errors like the following when updating from local repositories: Error Downloading Packages: system-config-rootpassword-1.99.4-4.fc11.noarch: failure: Packages/system-config-rootpassword-1.99.4-4.fc11.noarch.rpm from rawhide: (256, 'No more mirrors to try.') Reverting to yum-3.2.22-1.fc11 gets things working again (though by making an extra copy of stuff). I am using file: urls in my local repositories.
Bruno, thanks i'll take a look. I'm not sure that the above is b/c of the fix, though.
I just tested it locally with an invalid package and this looks correct. The fix is doing what it should. The package doesn't check out - and in your case b/c there is no other mirror to hit, it's exiting with an error msg. Are you sure that system-config-rootpassword-1.99.4-4.fc11.noarch.rpm is valid? run rpm -K -v system-config-rootpassword-1.99.4-4.fc11.noarch.rpm
[root@bruno bruno]# rpm -K -v /home/fedora/development/i386/os/Packages/system-config-rootpassword-1.99.4-4.fc11.noarch.rpm /home/fedora/development/i386/os/Packages/system-config-rootpassword-1.99.4-4.fc11.noarch.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 Header SHA1 digest: OK (13bdb4232263a57aa7dab70d4f377b33391190f2) V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 MD5 digest: OK (01f72948b7880916c9086608fdd7c430) rpm has been kind of flakey with the d22e77f2 the last few days, so I had to remove it. So this is really new good behavior in yum-3.2.22-2? If so the error message could explain what happened better. It looks too similar to what you get when the file is missing. Will --nogpgcheck get around this if I want to manually override the check?
It's similar to what you get when the file has failed the check and there is nothing else to do. try the --nogpgcheck on it, if that's what's failing it.
and I was wrong about that 3.2.22-3 fixes a different bug that caused file:// urls to not work.