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

James Antill james at fedoraproject.org
Tue Aug 28 14:45:35 UTC 2012


On Tue, 2012-08-28 at 05:38 -0400, Zdenek Pavlas wrote:
> >  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.

 Yeh.

> UNKNOWN:
> 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

 This is "just" rpmfusion using a _really_ old createrepo, which doesn't
create the size data ... *sigh*. I'd guess they are on CentOS-5 and
using the createrepo that comes with it. It'll get better eventually, I
guess. Still annoying though.

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

 Ahh, so in TextMeter we have two code paths depending on if we know the
total size or not. See the giant "comment". Basically we drop the
progress bar and percentage completely, and ETA => Elapsed time.
 I thought I'd done the same thing for Multi, but there's no test for
size. So maybe I just assumed we'd have fixed all the missing size data
by the time RHEL-7 hit ... or something. Who knows.

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

 Even without fixing the "unknown total size" output, having the first
pass be 100% correct and the second 100% broken is still nicer in many
ways.

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

 It looks fine if you download a lot of small things (what I assume I
was seeing for a while on rawhide when testing, and thought it worked),
as even at 250k we download small packages so fast that the percentage
looks like it's moving enough. But if you download a small (esp. 1)
number of large things then the percentage becomes much less useful (and
for 1 thing it just stays at 0% the entire download).

> If you think we should make it byte-accurate, I can do it
> (should fix BZ 852279)

 Yeh, shouldn't be a big fix. But with the size thing too, I don't mind
volunteering to do it and copy the bits needed from TextMeter (but I'm
happy to let you do it, if you want :).



More information about the Yum-devel mailing list