> We can't/shouldn't show percentages/progress-bar if we don't have > the total size. Doing that means that the progress bar stops for unknown > (to any sane user) reasons with the degenerate case being we get to 100% > and stay there, which they are guaranteed to notice and open bugs about.
I agree, mostly. The fact that progress bar does not stop when downloading a file with unknown size is actually a bug, indeed. But the unknown-sized files are from small 3rd party repos, much smaller than the ones with known size. And it's getting better, as group and group_gz finally have <size> tags, too. KNOWN: f17/filelists_db 20187248 f17/other_db 6667474 f17/group_gz 444401 f17/primary_db 12150697 f17/prestodelta 386966 fedora/other_db 6606486 fedora/filelists_db 1784053618 rhpkg/filelists_db 8681 rhpkg/other_db 10712 rhpkg/primary_db 11773 fedora/prestodelta 94311 updates/filelists_db 9869691 updates/other_db 3209426 fedora/primary_db 11615346 updates/primary_db 5709635 updates/prestodelta 1065324 Total 95.878.707 UNKNOWN: fedora/group_gz 417270 rpmfusion-free/other_db 96945 rpmfusion-free-updates/filelists_db 230809 rpmfusion-nonfree/primary_db 11721038 rpmfusion-nonfree/filelists_db 85740 rpmfusion-free-updates/other_db 185086 rpmfusion-free-updates/group_gz 15790 rpmfusion-nonfree-updates/group_gz 1036 rpmfusion-free-updates/primary_db 410637 rpmfusion-nonfree/other_db 49067 rpmfusion-nonfree-updates/filelists_db 88235 rpmfusion-free/primary_db 272783 rpmfusion-free/filelists_db 186772 rpmfusion-nonfree-updates/primary_db 166202 rpmfusion-nonfree-updates/other_db 91173 updates/updateinfo 785031 updates/group_gz 430557 updates/pkgtags 77608 Total 15.311.779 > alternative is to have the percentage goto 250% or whatever (and the > progress bar will still be "stuck"), and that will also cause > unhappiness/BZs. That's what happens already, when we do the split in Yum. Downloading 20 files with apparent sum(size)==0 bumps the bar to 100% on first byte. > That's why I split it at the yum layer, there didn't seem to be a > reasonable way to deal with a mix at the urlgrabber layer. The split "fixes" the 1st pass, but the 2nd is still broken. When we mix with_size and no_size in the same batch, it's less visible (which is better, IMO). > Ahh, that was a missed fix in > d09bda90f15eee161a17944428e9bec0bfc812b6, > for the old UI. Want me to send a patch, or you want to just do it? I was thinking that the current file-counting percentage display was fine, as it's always "right" (solves the unknow-size issue). If you think we should make it byte-accurate, I can do it (should fix BZ 852279) > Also ... 20 without size? Do some of your repos. have no size > information on any files? above :) F14/i386 repos, F17 to test the fast local mirror. _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
