My internet connection is less than 100% reliable, so sometimes downloads get interrupted and have to resume. This results in corrupted downloads every so often. Instead of requiring manual intervention to delete the corrupted file and re-download, Portage should have a configurable option to delete files that fail the md5 check and try to download them again. It isn't a majot problem, but it could save some frustration (you wake up in the morning to discover that "emerge kde" stopped after the second program). Reproducible: Always Steps to Reproduce:
I want to second this bug. Recently, I was installing a new gentoo system. One package (dev-java/bcel) would ALWAYS abort in the middle of the download from one mirror (BAD MIRROR), resulting in a resume on the next server. The result was a CONSISTENTLY corrupted download. I was completely stuck and still would be if I didn't have another gentoo box from where I was able to manually copy the file. THIS IS A HUGE PROBLEM.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for consideration.
Well dunno, this appears to be handled perfectly fine w/ recent portage versions?
(In reply to comment #4) > Well dunno, this appears to be handled perfectly fine w/ recent portage > versions? It does that in the background process if you have FEATURES="parallel-fetch" enabled because the --fetchonly option triggers the more aggressive fetching behavior. Maybe we should a PORTAGE_FETCH_CHECKSUM_RETRIES config variable for make.conf to control the number of retries.
There's support for a PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS variable in svn now, with 5 set as the default number of mirrors to try.
This is supposed to be fixed in portage-2.2_pre5 or earlier.