Bug 496385

Summary:	RFE: Better callback interface for progress
Product:	[Fedora] Fedora	Reporter:	Mary Ellen Foster <mefoster>
Component:	python-urlgrabber	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dmach, ffesti, james.antill, tim.lauridsen
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-18 21:31:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mary Ellen Foster 2009-04-18 13:59:17 UTC

Description of problem:
If a downloaded package doesn't match the checksum and has to be downloaded again, the cumulative progress number does not go down. I experienced this today when trying to install a few packages on my Rawhide system when most mirrors are not up-to-date -- it had to retry a large package several times, and by the third of fourth time the progress went up to about 110%. On the subsequent try -- which started with a progress over 100% -- it didn't even show any cumulative progress at all.


Version-Release number of selected component (if applicable):
yum-3.2.22-4.fc11.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Try to install a big package that fails on most mirrors
  
Actual results:
Progress keeps counting up on each try

Expected results:
Progress should reset to where it was before the unsuccessful attempt

Comment 1 James Antill 2009-04-18 19:26:45 UTC

 For re-downloading the same package, there's little the callback can do as the hash verify is done outside the callback.
 We have a workaround for when it moves onto the next package it resets the total downloaded (from the yum side), so the problem doesn't last long. And hopefully the rare occurrences of packages with the same name but different hashes should go away completely if the signing changes.

 We could maybe put another hack in for if basename(current) == basename(old) but it'll probably just fail in other weird ways I can't think of. I'll just move it to an RFE against urlgrabber, where it'll probably die a lonely death.

Comment 2 Daniel Mach 2018-07-18 21:31:55 UTC

yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.

Comment 3 Daniel Mach 2018-07-18 21:34:28 UTC

yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.