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):
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
rpms are copied to cache
rpms are sym linked to from cache or appropriate direct paths into the local repo are used.
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.
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?
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
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.