Bug 469680

preupgrade uses the same UI as yum when downloading packages, so we have:

current package, total pacakge, package name, total progress percentage, current progress percentage, current progress bar, download speed, current size, time

...while it's true that it can download 500-600 packages before the current progress is on the screen for long (which includes the total progress percentage), this wouldn't change by making the progress bar for the total amount of data to be downloaded.
 Also given that on a test I'm at 600/1902 and am still at a total progress of 0% ... I could see how making the progressbar be the total progress would be annoying/confusing in that it would change so slowly.

Maybe it doesn't make much different if the mirror is on a local LAN but it does if its not. I'll attach a graph that I produced by looking at the ctime of the preupgrade rpms (I haven't actually done the upgrade because something came up, although all the files are downloaded)

x-axis is time in seconds, with 0 being the time that the first package would have finished downloading. y-axis is fraction complete.

When the progress meter is file-based, it ends up at 80% when the download is only 30% completed, but the size-based one is roughly linear (its not quite, presumably due to the ~50ms latency combined with the very small files that it starts off with

It is the same way that yum manages things, but:
 - with yum's line-per-package UI thats really the only way to do it.
 - Its clear that thats what its doing.
 - I don't think that yum's behaviour is ideal, but it doesn't tend to matter, since yum doesn't tend to download ~1000 (out of 1281) packages under 1M (including 400 packages under 100K) and end up with 2 packages over 100M

Created attachment 322806 [details]
graph showing file-based progress vs size-based progress

Created attachment 322808 [details]
Random order comparision

And for comparison, heres what the two methods look like if the files were downloaded manually. Previous versions weren't actually random, but it'll do as an approximation.

> When the progress meter is file-based, it ends up at 80% when the download is
> only 30% completed, but the size-based one is roughly linear

 I have no idea what this means.
 What do you mean by "progress meter"?

 As I said in comment #1, there are a number of stats. that are produced. One of which is the "total progress percentage" which is the second thing in brackets. This is based on size, not number of files, and so goes up "linearly".
 The "progress bar" which looks a bit like this: [===   ] ... is per. file (based on the file size), which seems the most useful to me given that we only have space for one.

This is a bug report for preupgrade, not for yum - http://fedoraproject.org/wiki/Image:Features_PreUpgrade_mizmo-mocks.1.png (second from the bottom) is the bit I'm talking about. Looks slightly different in the updates-testing preupgrade, but not enough to be relevent.

Changing the progress bar in the preupgrade GUI is actually pretty easy - I'll put it on the TODO for 1.0.

preupgrade-1.0.0-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/preupgrade-1.0.0-1.fc10

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

preupgrade-1.0.0-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

preupgrade-1.0.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

preupgrade-1.0.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.