[Yum-devel] [PATCH] Drop the with_size & no_size split.

[Zdenek Pavlas]

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