[packagekit] The yum percentage changed callback for refresh-cache

[Tim Lauridsen]

Richard Hughes wrote:
> At the moment we have the yum refresh cache percentage callback as big
> jumps, e.g. 0, 25%, 50%, 75% and 100% - this isn't very nice when the
> time between jumps can be a few minutes.
>
> We seem to get lots of subpercentage updates, which are good, so could
> we _refine_ the percentage updates with this information?
>
> i.e. we still do the "bump" computation, but add to it the
> subpercentage / len(self.yumbase.repos.listEnabled()) to get a much
> smoother scale.
>
> Does this make sense?
>
> The code that works out the jumps is this:
>
>         self.percentage(0)
>
>         pct = 0
>         try:
>             if len(self.yumbase.repos.listEnabled()) == 0:
>                 self.percentage(100)
>                 return
>
>             #work out the slice for each one
>             bump = (100/len(self.yumbase.repos.listEnabled()))/2
>
>             for repo in self.yumbase.repos.listEnabled():
>                 repo.metadata_expire = 0
>                 self.yumbase.repos.populateSack(which=[repo.id], mdtype='metadata', cacheonly=1)
>                 pct+=bump
>                 self.percentage(pct)
>                 self.yumbase.repos.populateSack(which=[repo.id], mdtype='filelists', cacheonly=1)
>                 pct+=bump
>                 self.percentage(pct)
>
> Yum legends, take your marks, get set, go!
>
> Thanks,
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   
The problem is that we don't know which files there will be download 
while setting up the repo, it all depending on the age of the metadata 
in the cache.
The download progress handler there is sending the subpercentage signal, 
don't know  the pre history, it is only knowing the file and how many 
bytes to download and the total size of the file.
In package download for package installation/updating we have a better 
case, because we know the files to download upfront so we can tell the 
download progress handler that we have x files too download, so we can 
bump the percentage at each file.

Tim