Bug 42456 – Add option to re-download after md5 check fails

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Justus Ranvier 2004-02-22 02:05:51 UTC]

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:

[Comment 1 Timothy Miller 2004-11-02 19:39:42 UTC]

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.

[Comment 2 Jason Stubbs (RETIRED) 2005-07-28 07:25:38 UTC]

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. ;) 

[Comment 3 Marius Mauch (RETIRED) 2007-01-11 12:58:43 UTC]

Reopening for consideration.

[Comment 4 Jakub Moc (RETIRED) 2008-02-17 21:49:25 UTC]

Well dunno, this appears to be handled perfectly fine w/ recent portage versions?

[Comment 5 Zac Medico 2008-02-18 00:35:11 UTC]

(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.

[Comment 6 Zac Medico 2008-03-14 06:54:25 UTC]

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.

[Comment 7 Marius Mauch (RETIRED) 2008-03-20 18:14:35 UTC]

This is supposed to be fixed in portage-2.2_pre5 or earlier.

[Comment 8 Marius Mauch (RETIRED) 2008-03-20 18:15:01 UTC]

This is supposed to be fixed in portage-2.2_pre5 or earlier.