From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
When up2date is downloading packages, it appears to increment the
progress bar strictly by package count. I.e. the progress bar
increments by the same amount for a ~500KB package as for a 60MB package.

This differs from the RH9 behaviour, where the progress bar
incremented proportionally to the size of the package. I.e. if package
A represents 1% of the total size of all packages to be downloaded,
and package B represents 10% of said size, then:

 [package B comp. increment] = 10 x [package A comp. increment]

This is a user feedback issue - I believe it to be a bug, because it
differs from the prior behaviour. It would also be really nice if
total download sizes (downloaded/total) were displayed numerically, as
they are for individual packages.

Interestingly, the current behaviour is identical to that of the
installation progress bar, where it makes _much_ more sense, as the
actual file copying seems to take a much smaller percentage of the
total time to install a package. For downloading, where download time
is the major part of the task, this isn't appropriate.

Version-Release number of selected component (if applicable):
up2date-4.3.16-1

How reproducible:
Always

Steps to Reproduce:
1. Run up2date on an out-of-date system (full install)
2. Select All packages for update
3. Observe progress bar as downloading continues
    

Actual Results:  Progress bar incremented equally for each package
download completion

Expected Results:  Progress bar should have incremented more for large
package downloads than small ones.

Additional info: