[packagekit] The yum percentage changed callback for refresh-cache
tla at rasmil.dk
Mon Oct 22 02:52:12 PDT 2007
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:
> pct = 0
> if len(self.yumbase.repos.listEnabled()) == 0:
> #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)
> self.yumbase.repos.populateSack(which=[repo.id], mdtype='filelists', cacheonly=1)
> Yum legends, take your marks, get set, go!
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
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.
More information about the PackageKit